Things about GNOME that Rock, Number Two

One comment on a previous post was along the lines of "Why aren't you praising GNOME software? The software should be number one, community is secondary." I am trying in this series "Things about GNOME that {Rock|Suck}" series to avoid talking about specific applications. IMHO that sort of feedback belongs in bugzilla, whereas I am trying to comment on GNOME as a desktop environment and developer platform, i.e. as a whole rather than particular components applications. I hope that makes sense. So, without further ado, Rock Number Two:

Increasing integration of applications, for example Evolution and Gaim. (And now Evolution and Tomboy!) The more that central information stores such as evolution-data-server (and the MIME tye system, DBUS etc.) permeates the desktop, the cooler things will be for a humble user like myself. That is real usability (as opposed to discoverability). Fewer mouse-clicks and keystrokes == more productivity in my book.

Someone else commented that I need screenshots in these posts ("people love bling"), and I was going to include some in this post. However I am currently running the latest CVS build of GNOME, and neither Evolution or Gaim work for me. I thought it was more important to test and report bugs than produce spiffy blog entries, but hey, that's the sort of guy I am...

Things about GNOME that Suck, Number Three

I am running out of things that suck about GNOME. That's cool! By that I mean that all the other things I would have to say really belong in bugzilla, not here :-)

But today's gripe is this: the bug reporting, triaging and fixing system appears to be fundamentally broken.

I will base my commentary of these premises:

1. All software has bugs
2. Users hate bugs
3. Users find it very difficult to produce useful (to developers) bug reports
4. Bugs cause lost productivity for both users and developers (who have to fix them)
5. Bug fixing is often very difficult
6. The sheer number of bugs is a severe psychological barrier to fixing them

Immediate conclusions that follow are:

1. Minimizing the number of bugs leads to greater productivity and happiness for both users and developers, and hence should be a major goal of GNOME.
2. In order to achieve that goal, the quality of bug reports must be increased
3. Because users have limited ability (regardless of motivation) to increase the quality of bug reports, the more the bug reporting system can be automated, the better things will be for both users and developers.

So, what is the way forward? I can think of three broad areas:

1. Forget trying to make bugzilla more friendly to non-technical users. It could probably be done, but other, easier paths will lead to the same destinations. (By the way, the recent improvements are totally awesome!)

