Previous Entry Share Next Entry
A Few Minutes of Querki
jducoeur wrote in querki_project
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.

  • 1
How will the interface work with mobile devices?

One app I could see wanting would be a wine list. I'm a wine drinker to the point of I know when I like something but I have no memory for which brands and varietals those were. Having a place to jot down which ones I like after drinking it would be handy (yes, there are existing apps for this, but having that list in one space with my other mental lists would be nice).

Damned good question. Mobile is clearly crucial, and I plan to work on that fairly early, but I'm not going to pretend to know all the right answers yet. I think we're going to take some of the use cases where mobile is clearly really useful, figure out what those need, and proceed from there.

And yes, a personal wine list (probably connected to a community-driven database of some sort) is very much the sort of thing that Querki is likely to be quite good for. Okay if I add that to my Use Case list?

Of course you should feel free to use the wine list suggestion, along with anything else I mention here.

The probabilities that we would use a wine list app, esp if we can input into J's phone when we decide we like something, is fairly high...

Thanks -- here's my writeup. Other suggestions more than welcomed...

Just read the Use Case. As you say, Mobile is important for entering after a glass at a restaurant, but it's also very important when browsing in a wine store and trying to remember which bottle you liked.

In checking the list I made on Evernote, I broke up my flat fields as: Type (White, Red, Etc.), Grape (Reisling, Shiraz, Etc.), Vintner, Name (Bottle), Origin (Country), Year, and notes (generally where I encountered it). I didn't include a rating because it's a small personal list and I only noted ones I knew I'd be happy to buy again.

Besides the obvious record keeping, I included Vintner and Origin in part so I could start to try to notice trends of what types of things I liked.

I like your idea of using tags rather than Type with Grape as a sub-category (I just did that becuase I was writing flat in evernote).

I didn't include a rating because it's a small personal list and I only noted ones I knew I'd be happy to buy again.

Mmm -- good point. That varies (I also track what I *don't* like, so I know not to get it again), but for many folks it's going to be easier to just track "likes", and that would simplify the UI a bit.

I like your idea of using tags rather than Type with Grape as a sub-category (I just did that becuase I was writing flat in evernote).

Yeah, I concluded a while ago that many things really want hierarchical tags -- moreover, they want multi-valued tags, since different people have different priorities, and often care about multiple ones. For example, Kate can only drink Whites, and strongly prefers Dry Whites, so the really important breakdown for us is the sub-flavors *within* Dry White -- Acid, Mineral, and so on. And Country is quite important, although we pay only loose attention to Year.

So Tags are one of the heart-and-soul data types for Querki, probably *more* important than conventional types like Number. I expect to use them quite heavily, and I'm planning a fairly sophisticated tagging system in the long run...

  • 1

Log in

No account? Create an account