Re: Query Branch: UI Proposal

[Stephane Delcroix <stephane delcroix org>]

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
> F-spot-list gnome org
> http://mail.gnome.org/mailman/listinfo/f-spot-list
-- 
Stephane Delcroix
stephane delcroix org