Okular moving

[Friedrich W. H. Kossebau]

Hi Thomas,

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

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

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