Re: UI changes for control-center

[Shaun McCance <shaunm gnome org>]

On Sun, 2009-08-23 at 17:24 -0400, William Jon McCann wrote:
> 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?

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

Why are we allowing that?  Is it just as a workaround for
the fact that some people just won't have the hardware to
run Mutter?

Regardless, we control both window managers, and if we want
to expose window management options, we can make sure they
both respect them.

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

With respect to Alt+click, a good first step would be talking
to KDE to come to an agreement about which keybindings and
such desktops should assume control of.

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

Sorry, I'm just not seeing it.  You didn't seem to be aware
of the reason why people change their window management
modifier key.  All right, so I happen to have particularly
special knowledge of the one application I pointed out.
But I found plenty of others by Googling "alt click gnome".
Did anybody else Google that?

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

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

If by "bikeshedding" you mean "input from the community".
I mean, if you're going to talk about what "we" want to
promote, you should talk to the community.

But, fine.  You don't have to convince me.  All you need
is approval from the release team.  They ask for my input
as a courtesy.

--
Shaun