Community
Participate
Working Groups
Quote from a thread on the dev list: "Although the editor now looks different, things like the navigator still look (err, how do I phrase this nicely...), a bit crude . Not in terms of colours, more in terms of the boxes/arrows/icons - not sure if they're just too big for my tastes, or there is too much clutter, or what it is. I just don't find the orion navigator layout as appealing as something like the one in the koding editor. Do you know if there are plans to allowing theming to that extreme? If I change the CSS do I have the level of control to change that, or would I need to do real programming?" I took a quick look at the Koding navigation ( from a screenshot ). It does seem simpler/cleaner looking than the Orion navigation. Without using it, I can't tell how they achieve usability for adding folders, adding files etc. It seems to me in the screenshot that it is a read only navigation, whereas Orions can be added to. If our navigation was read only, we could certainly simplify the elements and icons within it. Orion's navigation is busier and perhaps noisier because each row has a check-box and a time-stamp. The downward arrows with three stripes for selecting a drop-down menu are large and perhaps not the cleanest of choices because of the aggregated number of stripes that collect when there are multiple rows in the navigation. We could remove some of the arrow icons from the inner branches - just clicking on the name of the branch could open it. That would reduce the number of icons, and align it more closely to the workings of the Koding app. Mine are just observations on the differences. I thought I'd make a bug to remember the observation from the dev list.
How about a link or copy of the screenshot you are comparing to?
Created attachment 213770 [details] Koding navigation Andy mentioned 'Koding' in his thread. I just did a search for that and found koding.com. I don't have an account, I made my comments based on a screenshot that I saw there. I've attached it. Could in fact be that Andy was referring to something else!
Ok thanks. The koding screenshot shows more of an IDE like file selection widget. Orion's navigator is more like an OS file system window, Finder, Windows Explorer.
I agree. You managed to say more clearly what I was hinting at in my spiel above. A few thoughts. On reflection I wonder if Andy was suggesting that koding looks a little more 'slick' in general - it does look quite polished in the screenshot. When searching for something, I think I could happily use a more lightweight 'read only' IDE navigation system view that is docked. OS File system views can still look quite cleanly presented too.
Thanks for raising this Anton. Yes, the screenshot i picked (out of thin air) was the koding one when you visit their site and press the arrow to see a picture. It is just one example though - the original list that was linked to on the mail thread contained many other slick views - some web apps some not. That link was: http://www.designtickle.com/2012/04/dribbble-shots-source-code-ide-editors/ > On reflection I wonder if Andy was suggesting that koding looks a little more > 'slick' in general - it does look quite polished in the screenshot. exactly right. I don't see that it has to be a choice between a read only view and a more interactive view though. It can just be a question of only sticking the 'chrome' for interacting with nodes on the screen when it is required.For example, the pull down arrows to access numerous sub menus (create new file, etc) appearing only when I hover over the navigator entries, rather than being there all the time. And the big arrows to the left of folder nodes - they don't look very nice. And the checkboxes to the left of the arrows, are they really necessary, can single (or multiselect) not be done in a nicer way with a 'click' (shift-click) of the nodes to select/highlight them? (change their background or something, rather than a crude checkbox). Now I may be talking beyond what is possible here as I'm not a js/widgety programming guru (yet) :)
> I don't see that it has to be a choice between a read only view and a more > interactive view though. It can just be a question of only sticking the > 'chrome' for interacting with nodes on the screen when it is required.For > example, the pull down arrows to access numerous sub menus (create new file, > etc) appearing only when I hover over the navigator entries, rather than being > there all the time. And the big arrows to the left of folder nodes - they > don't look very nice. And the checkboxes to the left of the arrows, are they > really necessary, can single (or multiselect) not be done in a nicer way with a > 'click' (shift-click) of the nodes to select/highlight them? (change their > background or something, rather than a crude checkbox). Now I may be talking > beyond what is possible here as I'm not a js/widgety programming guru (yet) :) Just some historical stuff... We used to show commands only on hover but we abandoned that approach because tablet users couldn't discover the functionality. We used to have a lot of atomic commands in a column (not all grouped in a menu) and part of making them visible all the time was to group them. Likewise we've played with those twistie sizes, etc. to find a good common ground where you can still hit it with your finger. We've done some little things like increasing hit space (but not icon size) on a tablet. Maybe it's time to consider different graphics for those cases. There seems to be consensus from multiple places that both the look and raggedy placement of the chevron for invoking commands is not good.
Created attachment 213920 [details] Google Docs Screenshot
I've been thinking a little about this over the past couple of days. I really admire the Google Docs model of navigation which is not a million miles different from ours but there are a couple of significant differences that I think we could learn from. I've attached a screenshot, and don't have too much time to go into all of my thoughts now, but I'll start off on a few. First thought surrounds icons. Icons these days from my observation, in Google apps, in Twitter and in mobile apps are more monochrome and block-y. For instance the folder icons on Google Docs are classy, clean and simple. Same goes for the trashcan icon. iPhone navigation icons are similar. I'd prefer for ours to be like that - and for our icons in general to not be elaborate, preferably not yellow, and solid. I'm trying to think of a way of describing the icon style. I tried to mimic the style in my plugin icons. Layout The Google Docs navigation layout has the tree to one side, and a table like ours on the other side. Not a tree table like ours, a tree and a table. I like how the Google Docs layout takes up the whole screen - I'm not sure what the layout goal of ours is - it takes up part of the screen, and I'm not unhappy with that - just that as a user/developer maybe with my design hat on I wonder why. I absolutely love how when I select a row in the list on Google Docs that it offers a row of nicely sized buttons with clean simple icons at the top. I can right click too - and it overrides the right click of the browser. I'm less hung up on that these days. Mobile On a tablet, there is a mobile version offered, which I find lacking - probably designed for a phone. But you can switch to the desktop view on a tablet. I wonder why the desktop is the default on a tablet, because it works beautifully - I wouldn't be surprised if had been designed with that intention. By default the documents all open on a new tab. This application is used by millions of people that obviously haven't ruled in the majority to open it in the same tab. Overall the document navigation, is clean, modern and gets the job done in this case. Just some thoughts from that user experience for me.
(In reply to comment #8) All good observations. But this one stands out for me though as a symptom of a greater issue: > I like how the Google Docs layout takes up the whole screen - I'm not sure what > the layout goal of ours is - it takes up part of the screen, and I'm not > unhappy with that - just that as a user/developer maybe with my design hat on I > wonder why. We don't have a good story for what a new user sees when they get to Orion, and what an existing user sees. This is covered in other places such as bug 345622 and bug 368739. Meanwhile we have this navigator that really doesn't show very much. I think that the navigator should evolve to be more like a (logged in) landing page. Users with content can browse content but can also create new kinds of projects. Users with no content might see those "getting started" suggestions for how to create a project or better yet can quickly create some canned ones. This is discussed in bug 345622 but there are aspects from this (old) mockup that also apply: https://bugs.eclipse.org/bugs/attachment.cgi?id=205865
(In reply to comment #8) > I like how the Google Docs layout takes up the whole screen - I'm not sure what > the layout goal of ours is - it takes up part of the screen, and I'm not > unhappy with that - just that as a user/developer maybe with my design hat on I > wonder why. I like the compact navigator layout. It should take up no more space than it needs. Otherwise you waste a lot of motion to move from control to control and you quickly find yourself scrolling to see the results. The git pages have become almost unusable because of these effects. Let's not throw out the good aspects of the navigator page unless we really have a better solution.
I guess the icons would be fine if the workflow was excellent. However, the current navigator behavior is bizarre: the twisty disclosures close and the UI flashes a lot, eg when you rename a file.
The triangles on the tree seem large. The tree would look cleaner without them on the inner nodes. In terms of my comment about screen width - I don't think it would necessarily change anything regarding height or travel - the height would remain the same. I think it would be beneficial to see the author of the code in there too - much like the google docs screenshot. My comment about the icons was more that I think they they could/should look more modern and cleaner - and not out of place in a mobile environment. The trend at the moment is for monochrome/solid clean icons. I'm not a fan of the yellow on white. I'm not sure it is the easiest combination on the eye. Though I suppose my comments may be personal. On the other hand it is a little bit of a unique choice - perhaps there's a reason why we don't see that combination very much in the wider world. I like the google docs table too in that you can choose to either select a row or to select the checkbox. Choosing the row translates well on the tablet. I imagine the checkbox is there for accessibility.
re icons: The attempt was to get a monochrome-ish style vs. full color, but I agree the orion yellow is not working. I wonder if a programmatic pass to darken them would help.
(In reply to comment #13) > re icons: The attempt was to get a monochrome-ish style vs. full color, but I > agree the orion yellow is not working. I wonder if a programmatic pass to > darken them would help. I think this is worth pulling out in a separate bug since it's not specifically nav related. Opened bug 377105
While working on some other bugs, there has been some improvement here (I hope). We've got a new selection model that doesn't require a checkbox (bug 377018)and we've moved the chevron commands to the "More" menu. (bug 367458). I also found some problems/inconsistencies in our default font specification and cleaned that up. The net effect is that the nav font is smaller. I'm sure there's room for improvement but the work in these bugs is at least making things look a little more consistent/clean.
There has been so much evolution of the Orion UI over the past two years that I think this bug no longer contains relevant discussion. We should open new bugs to track further suggestions.
