Bongo: UI stuff to be fixed

Bongo
1

Some UI stuff that needs to be fixed in Bongo.

First of all, UI is for Users, not for Developers. (UI, not DI)

Developer’s logic is kind of like - “Since this function functions like this, thus you need to feed it with info like so…” . But, developer’s logic is irrelevant in a UI. A user tries to achieve what HE wants and finds useful (an end), not to “feed” the software.

MOST VALUABLE OPINIONS
I still have the valuable opinions of a beginners perspective on Bongo (and Rhino too for that part). Valuable, because I can tell what to fix in order to make the software easier to learn, and so also potentially more popular. Meaning; more sale. But every intuitive attempt to do things in a “natural way” will disappear after I have finally learned to conquer the current silly interface (it’s a battle, namely). So be aware, the things below is only about basics, and if fixed it would most certainly help other new users fix their problems without having to ask things that they should be able to discover on their own, intuitively at that, either by constantly visible UI options (overview), enabled or disabled is key concept here, or or by message dialogs prompting the user to select relevant options, at least such options that are absolutely required for an attempted new command/action/setting to have success.

FIX THIS

  1. Include the “Rotate Pivot” icon in the main Toolbar (0). See fig 1.
  2. Counter intuitive: The missing icon in the main tool bar doesn’t help new users to intuitively discover that the Pivot can be rotated, and users also get no indication of that the Pivot may need to be rotated. nor that such a command exist. That’s serious and leads to an unnecessary steep learning curve.
  3. Illogic: The Bongo Properties icon tools should consist of a subset of the main bar, not entirely different icons.
  4. Context: Since the icon should exist in the main Tool bar (0), it may by some be perceived as misleading if the icon is not disabled when no object is selected (but by being there it will still help users to discover this functionality, via mouse over etc).
  5. Message: If a user tries to rotate the pivot while the option “Rotate in world space” is still checked, the user should be notified about that - of course. In the message box there should be the option to immediately uncheck the option, as a means to fix the conflict (Noteworthy: I have never, no never, seen any other software being so plain stupid and lacking about basic UI things like this as Rhino. Unbelievable, really). How ELSE would a user know that any such option even exist?
  6. "Rotate Pivot" silently fails: When trying to rotate the Pivot while in perspective mode, the Pivot simply and silently refuses to rotate. No explanation, just dead in the water. Again, a clever little message box(!) could educate the user about the fact that someone decided that a direction cannot be set in perspective mode, in a 3D software. Counter intuitive?
  1. Bongo properties: DO NOT put Bongo properties and Rhino properties in the same pane since on often needs to see both at the same time (see also Fig 2.).
  • Flickering & lost: The flickering of the Bongo properties pane which occurs (at best) when selecting a Bongo object is confusing. Sometimes you see Bongo related UI stuff and sometimes not, and when not then you have no idea why Bongo went hiding. It’s like a silly child’s play. I’ve never seen any such confusing UI scheme as this before. Never. It’s actually provocative.
  • Object Name: Include at least the most essential (rhino) object info in the properties dialog (since you may (will often) need to know what exact object (name) you selected and currently are dealing with. For heavens sake.
  • Lacking overview: The Bongo properties dialog pane does not allow seeing related info/settings without scrolling up and down like crazy (and the tools icons scrolls away, which should instead always be visible at top).
  • Wasted UI space: In short: the Bongo prop. pane covers the entire height of a 1900px screen, and consists of more separator lines, group-box lines and other useless dead UI space than essential info. So, get rid of all that crap and show the info instead. Scrap all the extra lines, the wasteful group boxes and use the space for info instead. Info can be grouped without wasting so much space. What all this actually means is, make the dialog useful. Again, this silly waste of screen space - and total lack of understanding of the user’s need for overview - is provocative. Yes, provocative.

Fig 2: Tutorial on how to waste UI space (to the pain of lack of overview and more essential info) :

Bongo - Fix UI 02.png696×770 46.1 KB

Fig 3. Example of how to “ShrinkUISurface” :smiling_imp: Enough context info (underlined) is still there :

.
.

Fix this. Just do it. On Monday, not on Tuesday.

And who am I to say this? Well, I designed a 10+ million dollar ERP system with the explicit requirement that users would also understand the UI Apart from being able to use it while having overview of all relevant info at all times, and without any silly flickering of windows and context all the time. (and no, it’s NOT about sticking only to “Windows standard” etc, it’s about overview and relevant info onscreen, at all times). So, make sure relevant stuff is “at rest” before your eyes at all times.

And I didn’t go to any school to learn how to achieve such an UI, all I needed to know was the need for it. And I didn’t wait until Tuesday when I realized something was not good.

Just do it.

// Rolf

  • I plan to add to this fix list as we go. And BTW, Bongo is fine, only the UI isn’t.
  • Edit: Added § 1.5.
  • Edit: Added Fig 3.
3 Likes
2

The forum is a civilized place for Public Discussion. It is a shared community resource — a place to share skills, knowledge and interests through ongoing conversation.
It’s not the place to ventilate ad hominem personal frustrations (developers are humans after all).

I can personally agree with two of your remarks:
• As I said earlier, there is desperate need of reorganizing the toolbars. Regrouping in a logical order, creating buttons for frequently used commands etc…
• The vastness of info in Bongo’s Properties window, creating a lack of overview, is definitely an issue.

Despite the lack of courtesy in your post the Bongo team will consider your suggestions in due time.

1 Like
3

It is significant info that the UI is in part very, very poorly designed. So bad that it is hard to imagine how it could have slipped out of the lab.

It is also a significant fact that the UI is so bad that it’s provocative.

It is also a fact that I find Bongo very very useful. But again, I really do regret that the UI is hiding the treasures buried under the UI in Bongo.

// Rolf

4

[quote=“Luc, post:2, topic:38191”]
civilized place for Public Discussion. … share skills, knowledge and interests through ongoing conversation.
It’s not the place to ventilate ad hominem personal frustrations (developers are humans after all).[/quote]
I’ve been puzzled several days over this reaction, so I decided that I must give it some time and try to understand where the ad hominems came from, and in which way developers were hurt from my post.

But now that you have decided that my post actually was an ad hominem (not pointing out where that crime was committed) - and told everyone else too - it might not change your attitude. But the fact of the matter is that after several years designing (and also programming) complex systems I learned something about developers and their perspective on User Interfaces, which I essentially tried to summarize in my post (but that was not an attack, it was a description of a “perspective problem” for ALL developers, including myself when in that role).

And below I’m going to state the same thing again, but now trying to explain in more elaborate terms also to you Luc what I was actually saying (but be aware, I have no other way of stating the well known fact) :

WHAT NOT
Developers generally don’t think the SAME WAY as users. Just like an arrow can point forward it can also point backwards. Developers are not stupid people. They make great sofware (including some crap, but that’s not what we’re talking about here). Developers think from the “inside-out-perspective” (because they know how the software functions under the hood, on the “Inside”) while users think the exact opposite way, from the “outside -> in” (what the user wants to do, not how the software were programmed). Compared to users the developers thus often thinks “backwards” (the inside out, instead of outside in). Again, the user’s starting point is an idea of what he wants to do and not how the software functions (which in most cases is irrelevant).

Hence the term “backwards”, which may not have the same meaning in English as in Swedish (which is my native language), but I explained in context in which meaning I used the term. And it was NOT in any derogatory sense. Developers are smart people.

WHY SURPRISED THEN?
Moreover, I thought everyone in the IT industry knew about this problem (developers not having the user’s perspective). I took this knowledge for granted. And given that I thought everyone knew this problem as a fact (well, I still do, but now with a few exceptions), from that perspective I was surprised, and it also seems only strange to me that every time I have (in this forum) pointed out some very odd ways of how the Bongo UI was designed, then you have chimed in and tried to explain HOW THE SOFTWARE WORKS.

  • !

One word - Irrelevant. I have tried to explain to you, at least two times, why some of your comments from that perspective has been entirely irrelevant (see again the “developers perspective”, which truly IS irrelevant)

Exactly that part about how the software functions is the irrelevant part when users, sometimes other users than me as well, say the exact same thing - that some part of the UI is counter intuitive. And not only "counter intuitive, but even “backwards” in the meaning I explained above - someone knowing the software very well from the inside was thinking in the exact opposite way (“backwards”) compared to regular users, and so he/she designs the UI…well, he/she assumes a workflow flowing backwards is the most natural way to approach it.

But it isn’t.

DIDN’T EVERYONE KNOW THIS?
At least all professional developers I know in Scandinavia as well as other professionals I know from all over the world, understands this “developer perspective problem” and considers it a given, and so they consult UI experts to avoid this well known trap.

UI - User Inversed?
No, UI’s are not IK-chains. UI typically involves Forward thinking, not Inverse thinking. Forward, not backward.

So when I tried to explain that developers think about UI’s from a different perspective than users generally do, that is just a well known fact out there, it’s certainly not an “ad hominem”!

DEVELOPERS ARE (PROBABLY) NOT THE PROBLEM
Having said all this, it’s easy (well, easier) to deal with the actual UI-problem - just let someone else take care of the final decisions regarding UI design (that’s also how I dealt with the problem myself as a chief architect for a big logistics system- I let others do what I would not be very good at after designing all the back end stuff).

I find it hard to believe that developers living near Redmond/Seattle wouldn’t know about this “UI-backwards-perspective” problem, which to me means that the information from users regarding problems with the UI gets filtered and stuck before it even reaches the developers.

But selfish as I am I want McNeel to listen to people who actually understands UI:s (there are even exceptions among developers being aware of the dev-perspective trap, and so they can “switch hat” to the user’s perspective and still make good UI:s), which eventuallly will lead to a better product for me (and better sales for McNeel, but never mind)

// Rolf

5

Just FYI @Luc is not a developer, but a user…

6

Yes, I learned this recently, and perhaps that can explain the confusion.

All the best from your brother country,
// Rolf

7

Perhaps this is the source of the confusion?

8

In Sweden we had a CEO for the Scandinavian Airlines, Jan Carlsson, which became famous in management circles for his communication skills. One of his classics was his description of how different people perceive their job differently, and gave an example of two bricklayers being asked about what they were doing at work. One of the bricklayers replied :

  • “Laying bricks.”

Asking the other bricklayer he replied:

  • “Making a castle”.

Not all at McNeel are into making castles.

// Rolf

9

so, members of the group McNeel are not all official McNeel employees? or is it that, some members of the McNeel group are Rhino teachers/instructors but not directly employed by McNeel?

10

UI problems aside, @Luc has been very helpful to me, helping me out with tricky Bongo IK-chain problems, problems which has had more with my own limited capacity to do than Bongo’s ditto. He has also been way more helpful than anyone could expect, of anyone.

Just want to make that thing clear.

// Rolf

11

… don’t all write code is what I am saying (where developer = person typing text for a compiler in the hope bugs get fixed and new features work as intended).

I suppose the problem could be presented like


:slight_smile:

4 Likes
12

I agree.