The SketchUp Free Interface

There is a lot to be said about SketchUp Free but in this thread I’ll focus on the UI. First of all I’d like to start by saying I don’t think it’s all bad (even though it might sometimes sound like so). I appreciate the attempt to lower the number of inspectors. This can help simplify the whole UI. I know a lot of people won’t agree but I also personally like how there is a pre-defined static order to the inspectors. This will simplify for users helping each other as they’ll always know where to find a certain inspector. Lastly the UI obviously looks beautiful! Even I can’t deny that (even though I value usability higher than appearance).

There is though quite a potential for improvement.

Difficulty Visually Parsing the UI

With the flat design and lack of 3D borders and shadows it’s much harder to visually parse the UI to understand its hierarchy, and know what elements are clickable.

Where is the Material inspector? What inspector does the cross belong to? Is the cross a button? Is it supposed to represent a plus sign thus denoting object creation?

All these questions can of course be answered quite quickly, but not as quickly as in the desktop version. These, by their own tiny, cognitive workloads add up to create a UI that is more tiring to use and distracts from getting the actual modeling done. This is especially troubling for neurodiverse users who struggle to filter information and visually impaired users.

This is in my view inherently a problem with flat design but can be eased by clever use of white-space, color consistency, color contrast and adhering to well established conventions.

No Conventional Top Menu

With no conventional top menu where users can Save, Save As…, Open, Export etc users have to re-learn how to perform these basic tasks. Again, on it’s own, it may seem like a small cognitive load but it adds up to quite a large distraction. Especially for users who switch a lot between different applications it easily becomes plain annoying when one software insist on being a special snowflake and doing things in its completely own way. I just can’t see any reason to re-invent the wheel. The problem is increased by the flat design obfuscating what elements are clickable.

Animated GIF

3 Top menu clickable
Model name is clickable, and apparently saves the model, but the text saved isn’t? Is the text saved of the same type as Untitled but merely disabled? If so, why is this text bold?

When opening what seems to be the main menu there is still no Save option and no Save As option. If you happen to know wht Trimble Connect is you still can’t save the model without opening what I think is supposed to represent a folder (even though it doesn’t look like one). Also, at least for me, there is the impossible choose between SketchUp and SketchUp. Huh?

30 years of evolution has been put into the conventional menu design. By re-using what already works, and what people are used to, a lot of unnecessary problems can be avoided.

Checkboxes looking disabled

To move move into details, but still stay in the area o flat design and old conventions, I find it very hard to distinguish un-ticked checboxes from disabled checkboxes. As I see it this is yet again an example of flat design not working very well in practice. Sticking to the OS checboxes is of course ugly but a lot safer. If every single element is designed from scratch great precaution must be taken to make sure it is done right, e.g. give enabled checkboxes a white background while disabled once are transparent. Again, the user should never have to stop for a fraction of a second to figure out what is clickable and what isn’t.


Inspector Organization

As I’ve already said I really like how the number of inspector is attempted to be kept to a minimum.

However I don’t agree Smooth/Soften edges should be under Display. Display changes globally how the model is viewed (RenderingOptions to use a technical term). Soft/Smooth are properties of the individual edges. I propose for these options be moved into Entity Info where it belongs. When more than one edge is selected it can replace the current checkboxes as it is really the same setting, just set by an angular threshold instead of a toggle. This would stay more true to the conceptual model of SketchUp, making it easier for new users to understand and making the option easier for old users to find.

I’d also like to object to Scenes being forced into the Views inspector. At first glance this inspector controls the camera but scenes are so much more than camera location! Scenes controls styles, axes location, fog, shadows, active section cuts and more. It is very common by advanced users to set up scenes that ONLY changes one of these other properties, e.g. change how a model is cut or swap axes, without touching the camera. Currently it’s hard for old users to find scenes and hard for new users to distinguish View from Display. I’d very much like to propose splitting Camera and Scenes into two inspectors and not have a View inspector.

Inspectors Jumping Up and Down

Finally an issue I noticed today is that whenever the selection changes while Entity Info is open all instructors jump ferociously up and down in a rather distracting manner.

Partly this is because there is no delay for Entity Info to update when the selection changes. In the desktop version there is a short subtle delay, perhaps 200 MS or so. This means that triple clicking for selecting all connected (a very common action!) only updates Entity Info once, not for the initial double click selecting bounded edges/bound faces, on desktop. Fixing this would tame the jumping quite a bit.

Still the issue is caused by Entity Info having different heights depending on its content, and being atop the other inspectors. I don’t know if it could be moved to the button (it really makes sense to have it at the top). Redesigning it to have a static height is probably out of the question (I personally much prefer interfaces where each element is individually places as I find it much easier to remember where things are but understand it is much less work and more contemporary to programmatically generate a uniform list). Maybe the inspectors could automatically scroll to compensate Entity Info changes height but the scrollbar would still jump up and down. I don’t know how this could be easily fixed.

Thanks for reading!


I would add that I find the pop out toolbars less than efficient. I spend longer thinking where each tool may be hidden than using them.
I’d prefer a large toolset. One click on the tool you can see rather than, click look oops click look click use.


I agree completely. Even though Large Toolset has more button than Getting Started I find it much easier to remember where things are as you can remember their relative positions to each others, while still seeing all of them at once. With fly-outs you need to know exactly what tools are in the same groups to be able to find them.

On the desktop, I have Entity Info in its own floating tray so it can mostly remain open. Visibility is controlled with a keyboard shortcut if I want to see more of the workspace. MIss that layout in Free. I prefer the more compact layout of Entity Info in the desktop as its info is quite useful and warrants being open as much as possible. Regardless, I don’t get why Entity Info needs to take up so much space in the web version.

I use Deselect All (Select None) enough to assign that command to a mouse button. On the web, that’s missing and Ctrl-T, the desktop shortcut, opens a new browser tab.

The Instructor doesn’t provide keyboard shortcuts.

Mice can be customized per desktop application. This feature doesn’t yet extend to web applications.

1 Like

I struggled with finding where everything is hiding myself, though it’s not fundamentally different than the flyout parts of the large tool palette.

I believe there is a bug there, however. If you need to pre-select objects and then get at a tool other than the one on top, you loose your selection and have to start over. (Keyboard shortcut may circumvent this.) I hit this problem while recording my videos and saw my students hit this too when they tried to follow.

Going back and testing this, I don’t seem to be able to repeat it now, with SU Free or SU for Schools.

I assigned the letter N to it. Ctrl-T needs two hands for a clumsy typist like me.

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.



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


@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.


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.



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


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