Bild nicht mehr verfügbar.

Image: Federico Mena Quintero, a Creative Commons Attribution Share-Alike (2.0) image from szilveszter_farkas's photostream

Federico Mena-Quintero is one of the longest standing contributors to the free desktop, having started GNOME together with Miguel de Icaza back in 1997. He is still a very active GNOME developer, nowadays being employed by Novell / SUSE to work on the desktop. During this years Desktop Summit Andreas Proschofsky had the chance to conduct the following interview with the Mexican. In this Mena-Quintero talks about his concept of the "document-centric-desktop" and the importance of having a journal directly in the GNOME Shell, but also goes on to add some criticism about the current way decisions are made in the GNOME world. In the last few years you've been talking a lot about the "document-centric desktop". Could you give as an overview what this actually is and which problems you are trying to solve?

Federico Mena-Quintero: The current hierarchical file system model is actually very inconvenient to use for a number of subtle reasons. For one, you need to choose a file name – and it actually takes a lot of discipline to pick a good name. Second, you need to pick a location, and picking the right location is hard, so people tend to drop everything in some place by accident. And this gets worse over time – the messier your file system gets, the harder it gets to find anything. Also every application has its own policy for where to save documents, with the result that your files often end up in a very unpredictable place.

I will give you an example: My dad has a toy shop, so he told me one day: "Hey, I'd like to make some barcodes for the stuff I sell; can you help me with that?". So I looked up a program to do that and told him to send me the numbers, so I could convert them in barcodes. I did that and sent him the resulting PDF as a mail attachment. Then I called him a few weeks later and asked him, "did those barcodes actually work?". And he said, "No. I couldn't open them". So I asked him to tell me exactly what he did, and in the end it turned out that he saved the attachment but just couldn't find it afterwards to open and print it. And such things happen all the time.

Document-centric GNOME is about finding those little, humble problems people have, and doing something about them. What I proposed in 2008 at the GUADEC in Istanbul was to have an automatically maintained journal which shows everything you have done in a timeline. Basically that's what started Zeitgeist?

Federico Mena-Quintero: Yes. I started implementing my ideas and then Seif Lotfy came around and told me: "Hey, I liked your journal idea and I've implemented it". And he did a pretty nice job. He had a separate daemon for logging, and the implications of having such a dedicated service are very interesting. At first I just thought about scraping different data sources, like your recently-used file list or your IM conversations list. But Seif's service did a lot more, and logged the exact information we needed for a lot of applications.

The journal has different purposes: You can remind yourself of what you were doing. It also solves my wife's problem of, "what was the name of the file I saved the other day", because she just can scroll up in the timeline and find it easily. So is the Document-centric GNOME just about the journal idea?

Federico Mena-Quintero: No, there is other stuff. To actually start solving the problem of people saving files in wrong places by accident, I started changing the file chooser dialog in GTK+. If you now hit "File/Save" for the first time, we show you the file chooser, but we also show you a list of the folders you have used most recently and require you to pick one. The theory behind that is, by doing it that way, you won't save files in the wrong place by accident because you actually had to pick something. We'll see how this works out, but so far it has been good. And if you hit "File/Open", instead of showing you a folder that the application chose for you, we now show you a list of recently-used files – by default. But you still have to choose a location...

Federico Mena-Quintero: Yes. And that's a problem. So – you want to get rid of the file selector in the long run?

Federico Mena-Quintero: Yes. Think about Tomboy. The nice thing about it is, you type your note and it automatically gets saved somewhere; you don't have to care about that. And you always have access to it, because you have that little menu of notes. Google Docs does this as well; Apple is moving towards this model – and I'm kind of angry that they got to implement it before we did.

The idea is you write your document, and we save it for you at convenient times; we either extract a title from it or we require you to provide one and it will be saved somewhere. And this then shows up in the journal. Nobody wants to have lots of "untitled" entries there, so people will quickly get used to providing good names. We could make it easy to change titles in the titlebar of document windows. Has the work on this already started?

Federico Mena-Quintero: Not yet. But we should be able to start implementing autosave easily in some applications; we may start with little Gnome applications like Gedit to get a general feel for how it should be done. And then, we can move on to more complex things like LibreOffice.

But once we have autosave, we can move on to other things. One of the things I was saying in my talk here ("Software without the quality that has no name") is that we need to do things incrementally. So we do the journal, then we do autosave, and after that we can start to see if we can move away from the file system – maybe some sort of semantic file management. But for now, it doesn't make sense to start breaking all the exisiting apps just to have this abstract file storage thing. Implementation-wise the diary has seen a lot of permutations over the years. So where is this going to end up? As a separate application like GNOME Activity Journal or directly in the shell?

Federico Mena-Quintero: We have an extension for GNOME Shell that shows you a journal. Originally this was in a branch of GNOME Shell but we moved it to an extension to make it easier to test. We should be releasing that pretty soon; basically when the Summer of Code ends this should be done. [This has been released now, ed.]

