This is a long post, but I think the importance of the topic and the opportunity for us all to work together to get what we want is worth more depth.
Before I discuss the GUI, I'd like to touch on what I meant by "infrastructure" in other postings: I meant the internal machinery that makes all else possible.
If the internal machinery can handle vectors but has no data structures or ability to handle rasters, then it doesn't matter what GUI or features you want to change things like hue or contrast. First, you have to have the infrastructure to store rasters, to get at them fast, and to compute how to render pixels on screen from what you get. If you have that and the supporting machinery to utilize those capabilities, then you can go on to decide how you want to offer GUI controls to manipulate contrast, hue, etc.
Three years ago the first betas of 9 were lacking infrastructure for some fundamental things. Since then the core internals and supporting machinery have grown to the point where pretty much anything people do in GIS or in related niche areas like remote sensing imagery manipulation can be done.
For example, there is infrastructure for Z coordinates in addition to XY, so all the infrastructure is in there to do things like 3D scene visualization. Anything that people want can now be implemented as features. That's what I meant by infrastructure being pretty much complete.
About that GUI.... let's launch from two observations:
if 9 has a perception problem, or poses barriers to learning, then those things need fixing.
I agree, of course, and
I think the GUI is very tough in the beginning because it relies on ctrl, alt, and shift greatly and is a big departure from other GIS.
...also something to consider carefully. When tuning the GUI to be what we want it to be, going forward it should not lose those parts where it works very well, better than alternatives.
For starters, sure, the GUI is different, as most truly new things are. It is different from other GIS for two reasons: First, because the capabilities are different, and second, because of how the product evolved.
I'll take that second point first. Most classic GIS packages are primarily viewers and display engines at heart. They don't have any DBMS within them, but are designed to display what's linked in from external files. If those external files or sources are a DBMS, well, then the GIS can be a client to that and do some DBMS things by calling on the external source. But they don't really have a way of bringing data into their own, internal world of full-power data storage and data engineering.
That is one reason why most classic GIS packages are full of viewing features such as formatting and presentation but are light on data engineering features. Arc, for example, can't even select on the fly based on, say, an expression computed on geometry. You first have to create a new attribute column, that literally creates for each record the results of the expression you would use for selection, and then you can select on that field. Arc has no clean, effective GUI for data engineering, because it lacks core infrastructure.
Unlike classic GIS packages, 9 was built from a data centric perspective. That was primarily for three reasons: first, because of the feeling that the value of the data is the main reason GIS has big value over things like Illustrator, second, because doing the data side of it is far harder than the viewer / display side of it, and third, because if you want quick response and speed with contemporary data sizes in GIS viewer/display functionality, you can't get that without basing the whole thing on a high-speed, parallel DBMS. There was no choice about that.
As soon as the Radian engine came to life enough to be useful for data engineering, the product was released so the community that could use it could get the benefit of it and, also, help guide it. Guidance from users who were expert at data engineering helped ensure Radian infrastructure was built out to world class levels. Weak spots were eliminated, that otherwise later on would have caused a mess when the thing would be applied in GIS.
Most of those expert voices came from outside classic GIS, understandably so, since most data engineering expertise comes from DBMS and not from classic GIS. It therefore makes sense that early users prioritized capabilities that may puzzle classic GIS users. Collations are a good example. If you don't have the infrastructure for those, you really don't have an ability to do data engineering in a high quality, contemporary way. But I'd bet not one person in 100 doing GIS with Arc even knows what a collation is.
The initial focus on data centric infrastructure and features is not a bad thing, because all else is based on that. Get the data side done right and you get speed, power, flexibility, and accuracy to do whatever else you want throughout data science and GIS.
As all the data centric infrastructure gets done, you can move on to using it for new and better GIS, but now you can do that GIS in a far more useful way. The key is to implement those GIS features in a way that GIS people will find them convenient, evolving into a GUI that provides visual/interactive GIS-style tools in addition to retaining interfaces that can make full use of very rich data engineering capabilities.
That brings me to how the GUI is different because the product is different.
It's important not to surrender to inertia and to just keep doing the same thing over and over because that 30 years ago was the best that could be done. If we did that, everybody still would be thumbing away on Blackberry devices with a zillion buttons, instead of using gestures on smart phones that have no buttons.
Classic GIS like Arc, QGIS, and 8 are "button heavy." If you want to do something, generally you click a button and have at it within a modal dialog that prevents you from doing anything else at the same time. There are no previews and no going back and forth to check something in the middle of, say, a transform session. It's always back and forth to yet another button.
Button heavy interfaces are similar to wizard interfaces, in that they can be easier to teach and to learn for simple things. They are also similar to wizard interfaces in that they usually are slower, more limiting, and way more annoying for intermediate or expert users who want to do more advanced things.
I don't think it is automatically necessary for a high end, modeless, light-on-buttons, interface to be hard to learn for users, or difficult for beginners. A good example is how 9 does navigation.
Navigation, how you pan and zoom to see what you want to see, is probably the most important part of a GUI for visual display packages like GIS, CAD, or graphics editors. It's the first thing you meet. For navigation, 9 is the best I've seen. Left click and drag to pan, and right click and drag to zoom box, plus scroll to zoom, are revolutionary: much faster and easier than how 8 does it.
With 8 if you want to pan the view you have to click a "hand" button and then you can pan. Want to zoom box? Got to click a zoom box button to do that. Most GIS packages are like that. 9 is far easier.
The downside? It's true that the very first time you lwant to pan and zoom in 9 you don't have a "hand" button and a "zoom box" button that you might think "oh, OK,... that'st the button to click." You have to learn about left mouse / right mouse as the path to dramatically faster, more convenient, and more intuitive panning and zooming. That's a microscopic amount to learn, for huge benefits in return, but it can be an obstacle if the package is either presented or approached in the wrong way.
That bring's me to Tim's comment, about perception.
I think the biggest issue with 9 in terms of perception is that many people who first jumped into 9 were 8 users, and few of those 8 users either heard or heeded the advice that 9 is totally different: instead, they just jumped into 9 thinking it must be just like 8, only faster. Pop it open and start punching buttons you expect should be there. As Mike correctly put it, that's a showstopper even in something as simple and so much better in 9 as panning and zooming.
Manifold didn't help by naming the new product "9." Given the numeric name, people expected it to be another version of 8. That possible effect was considered. In fact, at first there was talk of totally new branding. At one point it was thought the product would fork into two products, one for the data world called Radian and another for the GIS world called Polygon (both of which are registered trademarks Manifold owns, initially used as trade names for OEM products).
Launching two different products would have enabled a full commitment to the data side for advancing a product into the DBMS and IT world, and another for a purely GIS world. It also would have nipped in the bud any notion that 9 is just a newer version of 8.
That didn't happen because it was felt wrong to deny GIS people a full-power data engineering product, and wrong to deny DBMS people a full power GIS. The two just naturally go together. So, as GIS features were added there was no fork in the road, just a totally full power product for everyone going forward.
I think the key for perception issues now is a two part plan.
The first part is a new, initial presentation of the product in terms of a learning experience. I think that's best done with a new series of initial "Getting Started" and "Basics" topics, that work together with a new series of short, introductory videos.
The second part is what is going on right now in builds, where much attention to adding useful features and evolving key details to make command use smoother is happening in build after build. A good structure that minimizes clicks for maximum speed and power in interactive commands makes 9 more productive for experts and easier to learn for beginners.
But that will take some commitment from beginners. I think the best example of how a product tuned for regular users can be a spectacularly wonderful product while being famously difficult for beginners to learn is PhotoShop. If you want to be mean, take somebody who knows computers but who doesn't know PhotoShop and sit them in front of it and ask them to draw a straight line. People who don't RTFM can't figure that out. For all that, people who know graphics editors will tell you PhotoShop is still the gold standard. It really is highly effective and delivers wonderful productivity, in the hands of somebody who has learned to use it.
That's true of all the very best applications which do sophisticated, powerful things. They don't trade off power in the hands of regular users for interfaces that may be easier to learn but ultimately slower and more limiting.
I don't think there are that many features left to do to get to "completeness" in feature set: adding a couple of hundred features, with a mix of small things like a split tool, medium features like georegistration, and more advanced features like very elaborate and full featured legending, and you pretty much run out of "must do." In fact, I think most people would be hard pressed to come up with a list of 50 "9 really needs this..." items.
A couple of hundred features isn't a lot considering what's been done to date and the continuing issuance of builds every two weeks. That's something the community in this forum can help make happen.
There is also a continuing balance, with frequent builds an opportunity to tune the balance, between a more data centric approach and a more GIS approach to how a particular command or feature is implemented. Small changes are always easy, and often the path to a very smooth GUI is many small changes and details that work together. The community can help there.
How to Help
1. Keep sending in lists in priority order of Top 5, Top 10 and similar you feel 9 must have.
2. Never hesitate to send in small notes where an existing feature can be improved. This usually requires mastery of what is there today, to get a genuine improvement that doesn't throw away valuable aspects of how it is done today.
3. Send in short summaries of what would be helpful learning materials. For example, an outline of which ten topics you think would be a super "Getting Started" section and an outline of what each of those ten topics would contain. Likewise, what would be the analogous set of ten, five-minute videos?
It really helps to get a guide to a new introduction by documentation and video. Manifold documentation uses many illustrations, so small changes in the GUI can require re-shooting hundreds of illustrations in addition to changes in dozens or even hundreds of topics. I think there are now around 9000 illustrations and about 650 topics, so that's a lot to update for any changes.
I think a steady process of every build making small changes and adding more and more items from "must have" lists will fairly rapidly, in months, not years, bring 9 to a much higher level. Already there are synergistic effects as holes in the GUI are filled and connections for faster workflow are made possible, with each tweak or new addition having geometrically greater effect.
Presentation (initial learning materials) will catch up to that as the GUI settles down, and that will help people get to a quicker, easier start with 9, and with moving on to leveraging 9 to do their work faster and easier than is possible with alternatives.
We can then move on to greatly expanding the 9 feature set, steadily adding GUI features that leverage more and more of what the infrastructure makes possible, to do more and more things that are simply not possible in alternatives. There are many, many ideas for such things.