[Desktop_architects] Printing dialog and GNOME

Havoc Pennington hp at pobox.com
Tue Dec 13 23:14:30 PST 2005


Hi,

Yay, discussion is looking more useful ;-)

Here's an applicable article to much of what you're saying:
  http://www.gnomejournal.org/article/5/experimental-culture

That article tries to imagine a path that's neither "a fun project by
and for developers, but sucky for everyone else" nor "a kind of boring
same-old project," in part by wondering if we can find a way to try
lots of stuff without necessarily _shipping_ all of it.

How to get there in practice, I don't know.

On 12/13/05, Linus Torvalds <torvalds at osdl.org> wrote:
> I don't understand why you and Havoc seem to be of the opinion that
> working well out of the box and having good defaults is in any way
> something I argue against.

For me, it's just that I don't think you're 100% right here:

> So you can have your cake and eat it too. It's not an either-or thing.

That just doesn't match my experience. I'm not saying it can't be
done, but in terms of desktop stuff I've seen, it's always seemed to
be a tradeoff, for a variety of reasons.

Firefox is maybe the best example of escaping the tradeoff I can come
up with. I don't have a lot of insights into how it came to be and
what their process is.

> But _indirectly_, the thing that open source really excels at, is the
> flexibility it offers thanks to having lots of users, and lots of users
> whose needs get _heard_.

My view on this would be that in an open source project, absent some
outside force (such as the maintainer or the project culture) the
needs of technical users get heard, but the needs of most other kinds
of users do not. You get a "GNOME 1.4" kind of product. Thus if the
goal of a project is primarily about some subset of nontechnical
users, you need to find a way to stay out of the "by and for
developers" problem - there are probably several ways.

> THAT is the core of open source. You've got
> different kinds of people that get attached to a project. It's _not_ a
> corporate mono-culture, because people from different backgrounds can get
> together and work on it _without_ going through the corporate mind-wash.

BTW I really don't think the design/usability stuff is corporate at
all; it's counter to most of the corporate interests on this list and
elsewhere, and many companies have "by and for developers" as a strong
de facto reality, just like open source projects.

"By and for developers" by the way is better than some popular
alternatives in the proprietary world, like "by incompetent developers
for nobody-knows-who" ;-) and this does give open source a certain
baseline that's better than average. But it's not enough to compete
with the best examples of consumer products, even though it's perfect
for designing and implementing web servers and IDEs and that sort of
thing.

> And to me, gnome is killing itself as an open source project, because it
> ends up dismissing exactly that thing.

I don't think oscillating back to the previous extreme is going to be
progress; to get anywhere, we need to find the "best of both worlds"
kind of setup.

> Having strict UI rules ("The HID
> says so-and-so") that are really a religion that you're not allowed to
> question.

I sit in the same office as Bryan Clark (one of the HIG authors), and
last week he was complaining about zealots quoting the HIG back at him
without knowing he wrote it.

The "G" is for Guidelines, and really, the HIG is just cosmetics
anyhow. You could not use the HIG to design something like the print
dialog, other than the uninteresting parts like how much spacing
between labels. A HIG-type document addresses UI consistency, but it
doesn't address the design questions for a particular new capability.
What printing-related stuff is there, how does it work, what does it
let people do; the HIG isn't going to cover that. It's not a design
algorithm.

> And I think that's important. It's important, because that developer
> energy, in the end, is what get things done. And as a side effect, you
> will automatically end up with a system that understands that defaults may
> be good, but that different people have different needs and views. Because
> you had a very diverse group of people that worked on it.

Here I just don't agree. Programmers as a group are very possible to
distinguish statistically from the general population: introverted,
male, for starters. Open source programmers are even more skewed away
from the general population than programmers as a whole.

But while that could be arguable, programmers are *definitely* very
different if you start measuring how and why they use computers. For
example, they will almost all be shell users, and shell users have a
lot of special expectations and mental models.

So while sure you have some geographic diversity and other kinds among
developers, I don't think you have diversity on some of the important
dimensions.

> This, btw, is also why a "enterprise desktop" should never be allowed to
> drive development. It is, by definition, boring and same-old, same-old.

Concur completely. Same-old same-old is the best case, it can get worse.

I don't think the usability/design stuff in open source has been about
enterprise; it's been in conflict with the enterprise-ish nature of
Red Hat and Novell most of the time.

> And if you don't see the parallels with "enterprise UNIX" and "Linux"
> here, I think you're blind. The thing is, Linux (the kernel) got better
> than just about any enterprise Unix kernel _not_ by trying to develop
> itself for the enterprise, but by allowing and encouraging different kinds
> of people to all scratch their own itch.

The kernel on my (admittedly old) laptop is a good example of
something that works for a developer like me, but isn't usable by a
nondeveloper who can't scratch their own itch.

The wireless card gets wedged if you do certain things "too fast" (I'm
really not sure exactly), in any case it never happens if you just use
the command line, but almost always happens if you use a GUI for
wireless networking.

The suspend used to require mucking with grub to disable ACPI, and now
that Fedora seems to have yanked APM, you have to go in and manually
configure hibernate rather than suspend, then avoid clicking on the
"suspend" menu item since it crashes the system.

In both cases it works fine for me, and indeed anyone capable of
coding a patch could also use my workarounds, but it's entirely
unusable for a lot of people.

This is the kind of stuff I think needs fixing by developers, for
someone who isn't a developer. Maybe that requires paid development,
but if it does it does.

> Yeah, the whole development process is a bit more chaotic, and maybe a bit
> more "cluttered" and even scary, but the end result is BETTER. And yes,
> Linux (the kernel) has a million drivers that the "serious guys" don't
> care for. But that wild and crazy thing is exactly what made Linux a
> success in the first place.

I would say drivers are more analogous to firefox extensions or "third
party" GNOME apps. The analogy to a typical GNOME feature would be a
new feature in the kernel core or at least a major subsystem. By
reputation you guys are relatively picky about those, but I don't know
firsthand.

> Thinking that developers should also have to be aware or care about the
> crazy UI HID notion of the day is just stupid. It just alienates
> developers. And don't tell me that Gnome as a project hasn't alienated a
> lot of developers, because some of them have been emailing me privately as
> a result of this flamewar.

My point of view is that there _are_ developers who are interested in
doing "by developers for someone else" and who appreciate
design/usability, have bothered to learn something about it via books
or conversation or whatever, and enjoy writing apps that measure up to
what some of the canonical "good design" proprietary companies might
write. There are really quite a few of these developers involved in
GNOME. Alex Graveley who's been posting on this thread is an
interesting designer as well as a developer, in my opinion.

Absolutely, there are people who don't want to work on a project with
that kind of focus, but then there are people who don't want to work
on kernels, or don't want to work on whatever else. Normally you
should choose a project you find interesting.

I'm sure there are people who get alienated for bad reasons that are
GNOME's fault, like someone flamed them or failed to review their
patch (I've done both of those quite a few times sadly).

But I think if you look into a project and find out that its goals
aren't something you're interested in, and get turned off by that,
it's not really a "bug" in the project, just kind of the way it is. If
I don't like a neighborhood, the logical thing is that I don't decide
to live there. Some people would probably start flaming the existing
residents until they changed the neighborhood, but it's weird to do
that, at least where I come from.

I don't think all neighborhoods should be for all people. I guess
that's full circle to one of the first things I had to say in this
thread.

The GNOME tent could probably be bigger, sure. That's what Seth's
article tries to figure out how to do I guess. But again I think it's
about finding the smart path with best of both worlds, not about
oscillating back to past mistakes.

Havoc




More information about the Desktop_architects mailing list