Contour/Active global context menus

[Fania Jöck]

Hi All,
>> suggestions? comments?
> imho we should try and maintain precise clarity in each part of the UI. i see
> no reason to duplicate every possible action in every possible place. that
> will just lead to, as Sebastian already noted, clutter.
yes, duplicated actions shouldnt be used, the user can for example open 
a resource by a single touch instead of having that action in a context 
menu. No reason for duplicating learned interaction patterns.

But what I think would be really nice is to present actions that are 
specifically recommended for that resource: for example for a contact 
resource I get the 3 hottest actions, that are useful right now, as 
"call" because this person called me 2 times this morning, "send E-Mail" 
because I have regular Email communication with that contact and "start 
chat" because this person is online right now. This would be real added 
value for the user. And in my opinion these context menu should change 
dynamically, like the recommendations. Of course, some basic actions 
like "remove from activity" or "delete" might be always required and 
therefore should be listed always.

> i don't think that this feature needs to Do Everything(tm). in the scope of
> Plasma Active. it should probably allow the user to do one specific kind of
> thing.
>
> there isn't enough space, really, to offer a ton of options there and keep it
> easy to use on a touch screen.  there's also the issue of someone using the
> interface understanding why that exists and what it is for.
Yes, thats a very good point. In my last usability testings here the 
people didnt get where the recommendations came from. That might be 
solved, when the user interacts with the system and realizes the link 
between his last calls and the recommendation to add that called person 
to the activity... but this has to be find out with further UI design 
und testing.

> a question we need to step back and ask ourselves is this: "Do we want the
> connection of items to be something that one does while interacting directly
> with the object, or do we want these features to be a global function with a
> central location for interaction?"
>
> the context menu idea is the former, SLC is the latter. both have pros and
> cons.
>
> Context Menu
> 	Pros:
> 		It is right at the object itself; you don't have to change focus to act
> 		The object might be able to influence the menu contents more as it may
> have more internal knowledge about what it represents
>
> 	Cons:
> 		Discoverability is questionable
> 		It means having a "magic" interaction pattern to bring it up
Well, long touch on a object opens a context menu - is that really magic 
or is it already learned by mobile users?

> 		It will remain specific to components that implement/support this menu
>
> Global SLC-type approach
> 	Pros:
> 		Shows in tests to be discoverable and intuitive
> 		Can be applied to any application or source of data, not just Plasmoids
> 		By dividing the tasks up into 3 top level categories, each list can be
> longer
> 		Can be combined with complimentary functionality such as "live device
> pairing"
>
> 	Cons:
> 		You need to move from object to control
> 		Relies on a global UI being there; remove the SLC buttons and it's all
> gone
>
>
> it would be nice to add to the above list and figure out which directions we'd
> like to go based on that. it may also help define more clearly what the
> different pieces of UI we create are intended to do./mail.kde.org/mailman/listinfo/active
for me, the usecase of user behavior is the key to that. If we are 
working with our devices, we are currently searching the files we need, 
open them, work with them, create new ones and save them in a specific 
folder.
The user of Plasma Active/Contour would work in two ways, I suppose. The 
first one is within the activity: So he chooses the activity he needs 
and wants to extend it by creating new files and documents. Sometimes he 
might want to add new contacts to his current activity. He can either 
just use the "add resource" button of each box. Or he has a look in the 
recommendations overlay, if the system might already got the document, 
he is searching for (well, in an ideal world, where nepomuk gives us 
that information...) That would be more the "structured type of user". 
The other way would be the "Dynamic User": he just opens files, browses 
through different URLs and communication etc. In this flow he wants to 
add that current resource to an activity (doesnt have to be the current 
activity that is open in the background). So here I think some sort of 
SLC-Overlay/bar that is available in every resource I am just working 
with, would be the best solution. Just one touch on the "connect" 
button, choice of activity, and thats it.
So for me, both ways are correct and can adress both types of 
users/workflows.

So, these are my ideas, please give feedback if you think different or I 
missed some usecase etc...

Regards,
Fania