Matthew, Thanks for the feedback. The mockup that I did had exactly the same intent as what you guys did in the javascript prototypes. You addressed the concept of the "current" collection combined with the idea of "overlays" or multiple selections in an excellent way. That is *exactly* what I think you should do. I do not think you should force the user to decide what collection to put something in by asking her to select for every new item. Your design has the concept of currency and I think it will work fine, although you might consider some minor animation of the collection name or some other queue to indicate that that is where the new item is going.
The subtleties of whether there is an eye or a checkbox are very minimal indeed in the face of a fundamental break in the ability to understand the data model. In other words, any of these is fine, but I strongly suggest you do one of them. They are all reasonable and will be generally well understood. Since you guys already have some excellent mockups of how to solve these problems, perhaps the only value I can add is in suggesting that for 1.0, this is an item that should be fixed. Your #1 challenge will be ease of adoption, and these data model visualization issues are critical. Hank On Dec 10, 2007 4:43 PM, Matthew Eernisse <[EMAIL PROTECTED]> wrote: > Hank, > > I think your points about the need for improved simplicity and usability > in the Chandler UIs are in general very good ones. > > We did a bunch of work on the collection selector and overlays during > the FLOSS Usability Sprint last month, and some very similar > points/questions came up. > > Unfortunately Jeffrey's original post to the mailing list seems to have > been chewed up, but here's the wiki page we put together as a report: > > http://chandlerproject.org/Notes/FlossSprint2007 > > Mimi's initial response to the enormous pile of feedback is here: > > http://lists.osafoundation.org/pipermail/design/2007-November/007887.html > > hank williams wrote: > > By the way, overlay is another one of those words that is not > > necessary. All you are doing is selecting calendars. google calendars > > doesnt need fancy jargon to describe this feature. > > > > Google Calendar came up in comparisons a lot, and I agree they've done a > good job of making things very simple. > > One thing they've done is taken away the concept of a "selected" or > "active" calendar. There is only "shown" and "not shown" (the same as > our "overlay"). > > Since there's no "active calendar," when you create a new calendar > event, you have to pick *at that point* which calendar you want to put > it in. Google does a good job of guessing which one, so it's not usually > that annoying, but it's not necessarily automatic. > > Imagine a user has three calendars showing -- Home, Work, and Office. > When she creates a new event, what calendar does it go into? Chandler > has a "selected" ("active") collection, so it goes into that one. In > Google calendar, you have to make a choice on the individual event > itself when creating it. > > So, while the word "overlay" itself may be kind of jargony (we could > just say "shown" and "not shown"), it's not the same thing as "selected" > (at least in our current design). > > One improvement over the current confusing state might actually be to > take the Google approach of pushing the question off until the point of > creating a new calendar event. It's definitely worth considering. > > The other strategy suggested by some of the user-experience > professionals at the Sprint was to call out the selected collection in > some way, so users know (1) there is an "active" collection where newly > created items will go, and (2), which one it is. Consensus was for a > nice, obvious label saying "Active Collection: Blah-Blah Collection." > > We have a couple of bugs open for this: > > https://bugzilla.osafoundation.org/show_bug.cgi?id=11355 > https://bugzilla.osafoundation.org/show_bug.cgi?id=11354 > > Part of the confusion in the Web UI also revolves around the use of > checkboxes to indicate the show/not-show state. > > Checking a box seems to indicate in a lot of people's minds "selecting > something," so at least one of the users in our tests thought that a > checked collection was a selected one. We have made the selection-state > more obvious in the Web UI, and I think it does improve the situation, > but there is definitely more we can do. > > I believe the custom widget set used in the Desktop is aimed at fixing > this same problem. I personally find it more confusing to use, and think > that the checkbox on/off state is at least more visually obvious despite > its associations with selectedness. > > During the Sprint, we did a couple of prototypes trying to make things > clearer: > > http://www.fleegix.org/demo/floss_usability_2007/proto_1.html > http://www.fleegix.org/demo/floss_usability_2007/proto_2.html > > The second one uses an eyeball to indicate shown status. It's a usage > common in graphics programs where multiple layers can be shown/hidden, > but only one can be selected. > > I hope all this info is useful -- the overlay/selection problem may not > be quite as simple as it seems at first blush. I don't think we have > anything close to the optimal design, but it is something we're working on. > > > Matthew > > > > > > > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > Open Source Applications Foundation "Design" mailing list > http://lists.osafoundation.org/mailman/listinfo/design > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
