Interview with the KDE and Gnome UI/Usability Developers

This article we host here today is a must read for all Gnome and KDE users. We are happy to feature an exclusive interview with Waldo Bastian and Aaron J. Seigo from the KDE project and Havoc Pennington from the Gnome project. Waldo and Havoc are developers working on many “under the hood” places of their respective DEs, but they are also “sensitive” at UI and usability issues, so we could also call them “usability engineers”. Aaron is the head of usability in the KDE project. All three of them were… brave enough to answer twelve hard questions about interoperability, standards, UI etc. between the two leading Unix DEs. Note that this is not a Gnome Vs KDE article, it is in fact exactly the opposite: ‘KDE for Gnome‘ and ‘Gnome for KDE‘. The begining of a deeper collaboration and sharing that will bring the Unix desktop into a new era.

Note: We asked Seth Nickell, the leader of Usability for the Gnome project, to participate in this interview, but Seth is busy lately with other things (after postponing the publication of this article three times we still haven’t got his full response back). If and when Seth finds some time to answer all the questions, we will be posting them too.

1. Some users want infinite number of options and preferences, while others prefer a non-bloated interface where the best options for them is already decided by the system. Now, we all know that there is no such thing as the
“Perfect UI”, but would it be acceptable to sacrifice certain configurability and… bloat –with the possible outcome of losing some users– in order to provide a cleaner interface? Do you think such a move would simplify things for the user or do little but rob power from those who know enough to use it?

Aaron J. Seigo: Addressing the overall usability of an application or environment in terms of
“number of configuration options” is rather naive. Most people use whatever
the default settings are and only interact with the configuration systems
when the default settings are not what they need or want.

The sad irony is that the people who lose out the most when configuration is
limited in an ad-hoc fashion are those who care about configuring their
software in the first place. Those who don’t are rarely affected one way or
the other. Default configurations are therefore a much more interesting and
useful discussion as they effect everyone.

In that vein, it is our challenge as technology creators to deliver what our
users need and want in a way that actually works; we can’t shoehorn people
into the mold of our personal comfort zones. In the world of open source
development, our usability lab is much closer to our development offices than
is generally typical. In such a cooperative and open environment the question
to the answer of “how much is enough” manifests itself naturally if you let
it. This does not mean effort is unnecessary on the part of developers, but
rather that oligarchical scheming and Grand Unified Opinions are.

It disheartens me when I see a “developer-knows-best” attitude as it almost
always lead to “too many”, “to few” or just “the wrong” options for the users
of the software. Listening to and watching our users in action, I observe
three types of requests:

* Options, options and more options, please!
* Make it easy to use these options!
* Make the defaults sensible!

I almost never hear from actual users, “Hey, can you remove a bunch of these
options?” So that is our mandate: to make it easy to access featureful
software. This may not be the easiest path available, but it is the most
rewarding. Anyone clammering for across-the-board removal of options is
simply not in touch with our user base.

Of course, this does not mean that we should add every single option
imaginable or that we should make everything infinitely configurable. Not all
options are created equal, and you can oversaturate a system with
microconfigurations to the point that it becomes unmanageable. Some options
are the result of developer indecision, some are band-aids over bugs that
should be fixed, while others are clearly at odds with the overall design of
the software. But the majority of options are worthwhile and there because
they were wanted or even needed by actual users.

Havoc Pennington: My opinion on this is pretty well known.

It’s all about balance, as I say in that article. The question is not
whether configuration is good or bad (some people reduce the argument
to this), but about which configuration you have, and how you decide.
Claiming “all configuration is good” ignores real tradeoffs – not just
with simplicity, but also with stability and speed of development.

People miss that GNOME is still more configurable than OS X or
Windows, even though I talk about how it’s moved the configurability
tradeoff back into the realm of sanity. You have to keep things in
perspective.

Waldo Bastian: Configuration options have a cost, they make the software more complex and
complexity leads to bugs. More configuration options also makes it
increasingly difficult to write good user interfaces for them. On the other
hand configuration options can help to make the software perform it’s task
better for specific users. As a developer you have to balance these two
conflicting demands, for each extra configuration option you have to ask
yourself, is it really needed, does it really improve the overall quality of
my application?

If a configuration option adds very little extra value to the application but
stands in the way of a usable interface then I think it can be justified to
remove it. But that should be a last resort, the first goal of improving a
user interface should be to optimize usability while preserving all features.
Presenting the available options in a way so that they aren’t overwhelming and
form a logical and coherent whole.

2. Microsoft has a widely-used Windows certification standard, and Apple
has long been known to strongly encourage developers to follow its
guidelines and standards. Has your group considered creating an official
“stamp of approval” for applications, assuring potential users that certain
rules are obeyed and certain functionality present for the sake of
consistency?

Aaron J. Seigo: Applications that are shipped with KDE are required to follow the KDE
guidelines and standards, so obviously the project understands the importance
of such things. In fact, a tremendous amount of effort has gone into
codifying as much of these standards as possible in the KDE foundation
technologies so that it isn’t necessary to burden individual developers with
the task of compliance. This guarantees users get consistent applications
when they are built on KDE.

To me, that’s much more impressive and important than a certification system,
since it addresses the problem directly rather than poke at the symptoms.
This is especially poignant in the Free software world where the motivation
for achieving a “certified KDE” sticker would be far less than it would be in
the commercial development world.

Havoc Pennington: I think this would be unrealistic right now, because there’s no one
who would have the substantial time required to do the evaluation
work. But it’s certainly something we’d like to have as usage of
Linux/UNIX on the desktop grows.

Waldo Bastian: There is certainly a strong encouragement to follow guidelines and standards
within KDE. Consistency among applications was one of the major driving
forces for the creation of the KDE project. We try to achieve that both
through the KDE style guide, which was published several years ago already,
and by offering standardized solutions through the KDE framework. Especially
the latter is very effective.

We have considered creating some form of unofficial “stamp of approval” or at
least “rating” wrt standards compliance of applications but so far we haven’t
been able to find enough manpower to pull that off.

An “official” stap of approval is even harder in that respect since it would
put much higher demands on such process with respect to issues as fairness,
objectivity and processing time.

3. FreeDesktop.org is a very useful organization, created to do what in my
opinion should have been done years ago… I can’t help thinking how things
can work out though (in order to unify the two desktops in a way that brings
consisntency to the Unix desktop), when the two HIGs are not compatible. For
example, the OK/Cancel order in a window just to name one and change all the
third party apps to comply with any new rules, can be quite time consuming,
if not possible. How can the FreeDesktop bring interoperability between the
two DEs with such issues at hand?

Aaron J. Seigo: FreeDesktop.org has already brought KDE and GNOME closer together in terms of
interoperability when it comes to things that really matter like the
clipboard, so there is no question about it having already been a benefit.
But FreeDesktop.org is not a source of magic solutions. There will most
likely continue to be differences when it comes to interface details for the
foreseeable future. The situation is similar on other contemporary platforms
as well, so I don’t know if this is really a problem to be too concerned
about though it is something I’d like to see addressed over time. This is why
I helped start the Open HCI project which is currently in its earliest of
days.

Of course we are ultimately at the mercy of the individual development teams
and their developers. If one group decides cooperation, consistency and
user-centric solutions are more important than achieving their own
interpretation of an aesthetic world, then everyone benefits (including the
developers). When users and developers support the project(s) which have
values similar to their own, this reinforces “good” decision making and
removes mobility from those making “poor” decisions. Having more than one
project for people to support makes this process fault tolerant.

In other words, grass roots user and developer support is more potent than
FreeDesktop.org alone can be in these matters. In turn, FreeDesktop.org needs
to reflect those broader interests to be effective.

Semi-off-topic sidebar on the Ok/Cancel issue: KDE has implemented things in
such a way that allows all KDE applications to have the order of these
buttons flipped with a change to a single line of code. It is exactly this
sort of brilliant design that allows KDE to be so internally consistent. So
the question often comes down to whether or not we SHOULD make a change,
rather than if we CAN. Personally I think it is irresponsible to impose
personal aesthetics on your users in a seemingly random fashion by disrupting
the interface they know without *very* compelling reasons to do so.

Havoc Pennington: There are certainly benefits to each intermediate step. For example,
if all my apps work with the same “recent documents” feature, then
that is a big user-visible improvement (bug fix, really). It’s a big
improvement whether or not all orthogonal problems are also solved.

That said, the shared HIG problem is an interesting one and I’d like
to see some progress there. Seth and Aaron are just starting on it so
I’m optimistic.

Waldo Bastian: There are always solutions possible. However, instead of focussing on the
hardest issues, I think it is much more productive to focus on those areas
where results can be achieved relative easily. 100% consistency between the
different enironments doesn’t come overnight, it will be a long process, but
I’m convinced that we will also be able to solve the hard issues somewhere
along the road.

4. Some systems, such as Mac OS X, hide the directory stucture from users
who don’t purposefully look for it. However, products such as Konqueror and
Nautilus currently do not do this, and almost flaunt it with address bars in
the file manager and so forth. Do you forsee more “hiding” of the Unix
underpinnings in the future, or would you prefer to expose users to them?
Also, how has Apple’s OS X interface influenced you, if at all?

Aaron J. Seigo: I foresee both happening simultaneously. No to sound too Zen about it, but
there is more than one path that leads to the top of the mountain. As there
are benefits to various amounts and types of exposition depending on the
particular use case, rather than simply choose one level of abstraction we
need to decide when and how to abstract away the underlying details and when
to allow easy but direct interaction with those details, preferably with the
user in control of that decision.

Today there is room for improvement on both ends of that spectrum. So I expect
in the future we’ll some developments that help insulate the user from gross
detail, while other developments work on reflecting the underlying OS more
accurately in the interface.

As for OSX’s interface, for me it was a lesson in user respect and self-confidence, both good and bad.

It’s taught me that no matter how well you’ve done in the past, you can still
make amazingly obvious and stupid mistakes. Everyone is fallible and nobody
has all the answers yet. It also showed me that when you take away options
you disenfranchise your users: look at how many things were added back into
Jaguar due to user demand that had been removed in 10.0.

It’s also taught me that eye candy is a more important part of the user
experience for most people than I had previously considered. They’ll put up
with dreadfully slow start up times and all sorts of “dot-oh” interface
blunders if it looks like a visual masterpiece.

Finally, it showed that you can introduce radical new concepts into an
interface that have real benefits (such as dialog sheets) and users will grok
them even if they aren’t available in other popular interfaces. So we
shouldn’t be too afraid to introduce new UI concepts.

Havoc Pennington: I think more hiding is generally appropriate, yes. In star trek
future, something better than a hierarchical filesystem might be
nice. In the meantime, users don’t want to see /usr, in the
general/default case.

Regarding Aqua, when doing a new UI component, we generally survey existing UIs in that area; for example here you can read about the new GTKFileSelection.

So OS X usually factors into those kinds of discussion.

Waldo Bastian: I see it as a similar issue as wit the command line. Users shouldn’t need to
know about it but it should be available to them when they so desire.

5. What are a few things you like and dislike about the Windows XP
interface? Additionally, Microsoft is pursuing the “task-based” interface.
What do you think of it and how well could that work in practice?

Aaron J. Seigo: I’ve used Windows XP for a scant total of 2 days, so I’m anything but an
authority on Windows XP. Due to the closed nature of Windows XP and the fact
that it doesn’t provide me with the features I need nor run the applications
I use I don’t have any need for it.

I will say that during my brief time with the system, I found the file manager
pleasant to look at but horrible to use: it imposes too much of itself on the
user without offering enough in return. Most laughably, I could not move a
music file from the desktop while it was being viewed in the file manager. I
would suggest to Microsoft that they fix those sorts of problems first before
spending any more time on their embedded photo album view. The new start menu
is also an abomination. In fact, those two days with Windows XP reminded me
why most people hate computers. I’d hate them too if that was all that was
out there.

Like any potentially successful methodology, task based mechanisms have their
place and can be very effective when applied to an appropriately task based
problem. Task based interfaces can be quite good but they can also be quite
out of place and/or implemented poorly. I really don’t know how XP stacks up
in that regard.

Havoc Pennington: XP seems to have lots of nice small details, but is overall a bit too
complex. The task-based interface looks interesting, but I’ve never
tried it out or seen a detailed analysis of how it works.

Waldo Bastian: I am not familar with Windows XP.

6. Recently, we have seen a few attempts to help users better store and
organize their files, and there have been two extremely different
approaches. The approach taken by the BeOS, among others, was to provide a
general framework from which the user could organize files in rather
powerful ways (by using file system attributes). The other approach, taken
most strikingly by Apple, is to provide filetype-specific applications to
manage the files (such as iTunes managing a database of all your music, and
iPhoto your photos, etc.). Which do you think is the better approach, and
to what extent, if any, do you see [your project] adopting those practices?

Aaron J. Seigo: You’re asking whether metadata management belongs at the OS level or on the
application level. The benefit of it happening at the filesystem level is
that it can be fast and universally available to all applications, but at the
expense of portability and flexibility. Leaving it to the applications allows
more flexibility, portability and choice but makes sharing the results
between applications harder. I think both of these approaches leave much to
be desired.

Another approach is a hybrid class of program that sits below the user
application level but above the filesystem. This allows choice, availability
and portability. Such a program would offer collections of data from and
about the filesystem and other programs would provide an interface from which
to view and interact with these collections. The inklings of this can be seen
in the KDE KParts and KIOSlave technologies. There is more to be done, of
course, but it is the most promising approach I’ve yet to see in actual use.

Havoc Pennington: I think GNOME is following the Apple approach at the moment, though we
also do have “emblems” and other file system attributes, they are
underused.

My intuition would be that most users are a bit lost by the filesystem
concept, and making it even more complicated than files/folders
doesn’t necessarily help. While a dedicated application can do a lot
of nice things automatically and is based on the task the user is
trying to do – play music, organize/retouch their photos.

7. The biggest problem I personally see today with all the X11 DEs when
compared to OSX, BeOS, OS/2 and Windows, is the pretty much non-existant
integration to the underlying system. No X11 DE “truly knows” about the
system, its drivers and configuration, or how to deal with them, as every
distribution/Unix has its own way of making the OS work. Is there a way to
bring these DEs in a status where they “understand” the system and provide
preferences/settings or application behavior/features that normally the
distribution would have to provide? For example, there is a “mouse” panel
under Gnome’s preferences configuring the options for the mouse driver used,
but there is also “mouse” panel under the “system settings” Red Hat menu,
this time about the driver itself. This is a necessary additional step from
the distro maker to add more similar panels, as Gnome and KDE don’t know how
to deal with the system itself. But in order to create a low-bloat,
consistent and integrated interface that makes the usage of the OS easy, the
DEs will have to learn about the system and use it accordingly. What is your
opinion on this, and how could this be achieved when we have so many
different and sometimes incompatible distributions (despite LSB), while not
even counting the BSDs, Solaris, IRIX and AIX ports.

Aaron J. Seigo: Underlying this is the same issue underlying question #9, which I’ve answered
below.

Havoc Pennington: I believe this can be done, but it is highly nontrivial and no one has
really attacked it with the level of seriousness required.

The first task is to figure out how to present the root/user split,
and the idea that some settings will affect all users and some will
affect only yourself. The coward’s way out, in my view, is to just
have people log in as root. The reason I think this is bad is that it
throws out a big reason Linux is *better* than Windows, our
competitive advantages: manageability and security. If people are
logged in as root they can break the system much more seriously
(reducing stability), as well. So I think it’s OK to ask users to
understand the multiuser nature of the OS on some level; but I’m not
sure what the best way to present it is.

After figuring out the UI we want, it’s more or less a simple matter
of coding. I’m hoping that some new technology such as D-BUS will be helpful here. It will give us a way to pop up a dialog triggered by kernel events, for example – something we haven’t really had in the past.

Waldo Bastian: I think system integration is a very weak point of Linux. On one hand there is
the fragmentation in terms of user inteface (GNOME, KDE) and on the other
hand there is the fragmentation in terms of distributions which all tend to
do things differently (not to mention non-Linux operating systems)

The result is that system integration comes mostly down on the distributor.

There have been several attempts to create “standard” configuration tools by
different groups but none of those have been widely adopted across
distributions. I’m pessimistic about this area since I don’t think the
current mainstream distro’s are willing to change this given the investments
they have done in their own set of tools.

8. Both DEs (especially KDE) come with a large number of applications to add
in the mix. This is convienient for the user, but do you find it necessary
adding applications with each release? What about the issue of including
applications that do similar things? (e.g. Kate, Kedit, KWrite).

Aaron J. Seigo: I’ve never heard people worry about having too much application choice for so
little cost before. In fact, I distinctly remember a time when the complaint
was exactly the opposite. It amazes me what people will choose to worry
about.

A desktop is useless unless it enables you to get your work done, therefore it
should be our aim to provide people with as complete a solution set as
defined by the general needs of the userbase (as oppose to, say, our personal
opinion). Nobody is required to use or even install every available
application included with KDE, but unless they are available the environment
is that much less attractive and useful to at least some segment of the user
base. The proliferation of quality applications that fulfill real world user
needs is vital to our success. The importance of this can not be understated.

Outside of the official KDE distribution, competition between different
efforts can be a great things. Cooperation can often be even better, of
course. But within the base KDE distribution duplication of features is kept
to a minimum and generally frowned upon.

You offer the example of KEdit, KWrite and Kate, but all of those apps do
something quite different. KEdit simply edits plain text files, nothing more
and nothing less. KWrite is a source code editor for programmers while Kate
is a light-weight IDE. So why do all three exist? Because there are three
different types of users and use cases which are best served by each. This is
the difference between user driven design and “developer knows best” design.

Havoc Pennington: I pushed for GNOME to come in small modular tarballs, and generally I
like to see independent, healthy communities writing each GNOME app in
parallel. GTK+, AbiWord, Gnumeric, etc. all have large communities of
developers with release schedules that aren’t tied to GNOME.

Originally this made it kind of annoying for users to build GNOME, but
we’ve addressed that via tools such as jhbuild and GARNOME.
Plus most people use a distribution version anyway.

My feeling is that if an app has to come with GNOME in order to get it
properly integrated with the desktop, we have a model that’s not
scalable; it will have to bog down at some point as the Linux desktop
becomes more successful and there are more and more apps. A scalable
model is based on documentation, guidelines, APIs, that anyone can
pick up and use without having to release in sync with GNOME proper.

So I like having the GNOME project itself focus on the “desktop and
developer platform” release which is just the libraries and the
desktop shell, more or less. But we also have the GNOME Office
release, and the “fifth toe” add-on apps release, which are on
separate release cycles.

Waldo Bastian: Just because KDE releases an application doesn’t mean you actually have to
install it 😉 Until recently we used to put applications in large modules
and those tended to end up in single binary packages. The reason for that was
that that is easier to manage from a development point of view, and our users
liked the limited number of packages they had to download to get a complete
set of applications.

Since last year we have changed that course somewhat, we keep the large
modules that we have as much as possible but new applications are now mostly
added to “KDE Extra Gear”. The extra gear applications are supposed to be
released according to their own schedule and packaged as single binary
package so that users can choose per application whether to install it or
not.

9. Despite the advancements of RPM handling, apt-get from Debian and
Gentoo’s Portage, users are still not comfortable downloading applications
and easily installing them. Either dependancy hell (RPM) when downloading
apps from the web, bad interfaces for apt-get (Synaptic is not what I would
call “niiice”) while Gentoo itself is a nightmare to install for new users,
makes the installation of… random Linux applications pretty impossible for
new users. With all the advancements recently, this domain is still not as
easy as in Windows, OSX or BeOS. Do you think that the DEs themselves should
require a special packaging (doesn’t have to be a new technology or
something different than RPM or apt) that somehow elliminates the current
problems and adds visual un-installation, ability to install a package
without the need to be the administrator, or automatically categorize the
installed application etc? In essence, could the two leading DEs “force” the
Linux distros towards a common standard which will be modified in a way
that elliminates most of the problems mentioned above?

Aaron J. Seigo: This question is applying old-style thinking to problems in a new space. There
is a near zero chance of KDE and GNOME, even together, forcing anything on
operating systems integrators if they don’t want it. The Linux distributions
already modify KDE to their will, sometimes with good results and other times
to the detriment of everyone involved.

While this lack of leverage on the part of KDE and GNOME may seem like
impotence, it actually is a strength since it allows divergent systems to use
the same interface. Thanks to this agnostic principle I can use KDE on any
Linux, BSD or UNIX (including MacOS X) I wish.

The real problem is not with KDE, since it is actually the perfect incubator
for safe cooperation on the UI level between the OS vendors. And *that* is
where the real problem lies. The OS vendors feel it is perfectly allright to
modify (or “fork”) the desktops to suit their own needs so as to create
artificial benefits over their competitors. They should instead realize that
KDE represents an opportunity to work together within a larger vendor neutral
community to create consistent and more compelling systems at a lower cost to
each of them individually. Instead of differentiating each from the other,
they should be differentiating together from the real competitors: Microsoft
Windows and MacOS X.

This if Free Software 101, and I am completely baffled why the likes of Red
Hat, Mandrake and SuSe don’t seem to get it. Perhaps because the desktop
space is a new-ish phenomenon in the Open Source world, since they
deffinitely get it when it comes to server and systems software.

Havoc Pennington: I don’t think this is feasible. For one thing, a packaging system is
an extremely nontrivial undertaking. For another, there is no way you
could move existing distributions off their current systems.
Finally, it doesn’t make a lot of sense to have two packaging systems
at once (the distribution one, and the desktop one).

The road I think we have to take instead, is to add better integration
with RPM/dpkg/etc. – possibly extending those to give the UI the
information it needs to make things nice.

Another key issue in this area is that we have to make the LSB a
reality, so software can be provided in distribution-neutral RPM
packages as described in the LSB. Right now, most software comes as
source code, or as a tarball with binaries, because that’s the only
cross-distribution method. And obviously that distribution method is
hopeless from a UI standpoint.

Waldo Bastian: KDE limits itself to providing source code and most of our binary packages are
provided as courtesy by the major distributions (with Red Hat being a notable
exception), as such I don’t think we are in any position to set a standard
wrt binary packages.

10. Windows Explorer was among the first file managers which tried to be
more than just that. Nautilus does a lot these days, but Konqueror has
surpassed all, adding a lot of functionality and adding literally the
kitchen sink. Do you believe that this is the way to go in the future for
the file managers or does it lead to bloat and to unesessary functionality
(functionality that could be served by individual apps)?

Aaron J. Seigo: Konqueror is not a single application. It is an interface through which
hundreds of individual components cooperate to offer a full user experience.
If that sounds familiar, it’s because it is: the UNIX shell does the same
thing for command line interfaces. Where Konqueror goes one step further is
that the functionality it offers “just works” based on context without the
user having to explicitly command it to do something special, although the
user is still fully empowered to do just that.

The vast majority of the functionality in Konqueror is either provided by or
available to separate applications, so this is not an either/or situation.
You can do many of the same things from within Konqueror as well as in
separate apps, because they’re the same thing in KDE. There is no distinction
between an application and a component for viewing or editing.

This march towards radical componentization of the desktop will only continue.
Already we have reached the point where people, even those who are quite
aware of interface issues and design, stop distinguishing between individual
applications and instead simply experience the desktop as a coherent entity
doing a lot of great and cool things.

Sounds like a very compelling desktop computing paradigm to me.

Havoc Pennington: It depends. Having views such as a “photo album” in the file manager
makes sense to me. I don’t think having the web browser in there
necessarily does; my file manager and web browser just don’t have that
much overlap (in Windows, IE hardly looks like the file manager, even
though I guess they share code in some way). Epiphany and Nautilus are
both quite clean and simple alone but the merger would be sort of a
mess.

Waldo Bastian: I think it is Mozilla that has a kitchen sync, I haven’t seen one in Konqueror
yet.

Konqueror has a very modular design so it is possible to add lots of optional
functionality without bloating it. On the other hand I have always advocated
that Konqueror is a browser and functionality that doesn’t fall in that
category doesn’t belong in konqueror.

