[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