Aaron J. Seigo
Aaron J. Seigo <aseigo at kde dot org>
... sponsors my KDE work
aseigo> su -
linux:~/PublicLife/LinuxBoxShowTranscript # _

The Linux Box Show Interview

The Players

Sean Parsons (SP), the interviewer
Aaron J. Seigo (AS), the interviewed

Warm Up Banter

SPHey Aaron, it's Sean. How are you doing?
ASNot bad, yourself?
SPOh pretty good.
ASGood, how are things out there?
SPOh you know, it's a beautiful day in Pittsburgh. It's probably the nicest day we'll have all year. *laughs* And here I am inside instead. *laughter*
ASDon't step outside, that'll ruin it. It'll immediately start raining or something.
SPThere you go. I'll tell you what, I don't know if you've ever been to Pittsburgh, this has got to be one of the heaviest rained cities in the United States.
ASI'm sure Seattle gives you a run for your money. *laughter* I lived on the West Coast for many years. Yeah you get used to the rain. The grey days. The weeks of unending drizzle. *laughter* You incorporate it into your psyche. *laugh*

What Is Appeal?

SPAlright. OK, we'll get started with the interview if you don't mind.
SPAlright Aaron, the email you sent me was about a new project called the Appeal Project. Can you tell me more specifically what the Appeal Project is and whom is involved with it?
ASSure. The Appeal project started really as a meeting of around 15 KDE contributors in Berlin in March 2005, and we got together to really discuss where we wanted to see KDE go and how we wanted to direct our own efforts within it, especially with the push towards KDE 4.

So the appeal project is kind of our banner, if you will, representing what we're trying to achieve. There's three really principles that we're chasing after.

One is breathtaking beauty: we want take KDE and make it as gorgeous as possible; something that is zen-like in its calmness but also compelling.

Second of all: clarity in the interface. One of the things that people say time and again is well KControl has issues or there's too many icons in the Konqueror toolbars. And these are issues that we've dealt with for a while now and we're saying, "Ok, how can we actually address these things in a way that makes sense?"

And the third thing is technical creativity. We've really fleshed out the current set of technologies that we have. And now it's a question of, "Well, where do we go from here?" Now that we've, you know, we've done a lot with DCOP, done a lot with KParts ... we can do a lot more with them, but where else can we go?

So with these three principles in mind we brought together a group of artists, usability expoert and actual software developers from the KDE project and formed this project to work on specific technologies and areas around KDE.

We Want Candy!
SPWow, that sounds really great. Now you mentioned that there would be some eye candy coming with KDE4 just now. Now you know I spend a lot of time playing with the eye candy myself. You know I can't help myself there. *laughter* So are we talking broader use of SVG, true transparency or are we talking something similar to the "wobbly windows" that the GNOME camp has been showing off, or is there something more radical than I've anticipated on this?
ASWell, fortunately we've seen a few really exciting things happen on the eye candy front. One of them being the revitalization of X development. That had been stagnant for quite a while and limited our possibilities. We've now got more people working on X to do really cool things. We've got the COMPOSITE engine that came out that's stable on some graphics cards and is progressing in that direction. But we're really just seeing the beginning of what's really possible with the X protocol. If you look at other operating systems... MacOS X what they've been able to do, what Microsoft is promising to do with Longhorn .. and there's this movement towards utilizing graphics effects to really enhance, not just give eye candy that you can look at and go "Ooh, that's really nice" but also enhances the user experience.

We've got one of the people in the KDE project recently just got hired basically to work on these type of issues in X within with a focus more towards KDE. So that's an exciting opportunity for us to really say, "Ok, what can we do with the graphics capabilities?" Will it be transparency? We've already got that in 3.4. It can be a lot a better and go a lot further and we plan to take it there, but what are we going to do with the eye candy? We're still working on the exact details. You'll see some of the concepts in 3.4 where we've got the fade-in tooltips on kicker. Those are really tame, basic things. We've got so much power in the graphics cards that we just really aren't tapping.

