Havoc's Blog

If you write an application or a dialog called “____________ Manager,”
be sure it’s called that because your software does the
managing. Imagine a bookshelf and a disorganized pile of books, and
you get to pick them up and alphabetize them yourself. In software
this would be called a “book manager.” In real life it’s called “my
house” and I never get around to the picking up, let alone the
alphabetizing …

I see lots of software feature lists and marketing materials with
these bullet points:

• Manage your music
• Manage your photos
• Manage your account
• Manage your plugins

If you must do this at least think of the feature as “organize.” That
provides some kind of design direction beyond “let people manually
move crap around.” But I might suggest that what your users really
want to do with music (for example) is listen to it, not manage it.

(The file manager and window manager are some of the oldest and worst
offenders, but no need to copy them in new designs. The web, at least
some PDAs, some cell phones, TiVo… lots of non-desktop software
avoids file and window management hell.)

(This post was originally found at http://log.ometer.com/2005–09.html#18)

I’m pretty sure this UI
contest is 100% broken by design. My entry to the contest would be
this mockup (hey, maybe I’d do it in Glade instead of ASCII art if
entering for real):

[ ] Enable anonymous Internet

I could flesh out the spec and show the other state the UI has:

[x] Enable anonymous Internet

There might be some discussion about the exact phrasing of the big
toggle, but that’s about how much UI this thing should have. The
contest is to put a UI on stuff people won’t want to understand, can’t
understand if they wanted to, and shouldn’t have to understand; having
GUI controls rather than text files doesn’t magically make “which
servers I am connected to and how many connections they have”
interesting information. DO NOT CARE. It’s downhill from there in the
list of example features on the contest page.

Reminds me of all the time people have wasted putting UI on SSL and
certificates. If you have to ask the user anything about security, you
have lost. Go back to square one; do not collect $200. Imagine your
dialog has a “don’t care, pick something” button, just do what that
button would do, and lose the silly dialog.

(This post was originally found at http://log.ometer.com/2005–09.html#12)

I just got a paper envelope in snail mail advertising a search engine
listing service. The spammers have reverted to analog…

(This post was originally found at http://log.ometer.com/2005–09.html#6)

The book Built
to Last has a famous discussion of the “Tyranny of the OR,”
pointing out that mediocre companies force themselves to choose short
vs. long term, or values vs. profit, or whatever; while great
companies find a way to do both things at the same time. The desired
state isn’t balance (some values, some profit); but both. Do
both things 100% by coming up with innovative and clever approaches,
don’t trade off one vs. the other.

A cliche computer industry example, perhaps, would be all the search engines
that lazily traded off user experience vs. advertising revenue; while
Google spent the time to figure out how to have better user
experience, and more advertising revenue, at the same time. I
like to think the RHEL/Fedora model Red
Hat arrived at after many years of trial-and-error is a similar kind
of thing; other companies either settled for a “proprietary frosting”
model or failed to become profitable. I won’t try to take a position
on whether Google or Red Hat will (or do) manage to consistently get
it right, but these two examples make sense to me.
Another open source company that seems good at this is
Trolltech.

I don’t really want to talk about the computer industry, though. My
favorite examples (what I really want to blog about) are a couple of
magazines I read, Game Informer and
Entertainment Weekly. Most magazines
about video games or entertainment are terrible, full of fluff
crap, gossip, more ads than content, and unreliable reviews.

These two magazines both have a similar format, which I think of as
the front half and the back half. Before a movie/book/game comes out,
they will do almost-always-positive “preview” articles talking about
why the thing could be good, interviewing the people making it, and
discussing the concept. These articles are fairly advertiser-friendly,
but I think are also what readers want (or at least what I want). I
want to hear why the director or game designer thinks their product
will be exciting, so I can judge for myself. I wouldn’t want some
snarky magazine writer’s opinion at this stage. Everything gets a fair
chance at success. The cover story and cover art normally point to
articles in this “front half.”

Both magazines then have a “back half” consisting of reliable,
well-written reviews that are perfectly willing to be negative. These
appear “just in time” when the movie, book, or game comes out. Often
the same product appears in the “front half” first and then “back
half” in the following issue. The magazines both seem to avoid putting
a preview and a review of the same product in the same issue if they
can help it.

The magazines even have a similar tone, with a lot of humor and a
level of intelligence somewhat above e.g. the Boston Globe or
Associated Press movie/book reviews, but less pretentious than the New
York Times or Time Magazine reviews. And they have readable graphic
design, vs. the our-Quark-XPress-person-is-on-acid train wrecks you can
find on the newsstand. Finally, they tend to cover all products, not
only blockbusters or only independent/artsy stuff.

The upshot is that these magazines appeal to a wide audience, they are
advertiser-friendly AND reliable advisers, both fun to read AND smart.
To me that makes them great role models.

(This post was originally found at http://log.ometer.com/2005–08.html#27)

Sign in Oakland airport:

Attention customers: Our Italian sodas are made with Sprite.

(This post was originally found at http://log.ometer.com/2005–08.html#22)

Occasionally I check in on Internet Explorer, and I always notice that
when you open a new window it displays the same page in the new window
that you had open in the previous window. I’m pretty sure this is the
only page on the Internet that I could not possibly want to see in
the new window, since I already had it open. A search box or blank
page would be a much better guess. Epiphany and Firefox both get it right.

(This post was originally found at http://log.ometer.com/2005–08.html#17)

I haven’t thought about a canvas widget too often in the last couple
years, but when I did it was along the lines of “well, most apps
stopped using GnomeCanvas, so I’m not sure an official GTK+ canvas is
important.” This weekend I looked into it a bit and wrote
up some notes. Now I think a canvas could be huge, if done
properly with a focus on the right kinds of high-level features.

(This post was originally found at http://log.ometer.com/2005–08.html#15)

Jeff, what isn’t clear to me I guess is what structure or process do
you want? As I see it, it isn’t very complicated; there are designers,
and you work with them collaboratively to figure out how to approach a
problem and implement it. A variety of apps and features have been
approached this way, such as Epiphany, Evince, file selector,
NetworkManager, Sabayon, some of the Google Summer of Code stuff,
Yarrr, etc. The good design examples that got implemented have
involved solid one-on-one communication between the designers and
coders. So the process is just that, find a competent designer and
work with them. Perhaps we should state this officially somewhere and
kind of map out how a typical collaboration would go, with some
examples.

There are examples of developers who have done good designs on their
own, too; some people are OK at this and some are not. The real
problem is people who are not but don’t realize it, of course. 😉
At least 90% of us really are not OK at it in my view, unsurprising
since it’s a full-time career and so is programming.

I don’t believe that design can be done by committee or on a mailing
list. 2–3 designers in person with a whiteboard can maybe work, but 20
people on a list is just a train wreck. Especially when 15 of the 20
don’t have a clue in the world (25% with a clue is optimistic, too).

Maybe we also need to spell out the distinction between design and
usability. The rough process I would say:

Design -> Code and Design Iterations   -> Usability Testing and Polish
             (coder comes to design team
              as issues become apparent;
              everyone learns from users
              with release-early-and-often)

The purpose of design is the “what is it?” question. Netapplet
vs. NetworkManager. Sabayon vs. KDE Kiosk Tool. Those examples are on
a whole-app level, but the same “what is it?” question also comes up
with each smaller aspect of an app. See the lightbulb joke.

Bryan and Seth at least tend to focus on projects where they can have
a large impact, vs. say running around CVS pointing out that
gnome-system-monitor thinks that Mebibyte is a
reasonable choice of words. In their place I have to say I’d do the
same, as bugzilla is full of “how to word this dialog” questions and
it’s just higher-impact to focus on the “what does the desktop do?”
questions. I agree with Seth’s
argument on that point.

Also, obviously, the design guys tend to work with really helpful
developers such as Marco or Dan before they work with some of the
shall-remain-unnamed not-so-helpful developers. Seems pretty sensible,
nobody likes banging their head on immovable objects.

(This post was originally found at http://log.ometer.com/2005–08.html#13)

Jeff,
Bryan and Seth were both at least a “design team” prior to
working at Red Hat and have continued to work in the same way while
working at Red Hat, so my view is you should leave corporate names out
of it and just talk about people if you want to talk about people. I
don’t know if they are the “official” design team or not, but they are
definitely (with Calum) the authors of the HIG and AFAIK the only
people involved in GNOME who can claim to have substantial interaction
design training and experience.

But really it’s immaterial what is on their diploma and resume. The
fact is that they are good at this, just as the rest of us are good at
the work that we do. And Bryan’s design for notification is a good one
and he posted it openly at some considerable expenditure of his time.
This was not posted at Red Hat’s request. Neither was Colin’s post or
John’s. These guys have been trying to engage in an open discussion on
how notifications should be done, which I don’t quite parse as an
example of “closed development.”

To me this is an example of open discussion and (while I haven’t
asked) my guess is that Bryan posted his notification design even
though he assumed it would be a waste of time since he’d have to get
in silly flamefests about it and people would just implement some
random, bottom-up thing anyhow. I’d guess that Seth would not have
spent time on a design for that reason, and GNOME is mostly proving
his point at the moment so he’ll probably taunt Bryan on Monday and
they will both return to working on projects where the developers
listen to them.

If people don’t appreciate the value of design skills and take
advantage of them then GNOME (and Linux) are hosed. I find
well-designed Evince for example just unquestionably, definitively
superior to other similar efforts on Linux. Some people will disagree
but then, dozens of people disagree with the coding decisions I make,
and I’m taking feedback but I’m not taking a
poll. That’s because I want a successful project, not an
everyone-gets-a-vote project.

There’s the criticism one could make that design is telling other people
how to do the work without doing the work. Two points here. First,
this claim implies that design and usability don’t count as work,
which is bullshit; if done competently they require quite a bit of
work. Second, nobody is stopping anyone from doing the work the way
they want. Go for it. Open source lets you. However, for many
developers their no-design-input work is going to suck and I for one
won’t have qualms about pointing that out.

My personal view is that it should not be the job of GNOME’s designers
(whoever they are) to go around finding and arguing away every wrong
direction. Instead, programmers should be actively seeking the right
design before they type in a load of irrelevant code and specs.

On to your general point about closed company discussions. I half
agree and half don’t. NetworkManager as far as I can remember has been
in GNOME CVS virtually from day 1. I don’t know when Dan moved it from
his hard drive to CVS, but I know from the logs it was in CVS before
it worked at all, over a year ago.

You refer to the “netapplet/NetworkManager debacle,” which I guess
means debate over which to use or which was right. I posted to GNOME
lists numerous times arguing for the NetworkManager approach
(specifically in the context of gnome-system-tools, IIRC). This was
debated quite a bit. And when we started doing it the IMO right way,
it was in CVS the whole time. netapplet and NetworkManager are
entirely different and there was no meaningful code that could have
been shared between them. That’s why you have to design first
and write code second, because design is about what to write
not how to write it.

I didn’t really see a lot of debacle here to be honest. It seems like
NetworkManager is agreed to be the right approach and everyone is
working on it and I never saw any huge flamewar or anything. Maybe
someone is quietly pissed off and I just don’t know about it, I don’t
know.

So I don’t know what the problem is, in some ways. Similarly for
e.g. Sabayon — it’s in CVS and always has been. Gamin — it’s in CVS
and always has been. Yarrr — ditto. X.org/Cairo/Luminocity — ditto. We
make web sites and mailing lists for this stuff and use them. What is
the big secret non-public project you think we are working on?

I said I half agree and half don’t. The half I agree with is that yes
you aren’t seeing a high level of engagement from Red Hat and Novell
on the core GNOME pieces. I think there are a few explanations.
First, we are largely working on surrounding pieces that need more
work. For example HAL and X.org rather than gnome-panel. Second,
people sharing a hallway naturally have hallway
conversations. However, with 1/3 of our desktop team remote this is a
problem for us as well as GNOME, and we do not have an internal
technical list. (We do have internal IRC, and some people like me have
dropped off external IRC due to lack of time. Though, I have always
gone through IRC-absent periods in the 7 years I’ve done GNOME stuff.)
Third, the language split is leading to multiple projects in the same
category. Fourth, the companies are just working on different things
because they have pretty different ideas on what the priorities are,
so they aren’t having to talk to each other too much. I’m not just
saying Red Hat and Novell here; also Canonical and IBM and others.

On the projects that do overlap, it seems to me the
communication and openness is pretty good, e.g. on HAL, X.org, and so
forth. Or even notification systems since there is currently a lively
discussion and I’m pretty sure I’ve seen it discussed in the past too.

(This post was originally found at http://log.ometer.com/2005–08.html#13.2)

Led by the fearless jrb and the
Gazpacho team, a bunch of us sat down to hack on Gazpacho today.

My only useful accomplishment was a hack to allow toplevel windows to
be displayed on a “work table,” like so, rather
than the old Glade-style standalone windows. It shows
how mature pygtk is that you can do scary not-really-allowed gtk hacks
with it.

Then we spent some time talking about how to rework the layout of the
app, yarrr
whiteboard with a proposal (double-click the whiteboard thumbnail
so it’s large enough to see).

The delta from current Gazpacho would be:

• Move the widgets being edited into the main window, on a big “work
  table” — so there’s a single “document” that all your widgets live
  on. You can just drop widgets on the work table, not everything has to
  be a toplevel window. This area is scrolled if it gets too big.
• Remove the toolbar because none of the operations there are very
  common anyway, or they are normally accessed via keyboard shortcut.
• For the widget tree, drop the notebook and move the Actions tab
  into its own toplevel accessed from the menus.
• Put the widget tree on the left, the palette on the right, and the
  property sheet on the bottom. The “work table” is in the middle.
• Change the property sheet to have only the top 5–10 common
  settings for the widget, and then some way to open a window
  with the complete 4‑tab list of every possible property. This removes
  another set of notebook tabs and keeps the property sheet smaller.
• Remove the “Selector” button if possible, instead could just press
  Escape to revert to Selector mode. If the button remains it should
  always toggle between Selector and last-used widget, right now it has
  a state where it becomes a no-op.
• Widget tree should maybe be collapsible, the palette and property
  editor maybe not since you can’t do much without it.

There’s a similar single-window
proposal already, the differences we came up with were to put the
property sheet on the bottom and palette on the right, drop the
Selector button, and use a single “work table” in place of an MDI tab
per-widget. Also dropping the toolbar and doing the reduced “most
useful items” property sheet while hiding the full property sheet.

With our proposal the default Gazpacho screen would be mostly occupied
by the work area, the only visible items with widget tree collapsed
would be palette, 5–10 property sheet items, and menubar.

Some other Gazpacho
suggestions to read here.

I think an essential element of “nice feel” would be good design to
the “work area”/“work table” widget. It needs to be easy to drag a
child widget out onto the work table to temporarily remove it from a
layout, then drag it back to your layout later. Each widget should
probably be tagged with its Glade name and this name could be in-place
editable. Toplevel widgets would ideally use libmetacity-private to
show what their window decorations would be like (and allow
resizing). This also makes it easy to distinguish toplevels from other
widgets on the table.

In-place editing for widgets would really be nicer than property
sheets in a lot of cases, but it’s so hard to implement that it’s
probably not worth it.

(This post was originally found at http://log.ometer.com/2005–08.html#11)