Previous Entry Share Next Entry
Release Alpha-RC3
querki
jducoeur wrote in querki_project
... okay, so I failed at feature freeze.

Kate is supposed to be the next person joining Querki. But when I brought it up, she made clear that the Space she wants is a shared Shopping List, to replace the one I keep in my phone. My initial reaction was, "Ack! Too much work! Can't do it!". But then I thought about it for about ten minutes, and changed my mind.

The thing is, a good Shopping List is all about selecting from a persistent list. Some of the list is one-offs, but most of it is just a checkoff list, drawn from a master list of stuff you use over and over again. Which is, actually, a pretty good description of what a Set of Links looks like. The Space is mostly made up of little Items, which are mainly a name. The Shopping List is a Set of Links to those Items, which you can check off with one click. The only weakness is that you *also* want a list of all the known items, with a really easy way to put them onto the list and to add new ones. But really, that's mostly a new bit of UI, not a big new concept.

So I wound up taking a day or so to build that new UI. We now have a new command, which looks kind of like this:
[[Shopping List -> Contents._editAsPickList(withAdd)]]
That is, on my Thing named "Shopping List", I have a property "Contents", which is a Set of Links, with a Link Model specified. (That is, we know what kind of Things this is a list *of*.) This command displays *all* Things that derive from the specified Model, as a bullet list, with a checkbox next to each indicating whether it is currently in the set.

As a kicker, the "withAdd" parameter (which is just a token) says to also have an input field at the bottom, that lets you quickly add new items of this model. I confess, this idea is a tad half-baked at the moment, and likely to evolve further, but it seems like a good starting point. Indeed, I suspect that this command will eventually be deprecated and replaced with something more general like:
[[Shopping List -> Contents._edit(displayAs = pickList, withAdd)]]
But that requires named parameters, which haven't been implemented yet.

Eventually, I'll be playing further with this. For example, the Item model has a Source tag property -- basically, where to get this Item from. In the medium term, we'll add filtering, so I can say something like:
[[Shopping List -> Contents._edit(displayAs = pickList, filter = equals(Source, Costco), withAdd)]]
Basically, the filter will say that I only want to show the Items whose Source is Costco -- that way, I can have little sub-list pages (probably just generated when looking at the Source tags) for what I need from each place.

Anyway, this feature is now live, so I'm going back to testing. Alpha should be quite soon, once I sanity-check some core scenarios...
Tags:

  • 1
A feature must fight for its life, unless it is "fight with your wife." Then you roll with it.

Interesting. Amanda and I have been using Wunderlist as a shared list tool (and I use it independently as a multi-list tool, but a few of them are shared). But it is in no way behaviour modifiable. Some of my lists, like a voicemail log, have no need for repeatable elements. But those like packing or grocery lists do. One tool that can be tweaked to do both well sounds like an improvement opportunity.

Also, you need to bake a UI for removing things from the list, or maybe adding things to the list that are those one-offs.

I will say, one of the compelling usability features of Wunderlist is that a single click will mark an item as 'complete' and take it off the main view. Which is invaluable when grocery shopping and needing to see what items have yet to be obtained.

Also, you need to bake a UI for removing things from the list, or maybe adding things to the list that are those one-offs.

Yep -- on the to-do list, although a ways down. I'm able to get things *functioning* without that, but that'll be necessary to make it genuinely *usable* (in the UX sense).

Of course, it's already possible to delete things -- it's just too laborious to be appropriate. Currently, you have to go to the page for each Item, select "Delete" from the menu, and confirm in the dialog. It ought to be easily done, probably as a one-click, from the overall alphabetized list. And it's not actually *difficult* to implement that -- it's probably about two hours' work to add, half UI and half adding a new AJAX entry point for delete. But one thing at a time: this project has eaten enough time for the moment. When somebody complains, I'll deal with it.

I will say, one of the compelling usability features of Wunderlist is that a single click will mark an item as 'complete' and take it off the main view. Which is invaluable when grocery shopping and needing to see what items have yet to be obtained.

Yep -- my version (which was inspired by the Durable Checklist feature of Note Everything) does the same thing. Conveniently, the Tag Set UI (based on the wonderful open-source tool Manifest) already had that capability, so it was basically trivial.

But that's why I decided to implement our Shopping List as two distinct pages:

-- Add Items, which shows the full _editAsPickList(withAdd) view of everything, which is optimized for *adding* things to the list; and

-- Shopping View, which shows the ordinary _edit view, with just the items that are actually on the list, and is optimized for *removing* things from it.

As is the Querki way, I spent about a day implementing the new system feature, and half an hour on the data entry of everything on my "standard" shopping list, but only a whopping ten minutes actually implementing the Space. That's how it should work: the entire "app" consists of maybe 15 lines of text, including two one-line QL expressions...

Just so. That's the thing about Querki's intended approach: I don't expect it to be as good as a well-tuned "real app" that meets your needs just right. But in many cases, it'll eventually be a lot more useful than one that is almost, but not quite, right.

Of course, I expect it to take most of the next year to get there. But suggestions for improvements are always welcome. Frankly, this sort of thing is the *fun* part of the project -- figuring out how to craft this platform to do the things that people really need, with a minimum of conceptual overhead...

  • 1
?

Log in

No account? Create an account