Nine things KDE should learn from Mac OS X
sequitur at kde.org
Fri Aug 5 22:23:35 BST 2005
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.
> -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
More information about the kde-core-devel