First impressions on this: - having a 2 level UI is probably the best solution to fill all needs - what about selecting a category ? items will be still OR'ed, whatever the scheme, or... ? I mean, choosing Pets AND Favorites needs to be (internally) translated to (Dogs OR Cats) AND Favorites - what about the NOT operator ? After trying to find a real use case to describe the needs, I don't think we need it in the general UI. idem for the XOR (but both could be very useful in the advanced UI. don't forget about it) - about the tray. If I understand well, that's a way of storing query and OR'ing them ? Do you have any sketch (even scanned from paper) of this ?
Stephane On Tue, 2006-08-15 at 19:38 +0200, Ben Monnahan wrote: > Hi all, we were discussing the UI for the query code at the meeting > and I said I would formulate my idea in an email. > > My proposal is for a UI that covers 2 use cases. (1) Casual use, by a > user regardless of their technically proficiency, and (2) Serious use > by a technical user. My guess (not backed up by data :)) is that the > large majority of the use falls into (1), but that providing (2) would > be a big benifit to those who need it. > > > USE CASE (1): We would have a simple toggle between AND and OR for > the tags. Checkboxes stay the same as now and the query happens > depending on how the toggle is set . For the toggle, my current idea > would be a dropdown just above the list of tags containing "Require > all tags" and "Require any of the tags" but it could be done many > ways. (Another check box, put it in the menus) > > This allows for queries such as: > (A) (Dog OR Cat) > (B) (Vacation AND Frank AND Injury AND Water) > > But doesn't allow for: > (C) ((Dog OR Cat) AND Favorite) > (D) ((Paris OR (France AND Monument)) AND (2003 OR 2004)) > > As a side suggestion I would like to add a "tray" (suggested by > someone else elsewhere) which would allow you to construct a working > set of photos. Having that would make (C) possible although you would > have to reformulate it as ((Dog AND Favorite) OR (Cat AND Favorite)) > Query (D) is still difficult athough not impossible. > > The benifits of this approach is that it should be fairly > discoverable, and apparent to all levels of users how it works. With > the added power of the tray fairly complex queries could be generated > in step by step manner. > > > USE CASE (2): I would have a separate dialog available from a menu > that allows a much more powerful interface similar to an advanced > search you would find on the web. I can't say I have a very good idea > of how exactly this would work, but the idea would be to provide the > user with a lot of controls to make queries like (D) possible and > maybe even (C) if the user is more comfortable with doing it that > way. > > > Summary: Its a two pronged approach on simple way of just letting the > user choose between ORing and ANDing, and a dialog for those who need > advanced searching. My guess is that for the majority of users the > simple approach will be enough, so I think its worth the effort to > optimize for the common case and give them the best possible > experience while not removing the possibility of more intricate > queries that the dialog would provide. An additional benefit of the > dual approach is that the simple query could probably go in without > too much effort while the more complex system was being developed. > > > Comments/Questions/Other proposal? > > Ben > _______________________________________________ > F-spot-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/f-spot-list -- Stephane Delcroix [EMAIL PROTECTED] _______________________________________________ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
