Friedrich W. H. Kossebau
friedrich.w.h at kossebau.de
Fri Nov 17 15:16:22 GMT 2006
Am Freitag, 17. November 2006 13:41, schrieb Thomas Zander:
[secretary using msword as the one and only file manager]
> Where am I going with this?
Windows (and Word) are no object-oriented systems? :P
> Just because you can do something doesn't mean its a good thing to do. As
> an application developer you have the responsibility to find out, first and
> foremost, the problem the user tries to solve. Best described as the users
> goals. (Print one page, send a document to a friend).
And before finding out the problem the developer even has to get to know the
stakeholders and the domain. Like in a office environment what is a page,
what is a document, what is a image...
Problem with Windows and most of all other software not made for a single
customer: there is no glossary where the concepts are clearly defined and a
user/developer has a chance to grasp what all the things in the system are
meant to be and how to behave. And as that software is targetting as many
people with as many goals as possible it is by definition doomed to fail for
most of them by getting too complex/powerful. Happy software users are
randomly found, as far as I experienced.
Reminds me, that KDE needs a glossary, too. Both for developers and the
technical terms. And the user interface. Think of folder vs. directory etc.
Helps with consistency a lot.
> > I think this is the base that new features should be considered on.
> Placing a feature in the application where it makes most sense is another
> one. And 'most sense' is not where you personally think it should go
> because, as you know, you are not your user. Typical users look very
> differently on things, they make silly decisions and ask for silly features
> just to work around the silly decisions they made earlier.
> The lady from my example thought she had to work around some difficult
> concept by using Word to 'copy' a file.
Whose sillyness comes from not understanding the complex thing. So our goal
would be to make her smarter, so she would do/want less silly (in the sense
of the system) things. And making smarter can also be done by making the
appearance of the system less complex. E.g. by consistency. And clear
> Lets show people how we they can be productive by making applications
> simple, to the point and do what it says it does.
> Overloading a concept like a viewer with editing functionality just
> distorts the mental model of the way things work and it doesn't help the
> huge percentage of those users that has no need to edit and _just_ want to
> view the page.
It all depends on the presentation to the user. Why does she even need to know
the concept Viewer? Why can she not simply think of image, document or
whatever? Which has two states, modifyable and not. And there is a switch to
make it modifyable. Pressing it also makes some tools appear. Pressing it
again makes them dissapear and turns the state back to modifyable. Or
Programs are a concept for developers. And marketing people. But they do not
help users to operate in the virtual system, the virtual desktop.
> I'd say that finding out what high-level goal the user wants to accomplish
> and finding the best way (and app) to accomplish that is a much better way
> to consider which feature to add.
I fear the problem is that there are too many high-level goals.
> After all, what would KMail look like if we'd add adding images, and
> cropping and color adjustment etc. Just because we can.
> Very hard to use, thats what.
As you said people don't want to use a program, they want to get a task done.
Programs just implement support for it, partially or orchestrated with
others. Why should KMail not support these things if people need it? Based on
a plugin concept? With an ui that adapts to the current task?
KMail is a good example, where program-centric get's in the way: Many use
emailing for sending files around to have others edit/add things to them and
send them back. Now how well supported is this? It's a mess. Instead KMail
has support for mailing lists, even though only 5 % are using it. Who uses
filters, except power users? If KMail would have been designed to
interoperate more with other programs/plugins, there could be now ways to
adapt to each ones' typical usages, without making things complex for others.
The current implementation of hardcoding things, displaying all options in
text menu bars and button bars simply doesn't scale with powerful integrated
systems. Time for new approaches. Drop hardcoded monolithic programs. Go for
modules. This modularity would allow to build systems really customised to
the individual tasks of peope. Ruby, Python, & Co. would nicely come in play.
Tobias cited the famous UNIX philosphy, one tool for one task. Exactly.
But the real power of these tools is, that the sum of little small things is
greater. And those tools are usually used together, not alone, piping data
from one tool to another. And typical orchestrated tool usages are fixed in
scripts and simply called by name. So even KPDF is already too bloated to be a
single tool, you can "grep", "less", and "cat > lpt1" in the same program ;)
Oh, I have a really strong opion on that, sorry.
More information about the kde-core-devel