Sunday, August 31, 2008

Branding 101

A while ago there was a big effort to make all the various "official" GNOME web sites consistent in some minimal way.  The reason for this was the reconition that "branding" is important.

So, imagine you are a potential new user or reporter trying to figure out what GNOME is all about by checking out the GNOME info-web.

Currently, if you Google for "GNOME", you get the correct result (for us): the first hit is, check.

On this page the top line navbar elements are
  1. News (, didn't load for me today
  2. Projects (
  3. Art (
  4. Support (
  5. Development (
  6. Community (
From a cursory top-level examination the potential convert or evangelist will find that
  1. There is no news (OK, maybe that's a transient error)
  2. There are a mixture of headers navigational elements in the "official" GNOME web (art, developer)
  3. The developer docs are extremely out of data
So far not good, but maybe not too bad.

But what if you Google for "GNOME support"?  Currently the first hit is  Seems reasonable.  But you get to a site that at first glance looks nothing like the "official" GNOME sites.  Maybe this is a third part ("Community") site?  Who knows?  You certainly can't tell from the page itself.  The "About" link doesn't tell you about, it takes you to; probably not what you'd expect.

All in all, not a good first impression.  And it seems so easy to fix.  We tried to fix this in the past.  Why couldn't we?

Why am I led to the conclusion that the people in control of those sites just don't care about the user-facing side of their efforts?  I'm not saying that's a bad thing, but rather there seems to be a disconnect about what we say and what we do.  If we really care about the users, why do we make life harder than it needs to be for them?

Did I say "them"?  Sorry, I meant "us".


The first comment on this post shows exactly the problem with many open source and Free software developers attitude to users:

"Why do you switch from 'why couldn't we' to above accusation?

Everyone having SVN can improve. Instead of asking who does it, do it already or quit complaining, too easy."

I rest my case.  Developers don't care about users.  If a user offers constructive and actionable feedback, the guaranteed reply is "do it yourself".  Is it any wonder we haven't acheived Word Domination, or at least 10x10 by now?

But I'm not bitter.  I will stick with GNOME until I die, and weather the flames generated from trying to help.

Peace and love,


Sunday, August 03, 2008

Visions of GNOME 3.0


I've been silently digesting all the GNOME 3.0 thoughts for a while now. Then, yesterday, I installed KDE 4.1 and all of a sudden things kinda crystallised in my mind. I'm a marketing person, so I tend to think in terms of users; and user needs and wants.

In what follows, I will assume that in any GNOME 3.0 release the GNOME 2.x values (Powerful, Simple) will be incorporated. I would like to see GNOME's next major release add to that list and I've got a tag-line all ready: GNOME 3.0: Helpful. In what follows I will try to explain what this means and why I think it's a good idea.

What do you mean, "Helpful"?

I mean that GNOME (the development platform and the bunch of officially blessed applications that comprise a release set) is a set of enabling technologies that enable developers and users to get stuff done using computers without putting barriers in the way. In other words, user experience.

What, then, are the barriers that get in the way of getting stuff done? What would produce a qualitatively different release of GNOME, one that makes using it feel different?

Uninterrupted workflow

Has it worked?

Why, why, why does it take the simplest of applications (a text editor or a terminal) more than a second to start up? At least there's a little animation to tell me that my request is being considered, but why is it taking so long? Should I be worried? And if the animation happens for requests (commands) that take a long time, why doesn't it happen for all of them? Many times I've clicked on the update manager icon in the panel twice (with a delay of a second or two between clicks) because nothing seems to be happening. And then, of course, I get two instances of the application running (eventually).

This behaviour interrupts work-flow and train-of-thought. Application startup time is a seemingly small issue, but consider how it would feel to use a computer when there was more-or-less instant reaction to user input. It would become a qualitatively different experience.

With the work on GNOME-Mobile underway, can we get that work for re-jigging GNOME to work well on resource-constrained machines back into "mainstream" GNOME? Please? That would be really helpful.

Has it crashed?

Why, oh why, do applications fail to repaint the screen or respond to user input (mouse clicks, for example) while they are waiting on disk or network I/O? Has the application crashed (and do I need to kill it?) or is it actually working "normally"? Do I have do interrupt what I'm doing to attend to it, or shall I just wait?

It has crashed! Why?

OK, so a GNOME application has crashed. What do I do now? Start it again and hope it doesn't crash again? And if I got an error message, does it actually give me (a non-programmer) a clue about what to do in order to prevent it crashing again? If it's a problem that others have faced and solved, can I get their solutions quickly and easily? (Reverse Bugzilla?)

Helpful summary

So, priorities for GNOME 3.0 from the user-experience point of view. In summary we need to increase responsiveness:
  1. Reduce application startup time

  2. Eliminate blocking UI on I/O

  3. Automatic bug reporting

  4. Automatic bug solution/work-around suggestion
That would be helpful.

Mutual Help

All the above is about developers helping users. But how can users help developers? By writing documentation, of course! But it be "user" we mean "non-programmer", how easy is it for a user to "contribute" to the community rather than just taking?

User-contributed Documentation

It seems to be a truism that programmers hate to write documentation. Well, maybe not hate: probably they've just got better (more interesting) things to do. So let's harness the type of goodwill that gets people posting to user-to-user help forums and writing Wikipedia articles. But let's not start another "social networking" web site. Let's put the good stuff into the documentation that comes with the software.

Currently in order to do that a user must learn a markup language, and hence a write-compile-test cycle of working. Probably a (D)RVCS system too. Can't we create a tool that would make it easy for a user to submit an edit to existing documentation (including tool tips) or create an entirely new chunk of documentation? People would actually use it.

Then we'd need an editorial layer. The maintainer(s) and their trusted lieutenants need to do that. But "trusted lieutenants" need not be other coders. They could be simply particularly clueful users. But they'd need easy-to-use tools.

That would be very helpful.


I've written about things that bug me when I'm using my computers: things that get in my way, make me focus on the software rather than what I'm trying to do. Addressing these issues is not trivial, but it would produce a quantum leap in user experience compared to any other GUI that I've ever used (including various versions of Windows and OS/2).

Why should you care? GNOME will never, ever, gain significant market share if it's at least as good as the alternatives, with the additional benefit of being Free. Only if it's obviously, immediately, better than the alternatives will it grow, What is "better"? Well, "not so annoying" would be a good start.

I've written about helpfulness from the user's point of view. Perhaps someone who knows could write about it from the developers (ISVs?) point of view?

Tuesday, June 03, 2008


Linux is user-friendly. Gone are the days of "RTFM". Yeah, right.

How much extra effort would it have taken to provide, in the widget, a link (or at least a clue!) to the Fine Manual?

What about more options for the user. What do you mean "Don't show me this again"? Ever? What if I want to ignore the error for now (the computer is still working, so I want to actually use it) but come back to it later? If I want to file a bug, how in the name of ${DEITY} can I figure out what "product" or "component" to file it against?

Sorry for the rant. After having watched the excellent Lug Radio Live USA videos (thanks!), particularly Aza Raskin on "Humane Computing", and Benjamin Mako Hill on "Revealing" errors, (here is the schedule of links to the talks), I'm a bit sensitive to this sort of thing.

Yeah, I know you get the same BS on legacy systems. But if we want people to adopt Our Favourite System, we have to be so much better that the benefits will outweigh the barriers to, and costs of, adoption.

Wednesday, April 30, 2008

Hi Benjamin,

I find your post to be very interesting reading, because I am a Free software user and I also teach marketing. Please allow me to comment, from the perspective of one who tries to teach people how to be marketers, rather than one who actually does marketing.

Marketing is a societal process … attempting to move the consumers toward the products or services offered.

That quote is complete bullshit. It is a definition of the "Selling concept", which is what the "Marketing Concept" is entirely against. This is one example of why Wikipedia should not be used as a source of authority on contentious issues. Try Citizendium's take on this issue instead.

I hate marketing. With a passion. The sentence above shows the 2 biggest problems I have with it. One is the word consumer, which often means “too stupid to make its own decisions”. The other is the fact that it doesn’t talk about the quality of the offer, but only about “moving towards”.

The first sentence above might be expected to enrage me. In fact, I couldn't agree more with you if, in fact, "marketing" is what it says in the Wikipedia quote and article above. But it's not. At least, not the way we teach it at my place. And the "official" definition of Marketing, if there could be such a thing, is also at variance with the Wikipedia definition. It's from the AMA (American Marketing Association), and the latest version can be found here.

Turns out, the people we trust have no clue either. That bug report is Debian wondering which Flash player to ship in the default install. Apparently the most important thing in deciding about it is wether Flash starts paused (changing that is a one-line diff) or the amount of people that have submitted code. Stuff like feature completeness or code quality don’t seem to be that important. Why should they be, those are hard questions, answering them is way easier than looking at statistics or the big play button in your browser. Another hard thing for people is realizing that one doesn’t have a clue and asking the developers of the respective projects for their opinion. It still baffles me that people don’t ask.

Here's where we disagree. From a Marketing point of view, the opinions of the people who create the software don't matter. All that matters is the wants and needs of the consumers.

Apparently in these cases marketing is very easy. Since the people don’t even have a clue what the right questions to ask are, marketers are free to make up their own questions to ask about the project and provide the answers.

Then those people don't deserver to be called "Marketers". If they don't source their answers from consumers, they are not doing marketing.

So you have one project that overpromises and another one that underpromises. Now if you browse discussions about Flash players on various mailing lists or forums, you’ll notice that Gnash is known way better. People are very more aware of an application that claims to almost support Flash than an application that claims it might not even work. On the other hand, the perception of Gnash is more negative. Gnash does not deliver its promises. Swfdec on the other hand promises nothing, so it’s likely it’ll be better than people expect, which makes them happy. Now, the question is: What’s the better approach?

This is common wisdom in marketing circles: under-promise and over-deliver is a mantra we learn early on.

Until then, it’ll probably remain nothing but an interesting thesis project for someone studying marketing.

Probably not. We've known this for decades. It's just that some people don't pay attention in class ... :-)