Initials thoughts on the Mac UX


#1

I’ve been using the Mac beta for about three weeks and have held off posting anything until I felt any quirks I encountered weren’t being caused by user error.

The single window user interface is a joy to use and has many little tweaks over it’s windows cousin that I like e.g. the ability to easily open and close the sidebar windows for those occasions when you need maximum screen real estate for the viewports (would be even better if that feature could be actioned via keyboard shortcuts) . I’m in agreement that the Windows interface has become cluttered by the introduction of the ‘ribbon like’ tab bar in V5 but I think this is missing the point a little of how useful the tab bar is. Once you customise the tab bar to your specific workflows it makes much more sense so not having this customisation feature within the Mac version is something I miss.

I like the fact that the Mac version of Rhino is attempting to give a Mac like user experience but at the moment the default settings feel a little ‘Frankensteins Monster’. One I’d configured everything to my liking via the preferences I got closer to what I look for in an OS X program but I feel the default settings leave you between ‘pillar & post’. It was alien to me both as someone who is experienced in the Windows version of Rhino and as daily user of OS X as my primary OS. I’m sure this is in part because I’m testing a beta product but I would suggest some kind of wizard to help users configure their experience on first run based on whether they’re migrating from Windows or are brand new to Rhino.

The viewport management features are lacking the sophistication of the Windows version and much as I like the streamlined OS X friendly way of entering commands I do miss being able to expand the command window interface to 3 or 4 lines so I can get a quick view of the last commands I entered (having to open the command history palette for this info is cumbersome).

Having said all that I was pleasantly surprised with the overall experience of Rhino on my Mac and feel sure that it will mature into a solid product in the coming months.


(Marlin Prowell) #2

There are already commands ToggleLeftSidebar and ToggleRightSidebar which can be attached to scrren edge macros or trackpad gestures. In the next WIP release, these will have the keyboard shortcuts Command-0 (zero) and Command-Option-0 (zero).

The changes to the single modeling window are not finished. This feature will be back in a slightly different form.

I’m well aware that the Mac version is trying to please two different masters. Would you give some specific examples of how you would set up Rhino for a Mac user new to Rhino?

Click the three horizontal lines icon in the very lower left corner.


#3

Here’s a Mac specific difference worth considering: WYSIWYG line functionality.

Which I would also add to v6 WinRhino. There really is no substitute for working on a drawing while seeing the actual result. Could easily toggle the display to single line thickness mode with assigned widths. [Useful for all those still apparently using pen plotters. :wink: ]


(Pascal Golay) #4

You can try PrintDisplay- that will show you line width and line types etc - does that help?

-Pascal


#5

Marlin I don’t see no three horizontal lines icon in the very lower left corner, where is it?


#6

Hi Pascal,

PrintDisplay helps… but, respectfully, I believe it falls short of optimal behavior for today’s software environment.

To understand (a number of) my comments on MacRhino’s UX, one must imagine being a new user—lacking all prior knowledge of Rhino conventions which have developed over the past few decades. New users will be coming at MacRhino with experiences shaped by OSX, other applications (OSX and Windows), tablets (of all stripe), and The Cloud.

Understandably, many current Rhino conventions began their life consistent with AutoCAD’s (often clumsy) conventions—that date back to MS DOS days. In saying this, I’m well aware that looking freshly at conventions is very hard to do for experienced users who are thoroughly (ab)used to these conventions. But, given that MacRhino is (likely) aimed at new users, serious reconsideration of a number of these awkward conventions seems worthwhile.

(Admittedly, perhaps some of these comments are “looking ahead” ideas for V6. At the same time, MacRhino seems a perfect beta environment to explore/develop some possibly better conventions, rather than simply be a “twin” of WinRhino V5.)

So, what are the current weaknesses with line weights? Here are a few that may plague a new (Mac)Rhino user:

  1. At the heart of this situation is a fundamental difference between Mac OS and Windows OS interface logics, historically speaking—and that is WYSIWYG behavior. In many ways, transplanting the venerable Windows logic into the Mac environment—without fully embracing WYSIWYG behavior—seems a problematic pursuit. I suggest this for obvious reasons, but add the fact that newer Windows applications, tablets (of all stripe), and cloud solutions all seem to be increasingly committed to WYSWYG behavior.

  2. PrintDisplay does not make intuitive sense. largely because “print” can be interpreted as both a verb and as a noun. Yes, it’s under the View menu, but a new user might easily believe this is simply a way to print out a snapshot of what is on the display. An easy improvement might be renaming this to View Output or View Line Color/Weight?

  3. The PrintDisplay command is buried. Would prefer an easy toggle somewhere that new users could find more easily.

  4. Currently, changing line weights and colors is “doable”, but is inconvenient—and Properties are buried. New users would ideally be more easily presented with Properties. Further, people have become accustomed to having a color, line type, and a line weight option being presented when a tool is selected, before they start drawing, not after. Likely, if one is drawing on the same layer, all operations would be of the same color, type, and weight by default. These options could easily be on the menu bar, or part of the popups. There could also be an option for these settings to be “sticky”, remaining in place until changed (sort of like snaps are currently).

  5. Print Color and Display Color? More confusion for new users and an AutoCAD relic. In only the rarest of situations can I imagine someone wanting a different Display Color than a Print Color, and this would be done most likely by only a Power User.

  6. Color: By Layer, By Display, By Parent, and Custom? I understand the intent, but I’ve seen no end of confusion over this from new users. New users (who have never even heard of pen plotters) simply want to view what is going to be printed. Could these options all still be available? Sure. Just have an “Advanced” drop-down menu.

  7. A better solution might be viewing for 2D that would parallel the different view options currently available for 3D objects. These views could reflect output devices or desired working methods. Something like: Full Color, Grayscale, B/W, Hairline, and who knows what else—including pen plotters! :wink: Heck, I’d even add a toggle for “White Paper”.

