This idea is intended to save the user time when opening applications that take parameters like filenames. Below are the two rather slow methods available today.


Terminal way:

1.) Applications->Accessories->Terminal or <keyboard shortcut to terminal> 2.) Use cd and ls to find the file. 3.) gedit [options] [path]

== Current graphical way: == 1.) Applications->Accessories->Gedit ...wait for gedit to open 2.) File->Open ...wait for file selector to open 3.) Navigate to file graphically. 4.) click to open

If the user is familiar with the general location of the file, the first case will be much faster, but still requires the user to open a terminal tab, and most will open the application in a way that requires that the tab be left open. Other users may not even be aware they can use custom commands like this to open programs, meaning they only have the graphical option. The solution to this is to give the search box the ability to open applications with custom options, functioning as a mini-terminal if you will. I'm not sure if we want to give it full terminal power, since this might interfere with certain search functions we might want to include, but at least custom launching behavior would be very helpful. Please see the attached image to see an example of the proposed behaviors. So far the user has entered in "gedit" and most of the filename. The text highlighted in yellow is the computers best/first guess at what the user wants to type, and the options below it are other possible suggestions. The button below will let the user see more suggestions if there are too many to show. This new behavior would make any program that takes arguments much faster to open because it eliminates a lot of clicking around into different folders after launching the app and eliminates a lot of cd and ls usage in the terminal. Here is the new workflow.

New search box/mini-term way:

1.) Activities->search box 2.) type "gedit" and use autocomplete and suggestions to type path quickly

Application View Options

Note the three buttons above the Applications list. Gnome's current menus give fast access to any program in the applications list, but there is nothing like the "recent/frequent" apps listing seen in gnome-shell. At the same time, the new gnome-shell way hides all but the most recent applications in the "More..." list. If any of you use the XP style start menu regularly, you'll notice that it does the same thing with "All Programs", but the user is not always sure if they should hover over the button, or click on it to open and keep the menu open. It also adds an extra step everytime, even without the above quirk. Vista is the same way, except that it fixes the click or hover dilemma and replaces it with scrolling through a long and poorly formatted list. The buttons in this example would select either the most recent, most used, categorized (like present applications menu or the category view on the mockups page), or (possibly) alphabetical view. These buttons should select the view and maintain it until another view is selected. This way the user will more often than not have their preferred method of interaction already there when they open the overlay. It also presents the user with a clear(simple and discoverable) choice in how they want to view the list without requiring them to take any action unless they want to. I would very much appreciate feedback on these ideas, so we can develop and vet them further!


Projects/GnomeShell/DesignerPlayground/MiniTerminal (last edited 2013-11-22 16:59:54 by WilliamJonMcCann)