Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 338001

Summary:	[client] searchbox on editor page - what should workflow be?
Product:	[ECD] Orion	Reporter:	Susan McCourt <susan>
Component:	Client	Assignee:	Susan McCourt <susan>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	bokowski, john.arthorne
Version:	0.2
Target Milestone:	0.2
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Susan McCourt

2011-02-23 12:37:39 EST

I've been assuming that for consistency and discovery, we should put the global search bar on the editor page.  (You can also search using ctrl-H from within the editor)

What should the workflow be?
* replace the current page with a search results page 
  + what most sites do
  - most of the time when I'm editing, I want to see some more code, not replace my code
  - navigator behaves slightly differently

* use a results float like we do for ctrl-h
  + lets me keep my context and use ctrl-click to open results
  - not typical
  - inconsistent with navigator

Since I don't have a great idea, I think we should do what everyone else does.  (Can anyone think of a site that does something different and it works well/is not a surprise?)
So I would propose:
- have a bannered search results page that shows the favorites list (kind of like the nav looks today when you search)
- editor and nav both replace the page with this results page
- use browser history to get back to editor if that's not what you meant
- when working on code, users could still use ctrl-h to see results in a float and ctrl-click to a new page

Anyone have a better idea/example?

Comment 1 Susan McCourt

2011-02-24 03:54:30 EST

I took a first pass at this.  We now have a dedicated search results page.  It currently looks very much like the navigator, in that it has the favorites/searches panel along with results.   In the future we could add commands for doing advanced searches, or refining the search settings, etc.

Comment 2 Susan McCourt

2011-02-24 03:54:48 EST

fixed.

Comment 3 John Arthorne

2011-02-24 14:17:19 EST

I think I mentioned this before, but I really like what the GitHub search does:

- Search results appear on current page
- I can cancel the search to get back what was previously shown (hitting Esc)
- I can ctrl-click a result to open that result on a separate page.

Having said that, this is quite a fancy solution, so I'm fine with something simple for the near term.

Comment 4 Boris Bokowski

2011-02-24 14:35:54 EST

(In reply to comment #3)
> - Search results appear on current page
> - I can cancel the search to get back what was previously shown (hitting Esc)

I couldn't find this search UI - on which GitHub page(s) did you see it?

Comment 5 John Arthorne

2011-02-24 16:57:57 EST

(In reply to comment #4)
> I couldn't find this search UI - on which GitHub page(s) did you see it?

Any page where you are viewing a repository, a directory listing, or a file. Hit the letter 't'.

Comment 6 Susan McCourt

2011-02-24 17:02:50 EST

(In reply to comment #5)
> (In reply to comment #4)
> > I couldn't find this search UI - on which GitHub page(s) did you see it?
> 
> Any page where you are viewing a repository, a directory listing, or a file.
> Hit the letter 't'.

I think of the GitHub 't' as being a better implementation of "open resource."  (And I'd like to look at getting rid of the open resource dialog in favor of this at some point).

But I think our searchbox behavior is pretty close to GitHub's.  When you are searching the site/content for stuff, you get a page of results.

Comment 7 Susan McCourt

2011-02-24 17:05:11 EST

(In reply to comment #6)

> I think of the GitHub 't' as being a better implementation of "open resource." 
> (And I'd like to look at getting rid of the open resource dialog in favor of
> this at some point).
bug 334044  covers this part.