[Panel-devel] The ALI: do we really need or want it?
Brian Beck
brian.beck at mchsi.com
Sat Jan 7 21:08:43 CET 2006
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
Why? Because I only have one juk, and lots of content, it's easier for me to
get my mind around. (1 vs many)
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.
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)
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.
Then I think you bring up the biggest change yet...
> And in your example, you have to start a separate app to access the
> content: Konqueror. You then access the content which is not categorised in
> any shape or form (or, it has been categorised manually, and that is plain
> tedious). In my example, you do not have to start a separate app, and the
> content is categorised automatically.
Everything prior has been a redesign of the K-menu to make it content-centric
rather than application-centric.
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 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.
-- Brian
On Saturday 07 January 2006 12:46 pm, Janne Ojaniemi wrote:
> On Saturday 07 January 2006 20:05, Brian Beck wrote:
> > Unless I'm totally misunderstanding this sounds awful.
> >
> > I have about 1000 music files on my computer, I also have one music
> > player I like to use (juk). I can tell you right off that I'd rather
> > click on juk and use him to listen to my music then select x songs out of
> > 1000 I'd like to listen to first.
>
> I have over 1000 songs on my computer. And I don't really see how managing
> those songs would be any harder on this kind of system than it is today. Of
> course if you want to create a playlist on ad-hoc basis, using a real app
> for it would be better. The "content-menu" is really meant to access the
> content (in this case, playlists) that you already have there.
>
> > So I guess I see two problems with the music example.
> >
> > 1. I have to select x songs out of y to just to listen to music.
>
> If you want to listen to Metallica, you simply select Metallica, and be
> done with it. If you want to create a brand-new playlist, you should and
> could use a dedicated app for that task. Although the menu could offer
> rudimentary tools for that as well (read my description on the
> "Task"-section in the menu.)
>
> > 2. What if I change my mind about what I want to listen to? Do I need to
> > stop the player, dig through all my music files again and restart?
>
> No. Selecting some music from the list would start the app of your choice
> and play back the music (although KDE might use some "embedded player" by
> default, I dunno). You could then use that app to listen to your music like
> you do today. If you selected some new music from the content-menu, the
> already running app (Amarok, Juk, Embedded Player etc.) would play them
> back. Or you could simply use the app in question to select new music. It's
> up to you.
>
> > Currently I start Juk and type what I want to listen to in the search
> > bar. If I change my mind I type something different. What could be
> > easier than that.
>
> And you could still do that just fine. NOTHING in my suggestion prevents
> you from doing that.
>
> > Please if I've misunderstood, tell me where, but I've seen mock-ups and
> > read descriptions, and it all sounds more complicated than going to the
> > K-menu if I want an application or going to Konqueror if I want a
> > document.
>
> In both cases the user needs to know what each application does. He then
> has to choose which apps he decides to use. And then he uses that app to
> access the content. In my suggestion, he simply accesses the content, he
> doesn't have to know what each application does. Why should the user know
> what application does what? Why should he know what "Codeine", "Amarok",
> "Konqueror" and "Juk" are and what they do? How does it help the user to
> read through descriptions which say "Amarok, a Music player" "Juk, a music
> player" and "Some new Music-app, a music player"?
>
> And in your example, you have to start a separate app to access the
> content: Konqueror. You then access the content which is not categorised in
> any shape or form (or, it has been categorised manually, and that is plain
> tedious). In my example, you do not have to start a separate app, and the
> content is categorised automatically.
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
More information about the Panel-devel
mailing list