jducoeur | A Few Minutes of Querki

Entry tags:

querki

A Few Minutes of Querki

There's a lot of grand vision to this project, and almost too many ideas and features to absorb. So rather than drowning folks in all of those details, let me describe a few minutes of what Querki is supposed to be like in practice. Keep in mind, nothing at all has been written yet, and it'll probably take a year for us to get all of the main pieces in place. But it's important to know where we're going. So here's a scenario showing what this system is supposed to feel like once it's all up and running.

A Few Minutes: My Cookbook

Last night's dinner was good -- I made soft tacos, and experimentally decided to make my own Pico de Gallo. It was tasty enough that it's worth writing down.

I open up Querki, which presents me with all of my Spaces: the Comic Book database, my Contact List, my Blog, and my Cookbook. I choose the latter, and it opens up. I didn't build the format of the Cookbook myself -- one of my friends did it a couple of months ago, and shared it as an App. I picked that up for myself, getting my own Cookbook, and have been moving all my recipes into it ever since.

I select "new Recipe", and get presented with a form. I fill in the fields that the Recipe model knows about: the name, how many it serves, and so on. It asks me for ingredients, one at a time, with the quantity of each. I give it a narrative of how to make the Pico, and hit "Save"; it shows me the newly-created Recipe, all neatly formatted. (My friend who built the Cookbook app did a good job with the formatting, so that the ingredients show up as two columns; I like that touch.)

Since Recipes have a Rating property, I can say how much I like this one. I give it four stars out of five: solid, but could use some tweaking yet.

I realize, though, that the Cookbook app is actually missing something I care about. I'm all about attribution and documentation (comes with being a Laurel), so I really want to track where I got this recipe from. No problem, though: I just tell Querki to add a Sources property to my Cookbook, and to add that property to Recipes. I edit my Pico recipe again, which now shows the Sources property -- I add a few links to the web pages I used, and save it again. I tweak the Recipe format to show Sources down at the bottom, and *voila*: a list of links, which I can refer back to or query later. I go over to the Cookbook app itself, click on the Ideas and Suggestions page, and suggest that my changes get lifted into the common app so that everybody else can use it.

I've set up my Cookbook to automatically publish new entries, so a post shows up a few minutes later on my Facebook Timeline, with a pointer to the entry. It also shows up as an RSS feed in LiveJournal -- I mixed in the What's New app, so new entries basically get turned into blog posts automatically.

My friend Ailish likes the sound of it, but being Canadian she prefers things in metric units. No problem: she right-clicks on one of the ingredients, chooses "Convert to...", picks Metric, and it all shows the way she wants. (Personally, I don't use that much, except with the medieval recipes I've been working with -- I enter those with the ancient Arabic units, and then convert them to US for actual cooking.)

While I'm in my Cookbook, I remember that my friend Anna has asked me for an index of my medieval recipes. Easy enough: I pull up Querki Explorer, and build a quick filter. I tell it to list my Recipes, then filter for just the ones that are tagged "medieval", group those by the TimePeriod property that I added in, and for each one list the name of the recipe. The results look right, so I tell Querki Explorer to save that as a new "Period Recipes" page, and I send the URL over to Anna. That'll now automatically update whenever I add new Recipes, so she can get an up-to-date view any time.

What's Going on Here

The Cookbook isn't the point above, but is kind of needed to illustrate the point. Querki is a *platform*. In and of itself, it doesn't do anything. Instead, it is designed to make it easy to build apps that are useful and personalized.

Keep in mind, none of the above is rocket science. If you're a professional programmer, it's not hard to build the sort of Cookbook application I describe above. If you know all the APIs and are good with Rails, it would probably only take a couple of days to slap together.

But seriously -- why would I want to spend a couple of days on this? All we're doing here is keeping track of a little data, saying how to display that data, and tweaking it as we go. This should be *easy*, not just for the computer pros but for anybody. The Cookbook app is built by end users, not by high-priced programmers, and tweaked by others.

So that's where Querki comes in. It builds in all the boilerplate, everything from working with the social networks to managing the database to doing the fiddly page rendering. It gives me powerful tools for exploring and collating my data, with wizards to make that easy. All I do, as an end user, is say what I want to keep track of, what it consists of, and how to display it. That's not trivial, but it should be a matter of minutes or hours, not days. Moreover, the system should cope with me changing as I go, letting me add new concepts and ideas as I learn more, so that building this stuff becomes quick, fun and low-risk.

Flat | Top-Level Comments Only

I'd noticed this online yesterday on GitHub.

Did you want to include unusual phrasing like "I'm a Laurel" and that sort of thing?

For now, yes. That's a deliberate decision: while this is still a tiny garage project, I need to enthuse, and that requires letting it be personal.

As the project grows, I'm going to make it less so -- there's going to be a point (possibly within just a couple of months) when I need to take the word "I" out of most of the online documentation. But for now, it's a bit more honest to leave it in, and I need that honesty. (And yes, I'm *well* aware of the social interactions here, and paying attention to them.)