2. Delete all bugs from bugzilla and start again. (Tell everyone that we're doing this, and why.) Devote massive resources to the triaging system. Make sure that every bug that gets assigned to a developer is assigned to the corrects developer, has sufficient information to be useful, and is not a duplicate.

3. Bug Buddy needs love. Lots and lots of love. And when it has been loved so much that it is limp, it should be loved some more. Bug Buddy is not usable for non-technical users. Not convinced? Let me show you what I mean. (At last, some bling!)

Testing the latest Evolution from CVS:


Hmm... trouble! Better report it. Press the "Inform Developers" button. First Bug Buddy tells me that my information is out of date. Well, it told me that last night too, and I updated it then, but I suppose things may have changed. OK, download updates and wait while "Bug Buddy gathers information". Inspect the stack trace and confirm that it appears to be, indeed, about evolution-exchange-storage. But wait, what's this? Bug buddy tries to help me by eliminating duplicate bug reports. Cool! But what's all this about products that have nothing to do with evolution-exchange-storage? How is that relevant? Wouldn't it be better to present information about the application that crashed?


Whatever. Let's go to the next step. What's this? I have to choose the application that I'm reporting on? Doesn't Bug Buddy know already? It's got the stack trace. And couldn't the system that launched Bug Buddy tell what has crashed? Never mind. Let's try to pick the application. But wait, it's not there!

Oh, maybe evolution-exchange-storage is not an application. But hang on, Evolution is, why isn't it there? Oh well, try "Products" instead. (Puzzling over the difference between an "Application" and a "Product".) What now? Why are there so many duplicate entries, and how can I tell which one I should choose? And where is evolution-exchange-storage?

Hmmm. Oh, wait. I've been using GNOME for years, and I recall that once upon a time it was called "Ximian Connector". Look under "X", no, ... OK, there is a "Connector" (or two), one of them is (probably) the right one. Hang on, why is "Crossover" in this list? I have never installed that, ever, on any of my computers! Whatever ...


What's next? I have to tell Bug Buddy what version of the product I am reporting on? Can't the system that launched Bug Buddy provide that information? And what about "Severity"? How do I decide what to put in there?

Whew! Finally I get to actually type in the bug report. It appears there should be exactly three steps to reproduce a bug. OK, I suppose I can adapt my experience to that framework. Now, once the information is entered, I get to choose what to do with the report. I have to choose between saving it as a text file, or emailing it. (Why can't I do both? What if mailing fails? Do I have to go through all this again?)


Yay! At last! The bug report has been filed. I feel a warm glow of satisfaction at having fulfilled my duty as a non-developer member of the GNOME community: I have filed a (damn good!) bug report. But wait, have I really? If I check bugzilla.gnome.org it does not appear to be there. Even days later. What's going on? Perhaps the mail did not get through? How do I check? What was that about sendmail in the mailing options?

Discover mailq, and the fact that the bug report was not, as claimed, file. Dismayed to find that now I have to learn how to configure sendmail. It's about enough to make a poor user want to cry...

Things about GNOME that Suck, Number Four

First, let me thank all the people who have been posting comments on my blog entries. I never expected such a positive and encouraging response to this series! For those of you who have not read the comments, I can summarize the frequency distribution of classes of comments as follows:

1. "Right on! Keep up the good work": lots.
2. "That's bullshit/You suck": none.
3. "What about ?": some.

Thanks! But just to reiterate: If you think that I am being unfair, or am JPW (Just Plain Wrong), please let me know. I could let this go to my head otherwise... ;-)

So, Gripe Number Four: The desktop environment does not remember the size and position of windows.

Premises:
1. The purpose of computers is to make the lives of humans better and easier
2. Computers are for automating tasks that are boring and repetitive
3. GNOME is simple and easy to use
4. GNOME "Just Works".

Data:
Every time I start the applications that I use every day (Evolution, Firefox, Gaim, a couple of terminals, Emacs) I have to arrange the size and locations of the application window, both across virtual desktops and within each desktop.

Conclusion:
At least one of the premises are false.

I know that it is a deliberate policy decision of the Metacity hackers to not handle this functionality. I also know about Devil's Pie (thanks Ross!). But I still find the premises compelling. I don't want them to be false. Do you?

Things about GNOME that Suck, Number Two

(Editorial note: I am trying to keep these posts short and to the point. I have had about 20 responses to them so far, all but one positive. So I will keep going for now.)

The woeful state of multimedia. Specifically: handling the (in)ability to play some formats.

A typical scenario that occurs at least once a week for me is that I will attempt to play a multimedia file (usually a movie), and the application I use can not deal with it. That's actually fine, especially if you are free software/anti-patent bigot like me. What bugs me, however, is that the shell (Nautilus?) will happily launch the application, or allow you to associate the application with the particular MIME type, when it is known that the application is unable to deal with the file. (I use Totem, Xine, and Mplayer by the way.)

I was going to post about something else today, but this one leapt to the fore in my brain after I had waited for a long time for a file to download (5Mb on a 56k connection) after Firefox offered me the option to save it to disk or open it with Totem. Totem starts up and then tells me it can't handle that file. OK, so it was a WMV. Try again with the Quicktime version of the file. Same result. DVDs? With Totem? Forget it. That's why I have to have three media players: to handle all the formats that I come across.



GNOME "Just Works"? GNOME is simple? I don't think so. And considering the ubiquity of multimedia in today's computing experience, I see this as a major impediment to encouraging people to start using GNOME.

The way forward: can we change the MIME type infrastructure to disallow the user associating applications with MIME types that they cannot handle? Nautilus offered to open a VOB file with Gedit. I can't remember associating Gedit with VOB files, and I am pretty sure that I would not have done so on purpose. Perhaps a distribution associated VOB files with Totem. But why would one do so? We know that will cause failure and frustration.

More: can the error dialogue of Totem be changed to give the user a clue about how to install plugins and where to find them? And perhaps a link to a page describing GNOME's stance on proprietary formats? (Does such a page exist?) I have hope on this front, and want to publicly thank the Gstreamer people for their efforts.

/EndTransmission

Things about GNOME that Rock, Number One

Well, I have had about a dozen comments on my previous blog entry (Things about GNOME that Suck, Part One), all of which were along the lines of, "yeah, me too". I have had one private email from someone (whose opinion I respect) who suggested that it's not very nice to criticise people in public. I have some sympathy for this view, but do not entirely agree with it. But, if anyone here objects to my criticism, please let me know! I would not want to piss off a bunch of people for whom I have huge respect and admiration.

As I said in my previous entry, I want to criticise and praise on alternate days. So here is my first item of praise. :-)

One thing about GNOME that rocks HARD is the community spirit, and the ease with which can become involved and contribute within the bounds of one's abilities. I am not a developer, but I feel that I can and have contributed something, however small, to GNOME. (I also feel that I could do much more, but that's a different story.) This is something about GNOME that should not be underappreciated. So to all you other people in the GNOME community: Hello! And thanks!

Things about GNOME that Suck, Part One

Well, after GNOME.conf.au I have been re-invigorated. My desire to contribute to GNOME has risen, so here is my first concrete action. Unfortunately it isn't a patch or anything as concrete as that. What is it then? I have resolved to blog every second day about one and only one thing that bugs me about GNOME. On alternate days I will blog about things that I love about GNOME. When I have run out of those things, I will stop. ;-)

So, without further ado, here is Gripe Number One from me. UIs that block on I/O. In particular: yumex, Gaim and Evolution. I suspect that the reason why I notice this and it bugs me so much is that (at home) I am on a 56k modem connection. Waiting on a response from the network really exposes those "no-repaint" moments.



What to do about it? There has been discussion on this planet recently about multi- threading vs. not. Perhaps the one way to drive the point home is for people who develop network-using applications to dogfood their project using a network throttler. Have a fat pipe? Maybe that's why your application looks unprofessional.

Update: someone asked for evidence of Gaim blocking on I/O: here it is:

GNOME Miniconf in Dunedin

Hello fellow freedom lovers! As some of you may know, LinuxConf.au is in Dunedin, New Zealand this year. That is where I live, so I thought I would attend. :-)

I will be presenting in the GNOME MiniConf, talking about marketing GNOME. I have quite a few thoughts on the matter, but almost none of them are original to me. I think about marketing GNOME quite a bit, but most of this thinking is evaluating the ideas and opinions of others.

So, unless you want to see another article from me in GNOMEJournal that is just a rehash of stuff you've already seen elsewhere, please contact me (jwilliams@gnome.org) with your thoughts on:

1. What {are | should be} the goal(s) of the GNOME marketing team?


2. How effective is the marketing team at achieving these goals?


3. What is the marketing team doing right?


4. What is the marketing team doing wrong?


5. What is the marketing team not doing (that they should be doing)?

Now the punch line: You are all on the GNOME marketing team. You are just not full-time marketers. You are part-time marketers. Every time you change a GNOME "product", or interact with one of GNOME's stakeholders, you are performing a marketing function. Marketing is about (all the activities that achieve the goal of)matching the desires and capabilities of the organisation with the desires of the market. And since GNOME is a loose network organisation, YOU are, in a sense, "the organisation". Yes, YOU, punk. I'm looking at YOU.

That is all.