All that being said, I think that departing from the MS Ribbon style of user interface for 9 is a mistake. If activity level in the forum is even slightly representative of uptake, 9 appears less popular than 8.
? Compare the number of posts referring to 9 and to 8, and the majority are 9.
I think the effect and perception is similar to ESRI's transition from ArcGIS/ArcMap to ArcGIS Pro.
Hands down, Pro is a superior product, and it has outstanding uptake within the ESRI community, excepting a relatively small minority of people who don't want to learn the new UI for ArcGIS Pro (a ribbon interface, I should note...). Those folks are the source of truly bitter complaints in ESRI forums that Pro is unlike prior Arc versions. The replies are always the same: a few people who agree "oh, yeah, it's awful" and then others who reply, "It's way better if you learn it."
That's the case with any genuinely sophisticated and big product: you have to invest some time into learning it to gain facility with it. Well managed organizations know that.
For example, there isn't a jet services company on the planet that is going to let any self-proclaimed "mechanic" near their Gulfstream jets if he or she shows up and says "Oh, I don't read manuals, I just learn it by connecting and disconnecting stuff to see what happens."
I use that example because it's immediately obvious as a matter of common sense that you don't let anybody near your private jet, either to work on it or to fly it, if they don't take the time to learn it before trying to work it. It's the same way in big software products as well, but those involve even more complex knowledge than flying a private jet.
No organization that is well managed is going to let anybody touch their enterprise Oracle or SQL Server installation if he or she announces "I never look at manuals" but intends to try to learn the thing by clicking at menus and trying things. A deep respect for leveraging knowledge passed on by others is one of the things that characterizes an enterprise professional. They start the job by reading the fine manual, checking out videos, and learning the basics.
Given support for new data sources, new functionality and massive performance gains, why is it that 9 doesn't seem to be getting the traction that 8 had?
Oh, it's getting traction, just in sectors you might not be counting. I think that's a natural outgrowth of how 9 was financed as opposed to the GIS constituency that, as is natural and expected, dominates the Release 8 user base.
9 happened because classic GIS technology, single threaded technology, doesn't have the horsepower to handle modern GIS needs. It's that simple: you have to go parallel, and because only about one person in a million can parallelize manually, that means you have to go parallel with the software automatically doing that for you. That's becoming true in many software sectors, not just GIS.
Manifold isn't the first to either realize that or to try it. Both Microsoft and Intel spent over 100 million each at trying and failing to create software in various sectors that could auto-parallelize the way the Radian query engine parallelizes for DBMS and GIS. That's very difficult work that takes years and costs millions.
But it's the heart of what modern GIS is and Manifold succeeded where both Microsoft and Intel failed: if you don't have parallel DBMS you don't have parallel GIS and you don't ever get the performance you need to deal with modern data sizes, both raster and vector, and modern expectations for analytics. Building a fully parallel DBMS comes first.
Besides being the part that has to come first, that's also the hardest, most expensive part. It took Manifold about eight years and many millions of dollars to get Radian to the point where anybody but the military and large OEMs could use it to do basic work, using Radian Studio as the interface wrapper. Lucky for Manifold, it turns out there is a big constituency for such data-centric work, quite a bit of which is not GIS, and much of which is GIS, but at the high level where absolutely everybody reads manuals.
If you look at the early evolution of 9 from Radian Studio onwards, you see the influence of that constituency. It's no surprise that if early adopters were primarily data-centric users, user suggestions would tend to steer the product into more data-oriented infrastructure for the data-centric work they were doing. The result is a huge Venn lobe of capabilities that is very deeply prized by data-centric users. That's not a bad thing for GIS, either, because clearly GIS as an industry and as an activity is getting way more data centric.
As a result there's nothing else like 9 for such work and people who need those capabilities love buying it. For example, it's no accident that every Monday the banner image on the web site is a military theme. The only thing they don't like is Manifold's Covid response of reducing price to $95. That makes it harder to procure a mil-spec version that's basically the same thing, but priced at $9500. :-)
As wonderful as all that is, the point of 9 is to build a new technology GIS, and to build a new technology GIS that everyone can afford, so that's where the product must go. But that has to be done by expanding into more conventional GIS use without losing all the strengths made possible by a new technology core.
The new GIS things that are added must work within the orthogonal framework to multiply what's possible in a network effect of interactions of user interfaces. That not only makes the product more powerful for GIS, it also makes it ultimately much easier to learn and to use, especially to make workflow fluid and fast.
It's only relatively recently that 9 has expanded into more of a GIS focus, with nibbles taken at Style and labeling, and then with introduction of more typical GIS facilities like georeferencing. If you look at how something like the new georegistration facility works, it's a good example of where orthogonality produces an absolutely superior facility compared to how ESRI or Q do georeferencing.
That's where I respectfully differ with this:
but the ribbon style interface is more or less ubiquitous, and locating what you need is usually fairly intuitive from one application to the next.
There's nothing intuitive about a ribbon full of buttons that tells you how those buttons work in complex circumstances. A good example of that is ESRI's transition from Arc-older to ArcGIS Pro.
Pro in many respects is exactly the same thing as Arc-older, just packaged differently. Most of the Spatial Analyst tools and most of the other various capabilities are the same. So, if there's anybody who you would expect to instantly understand that "intuitive" ribbon interface that Pro introduced, it would be the ESRI community, right? After all, they know what all those modules do inside and out.
Yet the actual effect is the opposite: Arc-older users routinely shovel hate onto the Pro ribbon interface for "moving things around." They don't find all the cute ribbon graphics either intuitive or helpful. They think they get in the way of doing stuff quickly, and they routinely complain that all those fat graphics just use up screen real estate. That's actually a fairly common criticism of ribbon interfaces, that making the icons bigger and more artistic doesn't tell you anything about how a complex tool works, but it sure does use up screen real estate.
So... if the ribbon interface isn't "intuitive" for ESRI people who already know how all that complicated stuff works, how is it going to be intuitive for somebody who doesn't know how all that complicated stuff works? Here's an example:
OK, so clicking on the big, colorful Suitability Modeler button will, according to the tooltip, show the suitability modeling panels. Roger that. Does it tell you what Suitability Modeler does? Nope.
I don't disagree that for really trivial things, like the Map tab, a "wizard" interface that basically includes short text phrases can be helpful, especially with tool tips...
But that ends up having lots of duplication and long, very wordy UI interfaces that annoy people who have learned the basics:
That "add data" button doesn't do anything but call up a sub menu with a lot of text that adds zero understanding. So, the "Route Events" menu command is explained by "Add route event layer to the map." Uh, yeah, sure. Lots of words for the same thing, none of which is the slightest different from a File - Add menu list. It's just a lot busier, with more visual text clutter if you have a desktop full of many windows.
The "busyness" of poorly implemented ribbon interfaces is probably their worst attribute when it comes to efficiency. In contrast, a key approach to user interface design for any highly complex system where lots of stuff happens fast that is hard for people to keep in mind is "quiet cockpit" design.
Fighter jets have remarkably simple cockpit displays, mostly all black, despite the huge complexity of managing a complex aircraft along with complex weapons systems engaged with a dozen different targets, all of which are trying to shoot you down in real time with supersonic, smart, missiles. There's no room for "idiot button" text captions floating along like "Radar... This is the button that turns on the radar."
Manifold takes the "quiet cockpit" approach. It doesn't throw clutter at you. Clutter won't help anyway, because if you don't know what a "route event" is, it's not going to help to add a caption to a "Route Events" command that says "Add route event layer to the map." But that sure will annoy people who add add dozens, if not hundreds, of data sources a day in their daily work by presenting them with a very long idiot-buttoned list with captions like that (the illustration only shows a small part of that "add data" menu...).
ESRI, in contrast, is enormously cluttered, and very poorly orthogonally structured.
Consider that "measure" button: it has two different tools to measure distance and area. The same tool should do both, as Manifold does. It has yet a different tool to measure a specific feature. Manifold's approach to that is not to have a separate tool to click, but to have such an important thing a built-in part of the default interface that is always on.
With 9 you get navigation, selection, and picking for information / editing all as part of the default mouse interface with no need to pick special tools: pan and zoom, add ctrl for selection, and add alt for picking, with the info pane automatically showing desired info.
Arc and Q, by the way, don't even have basic panning and zooming without keyboard modifiers: you can pan by clicking and dragging, but you have to Shift-click and drag to do a zoom box. (That also conflicts with the usual way in which the Shift modifier is used in Windows, but then, since when have Arc or Q cared about how Windows does stuff?)
Ah... one last thing: ribbon interfaces tend to be modal interfaces. "Modal" is when you pop open that dialog and it grabs you, not allowing you to do anything else, and locked onto whatever had the focus when you opened it.
Manifold prefers non-modal interfaces where possible, like the panes Manifold provides, because those provide way more efficient, faster, and easier workflow with many different windows open. You can see that by how you can start an editing process in one window, manipulating attributes and coordinates in the info pane, switch to a different window and do something else, and then when you move the focus back to the first window both that window and the pane are exactly where you left it. Same with complex sequences of transforms and selects. Can't do any of that in modal interfaces like the ESRI ribbon interface or the even more primitive, even more modal "blackberry button" interface of Q.
Anyway, all the above is just an essay on why ribbons aren't really intuitive, and why certain aspects of ribbons that are not done well, like their bloatware approach to using space, the distraction factor of lots of text clutter, and "everything you do is a separate, unique, modal tool" lack of orthogonality don't make them as high a performance user interface as using a quiet cockpit approach that focuses on orthogonality.
I think is the solution to your interest is adding more and more conventional GIS functionality to 9, like the new GIS features Manifold has switched gears into providing for 9. That will make it a lot easier for you to present 9 for conventional GIS approaches.
But ultimately, learning a better way of doing things requires an investment into learning better ways of doing things. Manifold is not stressed about that, because more and more people are investing that time since they don't really have a choice: the data sizes they're working with simply do not allow them to use ESRI or Q.
ESRI and the Q community can mess around with gluing trinkets and modal dialogs onto an old-fashioned core for the rest of their lives and still end up with packages that are too slow to use as data sizes increase. That tends to drive a sufficient number of people (sufficient number to finance further development, that is) into learning 9, and then they learn how a significantly faster and more efficient workflow pays all sorts of dividends even with much smaller data that could be handled with no issues in Arc or Q.
Manifold's strategy is not to stress about that, but to steadily add GIS enhancements while retaining a much more efficient user interface aimed at regular users. As you get more and more GIS conveniences that are indisputably way easier in Manifold, like georeferencing, you'll have more and more people who will invest the time to see that the new user interface is much better to use for everything else as well if you're doing a lot of GIS.
At the end of the day, Manifold will have a package that does everything you want in GIS, and also does it with profoundly more efficient workflow and with modern data sizes that totally crush anything else.
That's going to be a very necessary option for everyone to have, because just digging out of the data size hole is something that neither ESRI nor Q will be able to do without investing about ten years into internal upgrades from 1980's technology. And then after that they'll still have the long haul to modernize user interfaces from endless button clutter and modal interfaces to fast, non-modal, quiet cockpit interfaces that work so much better in daily, production use.
I'd like to close with three short notes to avoid any misunderstandings:
First, nothing about comparing and contrasting different approaches is intended as any disrespect to other GIS packages. They're all created by competent and expert people, just with different constraints upon what they can do.
Second, there's nothing but enthusiasm at Manifold for improvements to better meet the needs of users, such as adding numerous GIS facilities, conveniences and alterations to what's there. Some can happen virtually instantly, (like a new name for the Tracker tool in the next build), while others may take longer (especially those things very few have requested), but suggestions are always welcome.
Third, the focus on providing a great tool for people who use it the most does not need to conflict with broad use by people who are not experts. Every time technology jumps forward to a new level there is always inertia from old ways. Just look at how bitter so many Blackberry users were when big arrays of buttons disappeared from smart phones. But once people got used to the idea, even beginners don't expect phones to come with keyboards full of buttons.
It's the same with GIS. People rise to the occasion and even beginners appreciate faster and easier workflow, even if it requires in the very beginning a bit more thought. There will always be folks who say, no, that without painfully feeble, take by the hand, wizard interfaces that total beginners cannot get started, and that certainly is true for some constituencies. But that tends not to be the case with activities that require some smarts to begin with, like programming, GIS, and significant graphics arts.
There is a basic level of know-how needed to do GIS at all, and that basic level is way beyond the relatively minimal level of learning needed to feel comfortable with efficient user interfaces. The more complex user interfaces of classic GIS, like ponderously complicated and limited Arc-interfaces for actually getting work done, or the many complexities of dealing with a labyrinth of many different packages and user interfaces in Q, not to mention having to resort to Python scripting so often, are way harder for beginners.