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 and <span style="font-weight: bold;">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..

<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. The 'ends' (the playing of the music) at the end. The user can search for the data hierarchically (permanent or temporary), or search. </div> </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. 

<div style="margin-left: 40px;">This is a case of the user generating a temporary hierarchy by a keyword. </div> Looking above, though, it seems: 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) 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 <span style="font-weight: bold;">where and when. <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;">

<span style="font-weight: bold;">Back to <span style="font-weight: bold;">efficiency <span style="font-weight: bold;"><span style="font-weight: bold;">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;"> 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.

<br>:)<br>