GNOME Bugzilla – Bug 416068
Use side pane instead of tabs in UI
Last modified: 2007-07-14 02:40:59 UTC
The current TST UI provide a tab for each category of matched files/objects. Each tab is showed only if you have matches. I'm not sure about it, but it could be bad for HIG (appering/disappearing widget) and it's of course bad, from an HIG point of view, if you have match in a lot of services: "Do not put too many pages in the same notebook. If you cannot see all the tabs without scrolling or splitting them into multiple rows, you are probably using too many and should use a list control instead." So, could we direclty use a list control? It will help end-users to know the scope of their searches ("you can use this tool to search in images, documents, emails...) and it's also the new (Leopard) look of Spotlight[1] Moreover, as in Spotlight screenshot, this UI will allow the definition of saved searches :-) I'll attach a glade mochup. [1] http://thinksecret.com/archives/leopard9a377a/source/35.html
Created attachment 84241 [details] A simple glade mockup The Add button could be used to add criteria (RDF) to current search, the Save button to save current search.
Created attachment 84242 [details] A screenshot of glade mochup Entries in list pane are added with GIMP.
Created attachment 88859 [details] new mockup (created in Glade 3.2) This is very well designed. Beats the current Tracker SVN user interface for tracker-search-tool. You have my vote :) Some ui-nazi comments on your mockup however: - the two buttons on the lower left should have 6px spacing around them and between them. - the 24px spacing around the top portion is insane - your search field is missing a "Search" stock gtk button - the label "Search:" might be redundant - your mockup is missing the current SVN's metadata pane on the bottom So, instead of just whining about it, I made an updated mockup. Thanks for doing the big part of the work :). Beware, this was created in Glade 3.2, not glade2. My changes: - less tables - unclutter stuff - separate "search" from the previous/next buttons; they don't go together, the previous/next buttons are related to *results* - better spacing (I added spacing in some places, removed spacing in others) - cleaner code - I gave names to the widgets so that you are not entirely lost when you look at the tree - added a metadata pane (to match SVN) - "add" and "save" buttons did not seem to make sense to me. Replaced "save" by "remove" (because you may want to remove custom searches). A save button is useless if the app is smart enough to save automatically ;) - added an "expander" for the metadata pane. I believe this is a better approach than the weird cairo-colored thing that is currently in SVN's ui. This is just plain gtk. I really wish that Tracker-Search-Tool was just a python application that imported glade directly, so user interface designers could easily create patches themselves instead of mere mockups... I think a good user interface would unveil the full ass-kicking potential of Tracker.
Created attachment 88860 [details] new mockup (created in Glade 3.2) screenshot
(In reply to comment #3) > Created an attachment (id=88859) [edit] > new mockup (created in Glade 3.2) > > This is very well designed. Beats the current Tracker SVN user interface for > tracker-search-tool. You have my vote :) > > Some ui-nazi comments on your mockup however: > - the two buttons on the lower left should have 6px spacing around them and > between them. > - the 24px spacing around the top portion is insane Ehi, it was just a mockup ;-) > - your search field is missing a "Search" stock gtk button I'm for search-on-type > - separate "search" from the previous/next buttons; they don't go together, > the previous/next buttons are related to *results* But there is also a lot ow wasted space... dunno > - "add" and "save" buttons did not seem to make sense to me. Replaced "save" > by "remove" (because you may want to remove custom searches). > A save button is useless if the app is smart enough to save automatically ;) From a features pont of view, you should be able to: * "save" the current search as saved search, i.e. type words and criteria in search text entry, review results, then fix words and criteria in a saved search * add a new saved search from scratch, i.e. clicking a button should appear dialog allowing you to specify "advandeced" search option in a simple way (for example file type or date or other using comboboxes), something like the Rhythmbox's dialog to add a new smart playlist * edit a saved search, i.e. open the previous dialog and change some settings (of course the same dialog should be opened if you "saved", not "added" the saved search. * remove a saved search IMHO course Edit and Remove action could be placed on popup menu right-clicking on saved search entry. PS of course "saved" searches and "added" searches are the same thing, the only difference is when you enter critera (in search text entry or in dialog field), so we could use a single button to perform both action: clicking on it could appear the criteria dialog, with some fields yet filled if you have yet typed something in search entry. Example: type "mountain type:pictures date: >2006/12/31" in search entry, then click Add, you will have a criteria dialog like Search for: [ mountain ] Type is: [ Pictures ^] (Remove) Date is: [ after ^] [ 2006/12/31 ] (Remove) (Add Criterium) (Save Search) [ ] <-- text entry [ ^] <-- combobox ( ) <-- button
> I'm for search-on-type I don't think this is possible, not unless Tracker Search Tool stops eating the CPU/locking up when displaying results, which it currently does if I recall correctly. Also, think of those poor old CPUs or power-saving laptops :) This needs a lot more number crunching than, say, nautilus' typeahead (I think). Not entirely sure this can be done realtime without huge lag, but Jamie should be the one commenting on that I guess. As for "add" vs "save", I would argue that the Add button might simply show a dialog like the one below. The two topmost widgets would be a RadioButton group, and activating the 2nd choice would unfold an "expander widget" displaying all that stuff for the custom criteria. What do you think? Using this dialog would remove the need for two buttons and make the context clearer, I hope. (o) add the current search criteria as a custom search ( ) I want to specify a new custom search below: ->--------------------expander?----------------------- Search for: [ mountain ] Type is: [ Pictures ^] |Remove| Date is: [ after ^] [ 2006/12/31 ] |Remove| |Add| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |Save Search|
tabs are replaced bya sidebar/list in latest svn
just an initial quick comment (I would reopen this bug if I was the OP), the side pane does not remember its size. It's annoying because the contents sometimes exceed the width and a scrollbar appears, and you have to resize it each time (especially in locales that have longer strings). Actually, remembering the size would be the wrong solution I think, the user should not have to mess with that size I presume. Maybe just making the sidebar "impossible to shrink"/auto-expand+shrink would fix the problem. I'll have to take a closer look for the rest of the changes whenever I have a minute in the next days or so.