Nine things KDE should learn from Mac OS X

[Benjamin Meyer]

On Friday 05 August 2005 09:23 pm, Eric Laffoon wrote:
> 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". ;-)

Before I respond... Wow, a well though out reply!  Let me buy you a beer for 
that alone rather then a quick emotional reaction.  koodos.

Yes I understand that the application can do a lot.  In fact that is why I 
launched it to try it out.  I do all my web development at the console so I 
wanted to see if Quanta could help out.  But as someone who had never used 
Quanta I was very confused.  Maybe Quanta just is too powerfull and a new 
user has to read the manual before it can be used.  I personally think that 
by _default_ applications should be simple for new users to learn (and to 
grow my/your userbase). As they explore the application it is forgiving.  

> 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.

Yup, heard the same thing here, lots of praise all around.  That is why I was 
so disappointed that I couldn't figure out how to do anything.
 
> 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.

Why is "Document Structure" on the left then?  Shouldn't it be on the right 
with "Attribute Editor"?  And shouldn't Documentation really be called 
"Reference" and be on the left?

> 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

I am sorry, but your interface shouldn't need to be explained.

> 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.

Shouldn't this be the default?

> 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.

Sorry, but I just don't buy it.  What you are saying is that Quanta is only 
good for those who are building huge sites with twenty people working on them 
and everyone gets several days of training and the manager customizes 
everyones application....

Application customization is great, but you want a default that can apply to 
the most number of people, which for an application like Quanta would be new 
users.

Or for a completely new idea how about rather then having one large window 
that tries to do everything what about breaking it up into two windows.  The 
main window is the project management, and you have a separate editor window 
for the currently opened files.  The editor window could even look like Qt's 
designer with all the tags on the left (rather then 6 tabs of toolbars) and 
the Document Structure and Attribute Editor on the right.

-Benjamin Meyer