Re: [Usability] Mac-style menubar in GNOME
Joachim Noreiko wrote: As the Mac-style menubar is likely to take some time, it might be a good idea to look at renaming the Menu Bar in the interim (or in fact, just *naming* it). System menu is what comes to my mind. I think those terms are used by other OSes (since it sounds familiar to me) but I don't know which. I've ever actually *used* that menu, except to get to the hopefully-soon-obsolete Search for Files). Yes, there is an ugly inconsistency between that and Nautilus's built-in search. (I do actually use that menu to open nautilus folders quickly. But having to click on a bit of desktop first to make it available is hardly a great cost.) I use the places menu *all the time*. Actually I wouldn't mind if there was an applet providing only the places menu ;-) This is especially useful for people that don't display mounts and remote places on the desktop. ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Quicky review of Seahorse encryption key manager (fwd)
-- Forwarded message -- Date: Sat, 16 Sep 2006 13:14:30 +0100 (BST) From: Alan Horkan [EMAIL PROTECTED] Cc: Usability gnome conference usability@gnome.org Subject: Re: [Usability] Quicky review of Seahorse encryption key manager On Sat, 16 Sep 2006, Matthew Paul Thomas wrote: Alan Horkan wrote: ... The first dialog includes the following labels on the Tabs: My Personal Keys Keys I trust Keys I've Collected ... More appropriate labels would be: Personal Keys Trusted Keys Collected Keys. I've changed all but the first tab label. As Murray pointed out Personal Keys is ambiguous. I'm all out of ideas on this one, ie: How to remove the 'my' but still convey: * They're keys I've created. My very own keys. Only for me. * These aren't the keys of people I feel 'personal' about. The concepts behind encryption (and PGP in particular) are so confusing for people than being unambiguous is necessary in the labels. I think this is the right approach. I'd go so far as to say that Keys You Trust is better than Trusted Keys, and Keys You've Collected better than Collected Keys, because they answer the vital question: By whom? (And yes, I would say You've rather than You Have. Contractions aren't excessively informal, and allowing space for longer translations shouldn't be used as an excuse to make the English unnecessarily long.) We can make excuses all day long but it sends mixed messages to use abbrevations sometimes and then try to explain later not to use exceptions. A clear consistent rule not to use abbreviations is less confusing than saying it is sometimes okay. Non-native English speakers often find themselves using the English translation so clarity should be maximized. This is a largely cosmetic change, and there may well be a better way to fundamentally reorganise things and change how they are presented. If the English labels are unnecessarily long they would need to be reworded, abbreviations have nothing to do with it so to characterise the issue as an excuse to make the English unnecessarily long is wrong and an entirely misleading attempt to reframe the arguement. It took Microsoft a decade to drop their overuse of the My prefix and we should know better than to take their Vista guidelines at face value. Sincerely Alan Horkan Inkscape http://inkscape.org Abiword http://www.abisource.com Open Clip Art http://OpenClipArt.org ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Dialogs and Maximize button
Am Sonntag, den 10.09.2006, 17:21 +1200 schrieb Matthew Paul Thomas: Some of the content useful for more advanced users it outside the default visible area, and can be scrolled to. I don't think I've ever seen a window like that. Can you give an example? The synaptic download window and all of its error dialogs, which also display the terminal output of apt. Resizing the window to make this content viewable makes the dialog much more useful for those users. In reality, there should be absolutely NO windows on the desktop, which cannot be resized. ... Dialogs that only contain some text look quite ugly if you start to resize them. So why should ALL dialogs be resizable? Cheers, Sebastian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
[Usability] Finish - Close
Hi, I would like to put a quite old issue back on the agenda: The background properties capplet uses a 'finish' button, but all other capplets (still) use 'close' buttons. Rodney, in a short comment you said that the wording change was based on your test at Novell. Could you please elaborate this? If finish would be used for all instant apply dialogs, what would be the impacts for explicit apply? This could also be a good chance to get rid of the ok: [Apply] [Cancel] [Finish] In the short term I would like to see that background properties also uses close. Thanks, Sebastian Related bugs and discussions: http://bugzilla.gnome.org/show_bug.cgi?id=334947 http://bugzilla.gnome.org/show_bug.cgi?id=327335 http://mail.gnome.org/archives/desktop-devel-list/2006-January/msg00479.html signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
