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

Janne Ojaniemi janne.ojaniemi at nbl.fi
Fri Jan 6 16:57:58 CET 2006


I know that Kmenu is destined to be dropped from KDE4, and taking it's place 
will be ALI, the "Application Launch Interface". But do we really need it? I 
think that users are not interested in using applications as such, they want 
to use their content (documents, music, websites etc.). Apps are merely the 
necessary evil to access that content. And it seems to me that ALI is 
application-driven, instead of content-driven, just like Kmenu is today.

What I suggest is a system that is content-centric, instead of 
application-centric (or task-centric, another proposal I have seen 
suggested). Allow me to quote a post I made in kde-artists.org:

=====================

As I have said several times: content is the key. People don't want to "use 
Konqueror", they want to surf the web, it just might be that Konqueror is the 
best tool for the job. They don't want to use Amarok, they want to listen to 
music. And so forth. So the content is the key. With that in mind, let's 
proceed.

There would be three top-level menus:

- Content
- Applications (note: if we were really adventurous, we could rop this menu 
altogether)
- System

Those three allow the user to do anything he wants to do, and it will be 
elegant and fast. Notice that the "Content" is the first menu. The content is 
at the forefront, and not the applications. Let's go through them one by one

The Content-menu

This menu contains the users "content". Note: I'm not saying "files" or 
"documents". When the user clicks on this menu, what will he see? On the left 
side, there would be the content he has been working on recently (with few 
exceptions: URL's and the like would not be listed here. Playlists would be 
listed, but not the content of the playlist and so forth). On the right side 
there would be categories (like we have today in Kmenu). These categories 
would include things like:

- Videos
- Music
- Documents
- Pictures
- E-mail
- Bookmarks
- Tasks

This system relies on metadata to categorise things. "Videos" would include 
users video-files. This category could include subcategories, divided by (for 
example) name of the TV-show, season, and finally list of episodes (in case 
of tv-shows). "Music" would include the users music, listed by artist. 
"Documents" would include users documents. "Pictures" would include users 
pictures. Again: this could be categorised by keywords (like "Mark and Lisa's 
Wedding" and so forth). "E-mail" would include the users mail-folders. For 
example, I have "Inbox" and bunch of mailinglists, with filters set up to 
sort incoming mail accordingly. This category would include those folders. 
Now, the user might receive lots of email every day, so this section would 
only list dozen or so latest emails. This section would also contain the 
mails he had been working on. "Bookmarks" would contain users bookmarks 
(duh!). Bookmark could also contain a subgroup called "Feeds"; which would 
contain users RSS-feeds.

Then we have the "Tasks"-menu. This would be user-configurable category. 
Basically, the user could set up "tasks" (like "The Wedding" and "The 
Thesis"). Each task would then contain files related to that task 
(user-configurable). For example "The Wedding" could include Wedding-photos, 
guest-list, playlist to be played at the wedding and so forth. "Thesis" could 
include the files and content the user needs for his thesis.

Everything could be drag and drop. How would the user add a song to the 
wedding-playlist? Well, he could use Amarok to do it for example. Or he could 
go to "Music", select the song, and simply drag it to the relevant playlist 
in "Tasks".

What if the user wants to play back all songs by certain artist? He goes to 
"Music", and clicks on the artist in question. All the songs categorized 
under that artist would be queued and played back. If he wants to hear a 
individual song, he would click that individual song. The actual playback 
could be handled by the music-.player of his choice (Amarok, Juk etc.). 
Simple and easy. The content is right there, and it would be very easy to 
access.

The Applications-menu

This would contain the applications. On the left side of the menu, we would 
have few buttons for commonly used apps (like Kicker does today). Apps to 
have here could include Konqueror and Kontact, but the user could select his 
own apps. Then we would have the app-categories like we do today (although 
refined). Categories to have could be

- Internet
- Multimedia
- Office
- Utilities
- Games

Do we really need more? "Internet" would include internet-related apps 
(Kopete, Konqueror etc.). "Multimedia" has the multimedia-apps (K3b, Amarok, 
Codeine etc.). Office has PIM, Koffice and the like. Utilties has those nifty 
utilities we all know and love. It would also contain Kate. Games would 
contain games (surprise surpise!). We would also have "Developement", if the 
user has developer-tools installed (Kdevelop etc.). Edutainment could be 
there, if relevant apps are installed. In total, there could be seven 
categories, making the navigation of the menu a lot easier than it is today 
(with 12 categories, and several individual items in the root-menu).

The System-menu

This menu would contain the tools needed to configure the system (including 
the desktop). It would also contain the "Log out", "Lock screen" and 
"Shutdown"-buttons. As you are propably thinking, having all the entries in 
Control Center crammed in here, would make the system quite messy and hard to 
use. That's why the number of configuration-entries would be trimmed. Having 
them here would help developers trim the settings, since they can't fit that 
much stuff in here ;).

Of course, each of these menu's could be detached and turned in to a plasmoid.

Opinions?


More information about the Panel-devel mailing list