Re: UI changes for control-center

[William Jon McCann <william jon mccann gmail com>]

Hey,

On Sun, Aug 23, 2009 at 4:52 PM, Shaun McCance<shaunm 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 McCance<shaunm 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 agree that we're not telling a good story here.  We suck.
Optional, inconsistent, and customizable behavior has a tremendous
cost that isn't immediately obvious.

We're hopefully going to do this better as time goes on.  This
proposal is just the first step.

>> > 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.

Again you are assuming that no one is thinking of the impact of these
changes.  Which isn't correct.  As noted above, there are

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?

But really this approval process shouldn't turn into a massive
bikeshedding event.

Thanks,
Jon