Op vr, 05-05-2006 te 21:34 +0200, schreef Karel Demeyer: > Op vr, 05-05-2006 te 14:55 -0400, schreef Youness Alaoui: > > On Fri, 05 May 2006 14:26:26 -0400, Karel Demeyer <[EMAIL PROTECTED]> > > wrote: > > > > > Please comment on this. I was assited by 2 Gnome Usability guys for > > > this. About the contactlist-right-click menu I have to ask some more > > > advice fomr 'm. But we have to make sure what we want. When a user is > > > not online and we double-click, and we want it to open a SMS for mobile > > > users, we should have "send an SMS" as first item and have thus the > > > action on doubleclick and also the first group of actions in that menu > > > depend on this. If you gray out the first item and do it also for > > > others, it means you don't have any double-click action defined. > > > > > cool, but I still beleive the popup menu should be the same for every user > > with items greyed out and "first non-greyed out action == double-click" > > > I asked for advice on this one but didn't get reply yet. I'll keep you > informed. The Gnome HIG states the first thing in a contextual menu > should be: > "the double-click action for object, when it exists" So for mobile > users this should be the "send sms" entry. But I know invariance in UI > is very important as it makes it easier to find stuff; As in: > "Do not remove command items from the menu when they are unavailable, > make them insensitive instead. This allows the user to infer what > functionality the application provides even if it is not currently > available, and keeping the menu structure static makes it easier to > memorize." -- about 'Command items' (the only kind of items we have in > this menu) in general though the examples are all for drop-down menus > (in the menubar). > > Anyway, I'm gonna contact both gnome usability ppl as openusability ppl > (hey have a IRC channel ;)) to get some advice on this. I think both > guidelines are kind of important, so I'll try to know what it should be > according to Gnome HIG ppl as there is the controversy to be foudn and > then see what openusability ppl have to say too :) > > > A cool fait-divers; a lot of even-computer-literate users don't know > about contextual menus or "right click". > Apple IG: > "A contextual menu is hidden by default and a user might not know it > exists, so it should never be the only way to access a command. In > particular, you should not use a contextual menu as the only way to > access an advanced or power-user feature." > Gnome HIG: > "Be aware that popup menus are used primarily by intermediate and > advanced users. Even some users who have used graphical desktops for > many years do not know about popup menus until somebody shows them." > > > > > > > > > > > > > Under here the mainwin-proposal, > > > > > > Karel. > > > > > > > > > > > > > > > These are not anymore in this menus-proposal: > > > > > > [OFF] amsn versioncontrol -> in about window > > > This was removes because it's not very much used anyway and only > > > populates > > > screen real-estate. whe a user checks the version he/she has in the > > > about > > > window, he/she should be able to check for the latest release in there > > > too. > > > > > > [OFF] minimise instead of close -> in preferences > > > This is something only set once. From usability point of view it's > > > even > > > wrong to minimise a window (to the tray) when the close button is used > > > as > > > this should do the same as the "close" entry in the main menu. Though, > > > this is an often requested feature, so it should be kept, and it's > > > place > > > is in the preferences window. > > > > > > > here's an example of a non respected thing from the guideline.. congrats > > for your open mind ;) :p > > > > > [OFF] Change language -> in preferences > > > This is a preference mostly only set once and thus belongs in the > > > preferences screen. > > > [OFF] Change skin -> appearances in prefs > > > Idem dito. > > > > > > > > > > all seem to be well justified, 100% agree > > > > > > I s > > > > > > > > > > > > This is hte proposal: > > > > > > ===Account=== > > > Log in as ... > > > Log in > > > Log out > > > --- > > > Change Nickname ... > > > My Status > > > > --- > > > Go to Inbox > > > My profile > > > --- > > > view received files > > > show events history > > > --- > > > Enable sounds > > > Plugins > > > Prefs > > > --- > > > Close > > > > > > > > > ===View=== > > > Sort contacts by status > > > Sort contacts by group > > > * Sort contacts in hybrid mode > > > --- > > > * Show contact with nickname > > > Show contact with email > > > --- > > > Change global nickname ... > > > --- > > > * Sort groups ascending > > > Sort groups descending > > > > > > > > > > > > ===Actions=== > > > send a message > > > send sms > > > send email > > > --- > > > send file or foto > > > send webcam > > > ask to see webcam > > > > > > > > > (Wanted to merge this with "Contacts" but it would make the menu > > > too crowded andalso plugins should still be able to add stuff here) > > > > > > > > > > > > ===Contacts=== > > > add a contact ... > > > remove a contact ... > > > Contact properties > > > --- > > > New group > > > Rename group > > > Remove group > > > --- > > > view chat history > > > view webcam sessions > > > --- > > > save contactlist > > > load saved contactlist > > > > > > > > > > > > ===Help=== > > > contents > > > --- > > > FAQ > > > online help > > > --- > > > about aMSN > > > > > > > > > > > I pressed "Send" too quickly :) I read this first before replying on the comments above though.
> > I 99% agree, you really did a great job on this! kudos > > my few comments : why enable sound in account menu ? yes it is account > > option, but I don't see it in there.. For that reason and because creating yet another menu would be overkill. I guess you want more stuff in this menu ... > > I would also think that an "Options" or "Tools" menu would be usefull > > (enable sound in there as well as access to prefs window + any often > > modified preferences) wat often modified preferences ? My first draft added "dp in cl" in the view menu but one pf the usability ppl said "it's crack" and indeed, it is. You don't change it that often. In finitis you could add the "where is the psm showed" stuffin the view menu .. but again that's not for tools, and you don't want to change that alot ;). What rests ? I don't have an idea what prefs you'd want to see in a menu. The sound one is the only one I could think of as it's something you might change a lot, like changing your status. We could have a cool plugin that for example sets sounds muted dpending on the state btw ;) > > Also, optional, but what do you think of (as a new feature) a "Windows" > > menu ? with the list of all opened windows/contains.. might be usefull.. > > since it needs new code, maybe if it's accepted, do the design and keep it > > in the wiki until we implement the code for it. I don't think this would enhance usability. A "Windows" menu is found in MDI's (multiple document interfaces), this type of programs is not very liked by usability crowd ( "The use of MDI is discouraged, as they have a number of inherent usability problems" ). You coujld say aMSN is kind of a MDI prog as we 'work' on multiple chats. But, there's no such an art of adding menu-titles. We already have 5 now with my proposal, you propose 2 more. Maybe we do have to add 'm, but I think we better don't. In fact allmost all modern desktops have a "windows listing" somewhere in a panel, also called the "taskbar" in windows. Most modrn windowmanagers support grouping of all windows of 1 application. In other words, 99% of our users will already have this functionality on their desktop! It's like hte same reason why a clock on, a website is crack ;). Those 1% are likely geeks and if they want it they can add it to powertools ;) > > > > you also pointed out something interesting when talking about some stuff > > that needs to be moved to prefs window.. how about a redesign of the prefs > > window :p yes, it WILL be redesigned.. but in time only.. also, we'd need > > someone to take it where Alvaro left on the new prefs window, I think he > > has the API finished, but only needs to code the items to apepar in the > > prefs window.. > > post-0.96 I'm wanting to do a design of a clean preferences window, but beware, this will mean a lot of preferences would be added to this window byb a plugin so it's not in the way of "normal"' users. > > > > > > > > -- > > KaKaRoTo > > > > > > ------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job > > easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > Amsn-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/amsn-devel > > > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Amsn-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/amsn-devel > ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Amsn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amsn-devel
