I’ve met with Mark, the owner and developer of Querki, a couple of times now. I shall now do my best to summarize my understanding thereof, with the purpose of identifying any obvious gaps in my knowledge and any clarifications that may be needed.
It is a way for you to keep track of your information, the way you want it, not the way some distant programmer or corporate executive thinks you should. You should be able to share that information with exactly who you want, and it should be easy to work together on it. You should be able to use it from your computer or your smartphone, having it all there when you need it.
Everyone has a lot of information to keep track of, much of which they would also like to be able to share and discuss with others. Querki offers a customizable interface in which to manage, display, discuss, share, and explore small to medium data sets with small to medium-sized groups.
An existing example of this is from the Cook’s Guild in the local SCA chapter: they have recipes from specific time periods, and they figured out reconstructions of those recipes so that they can be made nowadays.
As you can see in the screenshot above, the recipes are categorized by type of food, period of food, and culture. Clicking on any of those — also known as tags — will bring you to a list of relevant recipes.
Many of Querki’s useful abilities are currently only possible using the Querki programming language (QL, said as ‘cool’) — such as finding a recipe for 14th century French pancakes in the above cook’s guild space. In the future, the plan is to make common tasks easy to do without the use of QL.
To view a Querki space, one only needs a link to said space. Precisely what a space will look like varies depending on the desires of the owner of that space.
One of the topics that Mark and I are currently discussing is the idea of a basic default structure for a space . This would hopefully mean that those who don’t want to spend a lot of time structuring their space will still have usable spaces for people to access, discuss, and interact with the data. For those who want to affect structure, that can be done when one has time and inclination, smoothly allowing the transition from a basic Querki space structure to whatever modifications are desired.
A Querki space is meant to be a place for information to be stored and shared. To do this, however, one needs to tell Querki how you want your information to be structured. A model is how you tell Querki the structure you would like for your information.
For example, a model for a CD might include properties for the album title, author, song lists, genre, and publication date, as well as an auto-generated name of the model. Properties can be added when the model is first created, as well as after the fact.
Properties have types. Types include the tag type, the text type, the photo type, and the views type, among others. Properties can themselves have properties, such as with tags. Tags are both the name of a thing and have the possibility of pointing to a related model. Tags may have a description, visible when the tag name is clicked, or simply show a list of things with that tag.
Views are ways to display models. The current default view shows a list of things with that model associated with it. There is also the possibility of a ‘print view’, which will tell Querki how to print the model.
Models will have instances of that model: rather than the generic properties that models contain, instances contain information specific to the instance of that model. In our CD model example, you might have the CD Zoostation by U2, as an instance of the CD model.
In addition to models and their associated pieces, Querki has pages. These are unstructured, and may be understood as a report from a data base, or a wiki page.
Major goals of Querki
- Allow for integration with existing social networks in order to help people connect with and invite people they know to work together on Querki.
- Get Querki to the point of general availability (it’s currently in beta) and having people interested in paying for it. It’s not yet clear what this entails. More investigation required.
Different skill levels of users
Currently, there is an idea of an ‘easy’, ‘medium’, and ‘hard interface. These largely describe the degree to which one needs to be able to program to get the interface to do what you want.
- The “easy” interface is meant to allow people to use a published template (aka ‘an app’) from an existing Querki space to structure their own, and to use someone else’s space.
- The “medium” interface allows more customization, but doesn’t present the more complicated/confusing programming options to the user.
- The “hard” interface is meant for hard-core programmers, allowing the use of every tool available in Querki. This allows the building of templates (apps) and lots of power user commands through the underlying programming language QL (pronounced “COOL”).
It is not currently very clear to users what their options are for using QL.
Search is very basic right now, with searches being within a Querki space, on plain text strings. The goal in the future is to include the ability to search across spaces as well as objects, including tags.
There are currently icons for editing a page, refreshing a page (with your changes?), and publishing a page (for those spaces which do not want changes to happen immediately during editing). Are these reasonable things to have as icons? Do they need text also/instead?
Mobile is very important! Consuming a page should be possible even on small phone screens. Editing should also be possible on a mobile phone. Designing a page for a phone isn’t likely due to small screen, but planned for tablets.
Data manipulation/query building talks about the need to do some basic filtering and sorting of the information in an instance. We need to figure out the most common queries of this type, and see how many can be abstracted away from the underlying programming language for use by anyone/everyone.
Specific pages in need of (design?) work: front page, help, contextual help, model design page/advanced editor. The programming UI needs help (see the design page), and likely needs a simple IDE.
Querki spaces are mostly publicly visible, which should help come time to improve the login page/start page.
Tag names cannot currently be the same name as the model associated with them, due to the fact that tags point to a related model rather than containing it. This may need to be invisible to users to avoid confusion?