Perhaps a timeline might also be useful to this discussion…
Rhino 7 was released in November of 2020. That means the first Rhino 8 WIP was available immediately thereafter.
The new UI/Toolbar system was dropped in some time in August of 2022.
So, around 20 months of WIP development, or more than half the WIP’s estimated ~3 year development period had elapsed before the new UI system was introduced.
There were a few threads on some of the toolbar related problems immediately after it was released in August of last year, some searching of the forum will find them. Then not much for quite awhile after. My guess is that the lack of discussion over that period was due to one or more of the following things:
People were using the new default workspace without modifying it.
People who had a V7 customized workspace had imported it into the WIP before the new system dropped in, and thus were not really testing any of the new UI stuff.
The initial problems reported were pretty awful, so most people who were following the reports at the time refrained from testing/posting - while waiting/hoping for the system to get better before diving in. Which it didn’t, really.
(For me it was both 2 and 3)
Now, 8 months have gone by since August 2022. And suddenly the little message about UI freeze in a couple of weeks woke people up (myself included) and got them panicking and out of their ‘Waiting for Godot’ mode.
So, OK, now that we’re all awake… what is the way forward here?
Some more or less uncomfortable facts:
It is highly unlikely that any kind of U-turn is going to be made. The system is here to stay - it probably already was when it was introduced in August 2022, as these kinds of large UI modifications have had a tendency to work that way.
The problems we are seeing are likely exacerbated by the very creditable effort on McNeel’s part to unify the Mac/PC code and interface - which must be a very (and I mean VERY) large nightmare to code.
Those people who are testing and posting now (again, I include myself here) should probably have been far more pro-active and vociferous when the system was dropped in last year and not waited this long. Personally I feel bad about not having kept up my end of the job.
Given the above… we need to concentrate on what can now be reasonably fixed in the development time remaining. We also need to know (from McNeel development) what simply cannot be fixed at this point and why.
I have my list of things that I think (hope) can be reasonably fixed - I will post that later as I am a bit pressed for time right now. I am glad to see that more people are now jumping in, we need as much input from different users/use cases as possible.
I am also hoping the “UI Freeze” is taken to mean that no new major elements will be added to the UI, but that existing elements can still be modified/fixed after that date.
In my case the WIP was way too raw this time around so I didn’t get on it early like I’ve always done since V2. Also the file format was non-compatible which was a huge strategic mistake IMO.
By the time V* seem stable and interesting enough to test, the workspace stuff was already in full clusterfuck-mode. So I just gave up. I still cannot use V8 because this problem continues.
Like I said many times before, we are customers and people trying to get our own work done first, beta testers a very very distant second, blah, blah blah…
I think this is a very good learning experience for McNeel on how NOT to engage with customers again.
Unfortunately there is a fundamental flaw in the process that effectively makes it probable that people will defer action. McNeel have embraced the incremental delivery aspect of agile development which means that functionality is drip-fed to the community in small weekly chunks. However, they haven’t addressed sharing the backlog, the list of all the things that are up for development. So people don’t know what they’ve been given or when they can expect it to be expanded.
Community members are busy with their own jobs and responsibilities. They take a look at, say, UI management tools: the area they are interested in is dysfunctional. It’s so dysfunctional they’d need a couple of days to properly write up the shortcomings. They don’t have that much time. So they put it aside with the hope that some future release will go some way to making it work well enough to comment upon. There’s no schedule so they don’t quickly take another look and then day job concerns put it out of their heads and nothing gets looked at until Mitch sounds the alarum and shames them into action. By which time it becomes apparent that nothing was coming to fix the dysfunctional and it’s too close to release to do anything about it.
Furthermore, people have to ration their time for trying out the WIP. Most people are going to use up their ration trying out the improvements to intersections, fillets, booleans, layer management etc before they start playing with UI customisation.
So don’t beat yourself up Mitch: it is not a problem of your making.
These observations are spot on and point directly at flaws in the Rhino development/release process and its management.
It seems that there is no recourse but a panic-driven rush of job-stopping feature requests before the impending freeze date. Which means that actual concerned users must stop their revenue work and devote considerable effort to the testing that they avoided up until now due to the frustratingly unusable original design. These are the very users who could offer the most usable criticism, but nice guys and gals that they are, they just decided to say nothing in the belief that Rhino developers couldn’t possibly be as out of touch and sloppy as the initial efforts implied and that something reasonably testable would come along eventually. But it didn’t.
On the other hand, there is nothing but hubris to prevent McNeel from re-thinking the freeze date in light of these revelations.
But whats the alternative. McNeel cant be any more transparent than with the WIP process. If users dont have time to test, or dont want to test, there isnt much they could do about it. They cant very well spoonfeed the WIP changelog to users.
Or #4: we intentionally prioritized how Rhino 8 works for everyone before tackling customization again.
I’m not sure that’s the case. It’s a tough problem, and really has more to do with an architectural choice we made to solve other problems (not cross platform). I’m glad you’re both awake and paying attention, and providing feedback. Also know that there are several people inside McNeel that share your views and are advocating actively for them.
Rest assured that this debate is not considered settled internally. When it is settled, I’ll say so.
The trouble is that we were ignoring this problem actively. You could have been louder, but we’d still have ignored it.
And remember, we ship software when it’s ready, not when a date comes. Part of the inspiration for my “UI Freeze Is Imminent” thread was to see which topics floated to the top from you. There’s actually some very good news in the lack of posting about quite a few other topics that are also new in Rhino 8. Nobody is complaining about a lot of other things, which communicates to me that we’re actually getting close to being done for quite a lot of the rest of Rhino.
thanks for listening and taking care of this messy situation. I think you guys should always think about this meme, and what our reaction will be before seriously thinking (or not thinking) about regressions:
Not sure I agree with that. For the bulk of feature adjustments, paper cuts, etc., sure. But for major reworks or totally new major features I think that much more user involvement in the design and specification process could be very useful and would prevent poorly coded “placeholder”, “run it up the flagpole and see if anyone salutes it” initial WIP features that discourage testing and feedback.
For these features it’s unreasonable to expect users to take lengthy exploration trips through the tracking system to learn what is being considered. I think it would be very helpful for project managers to prepare at practical intervals a one or two page summary of the current direction and post it for user comments. Preparing such a document might also keep project manager’s heads pointed straight too. Wouldn’t surprise me if such documents already exist for internal use.
Competitive concerns about a new feature might limit how much detail could be included, but maybe it would make sense to limit the summary document distribution to downloading with the WIP or even to just a select list of trusted expert users and/or biggest complainers about the issues the feature is intended to solve. On the other hand I can think of only a few things in Rhino that were novel enough that the competition really didn’t need to know about them until release.
