[Sugar-devel] [DESIGN] Re: [PATCH] Protected-Activities-Support.3
garycmartin at googlemail.com
Tue Sep 14 16:34:36 EDT 2010
On 6 Sep 2010, at 14:23, Tomeu Vizoso wrote:
> On Sat, Sep 4, 2010 at 22:18, Sascha Silbe
> <sascha-ml-reply-to-2010-3 at silbe.org> wrote:
>> Excerpts from Kandarp Kaushik's message of Sat Sep 04 21:41:10 +0200 2010:
>> Thanks for submitting the patch with git send-email, I could apply it
>> - test your patch before submitting it (there's a syntax error)
>> - provide a useful subject and description
>> - fix the white space errors (I recommend using
>> "git config --global color.diff auto" to enable diff coloring)
>> - adjust the _add_erase_option() docstring: only "user" activities
>> (i.e. those in ~/Activities) can be removed at all, so
>> "user or unprotected activities" doesn't make sense.
>> On the ticket  Gary suggested to deactivate (instead of remove) the
>> Erase option for protected activities (like we're already doing for
>> "system" activities). +1 from me, but maybe someone else from the design
>> team wants to chime in.
> Hi Design team,
> Any preference for disabling or removing options in palettes that are
> not activable in a specific moment?
I don't think there is a hard and fast rule we can simply generalise to, but I think consistency between menus is important. If you have N objects of the same type (e.g. activities) on screen at the same time with menus, they should contain the same items, with some disabled/ghosted out if needed. Removing the items in this case causes confusion, and can feel like a bug ("Hey, where is the 'Erase' option gone? It's there for all the others, must be a bug with the menu not redrawing correctly.").
Completely removing items/choices from a UI makes it less complex/clearer, especially if they are in prominent UI positions. A good example of where removing unavailable UI items is good, is in the frame's device border – showing lots of dimmed/inactive devices there would get messy real fast.
>>  https://bugs.sugarlabs.org/ticket/2087
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
More information about the Sugar-devel