One month ago I presented some ideas for an application repository. This interface would give users an unrestrictive way to search and explore software installed on their system within several contexts. The system is one part of a response to dissastisfaction with the KMenu. The other parts of my solution include an interface to quickly launch applications and a "smart" system to help the user relate data and applications together as tasks.
Here is part 2: The Application Launch Menu (including contexualization)
Hundreds of applications could be installed on a system, but only a small percentage of them are actually used. The KMenu is bulky and slow to navigate through for finding an application you know and use often. Moderate and advanced users who are more familiar and comfortable with the system may create more easily accessed shortcuts, however over time they may collect and become clutter. How can we fix this?
Well first off, just about everything is in the KMenu. Software we use, software we dont use, software we launch from documents instead of shortcuts, software we didnt know was even installed... its a lot of "stuff". Although we may create shortcuts on our desktop or use the CLI to quickly launch known applications, at some point we still resort to browsing through it to find something we havnt used in a while or ever. The application index, as previously mentioned, provides and easier and more intuitive interface to facilitate our browsing and searching. That helps fix the times we want to discover software.
What about the software we already know and the documents we open often and treat as applications? The launch interface should help curb the desktop clutter we resorted to when the KMenu was too much for the job.
But first, let's define a context.
Currently the KMenu has no context. It is a one-stop-shop for system configuration, session control, application shortcuts, searching... everything! Part of the difficulty it has in its organization and information visualization lies in the lack of context. Since we dont separate user applications from system applications, we have to create a hierarchy to define that. Since we dont have user preferences or meta data or contextual information, we try to guess categories and labels the user will find intuitive. By the time we actually get to the software, there are so many hoops the user has gone through its a suprise they havnt forgotten what they were looking for.
Tasks related to interacting with user information such as documents, email, and images are very user-centric. User's manipulate their information with use of tools which can manipulate them.
Tasks related to things such as hardware configuration, changing backgrounds, and screen resolution are
machine-centric. They effect how the system looks, behaves, and reacts to the user. It doesn't effect the user's data. Changing the widget theme could be a goal of the user but the machine is what is changed, not the user's documents.
"But what about the grey area of sysadmins who regularly edit config files by hand?" Then those files become information for those users, and the applications they use to manipulate them are in a user context. Monitoring network traffic does not effect the users data and is a reflection of the machine. Tasks such as viewing apache logs or editing configuration files create a user (not machine) context for those system files and it becomes user information.
Provided is a mockup of what the user's menu could look like:
User's Shortcuts
Similar to the frequently used programs in the Windows Start Menu, the left half of the menu (column closest to the mouse) is a collection of shortcuts the user can drag and drop and rearrange in whatever order they want. If what the user is looking for is not in their shortcut list (or contextual menus I describe in a bit), they may browse applications (a link to the application index is below the list of links) or directly search for it using the name or a description (with the search bar at the top of the menu).
Users expect effort to be required while browsing, so a link to the application index where they start from the beginning will suffice. However, if the user had an idea of what they want, they are less forgiving of the effort required. The search bar can pass the query to the application index and present the user with the results page. That way, there is one action necessary to get a result yeilded in a short amount of time. If the query was sufficient, their target item should be available in the results. If they need help or to refine their search, query help and lower rated hits could be suggested.
'Tasks' and Smart-menus
To the right of the user's favorites are a series of contextual menus, user- and system-defined. This panel contains collections of files (applications, contacts, and documents) which relate to each other and are often accessed together. These menus can act as shortcuts to contexts greater than one or two files.
Creating "Tasks"
With these menus, users will be able to create custom "tasks", documents which are frequently needed in order to complete a goal. There could also possibly be a button which will "open all files" to provide a one click way to begin a task. Each item is also clickable to be able to open individual items.
Panel "Buttons"
You may have seem this panel design before, including Microsoft Outlook. These types of button-menu interfaces work well to create a context based on a descriptive label. They have tested well qualitativly (acceptance/satisfaction) and quantitativly (performance/comprehension) in usability tests. From a design perspective, they are a good way to provide additional space while preserving context and understanding of the information.
System-defined Menus
The smart-menus will be described in more detail in my next installment. Basically, the user will be able to create 'smart' filters to generate automatically updating, yet somewhat bounded lists of their information. Examples include "Recently Installed Applications" or "Files opened with Kate in the past 48 hours".
I realise now I should have also created a 'machine' system menu to help you visualize the different contexts. It would be fairly similar with the ability to create 'tasks' such as 'website administration' or 'review and edit user accounts'. User your imagination and if you think of a frequent scenario that could be sticky, send me a mail.
Next time I will go in to more detail about the information itself and some of the mechanisms we could use to help create better organization, labelling, "smart" filters to help users create tasks, file tagging and meta contet, and all that good stuff. Knowing how the information works together with the system for the user will help bring the application index and the launch menus together for a solution which could ultimatly replace the KMenu.
Syndicate Blogs
Recently Installed Applications
This alone is one of the most expected feature much expected by non-geeks.
That said, I consider the new KMenu you presented so nicely in every detail, in reality could be KDesktop replacement in KDE4. A few others said the same and I guess this is sane idea. At least, there could be no problem with too laaaarge menu, something what (first) make Windows users mad, and then KDE users too...
Maybe let's make the stuff more like a web pages people are accustomed with... This worked in Konq/KMail welcome screens, will work in KOffice 1.5/2.0, so why not?
Program info page
I looks like reinventing the XP menu. Very bad.
I do no think a menu is needed at all.
1. extensive metadata about applications
- what type of application
- screenshots
- what files you can edit/view etc. with them
- how to contact the author, link to webforum etc.
- etc.
2. Metadata presented in html like fashion which fits on one screen
with link to launch the application
3. Desktop search as the main user interface.
e.g I type in "write text" and get a search result page, for each application I get further info by following the link. Sorted by average use, installed or not and other relevance indicators.
4. Metadata could be provided regardless whether the software is installed on my PC or not. So when say Abiword is not installed I get a Abiword info page via search results and a one click download for an RPM for my installed Linux flavour.
5. Parts of that pages can be provided as an internet service.
6. When I search for say "Greeting cards" then I will get explained:
- how to sent greetings cards with Kmail
- how to design them with scribus template xy
- etc.
i already commented about
i already commented about the 'menu' look, this is simply an mechanism to collect shortcuts to documents and applications so they can be quickly executed. a context of x is created for y and a shortcut is created so the user doesnt have to waste time and mental energy going through hoops to execute it.
refer to the rest of the discussion and the previous post about the index.
Not a menu anymore...
According to what you presented last month, it was obvious that the KMenu couldn't be a menu anymore. There isn't enough room in a menu to implement all your ideas. Why wouldn't we make the big step to turn KMenu into an app? Whether its window remains stuck to the K button or appears in the center of the screen would be just a matter of user configuration... which by the way would become easier to access with a dedicated entry in a regular menu. Besides, to close the KMenu, you must click once so it would become a "logical" click on the closer button.
In a real window a lot of things would become easier for the user (and the developer) like collapsable, resizable, moveable panels for a free layout according to the user's likings. There's something I've always dislike about the KMenu is that its layout can't be reversed to match the fact that it pops up from the bottom of the screen. The most/last used apps should be close to the K button and the least useful things like shutdown should be far away. With a customizable layout in a window, such problems would belong to the past. Drag and drop would also be obvious within the KMenu window or with the "outside world". Picking an icon in a Konqueror's window to put it in the KMenu would be easy. That removes the need to implement a special feature to add something and the pain for the user to retrieve what s/he wants in the tiny weeny fileselector while s/he has the power of Konqueror right under the tip of the mouse.
It's even possible to imagine that the KMenu could appear when you press ALT+F2, with all its panels collapsed (by default) except the one to type directly the name of the app to launch.
Some would say that it will make life harder for the hypothetical potential Windblows users that may come to KDE but I wonder if to make life easier for them should be one of the main goals of KDE. On the contrary, I think we should have our own (easy) way that makes their life feel harder when they return to Windblows.
"According to what you
"According to what you presented last month, it was obvious that the KMenu couldn't be a menu anymore. There isn't enough room in a menu to implement all your ideas."
keep in mind the index is completely separate from a 'thing' which allows quick and easy access to frequently used 'bookmarks' (of things such as applications, documents, collections, etc..) the index will be an app.
whether a quick launch interface should be a standalone application, i dont know if its necessary. it should be part of kicker. whether its anchored to a button or follow the same size design as the current kmenu.. i dont think that matters as much. thats an interaction/usability issue with the cosmetics, and right now were trying to solve the ia/usability issues with the content.
i seriously doubt the final solution will look like the mockups ive used to visualize my ideas, however i doubt the information context and relation will change much. the index will be an index with relations between other things, and the launch menu will be quick, easy to manipulate, and contain shortcuts and collections for easy access.
"Some would say that it will make life harder for the hypothetical potential Windblows users that may come to KDE but I wonder if to make life easier for them should be one of the main goals of KDE."
you mean by the design of the menu itself or its mechanics? i was opposed to too much change (such as a completely task-based driven interface) because 1) it would be a new model with new metaphors for the user to learn (which isnt really that bad, its just 'new') and 2) the rest of the desktop does not support those metaphors (which is a bigger issue because they cant take their newfound knowledge with them to a new part of the interface and apply it).
overall, i agree 1) kmenu as a whole wont be a menu (because its been split up into several parts), and 2) better interaction with the rest of the inerface is a must (drag and drop shortcuts, not use a wizard to configure it).
Dynamism!
I agree there will still be some static list of all installed applications of one's system somewhere in the future KMenu but your idea of dynamically generated lists according to user's search path and the possibility to obtain information about applications seemed to imply a window driven interface... unless you had in mind an idea of a jungle of sub-menus with pop-up windows in every corner. But I don't think so. KMenu is already that jungle of sub-menus.
Whether the future KMenu will look like your previous mockups or not is irrelevant. You just can't implement your ideas in a static menu style interface --hence (logically) a window.
As for the Windblows users, I think we should totally disregard what happens on their side of the force --except to rip ideas that fit in our design-- to find our own way no matter how far or close from a Start menu it is. It would/must be KDE's way. To mimic Windblows or V*st* should NOT be a main goal of KDE, that's what I meant. Apart from an icon in the kicker --and not a Start thingy-- just to keep a rather good habit, KMenu has no obligation to follow any known scheme. No matter what will happen with the K Menu, we'll have to take new habits to use it. And the "mythical" KDE 4 is a good opportunity to make radical changes --for the best, I hope.
I also definitively would like a task oriented desktop and K Menu, to forget about the applications, but that would be more than a change! KDE is ready with its embedding capabilities and the KIO-slaves... but most of its users aren't and the developers aren't ready to fall into anonymity either. Let's wait for KDE 5 or 6.
With these menus, users will
With these menus, users will be able to create custom "tasks"
and
Basically, the user will be able to create 'smart' filters to generate automatically updating, yet somewhat bounded lists of their information.
But most users never do any of those optimizations, they just use whatever is presented to them by default.
I don't see you mention the "Most Used Applications" that the KDE menu currently provides, why is that?
"But most users never do any
"But most users never do any of those optimizations, they just use whatever is presented to them by default."
this isnt an optimization, its part of them menu. their creation should be as easy as dragging files in to a box and labeling it. it shouldnt require a wizard or advanced knowledge of the system to configure.
users love the itunes smart lists because theyre easy to create and theyre accurate. their creation isnt hidden somewhere in an obscure advanced configuration menu under some strange option label.
but this is starting to turn in to an interaction design discussion instead of information architecture. the point is the information and easy access to it. if it requires adjustments to the wireframe i used to visualize it, then sure.
"I don't see you mention the "Most Used Applications" that the KDE menu currently provides, why is that?"
because.. i just didnt mention it? that list provides most used apps, but it doesnt solve the IA and usability problems of the rest of the kmenu. most used applications is just another collection of shortcuts in a context.
Actions and Menu
Other then historical significants why do actions and applications have to be in the menu? I very much like the way that Gnome and OSX have it where they are two separate things. There is an action menu which contains the stuff like shut down, preferences, software update, log out, lock screen. Then (at least in OS X) you have the apps inside finder and can be browsed, moved, rearranged, searched, renamed etc by the users just like folders (one less thing to learn). Why should the list of favorites be in the menu at all? Thinking out of the box why can't they be SUPER easy to added/remove them to kicker where I actually want them?
The menu that I *really* want is apps that I recently used that aren't already in kicker. OS X almost has this in the action menu there is a sub menu of recent items (including apps) but it lists all apps even if they are already in the dock. You touch on this in the end, but you hint that it will be yet another sub menu which brings us back to the topic. Why does it all have to be contained in a menu? I never really got that. A big complicated widget inside a menu button that will disappear and reappear. If rather then bringing up a menu how about it launches an application? They you can do it right and have a toolbar, a real menu, different views, dialogs, etc all without having to try to poorly squeeze it into a menu with an interface that is unlike any application out there.
yes, but..
" There is an action menu which contains the stuff like shut down, preferences, software update, log out, lock screen. "
that sort of stuff isnt in this kind of menu.. there is no shut down/preferences/update/logout. in an administration menu, the task of 'managing software' could be created and shortcuts to GUI software used by the user could be bookmarked.
controls such as shut down, log out, and lock screen should be on the kicker.
"Then (at least in OS X) you have the apps inside finder and can be browsed, moved, rearranged, searched, renamed etc by the users just like folders (one less thing to learn)."
thats basically what the application index is and does. it is the collection of software, provides information about the software, allows the user to edit the software to be available under some type of category, it can be whatever you want if someone is willing to program the functionality.
"Why does it all have to be contained in a menu?"
its a menu by my definition. it could just as easily become an app.. really thats not my concern. my concern is that this "thing" 1) completes the goal of providing the user with a quick way to access their information through their known tools and 2) helps the user keep track of what their known applications and tasks are.
browsing/finding applications and the management of such is the job of the application browser. if you dont use it enough to keep track of it or you dont know what you want to use in order to complete a task, use the index.
"They you can do it right and have a toolbar, a real menu, different views, dialogs, etc all without having to try to poorly squeeze it into a menu with an interface that is unlike any application out there."
just because it breaks the mould doesnt mean it shouldnt be done. yes, it would certainly be nice to have more room to design in, but i doubt the fundamentals of the collection of favorites or the creation and management of tasks wouldnt change.
just as mimicing the start menu was to help users convert with a familiar interface, we should consider how long weve been using 'start menu'-like interfaces and evolve not introduce an entirely new metaphor. there needs to be time for testing and for the rest of the desktop environment to catch up.