[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: [Panel-devel] The ALI: do we really need or want it?
From:       Nicholas Kaye-Smith <nkayesmith () gmail ! com>
Date:       2006-01-09 22:19:46
Message-ID: 273997e40601091419qdeadfdcx () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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 thes=
e
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), o=
r
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 produc=
e
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), o=
r
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 datamean=
s
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.
:)

[Attachment #5 (text/html)]

The goal of a user is to:<br><span style="font-weight: bold;">Handle data in a \
productive way. <br><span style="font-style: italic;"><span style="font-weight: \
bold;">or </span></span><span style="font-weight: bold;"><span style="font-weight: \
bold;">

Make it possible to handle data in a more productive way.</span></span><br><span \
style="font-weight: bold;"></span></span>generally speaking (where the word \
productive means the eventual satisfaction of the user).<br><br>

Since <span style="font-weight: bold;">data </span>and <span style="font-weight: \
bold;">productiveness </span>are at the center of these, lets look at these two \
concepts. <br>Data can be navigated through a permanent hierarchy, a temporary \
hierarchy or by searching to generate a temporary hierarchy.. <br>Productiveness is \
all a measure of getting things done, and fast. <br><br>Lets consider it in a \
scenario.<br>1. A user comes to the PC. His/her goal is:<br><div style="margin-left: \
40px;">To listen to Beethoven's 9th Symphony  <br>There are two interpretations of \
this:<br><div style="margin-left: 40px;"><span style="font-weight: bold;">The user is \
handling the data of Beethoven's 9th symphony, to a 'productive end' (listening to \
it.)</span><br style="font-weight: bold;">

<span style="font-weight: bold;">The user is producing a 'productive end' through \
handling the data of Beethoven's 9th symphony.</span><br><br>Personally, I think the \
first is more logical. That is, <span style="font-weight: bold;">

the data first. </span>The 'ends' (the playing of the music) at the end.<br>The user \
can search for the data hierarchically (permanent or temporary), or \
search.<br></div><br></div>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. <span style="font-weight: bold;"></span><span style="font-style: \
italic;"></span><br><br><div style="margin-left: 40px;">This is a case of the user \
searching the data in a temporary hierarchy.<br><br></div>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.<br>User 2.5 is thankful and opens the rest of her \
pieces in amarok.<br><br><div style="margin-left: 40px;">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.<br><br></div>4. User 3 wants to get in the \
search thing. Opens up beagle, tripping over the kat on the way, and searches, \
&quot;Beethoven's 9th Symphony&quot;. 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.  <br><br><div style="margin-left: 40px;">This is a case of \
the user generating a temporary hierarchy by a keyword.<br><br></div><br>Looking \
above, though, it seems:<br>This is a case of the user generating a temporary \
hierarchy by a keyword. <br>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.<br>This is a case of the user searching \
the data in a temporary hierarchy.<br>(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  <span style="font-weight: bold;">by \
default</span>)<br>Are not that different.<br><br>Data is taken from the user at \
search time to produce a temporary hierarchy.<br>Amarok's list is generated from data \
taken at play time to produce a temporary hierarchy. <br>Konqueror's list is taken \
from the user when they want to give it to produce a temporary hierarchy.<br>The only \
difference is <span style="font-weight: bold;">where and when.<br><br><span \
style="font-weight: bold;">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. <br><span style="font-weight: bold;"><span style="font-weight: \
bold;"></span></span></span></span><br>I'll leave you there are go onto a related \
topic: Action and Data. <br>When the user comes to, say:<br>To listen to Beethoven's \
9th Symphony  <br>They might either:<br>Email someone (about it)<br>Edit it<br>Listen \
to Beethoven's 7th Symphony.<br><br>The fact that they are in Amarok only helps them \
for the last point. <br>Even if the percentage is 60 % likely that they will stay in \
amarok, the other 40% needs to be catered for.  <br>Notice what comes first:<br>To \
listen<br>Email<br>Edit<br><br>logically, the action comes first. But hold on, also, \
logically:<br><span style="font-weight: bold;">The user is handling the data of \
Beethoven's 9th symphony, to a 'productive end' (listening to it.) </span><br \
style="font-weight: bold;"> <span style="font-weight: bold;">The user is producing a \
'productive end' through handling the data of Beethoven's 9th symphony.</span><br> \
<br> Personally, I think the first is more logical. That is, <span \
style="font-weight: bold;">the data first. </span>The 'ends' (the playing of the \
music) at the end. <br> The user can search for the data hierarchically (permanent or \
temporary), or search.<br><br>It is because: <span style="font-weight: bold;">THE \
DATA AND MEANS ARE INSEPERABLE FROM A USER'S PERSPECTIVE.<br><span \
style="font-weight: bold;">

<br><span style="font-weight: bold;"></span></span></span>Back to <span \
style="font-weight: bold;">efficiency<br><br><span style="font-weight: bold;"><span \
style="font-weight: bold;"></span></span></span>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. <br>For example, it should have a way of displaying the 5 most \
popular datameans and the user's pinned datameans. <br>Then, since there is obviously \
too much data, either data will have to be grouped by means, or means by data.  <br>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).<br><span style="font-weight: bold;"><span style="font-weight: bold;">

<span style="font-weight: bold;"><br></span></span></span>Nicholas<br>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. <br>:)<br>



_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic