Bugzilla – Full Text Bug Listing
| Summary: | [search results] current position marker and navigation | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> | ||||||
| Component: | Client | Assignee: | libing wang <libingw> | ||||||
| Status: | CLOSED INVALID | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | john.arthorne, libingw, mamacdon, simon_kaegi | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Susan McCourt
Another improvement would be to color the entire "stripe" in the search results (as is done when you check a box in the navigator)...I think that could also help differentiate "current result" from "select this thing" Generalizing title. We discussed this some on the orion call. Wondering about the use of the next/prev and current position marker in general. In Eclipse it was there to move through the editor from the results page. With a separate results page, this doesn't make much sense. John suggested instead that we open the page on the line number (as we do now) but preload the find/replace with the search term so that the user can navigate through the matches in the editor. I really like this idea for navigation. Not sure if we need the find/replace bar to be opened, or if it's just enough to have the token set as the current search term and then I could use the keybindings to navigate prev and next. I've checked in the fix to to color the entire "stripe" in the search results , with e80e087f72755a0e32403cbe98d5dec268d29f09. This indicates that the highlighted match is the current one. Another interesting functionality by the next/prev navigation, as I mentioned in the last minute of today's call, is to auto-expand the next match block when you are at the bottom of a block and have no idea where the next match is. I keep this bug open for more comments. (In reply to comment #3) > I've checked in the fix to to color the entire "stripe" in the search results , > with e80e087f72755a0e32403cbe98d5dec268d29f09. I find that helps with the visual, though I still find the blue color to be much harsher/attention grabbing than the one in the editor. Will attach a screenshot. > This indicates that the highlighted match is the current one. > Another interesting functionality by the next/prev navigation, as I mentioned > in the last minute of today's call, is to auto-expand the next match block when > you are at the bottom of a block and have no idea where the next match is. > > I keep this bug open for more comments. I wonder if we should step back a moment. If the main point of next/prev is to help navigate through the results and do auto-expands, is the problem really the deeply nested presentation of results? I think my tendency would be to always "expand all" when I'm looking for something. I'm not sure that the nesting by individual folder is all that helpful. In the screenshot I'm about to attach, there are 6 levels of nesting to wade through before I see a result. For me, some of the path info is relevant (for example, suppose I care about all results in org.eclipse.orion.client.core but perhaps not org.eclipse.orion.client.git). Some ideas: - Maybe we should organize by path but not require traversal of the nesting, such as not showing empty folders and concatentating the path together. So that org.eclipse.orion.client bundles org.eclipse.orion.client.core web js-tests fileapi dummyFilePlugin.html result1 result2 becomes org.eclipse.orion.client/bundles/org.eclipse.orion.client.core/web/js-tests/fileapi/ dummyFilePlugin.html result1 result2 - Or for that matter, flatten the list but sort by location, and show full path info to the right of the name, or on hover, perhaps in a less obstrusive color). dummyFilePlugin.html (org.eclipse.oroin.client/bundles/org.eclipse.orion.client.core/web/js-tests/fileapi/) result1 result2 I'm not really sure here, but I think we should be careful about designing to optimize the deeply nested experience when that might not be the way to present the results. I really like the nested presentation of the multiple hits per file and ability to navigate directly to the line number, and to be able to expand/collapse the detailed hits. This discussion is not intended for 0.3, so if you would rather I open a bug to separate small changes from bigger conceptual issues, I can. Let me know. Created attachment 203916 [details]
screenshot
(In reply to comment #4) > I find that helps with the visual, though I still find the blue color to be > much harsher/attention grabbing than the one in the editor. Will attach a > screenshot. The same color in the editor is hard to see in the search result because there are alternative lines in the table. > I think my tendency would be to always "expand all" when I'm looking for >something. I'm not sure that the > nesting by individual folder is all that helpful. Always expand all will cause performance issues. The "current result" will trigger the expansion if needed. > - Maybe we should organize by path but not require traversal of the nesting, > such as not showing empty folders and concatentating the path together. > So that > org.eclipse.orion.client > bundles > org.eclipse.orion.client.core > web > js-tests > fileapi > dummyFilePlugin.html > result1 > result2 > > becomes > > org.eclipse.orion.client/bundles/org.eclipse.orion.client.core/web/js-tests/fileapi/ > dummyFilePlugin.html > result1 > result2 > This is another option but if there are some files sitting in the middle, say , org.eclipse.orion.client/bundles/org.eclipse.orion.client.core/web/anotherFile.js, will we put that as a parent node ? > This discussion is not intended for 0.3, so if you would rather I open a bug to > separate small changes from bigger conceptual issues, I can. Let me know. Please open separate bugs for 0.3. (In reply to comment #6) > > Always expand all will cause performance issues. The "current result" will > trigger the expansion if needed. I haven't looked at the server side of this in awhile. Do we have to do multiple gets to get search details? (ie, do we just get the file list and then we have to go and get the detailed hit list in the file?) Seems like we should minimally expand all to show all files since we know that information after the initial search get. > This is another option but if there are some files sitting in the middle, say , > org.eclipse.orion.client/bundles/org.eclipse.orion.client.core/web/anotherFile.js, > will we put that as a parent node ? Several options. We could go completely flat up to the file level (such as the eclipse search results view in flat mode.) Then the user could sort by file name, or if they care about groupings, they could sort by full path name, which would give you the nested groupings but without having real parent nodes. More google-ish. Also kind of like windows explorer search results. User could still expand the file if they want to see the individual line number hits. Or we could keep nesting and if there is a file in the middle, the parent node is retained. But we would still autoexpand to the file level (i'm still assuming we know all files up front). Examples: Today------------- >FolderA >FolderB >FolderC +SomeHit.js (9 hits) >FolderD >FolderE +AnotherHit.js (10 hits) Flat--------------- +SomeHit.js (FolderA/FolderB/FolderC) (9 hits) +AnotherHit.js (FolderA/FolderB/FolderC/FolderD/FolderE) (10 hits) Hybrid --- >FolderA/FolderB/FolderC >FolderD/FolderE +AnotherHit.js (9 hits) +SomeHit.js (10 hits) In each of these examples, file level is not automatically expanded to show individual hits. You can click to go to the file or expand to see the individual hits. Maybe flat is simpler. I remember Eclipse having a hybrid view, and John reminded me about the CVS Synch view, which has flat/tree/compressed folders (though it didn't seem to work properly in the examples I tried to build.) There are probably other examples out there Created attachment 204109 [details]
Example of compressed folders in CVS sync view
(In reply to comment #7) > I haven't looked at the server side of this in awhile. Do we have to do > multiple gets to get search details? (ie, do we just get the file list and > then we have to go and get the detailed hit list in the file?) Server only gives back a list of file (location , name, etc). Expanding a file need us to : 1.Get the file content. 2.Search inside the file on client side. That is why before you expand a file, you don't even see the (number of matches) on the file name. > Seems like we should minimally expand all to show all files since we know that > information after the initial search get. We can do this, plus, expanding all the matches in the first file. As a user I want to see the first match as default. > Hybrid --- > >FolderA/FolderB/FolderC > >FolderD/FolderE > +AnotherHit.js (9 hits) > +SomeHit.js (10 hits) > > In each of these examples, file level is not automatically expanded to show > individual hits. You can click to go to the file or expand to see the > individual hits. I prefer to hybrid but my mind is open. My existing algorithm to "build the tree from a flat list" has to change so that it can compress some levels of parents into one. But I will hold on for now till we have a solid solution. > Maybe flat is simpler. I remember Eclipse having a hybrid view, and John > reminded me about the CVS Synch view, which has flat/tree/compressed folders > (though it didn't seem to work properly in the examples I tried to build.) > There are probably other examples out there. To me, I don't like flat because if we will have actions on checked items (say, we want to hide the result on a top level node. In flat format you have to multi-select and do the action. But we can still have flat as an alternative view, like Eclipse does. Susan/John, once we decide, could you open a separate bug on he compressed S (In reply to comment #8) > Created attachment 204109 [details] > Example of compressed folders in CVS sync view I think this screen cap makes sense to me, once we decide I will open a separate bug for the "compressed parent node" structure, which Susan called it hybrid. (In reply to comment #9) > Server only gives back a list of file (location , name, etc). Expanding a file > need us to : > 1.Get the file content. > 2.Search inside the file on client side. > That is why before you expand a file, you don't even see the (number of > matches) on the file name. Makes sense, thanks. > We can do this, plus, expanding all the matches in the first file. > As a user I want to see the first match as default. I think this depends on the task. - I need to replace all occurrences of "eclipse.foo" with "orion.foo" but I want to look at what I'm doing. In this case I want to see first match and have a way of going through all hits and doing something. That could be the current next/prev navigation, or jumping to the editor and taking care of everything from there. This is where we have been debating workflows like "show part of the file in search results" or "show search results in the editor" (bug 358764). - "I need that file with "foo.bar" in it. In this case I may not care about individual results, I want to scan the list of file hits (without navigating through individual matches) in order to find a particular file in question. There are probably other use cases. I need to use it for real work for awhile before having a strong opinion. (In reply to comment #10) > Susan/John, once we decide, could you open a separate bug on he compressed S > (In reply to comment #8) > > Created attachment 204109 [details] [details] > > Example of compressed folders in CVS sync view > > I think this screen cap makes sense to me, once we decide I will open a > separate bug for the "compressed parent node" structure, which Susan called it > hybrid. Opened and fixed bug 359325. (In reply to comment #6) > (In reply to comment #4) > > > I find that helps with the visual, though I still find the blue color to be > > much harsher/attention grabbing than the one in the editor. Will attach a > > screenshot. > The same color in the editor is hard to see in the search result because there > are alternative lines in the table. The bright cyan color still hurts my eyes. Linda (graphic designer) chose a highlight color for navigator checked icons that works well with the alternative lines. Can we try that? .checkedRow { background-color: #e3e3e3 !important; } I am closi9ng this now because: 1.We no longer use tree view. 2.As the flat format we are using a 2-level tree where navigation follows a generic rule defined in explorerNavHandler.js, used now for both search result and file navigation pages. 3.Susan is working with Linda for a better visual design for the "current cursor". This will be used Orion wide. |