[Panel-devel] The ALI: do we really need or want it?

Nicholas Kaye-Smith nkayesmith at gmail.com
Mon Jan 9 23:19:46 CET 2006


The goal of a user is to:
Handle data in a productive way.
or Make it possible to handle data in a more productive way.
generally speaking (where the word productive means the eventual
satisfaction of the user).

Since data and productiveness are at the center of these, lets look at these
two concepts.
Data can be navigated through a permanent hierarchy, a temporary hierarchy
or by searching to generate a temporary hierarchy..
Productiveness is all a measure of getting things done, and fast.

Lets consider it in a scenario.
1. A user comes to the PC. His/her goal is:
To listen to Beethoven's 9th Symphony
There are two interpretations of this:
The user is handling the data of Beethoven's 9th symphony, to a 'productive
end' (listening to it.)
The user is producing a 'productive end' through handling the data of
Beethoven's 9th symphony.

Personally, I think the first is more logical. That is, the data first. The
'ends' (the playing of the music) at the end.
The user can search for the data hierarchically (permanent or temporary), or
search.

2. User 1, being used to kde 3, searches for amarok. He used to access it
from the universal sidebar (through amarok.) He is not disappointed.

This is a case of the user searching the data in a temporary hierarchy.

3. User 2, being used to heavy use of konqueror, looks for it there. She
clicks on it, and amarok opens to play. User 2.1 wonders why a huge
interface should open for one piece(if she wanted more she'd open them in
konqueror.
User 2.5 is thankful and opens the rest of her pieces in amarok.

This is a case of the user (User 2.1) searching the data in a permanent
(where changes are only done when triggered by the user, that is) hierarchy.

4. User 3 wants to get in the search thing. Opens up beagle, tripping over
the kat on the way, and searches, "Beethoven's 9th Symphony". Something
comes up, she clicks on it, and amarok opens. She searches for the rest of
the music in amarok, or she searches for the rest of it in beagle.

This is a case of the user generating a temporary hierarchy by a keyword.


Looking above, though, it seems:
This is a case of the user generating a temporary hierarchy by a keyword.
This is a case of the user (User 2.1) searching the data in a permanent
(where changes are only done when triggered by the user, that is) hierarchy.
This is a case of the user searching the data in a temporary hierarchy.
(the reference to 'the kat' is not a insult to the kat developers, who are
doing a good job, but rather mandriva, who chose to include the a buggy
product in their distro by default)
Are not that different.

Data is taken from the user at search time to produce a temporary hierarchy.
Amarok's list is generated from data taken at play time to produce a
temporary hierarchy.
Konqueror's list is taken from the user when they want to give it to produce
a temporary hierarchy.
The only difference is where and when.

I think you need to unify the where and when as much as possible. Keep the
old methods, but have a method which is consistent for all types of data.

I'll leave you there are go onto a related topic: Action and Data.
When the user comes to, say:
To listen to Beethoven's 9th Symphony
They might either:
Email someone (about it)
Edit it
Listen to Beethoven's 7th Symphony.

The fact that they are in Amarok only helps them for the last point.
Even if the percentage is 60 % likely that they will stay in amarok, the
other 40% needs to be catered for.
Notice what comes first:
To listen
Email
Edit

logically, the action comes first. But hold on, also, logically:
The user is handling the data of Beethoven's 9th symphony, to a 'productive
end' (listening to it.)
The user is producing a 'productive end' through handling the data of
Beethoven's 9th symphony.

Personally, I think the first is more logical. That is, the data first. The
'ends' (the playing of the music) at the end.
The user can search for the data hierarchically (permanent or temporary), or
search.

It is because: THE DATA AND MEANS ARE INSEPERABLE FROM A USER'S PERSPECTIVE.

Back to efficiency

Given that the data and means are inseperable, and the kmenu (like amarok)
should learn what the user wants to do, the best approach is to neither
group data by means or means by data, but group data and means where
possible.
For example, it should have a way of displaying the 5 most popular datameans
and the user's pinned datameans.
Then, since there is obviously too much data, either data will have to be
grouped by means, or means by data.
I suggest data by means, because, as above, the user's thought process
starts with the action. (The goals of a user; above, are mentioned from a
developer's point of view).

Nicholas
Disclaimer: The above is my logical thought (combined with a bit of bias,
but mostly logical thought). You are welcome to flaw the logic, but please
don't shout and scream at it and expect it to go away.
:)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20060109/ba7a79a4/attachment.html


More information about the Panel-devel mailing list