So Querki is going to be HyperCard, but building on all the experiences of the last 25 years? If so, that sounds spectacularly good.

Honestly, I never worked with HyperCard, so I don't know how it's going to be similar and different. I had been wondering, though: HyperCard was quite conspicuously the last system I remembering people describing in the sorts of terms I'm using for Querki. (And any insights you might have from HyperCard experience would be more than welcome -- I'm always happy to borrow from the best...)

HyperCard had an extremely shallow initial learning curve. You could walk a non-programmer through building a recipe stack in an hour or so. After you defined a recipe card by dragging fields on to a blank card, then adding some static text labels, you would have a working system. Then you could improve it by adding buttons and writing scripts for each button. The scripting language was very clunky and kind of slow, but it all ran on a machine with about the same specs as a PalmPilot Pro.

Huh. Wikipedia says that Ward Cunningham was thinking about a HyperCard system when he built the first wiki.

Hah! Okay, that is a *magnificent* bit of things coming full circle, since ProWiki -- the original prototype of Querki ten years ago -- was directly based on Cunningham's WikiWikiWeb code...

There were scripts attached to the stack, to backgrounds (the classes of cards), to cards, and to elements on cards or backgrounds. Scripts could include event handlers and functions—rather like JavaScript.

The language was clunky, yes, but it was very approachable; it was one of those languages that try to look like English, so non-programmers don't get scared off. Google for HyperTalk; you won't want to imitate too much of it, but you can get some ideas.

Come to think of it, I've still got an old Mac that's got Hypercard on it; if you want to experiment, I could see if it still runs. It's been boxed up since 1998 or so, so the odds aren't great...

The language was clunky, yes, but it was very approachable; it was one of those languages that try to look like English, so non-programmers don't get scared off. Google for HyperTalk; you won't want to imitate too much of it, but you can get some ideas.

Will do, although part of my goal is that most end users won't work with the language at all.

Much of the design is built around the idea of Querki Explorer, an interactive wizard that lets you interact with your data step-by-step, and the idea is that, by a year from now, most non-programmers will usually use that. That outputs the underlying language, and the language (Querki Query Language, AKA QL, pronounced "cool") is designed specifically to map 1-to-1 to the wizard.

I have high hopes there. My experience from ProWiki is that you mostly care about data transformation for the sorts of problems I'm aiming at, so I've wound up with a pipeline-styled functional language that is pretty simple and elegant. We'll see how well it flies when it confronts a variety of real-world problems.

I suspect I don't care too much about kicking the tires of Hypercard. But you're correct that I should at least know what they did, and what people liked about it...

There are going to be times when users want to engage a little bit at a lower level. You should definitely check out what hypercard did with making the syntax as facile as possible. Also the other things they did, like making it easy for every object to have properties that were innate or definable, and all addressable and mostly manipulatable.

Got any good pointers? I'm sure that I'm going in somewhat different directions -- among other things, I'm focused on rather different use cases than much of what HyperCard seemed to get used for -- and the style is rather different (I'm actually winding up with a fairly pure functional language, at least at the core), but I do want to understand what they did and what worked well. (And especially their object/property model.)

Tricky. Being an effectively dead system (although there are live descendants), there aren't a lot of live resources. You might get a feel and some information from http://www.digplanet.com/wiki/HyperTalk or http://edvista.com/claire/hypercard/index.html . I think the important paradigms (many of which you're already familiar with and use regularly) are the object oriented, dynamically typed nature of it, the subject/object/verb 'natural' syntax, scoping of variables, and event handling. http://www.amazon.com/dp/0966551427/ was the 'bible'. And http://www.youtube.com/watch?v=H5-T_S50Sr4 is a fun demonstration.

Oh, and of course, Myst is an even more fun demonstration of how far HyperCard was taken in the day. Definitely not a useful example for Querki, but a fun one.

Yaas. One of the things I *am* beginning to ponder is how one would build a game on top of Querki. Not at all sure what the answer will be, but I'd be a little surprised if we don't wind up trying...

I had a book on Hypercard and HyperTalk, which I don't think I ever got rid of; I probably know what shelf it's on. I can check sometime if you want.

(The failure mode would be if it never got unpacked after we moved to MA...)