11. Personally, I see Linux getting a big boost in the UI and desktop
experience via the “one DE”. Having more than one, gives the user choice of
course, but it can be inconsistent and prone to incompatibilities between
the various distros and Unices. The “less is more” approach has been taken
by Be, Apple and MS with quite some success judging from the desktop
experience they offer, so I kind of lean in this direction. Now, I don’t
mean to dismiss any of the two DEs, in fact, I would like to see both
thriving, but what I would really want is to have a single desktop, with
absolutely compatible development frameworks, one based on GTK+/gnome_libs
and one on Qt/kde_libs (and why not add more to the mix? Development choice
is good). Pretty much, is like saying that we have the Win32 API and the MFC
API and the .NET API, but at the end, no matter with what you compiled or
developed your application with, the end result application will look and
behave the same as all the other ones, under this “one” DE. Do you agree
with the prospect of such a “unification”, or does it sound too extreme (or
simply “the OSS world is not ready for something like it yet, if ever”)?

Aaron J. Seigo: I have a unified desktop. Everything looks and works the same and I get
everything I need and want done accomplished by using only KDE and command
line applications. I may well be able to do the same with a GNOME-only
desktop. I understand that not everyone has all their needs met in such a way
yet, but that just means we need more applications not that we need to
destroy all hints of variety between the applications.

Or should MacOS and BeOS and Microsoft Windows all become a single interface,
too? The way I look at it is that the situation on Linux is like being able
to run both MacOS and Microsoft Windows on the same machine simultaneously.
Yes, the applications are different looking and I can choose to stick with
one set of apps only, but I have the CHOICE to do so rather than being forced
to do so.

Are there people stubbing their toes and falling into comas because of this
choice? Or is diversity allowing us to explore the problem space more
effectively and to create an atmosphere of enjoyable and mutual coopetition?

Havoc Pennington: I believe it’s a perfectly achievable goal for apps written with
either GTK+ or Qt to nicely integrate with either desktop environment.

My hope for what will happen is that more and more infrastructure bits
(such as fontconfig, or the menu system) will become shared over time,
until basically what we have is two flavors of API (GTK+ and Qt)
for developers with different tastes, but desktop integration is using
the same mechanisms regardless.

At that point I’m quite sure we’ll always have lots of desktop environments (you’re forgetting XFCE, ROX, and many others).
I mean, look at the list of window managers.

However, one or the other may come to be the dominant environment.
It’s hard to predict that sort of thing. I don’t think the OSS world
will get to decide on this issue; I think it’ll be more of a market
decision. Since we really define “dominance” as “having most of the
users.”

Waldo Bastian: I think consistency among applications is very important. It has been one of
the founding principles of KDE. The original thought was that it was
achievable by offering a very compelling, advanced and easy to use framework
that everyone could use. The GNOME/KDE split pretty much killed that off
though. I think given the current situation, standards to ensure consistency
among application based on the two different frameworks is the only viable
solution to get consistency on the Linux desktop.

12. What major changes in user interfaces do you predict we will see in the
next five years? What steps is [your project] taking to accomodate this?

Aaron J. Seigo: Anybody who tells you what their project is doing to revolutionize user
interface in five years time is either lying or delusional. I’m more
comfortable pointing to what KDE has accomplished in its first 6 years of
life, especially its ever increasing pace of development and innovation. I
don’t know what the average computing interface will look like in five years,
but given current trends it is safe to say that KDE will be there and will
likely be the definition of leading edge desktop software.

Havoc Pennington:
I think they should tend to get simpler. Computers are still too
complicated, unreliable, etc.; they should be more appliance-like.
There seems to be a lot of consensus on this point, too.

GNOME is generally tending in that direction, though it’s all
evolutionary, not revolutionary. We are dedicated to time-based
releases, every half year or so – we aren’t going to go into a cave
for 3 years and rewrite everything.

Waldo Bastian: I think desktop user interface technology is very mature and I don’t expect
any major changes. We have this running gag in KDE that the window manager
should implement “(window) focus follows mind”, a breakthrough might happen
if the hardware people manage to make a reliable “mouse follows mind” device,
or at least a convenient working “mouse follows eyes” one. It wouldn’t
surprise me if it had been developed already for military purposes in which
case I don’t think it’s far fetched to predict that it will become available
as consumer product within the next five years as well.

Other than that I think that interesting user interface developments will
mostly happen wrt non-desktop related computer products.