Re: UI changes for control-center
Le jeudi 27 août 2009, à 15:03 -0400, Matthias Clasen a écrit : So, in order to come to some conclusion here, I'll give a +1 for removing the interface tab. (Kinda obvious, since I wrote the patch in the first place...). I'll be more than happy to work on fixing up the docs afterwards. Can we get some response from my fellow release team members ? -1 from me. It's too late in the cycle to change this kind of stuff. I don't see any reason to not wait for 2.29. Vincent -- Les gens heureux ne sont pas pressés. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
Am Freitag, den 28.08.2009, 16:17 +0200 schrieb Vincent Untz: Le jeudi 27 août 2009, à 15:03 -0400, Matthias Clasen a écrit : So, in order to come to some conclusion here, I'll give a +1 for removing the interface tab. (Kinda obvious, since I wrote the patch in the first place...). I'll be more than happy to work on fixing up the docs afterwards. Can we get some response from my fellow release team members ? -1 from me. It's too late in the cycle to change this kind of stuff. I don't see any reason to not wait for 2.29. Same opinion here (though I think I wrote this already). andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
On Fri, Aug 28, 2009 at 10:17 AM, Vincent Untzvu...@gnome.org wrote: Le jeudi 27 août 2009, à 15:03 -0400, Matthias Clasen a écrit : So, in order to come to some conclusion here, I'll give a +1 for removing the interface tab. (Kinda obvious, since I wrote the patch in the first place...). I'll be more than happy to work on fixing up the docs afterwards. Can we get some response from my fellow release team members ? -1 from me. It's too late in the cycle to change this kind of stuff. I don't see any reason to not wait for 2.29. I'd be honestly interested in the argument why it is too late. Are you afraid that this tab might be mentioned in the docs ? That point is really kinda moot, since the user guide was _completely_ out of sync with what we actually ship until I sat down last cycle to make it match reality somewhat again. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
Le vendredi 28 août 2009, à 18:44 -0400, Matthias Clasen a écrit : On Fri, Aug 28, 2009 at 10:17 AM, Vincent Untzvu...@gnome.org wrote: Le jeudi 27 août 2009, à 15:03 -0400, Matthias Clasen a écrit : So, in order to come to some conclusion here, I'll give a +1 for removing the interface tab. (Kinda obvious, since I wrote the patch in the first place...). I'll be more than happy to work on fixing up the docs afterwards. Can we get some response from my fellow release team members ? -1 from me. It's too late in the cycle to change this kind of stuff. I don't see any reason to not wait for 2.29. I'd be honestly interested in the argument why it is too late. Because I don't see why we would do a big change like this while we only have a RC left before the stable release. The main issue (from my point of view) is that we don't know how people will react to this change, and we don't have time to evaluate this. Also, I see no urgent reason to fix this now. It's definitely not something that, imho, is mandatory for the 2.28 release; so it can wait for the next release. Vincent -- Les gens heureux ne sont pas pressés. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
So, in order to come to some conclusion here, I'll give a +1 for removing the interface tab. (Kinda obvious, since I wrote the patch in the first place...). I'll be more than happy to work on fixing up the docs afterwards. Can we get some response from my fellow release team members ? ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
On Mon, 2009-08-24 at 14:23 -0500, Shaun McCance wrote: 3) Do a search online to see if these options are used to solve (or work around) real problems. Make a recommendation for troubleshooting topics to be written to address any such problems. I did a quick online search for gnome, appearance and interface tab. Obviously a lot of false positives with such vague keywords, but the few things I did find that where related basically where either: * user guide documentation * magazine/feature reviews. e.g. this article doesn't even consider the tab worthy of much discussion: (http://www.packtpub.com/article/ubuntu-user-interface-tweaks) * a page explaining how a user ended up with broken shortcut keys in their favourite application and found the problematic option in the interface tab (http://live.gnome.org/Gedit/KeyboardShortcuts) Regards, Thomas ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
So rereading this thread, I believe I've been unnecessarily abrasive, and I've injected my personal opinion of these changes into what should only be a discussion of whether we should break the UI freeze. I apologize for that. Let me try this again. http://bugzilla.gnome.org/show_bug.cgi?id=323323 http://bugzilla.gnome.org/show_bug.cgi?id=591375 http://bugzilla.gnome.org/show_bug.cgi?id=592510 These three are absolutely OK with me. They are all obvious improvements. They don't require substantive documentation work. And they have almost no chance of leading to user problems. http://bugzilla.gnome.org/show_bug.cgi?id=592756 http://bugzilla.gnome.org/show_bug.cgi?id=592759 Here is what I would like to see happen for these changes to be made after the UI freeze: 1) Make the necessary changes to the User Guide. Matthias already pointed out where the changes need to be made. 2) Look through our other documentation to see if any other documents are referring to these features. You can probably safely skip simple documents, like those for small games and utilities. I'd be even happier if somebody would look at some of the more comprehensive manuals outside our release, such as Gnumeric and GIMP. 3) Do a search online to see if these options are used to solve (or work around) real problems. Make a recommendation for troubleshooting topics to be written to address any such problems. I don't care who does the work. But that's what the documentation team would be facing if these changes were made. -- Shaun ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
William Jon McCann wrote: There are a few changes we'd like to make to the control center before the string freeze. Some of these involve UI changes as well. So, according to http://live.gnome.org/TwoPointTwentyseven we need approval. http://bugzilla.gnome.org/show_bug.cgi?id=323323 http://bugzilla.gnome.org/show_bug.cgi?id=591375 http://bugzilla.gnome.org/show_bug.cgi?id=592510 http://bugzilla.gnome.org/show_bug.cgi?id=592756 http://bugzilla.gnome.org/show_bug.cgi?id=592759 So, how about it? I promise they make the user experience better. I'll look at them later today (or tomorrow), CC'ing the documentation list for eventual input, and the translators for possible string changes. Cheers, Frederic ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
Il giorno dom, 23/08/2009 alle 08.44 +0200, Frederic Peters ha scritto: William Jon McCann wrote: http://bugzilla.gnome.org/show_bug.cgi?id=592759 So, how about it? I promise they make the user experience better. Are you proposing to remove the Windows preferences capplet now? Isn't better wait for availability of tweak ui tool? If you really think it doesn't fit, you could simply hide the launcher. However, I think the proper timing for this kind of changes/removals will be the switch to gnome-shell, keeping the ui that users are accustomed in the meantime. Cheers, Luca ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
Hi, On Sun, Aug 23, 2009 at 6:06 AM, Luca Ferrettielle@libero.it wrote: Il giorno dom, 23/08/2009 alle 08.44 +0200, Frederic Peters ha scritto: William Jon McCann wrote: http://bugzilla.gnome.org/show_bug.cgi?id=592759 So, how about it? I promise they make the user experience better. Are you proposing to remove the Windows preferences capplet now? Isn't better wait for availability of tweak ui tool? If you really think it doesn't fit, you could simply hide the launcher. Yes, we should remove it now - or years ago actually. There are a number of reasons why I don't think it is right to wait for the availability of a tweak UI tool. * If we don't remove the capplet there is less incentive to create such a tool * We shouldn't assume that such a tool will include this particular set of controls * We should let the demand/market determine whether such a tool is even desired * We shouldn't let these kind of issues hold us back from the providing a good user experience However, I think the proper timing for this kind of changes/removals will be the switch to gnome-shell, keeping the ui that users are accustomed in the meantime. I don't agree at all, obviously. Even in the GNOME 2 panel, this window clutters up our Preferences menu and provides no real value for the overwhelming majority of people. However, since you mention it, one of the very important goals for 2.28 is to be a baseline system for testing the Shell. Keep in mind that the Windows menu is tied to features of the old metacity that may not even be relevant for mutter. And even if they are they are certainly not the type of thing we'd want to show as a toplevel control center feature. I mean, look at the options in that dialog. They are for tweakers. Let's remove it. Thanks, Jon ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
В Вск, 23/08/2009 в 10:40 -0400, William Jon McCann пишет: Hi, On Sun, Aug 23, 2009 at 6:06 AM, Luca Ferrettielle@libero.it wrote: Il giorno dom, 23/08/2009 alle 08.44 +0200, Frederic Peters ha scritto: William Jon McCann wrote: http://bugzilla.gnome.org/show_bug.cgi?id=592759 So, how about it? I promise they make the user experience better. Are you proposing to remove the Windows preferences capplet now? Isn't better wait for availability of tweak ui tool? If you really think it doesn't fit, you could simply hide the launcher. Yes, we should remove it now - or years ago actually. There are a number of reasons why I don't think it is right to wait for the availability of a tweak UI tool. * If we don't remove the capplet there is less incentive to create such a tool * We shouldn't assume that such a tool will include this particular set of controls * We should let the demand/market determine whether such a tool is even desired * We shouldn't let these kind of issues hold us back from the providing a good user experience However, I think the proper timing for this kind of changes/removals will be the switch to gnome-shell, keeping the ui that users are accustomed in the meantime. I don't agree at all, obviously. Even in the GNOME 2 panel, this window clutters up our Preferences menu and provides no real value for the overwhelming majority of people. However, since you mention it, one of the very important goals for 2.28 is to be a baseline system for testing the Shell. Keep in mind that the Windows menu is tied to features of the old metacity that may not even be relevant for mutter. And even if they are they are certainly not the type of thing we'd want to show as a toplevel control center feature. I mean, look at the options in that dialog. They are for tweakers. Let's remove it. It looks like it's a wrong mailing list (whatever of those in Cc) to discuss such things. Anyway, I'm strongly against removing this capplet. I need at least two things in it (and I don't think they are 'advanced' settings): focus-follows-mouse checkbox and a modifier key for window manipulations. That's my personal opinion, however. -- Alexey Ktirf Rusakov GNOME Project ALT Linux Team signature.asc Description: Эта часть сообщения подписана цифровой подписью ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
Adding descriptions for the benefit of people who don't want to sift through bugzilla or aren't comfortable reading patches. On Sun, 2009-08-23 at 08:44 +0200, Frederic Peters wrote: William Jon McCann wrote: There are a few changes we'd like to make to the control center before the string freeze. Some of these involve UI changes as well. So, according to http://live.gnome.org/TwoPointTwentyseven we need approval. http://bugzilla.gnome.org/show_bug.cgi?id=323323 On the Appearance preferences, adds link Get more themes online to the Theme tab, and adds link Get more backgrounds online to the Background tab. These point to art.gnome.org. OK by me. http://bugzilla.gnome.org/show_bug.cgi?id=591375 Puts a nice decoration on slideshow background images. See the screenshot from Matthias: http://bugzilla-attachments.gnome.org/attachment.cgi?id=140666 I didn't even know we have slideshow backgrounds. The User Guide doesn't even mention these anyway. No reason to block something that makes an already undocumented feature more intuitive. http://bugzilla.gnome.org/show_bug.cgi?id=592510 On the Background tab, makes the Add and Remove buttons the same size. I'm not quibbling over these kinds of changes. http://bugzilla.gnome.org/show_bug.cgi?id=592756 This proposes removing the Interface tab. This removes from the user the options to show icons in menus, enable editable menu shortcut keys, and change the toolbar button label style. http://bugzilla.gnome.org/show_bug.cgi?id=592759 This proposes removing the Window Preferences tool. This removes from the ability to use point-to-focus, change the titlebar double-click action, and change the window movement key. So, how about it? I promise they make the user experience better. I'll look at them later today (or tomorrow), CC'ing the documentation list for eventual input, and the translators for possible string changes. The first three are fine by me. The last two are much more substantive and would require documentation work. On a personal level, I'm not fond of making window shading even more difficult to find. How do you know that these make the user experience better? Do you have any data on how many users use these features? I know of at least one piece of commercial software that uses Alt+click for its own purposes. They have to instruct GNOME users to change the window movement key to use that feature. You'll be making their troubleshooting docs harder. I'm not saying we need to include every configuration option under the sun. But you need some sort of criteria for deciding whether to remove something. And it really seems like people are using I don't use it as their sole criterion, which just isn't good enough. -- Shaun ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
Hi, On Sun, Aug 23, 2009 at 12:48 PM, Shaun McCancesha...@gnome.org wrote: ... The first three are fine by me. The last two are much more substantive and would require documentation work. On a personal level, I'm not fond of making window shading even more difficult to find. How do you know that these make the user experience better? Do you have any data on how many users use these features? You are welcome to do a study to see if people need the options in the window capplet. I know what you'll find if you ask the right people: What is window shading? But this isn't the point. The point is figuring out what kind of experience we want to provide - and then executing on it. The way we design our interfaces and the interfaces that we to provide say everything about what we value. If we show options for tweaking window management settings then we are saying that we think tweaking window management settings is something that you *should* do. This is especially true when the tool is a first class preference dialog - on the same level as sound, appearance, displays, etc. The same goes for the Interface tab. It is clearly not the story we want to be telling. Also, as mentioned in another message, the window preferences is strictly a metacity tweak tool. It doesn't apply to other window managers. Perhaps if someone really wants it they can move it to the metacity module as an optional tool. Otherwise, it doesn't belong in control center. I know of at least one piece of commercial software that uses Alt+click for its own purposes. They have to instruct GNOME users to change the window movement key to use that feature. You'll be making their troubleshooting docs harder. Well, I can't really respond to this without particulars. But it doesn't sound like a good reason to me. I'm not saying we need to include every configuration option under the sun. But you need some sort of criteria for deciding whether to remove something. And it really seems like people are using I don't use it as their sole criterion, which just isn't good enough. Not at all. What people are you referring to? I don't know anyone who is thinking about this as shallowly as you suggest. My concern isn't about whether I use it or not. As I said above, it is about what story we are trying to tell, the experience we want to provide, and about how we show our values. This capplet and tab are poor design decisions - and need to go. Jon ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
Il giorno dom, 23/08/2009 alle 10.40 -0400, William Jon McCann ha scritto: * We should let the demand/market determine whether such a tool is even desired William, we are not speaking about a feature like let me change the theme to show my friends how cool is my pc that anyone expects from a desktop environment. The kind of feature that, if you remove it, people will track you to use tickle torture :D Windows capplet is the perfect example of a tool that exposed (somewhere) in the UI is a way for users to learn what GNOME can do. Asking yourself What does this ui item? is a good starting point to explore the capabilities of GNOME, even if it's something that you will use only once in your lifetime. Rarely used options aren't useless options. Exaggerating and going politically incorrect, we could move all a11y related UI to gconf 'cause there are not so much people that use them. If we stick those stuff in gconf, only GNOME developers, translators and documenters will know that you can, for example, shade a window. As a side note, in my experience with other GNOME users, it seems that a common desire[1] about window management is the ability to close a window double-clicking on the icon in title bar. This case makes me think about: * the demand may be wrong * the demand may stay unimplemented However, since you mention it, one of the very important goals for 2.28 is to be a baseline system for testing the Shell. Keep in mind that the Windows menu is tied to features of the old metacity that may not even be relevant for mutter. If we are planning to remove those features moving from metacity to mutter, then another solution could be move the Windows capplet in metacity source tree. [1] desire, maybe non exposed in form of bug reports: users sometimes are lazy in bug reporting, but grumble when they know you are a GNOME contributor :) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
On Sun, 2009-08-23 at 13:23 -0400, William Jon McCann wrote: Hi, On Sun, Aug 23, 2009 at 12:48 PM, Shaun McCancesha...@gnome.org wrote: ... The first three are fine by me. The last two are much more substantive and would require documentation work. On a personal level, I'm not fond of making window shading even more difficult to find. How do you know that these make the user experience better? Do you have any data on how many users use these features? You are welcome to do a study to see if people need the options in the window capplet. I know what you'll find if you ask the right people: What is window shading? But this isn't the point. The point is figuring out what kind of experience we want to provide - and then executing on it. The way we design our interfaces and the interfaces that we to provide say everything about what we value. If we show options for tweaking window management settings then we are saying that we think tweaking window management settings is something that you *should* do. This is especially true when the tool is a first class preference dialog - on the same level as sound, appearance, displays, etc. It's not always what users *should* do. Sometimes it's just what users *need* to do. Do users need to select whether or not there are icons in menus? Almost certainly not. Do they need to tell the window manager to stop stealing Alt+click? Yes, there are users who need to do this to make effective use of the software they use. And who exactly is we? I think maximizing windows is a terrible way to work, and that minimizing is by far inferior to shading. So if I'm allowed to be a part of the we that decides what kind of experience we want to provide, then yes, I do want to encourage people to use window shading. The same goes for the Interface tab. It is clearly not the story we want to be telling. Also, as mentioned in another message, the window preferences is strictly a metacity tweak tool. It doesn't apply to other window managers. Perhaps if someone really wants it they can move it to the metacity module as an optional tool. Otherwise, it doesn't belong in control center. This paragraph doesn't really fit in with the rest of your argument. Throughout the rest of the email you talk about deciding on what experience we want to provide. And yet here you use window manager swapping as an argument. Is swapping out your window manager really an experience we want to promote? I know of at least one piece of commercial software that uses Alt+click for its own purposes. They have to instruct GNOME users to change the window movement key to use that feature. You'll be making their troubleshooting docs harder. Well, I can't really respond to this without particulars. But it doesn't sound like a good reason to me. People don't use computers to look at their desktops. If we don't care about the problems people have when running third-party software, well, we have a problem. The program I was referring to is Mathematica, but after a cursory Googling, I've found people having the same issue with a number of other programs. So, OK, tell everybody that the desktop owns Alt+click and those programs are broken, right? Except most of these programs aren't targetting Gnome. Figuring this stuff out as an ISD when your software might be run under $deity-knows-how-many window managers is pretty much impossible. I'm not saying we need to include every configuration option under the sun. But you need some sort of criteria for deciding whether to remove something. And it really seems like people are using I don't use it as their sole criterion, which just isn't good enough. Not at all. What people are you referring to? I don't know anyone who is thinking about this as shallowly as you suggest. My concern isn't about whether I use it or not. As I said above, it is about what story we are trying to tell, the experience we want to provide, and about how we show our values. This capplet and tab are poor design decisions - and need to go. OK, I apologize for mischaracterizing your argument. I should have asked for your reasoning first. Nonetheless, I don't see that anybody has actually looked into the impact of these changes have on users. Furthermore, we have interface freezes for a reason. These are substantial changes to the user experience that require us to modify the documentation. It's not just a matter of removing content. Since nobody else is looking at the user impact, we'll have to look at each of the options being removed, decide whether we're introducing stumbling blocks for a substantial number of users, and if necessary write considerably more complicated instructions. -- Shaun ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
Hey, On Sun, Aug 23, 2009 at 4:52 PM, Shaun McCancesha...@gnome.org wrote: On Sun, 2009-08-23 at 13:23 -0400, William Jon McCann wrote: Hi, On Sun, Aug 23, 2009 at 12:48 PM, Shaun McCancesha...@gnome.org wrote: ... The first three are fine by me. The last two are much more substantive and would require documentation work. On a personal level, I'm not fond of making window shading even more difficult to find. How do you know that these make the user experience better? Do you have any data on how many users use these features? You are welcome to do a study to see if people need the options in the window capplet. I know what you'll find if you ask the right people: What is window shading? But this isn't the point. The point is figuring out what kind of experience we want to provide - and then executing on it. The way we design our interfaces and the interfaces that we to provide say everything about what we value. If we show options for tweaking window management settings then we are saying that we think tweaking window management settings is something that you *should* do. This is especially true when the tool is a first class preference dialog - on the same level as sound, appearance, displays, etc. It's not always what users *should* do. Sometimes it's just what users *need* to do. Do users need to select whether or not there are icons in menus? Almost certainly not. Do they need to tell the window manager to stop stealing Alt+click? Yes, there are users who need to do this to make effective use of the software they use. And who exactly is we? I think maximizing windows is a terrible way to work, and that minimizing is by far inferior to shading. So if I'm allowed to be a part of the we that decides what kind of experience we want to provide, then yes, I do want to encourage people to use window shading. Ok, so we're down to discussing two features in particular. Alt+Click and Window shading. Right? If alt+click is as problematic as you suggest then perhaps we are wrong to rely on that as something that can be owned by the window manager. It is just not acceptable to require that users tweak this shit for that reason. It if exactly because we haven't standardized this kind of thing - and allow customization of basically all hotkeys - that we find ourselves in this situation. We can't tell a story to ISVs. All other platforms that I know of have reserved hotkeys. Also, I don't find it very interesting to try to work around proprietary applications that don't attempt to fit into our platform. And for our part we need to do better to provide a saner platform. Window shading is a really geeky feature. I am asserting that it is not what we want to promote. It is totally fine for you to use it of course. And you may end up being the one motivated to write the tweak UI tool that exposes this functionality graphically. If you feel that we should be promoting window shading then I think the burden of proof is on you. The same goes for the Interface tab. It is clearly not the story we want to be telling. Also, as mentioned in another message, the window preferences is strictly a metacity tweak tool. It doesn't apply to other window managers. Perhaps if someone really wants it they can move it to the metacity module as an optional tool. Otherwise, it doesn't belong in control center. This paragraph doesn't really fit in with the rest of your argument. Throughout the rest of the email you talk about deciding on what experience we want to provide. And yet here you use window manager swapping as an argument. Is swapping out your window manager really an experience we want to promote? GNOME Shell is built on mutter. Which is a diverging fork of metacity. For 2.28 (as an alpha/testbed for 3.0) we are going to support switching between metacity and gnome-shell/mutter. Yes. It is an open question if we will continue to support all the crazy options in metacity. I know of at least one piece of commercial software that uses Alt+click for its own purposes. They have to instruct GNOME users to change the window movement key to use that feature. You'll be making their troubleshooting docs harder. Well, I can't really respond to this without particulars. But it doesn't sound like a good reason to me. People don't use computers to look at their desktops. If we don't care about the problems people have when running third-party software, well, we have a problem. The program I was referring to is Mathematica, but after a cursory Googling, I've found people having the same issue with a number of other programs. So, OK, tell everybody that the desktop owns Alt+click and those programs are broken, right? Except most of these programs aren't targetting Gnome. Figuring this stuff out as an ISD when your software might be run under $deity-knows-how-many window managers is pretty much impossible. Very much
Re: UI changes for control-center
On Sun, 2009-08-23 at 17:24 -0400, William Jon McCann wrote: Hey, On Sun, Aug 23, 2009 at 4:52 PM, Shaun McCancesha...@gnome.org wrote: On Sun, 2009-08-23 at 13:23 -0400, William Jon McCann wrote: Hi, On Sun, Aug 23, 2009 at 12:48 PM, Shaun McCancesha...@gnome.org wrote: ... The first three are fine by me. The last two are much more substantive and would require documentation work. On a personal level, I'm not fond of making window shading even more difficult to find. How do you know that these make the user experience better? Do you have any data on how many users use these features? You are welcome to do a study to see if people need the options in the window capplet. I know what you'll find if you ask the right people: What is window shading? But this isn't the point. The point is figuring out what kind of experience we want to provide - and then executing on it. The way we design our interfaces and the interfaces that we to provide say everything about what we value. If we show options for tweaking window management settings then we are saying that we think tweaking window management settings is something that you *should* do. This is especially true when the tool is a first class preference dialog - on the same level as sound, appearance, displays, etc. It's not always what users *should* do. Sometimes it's just what users *need* to do. Do users need to select whether or not there are icons in menus? Almost certainly not. Do they need to tell the window manager to stop stealing Alt+click? Yes, there are users who need to do this to make effective use of the software they use. And who exactly is we? I think maximizing windows is a terrible way to work, and that minimizing is by far inferior to shading. So if I'm allowed to be a part of the we that decides what kind of experience we want to provide, then yes, I do want to encourage people to use window shading. Ok, so we're down to discussing two features in particular. Alt+Click and Window shading. Right? Those are the two that I had something to say about. There are people who still love sloppy focus. I'm not necessarily saying we need to design for them. But it's something to take into consideration. If alt+click is as problematic as you suggest then perhaps we are wrong to rely on that as something that can be owned by the window manager. It is just not acceptable to require that users tweak this shit for that reason. It if exactly because we haven't standardized this kind of thing - and allow customization of basically all hotkeys - that we find ourselves in this situation. We can't tell a story to ISVs. All other platforms that I know of have reserved hotkeys. Also, I don't find it very interesting to try to work around proprietary applications that don't attempt to fit into our platform. And for our part we need to do better to provide a saner platform. So, yeah, I totally agree we're in a sucky situation here. Windows and Mac both reserve certain things for the desktop, and ISDs know that and deal with it. The tight spot we find ourselves in is that most ISDs aren't going to target Gnome or KDE or XFCE. We're lucky when they target the Linux desktop at all. And because Gnome and KDE each reserve different things for the desktop, those ISDs find themselves pretty much SOL. It's a hard situation. I'm not putting the blame on us, and I'm not putting the blame on ISDs. It's just one of the many difficulties that we've all inherited. And if we can solve that difficulty once and for all, frickin' awesome. But if we can't (or we just haven't yet), then workarounds are just a fact of life. Window shading is a really geeky feature. I am asserting that it is not what we want to promote. It is totally fine for you to use it of course. And you may end up being the one motivated to write the tweak UI tool that exposes this functionality graphically. If you feel that we should be promoting window shading then I think the burden of proof is on you. It's only a geeky feature because we've relegated it to the dark geeks-only shadows. There's nothing about minimizing that's inherently more intuitive than shading. It's just what people are used to because Microsoft Windows has 90+% of the desktop market share. Before OS X, Mac used window shading. And I don't think Mac is a particularly geeky desktop. The same goes for the Interface tab. It is clearly not the story we want to be telling. Also, as mentioned in another message, the window preferences is strictly a metacity tweak tool. It doesn't apply to other window managers. Perhaps if someone really wants it they can move it to the metacity module as an optional tool. Otherwise, it doesn't belong in control center. This paragraph doesn't really fit in with the rest of your argument. Throughout the rest of the email you talk about
Re: UI changes for control-center
On Sun, Aug 23, 2009 at 6:07 PM, Shaun McCancesha...@gnome.org wrote: I agree that these proprietary applications are going to have to change their docs. And we will have to change some docs in GNOME too. Which docs in particular do you think need to be changed? If this is going to be a problem then I'll update the docs too. Is that necessary? For starters, the relevant sections in the User Guide. And then other material needs to be audited. And we have to analyze the user impact to see if we need to add troubleshooting docs. I can't just tell you exactly what needs to be edited, because that's the hard part. Typing words is a pretty small part of writing. Deciding what needs to be written is where the real work is. Looking over the user guide, there are sections Configuring Your Desktop Look and Feel Appearance Preferences Interface Preferences and Configuring Your Desktop Look and Feel Windows Preferences which will have to be axed along with the UI they describe. And then there is this sentence: You can also press-and-hold Alt and drag any part of the window. in the section Desktop Overview Windows Manipulating Windows. Worth pointing out that it is already a half-truth, since the current UI makes the modifier configurable, which should be mentioned here. My suggestion for Alt-click is to turn it off by default, since it seems to cause problems for some apps, and the functionality is available via the window menu anyway. Matthias ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
