The SketchUp Free Interface

One thing I really hate about most web apps is that everything is big enough to accommodate a finger tap. This is a tremendous waste of screen real estate for a young user like me with good vision.

image

3 Likes

Or even an old one like me, who (with glasses worn since age 5, now 70 years ago) can still easily read 5-7pt type

2 Likes

@jbacus: Did you see the link to this post from the What’s up with SketchUp Make thread last week? This was intended as a more elaborate response than what I thought suited the other thread.

I did, thanks

1 Like

I’ve fiddled a little with the my.sketchup CSS and found it to work much, much better for me with these changes. I increased the margin between browser from 5 to 15 px and added 5 px margin on all other sides of the browsers.

2017-12-18_14h51_20

Suddenly I can easily see what content belong to what browser and use my.sketchup without getting a headache!

The margins on the sides of each browser makes it possible to read the browser title bar and browser content together as one element and the extra spacing between browsers further distinguishes them.

Maybe the spacing needs to be adjusted to fit some grid or rhythm that I haven’t noticed but overall I think this would be great improvement.

Thoughts? @ericdbohn

Same idea applied to component editing. With the margin you can actually see the component editing is a child of the Component browser, and not just lives in the void between two browsers (of which the latter doesn’t have a title).

Now I used a 10 px margin to line up with the component preview but maybe this is too much. Anyhow, the idea is communicated.

12 posts were split to a new topic: Unhide rest of model

Another proposed styling change: set checkbox background to white so un-ticked but enabled checkboxes can be distinguished from the disabled ones.

Before:
2017-12-19_09h58_41

After:
2017-12-19_10h25_18

A post was merged into an existing topic: Unhide rest of model

I find that canvas#canvas.printable being positioned under UI elements effects modelling adversely…

zoom extents ends up hiding parts of the model under the footer and menu bars…

it is not good UX design as it destroys the primary use of zoom extents

john

1 Like

The left menu and right collapse bar thingy are so small they being in front of the viewport don’t bother me much. The browser though cover a quite large portion of the screen. I don’t know if users are expected to hide it when finished using a browser. The drawing area going in behind the status bar is just wrong to me. Since the status bar always cover the full width of the screen you expect the viewport to end just above it.

I wish the top level menu also covered the full width. It would be symmetrical to the status bar, it would interfere less with the viewport by not having to cover a corner of it and it would give enough space for a proper, conventional top menu containing File, Edit etc so you easily can find what you are locking for.

Having a proper menu with named entries ism also a requirement to implement custom shortcuts the way they are implemented in the desktop version.

as you know F11 cleans up the screen nicely.

It does not. It just enables full screen which is worthless for for everything but passively watching videos as it hides the taskbar with all open documents, the time and date, the start menu etc.

To clean up the UI you need to press f12 and manually change the CSS on a number of places.

1 Like

Agree.

Agree. The Camera “Views” part takes up way to much space, and this gets annoying when you just want to get at scenes.

Also the round expand button takes up too much vertical space. It can move to the left beneath the two “perspective” / “parallel” tabs, and not add vertical space to the Camera settings.

Hated that in the old pre-SU2016 desktop SketchUp too ! It would be nice to “lock” the Entity Info’s height ?

I’d prefer that the Entity Info inspector not expand until the user moves the mouse over the content. That would be a signal the user wants to see the “extra” information.

1 Like

Could work but then there has to be a visual cue that there is more content so users would understand they need to hover it to see it all. Perhaps there could be a 30 px gradient at the bottom of the panel fading out its controls? Or maybe the panel could be redesigned to have a constant height regardless of content. A compact layout (e.g. front and back material side by side as it used to be in the desktop version) would fix this.

Entity Info

Yes, I guess I should have said that. The desktop editions have a “down arrow” expand button that appears when there is more to see. This is already done in some places of the interface. (It’s a hidden element that then has it’s “display” property set from “none” to one of the visible settings, “block” etc.)

the lack of color for Tool Toolbar items is the biggest obstacle in learning the new interface…

these need to match the cursors to make finding them easier…

color would aid new users when watching pre existing tutorials…

the color of the SU icon hasn’t been ‘greyed’ so why have the functionally more important tool selectors…

john

1 Like

Agree 140%.

This is a very good example of appearance being chosen over usability! Well, Free does look great (mostly), I can’t deny that. But its purpose isn’t to be looked at just for the sake of looking. It’s not a painting!

My experience, both personally and when teaching others, is, just as you say, that colors are highly important. Users seem to remember the color and position of the icon they press (and its neighbors) much better than they remember what the icon is supposed to show.

1 Like

I made a separate post focused solely on the menu: [FR] Proper conventional top menu

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.