So I don't know exactly what's going to roll out with KDE 4.0. I mean, that's a year away for that release, but we're agressively looking at how can we take X, how can we take the actual user work flows and create visual metaphores that actually work and that look modern as well.

SPWow, that's a lot. OK, well you've also talked about the usability issues and, you know, as you'd pointed out a lot of people have mentioned some of the crowded Konqueror toolbars and poor organization. Konqueror is of course one of those all-in-one tools that people love to use for everything, including myself, but you also mentioned KControl. So now, are you going to be setting any sort of usability standards for future KDE applications or are you going to address it on an application-by-application basis. In other words, are we looking at establishing something like GNOME's human interface guidelines or anything of that sort?
ASDefinitely. Two of the people that were at the Appeal meeting, the first Appeal meeting in March, are the maintainers of the human interface guidelines for KDE. We started working on this back in aKademy, the KDE World Conference in August of 2004, and they've been working on it for the last few months. And part of the Appeal project will be to complete the interface guidelines and then start to roll it out to the various applications starting with the core set of applications within KDE.

The KDE HIG will be a comprehensive document that will cover soup to nuts. But at the same time we were really concerned that if we had a document that read like a novel developers wouldn't really get into it and it would be something that would be in the realm of the usabilty peole. We'd have to have the usability people running around and fixing things. And one of the things we're trying to do with the Appeal project is artists, usability and software developers working together. So the interface guidelines, as it's drafted right now, is really designed for use by developers, the people it should be targetted at. Which means that it's use case based, it's quite basic. You go in and say, "If I'm looking at my toolbars, what should they look like? How sould I set them up?" and then all the usability principles and details are drill-down items from there.

But that's definitely one of the sub-projects underneath the Appeal umbrella. And complimenting that is our Community Identity Guidelines, or CIG, which covers the actual look and feel of branding of things in KDE which ranges from a colour palette right through to icon standards to follow when creating icons for applications. And we feel that these two guideliness really compliment each other to create a consistent interface and one that is compelling. If you have a usable interface but the icons are one colour, they are boring to look at, or they are straining on the eyes you can have a really work-flow oriented, easy to use, easy to understand interface but it won't be compelling. And vice versa. You can have a beautiful desktop but one that is completely unusable because of the way configuration dialogs are layed out or the work flow just isn't reflected in the interface. So we're looking at combining these two documents into a kind of one-two punch to really create a calmer and more consistent interface for KDE.

SPOk, well, while we're on the subject of consistency then I'd like to go ahead and jump to a related issue, are there going to be any consistency improvements when utilizing Gtk apps under KDE? I mean currently many of the Gtk apps will require double clicks for functions that only require single clicks under KDE. I think that sometimes provides a little bit of confusion for people that don't know the difference between the KDE and the Gtk apps.
ASYeah, and the interoperability issues are largely within the domain of the playground of Freedesktop.org.
ASWhich really is not a seperate project as much as it is a metaproject between the different desktop projects, where we can go and say, "Ok, well, this is where our applications hook together. How do they operate together?" Right now within Appeal itself we don't have an actual focus towards, "Ok, let's make a Gtk applications and the Qt/KDE applications work more stable in this way." I think that's one place that would be great to expand the project into at some point, but right now that's largely something that's handled via individual collaborators from the various projects at FreeDesktop.org.

New Applications?

SPAlright. You also provided the temptation for new applications in the next version of KDE 4. So I can start anticipating the availability of the first alphas, what do these new applications do?
ASWell, we're looking at a few different possiblities here. One the ones that I find really exciting is the idea of a content browser. We've got file managers, right? And this is a well know concept: you go around and you point and you click; files are on your disk or on the network. It's a literal translation of where they exist in the filesystem to what you see. This really breaks down as you have more than a few hundred files. People are really bad at keeping hierarchical structures in a sane structure, let alone navigating them after the fact. So the file system hierarchies really start to break down.

If you look at media players, more and more they're moving away from reflecting the file system and more towards using the meta data contained in the media files to build playlists and show you your actual music files. There's a growing disconnect in media players between what's on the file system and what you're looking at.

The content manager really takes the next step and applies this to all of your information on the desktop. So then instead of manually mapping, "Ok, this document is in this folder which is in this folder which happens to be in my home directory" you can now say, "Ok, I'm looking for office documents, and they came from Sean, and I think they came by email." Or, "Here's an image, where else did I use this image?" and bring up all the documents that that image appears in. So it's a way that's a more human way of browsing your information on the desktop. And this compliments Konqueror, it's not going to be a replacement for the file manager that we all know and love but it's going to be another way of actually managing your information.

KControl, which I mentioned earlier, is going to be worked over rather seriously, and again for many of the same reasons. The hierarchical structure of an application like KControl really starts to break down. And it's not just in KDE. If you look at virtually any operating system or any desktop environment right now they all offer a hierarchical view to their configuration. And if you put a new user in front of these systems they hunt, and peck, and click, and move around and it's not "Oh, this is exactly where I have to go." deal. It's very non-intuitive. The reason being that we moved from having a dozen or so settings ... I remember way back when the first Apple interfaces hit the mainstream there weren't that many things you could tweak. So such a hierarchical representation made sense, it worked. It was easy to remember, there weren't that many categories and what categories there were were obvious. Now we've got dozens, hundreds even, of settings, and of course KDE is kind of the king of that so it's more obvious on the K Desktop Environment than other places perhaps.

So we're looking at KControl and asking how can we take this from a pure hierarchical viewpoint... how can we add search, how can we add navigation? If you're looking at settings for the mouse why shouldn't there be a pointer to, "Here's other areas you can configure things related to your mouse, like the icons for the mouse cursor." So KControl's going to come out in KDE4 looking substantially different than it does right now, hopefully working a lot more like humans actually think and work.

So those are two examples of applications that are being worked on right now within the Appeal project. We've got more coming down the pipe but I don't want to fill the air with vapouware either.

SP*laughs* Alright, since you guys are working on a lot of new things to integrate into KDE4 like that with the Appeal project I know that apt-get, rpm and portage have all come a long way. Many end users are still not comfortable with installing, removing or updating various packages. Does KDE have a plan to improve this scenario with tools like Kynaptic or will this remain the territory of distribution maintainers?
ASI was actually going to bring up Kynaptic because I think it's a good example. We've identified it as an issue. We've got kind of an internal laundry list, internal to the Appeal project, of things that we want to address and things we'd love to see be addressed. And this is one of the things on that list.

At the same time right now we're about 15 people in the project. It's really just starting, it's fledgling. We hope to grow this project and really the philosophy that it embodies into a larger thing. As people come into the project and start working in this manner I think we'll see more and more of our internal laundry list items get addressed.

Is installation of software an issue? Yes. As you said there's the whole thing about tieing to the distributions. We've got within Linux which has several different means and ways that are rather different to install software let alone when we run KDE on Solaris or run KDE on OS X or run KDE on AIX or FreeBSD or OpenBSD. They all have their own systems. So it's a very complex issue, one that reaches further down into the stack. And a lot of the problems that we noted with the open source desktop that people find challenging really have to do with reaching further down into the software stack. Things like removable media which is now being addressed. That had to be addressed lower in the software stack, and I think that's going to be a trend that we see grow in the desktop efforts. And that's more integration with and cooperation with people who are working at the sub-grahpics level.

Office Applications

SPIs the Appeal project going to have any involvement with the KOffice project part of KDE? The reason why I'm asking is that there's been a lot of tension around the OpenOffice 2.0 requiring Java for a lot of its core parts and there seems to be a lot of unhappiness from the FOSS community with this. So I don't know if you guys are expecting to see a lot more improvements from KOffice or if you expect to see at least that improvements that KOffice is getting to attain a lot more attention.
ASWell, KOffice, I think, has a lot of potential for a few reasons. One is it's a native set of applications. Open Office, the people working on that have done some great work making it look and feel more like a native application by KDE-izing and GNOME-ifying it. That only goes so far, and the native applications like KOffice and for that matter the GNOME office applications have in the long run a much more compelling story behind them.

Where Appeal and KOffice will overlap is... one of the things that the Appeal project is doing is creating a new icon theme and a new widget theme as well to compliment that. As well as working on a whole set of graphics. If you use applications you'll see splash screens, you'll see sidebar graphics in wizards and what-not. We've already got a fair number of artists involved with the Appeal desktop project and they're looking at creating a pan-desktop look and feel, if you will, via their graphic work. That's one place that the Appeal project and KOffice will overlap.

As far as getting more of the KOffice developers working with or within the Appeal project we haven't really addressed that at this point. I do know that in KDE4, the KOffice that ships with it will have a lot more flexibility and possibilities than it does right now. Qt4 from Trolltech which KDE4 will be based on offers a lot more of the tools and the capabilities that something like KOffice needs. So we're really looking forward to what will come from there and I definitely hope to see more of the Appeal philosophy of marry the artists, the usability experts, the software developers.. push towards clarity, push towards work-flow orientated interfaces emerge in projects like KOffice.

SPSun Microsystems and Novell have both been discussing the higher level languages in GNOME. Has there been any major discussion for KDE to start using higher level languages as well?
ASThat's one that has been off and on for a while now. One of the issues is bindings: how do you keep bindings up? The best scenario would be if could say, "Here's one or two languages, we're going to ship these with the core of KDE4." So if you have KDE4 you know you can run a Python or a Ruby application written for KDE.

The challenge with that is that with that sort of commitment we have to make sure the bindings are maintainable, that they are maintained and that they're of a high quality. Of course there's the issue of do we pick or or two, or which ones do we pick. As you know everyone has their favourite language. So I think that that is a discussion that as time approaches heats up.

I wouldn't be surprised to see the Appeal project extend a hand to more of these binding projects and say, "Ok look, let's work with, say, the Ruby bindings." I'm justing pulling one out of the air, I'm not saying Ruby is our choice, but, "let's work with the Ruby bindings and let's really polish them up and let's make sure that application developers can really rely on this." And that's really the kind of interaction that the Appeal project and the people within it right now are looking to have with the rest of KDE as a way to provide focus and directed development to help direct us towards these harder visions.

SPLet's move away a little bit from the Appeal project and discuss another KDE related issue that I know you have strong feelings about. How do you feel about some of the work that people have been preparing to try and port KDE or at least parts of KDE to MS Windows from the new from-scratch Qt port that they've made for Windows?
ASYeah, I do have strong feelings about that. *laughter*
SPIt's just something I had to bring up because it was something you and I had had a discussion about previously.
ASRight. Anyone who's read my blog probably knows my feelings on that. There's obviously good arguments to be made for Open Source applications on Windows, especially when it comes to migration issues. What I said in my blog last year that really kind of kicked up a caffufle, we really have to go with eyes wide open and realize that we're entering or working on a platform that we don't have a load of control over and that doesn't really like us. And it hasn't hasn't been above the people who control that platform to compete agressively.

I was talking with a fellow who is very high up in the IT organization of a Fortune 500 company and his whole opinion was, "Well, we can put Open Source applications on Windows but ... you know how long is that really going to last for us before Microsoft changes something on us." They don't really see it as a viable alternative in the long term.

When I look at that I go: if people want to work on that, if that's something that interests them and that's where they want to put their efforts, well great. That's one of the beautiful things about Open Source projects: you get to work on what interests you, scratch your itch. But there are potential issues that we have to be aware of if we go down this route so that we don't just line up like chearleaders behind it and go, "YAAAY!" *laughter* "this is great this is wonderful" without realizing all the things involved.

And it is a difficult issue because you have to say, well is Open Office on Windows a good thing because now people can migrate off? Is Firefox on Windows a good thing because that helps us establish standards on the Web? Yeah, those are probably good things. Is ite good to have Kexi on Windows, the KDE database application? Yeah, it could very well be because it allows people to start breaking that lock that Microsoft Access represents. So there definitely are situations where it does make sense.

Does it makes sense as an across-the-board strategy? Personally, I don't think so and I think there are some real long-term dangers there.

SPI've taken up a lot of your time. Is there anything else you'd like to try and discuss at this point or should I try and let you get back to your job? *laughter*
ASWell, I one thing that I would add ... a couple of things that are happening in the Appeal project that we didn't really get to discuss thus far taht I find really interesting are, one: the contextual link enginge. We were talking previously by email, you had asked is there a search engine sort of thing coming around. And search tools are a really hot topic right now. It seems every desktop environment is throwing up a search tool. In the KDE project I think in the last two months I've seen three or four different approaches from people that are working on it on their own. We think that's kind of just the first step and that what's a lot more compelling than saying, "Let's throw all the full text and all the meta data into a big glop database and let you full text search it" is the ability to record, mine and then go back and navigation and search through contextual relationships between information.

It's funny how much information we throw away on the desktop. Insane amounts of information. If you're doing research on the Internet, for instance.. An example I've used is say you're doing an essay on panda bears. You go on the 'net, you go to ilovepandabears.com, find an image you really want to use in your presentation, you download that image. When that image is downloaded to your disk, we no longer know where it came from. We've lost a bit of context for that image. Then you take that image and you put it in your word processing document. We have lost yet more of the context because we really no longer know that that image is actually the same image as the one that's on disk and that it actually came from the Internet, in fact it actually came from this website.

We're looking at capturing that sort of information and allowing the user to actually navigate and move through their information using that contextual web. Uou look at Google, that was how they broke through: they use their whole page ranking thing. The idea of context being more important even than the content of the actual information you're looking at. And if you examine how we use groupware or how we build word processing documents or slide presentations, media files, the whole bit there's a lot of context that were not allowing people to gather.

We don't allow people to annotate information freely and then collect those annotations. We have these sticky notes, KNotes or whatever, that you stick randomly in places on screen that aren't semantically connected to anything.

The contextual linking engine, which is called Tenor, allows us to start bridging that gap. It really starts allowing us to provide context-based, in other words informational or meaning based, searching and navigation on the desktop. And this is widely applicable from things like KControl and the relationships between the different panels to managing your files in a content manager to your address book: Who is Jane Doe andw hat is she associated with in your life?

So I think that is one of the really exciting, almost R&D projects that is happening right now within the Appeal project.

And then we've got things like NX from NoMachine. We're moving that technology forward and embedding it deep into the desktop. So we've got the art, we've got the branding, we've got the usability people peering hard at our interfaces and saying, "Where do these buttons belong?" as well as some really interesting hard-core technology that's emerging.

SPWow, that's just great, that's fantastic.
ASAnd we're looking to grow it as well. This isn't a closed project, a little cabal of 15 people. This is our first step. And hopefully in a year we'll have 50 people involved in twelve different projects working on whatever they do in KDE within these principles of beauty, interface clarity and technological creativity.
SPDo you have a system for people to try and join or is this more or less an invitation only currently or how do you intend to get more volunteers?
ASWell we're working on how that's exacty going to work right now. We obviously don't want it to be a chaotic stampede. We're still working out the details of our own culture really. If we had a stampede of people come in it would rapidly become unmanageable and we're really not trying to recreate the wild herding of cats of Open Source development, which really serves a purpose but it breaks down when you're trying to do certain types of focused development. So right now it's probably going to be a let's discuss what you're doing, what's your project do, are you interested in working in a directed, focused kind of manner with these principles and just kind of finding where the synergies are. So I think it will grow organically, but it will certainly be something that grows in a measured way just to avoid growing to such an extent that it just falls apart for lack of definition.
SPThat's just unbelievably cool, everything there. I can't say how much I appreciate you letting me do this interview with you, Aaron. It's been really great.
ASThanks for having me on the show. I've been listening to the show since you started and I really like it, so I'm glad to be here.
SPWell, thanks and have a good day.
ASYou too.
SPOk, bye.