Taskdriven actions

Today I was wondering, on an ever lurking question of usability: “What would my productivity on the desktop increase?” An important factor is probably the ease of finding the right application for doing the job. I think a taskdriven interface is one of the best solutions.

I think we can improve this factor in GNOME by improving the way we start applications, one way would be to run the application from the ‘Applications’-menu on the menubar, but why don’t we add another menu for specific tasks or actions? Likewise:

Mockup of the Actions menu (thumbnail)

An application could register its actions for this menu in some kind of mimetypie or gtk-boomarkie way.

A downside will be that this would add another menu to the menubar, which makes it long and maybe hard to read. Also, some things in the System (or Desktop) menu are also actions. What about combining these menus or moving some menuitems around?

Maybe we had this before, or someone has already proposed it in the past, I was to lazy to check up history 🙂 Overall, I think this would be a neat idea.

By the way, anyone knows what this (below) is? I’m using blogs.gnome.org.

16 thoughts on “Taskdriven actions”

  1. I think this would be a great idea, and I always favour things that can be done quickly!

    That said I think that the OS X ‘Services’ concept would be great in GNOME. Although I can’t seem to find a good reference to it! But essentially every program can attach actions to objects – so if you highlight some text in the terminal you can go to the ‘Services’ menu and do a bunch of things.

    I’m told it’s a NextStep concept and that they did a lot more with it – making it pervasive ‘task orientated’.

  2. What if the menu was more dynamic and listed the most commonly used actions that were performed, instead of a static list that every application publishes (which the user may or may not use).

    Use case: a user commonly uses Evolution to manage their calendar but uses Thunderbird to check their e-mail. “Compose e-mail” should open up a Thunderbird compose window, and “Create appointment” should open an appointment window in Evolution.

    Obviously something like this wouldn’t be as easy as just extending .desktop files and adding actions to them.

  3. Very nice idea! In my ideal world applications could expose Roles that could easily be added or removed from such a list. For example you could have “Compose Email”, “Make Calendar”, “News”, along with a smart interface for setting your preferred applications for filling those roles.

    This is a little like what MS does with the “Internet” and “E-mail” icons at the top of the Start menu in XP, except worlds better!

  4. this could be done using a menu built from .desktop files, like Nautilus Templates menu. each .desktop file points to an application. some apps should implement a command-line switch/component to enable launching a specific action, but I think this could be easily done.

  5. I don’t know if that would be very useful.

    I tried to think of what my parents do with their computers. My father mostly creates new menus (he’s a chef) and my mother mostly listens music and reads news on the web.

    Now think about the applications installed on your computer. There are dozends. And each of them has about two or three “actions”. This results in a very big menu. And as we all know; big menues are useless.

    Back to my parents. The tasks my mother needs (“Browse the net” and “Listen to music” are to ambiguous to be helpful. Listen to what music? Browse what internet site? All this task-starter can do ist start the right application, not more.

    Almost the same goes for my father. He mostly copies an old menu and just makes the changes. What task would be the right for him? “Create a new text document by copying the date from a new one?” Hell, what a name.

    I do think that task oriented GUIs are the future. I do not think however that this is the right way.

  6. Why have a seperate actions menu? Why not display the applications as a “tooltip” or slide-out from the actual entry in Applications menu.

    The applications are already well categorised, so Joe User is already going to see “Ah the Applications menu, my email client must be up there somewhere….” “… Ah, internet, is it in there? What about Office”.

    Now, when the hoevers the cursor over the “Evolution Email” icon for more than 2 seconds, a further submenu (stick with me here… a sub menu may not be the way, but it definitely needs to be something “appearing”) flys out containing a list of no more than 7 actions associated with that application. Clicking an action will open the application ready to perform that action, or clicking the application icon will start the application as per usual.

    Further to this, you’d need a spec in the .desktop files to assign “known actions” to an application. Gnome would have predefined known actions (as a previous poster mentioned, there could be many, and a schema approach could permit new applications to install new actions, though there would have to be a limit somewhere). The .desktop for an application could contain a KnownActions section, list a known action (for e.g. “SendNewEmail”), and pair it with the commandline arguments / other command to run to complete that action from the application.

    Seems a bit zany I know, but I like the current menu spec, and I’d rather see an extension to that paradigm than the introduction of another panel top level menu item.

    Feel free to email me at jon_cooperuk@-nospamharvesting-hotmail.com with any discussion relating to this idea.

  7. I thought there was already way to set the Applications menu to show Action lables instead of Application names/Generic Names but perhaps I am misremebering.

  8. Excellent idea!

    I hope it could get into gnome quickly!

    THAT’s the way to simplify the use of the desktop!
    Love it, really!

  9. I think what would be a good idea is to have Gnome remember the most commonnly used actions that you do on the computer for example if you use evolution to send email alot then the send email action will show up on the action menu, Or if you tend to add alot off addresses then the add address will show up.. The actions menu could be dynamic like the recent documents.

  10. I really like the idea of task driven menu. For one year, I thought about a proposition to do. Unfortunately my knowledge in C/C++ is not enough to realize a prototype by my self.

    The ideq’s summary is:
    – Main entry point for people are tasks (view photo, listen music, send mail, write letter, view movie…) – because people don’t know programs (xine, vlc, mplayer, evolution, gthumb…)
    – As there may be a lot of tasks, put all knowledge in a database
    – As information like “evolution send mail” is not subject to version number, keeping an updated database for major available programs should not be a big deal.
    – If program able to do a task is not installed, use the distribution packaging to install it automagically.

    I made different database content prototype but I was not able to go further.

    Take a look at deverne.free.fr. It was not updated for a long time but there is explanation about “task driven desktop”.

    Denis

  11. We got dogtail, why not use it to drive applications. Distributions could ship with a series of predefined actions, and the user could be able of store new procedures/macros.

    The menu could be inteligent enough to reorder the menu entries based in their frequency of use, and hide the less used ones under a “More actions…” menu entry.

    Just my two cents.

  12. Seems like a pretty good idea, but I would also see this stuff on files. I often start with my home folder and want to do stuff with the files already there…
    A few examples…

    An image: Compose email and attach with this file (thunderbird, evo), Convert to jpeg/png/… (convert), Resize (convert), Publish on the net (cp :-)), Send to buddy (gaim), etc etc.

    Document: Convert to pdf (ooo/abiword), send as email, etc..

    I think you know a lot more stuff to do with your files…

Comments are closed.