Search for Tabs
Provide search box to quickly locate tabs based on match in page title or URL. Highlight them and provide an option to create group from the matches.
These search groups could potentially be saved to work as Smart Playlists in iTunes or like saved Search Folders (from Bookmarks / History) in Firefox's Library.
Check out prospector at the labs. Does exactly this. It is AMAZING:
All merged into the awesome bar. Does your history and new websites TOO!
This would be good. But I also think it should be great to have the opportunity to search in the adress bar without going to TabCany. You can search for tabs in another group(it shouldn't say "Switch to tab", it should say something about that it's swithcing group) and to searh for groups and open them.
This is desired, but there is much to be considered here. In the context of a single focused tab, the find feature (and presumably nsIWebBrowserFind) scrolls the query into view and selects it. However, for multiple tabs where at most one is in the foreground context, should the browser still scroll and select?
Searching the URL presents much the same issue as page content. How do you present context. The tabbar has favicons and labels, tabcandy adds thumbnails, but neither appear to offer context to searching anything other than these elements. Without context, it is far too easy to be presented with a list of relevant results that are perceived irrelevant due to a lack of context.
Searching content is also problematic -- what text should be searched? doc.body.textContent != visible content that the find feature searches. However, given the popularity of AJAX and CSS, what about content that was recently viewed, is still part of the page, but is now hidden? If the user is searching for that content, the current method is a false negative; however, any more than this can easily lead to perceived false positives. Does scrolling a page or changing selection effect any AJAX apps adversely or otherwise? If so, probably not something that should happen from a background context.
Additionally, how do you differentiate search context? The "awesomebar" searches multiple contexts by default, but provides arcane escapes to limit context, which severely limits its utility -- who can ever remember what symbol to use to change to the desired context? For tabcandy: How do you filter by Title? Text? Url? Combinations thereof? How do you express the relationship between multiple contexts? For example, the intent of of these is the same: "Search both A *AND* B" versus "Match either A *OR* B". Does a query to match multiple contexts make sense? How do such semantic distinctions convey to an international audience. Visual HIG is one issue, but that's only one aspect of the UI.
A benefit of tab candy is the tabs are further abstracted, such that filtering does not directly affect the implementation, but rather an abstraction thereof. That is, filtering for a given query does not actually hide non-matching tabs, but only a corresponding abstraction thereof. Still, it's effectively yet another new window and moreover, is yet another abstraction of the actual content.
What about non-text queries? For example, what open tabs look similar to this tab's thumbnail? For example, trying to locate a splinter group, without recalling the context or the content of the original (aside from spotting a similar thumbnail).
Tab searching is very important for users who repeatedly and quickly generate dozens of tabs; however, the context of the results and the unity and consistency of the UI is equally important.
Ended up creating my own WORKSFORME extension, but still looking for some good accessibility and/or HIG articles on this topic of filtering documents in a mixed MDI/SDI interface...
I like this idea. I posted my comment in the wrong idea topic. Ill copy paste it here:
This would be cool maybe a little search box like seen in fox tab. All animated with slide in and slide out. And an option to remember last position (in/out).
Typing like "title:blah" will search for blah in title. "notes:blah" will search notes. "metadata:blah" will search metadata. "group:blah" will search for group name. "body:blah" will search the body of the tabs for that. And just "blah" probably should make it search what is most commonly search i dont know what that is, maybe title of page?
I'd hope the search would be implemented in a way that you can just start typing while in the groups view and the not matching tabs (and successively the groups from which all the tabs have disappeared) simply start disappearing (or graying out).
Smart groups is really a great idea, even though probably worth a separate wishlist item.