Nine things KDE should learn from Mac OS X

[Eric Laffoon]

Sorry to respond to this so late, but I'm catching up on old emails today.

On Tuesday 09 August 2005 3:22 am, Benjamin Meyer wrote:
> 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.

Were you in Malaga? I didn't get that beer. ;-)
>
> 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.

I don't disagree. However some of the tools we need to make that happen are 
only now becoming available. I can't realistically take the position of a new 
user approaching Quanta now because of all the years of involvement, but at 
least in years past I have had a lot of new users give me positive feedback. 
As there is tremendous depth to the application much of what has been added 
is not really obvious just opening it up. It's a paradox that having a great 
deal of functionality requires orders of magnitude more genius to to make it 
look really simple and still have the power easily accessible. That is one of 
the things we're addressing now.
>
> > 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.

I don't know how to respond to something like this. I have no reason to doubt 
you, but yet I still see new users sending me emails and we have around 500 
users on our mailing list. This is crucial for us because we use many of 
these users as a sounding board for our development version and we use the 
discussions and questions from new users for input. After all that it seems 
we could benefit from even more input because there is a lot to look at.

My challenge is in whether I can get specific data from you. Currently I don't 
get too many complaints about figuring things out and I see feedback 
indicating people do. As far as I can tell the representative data indicates 
some people don't acclimate, but in most cases people coming from other 
editors find in a matter of days that Quanta exceeds what they had. However 
you said you do your web development from the console. I'm trying to imagine 
what tools I'd be using in console, like scp and Vi... I'm going to have to 
say that I would guess 95% or more of our new users would be far more lost 
there and possibly this is key to the discussion. My personal philosophy is 
that the command line is better for some things which is why we have user 
definable Actions, but Quanta remains still quite visual.
>
> > 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?

I think Andras answered that and they are good questions.
>
> > 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.

Then my answer should. ;-) Aaron was not actually developing web sites. In 
order to effectively review a tool you must first know certain specifics 
about the use of it. I was not explaining the interface to Aaron. I was 
explaining why the interface decisions had been made relevent to the tasks 
that were being done. There's a big difference.
>
> > 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?

Yes and no. Yes, a relatively simple and functional interface should be the 
default when possible. However there are other factors, not the least of 
which is that what I described above is how we will address this in Quanta 4 
in KDE 4. Beyond that there is the classic question of "what don't you need?" 
which of course is different for pretty much everyone. The purpose of what I 
described was to enable either a user or a project leader to customize the 
interface for their roles and tasks. An attempt at this in a generalization 
would be as broken as showing everything but for different reasons. A better 
solution would be on initial start up to ask the user to answer a few 
questions and then from that select, or offer for their selection from a 
short list, an initial default or set of task defaults to be available.

I definitely agree with Aaron here that simplification and a stratified 
interface is too difficult to get right, but I would say that is largely 
because it has traditionally been an authoritarian A or B choice.
>
> > 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....

I still remember saying it... You may think you know what I said but I don't 
think you know what I said. ;-) Inherently the incorrect word is "only" and a 
logical evaluation will demonstrate it's incompatibility. If a team of 20 
people can each have custom interfaces why would you conclude an individual 
could not have the same? As far as the days of training... It would be great 
to pick up some consulting to subsidize development. We could use it. However 
once this is in place users will be able to share their configurations via 
KStuff which will mean that we should (hopefully) have an emberassment of 
riches in configurations for roles and tasks to evaluate. It will be right 
click and upload or right click and download.

The fundamental aspect to consider here is that it is not possible with our 
resources as developers to compete on this level and it's not possible to 
recruit enough developers... It is possible to enable the user to be able to 
contribute by making an extremely extensible platform and making the process 
as easy as pointing and clicking. So even if we hit a release with less than 
what we want we can still have an initialization routine that looks for a 
connection and offers a selection of recommended configuration to 
automatically be installed. Even if the customization is easy for our 
experienced users, our new users should be able to simply select options from 
community driven resources.
>
> 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.

See above. In fact the last thing I want to do is be responsible for the bad 
habits of others which is why I want to have as little control over this as 
possible. ;-)
>
> 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
We will be working on design for KDE 4 and we will be working within the 
KDevelop framework. It provides a lot of advantages and helps us eliminate a 
lot of duplicated effort. You're welcome to get involved in helping us with 
ideas. I think you've given us a few good ones already. We also have to keep 
in mind that we have a huge user base, probably hundreds of thousands if not 
over a million. These people have specific expectations. Much of what we have 
done started with my wanting a tool based on my experience in high pressure 
contract web development. Our objective is to win over the serious web 
developers in the world to run Quanta on KDE. I want to remain as friendly as 
possible to new users, but I'm also glad there is a new web development tool, 
Redwolf, on KDE. While I want to succeed at being everything to everyone, 
doing it for a more focused target is a less monumental task that I could 
learn to live with. ;-)
-- 
Eric Laffoon - Quanta+ Team Leader 
http://quanta.kdewebdev.org