| Hi Priscilla,
I think there are maybe some subtle semantic mis-matches, because in principle I don't think there's disagreement. I agree the eye, along with other icon treatment should be tested to see which one works. In fact we can ship 0.7 with multiple versions of the icon.
See more in-line. On Feb 27, 2006, at 8:23 AM, Priscilla Chung wrote: Mimi,
So correct me if I'm wrong, but here are two things the check box is doing in Chandler:
1. Acting as an icon "handle" for a collection (for deletion etc..).
I think this is the crux of the semantic mis-match. The entire collection row acts as the selection handle. This is one important difference between desktop and web applications. On the web, text is never selected (ie. An email in a webmail UI). Instead a widget (usually a checkbox) is used to allow the user to select the item in order to perform actions such as delete or edit. (And when that happens, it's always permanent selection, not temporary selection. The user has to click the checkbox again in order to de-select the item.)
In desktop GUIs however, row items can be selected and as a result, the icon (if there is one) is used primarily as a means of communicating information about the row item (ie. this is a folder, this is a playlist, this is a trash can). 2. Showing if the collection is permanently selected.
Yes, the collection icon is the user's primary means for 1) permanently selecting a collection; and 2) seeing if it's been permanently selected.
Here's is the reason why I think there is currently a behavior problem (which you probably already know):
In Chandler the circle is acting as an icon and a check box. Not only are you selecting it, but you are making it permanently viewed. Selecting the circle and selecting the name do different things and that may not be the user's intentions.
Yes agreed. In 0.6 we agreed that following the iCal model would be 1 viable alternative. In the Calendar App, selecting a collection in the sidebar "makes the collection stick". In the other app areas, selection doesn't stick, you're always switching between collections.
But the ideal would be if we could find a simple way to accommodate both behaviors so the user could choose whether they wanted overlays or to switch views on a case-by-case basis. This is primarily because there isn't necessarily a 1:1 mapping between the Calendar App area and the desire for overlay behavior.
If we take a look at the use cases there are 2 clear reasons for clicking on the sidebar collections: 1. You want to change your view (ie. First I look at my Project: Foo tasks and then I want to look at Houshold tasks) 2. You want to combine your views (ie. I want to overlay the Project Foo calendar with Amy's calendar.)
So we had two conflicting use cases that called for 2 different sets of behavior. We could either decide for the user what they want. Or we could give the user 2 different affordances, one for each behavior. You're right, most users will not expect this kind of behavior. It's a new kind of widget. But the motivation for it is to avoid dictating user intent when there is no clear rule the app can follow to reliably predict user intent.
Conventionally an icon before the "name of the collection" is the selector or the 'handle' for that item, ie. a folder icon in a file manager, a folder icon in an e-mail application, a photo icon and the name of the person in an instant messenger application.
-Priscilla
See additional comments in-line…
Mimi Yin wrote: Hi Priscilla,
See comments in-line...
On Feb 21, 2006, at 10:50 AM, Mimi Yin wrote:
Priscilla: Yes absolutely. Could you elaborate on the specific steps you took to try and delete the collection? This is a really interesting scenario.
<mime-attachment.png> So when I click on a collection or two (see visual attached). The first this I want to do is right click to delete. Currently it does not do that in Chandler 0.6.1.So then I go under the edit menu and the 'delete' is grey-ed out.
Then I only select one collection, go under the edit menu and see 'delete collection'.
Yes, it sounds like you probably wouldn't have gotten all the way to the point where you associated "check selection" with "delete collection" if 1) there was a context menu and 2) the menu items refreshed quickly enough to allow you to delete the selected collection (without checking it).
Checkboxes or check circles, especially on the web say "selection", they also say "approved" and "finished." Maybe there is a better symbol for "always visible".
Here again, I think we may be interpreting checkbox slightly different. Checkbox generally means: "always selected...please click me again to de-select me"...which is different from selecting a row item of text, which means "temporarily selected...if you click somewhere else, this selection will go away".
In desktop GUIs, both kinds of selection exist. On the web, only the former exists (permanent selection), because there is no notion of "temporary" mouse selection.
In the end, I think the biggest problem users have with understanding selection versus permanent selection is not so much the icon, but the lack of "feedback" described further down.
Heh, I tried the eye as well, and I gave up because I couldn't get it to look right (as in same illustration style as the collection icons - they all looked like Lisa Simpson), but that's not a good reason to not use the concept! It's just hard. ;o)
I also tried using a thumb-tack. It might communicate "stuckness" or "persistent selection" even better than an eye? In reality, selecting a collection is "viewing it". "Checking it off" is "viewing it forever"...or at least until you decide to "uncheck" it again.
Yup. coming up with visually appealing icons is a full time job in itself. I can help to re-explore and draw up some icons with you....and hopefully in time find some contributors who are interested in coming up with visually appealing icon set that makes sense??? ; )
Huh, that's a good idea. But might feel weird in more complicated scenarios. (ie. I have 1 collection "checked off", and 1 collection NOT "checked off", but selected.)
Think of how you use the palettes in photoshop. Something can be visible, not visible, but still selected? Well in any case, this might be something to put in-front of users to see how complicated it is to understand. (Visual: I can still select even though it's unchecked, is this not the same 'weird' behavior you're talking about?)
-Priscilla
I think the difference here is that in Photoshop, when you "select" a layer, the layer doesn't appear. In Chandler, if you select a collection, the collection appears. In Chandler, clicking on the collection icon makes the selection stick OR makes its appearance persistent. Which means, you have to click the collection icon again in order to make it disappear. As in, the collection won't disappear if you just select a different collection. The usual icon for this kind of behavior is usually a checkbox.
Yes but you have two toggled states: selection and visibility. I just don't think checkboxes are not well setup to handle it. In Photoshop it displays two (or used be three) icons. One for viewing, one that used to be the 'link' for linking layers and one that is the photo/icon of the image on the canvas. There is a discrete column for each function. In a two "icon" situation, nothing prevents us from forcing a "temporary" view (gray eye) as opposed to a permanent view ("black eye"...no pun intended) upon selection of the handle.
I'm proposing that as a first test, we test an out of the box configuration that shows 2 checked collections and 1 un-checked collection (with no tweaks to the visuals)...I have a feeling that regardless of what icon we have, it will be hard for users to understand the difference between "selection" and "stuck selection", if they're only playing around with a single collection that has items.
I guess this is a really long-winded way of saying that before we spend more time on refining the icon, I'd like to do a controlled experiment to see if having multiple collections is a key factor in understanding the distinction between "selected collection" and "checked collection".
Okay, its good to test. Maybe it would be good to test both versions at some point: separate icons and single icons.
Yes, I think we should test all the options. But in the interest of time and limited resources, we're going to test a few options that don't require any change in code.
It seems like at least some people are able to see the rollover effect and try clicking on it as a result. The problem seems to arise when "nothing new" happens as a result of checking the collection, thereby breaking the all-important cause-and-effect feedback loop that is crucial to the process of building a coherent end-user mental model of an app's "laws of physics", so-to-speak.
Its just very,very subtle, and we maybe there needs to be something more obvious.
In the scenario I'm describing, nothing happens. If you have 1 collection selected and you "check it" literally nothing happens.
===
However, the weirdness I was referring to has to do with using the checkboxes to multi-select collections and then "delete" them all in one stroke. It may be strange to have 1 collection selected, and then end up deleting 3 collections because 2 other collections were checked.
Automatically 'selecting' all checked collections would mean finding another way to visually distinguish between the 'selected' collection (ie. the calendar that's on top) versus simply 'activated or checked collections'.
Mimi :o)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
|
