Bugzilla – Full Text Bug Listing
| Summary: | should we get rid of the tree in the navigator? | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> | ||||
| Component: | Client | Assignee: | Susan McCourt <susan> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | antonm, bokowski, carolynmacleod4, eclipse.felipe, grant_gayed, john.arthorne, johnjbarton, ken_walker, libingw, madtom1999, mamacdon, simon_kaegi | ||||
| Version: | 0.3 | ||||||
| Target Milestone: | 0.4 M2 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=366265 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Susan McCourt
Simon votes to "just do it" in M2. Sounds kinda fun. I think the times I use the twistie are out of old habit, and if it were gone I would just get used to drill in/out. But we would probably need to keep the existing code working as a fallback, at least for awhile, or (errr....a preference...yuck....but maybe) (In reply to comment #0) > who uses the expand/collapse? I do, it is faster than "drilling in and out with items "... and without them we would not be able to see two (or more) folder content in the same page. I like to keep the navigator open in a state where I can quickly open files (ctrl+click) from different folders, for example: web/orion/textview/ textView.js textModel.js etc web/orion/editor/ editor.js editorFeatures.js etc web/examples/textview/ demo.js etc I agree with the last comment; my recent exploration through the org.eclipse.orion.client code, comparing structural similarities between its bundles, etc., would have been slower and more difficult without the tree. I think having multiple branches available on a page is easier than each being on its own tab. Created attachment 208204 [details]
screenshot mock up of simplified navigation tree
I use the tree, breadcrumbs and favorites. My vote is to keep the tree, but strip it of icons and the header, sharpen the font and maybe the triangle joints. See screenshot. I'd like to be able to use it at the side too. (In reply to comment #5) > I use the tree, breadcrumbs and favorites. My vote is to keep the tree, but > strip it of icons and the header, sharpen the font and maybe the triangle > joints. The icons are mostly clutter right now, but they're handy for images (thumbnails) and they would become more useful if we let a content type provide a custom icon. I think we should at least get rid of the tree for the mobile use case -- a Github-like single-folder table would be better there. But like Grant, I appreciate the tree for browsing. I wish the twistie was easier to target though. I hacked up the "treeless" nav in my workspace and after I few minutes of usage I notice: - I would want a next/prev/go up closer to the nav if I'm going to navigate that way Incidentally it was trivial to change the behavior in the code, so supporting both modes would not be difficult. (In reply to comment #6) > The icons are mostly clutter right now, but they're handy for images > (thumbnails) and they would become more useful if we let a content type provide > a custom icon. Do we have a bug for this? We should. (In reply to comment #5) > I use the tree, breadcrumbs and favorites. My vote is to keep the tree, but > strip it of icons and the header, sharpen the font and maybe the triangle > joints. See screenshot. I wrote a bunch of comments about clutter and realized I was getting off topic. See bug 366258. (In reply to comment #7) > (In reply to comment #6) > > The icons are mostly clutter right now, but they're handy for images > > (thumbnails) and they would become more useful if we let a content type provide > > a custom icon. > > Do we have a bug for this? We should. Opened Bug 366265 perhaps we should do like search results and choose a default representation (flat?) and provide a way to switch it. (In reply to comment #9) > perhaps we should do like search results and choose a default representation > (flat?) and provide a way to switch it. If we are in the root and use the flat view, does that mean walking through all the leaf nodes(files) and show them in a flat list? How about a leaf node that is just a folder? I found myself recently use breadcrumb a lot to dill in/out. It gives me a clear context where I am now. Favorite is also a key for me. I even never tried to use breadcrumb again once I have a favorite folder. Tree has been really rarely used recently. If you click on the folder name don't you get the non-tree mode already? I admit I still like the tree. The reasons have already been given - faster to explore and "find" things, and sometimes you just need to see the contents of two folders at once. I drill down a lot to keep the tree small and simple, but will often expand the tree at least one level. For example a page I am currently working on has the structure: - blah.html - blah.css - images/ a-bunch-of-images.png It's handy to be able to see all that in one place. The only reason I can imagine for having two modes is to experiment with different layouts. Otherwise people who don't like trees can just treat the current navigator like it isn't a tree (always drill down instead of expanding twisties). I'd be willing to force myself to use a tree-less layout in the name of experimentation though. Just thinking out loud... an alternate layout to a tree that would still give a bit of context would be a flat list, where clicking on a folder opens a slideout showing its children while still showing all the folder's siblings (kind of like the slide-out palettes in some drawing tools). It would only work to depth one. Clicking a child folder would drill down into that folder. This would let you do things like see the contents of two folders at once, see the siblings of the folder you are viewing, etc, but without the infinite depth problems and fiddly little twisties of a tree... Anyway just a thought. I wonder if we just fixed the twistie problem (big enough to hit, but much more subtle/not a solid color) and then didn't have it on small screens (as suggested by Mark in comment 6), we might be good. Because one thing I've been wrestling with is that we want a nice hit area, but it takes up too much room on mobile, but if it's small on mobile it's useless anyway. So I kind of like the idea of CSS'ing it. We could use media queries where we get rid of the twisties when the screen is, say, 1024 or less (or maybe smaller, we can argue about where the twisties go away). And on larger screens we make the twistie prettier and easier to hit. And the keyboard access part for screen readers...we could possibly not worry about all the cursor rules for twistie keyboard access because the non-sighted user can navigate to the link (vs. the twistie) and still drill down. Best of all worlds? My personal desire is to have a 'fold/branch' closable from the bottom. When a fold/branch opens one scrolls to the bottom and then you have to scroll all the way back up which can lead to a loss of 'sync' with the data. (In reply to comment #15) > My personal desire is to have a 'fold/branch' closable from the bottom. When a > fold/branch opens one scrolls to the bottom and then you have to scroll all the > way back up which can lead to a loss of 'sync' with the data. I understand the problem you are describing (having to scroll and then reset your "context" when you scroll back up). But I'm not sure I understand the suggestion. Are you suggesting something like a "next level" pane at the bottom where your contents are always shown? (In reply to comment #14) > I wonder if we just fixed the twistie problem (big enough to hit, but much more > subtle/not a solid color) and then didn't have it on small screens (as > suggested by Mark in comment 6), we might be good. > > Because one thing I've been wrestling with is that we want a nice hit area, but > it takes up too much room on mobile, but if it's small on mobile it's useless > anyway. > > So I kind of like the idea of CSS'ing it. We could use media queries where we > get rid of the twisties when the screen is, say, 1024 or less (or maybe > smaller, we can argue about where the twisties go away). And on larger screens > we make the twistie prettier and easier to hit. I played around with using media queries to replace the twistie with the folder icon on small devices. Then I had to jump through hoops in the js to detect this case and disable the expand/collapse behavior. In the end, it felt draconian to make this decision at a device level. Who am I to say you can't use the tree if you happen to be on a 1024 or less device? So...what I did here was change the styling of the twistie on smaller screens. I didn't change the icon per se, but I added a lot more padding all the way around the checkbox and twistie so that it's just much easier to hit them. I also added more "dead space" between checkbox, twistie, and link, so that it wouldn't be too easy to accidentally hit one or the other without some "dead space" in between. Trying it on an ipad...it was very easy to check/expand/collapse/select links without needing to use my smallest finger or zoom. This might be good enough? I'm going to mark this fixed based on what we did. We have tried to make the tree more usable on small devices, less cluttered in appearance, etc. The twistie is going to become less obstrusive in bug 364399. I think there is enough desire for tree behavior that we aren't going to remove it in the navigator. (Note we are removing it for the repositories view in bug 359621. |