Nine things KDE should learn from Mac OS X

[Eric Laffoon]

On Thursday 04 August 2005 2:03 am, Benjamin Meyer wrote:
> I have written up an article about Nine things KDE should learn from Mac OS
> X. A lot of ideas that we might want to use for KDE4.
>
> http://www.icefox.net/articles/kdeosx.php
>
> -Benjamin Meyer
From the article:
===
Lets taking a look at another KDE application. The other day I loaded up 
Quanta so I could see what has changed sense I last used it. Notice how much 
of the window is actual productive space where you can work on your document. 
A quick list of actions presented to the user: 
13 different top menus!
34 toolbar buttons in the primary toolbars
5 left sidebar things
2 bottom sidebar things
2 right sidebar things
6 tabs of toolbars on top of the edit window each with around 10 toolbar items
Tabs for each open file
Granted this isn't as bad as KDevelop, but still it feels like the developers 
tried to cram everything on the main screen to the point that I as a user 
have absolutely no idea where to look for things. I personally hate the idea 
of the sidebars and find it way to confusing, and to have them on every side 
of the screen is too much. Application do not need to present this much to 
the users on the default view and in many cases it is redundant. When I 
started clicking on buttons the entire screen started changing (as things 
showed and hid) and after ten minutes I gave up and quit.
===

There are relevent points here as well as a miss of what is relevent. First of 
all we did not try to cram everything in we could. Just the opposite. We 
agonized over what we could remove, but everything we tried to had arguments 
to keep it. In my opinion the biggest problem here is not having a mechanism 
in KDE to handle interface complexity in context. Things are there no matter 
what, but because of the nature of projects and our document parsing a high 
degree of specificity could be focused to the interface shown. In fact the 
diverse needs are extreme where you might be doing XHTML, then PHP database 
access then XML Docbook. Quanta Plus is a toolbox, and even if you're only 
using one tool at a time the right tool for the right job produces better 
results then the proverbial "when all you have is a hammer everything looks 
like a nail". ;-)

Not to diminish the point of it being busy, because I want to make it as 
simple as possible too, I'd like to express the counterpoint. First of all 
usability is not just your first few minutes, but also how well a program 
serves you as your needs grow. As such it's worth noting that our subject 
matter and diverse targets are not simple by nature. Yes, a little HTML page 
is simple, but no a maintainable web site is not, and there are infinite ways 
to approach this. Diverse tasks breed complexity, which is why I believe task 
and role managed interface personalities would be useful. The important point 
I want to make though is that the leading professional HTML web development 
tool on Windows is Dreamweaver. With the exception of graphics and some 
limitations in visual mode, which we're addressing now, many people are 
telling us that Quanta Plus exceeds the performance of Dreamweaver for 
professionals. This is significant and the only other desktop application I 
know on *nix realizing this degree of success is Scribus. I regularly have 
web developers tell me there is no alternative on *nix.

As for the rest, the sidebars can be collapsed and take little space. The 
sidebar on the left handles projects, something essential for managing 
uploads of a web site as well as supplemental features like templates, a 
structural document view and a script repository. If we remove these do we 
dispose of them or make the menus longer? What is there demonstrates it's 
usefulness in real world use and is praised by users who do web development 
day in and day out. Aaron Siego did some review of Quanta and after my 
explanation of our decision process concluded that our interface was 
applicable to our users. After all, if you don't care about markup and want 
something quick any word processor can export HTML. If you want W3C valid 
markup and PHP management we're an asset as the best of breed.

Let me explain the personality concept I have to address the issues of 
complexity you brought up. Ideally I'd like to be able to hand a Live CD to a 
content person and have them be able to edit and upload content without 
touching and breaking anything else and without even knowing what the site 
password is. I think the personality concept would be useful for more than 
just our application. I'm not against learning from OS X, but I think 
learning from analysis of usage and our objectives is the challenge of 
innovation. The following is an interface personality scenario with Quanta 
Plus. In a project there will be different people with different roles doing 
different tasks. A project manager could set a default interface for someone 
editing content. This is the person who will freak out with a complex 
interface. They can set up that role to:
* remove menus and menu items not relevent to the role
* remove docks or dock items that are not relevent
* set files that are visible for edit in the project
* set files that can be linked for preview and test configuration
Individually files or document types could have interface elements added or 
removed. An individual who just wants to do simple HTML could set a default 
configuration up, or choose from a list of example configurations.

While this appears to add complexity for the user it actually only adds it for 
developers. By strategically designing this into the UI with the intention of 
reuse several things could be accomplished.
1) Interface elements could be marked for configuration during development.
2) An interface configuration wizard could be made to walk through menus, 
panels, toolbars and such and create a configuration. These could load 
configurations to be edited and saved as new configurations.
3) Instant recall of personality configurations could be accessed from a 
settings menu or managed by mimetype or hidden data in a file index.
4) Users who like to tinker with these types of things could share personality 
configurations with other users or developers could make enhancements 
available for download.

The inherent problem of complexity is inevitable. Small applications lead to 
innumerable choices and leave you looking for what you need for a task. 
Components offer best of breed but create issues merging because they often 
fail to merge organically. Large monolithic applications do everything and 
doing many simple things creates a cluttered interface. I believe the 
solution is an intelligent management of components through task and role 
interface personalities. Best of all this allows maximal user modification 
and kills no sacred cows.
-- 
Eric Laffoon - Quanta+ Team Leader 
http://quanta.kdewebdev.org