On Wed, Oct 14, 2009 at 12:04 PM, Simon Schampijer <si...@schampijer.de> wrote: > On 10/13/2009 04:36 AM, Bernie Innocenti wrote: >> Hello, >> >> Michael just passed by the Acetarium and, since the dinner was late, we >> found the time to test and review his latest prototype^W patch. >> >> I'm loving how the menus suddenly are now snappy and responsive. Please, >> test it yourself and report back. If we like this change, I think we >> should go on and also kill the code that this patch makes redundant. >> (please, let's not add another configurable knob!) >> >>> From 83ef08969ed7bee08f90c12bfa1eedcb7fb0500c Mon Sep 17 00:00:00 2001 >> From: Michael Stone<mich...@laptop.org> >> Date: Mon, 14 Sep 2009 22:33:12 -0400 >> Subject: Make various palette animations happen more quickly. > > Can you describe what the patch will change from the user point of view? > Is this to get rid of the delayed build up of palettes when hovering > over icons? > > You can use right click to get the menu immediately. The delay is on > purpose.
We should definitely get feedback. I wouldn't be entirely opposed to a change, but I do want to make sure that we make such a change for the right reasons, and that it's actually the right change to make. The initial design intent was to develop a system which worked in a sufficiently complete manner without needing palettes at all. Kids should be able to start activities, resume activities, join activities, write, paint, stop, etc. without ever seeing a palette at all. [1] This is the "low floor". For kids with more experience or curiosity, we decided to provide contextual palettes which grouped related actions and provided more complex interactions with the system. This is "no ceiling". Furthermore, we wanted to help introduce kids to the availability of additional options in a discoverable way, which is why the hover effect was chosen to provide increasing levels of detail and interaction for a given object. Finding that many kids were actually waiting for the palette to appear always, instead of, for instance, simply clicking on an activity icon to join it, encouraged us to INcrease the delay on the palettes to help emphasize this as a secondary mechanism for interaction. A agree that hovering in one place to click in another isn't great; but that's also not the intended primary means of interaction, and should only really be done when one of the secondary actions is desired. Removing the delay pushes us, I fear, even farther away from an interface in which nice friendly large clickable icons can be directly manipulated and encourages every action to be done through a contextual menu with a bunch of text in it. Is that really what we want kids to face? Just for fun, I might suggest an alternate possibility which actually decreases the discoverability of the secondary palette. We could reveal the primary palette (label) on a delay as we do now, with some indication of "more options" that can be clicked to expand the menu to reveal the secondary items. This would provide the (essential) primary palette as a label and introduce kids to the existence of more controls without encouraging them to use this as a primary method of interaction. Advanced users, of course, could still right-click to invoke the full menu in one shot. Eben [1] Incidentally, one of my major complaints with the "resume by default" behavior is that it makes starting new activities hard to do, and virtually impossible to do without using a secondary action, which is the wrong approach in my mind. I think starting from home, with the option to resume, while encouraging one-click resume from the Journal is still the correct approach. I think offering the option to enter "resume by default" mode is great, but I'm not sure it should be, itself, the default for Home view. In practice, it seems it has worked too "well". It used to be that kids never resumed activities. Now, it seems, they never start new ones. The solution seems to be in encouraging use of the Journal and the Home view for these different default actions, and in clarifying the UI such that kids understand and desire to do so. Eben > Regards, > Simon > _______________________________________________ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel