Bugzilla – Full Text Bug Listing
| Summary: | global search that doesn't change my current page | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> |
| Component: | Client | Assignee: | libing wang <libingw> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | john.arthorne, libingw, mamacdon |
| Version: | unspecified | ||
| Target Milestone: | 8.0 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 334709 | ||
|
Description
Susan McCourt
(In reply to comment #0) > I often finding myself needing to search for something while working on > something. I have to open some random Orion page (usually choose what I think > will be the fastest) simply to type in the search box and get results, because > I don't want to leave my current page. Actually that is the way I am using global search for now. > One way to do this is provide the popup global search on all Orion pages, not > just the editor, but the results shown there have no context. CTRL+H is a good way to do global search in the editor and the small result pane is only good for a list of files. I was thinking about rendering the full result in this case but I believed the result i nthe editor page should be really compact... > We could consider prompting for search term and then opening a search results >page instead? The search term input is already global. Could we just consider rendering the result in a separate page? (In reply to comment #1) > > We could consider prompting for search term and then opening a search results >page instead? > The search term input is already global. Could we just consider rendering the > result in a separate page? The main reason I didn't suggest this is that I couldn't think of any other site that does this...and including some kind of option (open in a new page) clutters the UI. I find myself doing exactly the same thing... Ctrl+Click on "Navigator" to open a new page, Ctrl+tab, do my search. Maybe the global search box should *always* open a new page. Our usual rule is that we let the user decided by doing Click vs. Ctrl+Click, but in this case the user has no way to choose. It seems I would rarely want to lose my current context when doing a search. Of course the other option is doing the results in a hover but I find that's often not useful. I want that result list to be "sticky" and not get blown away as soon as it loses focus. Seems that if we really want to support scoped search, prompting search term is needed as search will invoked on the scope. Please see comment 3 at Bug 334709. When I'm working in the editor, I'd be satisfied with an enhanced hover that provided more context. Usually I just want to find the callers/callees of something, open some of the results in tabs, and then dismiss the search. brainstorming... If we had [ search box ] <search> (a box and a button) and you hit search without typing anything, what if that opened an empty results page (but it would have to be REALLY FAST) and then you could type the search term in that page. still brainstorming... assuming we move favorites to a menu(bug 347058 comment 3), the search results page link could be a favorite. So I would just have to choose Favorites>Search (which links to empty search page). Not obvious at all, but it would solve my problem. (In reply to comment #6) > brainstorming... > If we had > > [ search box ] <search> > > (a box and a button) > > and you hit search without typing anything, what if that opened an empty > results page (but it would have to be REALLY FAST) and then you could type the > search term in that page. Interesting.Then "search on empty string" brings you to the advanced search. If we can put a place holder, like, "type search term or click search directly for advanced search". Hmm, too long, not a place holder string any more. (In reply to comment #7) > still brainstorming... > > assuming we move favorites to a menu(bug 347058 comment 3), the search results > page link could be a favorite. > > So I would just have to choose Favorites>Search (which links to empty search > page). Not obvious at all, but it would solve my problem. I am a little confused here. I would like to make a folder a favorite first then choose favorite>search, as I mentioned in Bug 334709 comment 3. We should also consider using a left-right pane structure. There are two flavors of using it: 1.Use let pane as the result tree/list.When you navigate by previous/next match, the right pane shows a simplified editor which points out which line matches, like a preview.So clicking on the match on the left pane will open the real editor. 2.Use left pane as the advanced search generator.User can use all the options in the left pane (similar to Eclipse) and see the results in the right pane. The search result page will always be created in a new tab, not overwriting the current page. If user typed some thing in the search box in the banner we just show the result in the right pane with default options. Otherwise we will show cached options in the left pane and get ready for user to do search. No matter which flavor we will use, I think we need to avoid overwriting the current page. See comment 7 and comment 8. I had a example workflow when I used global search, which annoyed me a lot. 1.Open git status page to review my changes. 2.Go to compare page and navigate diffs. 3.Found something tricky and tried to see how others handled that. 4.Global search on the keyword. 5.Found the match and go to the editor. Copy some good references. 6.Navigate back to search result page. 7.Navigate back to compare editor page. 8.When I tried to paste that reference to my file I had to navigate the diff again. Now lets do it again in the new search page. 4.If there is already a search page opened just tab to that page. Otherwise open a new one by clicking on search. 5.Put options on the left pane and see results on the right pane. 6.Find the match and go to editor(If we can manage the search options and result all in left pane, we do not even need to go to editor). Copy some references. 7.Tab back to the compare page and I do not need to re-navigate diffs. The current slide-out search panel resolves this case perfectly. So closing it now. |