Better graphic clues and category differentiation in the browser

[Oceanconcepts]

I would ask what actual interface purpose the tiny icons in front of each individual item in the browser serve.  Many of them are indistinguishable to my eye, and they don't convey any information- but they do take up room. 

The little light bulbs are hard for my over 60 eyes to see- it's hard to tell which ones are on or not when the browser list gets long.  I wonder if the visibility message could be more clearly conveyed by highlighting or color shifting the text box (greyed for visibility off, say)- or even a bigger check box- just not something that relies on distinguishing between a very few pixels being either a yellow or a gray of about the same intensity. 

I would also wonder if the different categories of folders in the browser could be better conveyed by different shapes at one end of the text box, by category outlines or category flags, by changing text weight (i.e. bold for top level folders such as Components, normal for lower level items), or colors- something that is apparent at a glance. Again, when the list gets long and requires scrolling, it's hard to tell where you are. New users are going to miss when new categories appear in the browser, like Analysis, because they look graphically just like everything else. 

Ron

[lure23]

I second this. The browser has a purpose but it can be done better.

Somewhat connected to this are:

- One annoying bug, where mouse events are mishandled within the 'transparent' sections of the Browser. Was mentioned in discussions a month ago, but now I made it an IdeaStation entry to gather more interest in it. At least I'm hitting it often in my work, and it makes the interface feel awkward for newcomers - they wouldn't think there's difference in the visible area near the Browser and further right on the screen. I think it also effects other aspects than dragging.

I think that bug deserves an ASAP handling.

- There is a suggestion by me on how to avoid scrolling the Browser altogether. Implementing this would also allow to use bigger font/icon size for the currently active entry, which would help with Ron's reported issue.

- Sometimes I wish Sketch sub-elements (i.e. 2d constraints) were visible in the Browser (now they are conceptually there, but the user cannot get to them, I think).

- Browser should warrant its own tag in the IdeaStation. There are a lot of suggestions and bugs raised on it, but not a class (s.a. Patch, Sketch, Model, User Interface have).

[stanh1]

Graphic change of state indicators should be large enough to be seen and should consist of a change of gray scale value of at least 20%. If a graphic state indicator must be small for some reason then the change of gray scale value should be >20%. If the graphic is large it can be < 20%. Don't rely on color changes alone without gray scale changes as many users will not register a color change only.

[schneik-adsk]

Lots of ideas here... So allowing for a larger UI seems to be a common theme. What else? Bugs, of course, are being looked at.

[lure23]

Kevin, be careful to re-read Ron's original post. He was asking for a clearer UI, not necessarily larger.

To me, I'm still arguing the gray bar that goes across the whole screen is unneeded (duplicate menus, remember? 🙂 ). Luckily, I can hide it by the arrow icon.

Less UI is a good UI. For CAD.

[schneik-adsk]

Yes, I understand that clearer is also part of Ron's request. I'm trying to find common threads in the comments, but I understand your point.

[Oceanconcepts]

More browser UI thoughts:

Clarity, not size:

I don't think the browser UI needs to be bigger, I just think it could be made clearer and more obvious and informative.  Less cluttered with things like identical icons, and with more obvious visual cues as to the state of visibility, selectability, and the nature of different categories. Looking at Analysis, Bodies, Sketches, Construction, Components- all the icons for these categories are identical, which makes me ask what information they convey to the user.  

Small targets, hard to see:

Switching on and off visibility is one of the things I'm doing constantly, and the little light bulb is a bit subtle, small, and hard to hit accurately- the active area is not clearly indicated by the graphic design.  I think that graphically this indicator could stand to be improved.  Things that convey important information, like the light bulb, or the Selectable/ Un-selectable indicator, are very small.  It seems to me using something more obvious, like text weight or color, or a big check box to hit, would help make the interface clearer without taking any more room. 

Color use, variation in grayscale intensity:

In our own UI designs we use color a lot as a primary indicator of data type- but it's important to check the colors against common color perception problems- everyone doesn't see colors the same way. Stan's point about gray scale changes is spot on. There is almost no variation on the visibility indicator between the on and off state. 

Navigation (a biggie):

Browser navigation is an issue when the drawing gets complex.  I'm finding myself needing to jump from a newly created component, scroll several screen heights up to the Sketch area, or to Construction, and then back, and needing to toggle on and off visibility while in an action.   It makes me wonder if tab type functions or web like floating navigation options could be helpful- just hit Sketch to jump to Sketch.  I find myself wanting to organize the drawing into ever deeper nests of components, just to make scrolling easier. Cobalt used a combination Tab and list format to swap between history and layer views, and Adobe uses multiple tabs and lists in Photoshop as a way of managing this kind of complexity.  I really think this needs to be dealt with for those of us with lots of parts in our designs. 

Unclear content- related to navigation and usefulness:

re. the attached picture, and the items between Construction and my first Component, Wrist_lens: Why do I end up collecting a long list of "actions" in the browser, that can't be collapsed?  Is this some kind of leftover from creating bodies that later were turned into components, or used to modify them? Eliminating them doesn't seem to make for a happy outcome- if I delete Extrude85, for instance, the hole that I created with the extrude goes away. But this list makes scrolling the browser much more difficult as it grows, and it's not clear to me what the purpose of these items occupying non-collapsible real estate is. What category does this represent?  I'm very likely missing something basic- but I'll go out on a limb as suggest that probably others are as well.  This post was prompted by another user missing that the Analysis category had appeared in the browser with visibility on- and it's really not obvious as it looks just like everything else in the browser. 

Let us name our construction features: 

As I and others have said, I'd really like to be able to name construction features. I may create a dozen different axis or construction planes, it seems wrong to need to turn on and off visibility to see which one is which. 

I love the Browser:

The principle and the logic of the browser interface are great, and something that I'm finding very helpful as I exploit the organizational power more.  I'm just laying out the parts that I personally experience as stumbling blocks. Mostly these are around navigation and graphic design, not the basic concept.

Ron

[lure23]

+1 for Ron.

(Why oh why is IdeaStation different from other forums: no thumbs up, no signatures.)