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

[Janne Ojaniemi]

On Saturday 07 January 2006 22:08, Brian Beck wrote:
> I'm sorry I still don't understand, if this new system is going to work
> like
>
> 1. select songs
> 2. juk opens
>
> I prefer todays
>
> 1. juk opens
> 2. select songs

It doesn't quite work that way in reality. In first case, you locate the 
content you want to use, and be done with it. In the second case, you first 
locate the app you want to use, and then you use that app to locate the 
content you want to use. First case only has one step (access the content), 
while the seconds case has two steps (access the app, and then use it to 
access the content). And in any case: the second case relies on the user to 
know what each app does, and IMO, he should not care what each app does. He 
does know what his content is, however.

But, if you really preferred to first start the app, and then use the app to 
access the content, you would still have that option.

You may know what Juk is and you decide to use it. But in reality user has to 
know several apps, and he has to know what each of them does. And he has to 
locate those apps in his GUI, and he then uses those apps to access the 
content. My point is to remove the need to access the app in order to access 
the content. Instead, the user simply accesses the content.

And even if there was only one app (let's call it "Music Player" to avoid 
confusion). Even in that case, the user has to first access the app, and then 
access the content. Why does he first have to access the app? Seriously? What 
advantage does it bring?

> Why? Because I only have one juk, and lots of content, it's easier for me
> to get my mind around.  (1 vs many)

But in any case, you first have to access Juk, and then use Juk to access your 
content. Why not simply access the content, bypassing the need to access Juk 
entirely? Of course once the playback is up & running, you could use Juk like 
you normally do. Or you could use the content-browser to access the music. 
you would have both options at your disposal.

> You bring up the point that users should not have to know what an
> application does.  I think this might be an overstated difficulty.
> 1.  Confusion about what an app does can be mostly easily solved with
> better names Juk -> Jukebox, Kolourpaint -> Painter, etc.  (The
> applications name tells what it does)  Many distros have changed Konqueror
> to "My Files", "My Computer" or something like that, users need not know
> that they're using Konqueror, and when they click a document they need not
> know the name of the application that opened the document for them.

Better names tries to work around the problem, it does not solve the problem. 
How does the user choose between Kedit, Kate, Kword and Kwrite? How does the 
user choose between Kaffeine, Codeine, Kmplayer and the like? Feel free to 
substitute those names with more descriptive ones. But the user is still left 
with the task of knowing each app. And even with just one app with extremely 
descriptive name, what benefit does it bring to require the user to first 
load the app, and then use the app to access the content? It seems to me that 
it just introduces an additional step to the workflow, a step which is not 
ultimately needed.

Like I said: why should the user first load an app, and the use that app to 
access his content? Why couldn't the need to choose and start an app be 
replaced with choosing the content he wants to work on? First case has two 
steps, the second case has only one step. This is primarily a philosophical 
question: by requiring the user to first load an app, we make the system be 
about the apps, and not about the content. And people don't use computers in 
order to use apps, they use them to use and manage the various content they 
have. I do not use Kontact for the sake of using Kontact, I use it to manage 
my email. The email is the content. I do not use Konqueror for the sake of 
using Konqueror, I use it to surf the web and manage my files. Why can't I 
access my websites and files directly, why do I have to go through Konqueror, 
and then use Konqueror to select the content? I don't use Amarok for the sake 
of using Amarok, I use it to listen to music. Why does Amarok have to be the 
gatekeeper to my content, why couldn't I access that content directly?

> 2.  Most of us learned about what our new Linux computer could do by
> initially trying out a bunch of applications.  (It was a learning tool)

And, IMO that is not needed. Users don't want to waste their time going 
through bazillion different apps. They do not want to use apps. To them, 
computers are not about using apps, it's about getting work done. Yes, today 
(in all systems), they do their tasks through applications. They select the 
app, and then they select the content in that app. Why not replace the apps 
with content instead? requiring the user to first access the app and then 
access the content, is an exta step that does not have to be there.

You CAN learn what your computer can do with content-centric approach as well. 
The apps would still be there! This is about how the user accesses his 
content, and not about running the apps as such. Instead of first accessing 
the app, and then using that app to access the content, he would simply 
access the content.

> 3.  It's a new user issue (not that it isn't important), but it goes away
> with time.  My nephew installed linux for the first time last weekend on
> his laptop, and the names of applications haven't been where the learning
> curve has been.

I don't think you understand what I'm trying to say here... Again: Why does 
the user have to first select an app and the use that app to select the 
content? And even if the names of the apps are descriptive, there's still 
lots of redundancy in there. And when you use Juk, you don't do it so you 
could use Juk, you use it to listen to music. My suggestion puts the 
end-result (listening to music) at the forefront, instead of putting the tool 
(the application) at the forefront.

> You've got to expand this final point.  It seems that the removal of the
> folder concept from KDE would have huge repercussions.  For example..
>
> * Accessing you home directory through the command line.
> * Backups (how do I find something in a backup I have of someones home dir)
> * Changing GUIs
> * Those of us with Gigabytes of photos (or other meta-dataless content)

I'm not sure that where I said that we should get rid of folders....

> I think we should leave K-menu mostly as it is, include a powerful search
> tool Kat + Katapult might be right for the job.  (Something like the OS X
> search would be great) That way the user maintains the familiar way of
> accessing applications, gets a powerful content-centric search, and the
> folder organization method is maintained.

Why do I get the feeling that this is a case of "this is the way we have done 
things in the past, and therefore we will do it like this in the future as 
well. Well, we might copy features from these other OS'es, but let's leave it 
at that"? Wasn't KDE4 supposed to break new ground and do NEW things? Yes, 
right now we use apps to access the content. But just because we have done 
things like that in the past, and because some "other" system use that 
approach as well, does it mean that it's the RIGHT approach? My suggestion is 
about accessing the content directly, instead of going through separate apps. 
This makes things a lot more straightforward for users. And if you still 
wanted to access your apps, and then use them to access your content, your 
apps would still be there.