The reason for having it directly in GNOME Shell is that your data is the most important stuff for you. And if the Shell is your central point of control, it also makes sense for your data to be presented at that level. When you need to use a separate application, it's like having to go out to a service in the street to do something that you should be able to do where you are, so it really should be in the Shell. Which role do you see for online storage in this whole concept?

Federico Mena-Quintero: We are not doing a lot about this right now. We are definitely going to consider that, but I think it's much more productive to first solve the problem of dealing with your local stuff. One thing people need to think about is that, ultimately, the data needs to be in your computer for you to do something with it. Once you need to interface with the real world, like with a printer, you need to have it there.

Also, the cloud is just not everyday life where I live. In Mexico people do not have dozens of devices. A laptop is a luxury item. Most people have a cell phone; very few have smartphones because they are too expensive, and the carriers are too expensive. When people buy a desktop computer they keep it for years: my father's computer in his toy shop is like 10 years old, and it has a very slow internet connection. So I think it's very arrogant to say that people should move everything to the cloud because things are going to end up there, as that is not reality in the place where I live.

And even in very sophisticated places like the United States or Germany, you are not online all the time. So I think there is value in fixing the very mundane problems first, and then climbing up for the cloud case. Being one of original founders GNOME are you happy how the project has evolved over the years?

Federico Mena-Quintero: In the beginning there was nothing. Only chaos. [laughs] We had so little infrastructure, we needed to implement so much stuff that any contribution was valuable. We had crazy contributions back then, because it would have been silly to turn them down. One of the original founders of GNOME, Elliot Lee, he liked to write crazy little tools. So, one of the first things we had in GNOME was his program to manage mailing list subscriptions. Back then, language bindings were a big deal, so just for fun he decided to implement it in in Objective-C – simply to show that we can support other languages than C. We had lots of these things, even a recipe manager.

As things progressed we could actually afford the luxury to say "no" to some contributions as they were no longer really useful. Then the whole usability push came, a little bit before GNOME 2.0 – basically, when Sun Microsystems came into GNOME, they taught us to care about usability and to consider that. So, this sentiment developed that things have to be generally useful for people, things have to be made usable, and not just be hacker tools. And that was a good thing. Then we had the push for accessibility; we refactored a lot of stuff to be accessible; we refactored a lot of stuff to be usable. So, things have been changing slowly.

The latest thing is that now things have to go through the design team first, and I don't think that is a good thing; there should not be a central body of control that decides how things are done, because that simply doesn't scale. And it also doesn't teach people in how to do design properly. I really would like to move to a model where, instead of having a central body of people who can veto things in or out, we can have a shared understanding of what constitutes good design and implementation. And then, we can evaluate proposals on all their merits and modify them instead of just saying, "Oh no, I don't like this, because it doesn't follow my design criteria". Is it even possible to have one design that caters everyone, from kernel hackers to newcomers?

Federico Mena-Quintero: No. For example – my house is very nice; it has a very good kitchen, it has very nice bedrooms and a lot of sunlight. And my house works very well for me and my family: we designed it for ourselves. If I sold my house to you, it might be comfortable enough, but there would be things that are not quite to your liking. You may have different conventions for cooking, you may need an extra bedroom because your family is very large, and so you would want to adapt the house.

So even though spaces are generally usable by anyone, people will always want to customize them to their own preferences. And that's a thing people also do with their computers, because everyone has a different workflow. So we have a need for things to be customizable enough that people can make up their own workflows. We should not make things so that you need to build everything by hand; we need to provide a good baseline, but leave room for people to figure out the way they like to work. So I think it would be very arrogant to say, "no, that should not be customizable, because we did a good design". Isn't the success of Apple a counter-example for this in having very strict design rules?

Federico Mena-Quintero: I think Macs provide a good baseline, but they also allow for more customizability than you might think. Power users customize their Macs a lot; they install Quicksilver to launch things quickly; they install a lot of such applications because they find them useful for their workflow. And if you don't allow that you will just attract the "baseline" of users. So is this then where the extension system for GNOME Shell comes into play?

Federico Mena-Quintero: Yes. Some very wise programmer I once read said, "It is better to have a very flexible system which you then constrain to something actually useful than to have a very closed system and later try to extend it". You will get a much better architecture when you start with a very open-ended thing. And I think that the purpose of GNOME Shell extensions should be just that: Being able to do what most people won't do.

For instance, Red Hat had this contract with Pixar and they were really, really worried about having the applet for monitoring memory usage running properly all the time. So the question was: Why? I mean, they have those huge workstations with lots of memory. Well, it turns out that they used some proprietary 3D editing tools that were full of memory leaks, and sooner or later everything started crashing – and people would lose all their work. So the people at Pixar needed to have this display to check if the memory was filling up, to restart the application before it crashed. Very few people need a memory monitor in view all the time, but those that do, they can't use the system unless it has one. It would be a deal-breaker.

So we start with a good baseline – everybody needs to manage files, everbody needs to switch to another window, everybody needs to launch applications – but allow room for the people that need expansion for specialized use cases.

(,, 13.11.11)