Re: [Usability] useless message threading in Evolution
Recent versions of evolution sort threads by the most recent reply. The date for the toplevel message in a thread, is shown with the date of the latest reply as well, in the event the thread is collapsed. I don't know about Received Date, but sorting by Date works fine for me. The feature probably isn't bug free, either, though. -- dobey On Tue, 2007-02-27 at 17:47 -0600, Matthew Nuzum wrote: I hope I'm not tiring people with my bug reports... please understand my goal is to make systems better and to boost productivity. Many cool e-mail programs have a threading feature that groups related messages in chronological order. This makes it easy to see messages in context. Evolution has this feature, but as far as I can tell, it is crippled severely because of the inability to sort message threads in a useful way. For example, if someone sends you a message, and you reply, then a week later this person replies back, logically, the two messages they sent are grouped together. Unfortunately, if you've received 200 messages since then, you will have to scroll down past those 200 messages to see the reply. This is because when you sort your threaded display by received date (desc) the received date of the *oldest* message in the thread is used, not the newest. To illustrate this better, I have a folder called bugs and filters to put all my bug related e-mails there automatically. There are over 1700 e-mails in this folder. Some time ago, I got subscribed to a bug about pango. I get a couple messages from this thread a month it seems. When I get a new message, I have to scroll past 1500 or so e-mails to find the new one. The list is so long, that I scroll relatively fast. However, scrolling fast makes it incredibly easy to miss the unread message. That's an exaggerated (but true) example, however this characteristic of evolution hampers my e-mail reading every day. I would love to see sorting of threads use the received date of the newest msg in the thread rather than the oldest. This is how every other MTA I have used displays messages. Anyone willing to triage this and add comments? http://bugzilla.gnome.org/show_bug.cgi?id=412845 ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Three dialog problems
On Tue, 2007-02-20 at 21:48 +0100, Thorsten Wilms wrote: For some reason the Apple guys seem to see no problem in relying on drag and drop. Apple's target audience isn't Windows users. It's Mac users. Sure, they've gotten a few Windows users to switch over. One thing that has come up in usability testing in the Novell Cambridge, MA office, is that the end users who we ended up testing that were Mac users, did Drag Drop, while those that were Windows users, did Right Click. Both of them are originally designed to be advanced user actions, to speed up the flow of interaction. However, given that almost all users do them now, trying to call them advanced, and pushing to avoid them, is probably not the best interest to have. Why isn't there a check box outside the right-click menu to show hidden files? :) I think perhaps a different UI entirely for the save/open dialogs is the best solution, but we are stuck with what we have for now. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Three dialog problems
On Tue, 2007-02-20 at 19:01 -0300, Mariano Suárez-Alvarez wrote: On Tue, 2007-02-20 at 16:36 -0500, Rodney Dawes wrote: On Tue, 2007-02-20 at 21:48 +0100, Thorsten Wilms wrote: For some reason the Apple guys seem to see no problem in relying on drag and drop. Apple's target audience isn't Windows users. It's Mac users. Sure, they've gotten a few Windows users to switch over. One thing that has come up in usability testing in the Novell Cambridge, MA office, is that the end users who we ended up testing that were Mac users, did Drag Drop, while those that were Windows users, did Right Click. Both of them are originally designed to be advanced user actions, to speed up the flow of interaction. However, given that almost all users do them now, trying to call them advanced, and pushing to avoid them, is probably not the best interest to have. Why isn't there a check box outside the right-click menu to show hidden files? :) Because for the immense majority of users, for the most of their time, they do not need to see those files not hopefully know they exist? It was a rhetorical question. :) I think perhaps a different UI entirely for the save/open dialogs is the best solution, but we are stuck with what we have for now. Nothing that vaporous can be a solution ;-) Vaporous? ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] The Pathetic State of the GNU/Linux Desktop
On Mon, 2007-02-19 at 05:55 -0500, Jacob Beauregard wrote: P.S. And now I will mention that this entire letter is stream of consciousness, so good luck reading it. Yeah, the way to go to show good manners and respect for your readers. Like, do you really want to communicate something else except some vague frustration? Wow, this response is the least constructive I've received. A lot of the KDE people have been focused on many of the problems I've mentioned here for quite some time. If you want constructive responses, you should learn to word your complaints constructively. Pretty much every electronics device sold within the last 6-10 years or so, in the US, comes with a warning label: Do not dispose of in fire. If you don't want flames, don't throw a bunch of toxic batteries into the fire. It will most definitely incite responses of a common nature. Telling people that their work sucks, and they don't know how to write code for blind people, is only going to cause responses of a similar nature. Not that the response in question, to your original mail, is particularly negative, or not constructive, but your response definitely is. It in fact tells me that your entire goal here, is to try and start a flame war, by praising KDE, and dousing GNOME, on a GNOME list. -- As for your original mail, the accessibility support in GNOME for the most part, meets or exceeds that of Windows, as well as standards set by the US Government. Also, much of the code relating to accessibility, was written by at least one person who is in fact, blind. That said, those who are blind, are not the only target of the accessibility framework. What about users who are deaf? Illiterate? Paralyzed or who are amputees? What about users who simply have age-related sight and hearing problems, where they can still see and hear, but not as good as they could in their youth? What about users with disabilities in other countries, who don't speak English or use a Latin character set? The overbearing goal of GNOME is to be as easy to use, for as many persons as possible. Just making something better for one blind person, may make things worse for other blind users, or normal users, or many other types of users. All of these user types need to be taken into account when developing technologies to help any one subset, to be able to accommodate this goal. On your point of interoperability, your statements have nothing to do with interoperability. It is all about consistency. However, everyone has their own opinions about what is and isn't better. If everyone used the same toolkit to write their applications, it would be much easier to make things consistent. However, we have GTK+, QT, Motif, Windows, XForms, and several others to choose from. If you run apps from all of these different toolkits under an environment that uses one of those toolkits for the major portion of the desktop, you are going to notice inconsistencies in behavior between those applications, and ones written to conform to the standards of that desktop. Flaming GNOME because Opera doesn't fit in, is hardly going to solve the problem. If you really have constructive criticism, then please go back and re-think what you are trying to say, and choose your words more wisely. Trying to flame a project, simply because someone else who is famous is doing similar, isn't going to help anything. Throwing rocks at the beehive is only going to get you stung and swollen. :) -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] In short, I hate windows. (Hans Petter Jansson)
The problem with usability, is that it mostly isn't. The window management metaphor however, does fit well with the limitations we have, and with how people manage things in real life. People multitask. They eat, play video games, drive around, talk on the phone, use the PC, draw silly pictures, and do many other things, simultaneously. Trying to tell them that they can't do that any more, will make it harder to use the computer, not easier. What would really help, would be moving away from strictly having the desktop as we know it in software, and get away from the single or very few displays, pointing device, and keyboard way of thinking. When I'm working, I want to get up and move around, and do many things at once. I don't like being stuck in front of the same screen all day long, sitting in the same chair, with my hands in the same position, my fingers moving slightly, to fill in the words on my screen. I want my desktop computer to be more of a central docking station and server, more than a place I am required to be to get things done. Another common term for Usability is HCI (Human-Computer Interaction). However, it's still about how I can sit in this one position, and work more efficiently. It's much more about the computer, than the human. It lacks a certain amount of ergonomics and fluidity. It would be nice if someone could get us out of the rut we keep digging deeper, and help us leap into the 21st century, where we should be living. -- dobey On Wed, 2007-01-17 at 23:22 +0100, pohlmannmark72 wrote: Apart from the proposed functionality, it would be confusing for a user to have that kind of framed environment. For years, users are manipulating windows all day long. Changing that would be a very deep change in their way to use a window. I would not recommand that. Beside that, I do agree that this would be a very quick way to switch from one window to another. To conclude, as a reminder, you could use the ALT+TAB key combination to have that feature. ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] ‘extraneous text’ in dialo gs
The extraneous text is bad for accessibility. If the text is really needed, it should be in tooltips, not parenthesized within the actual text. It seems to me that the language in use in these particular cases could probably just use a bit of review. None (use solid color) could just be Solid Color for example. -- dobey On Wed, 2006-10-18 at 00:08 -0300, Mariano Suárez-Alvarez wrote: Hi all, What's the current stance on things like http://bugzilla.gnome.org/show_bug.cgi?id=143592 and http://bugzilla.gnome.org/show_bug.cgi?id=143594? Cheers, -- m ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] why are there no configuration tools for gnome?
This list is meant to discuss the usability of applications in GNOME, and not for asking questions about where various apps might be, or how to use them. This should be done on the gnome list. To answer your question, there are such tools, and in multiple varieties. Given that the way configuration works across distributions, and different versions of distributions, it's very difficult to have ONE tool that works across all distributions and versions. The GNOME Setup Tools aims to solve this by having one tool and an abstract back-end system to support as many versions of distributions as possible. However, it's a huge maintenance burden to have to keep up with the latest version of every distribution there is. -- dobey On Sun, 2006-10-01 at 23:23 +, 文 见 wrote: For example, configuring services, printer, network ... ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Drive applet by default
Më Enj , 2006-09-14 at 18:26 -0400, David Zeuthen ka shkruar: On Thu, 2006-09-14 at 14:05 +0200, Isak Savo wrote: I think he's talking about the fact that when you unmount a USB device in windows, the devices are often turning off their leds to indicate that they are now turned off. When unmounting in linux, this is often not the case (although the device *is* properly unmounted and data is flushed, so it's just a cosmetic thing.). Right, I've seen this too. It would be nice to turn power down the USB device when we've unmounted / ejected it. Unfortunately run-time power management is pretty weak in Linux but people are actually working on it. When it lands in Linux and is generally usable, we'll export this in HAL and it's easy to take advantage of from the desktop. On a laptop this might make sense. On my desktop though, I might want to eject my iPod, but leave it connect and have it continue to charge, if the battery is low. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Mac-style menubar in GNOME
Më Mar , 2006-09-12 at 17:10 -0700, Justin English ka shkruar: I find that occasionally (and heretically) the menu bar at the top of the screen is not what I want. If I have multiple apps open on my multiple-monitor desktop, I may have to move the pointer a great distance to get to the menu bar. As monitors grow, there is a tradeoff between having the menu bar always in the same place and impossible to overshoot versus close at hand in the current window. A good example of this is the 30 Apple Cinema HD display. Go to the store and try to use the Mac hooked up on the display. The amount of distance one needs to travel to get to the menus is insane. I for one am totally against the menubar idea, and people haven't even gotten to the real hard issues yet. What happens if you have said applet on the side or bottom of the screen, or in some arbitrary position along the edge, rather than in a corner? The overshoot problem makes sense on Mac, because they don't have arbitrary panel objects. They have a menu bar. It doesn't fit well into GNOME, and just because Apple did it for Mac OS, doesn't mean it works well on every other toolkit/OS too. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Dialogs and Maximize button
On Sat, 2006-09-09 at 11:49 -0600, Elijah Newren wrote: On 9/8/06, Olaf van der Spek [EMAIL PROTECTED] wrote: Hi, The HIG says (implicitly) dialogs shouldn't have a maximize button. http://developer.gnome.org/projects/gup/hig/2.0/windows-dialog.html Window Commands: Minimize, Roll-up/Unroll Also worth noting is http://live.gnome.org/Metacity/WindowTypes, which is mpt's work to try to extend the list of window types and provide better visual clues about each window. Can this be fixed such that dialogs can have a maximize button? Even better, can maximize buttons be automatically added to every window that is resizable? Given that both the HIG and mpt's extensions/modifications suggest no maximize button for such windows, it is possible that we should turn this question around: should we disable resizing for window types that shouldn't have a maximize button? Neither the HIG nor mpt's write-up addresses that question, and it seems some users are confused by the ability to resize if the window can't be maximized. If one automatically disables resizing of windows, may hellfire fall upon his skull. There are many MANY dialogs that have scrollable content inside them. Some of the content useful for more advanced users it outside the default visible area, and can be scrolled to. 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. I guess it's a problem that dialogs currently aren't iconifiable either. Is this a metacity or GTK+ bug though? -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] A Proposal for a new feature
On Wed, 2006-08-09 at 19:36 +0100, Alan Horkan wrote: On Wed, 9 Aug 2006, Reed Hedges wrote: Date: Wed, 9 Aug 2006 14:08:29 -0400 From: Reed Hedges [EMAIL PROTECTED] To: eigenlambda [EMAIL PROTECTED] Cc: usability@gnome.org Subject: Re: [Usability] A Proposal for a new feature One thing to consider is this: if you're typing at a terminal, ... you aren't really using the Gnome Desktop anymore. That's funny. There's this app in the GNOME Desktop release, called gnome-terminal. I would think that was part of the GNOME Desktop, no? Trying to force people away from using the terminal, isn't going to make it go away, or make people stop using it. And I don't think that the proposal here, or to add spell checking, will make it more usable. It's an application meant for a certain type of user. Just like Jokosher is meant for certain types of users. The goal of forcing people to not use the terminal, is not much of a goal. Why do you think Apple ships a terminal in OS X? Let's make it work better, but let's stop acting like it's not part of the Desktop, at the same time. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Usability Issues in Theme Manager
On Mon, 2006-05-01 at 11:51 +0100, Thomas Wood wrote: So definitely should be fixed? I could never see any use case for having the capplet open multiple times, so if it gets the approval of the usability team, then I will make sure it is prevented from opening more than once. Are you going to implement this in some way that isn't going to have to be a cutpaste code hack for every capplet? Frankly, I don't see a problem with being able to open it multiple times. The use case is that people aren't going to open it multiple times anyway. The case for fixing the code to not allow multiple instances, is that other pieces of UI are broken, and expect single click, where the user double-clicks, causing multiple instances to start. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Feature request: Workspace customization
On Thu, 2006-04-13 at 18:51 +0200, Lars Lundgren wrote: 1. A panel applet that shows the name of the current workspace. (Yes I know that you can configure the workspace switcher to show the labels, but that is not what I want.) Add a second workspace switcher to your panel. Configure it with the same layout as the origianl workspace switcher, and to only show the current workspace, and to show the names. This will show you the name of only the current workspace. 2. To have the background of certain components, like the desktop, to have an individual setting per workspace. Until someone can show me a reasonable UI for how to set the desktop background of different workspaces, this is not going to happen. Please forgive me if this is not the right forum for an email like this. It is not the right forum, as you are simply blindly requesting features, rather than discussing the usability aspect of how those features would be implemented, and suggesting methods for doing so. And, this forum is for the discussion of usability issues and solutions in GNOME, not for users to request features on. The proper forum for feature requests is bugzilla. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Primary window decorated as a dialog in an utility application?
I see no problem with the main window being a dialog. The preferences capplets in control-center are like this for example. However, it really bothers me when applications try to mix the two concepts into the applications main window. -- dobey On Fri, 2006-04-07 at 11:16 +0700, Артём Попов wrote: Hi all, I just wanted to know if GUP people consider okay to decorate an application primary window as a dialog with some small utilities, like a calculator, a volume control, etc. as seen in gfloppy: it does not have a menu or statusbar, but has some dialog-like buttons in the bottom. This also raises another question: should such an app mimic the GtkDialog appearance (the separator, spacings, etc.) or not? If yes, than is it okay to use GtkDialog class directly (note, that GtkDialogs do not have a minimize button)? If not, then what spacings and decorations are considerer standard? I ask this, because it seems to me that most GNOME apps have non-HIG spacings in their dialogs (e. g. 6-px window border instead of the HIG-recommented value - 12) And finally, how Help and About info could be made available in such an app? I was thinking about a help button in the action-area and a --about command-line option like in Zenity. Thanks everyone for your answers. --Artem ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Icons for document systems
On Mon, 2006-04-03 at 16:43 -0700, Bill Wohler wrote: Rodney Dawes [EMAIL PROTECTED] wrote: On Mon, 2006-04-03 at 15:40 -0700, Bill Wohler wrote: Given a hypertext document reader such as Info, what icons would you suggest for going back and forth in the history, going to the next and previous chapter, going up a section, or going up all the way to the table of contents? Info is beyond a hypertext reader. Yup, that's why I affixed document. Like an HTML Document? :) Perhaps documentation reader would be a better term, and one should throw out hypertext entirely from the sentence. It's an old buzzword from the 90s, that has become quite pervasive in the computing world, as just something that's there now. Even Tomboy, a little note-taking app, has links between notes and stuff now. I suppose it's a hypertext document reader too. :) But I deciphered your meaning, from the rest of your mail, so it's all good. I would suggest using the same bits that Yelp does, which is what should be displaying info under GNOME anyway. Yelp 2.12.2 on my system (Debian (etch)) doesn't have icons for Next Section, Previous Section, and Contents, and it doesn't even have an Up function, so there aren't really any bits to take. What icons would Yelp use if it had them? ;-) It wouldn't, and shouldn't, have icons for multiple levels of navigation, in the same area. That would be quite confusing to me, as a user. Next, Next, and Next?! Yelp doesn't have sections. Contents would presumably be the Home icon you see, which takes you to the TOC. Info is a bit too complicated in general I think. I actively avoid reading info pages, actually. I've found it basically impossible to actually find the information I want, and to navigate to it. Any chance you could just rewrite the Emacs docs in docbook, and use appropriate documentation output for the system you're installing to? Then you could integrate better with the desktops, and install the documenation into the system's help... system. That would be much better for the user, I think. Then they get the documentation, and in a format, and application, that they are perhaps better associated with. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] New launcher edition dialog
On Mon, 2006-03-27 at 22:01 +0200, Vincent Untz wrote: Hi, I'd like some feedback on this. Is it totally wrong? (I hope not ;-)) Is there some things to improve? Do you agree we should go ahead and use this in 2.15? Why is the new dialog Cancel/OK, and the rest of the dialogs Revert/Close? Shouldn't we just make them Cancel/OK too? -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Finish vs. Close in gnome-control-center dialogs
On Mon, 2006-03-27 at 16:45 +0100, Joachim Noreiko wrote: And why does it say wallpaper anyway? Is the style guide not clear enough? wallpaper: Do not use this term. Use the term desktop background. http://developer.gnome.org/documents/style-guide/gnome-glossary-desktop.html These are guidelines, and it uses appropriate terminology where appropriate. The guidelines are ignorant of the separation of image and color for the desktop background. These two items are not mutually inclusive into a single object and term. Also: http://makeashorterlink.com/?A21F13DDC Practically every movie site, and theme site, calls desktop backgrounds, wallpaper. The fact that it says Wallpaper is not confusing. The fact that it says Add is. And in more cases than not, Add in the file chooser dialog is much more confusing than Add Wallpaper in the main capplet UI. So, no, the style guide is in fact, not clear enough. As a maintainer and designer, actual usefulness and practical terminology is more important than following a guideline for the sake of following the guidelines. My job is to write the best possible software and interface that I can write, not to follow guidelines because the guidelines are there. They are in fact, only guidelines, and not a standard for language which must be adhered to by all applications. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Finish vs. Close in gnome-control-center dialogs
On Mon, 2006-03-27 at 22:55 +0100, Joachim Noreiko wrote: --- Rodney Dawes [EMAIL PROTECTED] wrote: On Mon, 2006-03-27 at 16:45 +0100, Joachim Noreiko wrote: http://developer.gnome.org/documents/style-guide/gnome-glossary-desktop.html These are guidelines, and it uses appropriate terminology where appropriate. The guidelines are ignorant of the separation of image and color for the desktop background. These two items are not mutually inclusive into a single object and term. Also: http://makeashorterlink.com/?A21F13DDC Practically every movie site, and theme site, calls desktop backgrounds, wallpaper. Just because Microsoft chose to use that term, and everybody is following, doesn't mean we should. OS X doesn't even use a term in the preferences, except in the desktop context menu, where is says 'desktop background'. Point-in-case. Microsoft doesn't use the term Wallpaper in their config dialog either. The tab in the Display Properties is titled Desktop, and the label for the list is titled Background:. So, no, it isn't just following Microsoft. It's following the terminology used where people actually go to get these things. And I think a search result of 17.x million vs. 2.x million is a sufficiently large difference to justify the use of the term. Surely 15 million people can't be wrong. But, just as I think blindly following Microsoft is a bad idea, so is blindly following what Apple does with Mac OS. We need to innovate on our own, and do better than both of them. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
[Usability] Re: Shouldn't Finish vs Close decision be made in the HIG [WAS: Finish vs. Close in gnome-control-center dialogs]
This is an incorrect assumption. All dialogs with a close button should not be switched to a Finish button. They should be changed to use the label and icon most appropriate for what the dialog does. In the case of the background properties dialog, I determined that we should use the GTK_STOCK_APPLY icon (because the OK/close icons suck), with the label of Finish. This may not be the best combination for other properties or preferences dialogs. It is certainly not a good thing for error dialogs, and other similar alert dialogs. -- dobey On Sat, 2006-03-25 at 09:45 +0100, Jaap Haitsma wrote: We are now discussing if capplets should have a Finish button instead of a Close button. If we agree to change that then in my opinion the HIG should be changed and all dialogs with a Close button should have a Finish button instead. Otherwise it will just lead to confusion Jaap ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
[Usability] Re: Shouldn't Finish vs Close decision be made in the HIG [WAS: Finish vs. Close in gnome-control-center dialogs]
On Sat, 2006-03-25 at 17:58 +0100, Jaap Haitsma wrote: Otherwise the desktop will get very inconsistent. I disagree with this. So long as the label and icon are actually affirmitive for the user, it shouldn't matter what they are. The HIG clearly states what spacing should be around the buttons, and that the affirmitive button should be on the right (or left, in the case of RTL languages). Therefore the affirmitive button should always be in the same place in the dialog. It shouldn't matter what the label is in the end, so long as it is affirmitive, rather than the opposite. I don't think the HIG needs to specify what dialogs use what labels. Perhaps we could make suggestions, such as If you cannot come up with a better label that is more specific to the dialog in question, you should use _Finish with the GTK_STOCK_APPLY icon. But I don't think we should force it really. We'll just end up with everyone switching if we do, and other dialogs may be confusing, as _Finish might not be the most appropriate label for them. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] GNOME default icons
On Wed, 2006-03-22 at 12:34 -0800, Bill Wohler wrote: Calum Benson [EMAIL PROTECTED] wrote: On 22 Mar 2006, at 16:46, Bill Wohler wrote: Also, there are a dazzling number of icon and desktop themes on the GNOME site, but none are branded Default so I could check for myself. What is the URL to the current default set of icons? The default stock icons in GNOME are provided by gnome-icon-theme: http://cvs.gnome.org/viewcvs/gnome-icon-theme/ Thank you Calum. It appears the new arrows are, indeed, blue. It would be nice if the set were available alongside the other themes to make it easy to compare. In the Icons tab of the details dialog in the theme manager, GNOME shows up right next to all the other icon themes. Packaging it as a tarball and putting it on art.gnome.org or some other site does not really make sense, as there are several pieces of infrastructure that would get ignored. This is even more so for 2.15. These icons may of course be over-ridden by any other theme that your distro specifies That's apparently what is happening here (to get the green arrows) but I'm baffled because I couldn't find any stock_left.png images on my system that were green. Is it possible the icons are compiled into the applications? I'll ask the Debian folks for debugging information. No, what's happening is that the icons in gnome-icon-theme do not have the appropriate names for overriding the arrow icons in GTK+. GTK+ uses stock icons with various names, which are different than the filenames of icons in gnome-icon-theme. As I stated earlier, there is a bug filed to update the theme, so that these new blue icons get used instead. 2.15 will be updated to follow the Icon Naming Specification, and have properly named symlinks to override the stock GTK+ icon names. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: Novell Start menu [was Re: [Usability] Thoughts on GNOME and DTP]
On Fri, 2006-03-24 at 12:34 -0500, Dan Winship wrote: Rodney Dawes wrote: There was no consensus on whether to make it the default in 2.16 or not. Well, that's kind of a weird way of looking it. No one has even proposed *including* it in the release yet. Exactly my point. It is foolish to claim something is highly unlikely to be included, if it hasn't even been proposed to be included yet. :) -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] GNOME default icons
The arrows among other icons, are stock GTK+ icons, and included in GTK+ itself. Most of these icons are not overridden in the icon theme, as one might expect, despite the fact that similar icons exist in the theme. http://bugzilla.gnome.org/show_bug.cgi?id=172607 The above bug has been filed about this, however, I have not had the time to get around to fixing it for 2.14.0 as I was working on more major changes, which unfortunately didn't get to go in either. These changes however, are in fact, scheduled to go in 2.15. Along with these changes, these icons will be renamed appropriately, and override the stock GTK+ icons. And, as Calum stated, gnome-icon-theme is in GNOME CVS, and not available as a simple tarball theme download on a theme site. -- dobey On Wed, 2006-03-22 at 08:46 -0800, Bill Wohler wrote: I'm a bit confused. On my Debian system, which seems to be about GNOME 2.12, the arrow in: /usr/share/icons/hicolor/24x24/stock/navigation/stock_left.png is blue, as are all the other stock_left.png images on my system. However, the arrows in Galeon, Nautilus, and other GNOME apps are green. I thought the green arrows were in GNOME 1 and the blue arrows are in GNOME 2. Is that true? If so, why do you suppose I'm seeing the green arrows in my apps? If not, then from what directory do you think my apps are pulling the icons? Also, there are a dazzling number of icon and desktop themes on the GNOME site, but none are branded Default so I could check for myself. What is the URL to the current default set of icons? Thanks! ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Mute in GNOME mixer applet does not have correct behavior
On Sun, 2006-03-19 at 18:30 +0100, Jaap Haitsma wrote: Wanting to set the volume to a level so that you do not hear is a special case. Just wanting to set volume lower isn't. The term for this special case is mute not 0. I was not arguing that simply wanting to lower the volume was a special case. I was arguing that, in fact, it was not a special case, and therefore should not continue to be treated as one. Any random piece of software. I agree it's maybe not that likely but if we can make the mixer applet functioning well in that case, why not do that? It was brought up by the gnome-mixer-applet maintainers in http://bugzilla.gnome.org/show_bug.cgi?id=164925 If a user is using a random piece of software that behaves this way when they click the mute button in that application, then would they not expect to see the mute icon as well in GNOME, as they probably see a mute icon in their application? The bug won't be filed in my case. The user holds down the key until he sees the 0 icon and then stops. Until the user cannot hear the audio and/or the progress meter is at 0. We should not rely upon an icon as the only method of feedback to the user. As I said before, the pop-up should have a label and progress bar which show the volume level more exactly. Another option would be to have a beep sound, like those of other operating systems when the volume level is changed. 0% volume is a special case because together with mute it's the only possibility to make your computer completely silent. This statement clearly says 0% == mute. Given this, the current behavior of the icon is correct. The issue is that unmute does not restore to the previous level. If there aren't any other people who feel like me that there should be a 0 icon to represent, I'm happy to go with your suggested improvement that the 0% volume is shown as low instead of muted as it is now. I'm sure there are plenty of people who would also argue for the 0 icon. But that doesn't mean there should be a 0 icon. As you said, we need to try and make the experience be the best one possible. To do that, we need to make 0 be either mute or low, but not both. It is not both. That said we need to do one of the following: 1) Keep 0 as mute, and fix the unmute behavior to restore to something 2) Make 0 be low And other than the case where a non-GNOME application is setting the volume on the hardware itself to 0, how many people are really going to hold down the lower volume key, rather than just pressing mute? Another thing we need to do, is to make it easy to mute the volume, from the mixer applet's pop-up. I think it's the main thing that causes people to drag the volume to 0. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Mute in GNOME mixer applet does not have correct behavior
On Sat, 2006-03-18 at 19:57 +0100, Jaap Haitsma wrote: Hi, Conclusion What do the usability people think of this?? stock_volume-0 is the worst icon ever. What exactly does 0 mean, when you have your volume set to 24%? The optimal behavior would be to restore the volume to where the user /started/ from, when dragging the slider to 0 in the first place, not to restore to it was last set after they let go (which would as you point out, in this case, always be 0). Their should be 4 states only. High, medium, low, and mute. Something between low and mute doesn't say anything. The volume-0 icon has no audio waves in the icon, but gets used up to 25%, so the user may still have quite a bit of audio coming out of the speakers in fact. This seems just as confusing to me. How often are people to drag to 0, rather than just clicking on mute? I highly recommend the suggestion in my first paragraph, to use the volume where they /started/ sliding from, when dragging the slider to 0, and later pressing unmute. The volume control surely must be able to keep this state. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Mute in GNOME mixer applet does not have correct behavior
On Sat, 2006-03-18 at 21:57 +0100, Jaap Haitsma wrote: On Sat, 2006-03-18 at 14:33 -0500, Rodney Dawes wrote: I don't see why the 0 icon is the worst icon ever. I agree if it isn't used properly like in the case you describe it's not good. That was even one the reasons that I filed bug [1]. Because it has no meaning. A volume level of 0 should not be something between low and mute. It should one of them. The icon exists because whoever wrote the code in the first place, decided they absolutely had to have this icon. What is the problem of using the 0 icon for 0% volume if the audio is not muted? What is the problem of using the low icon for 0% volume then? If the audio is not muted, it is low. It seems rather pointless to have two different icons for 0% and 1% where the 0% icon is not mute. Just make them the same, and get rid of the special case for 0 in the code. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Mute in GNOME mixer applet does not have correct behavior
On Sun, 2006-03-19 at 00:16 +0100, Jaap Haitsma wrote: 1. Display mute icon if mute button is active 2. Show volume level if mute is not active. This is basically the same thing I said in my last mail, which was to remove the special casing of 0, and make it use the -low volume icon. In other words, to revert to the example in your first mail, we should do this: volume(x) Icon -- mutemute 0 = x 1/3 low 1/3 = x 2/3 medium 2/3 = x 3/3 high The stock_volume-0 icon will exist no longer in 2.15 anyway, and the others will be renamed to follow the naming spec. To resolve the issue in 2.14, one should use the old icon names as the applet still does, but optimize in the case where one of those may be going away. We can stop using -0 now, so I see no reason not to. I would much rather not have this exact same discussion again in another 5-6 months. Simply stating that -low would be confusing because it has a single ) for 0% is just as well as saying it is confusing for other very low volume percentage levels where the user may not be able to hear any audible output from the speakers. Just use -low. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Re: [Desktop_architects] Printing dialog and GNOME
On Wed, 2005-12-21 at 18:56 +0100, Mateusz Łoskot wrote: Ross Burton wrote: On Wed, 2005-12-21 at 16:25 +0100, Mateusz Ĺ#65533;oskot wrote: Excause me, I've not expressed it precisely. I tried to say that I Nautilus file manager + desktop is highly integrated with GNOME, so currently there is no good substition. That's not correct, nautilus is integrated into GNOME as it's the default desktop and file manager. And IMHO this integration is a problem. Not really. Nautilus can be completely done away with, and GNOME in general will still function quite happily. If someone wants to run an alternative, there is no reason why that isn't possible. I didn't say it isn't possible, but running alternate file manager Nautilus integration to GNOME desktop is still present. What for? You didn't completely remove Nautilus then. It's probably still in your session and still controlling the icons on the desktop. If you want a different file manager to do this, you will have to configure Nautilus to not do it. Having said all that... What does the file manager have to do with the print dialog? If you want to start a new thread, please start a new thread. Diverging an existing thread for your own purposes is rude, and makes it difficult to read the original thread, or yours, as the two become quite intertwined. Ironic for someone complaining about how the Nautilus file manager is so heavily integrated. :) -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Panel applet interface
Spamassassin marks all of your mails as spam for me. It looks like it is because you are using a yahoo.com mail address, but are not sending the mail through yahoo, but rather, from a local agent. This is a common thing for spammers to do, so spamassassin gives it a bit of a score for that. -- dobey On Wed, 2005-10-26 at 16:20 +0100, Joachim Noreiko wrote: Joachim PS. My emails to various gnome lists go straight to my junk folder when I receive a copy back. Is this a problem with what I'm sending? ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] sound events in gnome
On Mon, 2005-09-26 at 12:16 +0200, Sven wrote: Hi list, The tab Sound events opens up much to small, and every section is opened by default - games on top. Most time i dont want to change the gnome-game-sounds. I want to change start sounds or warning sounds. They have to be on top in that list due to importance. Game sounds should not be customizeable outside the games at all I think. Game sounds are typically specific to the game type and the actions and events in it. I believe they are there simply due to historic reasons so that they could use the sound events API to play the sounds. Why are only so few options in the Sound events-dialog, lots of projects like gaim have their own sound-selection dialogs because the gnomes one is so bad and doesnt integrate well. Come on guys you have gconf, why dont you use that? Gaim has their own sound selection UI because they refuse to use extensive gnome APIs and the API you are questioning is above GTK+. They want to keep the dependencies to a minimum so it is easier for them to support win32, qtopia, etc... The current dialog would work totally fine for them, if they chose to use the sound events API on gnome. Using gconf for sound events is probably the wrong way to go about things. Though, some of the settings are stored in gconf. And then, in the tab System Bell one can choose to Sound an aubible bell, well its activated here but i never heard that bell. These should probably actually be in some other capplet. Probably the keyboard or a11y capplets. The control center is a bit of a mess at the moment with all of the features for keyboards and whatnot being spread across multiple capplets. It does indeed add to the complexity and confusion of the desktop. Additionally i can imagine a much better file chooser dialog for choosing a sound file than that standard gnome dialog. At the moment a user has to open the dialog with browse, browse to audio files and choose one, then he can test what it sounds like. Thats way to complicated if u want to check 10 files or more. Nautilus sound preview in icon view does the job, but drag and drop works only for the adress field, not for the lists element itself like a drap and drop should work. The file chooser dialog itself is a separate issue. But all in all, there is no technically better way to make it easier to browser a multitude of files and try each one individually. Adding a Preview to the dialog, so that you can listen to the sound would help though. Please file a bug in http://bugzilla.gnome.org/ against the sound preferences dialog requesting a preview in the file chooser. What if a user inserts a cd with 1000 sound files, he opens the dialog and browses to the sound files he likes with the file open dialog. He chooses the file and removes the cd - gnome should be that intelligent to copy files from removable medias to a temp directory if the user is not. This is a technical issue, not one affecting the interface or workflow of the application. I don't think it needs to be discussed any further on this list, but it is indeed something that must be considered when actually implementing the code. Gnome sound events still only work with wav files and if i choose a ogg, it tells me that this isnt a valid wav file, ugly thing to force users to stick with wav files. Wouldn't it be better to load a 200kb ogg instead of 2MB wav at the moment of gnome-start? This is a technical limitation of the APIs used to play back the audio data. ESound does not support OGG/Vorbis, MP3, or other formats directly. Of course, events should not be limited to sounds, I think, but that's another issue. anybody working in that field? There are various patches and changes available around. I myself have even started working on a specification for cross-desktop sound themes, though gnome developers were claiming that we should just get rid of sound events, and kde people were flaming because it wasn't straight KDE. I would be glad to continue work on the theme spec at some point. In SUSE 10, there is an updated events dialog, which only lists some of the more critical sound events, and has a preview. It's not the best UI but it's much better than the current upstream dialog, I think. We're working on improving it even further, and have done usability tests on it by having users try to disable certain sounds. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Input Methods and Insert Unicode Control Character in context menus
They are for text input using the keyboard. The fact that they are there has nothing to do with Pango and general text handling in terms of rendering the data. If Pango could not render the text, it would be quite useless to have the ability to enter it directly into something that does not support it. However, computers are party of a very multi- lingual society, where an input method may be required to enter text in another language, from a US keyboard, for example. As far as the usability of having it in the context menu goes, it is a submenu, so only adds a very small amount of space to the existing menu, and it does not require you to use it. In fact, I don't think I've ever even used the right click menu, except to test that the Input Methods submenu was working ok, when it was added to GtkHTML, so that Evolution could support input of text for the languages where such methods are needed. I would probably suggest just not using it, if you do not want to use it for now. Perhaps in the future, this could be an option in the Keyboard or Locale settings, though. -- dobey On Wed, 2005-08-03 at 15:59 +0100, Alan Horkan wrote: On Wed, 3 Aug 2005, Todd Chambery wrote: Date: Wed, 3 Aug 2005 08:43:25 -0400 From: Todd Chambery [EMAIL PROTECTED] To: usability@gnome.org Subject: [Usability] Input Methods and Insert Unicode Control Character in context menus Hi all, I've been using Gnome a while, and the Input Methods/Insert Unicode Control Character options that show up in every text entry context menu has always puzzled me. I've never had a need to use them (they are foreign to a MS Windows user) and feel that they unnecessarily clutter the context menu. Is there a way to turn off these context menu options? Not that I know of, but it may be possible. I believe they are for complex text input and developers insisted on having them in an easy to find place, and techincal considerations trumped usability cocerns. I was under the impression that improvements to Pango and the general text handling in Gnome might eventually allow these menu items to be removed entirely. Hopefully someone more expert can shed some light on these and explain it better. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] tools on the desktop
On Mon, 2005-08-01 at 15:57 +0100, Alan Horkan wrote: I believe there are patches for this functionality in Bugzilla and some of them may only require a little updating to work with current versions of Nautilus, which is why I suggest asking your distribution of choice. Do you have bug numbers? I have a patch that works with current HEAD. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] tools on the desktop
On Mon, 2005-08-01 at 17:20 +0100, Alan Horkan wrote: I expect you patch is better, let me see if I can find the one I was thinking of ... The request against nautilus largely responsible for this whole discussion: Trash should just Eject appropriate mounts instead of giving advice on how to do the umount http://bugzilla.gnome.org/show_bug.cgi?id=115763 I've attached my patch to this report. Hopefully people will go and support its inclusion in Nautilus, possibly for 2.14. I imagine that the feature/UI freeze argument is sufficient reason to disallow it for 2.12, which is fine. But it would be nice to improve the behavior for 2.14, whether it is through this patch, or a more featureful one, after useful discussion has taken place. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] tools on the desktop
On Sun, 2005-07-31 at 15:50 +0100, Alan Horkan wrote: On Sat, 30 Jul 2005, Rodney Dawes wrote: For things like USB keyfobs and such, I think we should just fix the problems with losing dating if you unplug the device, and it is not written to yet. Yes please! Making users jump through hoops because the sofware is not smart enough to cache data is really annoying. The problem is that the software is caching data, actually. It's buffering the write to disk, so the data might not actually be synced yet when the user pulls the plug, since the writes are async. :) This basically means that devices need to be unmounted properly so that the data can be dumped to disk, rather than lost. Windows and MacOS both have methods to whine at you when you unplug devices without stopping them. The Mac OS eject behavior for dragging to the trash, is more related to the hardware interfaces, I think. Macs have historically not had eject buttons for at least floppy and cd-rom drives, and therefore required the user to eject things via software, or with a paper clip. The hardware forced them to provide a proper software fix, but even if they had hardware buttons I think it is something they would have gotten around to eventually. I would hardly call it forced or a proper software fix. Apple designed both pieces of that equation. Being able to eject media from software is nice, so long as it is intuitive. If I recall correctly Mac OS provided a menu Item for Eject (in the System menu?) near where the Shutdown button lives but I dont think Gnome provides a suitable and convenient menu item for ejecting mounting drives (but dont quote me on that, I may have missed it or not be adequately up to date). Can we provide an equivalent as it might be less contraversial and we need a more easily discoverable method to eject drives even if the various suggestions are implemented in some form or another. They did provide a menu item, in at least pre-X Mac OS. However, the thing at the top of the screen in Mac OS is not a panel. It is THE menubar. So, when you are focused on the Finder desktop icons, you get the Finder menus. I don't know if the menu item to eject devices still exists in OS X, but it's not something that can be easily duplicated in Gnome with the way Nautilus and the panel work. It would take a sufficiently large patch to have Nautilus notify a panel applet of which icon on the desktop is focused, and if it can be ejected, unmounted, or anything else, I think. They've added eject buttons to some machines in the near recent development of hardware, but many devices still do not have hardware eject buttons. Of course, Nautilus also already provides an Eject/Unmount item in the context menu for mounted devices. I think the unreliability of mount which in effect cripples the eject button on most CD drives forced Nautilus to provide a workaround. Ideally the eject button should just work (although you might still want to disable it while a Disc is being burned). Mount itself does not cripple the eject button on CD drives, afaict. In SUSE 9.3 at least, with the subfs mounting stuff, it does not break the eject button at all. You can hit the hardware eject button on the drive, and it will Just Work (TM). -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] tools on the desktop
I like using the Eject button on the drive. It works nicely. :) For things like USB keyfobs and such, I think we should just fix the problems with losing dating if you unplug the device, and it is not written to yet. The Mac OS eject behavior for dragging to the trash, is more related to the hardware interfaces, I think. Macs have historically not had eject buttons for at least floppy and cd-rom drives, and therefore required the user to eject things via software, or with a paper clip. They've added eject buttons to some machines in the near recent development of hardware, but many devices still do not have hardware eject buttons. Of course, Nautilus also already provides an Eject/Unmount item in the context menu for mounted devices. Aside from that, if a device is not mounted, or does not contain accessible media, why should it appear on the desktop at all? It seems to me that users want to be notified that things ARE working, in rather odd ways sometimes, as they don't trust that it WILL work. And, yeah, adding more functionality to a menu item, based on where your pointer is horizontally across the menu item, is bad. I also somehow doubt that the patch needed to GTK+ to get menu items to work in a way to make the hilight change horizontally across a single menu item, so that the user will actually know what part they are clicking on, wouldn't get accepted either. :) -- dobey On Sat, 2005-07-30 at 18:22 +0300, Kalle Vahlman wrote: On 7/30/05, Alexander Brausewetter [EMAIL PROTECTED] wrote: On Fri, 2005-07-29 at 16:12 -0700, Daniel J. Wilson wrote: On Jul 29, 2005, at 3:27 PM, Alexander Brausewetter wrote: How about adding a small eject icon ⏏ to a corner of the device icon. I mocked up something similar several months ago: http://blog.wilsonet.com/archives/2005/04/15/dealing-with-ejection/ I've also done a little mockup now: http://f4ee.net/~alex/Device_eject_button.png Oh, please no. I find menus hard enough to use when the direction that matters is vertical, if you make the menus require precise targeting in *both* directions, using menus will be a pain. More presicely, it will a) take a lot of time to open something in menus (you need to target twice, so it'll take double the time to target) b) make mistakes frequent, and in this case, non-trivial ones that eject your disc when you try to acces it ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] tools on the desktop
On Fri, 2005-07-29 at 15:36 +0100, Phil Bull wrote: This tool also could manage resources in the network that are available via Rendezvous This would be pretty cool. I haven't used KDE for a long while, but they used to have something called the LISA daemon (IIRC), which listed all of the services on the local subnet in Konqueror. Something similar, and ZeroConf-based, would be a nice addition in the 'Network' folder perhaps. The Network folder already has support for listing dns-sd shares that are visible through Nautilus. I would not want to see all possible services that might use zeroconf, slp, or whatever, in a Nautilus folder. * Why not use Themes as something that is adopted to a local culture? Interface consistency. It's bad enough having language barriers, but when you start rearranging things based on locale, people from low-user-count locales might get stuck and have no-one to help them because their desktop layout is different from anyone else's. However, locale-based themes are useful. In fact, we already re-arrange some things based on locale. RTL languages need to have the interface flipped, for example. And metaphors for some things may not translate well, particularly with icons and branding. However, having said that, I do think it is better to just try and come up with simple metaphors for things, that do translate well, rather than having themes where the icons are different for different languages. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] changing view with key strokes.
On Thu, 2005-07-21 at 11:39 +0200, Thilo Pfennig wrote: I just cam across the fact that the shortcuts for inreasing and decreasing the view of a page are different in Evolution and Epiphany. Maybe in more applications? Evolution: Strg+8, Strg+9 Evolution uses C-+/- now in 2.3.x. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Button Layout in Dialogs, vertical button bar on the right?
In those dialogs, the buttons you are talking about, are usually add/remove or similar buttons, relating to the widget directly to the left of the column of buttons in question. In the theme capplet, these buttons generally directly reflect the view in the list, directly next to the buttons. This is the same for the Search/Folder/Filter editor dialogs in Evolution. In some places, it doesn't necessarily make much sense. The details dialog in the theme capplet for example. The Go to Theme Folder button has no real relation at all to the list. The closest possible argument, is that the items inside of the folder, may or may not affect individiual details theme lists. I think it's safe to say that the button doesn't belong on the upper right in the notebook tabs in the Theme Details dialog. Moving the OK/Cancel/etc... buttons to the right hand side, would only make things even more terribly confusing for our users, I think. -- dobey P.S. Anyone know of an easy to use key logger or click counter, something like to gather data on my own usage patterns? If there was something I could compile into my applications to gather usage data I might be interested to give that a try but in the short term I'm just looking for something simple, a step up from the odometer panel applet. The timeline module in CVS might be of help. It lets you visualize the applications you spend your time in, in a neat little timeline. :) ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Content Separation in GNOME
On Mon, 2005-04-04 at 02:34 +0100, Alan Horkan wrote: On Sun, 3 Apr 2005, Ivan Gyurdiev wrote: I would like to propose introducing content folders to GNOME, similar to Windows' My Documents, My Music, etc.. this will improve usability Some distributions have already done this. I want to smack them really hard with a wet fish for using that annoying My prefix in front of everything. The My prefix to things is annoying, but I can see how it would alleviate some confusion to users who are migrating from Windows, to our lovely desktop. I still hate it now though. Some users have their home directory set as their desktop and while I'd like to call them rude names and ignore them for being so weird that doesn't seem to be an option. They would not be impressed if you added yet another folder to their beloved home directories. I would be fine with ~/Documents, ~/Movies, and whatnot. What I wouldn't be fine with is having a Desktop directory, on my desktop, which is my $HOME. I think it would be fine to provide a few default content folders, but I don't think we should overdo it. The big problem here, is and always has been, translating the folder names to different strings. Sure, if we ignore every other piece of software out there that isn't Gnome/GTK+, or potentially KDE/QT, then it's much simpler. But as soon as a user opens a terminal and types ls, they are going to say WTF?. I think we should worry about solving it for the entire desktop, not just our desktop. (I'm grossly over simplifying because I'm in a hurry but) The solution I thought was most promising was to have: ~/Documents/ and various subfolders of that. (Some people *cough* developers *cough* have difficulty getting their head round all users files even non office related files, things like movies and mp3s being refferred to as documents. From what I understand though Gnome is supposed to be document based as opposed to say task based interface.) Document based is a rather generic term, which often ends up confusing people into thinking everything should be a document. That's not really the case though. Movies are movies. Audio is audio. Documents are documents. And tarballs may contain video, audio, still images, and documents, but they aren't necessarily documents themselves. Users aren't going to call them documents either. I would even go so far as to say that users don't refer to all files created by office suites, as documents either. They will say presentation, or spreadsheet, and generally refer to a document as something that came from word, acrobat, or the like. A form or letter, for example. I'm not sure we want to shove everything under ~/Documents as such. In fact, I store music and movies under appropriate directories in ~/Downloads currently, which may actually make more sense. It needs a lot more thought, and possibly a lot of extended user testing. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] GTK Stock icons
On Fri, 2005-04-01 at 16:44 -0300, Lucas Meneghel Rodrigues wrote: Hi everyone I don't know exactly where I should post this, so if someone finds it inappropriate, please forgive me and pont me to the right location. Most default stock icons (for actions like cancel or OK) present in gtk are really dated (gnome 1.X) and not really good looking. However, it seems that no one cared about getting rid of them on 5 (!) stable releases of the gnome 2.X series. Most of the icons were re-done actually for 2.0. However, there are already good replacements for (most of) them. For example, the stock icons made by jimmac for the industrial GTK theme fits well with default gnome artwork and are aesthetically pleasant. I know that this can be fixed by: 1 - Adding Industrial stock icons to the hicolor default icon theme, so every gnome/gtk app on X11 will benefit from it. The hicolor icon theme doesn't contain any icons, and isn't a gtk+ theme, so I'm not sure that this would really solve the problem. 2 - Other possible approach would be integrating the stock icons aforementioned on gtk proper, so the windows apps that uses gtk (gaim, abiword, gimp) can benefit for it too, and the old stock icons can rest in peace. Abiword on windows doesn't use GTK+. I believe they use XPM versions of some icons, imported into their code directly, even on *nix with GTK+. I would like to make clear that I'm suggesting the Industrial theme stock icons as the default because they are clear, distinctive, neutral and fit well with the rest of the artwork. I'm not trying to make a flamewar about this. So, I would like an opinion about this. I would like to see this fixed, making our desktop and development platform rock even more. If you know what icon names need to be used in the Icon Theme, not the gtk+ theme with an iconrc file, please file bugs against gnome-icon-theme in http://bugzilla.gnome.org/ with the list of names that are looked up in the icon theme for this. I will see what I can do to get them into gnome-icon-theme at that point. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] GTK Stock icons
Just list the proper names in the bug report. No need to attach a tarball. I have all the icons. -- dobey On Fri, 2005-04-01 at 19:07 -0300, Lucas Meneghel Rodrigues wrote: Thank you, Rodney. I'll file the bug. However, I still don't know how to do proper patches (shame on me!), so I will attach a tarball of the gnome icon folder with only the needed icons with the proper naming scheme inside of it. Please, if it's the wrong way to do it tell me and I'll skip this and only put the list of icons as you've requested. I don't want to cause all the fuss that happened with an incorrect patch on the gnome default theme. Best regards Lucas On Apr 1, 2005 5:25 PM, Rodney Dawes [EMAIL PROTECTED] wrote: On Fri, 2005-04-01 at 16:44 -0300, Lucas Meneghel Rodrigues wrote: Hi everyone I don't know exactly where I should post this, so if someone finds it inappropriate, please forgive me and pont me to the right location. Most default stock icons (for actions like cancel or OK) present in gtk are really dated (gnome 1.X) and not really good looking. However, it seems that no one cared about getting rid of them on 5 (!) stable releases of the gnome 2.X series. Most of the icons were re-done actually for 2.0. However, there are already good replacements for (most of) them. For example, the stock icons made by jimmac for the industrial GTK theme fits well with default gnome artwork and are aesthetically pleasant. I know that this can be fixed by: 1 - Adding Industrial stock icons to the hicolor default icon theme, so every gnome/gtk app on X11 will benefit from it. The hicolor icon theme doesn't contain any icons, and isn't a gtk+ theme, so I'm not sure that this would really solve the problem. 2 - Other possible approach would be integrating the stock icons aforementioned on gtk proper, so the windows apps that uses gtk (gaim, abiword, gimp) can benefit for it too, and the old stock icons can rest in peace. Abiword on windows doesn't use GTK+. I believe they use XPM versions of some icons, imported into their code directly, even on *nix with GTK+. I would like to make clear that I'm suggesting the Industrial theme stock icons as the default because they are clear, distinctive, neutral and fit well with the rest of the artwork. I'm not trying to make a flamewar about this. So, I would like an opinion about this. I would like to see this fixed, making our desktop and development platform rock even more. If you know what icon names need to be used in the Icon Theme, not the gtk+ theme with an iconrc file, please file bugs against gnome-icon-theme in http://bugzilla.gnome.org/ with the list of names that are looked up in the icon theme for this. I will see what I can do to get them into gnome-icon-theme at that point. -- dobey ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