Something that might be very educational is to invite in a group of experienced Mac users for an introductory MacRhino workshop (and maybe you’ve done this). Tell them to draw 2D lines, circles, etc, then make changes. Then create solids and make changes—but don’t tell them how. Watch them carefully, let them ask questions and answer them, and record the whole event. I suspect you’ll learn a LOT if this hasn’t already been done.


#7

Hi Marlin,

Apologies for the time it has taken for me to respond - the pleasures & excesses of the Xmas break got in the way slightly… :smile:

Without getting into the specifics of the differences between the Mac & PC user experience, it may be more helpful for me to discuss this in a more generic manner. As I stated in my initial message I really like the general direction of the OS X version of Rhino but because the Wintel version is so refined and customisable some of the design decisions have been a little jarring.

From a personal perspective I like my software to be designed around workflows not the OS and for this reason I prefer the way that the likes of Adobe & Maxon develop a unified UX for both OS platforms (designed around the needs of adaptive, creative workflows). I understand that under the hood the Wintel version of Rhino is very different to the OS X version especially where things like scripting & plugin extensions are concerned (even here the move to Python as the core Rhino scripting platform should help blur the lines) but I think it would be helpful if the level of customisability offered in the Wintel version was also available in the OS X version. Design professionals like to work in idiosyncratic ways and software that is easily customisable to those personal workflows is always preferable.

I strongly disagree with any design decisions that are made on the basis of a specific hardware bias - I’ve read elsewhere that the OS X version of Rhino is designed specifically around the needs of MacBook users. This seems very limiting to me if it’s true. The Wintel version of Rhino can be customised to work with all manner of hardware configurations from 12" laptop’s to 27" touchscreen/Cintiq style interfaces and I don’t see why it should be any different for OS X. Likewise, the touchpad navigation innovations in the OS X version of Rhino should be included with the Wintel version.

All that being said there are many innovations being made with the OS X interface that show great promise such as the wealth of information that’s available via popovers. I’d prefer it if these popovers could be actioned on rollover as well as via click, and it would be preferable if you could ‘tear off’ popovers to keep them on screen if required. But popovers in general are a great innovation for making the best use of screen real estate. The benefits of this optimised screen real estate is just as relevant to any manner of hardware configuration, be it a MacBook Air, a 27" iMac or my 24" Cintiq.

The core of my concerns with the existing Mac UX is its comparative lack of use focused customisation options compared to the Wintel version. I do however understand that the OS X version is still very much a work in progress and look forward to seeing how it develops in the coming months.

jm


(Marlin Prowell) #8

This is only available in single window modeling.


(Marlin Prowell) #9

My thought about this would be to have the PrintDisplay command default to being On. Is there any reason why this should not be the case? I imagine that the PrintDisplay command was added later, and that it defaulted to Off so it would not slow down drawing, but I don’t think that would be a limitation any more.


(Marlin Prowell) #10

You and I already know the answer to this. Rhino does not follow OS X conventions to drawing geometry. On OS X, you draw a line, or a circle, or a rectangle by clicking at the start point, dragging to the end point and releasing the mouse.

For better or worse, Rhino does not follow that convention. Rhino’s way of drawing is wired deep in the program and is not possible to change. Rhino’s way of drawing does open up other drawing possibilities, such as typing coordinates of interior point of a polyline, so this change is not entirely negative.

For teaching, it is a matter of telling OS X users that drawing conventions are different. I personally do not find that a deal-breaker. I also have done what I can to follow other OS X conventions, like right click always means display a context menu, so using Rhino is not entirely a foreign experience.

But expecting Rhino to be completely intuitive to an OS X user who won’t use a manual is an unrealistic expectation. The main reason is not the interface; the main reason is that Rhino is a very powerful tool with many commands and options.


(Marlin Prowell) #11

Adobe has ignored the native UI frameworks provided by OS X and MS Windows and built their own from scratch. Doing that requires at least an order of magnitude of effort more than the entire development staff at McNeel has avaialble. It’s just not practical.


(Marlin Prowell) #12

I believe you are misinterpreting what I said. I said that we need to consider that Rhino is run on laptops along with running on large displays. I said this in response to a particular UI layout suggestion that required so much horizontal screen width that it would not even fit on a laptop display.


#13

Hi Marlin. Achieving “intuitive use” for differing OS users is understandably an elusive goal – and the work done thus far in MacRhino is admirable in many ways.

Testament to this is that students learning Rhino over the past two years greatly preferred MacRhino to WinRhino, despite limited features and the superb Help lookup (manual excerpts) available only in WinRhino.

To be a bit more clear about my “new user testing” suggestion, this is somewhat less about “intuition” than it is about “navigability” or “decipherability”.

The litmus test for any UX might be described as: What methods might an inquisitive new user figure out on their own and what methods might be elusive?

Manuals (which I agree are critical to read – especially for those wishing to become power users) should provide insight into complex operations. However, if simple operations require an undue amount of manual reference the UX is probably worth reflecting on. New users may never discover the power of a program, become easily discouraged and/or seek alternatives.

A resourceful new user (regardless of OS) will easily figure out how to draw in Rhino, despite differing conventions I believe. Will a new user figure out how to: Display line work? Change line colors/weights? Use snaps easily? Of these basic operations, I’m less sure.

Are these sorts of actions worth trying to improve a little? Only McNeel can say. The best we users can offer is our observations.

Personally, I’m tickled by MacRhino’s development and happy that a whole new group of users are able to experience a program that is in many ways unequalled.

~Dave