My question to you (developers & designers) about the context menu in Silverlight:
Is an application more user friendly, if there are no functions hidden in the context menu?
What do you think?
Note
To get a context menu before Silverlight 4 you had to set the Silverlight app to windowless and do some weird hacks (UGLY and performance issues!).
With Silverlight 4 we have a context menu out of the box (MSDN Silverlight Whitepaper).
NB (Nota bene, the italian note)
There is no out-of-the-box context menu on the iPad.
I really like the UX of the iPad, but there are some inconsistencies left. Read more here from these usability experts (german article)
7 comments:
My first reply would be, I think it needs to complement the app. So instead of giving a new functionality that needs to be "discovered", I would like the context menu to satisfy either "the obvious" like Save, Copy, Paste etc; or duplicate commands that are already in the toolbar etc. for versatility.
But these are true for a product. if you are developing an app for a client, I believe it comes down to what the customer wants. If they are used to having everything in a context menu and that's what they want, then by all means, I will give it to them.
So I guess, to answer your question it "depends".
By the way, here is the link for Google translator for the German article:
http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-8&layout=1&eotf=1&u=http://www.usability.ch/Alertbox/20100510.htm&sl=auto&tl=en
TJ
>>"the obvious" like Save
Is Save something that you would put in a context menu???
>>duplicate commands
Why would you *duplicate* commands from a toolbar?
Just because MS is doing that?
MS developers tend to think: the latest MS product is our UX guideline ;-)
>> used to having everything in a context menu
mhmm... just because it was "bad" before, should we make the new app "bad" as well? We don't want to reproduce a new system with the same UI in a new technology, do we?
>>that's what they want
Agree. If client wants it that way, we do it.
Peter,
>>"the obvious" like Save
Is Save something that you would put in a context menu???
==> For grid, it may make sense. For me, context menus are most helpful on individual rows on a grid. So, having a Save this record on the row's context menu makes sense to me.
>>duplicate commands
Why would you *duplicate* commands from a toolbar?
Just because MS is doing that?
MS developers tend to think: the latest MS product is our UX guideline ;-)
==> No, of course not. But going back to the grid example, this "duplication" makes sense. Otherwise, unless it makes a good case, I do not like commands being hidden in the context menu (again unless the customer is used to this and wants this functionality).
I am trying to get away from "training" sessions for the applications I build, so having lots of hidden context menus definitely requires "training".
>> used to having everything in a context menu
mhmm... just because it was "bad" before, should we make the new app "bad" as well? We don't want to reproduce a new system with the same UI in a new technology, do we?
==> Unless you can convince your customer, then the answer to that is yes. You are free to go whichever way you want in a product, however for something that the customer wants, they are the ultimate winners. Even if you do not agree the UI they want, if you can not convince them or they are insisting that this is the way they want, I do not see an easy way out :-)
Customers generally really do not care avout the new technology that much - it is the "value" that new technology adds to their business. And people's behavior's are so hard to change. So, I find that, there is always a bit of the new along with the old. Just Google on MS Ribbon, and you will see how many people want the old menus back.
Anyway, I am now in the school of, everything should be visible to the customer. If you fnd yourself putting too many commands in context menus then may be the screen is too complex and/or it's time to re-think the GUI. I also found that the simpeler screens actually reduce the number of support calls.
==> having a Save this record on the row's context menu makes sense to me.
-> I never saw a UI that had that. And I think its not the users intent to save single rows.
BTW: I am not a fan of datagrid UI's at all
==> No, of course not. But going back to the grid example, this "duplication" makes sense.
-> So you have a "Save All" button and a "Save Row" button in the toolbar? Mhmm... Don't like that...
.......
I agree with all the rest: Keep it simple stupid and Make it intuitive to use.
==> having a Save this record on the row's context menu makes sense to me.
-> I never saw a UI that had that. And I think its not the users intent to save single rows.
BTW: I am not a fan of datagrid UI's at all
==>> Well, we are talking hypothetically because users generally prefer keyboard shortcuts to context menus for simple operations like save, delete etc anyway. At least in my case. And some of the users do want to save even at a single cell level :)
==> No, of course not. But going back to the grid example, this "duplication" makes sense.
-> So you have a "Save All" button and a "Save Row" button in the toolbar? Mhmm... Don't like that...
==>> No, I do not have Save All or Save Row context menus :-) However, I did have on couple of occasions, "Duplicate COntract", "Copy Contract", "Move Contract" kind of context menu commands, and while I had the same commands on the toolbar as well, the customer specifically asked for a row level context menu. So, it does happen.
May be we started with the wrong examples. Save, Delete etc may not make much sense in a context menu (or they may in some scenarios?), but it does make sense in terms of "helper" (as in business process not coding) methods if the customer requests it and I can see their point. "Move Contract", "Do xyz on this Contract" kind of actions may be required by the customer on a context menu.
Let me give an example though: Type associations in your search box. On the screen you are presented in Windows 7, you can change the default file associations here. The file extensions are presented in a gridview or listview fashion. Once you click on an extension, the Change Program... button is at the top. To me this is disconnected. Believe it or not, I actually did not see this button at first as I was selecting the extension and right clicking on it thinking that I will be presented with some options. When nothing happened, i searched the rest of the UI.
So, in this case, have your button at the top (but preferably on the left not the right as most people do not look at the farthest corner of the screen) by all means, but putting a context menu command per row seems like a good idea to me.
I am sorry if I am all over the place as I am writing this in between coding during coffee break :) But if you want we can further discuss this over a beer, however I believe we are on the same page. Still beer sounds like a good idea to me :-)
>> I am not a fan of datagrid UI's at all
I think we are on the same page ;-)
>> beer sounds like a good idea to me
I hope I see you at the UG next Wed..
>> Windows 7 default file associations
This is a weird UI ;-)
What do you think of Inductive User interfaces?
Good for beginners? Too easy for powerusers? ...
CU
Inductive User interfaces : This is a bit bigger topic then we can discuss in few sentences. Let's do this after the UG but I think it is a step in the right direction.
Of course, the ultimate challenge is, a UI that is easy for the first time user, but then powerful enough for a power user (and this could be where the keyboard shortcuts, and may be an integrated app language (like querying) comes into the picture.
Wow, It could take us while :-)
Post a Comment