If it's convenient, I'd be interested in looking through it, yes. (But don't make yourself nuts...)

I don't intend to. :-) There are two small bookcases with programming books; if it's not on either of them, I'll give up.

Yes and no. I did a -lot- of hypercard back in the day. As far as rapid structure building, linking, data manipulating, yeah. But Hypercard did so much more, especially in regards to multimedia, but so far predated the web, especially the social web, that it looks more like a case of parallel philosophies.

So far this use case describes creating, editing, and formatting data, with a little computation (units conversion). That's all great. The further question that immediately came to my mind was the extent to which an app could interact with already-existing data. Specifically, the use case that came to mind with this example was:

I start typing in my recipe. This isn't the first time I've played around with pico de gallo, so when I type the name the system pops up a list of the others that match. I take a quick look, conclude that no I'm not about to duplicate work I've already done, take note of my prior 1-star effort that involved canned tomatoes instead of fresh, and proceed. Later, when I give it my 4-star rating, the system helpfully offers that when I used these ingredients in another recipe, I added a splash of habenero and rated that 5 stars.

The next time I want to make tacos I come back to my app, and in addition to asking it what I've done before (search my recipes), I have it search the recipes from people I've subscribed to (using the handy "subscribe" link from some previous query, or because when you published one of your entries to LJ I subscribed that way). Still seeking inspiration, I ask to see all public five-star pico-de-gallo recipes that include cilantro, and one of the results is from someone I know but didn't know was on Querki. So I add him to my subscription list.

That's pretty rough, especially the stuff about subscriptions, but it's where my brain went so I thought I'd share. The "helpfully tell me stuff from my own data before I know to ask for it" part would be pretty helpful. (Think of it like the list of existing questions you get on Stack Exchange when you start to type a title.)

the extent to which an app could interact with already-existing data

Where my brain went when you said that was pulling in data from non-Querki sources, like an API for BoardGameGeek (I don't know that one exists, but I think so, since there are multiple Android apps).

Not the first time *that* has been suggested, although I don't yet understand quite what that would mean in practice. Writing an API in Querki that exposes the data stored in it is straightforward (and on the medium-term roadmap); incorporating external APIs and making use of them is intriguing but so far too fuzzy for me to make good use of. (That is, I know how to do it technically, but it's far less obvious how it would be exposed to the end user.)

We'll need to define some Use Cases where that functionality is crucial, and then we can figure out how much effort it would be, and when it's going to be worthwhile to do it. I'm pretty sure it doesn't go into the first year (there's plenty that is clearly more important), but I'm not sure when after that it gets to the top of the stack...

It's certainly possible to create an interface for bringing in external data and mapping it into your system's data model. But somebody has to write those transformation rules, the logic that, e.g., takes the XML returned from the BGG web service and turns it into something meaningful. Technical folks can do that, but enabling an end user to do that seems, to me, Very Challenging.

(I'm totally speculating about BGG having a web service. It's just an example.)

I dunno -- the more I think about it, the more the idea isn't crazy. From a well-formatted Web Service, there's enough metadata to be able to build a UI (indeed, that's how one typically works with Web Services in the Microsoft stack). And Querki is flexible enough that building at least a crude mapping probably isn't that hard.

And having said yesterday that I don't know *why* we would use that, I've come up with two concrete Use Cases for it in the past 18 hours. So this might make it into the medium-term stack yet...

Consider the wine list scenario. If there's some Web service with a categorization of wines, you could use that to provide suggestions, or maybe autocompletion, and not have to type as much—always a nice feature on a phone.

Edited 2012-10-22 14:04 (UTC)

Yeah, I had just arrived at almost the same idea by thinking about LibraryThing. I do *not* plan to implement a Book List myself (solely because I *like* LT and don't want to compete with it), but I was chewing on how I would implement their search-and-add functionality, which is very similar to what you're describing here. (In their case, using the Library of Congress and various major libraries.)

There you are: someone might want to use Querki to provide their own annotation schema on LibraryThing—e.g., someone like the authors of Law and the Multiverse might want to provide commentary on how accurately each book represents the law.

Or an oenophile who's cloned your wine list might want to augment it with pointers to books that mention particular wines.

Hmm -- intriguing, but tough. This is *way* more sophisticated than anything I'm targeting in the first year or two, and I'm going to need some time to digest the implications. Honestly, it's a little intimidating, because I don't know *how* I would do some of those features correctly.

(Some imply a lot of knowledge of the semantics of the problem, which I'm initially *specifically* not worrying about. Since I'm focused on the platform, the question becomes, how do we provide a platform for *describing* those sorts of semantics in a way that end users can actually deal with? Or if this is really a data-mining problem, which it might be, how do we build the system to extract and extrapolate that sort of information automatically?)

Still, that's a fascinating exploration, especially for a ways down the road, after I've dealt with the easy problems. One of the problems with platform plays like this is that they tend to get stale after doing the easy stuff, so it's good to have some higher-level goals to aim for afterwards. Thanks, and I'll add this to my Use Case list, if that's okay with you...

I aim to challenge. :-)

Seriously, I know some of that is really pie-in-the-sky, some is doable but probably not a priority, and some maybe is helpful. You have a way better handle on which fits into what category than I do. You are certainly welcome to turn anything I comment about on these posts into use cases if that helps you!

Thanks!

Flat | Top-Level Comments Only

A Few Minutes of Querki

A Few Minutes: My Cookbook

What's Going on Here

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject