Subscribe to this thread
Home - General / All posts - This program will never make it
beav7004 post(s)
#19-Mar-21 19:59

This is a horrible interface. You guys will never make it with this V9. I was power Manifold v8 user. Wrote hundreds of Sql, could do anything in it.

Anyone who will try the viewer will give up withing minutes. It's not intuitive AT ALL. I never look at manuals. I learned Manifold V8, ArcGis, QGis and Global Mapper just by clicking on menus and icons and trying things. With version 9, there is nothing there to click on. Nothing.

I guarantee you that 95% of people who will try the viewer will think this is nothing more then just a viewer because everything is hidden. I like my 50 icons and 20 menus and sub menus on Gis software. It shows the capabilities and power of the software.

You guys will fail with this thing. The only reason I stuck around and keep trying is because I used v8 for 6 years. Most others will not. And you can tell by amount of Youtube views you have.

Look at any best selling software out there, Photoshop, Illustaror, any CAD, any accounting, any video editing. Pick top 100 best selling programs, all have menus and icons but you hide everything and only have options if you click on something in proper order with CTRL or ALT. Total fail. I'm done. Never been this pissed of trying software before.

tjhb

9,700 post(s)
#19-Mar-21 20:10

I never look at manuals. I learned Manifold V8, ArcGis, QGis and Global Mapper just by clicking on menus and icons and trying things.

Poorly, then.

I was power Manifold v8 user.

No, you weren't. You short-changed yourself with 8, and are doing it again with 9.

But you are probably right that screen clutter or "bling" can help casual or uncommitted users. Manifold is not primarily aimed at that segment, I would agree.

beav7004 post(s)
#19-Mar-21 21:41

Yes, I was a power user. I had hundreds of posts on this board helping people and many helped me, mainly with SQLs. I can't remember my login or email I used. It's been 9-10 years.

You guys are short-changing yourself. You have a powerful software that most users will never try long enough because as soon as they load it, there is nothing there.

You have no presence in educational establishments or GIS community. The only hope is to grab market share from ArcGis or others by having powerful GIS at fraction of the price. Then when it becomes well known, you can commend proper price. It wont happen with this interface no matter how fast it can crunch data. Period. V8 was well known in 2010. Not many folks used it but everyone knew about it and those that used it loved it and recommended to others including me. Now you got version 9 and people like me coming back find it the strangest software ever. It might as well be commend prompt driven.

Anyone who loads it, will uninstall it within minutes because it looks like just a viewer. Just 5 second quick scan of the menus shows no tools available and you the developers don't see that. You are sitting deep in it and don't even realize just how awkward it is to use your software for outsider coming from Arc or Q. Even old v8 users will find it lacking. Big mistake.

sknox59 post(s)
#19-Mar-21 22:12

Was your username Ny-Mapper by any chance? Just searched for your current username and that came up.

I think you need to persevere a bit - it's actually refreshing to have a GUI that doesn't flash 100 icons and menus in your face as soon as you start it, although I agree some things take a bit of getting used to.

But reread the manual, I think you'll find it a useful read. It's not like you can pick up any GIS and just start using it like a pro (kudos to QGIS though, I think it is reasonably intuitive).

tjhb

9,700 post(s)
#20-Mar-21 00:05

Oh I remember ny-mapper! Cool.

But obviously not as open-minded now.

I think it will happen to me within a few years.

53 now, but I am moving to a house that I think will prune a few years off my age. Less curmudgeonly I promise.

I'll show you all (OT) as soon as I am permanently settled.

tjhb

9,700 post(s)
#20-Mar-21 00:08

And yes, I am saying: we all have lives, and life happens, and we should understand this and preferably forgive each other.

It's online, but quite a durable community.

Which is great.

mikedufty

869 post(s)
#20-Mar-21 07:31

How did you work out the ctrl-alt click to edit in M8 without reading the manual?

I have the same issues with 9, but not sure if its worse than 8 or I'm just not used to it.

I installed a trial version of mapinfo once and spent a couple of hours unable to work out how to do anything at all, I rate M9 more user friendly than that, but its not saying much.

Sloots

512 post(s)
#20-Mar-21 08:23

In the past I used to work with MapInfo. One day I switched to Manifold. A couple of years later I tried to create a simple one layer map with MapInfo. Could not figure out how to do it without consulting Google!

I really love the way M9 works.


http://www.mppng.nl/manifold/pointlabeler

KlausDE

6,391 post(s)
#20-Mar-21 08:42

Although I find myself scratching my head how I did things in M8 now that I'm used to M9 I think that @beav700 has a point in that the viewer is poorly advertising to buy the full version, because you don't stumble over show stoppers every minute that the full version would solve. The options are just not available.

However I like the viewer the way it is. In a team it's an interesting tool for those that work with results only and who would hate advertisment in the daily work.


Politics is the art of making the impossible unavoidable

Mike Pelletier


1,864 post(s)
#20-Mar-21 15:23

I agree that way M9 works is great. The tight cockpit UI allows working on smallish laptop.

A series of super fast moving videos easily found along with the context help is really all that is needed to get people past the initial stumbling points.

Of course there are still many holes in the program and areas that need improving.

adamw


9,588 post(s)
#20-Mar-21 14:47

Anyone who will try the viewer will give up withing minutes. It's not intuitive AT ALL. I never look at manuals.

What specifically did you try to do which wasn't intuitive (from what you say after, I am guessing the functionality was there, but was hidden too far away)?

We are absolutely willing to make things more discoverable and easier to use.

Thanks for your post.

dchall8
856 post(s)
#21-Mar-21 00:25

Adam, I think his giving a clue with his statement, "I like my 50 icons and 20 menus and sub menus on Gis software. It shows the capabilities and power of the software." He's describing ESRI and similar GIS software as well as Manifold up through 8 to a large extent. Still, I did not find Manifold to be intuitive. It was only after watching Art's videos that I was able to even draw a simple line. But the videos gave so many examples of getting stuff done, that I was productive in a week. Figuring out the other stuff I could do in my spare time.

But then he says, "Look at any best selling software out there, Photoshop, Illustaror, any CAD, any accounting, any video editing. Pick top 100 best selling programs, all have menus and icons but...." I've used those programs and do not find any of them to be intuitive enough for a novice to pick up and do anything with. I had Illustrator within weeks of launch on the Mac back in the 80s. Nothing was intuitive about that. I stopped using it in the 90s and came back to try and use the modern version. I wanted to make text, but dang it was hard.

There may be a subset of folks out here who can become productive by reading the fine manual, but I'm not one. Nor can I intuit the methods by clicking drop down menus and right-clicking icons. I'm a visual learner, so the YouTube channel has been invaluable for me to learn M9. I think the main difference between M8 and M9 so far is M8 had a lot of the transforms built into menus, icons, and the selection dialog in the bottom left border. The transform dialog to the right of that bottom border took care of the rest. Now that M9 has matured a lot, take a look back at M8's drop down menus and ask if those features would be valuable on a menu/icon/dialog in M9? Some no longer make sense. Some are much larger than they could be in M8. And some would be very useful in an easier to access interface.

artlembo


3,176 post(s)
#21-Mar-21 01:39

Dave - that was the primary reason I created those videos. It took me a little while to get used to manifold and I really liked it. But I knew a number of people were quitting after the first five minutes, literally. I thought “what a waste“, people were giving up on it too early. So what I wanted to do was create some videos that could get somebody started so they could realize this was a little bit different way of thinking and a very cool GIS. Little did I know, those videos really took off and I have been doing things like that now for almost 20 years!

Perhaps Dimitri would want to make a video on a “quick start“ tutorial. The tools are certainly there, but it’s a different way of thinking about it and using them. Because it’s so database driven the tools are actually in the database table themselves, bolted to the columns (like the transforms).

Unfortunately, I am too busy to take on something like this and my video workshops are stacked up like planes outside of a New York City airport. I have about three or four projects I am planning to get done and that will keep me busy for a while. Also, I haven’t really met any manifold 9 users out in the wild so I can’t really judge what the reach is. When we had those use a group meetings that was a great way to put faces to names and get a sense of how the product was being used in different organizations.

tjhb

9,700 post(s)
#21-Mar-21 01:51

I would suggest that if a quick-start video is made, it is made by someone well under 30.

That would solve a lot I think.

It’s great to have videos, provided for people who don’t thrive on a wordy manual.

But ideally, the videos should not be made by people who do thrive on a wordy manual.

Better made by a member of the target audience?

artlembo


3,176 post(s)
#21-Mar-21 03:44

I agree. And, as you know, some people are visual learners, some are auditory learners, so if an auditory learner is going to quit on 9 in 5 minutes, being able to watch a 30 minute video might keep them around.

I could likely put together a 40 minute video one of these days that gets people over the hump. Just have to find some time.

tjhb

9,700 post(s)
#21-Mar-21 04:25

I agree with everything you say there Art, except that you agree with me!

Unless I am much mistaken, you are not under 30, no more than I am.

That is my main point.

The next generation needs to make its own documentation (video or text).

If that happens, there is no doubt that it will throw up important design issues (which you or I might not agree with). Manifold will listen I’m sure.

If the documentation is only made by men over 40 or 50, for men about the same age, then...

artlembo


3,176 post(s)
#21-Mar-21 16:20

As an old guy over 50, I made two mistakes, since I wasn’t wearing my glasses, and was typing on my phone:

  1. I thought you meant the video should be under 30, as in minutes
  2. I said I would make a video under 30 minutes, but my fat thumbs and old eyes typed in 40

I guess that sort of proves the point.

Nonetheless, if people want me to put together something, I’ll do it when I get some time.

tjhb

9,700 post(s)
#21-Mar-21 22:09

Don't take my suggestion that a quick-start guide should be authored by someone strictly under 30 too seriously (or literally).

I don't know anything about marketing--Dimitri does.

But I do think it's a good question to raise.

Whenever I work with someone (say) 20 years younger than me, I am acutely aware that they learn and enquire in a completely different way than I do. I like cogent, succinct definitions, and concept diagrams, supported by examples. Go one or two generations forward and... a blank look. And I don't really know how to adapt.

Thus the suggestion that someone in the next generation of users might explain things better for Manifold's future (since they are it) than long-term users can.

dchall8
856 post(s)
#24-Mar-21 21:40

Here is a link to the University of Toronto at Mississaga (UTM) library of GIS video tutorials. Most are in English and some are in French/Canadian. They are ESRI based, of course, with some excursions into Google Earth. Most are under 2 minutes long. They cover the basics, but they do offer a few more techno tasks. If someone were to create a video library for Manifold, beyond what is already started at the Manifold Sales channel on YouTube, the UTM library might lend some ideas as to planning the topics to be covered.

M9 documentation is more of a periodical than a bible with new editions coming out every few weeks. As we have seen with M9 development, what used to be the best practices 12 months ago have been literally rewritten during development. A quick start guide filmed in March 2020 would not include a lot of great stuff. Furthermore there are often other ways to get similar results. I might call these less-than-best practices, but these might spark a creative way to do something else previously overlooked.

Should there be multiple quick start guides? Maybe there's another name for it, but getting started with LiDAR clouds is different from getting started with georegistration is different from getting started with watershed analysis, etc. I suppose there needs to be the very basic quick start showing installation and how to update any important Microsoft libraries or drivers. That might be its own, short, QS video. But for someone under 30, this part might not get many views.

geozap
169 post(s)
#21-Mar-21 06:33

Maybe a introductory 2-5 minutes video or a 10-15 slides presentation when one starts the program for the first time could be used to help those that want just to get a look on the software and "protect" them from being frustrated as beav700 describes. Maybe such a presentation could catch attention and show them that manifold worths having a closer look at.

Anyway, Manifold is a professional software (people use it in their jobs to make a living, not just for fun) and people (teachers, students, employers, employees) should be prepared to spend time to learn it, as an investment.

HMS
145 post(s)
#21-Mar-21 16:56

One of the most common issues I faced throughout the multiple times when I introduced Manifold to a potential user was not so much Manifold in itself, as the extreme dependency of other softwares procedures (buttons and extensions likes the ones provided by ESRI and to a similar extent, replicated by Q), that got people searching for an extension or a button to implement a given analysis instead of trying to understand the underlying GIS methodology to get the job done (regardless of the GIS software). There are multiple facts that can justify this, and for my experience, schools and even states rely way too much on ESRI procedures for GIS analysis when they should invest in providing tools for understanding basic GIS methodologies instead of being dependent to the default analysis made available by a given software.

As stated by geozap, Manifold is a professional software, and if someone aims to use it as a daily tool in their professional activity, the time to understand the software should be indeed considered as an investment and not as a waste of time. On a side note, after aproximately 1 year of undergoing a full transition from M8 to M9 I'm still climbing the learning curve, but it's always rewarding when you discover a better and faster way of doing things. So far, the fine manual, the videos and the help provided by users of this forum have worked great for me.

It's possible that a wrong assumption behind the first post is that Manifold 9 should be approached as a continuation of Manifold 8 and all the features available in M8 are already present in M9, when that's not the case (I know I made that mistake the first times I opened M9). Maybe that should be made even more clear when presenting Manifold 9 capabilities.

antoniocarlos

582 post(s)
#21-Mar-21 19:08

Hi (over 50 as well)

I think Adam asked a perfectly reasonable and civilized question. What exactly is the problem with the interphase? Is the Alt/Shift/Cntr combination of clicks not intuitive? It isn't to me, but I continue to use M8 and M9 in parallel with 0 complaints from clients. Is this something that the Manifold development team is willing to change? Aparently the answer is yes. The only way to help them change the interphase (if this is desired) is to complain about it and make recommendations.

A secondary aspect (from this thread) has to do with how Manifold presents itself to the world (via their website) to help us share our love for it. Not sure if Manifold will devote any effort towards this . It never has.

BTW I think Manifold has "made it" it's been around longer that Facebook or Google :-) Plus they sell their procuct for $95 bucks.

My recommendations

1. Organize the videos in the shape of a tutorial (maybe some of them) and given the changes to the interphase make sure these are kept up to date. Not saying they aren't btw.

2. Add an internal search function to the online manual (the google site search is usefull but clumsy to me)

3. Add a button to the first page of the Manifold website to this address (Read Me 1st) (http://www.manifold.net/doc/mfd9/index.htm)

It is not a long read even for those under 30. :-)

Cheers


How soon?

Kurt24 post(s)
#21-Mar-21 19:34

Hey, I am over 70 and use M9 every day and really enjoy its interface and functionality! I have been using Manifold for approx 20 years and writing code for 50+ years. I really enjoy the challenges coding presents to my brain, keeps me perky (especially after surviving the late 60's in San Francisco.)

The designers of M9 were thinking of Professional users, not hacks.

Even at my age I still have many active customers that need my expertise. I still know how to look things up for the other 80% of code I don't use frequently. As you may notice I have not used the forum many times. I have changed my user name several times over the decades.

Thank you Adam, Tjhb and the many others for such great software and teaching me the importance of RTFM! However, more examples would help us old geezers lot. Time for my nap.

adamw


9,588 post(s)
#22-Mar-21 15:28

Dimitri made a good detailed post on why we do what we do with UI, but I'll offer one more short note to try and explain it from a slightly different angle.

The whole reason we moved away from tons of toolbars and hundreds of menu items when going from 8 to 9 was because with the *additions* of tons of new things, the number of toolbar buttons and menu items were growing into the stratosphere. It happened pretty much immediately in the life of 9, the very first alpha builds we were showing around were already after that. Before these first builds we used to have commands *added* to the menus and options *added* to the dialogs, and this was way, way, way, way too much even early on.

The rework of the UI to hide everything that cannot be used right this moment, to move things away from the menus into lists of choices in panes and dialogs, to get rid of all options that could be set to something smart and automatic, and the rework of the system to do everything via SQL, to limit the object model to the bare bones required to reach SQL, to treat everything as tables with records, etc, etc, etc, - all these things were coming from the immense numbers of additions that we were making back then and have continued to make through all these years to this very moment. If we didn't rework the UI, we'd be drowning in commands. If we didn't rework things like scripting, we'd be drowning in complexity, both internal and exposed to the user.

Did you see that menu in wont-say-what-product that is adding layers from different data sources? It has a command for adding data from a vector file, another command for adding data from a raster file, another command for adding data from a database with a table of vectors, another command for adding data from a web server that is serving rasters, and so on. The whole menu for adding a new layer. We have all this menu in our New Data Source dialog. And the menu items we have are for favorite data sources. Because that's what you are using frequently. Do you honestly want to say that the UI which expands the dialog into a menu is better? Even if in this particular case added discoverability might be worth it (we don't think it is, but let's say we are wrong), it's clear we cannot expand things to menus and toolbar buttons in all such cases, that's just way too much.

Now, I agree completely that our UI tools are frequently erring on the side of being technologically orthogonal so to speak, at the cost of being friendly to a new user. We are changing that. We redesigned a number of big things already, the panes first and foremost. We design new UI-heavy features with the new user in mind. Take a look at the registration that we added recently - is it really all that unintuitive for a new user? Compare it to how the registration is done in other products - is our UI really more complex than there? If it is, tell us and we'll rewrite it. We are preparing changes to some of the fundamentals, too. For example, we have big plans for how data sources are represented and handled throughout the system, all simplifications and improvements (from the point of view of the user, not the code). There have been a lot of good feedback on table window and map window, we are going to act on it as well (already started with editing tools).

We welcome any advice into, say, which *specific* things are too far from the surface and should be brought closer to it. Or on what should be done differently, including completely differently. "Make this more like M8" is too unspecific. We'd love to fulfill that wish, it's just unclear how to do this, because if the advice is taken at face value, everything explodes into multiple screens worth of menu items on every corner.

(Heh, wanted to make a short note. Sorry. :-) )

JPMapas
45 post(s)
#21-Mar-21 20:23

Hello Beav700,

I agree with you in almost everything.

I start working with Manifold System, in the version 6.5. After I have migrate to the version 8.x, and this version has an amazing interface. It is very balanced, because it is easy to assimilate by ordinary users, and it is also very good for advanced users and programmers.

At the end of last year, I bought version 9, and I am very disappointed with its interface! Why? Because I don't consider it friendly for ordinary users, like me. The version 9, has an interface designed only for advanced users and mainly for programmers.

I recognize that with the built .173 there has been made an effort to make the interface more user friendly, but it is not enough ...

I have version 9, but I continue to work on version 8, because it is much easier to use....

KlausDE

6,391 post(s)
#21-Mar-21 21:35

Actually there is not much in M9 at this point for programmers but the documentation of the API. I guess your speaking of SQL and I guess we all agree that M9 is not finished in bringing the power of SQL into Transforms. But of course you first implement the functionality (available as SQL commands) and then you can put a GUI on top.

There is one basic GIS concept that perhaps needs to be stressed and that is: Everything is data and data live in Tables. Once you have ingested this M9 is more straight forward then M8. Most other GIS interfaces try to hide this and leave users with a limited idea of what they are doing.


Politics is the art of making the impossible unavoidable

tjhb

9,700 post(s)
#21-Mar-21 21:46

Good point Klaus.

Perhaps one reason Manifold 9 can seem so unfamiliar at first--and ironically, daunting--is that it has simplified everything so much (in exactly the way that you say). People look for familiar complexity and complications, and are perhaps disconcerted not to find them. (I want these unnecessary complications at my fingertips, dammit!)

With 9, the data model is entirely flat, the object model is flat, and analysis has exactly two uniform layers: SQL, and transforms built on SQL. (There are literally only one or two GUI functions that break that rule.)

There is a universal scripting interface as well, but it has almost no content of its own--it is there to support the same SQL used everywhere.

In all of those respects, the simplicity of 9 is revolutionary.

And at first, completely unexpected.

ranger.sean97 post(s)
#22-Mar-21 00:08

The original post struck a bit of a chord with me.

I’ll start by saying that I understand M9 is not intended to be an exact replacement for M8, and once you wrap your mind around how things are done it does get easier. Also, that I’m aware development is ongoing and some features haven’t been implemented or completed at this time. Finally, there is no substitute for reading the manual.

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.

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?

I suspect it is because of the learning curve that 9 imposes for new users when compared with 8 and applications like ArcGIS etc.Sure, the impressive performance of 9 may be a valid reason to stay the course, 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.

While the objective for 9 hasn't been to develop something that looks like other GIS applications, why place obstacles in the way of people who might otherwise purchase the product?

Case in point, the company I work for needs to increase its GIS capacity.As a Manifold userI find myself having to recommend software appropriate for the needs of the company, at a price point it can afford.

While I have worked more or less exclusively in M8 for the past few years, new hires are more likely to have used ArcGIS than any other GIS application.

As a long time Manifold user (c.15 years) I’m slowly getting to grips with M9, but frankly I can’t recommend it to management at the present time.Likewise, while 8 remains a solid performer, it is getting long in the tooth and doesn’t support a number of the data sources that we need to use.

Instead (and much to my regret), I’m leaning toward Global Mapper which seems to offer the best balance of features, usability and price point in relation to our needs.

It’s not comparing apples with apples, but I can train someone with ArcGIS experience to use Global Mapper in a shorter time than I could to use 9.

Dimitri


6,560 post(s)
#22-Mar-21 07:12

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.

Attachments:
arcgispro_ribbon.png
arcgispro_ribbon2.png
arcgispro_ribbon3.png

JPMapas
45 post(s)
#22-Mar-21 15:19

Hello,

I never used any ESRI software. I have start with the Intergraph (more or less, at 30 years ago), then I migrated to the MapInfo Pro, and then to the Manifold System GIS.

When I bought the Manifold Release 9, I expected an evolution of the M8 interface. I did not expect a complete revolution of the software interface where all the commands were hidden and where it is necessary to relearn everything!!

The most serious thing is that relearning for relearning, I have been learning QGIS because its interface is much more user friendly! And even more serious, at QGIS, I can build thematic cartography, such as proportional circles or proportional sectograms, something I can't build on the MR9!!!

I love the 8 but with the 9 I see myself giving opportunity to others GIS programs!!!Regards

adamw


9,588 post(s)
#22-Mar-21 15:45

And even more serious, at QGIS, I can build thematic cartography, such as proportional circles or proportional sectograms, something I can't build on the MR9!!!

Thanks, this is useful. Agree this is a great feature to have. We are planning to add it.

antoniocarlos

582 post(s)
#22-Mar-21 19:31

Hi

You know what I find wierd with the interfase. It is not that it is unintuitive. It is that I allows very little space for discovery (to figure out things) within drawings, images or maps (with the default tool). Opening a drawing shows the drawing but right clicking on the drawing, or the map, or the image does nothing. If I were a 1st time user this is what I would do. I guess what I mean is that there is little space to play (in the best sense of the word) with the UI. One idea (probably a bad one) is to allow right click to activate a particular pane.

Also, looking at the excelent instructional videos I find myself paying attention to how Dimitri manualy organizes the desktop to perform a particular operation. This is fine, but is there not a better (automatic) way to ask M9 to do that for me? Even with 20 undocked windows this should be possible to to. How about right click organize as cascade.

Thats it for now.


How soon?

Dimitri


6,560 post(s)
#23-Mar-21 07:29

If I were a 1st time user this is what I would do.

Perhaps, but then wouldn't it be a better idea to watch the introductory video?

If you don't mind a bit of good natured humor (this is intended as a good natured joke between respected colleagues) that brings to mind the famous Gary Larson cartoon:

Why try "pushing" when a moment to read "Pull" makes it effortless?

It takes but a few minutes to watch the Navigation and User Interface tutorial video, the second sentence in the Read Me First topic:

----

See the Installations topic for instructions on installing and activating Manifold.

Watch tutorial videos for a fast start:

  1. Manifold Tutorial 1 - Navigation and User Interface

----

There's a huge gulf in learning efficiency between people who will not invest small effort to learn a sophisticated new product, and those who will. That's unfortunate, because it results in missed opportunities to work more effectively and instead causes totally unnecessary frustration.

The gateway to some of the most wonderful things in life is a bit of learning. My favorite example is how easy it is to learn to fly a small aircraft. Remarkably, with a mere eight hours of dual instruction and perhaps ten hours of class time (reading), you can actually fly solo in a small Cessna or similar aircraft, free as a bird. But if you are not willing to invest time into learning, you'll never fly.

The gateway to sophisticated tools like Manifold is far more accessible. It's watching a five or ten minute video, and then two or three hours of attentive learning. That's not a lot, but if you don't invest that time, you'll not get access to the nearly infinite power of the thing.

manualy organizes the desktop to perform a particular operation

That's an example of the limitations of other GIS packages as well as an example of the limitations of videos.

About videos: When showing something that's a "big canvas" activity, you can't really capture all of it looking through the keyhole of a tiny YouTube video screen.

One of the tremendous advantages of 9, and a big disadvantage of other GIS packages, is how Manifold can undock and work with multiple windows at once, and also how what is forced to be a single project in Q or Arc, basically only one map that is one collection of layers, can be many maps in Manifold.

For example, where's the "Windows" menu command in Q? There isn't one. There's a View - New Map View, but that's just an undocked view of the same, single map it allows you. You can't even style it differently or show different layers in it. That's incredibly primitive, a really awful user interface.

With Manifold, in contrast, you can spread out over three monitors' worth of screen real estate, with not only multiple, different maps, but mixing and matching their contents. Use the same layers in a different map that can be styled completely differently, with different layers, etc. Or, if you want, pop open another view into the same thing that's synchronized. That provides immense flexibility for copying/pasting data between different contexts, discovering relationships, creating new visualizations, and so on. But you don't get that with either Arc or Q. Hmmm... that would make a great video... :-)

But showing how to use many undocked windows spread out over two or three monitors isn't really possible in a tiny video because there isn't enough room in the small video window.

This morning, for example, for a different post, I wanted to create these illustrations. Those show contours for Mt. Taranaki in New Zealand. Well, my problem was that I had a DEM for NZ from long ago that is not georegistered. I could have done contours from that, but I wanted the contours to appear above a Google layer so you could see the transparency effect.

OK, so I quickly georeferenced the NZ DEM that I had. Took about three minutes, because I could pop open the NZ DEM raster in a big window, and a Google map in a second big window, and then quickly pop back and forth between them to mark control points. If you have the real estate of two or three monitors (I use three) that's wonderfully easy and fast. Three minutes later, I had a georeferenced DEM and thirty seconds later I had contours, and then a minute after that I had styled the transparency effect.

A key part of the effortlessness of doing that was having plenty of elbow room using three monitors, so I could work in big windows where clicking control points was especially easy with just a zoom or two. There's no way to show that in a small video screen that shows only one fourth the space of a single monitor.

There's also no way you could do all that so conveniently and effortlessly in either Arc or Q that you'd just do it in five minutes for a quick post in a thread, just because you wanted New Zealand illustrations to honor the homeland of a friend. But a lot of discovery and quality work in GIS is like that, where if you can do it fast and easily you get higher quality work. The ability to work with many undocked windows and many maps, not just one fixed set of layers, and to use screen real estate over two or three monitors effectively, is one of those many UI advantages Manifold has over Arc and Q and other packages with more primitive user interfaces.

By the way, the reason 9's Window menu doesn't offer "tile" options is that those are mainly aimed at docked windows. You can Ctrl-click a window's caption bar to "tile" up and down, and you can reposition docked panes automatically, but tiling many docked windows into a grid is something of a Windows XP approach. The more modern way is to move undocked windows where they are convenient on your Windows desktop, not trying to scrunch them into a single, docked session.

I suppose if enough people asked for something like that it would be added, but I think using undocked windows in a free form way is something that is much more popular (and effective).

Attachments:
larson_pull.png

adamw


9,588 post(s)
#23-Mar-21 09:05

Opening a drawing shows the drawing but right clicking on the drawing, or the map, or the image does nothing.

Agree we should use context menus in table / map window much more than we do now. This is in the plans.

klausk115 post(s)
#22-Mar-21 19:58

You are so right! It is not only speed and big data. For my daily work it is impossible to create a sophisticated map or map series with M9.

Dimitri


6,560 post(s)
#23-Mar-21 04:43

Nonsense. There are plenty of examples in the gallery page, like this one, in "antique Swiss style", or this one, simpler but highly informative.

Read the manual, and you learn how to do such things.

JPMapas
45 post(s)
#23-Mar-21 11:46

Hello Dimitri,

The huge problem with the M9 is that its interface is no longer intuitive. I have had two images of the interface of the M8 and the M9, with the same file. As you can see, the M8's interface is much more intuitive! For example, if I want to build a thematic map, it is much easier to do it in version 8! It's only click on the commands available on the respective Toolbar. If I want to draw a line, it´s only use the Toolbar commands! In version 9, none of this is available!

Another example its "Select" and "Transform" Tools. This exists in both (8 and 9), but it is much, much easier to use in version 8!

Adapting to version 9 it's not the problem! The problem it's that we don't have time to read thousands of pages in the manual to relearn how to do the same task!

As an example, I work with Manifold in connection with MySQL. MySQL also had a major update when it released version 8. However, its interface with the name WorkBench, kept its appearance and way of working, between the version 5 and version 8.

And why? Because it is a very complex application to make its users have to waste time relearning everything again, about the software. We must only learn who to use the new tools!

Regards

Attachments:
MR8.png
MR9.png

adamw


9,588 post(s)
#23-Mar-21 12:55

If I may.

I understand where you are coming from. With formatting, 8 has buttons in the toolbar, 9 has buttons in the Style pane. With selects and transforms, 8 has buttons in the toolbars, 9 has buttons in the Select and Transform panes. With editing, 8 has buttons in the toolbar, 9 also has a button in the toolbar, but it's only one button with a menu, and many commands are in the context menu in the map window or in the Info pane. With 8 all buttons are immediately seen, but with 9 they are not, you have to click somewhere to see them.

But consider this:

For formatting, 8 only has buttons in the toolbar for vectors. To format rasters, you have to go into the menu. With 9, everything is in the Style pane. For selects and transforms, 8 does not have nearly as many options as 9 does. 8 has very few options for selects and transforms precisely because the toolbars are visible all the time and they have to be compact, 9 allows having many more options because selects and transforms are in panes rather than in toolbars. Many things that are transforms in 9 are other things in 8, eg, copy / paste scenarios. In 9 they are in the Transform pane. What's more discoverable - a copy / paste scenario or something visible in the Transform pane? Of course it's the latter, the former is barely visible, you mostly have to read the documentation to know it exists. For editing, take a look at editing commands that 9 shows in the context menu for the edited object. There are multiple cursor modes, more snap modes than in 8, various commands that 8 didn't have (with the list growing). Imagine putting all this into the toolbars in addition to what 8 already has - that's going to be like 2/3 of a new row even now, just for vector editing. With most of the buttons staying disabled until you start editing an object. Would that really be an improvement of the UI?

What I mean with all this is that there are so many things that they cannot be put onto toolbars. Most have to be hidden. Eg, ribbon interfaces organize things into toolbars which you switch between, you get to see just one toolbar out of multiple and text captions for all other toolbars. Our panes work exactly the same, you get to see one of them and text captions for all others.

Last, the point of the UI of the MySQL tool evolving instead of going through a revolution is the most difficult one to address. 9 changed a lot compared to 8 internally, there are many more things and what stayed changed dramatically. It was completely unclear if an evolution of the UI would even make sense, so we chose to go with a revolution. Now, maybe - it is very hard to say, but it is possible - there was a way to do an evolution rather than a revolution and keep the UI more in line with what 8 had. Maybe we could have done that without it all becoming a cumbersome mess. I am not completely sure as to how that would look -- just as an example, what exactly does it mean for selects and transforms? do these things stay in toolbars? then how do we add options? one more button to show a dialog with options? so we just keep adding these 'More...' buttons and the real thing is actually happening inside those buttons with the toolbars being just for the simplest transforms? doesn't sound very good... -- but who knows, maybe we could have done it somehow.

There are big benefits to the revolution though. Because we didn't have to stay true to the old UI and could start anew, we were able to create something that we think is much more logical and clean. Yes, it's different and has to be re-learned, and perhaps there are some rough corners still. But in the end it's worth it. It packs a lot more and it's a lot more efficient as well. Less clicks. Less quirks. Smarter commands overall. And the rough corners are being worked out.

Tell us what specifically works worse than it could and we will improve it. (Eg, you say that the Select and Transform tools are much easier to use in 8. If this is about the Select and Transform toolbars in 8 always being on the screen and the Select and Transform panes in 9 only being seen as text captions by default, which you have to click to switch to, then we understand. But if it is something else, eg, some options being harder to specify or whatever - let us know and we'll fix it.)

tjhb

9,700 post(s)
#23-Mar-21 14:28

1 Kings 3: 24-28.

sirnoble1 post(s)
#25-Mar-21 13:48

I rarely post, but I felt compelled to add something to this discussion. I'm an older guy, but I have observed how younger people work and learn when comes to software. Simply put, they click buttons and see what happens next. Without buttons to click, they are mostly lost. I'm not agreeing with their approach, but it is the way things seem to be.

A few suggestions:

I would give them a clear button/menu pathway to the primary functions/dialogs and some right-click functionality that is useful. If the necessary components aren't loaded, disable the buttons. Make all buttons highly visible (no text buttons). Use tooltips with links to the manual and video(s). Add a checkbox to turn on/off tooltips. Tooltips are annoying, but a checkbox option would fix that. Add a little glitz to the IU where you can. The initial screen is like a blind date. If it is too plain/empty, they may not hang around long enough to ask about your favorite color.

Disclaimer: I have worked with Manifold 8 but very little in 9.

Dimitri


6,560 post(s)
#25-Mar-21 15:33

I'm not agreeing with their approach, but it is the way things seem to be.

Thanks for posting! Hope to see more posts, as you have a knack for making sense, and for thought-provoking posts in few words.

I both agree and disagree with the observation on how younger people think. This is difficult to discuss in a GUI-design way because it touches on a third rail of politics these days, so let me approach it very gingerly

What you write is true about many younger people in the West, but not about all. And it's not a good match to the approach of technology-oriented young people in Asia (including the Indian subcontinent) or in many other non Western locations. Those folks have a far more effective approach to learning new technology. To venture close to that third rail, some would say that may be one reason why if you visit technology powerhouses like Nvidia, that's why you see near-zero Westerners in the engineering lunchroom.

But despite that effect, there are still plenty of young people in the West who don't expect to have significant concepts spoon fed to them, or to master sophisticated matters with zero effort invested into learning. There are plenty of them out there, and they're not to be underestimated.

Be that as it may, Manifold's task is to create the highest performance, most powerful GIS at the lowest possible cost - and that means of ownership and operation as much as or more so than license fee, key factors when the price of the software is the least cost factor given the high cost of labor.

The problem with button heavy interfaces is that they tend to be very slow and very inefficient interfaces, especially compared to non-modal panes. Lots of buttons might help you get started more quickly with very simple things, but then, like wizard interfaces, they get in the way of people who have moved beyond raw beginner stage.

It's an open question whether a truly sophisticated application can be packaged in a sufficiently spoon-fed, take 'em by the hand manner to get a "click and see what happens next" person launched. Nobody in their right minds suggests that's possible with, say, Oracle. But that also hasn't worked with PhotoShop, Illustrator or any FOSS would-be knockoff, like GIMP. Those applications are all equally famous both for being superb tools in the hands of people who know them, and also for having a vertical learning curve for people with poor RTFM skills.

There's also the economic reality that packaging for "must take me by the hand" users requires as much personnel time, and perhaps more, than creating a sophisticated application in the first place. It's a big task, the sort of thing you can spend a hundred million on and not achieve success.

Could Manifold do more in terms of helping low-RTFM folks get kick started? Sure. But I think the first priority is to build a killer system for those people who are ready to swing the big, sharp sword right now. So long as there are enough of them to continue funding development, Manifold can keep forging better and better swords.

At some future point when it comes time to broaden the user base with simplified versions or easy reader versions, then sure, it would be fun to do more to make Manifold accessible to more people, to think about ways to lower the barrier to entry to sophisticated, fast, fun, and powerful GIS.

ranger.sean97 post(s)
#26-Mar-21 20:54

Could Manifold do more in terms of helping low-RTFM folks get kick started? Sure. But I think the first priority is to build a killer system for those people who are ready to swing the big, sharp sword right now. So long as there are enough of them to continue funding development, Manifold can keep forging better and better swords.

At some future point when it comes time to broaden the user base with simplified versions or easy reader versions, then sure, it would be fun to do more to make Manifold accessible to more people, to think about ways to lower the barrier to entry to sophisticated, fast, fun, and powerful GIS.

Whether or not we agree, the fact is some people don't commit a week to reading the manual from cover to cover before opening a new application.

Yes, some people you term low-RTFM might be younger westerners, but don't you want to sell your software to that market / demographic?

Without losing sight of goals completely, surely broadening your user base would provide more funding to speed development, and improve your bottom line. Even if doing that means slowing the pace of development in other areas.

Leaving aside differences of opinion about the UI and acceptance that development is ongoing, people contributing to this thread have provided some good general feedback about removing barriers for new users.

Among other things, the manual could definitely be improved. Also, get onto adding and improving basic functionality like a scale bar and control over alignment of text in layout elements.

Sure, cartographic output may be less important to your developers and some Manifold users at this time, but many of us spend as much time producing cartographic outputs as we do crunching and manipulating the data behind it.

While the following isn't intended to insult, your responses in some discussions sometimes remind me a bit of King Canute and the tide.

tjhb

9,700 post(s)
#27-Mar-21 01:13
Whether or not we agree, the fact is some people don't commit a week to reading the manual from cover to cover before opening a new application.

That is a fatuous comment. No one, ever, reads the manual from cover to cover.

What is required is to read the “Getting Started” topic and follow the advice.

Anyone, whatever age, who doesn’t do that is a fool who cares barely about the value of their own time and even less about GIS.


So then, is the Getting Started topic currently useful?

In my opinion, having just re-read it: absolutely not.

It is both poorly written and far far far too long.

Also, among other things, there is no introduction to important concepts, or even to the main features of the GUI.

Am I wrong?

Let’s see some time and resources spent here. I would be happy to help.

I’m almost sorry—I had assumed this was better. I hadn’t looked recently.

ranger.sean97 post(s)
#27-Mar-21 23:13

That is a fatuous comment. No one, ever, reads the manual from cover to cover.

My comment was made thinking about a remark of Dimitri's re M9 some time ago, but when I checked back the suggested timeframe for getting to grips with introductory material was only a few days. Fair cop Tim.

dchall8
856 post(s)
#28-Mar-21 00:08

The manual is a work in progress and must follow behind the actual elements of the program. Still the outline of the manual could be built early as long as you know where you're going with it. To my thinking the information contained on the Installation and Activation page is what should go into Getting Started with Manifold topic. It is somewhat wordy, but it gets the program started. After that there might be something like Getting Started with LiDAR or some other more esoteric topics.

Getting started is a topic under Getting Started. The topic is nearly 8,000 words deep. I think the outline is there in the Getting Started section, but perhaps it gets too deep too fast. The outline for the topic is as follows.

  1. Launch Manifold.
  2. Add data.
  3. View data.
  4. Work on that data.
  5. Save the project.

When you finish the save part of the topic, the scroll bar is just over half way down the page. I suspect the rest of the topic is remnants of previous documentation ideas that found a temporary home but never got moved out into a proper home.

It's easy to be picky at this point. I think we need to be patient as we have been with the programmatic content.

tjhb

9,700 post(s)
#28-Mar-21 00:42

Fair enough, I may be being too critical. You may be right that it just has not had recent attention.

But this matters.

I think your summary of the outline is helpful. On one view, that is indeed what needs to be covered.

But I would take it differently. I would cover these topics:

1. What makes Manifold different.

2. Storage and the streaming data model. Native parellelism--CPU and GPGPU (briefly). Threads (extremely briefly). (Worth mentioning both Moore's law and Rotow's law, perhaps.)

3. A diagram of the workspace.

4. Projects, data sources, and nested projects.

5. Tables and the special role of SQL. Transforms and their relation to SQL. A brief note about scripts.

6. How to load native data or create a new datasource. Saving data.

7. Map windows and navigation. A pointer towards the Editing topic.

8. Architecture of the manual, especially a pointer towards Examples and a note about videos.

That is a sketch, and probably not in the right order.

The main point is that I think we need to be told what the programme is, its basic architecture, what makes it so fast and powerful, and what to expect--as well as how to get it running for a first simple task.

Concisely.

The Getting Started topic should among other things tell an ESRI or QGIS (possibly frustrated attempting to handle large data, or to more fully utilise their computing resources and knowledge) why they should care.

tjhb

9,700 post(s)
#28-Mar-21 02:23

At point 5, I would add a brief note about the Join dialog, since it is a main feature--more expert SQL for free-- and a pointer to the Join topic.

drtees108 post(s)
#24-Mar-21 23:48

I share many of the "complaints" that were written in this thread concerning the difficulties of using 9 after using 8 for so many years. My first "introduction" to GIS was in the late 80s - early 90s with GRASS. While I didn't use the program, I saw just how powerful it was as a tool for understanding the effects of forest fires in relation to prescribed burns. My first hands-on experience was with ESRI in the mid 90s. After leaving that job in 1999, I entered my current profession as an ecologist. I knew from my previous position that the combination of GPS and GIS was very useful. However, my employer for the newer position used AutoCAD for making maps and there was no good way to easily get waypoints from a Garmin GPS into CAD format. I researched the various GIS programs available and ran across Manifold. It was Version 4.5 then. I bought it and have introduced it to all my subsequent employers. The all saw the immense benefit that GIS can provide.

I am now dealing with large aerial image files and even larger LiDAR files. No one particular LiDAR file available is likely going to give me a clear understanding of a watershed. High quality aerial images from EarthExplorer seldom cover a project site in just one file. 8 has the ability to merge images, but to have a merged image exactly replicate the resolution of the source files requires me to copy one image or LiDAR file and Paste-Append it to a master image or LiDAR file. It is a very time consuming process.

I had been playing off and on with 9 from its first release. It was fast, but lacked so many editing and layout functions that I continued (and still continue) to use 8 for high quality figures in reports. I know that new functionality is being developed and implemented in 9. A year ago, I watched one of the YouTube videos from Manifold sales showing how to merge images in 9. I tried it and found that it was magnitudes faster than what I was doing in 8. Since then, I have been increasing my studies of the online documentation and the YouTube videos to learn how to do in 9 many of the things I routinely do with 8. At this very moment, I am running a large LiDAR file (Gigabytes in size) through the fill sinks transformation. I am also doing the same thing in 9. * has been crunching away for 2.5 hours now. I have started, stopped, and completed several things in 9, including the Watershed Preview transform at the same time. I know that 9 will complete the task first from experience. 9 has been filling sinks on the same LiDAR data set for the past 45 minutes.

Another great benefit of 9 that I found unnecessarily difficult in 8 is the ability to pull in images from image servers on the web and to directly call data into a map using APIs. The data are stored elsewhere and when it is updated, those updates show up on my map the next time I open it and formatted the way I like to see it.

9 is not a finished nor a polished program. The interface is radically different from 8, but I have been able to adapt. The online manual is a mess (no offense intended) in that searching for a topic on how to do something ends up as a slow crawl through every noted topic that remotely mentions the search term. The videos are the best, by the way! With each new iteration of 9, it gets closer to the point where I will be doing a majority of my work there and not on 8.

This is an evolving product. Best to be patient as it evolves.

Mike Pelletier


1,864 post(s)
#23-Mar-21 15:49

My sympathy is that it can be difficult to tell what in 8 cannot be done in 9 or at least done as easily. This can lead to thinking it is the UI's fault. Especially with stuff that seems to be basic GIS functions. Some obvious things are a scale bar and north arrow and I understand why Mfd doesn't highlighting these things.

I think there are some really nice things in 8 that we could do with selections and tables that are missing and Mfd has said they have improvements in these areas planned. After working on vector editing they said they are planning on working on labels and styling. Great. These are the things that will make map making more fun.

I do think a video whipping through each pane would launch people. I've done this for a client along with a "How to" comment component in the project. Both are a handy quick reference.

Toolbars are not necessarily easier. In either case, the devil is in the details.

The dropdown for editing tools and tracker might be better as a toolbar however since there is room.

Mike Pelletier


1,864 post(s)
#23-Mar-21 16:15

Should have also added that the icons for New, Open, Close, Zoom In, Zoom Out could go away. I'd be happy to do access them from a dropdown. That would make more room for other icons like the editing tools/tracker or whatever is useful based on current operations. Maybe even put the icons at the same level and to the right of the dropdowns (File, Edit, View, etc.), to make more room on small screens.

Dimitri


6,560 post(s)
#24-Mar-21 06:41

I think there are some really nice things in 8 that we could do with selections and tables that are missing and Mfd has said they have improvements in these areas planned

What did you have in mind?

Mike Pelletier


1,864 post(s)
#26-Mar-21 18:03

Pulling out useful data in Mfd is what first attracted me to Mfd many moons ago. It was and still is so much better than others. However, it is more confusing in 9 than 8 and I suspect this might be causing a large part of the grief in this thread. While 9 has more capabilities especially with filtering, it quickly gets confusing.

There's a select pane but filter/order is in a main menu dropdown. Maybe Select pane should be called something like Find, Get, or View and the filter/order tools be put in it. So you first filter/order and then select to do something with it.

Is the table showing all records or fetched? Is the filter/order command applied to the whole table or fetched records? Here's a post that discussed this. http://georeference.org/forum/t138898.107

How many records are selected? How many records are filtered? How many duplicates and unique values in a field (other simple stats)? Here's a post with ideas about it http://www.georeference.org/forum/t149564.13 Now we have a new pane system. Where should the answer to these questions be displayed? Could be on/around the table or in the pane where you do the work rather than switching to the Info pane.

The Select pane is confusing with order of operations, I think it is caused by selecting the field before the operaton. For example, select a number field and then go to the search options. Hey, I see that I can change the operation to work on a different number field. Good. Hmm, now I want to use a text field, but why are they not listed as an option. Click, click, click, getting aggravated. Ah, I have to go back up above the operation level and choose a text field. Okay it makes sense, but how long will I remember this?

FWIW, these issues are lower importance then vector editing and labeling.

adamw


9,588 post(s)
#27-Mar-21 14:38

We'll take care of the fetched records vs all records issue.

Number of selected records / selecting duplicates or uniques will happen as well.

As regards the order of operations in the Select pane and starting with a field - if not with a field, what else to start with? You open a window, you look at fields named POP2010 and POP2020, you think "well, let's see which records increased in population" and then you go into the Select pane - that's what we the process more or less is, is it not? You first see some values *in some field or fields* and start wondering about them. The fields are a natural place to start. No?

I mean we could try starting with operations instead of fields, that'd perhaps be great for discoverability (all operations in one place), but for usability we are skeptical (you'd select an operation that would require some data you don't have and all the choices are disabled, etc). It seems if we start with operations, that would produce exactly the UI nobody wants - logical in a way, but too technical and alien to how people perform in reality to be useful.

It seems to me that if there are some issues with the usability of Select and Transform, they are something else. Maybe going from one template to another is too slow or whatever.

Hear your opinion on editing and labels being more important.

Mike Pelletier


1,864 post(s)
#27-Mar-21 15:52

Starting with the field is good, but it somewhat happens twice. First you select a field, then select Search. It then opens up the operation dialogue with the chosen field shown at the top. However you can change the field to any other field that works with the operation. After awhile you come back to the selection pane and forget the first and then wonder why all fields are not shown.

Instead, why not just go to Search then choose the field from a list of all the fields, then the operation options below changes to match the field type chosen?

What do you think of the notion about moving filter and order operations into the Select pane and giving it a new name? Seems like it would keep a logical workflow in one place and allow space to display info like how many records remain after each filter is applied. It would be useful for drawings too because you could filter what objects in a drawing are drawn rather than having to use a separate query or try to do it with the styling. Might be useful to filter images as well.

Dimitri


6,560 post(s)
#28-Mar-21 13:49

However you can change the field to any other field that works with the operation. After awhile you come back to the selection pane and forget the first and then wonder why all fields are not shown.

Instead, why not just go to Search then choose the field from a list of all the fields, then the operation options below changes to match the field type chosen?

A really big effort multiplier in both the Select and the Transform panes is how they can be used with repetitive task with many fewer clicks. Choosing the data type that you're working with (which is what choosing a field does) is key to that.

It's often the case that when you want to select in a particular way on one text or numeric field, you want to do the same thing in a different text or numeric field. That's especially true with moving stuff around with token operations. The current set up lets you do that with very few clicks, because only the field changes and all the other settings (could be many, including some fancy regular expression...) stay the same. It really cuts down on the number of clicks and entering the same stuff into boxes over and over.

It's also visually clearer. If you're doing a sequence of similar things, it helps that dialogs don't jump around in terms of rearranging boxes.

Right now, the Select and Transform pane trees in terms of selecting field first and then the main template and then options are arranged to allow maximum recycling of contents as much as possible with as few clicks as possible. If you try it other ways (they've been tried), you end up with longer workflow and less recycling.

I don't think order options belong in the Select pane because they're not a selection operation. They're just options for how to show what you've selected.

Filters already are in the Select pane. That's what some Select templates do. All you need is a Show Only Selection toggle button in the main toolbar. Filters are a point and click way of doing simple, quasi-favorites. They have a place in context menus already, and also in the main menu. What's to gain by duplicating the View menu in the Select pane? Note that filters don't select: they just alter the view in convenient ways regardless of what the selection is.

Almost forgot...

After awhile you come back to the selection pane and forget the first and then wonder why all fields are not shown.

No, you don't wonder that if you've learned how to use the Select pane. If you have, you know that when you're looking at a template you have a choice of all the fields that can be used with that template. You know why they are shown, and you find that useful. You're not surprised when looking at a template to search for subtext patterns in text that it doesn't show you numeric fields, for example.

If you haven't really learned the thing, then there will be lots of places that are puzzling which are very useful performance enhancers for people who have learned it. The way to deal with that is to learn the Select pane so those performance enhancers work for you as well.

adamw


9,588 post(s)
#29-Mar-21 09:17

Dimitri mostly said why we limit the choice of fields after selecting an operation above - this lets the UI stay more stable, getting many things that are clearly inapplicable to the data you are currently trying to work with out of the way and reusing the same operation for different fields.

We tried it with the combo that chooses any field at the top and the operation list filtered appropriately to the field type next, this was one out of three or four designs that we tried right in the code (not on paper). I wouldn't say it didn't work at all, but the current design works better. I could go into the details, but instead I will offer this - every design we tried had things which were better in other designs. As you try to make some things faster and more intuitive, other things get slower and less intuitive. There is no perfection. When about the worst we can say about the current design is that one can pick a field, then pick an operation, then not realize that picking the operation limited the list of fields and wonder how to get back to be able to pick a field that is not on the list - that's a win, issues with other designs are worse.

Regarding getting filters into the Select pane - we had some ideas of combining them, but decided it is better to concentrate on keeping the number of available filters small and in return means to apply them very fast, keeping the number of available selections large, *and* allow filtering by selection. This way you can filter by however rich criteria you want *and* you get to keep several of the most useful filters fast since they don't have to go through the selection. Regarding extending filters to work with maps - yes, absolutely, we will do that.

Mike Pelletier


1,864 post(s)
#29-Mar-21 18:53

Good to know the background on how Mfd arrived at the current setup in the Select Pane. Maybe the following visual reminder would be helpful. After choosing the table, field, and desired select operation, have the bold header change to reflect the field types it works with. Something like "Search: text".

With filters and selections I now get better what the thinking is behind it. I do like the quick way filters are applied but it seems allowing the Filter by Query tool to apply to the original table would also be really good, including for when it can be applied to drawings.

To answer Dimitri's question about was is gained by putting filter/selection into a pane, I'm thinking it could help with clarity of what is applied and a place to report its effect. Of course, you guys know much better how to implement, but FWIW I'm hoping for a good way to apply filter/selections so that they are readily apparent when it is revisited later, see/track how many records are affected by each step, be able to modify each step in the filtering/selection process, and save the steps for future use. Sort of like how you can alter/track image filters in photo editing software.

Thanks to you both for kicking this around with me!

klausk115 post(s)
#23-Mar-21 17:04

In my opinionM9 is unbalanced: a lot of power in big data and speed but weak in cartography (legends with automatic update, rule based labeling, html-lalbeling, changing the properties of these elements...)

dchall8
856 post(s)
#23-Mar-21 18:32

HTML-labeling reminded me of another HTML feature M8 has that M9 does not yet have. I used to export a KML file every week for Google Earth users in the county. In the export dialog for KML, there is a dropdown for Description where you may select a field from the table to include as text to go with the parcels. I created a field called KMLExport and filled that with HTML and CSS coding, which Google Earth reads just fine. The coding inside that field was created by a fairly complicated Query which extracted data from many fields, formatted it, and inserted it into the KMLExport field. Then when the user clicks on a parcel, a lot of information pops up in what Google calls a balloon. The HTML allowed me to encode a link for driving directions from a local airport to the location where the person clicked on their map. I have mentioned this several times in the past as the coding was in development. I suspect the code I used is buried here in the archives of this forum.

Dimitri


6,560 post(s)
#24-Mar-21 07:23

there is a dropdown for Description where you may select a field from the table to include as text to go with the parcels. I created a field called KMLExport and filled that with HTML and CSS coding, which Google Earth reads just fine. The coding inside that field was created by a fairly complicated Query which extracted data from many fields, formatted it, and inserted it into the KMLExport field. Then when the user clicks on a parcel, a lot of information pops up in what Google calls a balloon.

You can do that now. Create a field called description in your table, and that will automatically be used for the <description> tag in the KML. Sample text table:

The result:

The .mxb used is attached. Export KML Drawing to KML.

Attachments:
kml_earth_result.png
KML_html_example.mxb
kml_table.png

Dimitri


6,560 post(s)
#24-Mar-21 07:33

rule based labeling

? There are infinite rules open to you for labels. If that's what you want, make labels out of computed fields. Besides the full power of SQL and zillions of text functions to use, you can also use in-line scripting in many languages. That's a lot of different ways to write endlessly many rules.

It's also possible to also use a computed field to specify the JSON that defines a label's characteristics (style).

html-lalbeling

Why is it better to use HTML inside a display (map windows, layouts) that have nothing to do with HTML? Isn't it better to learn and to use the vast range of styling features that are available?

changing the properties of these elements

Labels are fully exposed for editing however you like. They're just text fields in tables with "properties" simply being values in JSON strings. You can edit them change them however you like, using a very wide range of facilities, such as manually in the Style dialog, manually changing the JSON in tables, using panes like Select and Transform to change values in many labels at once, using SQL to do arbitrarily sophisticated things using the premier language for slicing and dicing data, or programmatically using your choice of a variety of scripting languages, or a combination of those things, like SQL with inline script functions.

Dimitri


6,560 post(s)
#23-Mar-21 08:06

The other post is about creating sophisticated maps. Forgot to mention...

It is not only speed and big data.

One of the most important reasons for speed is that high speed provides easier and more efficient user interfaces.

The classic example in Manifold is previews, which provide far easier workflows for things like georegistration, (see this video and this one) and entirely new types of discovery activities in things like visibility zones. (see this video, and this video and this one). Previews make life so much easier than in primitive user interfaces that don't have them.

They also dramatically increase the quality of work and save time for things like ETL (extract, transform, load) operations where people are manipulating data, because they dramatically reduce errors, and give people the confidence to try more sophisticated approaches, like using regular expressions, which can save them hours and days of time. Regular expressions are amazingly powerful, saving a lot of time, but very few people can get them right the first time when flying "blind." In contrast, seeing what a regular expression will do with a preview against the actual attribute data you're manipulating makes it easy to get it right.

Here's an example where a vector transform can, with high confidence because of the preview, do a shift with only some points, enabling re-use of control points that might have take an hour to carefully assign. It's just a simple shift, but doing it with a visual preview instead of "blind" makes all the difference for confidence and avoiding errors.

The ability to handle big data is also a huge time saver and ease-of-use enhancement even if you're not working with big data.

Once you get used to being able, absolutely without effort, to handle any range of data with 9, when you visit ESRI and other GIS forums it's striking how much time and hassles people waste groveling around trying to dumb data down into something that fits within the tiny brain case of the GIS they're using.

With 9, you don't worry about that at all. Have an area of interest where you need a DEM? No big deal: download a dozen SRTM tiles and merge them and don't even think that the result is 2 GB of terrain elevation, because 9 handles all that effortlessly. Working with a less capable GIS? People start stressing out about adding another SRTM tile or two just because part of their area of interest extends beyond the few tiles they've downloaded.

Or, they start stressing out about the need to learn command line tools or Python programming to trim down / transform bigger data into what their GIS can handle, because it doesn't have the muscle to do that easily within the GIS. Sometimes it's like "OK, so you think that UI you're using is friendly, but the price of that slow, small data UI is that you have to drop out of it to write a Python program using a quirky library to trim down / transform the data into what your UI can handle... good luck getting that right the first time!" It's so much easier in 9.

A real life example: I needed high resolution coastlines for a project I was doing with coastlines in one city. The most convenient to use were high resolution coastlines extracted from OpenStreetMap, but those came in a single GPKG for the entire world, over 2 GB of vector data. No big deal for 9. I just used the whole world even though I only needed one city's coastlines. If I cared about the space, I could have just selected what I wanted, inverted, and deleted all that I didn't want. But the point is I didn't have to pause with concern about loading 2 GB of vectors, as that's trivial. The speed and capacity let me do extremely easy workflow.

A similar principle applies when doing sophisticated maps. Sophisticated maps often involve many layers, and with 9 there's not the least worry about dropping in dozens of layers, each of which might be gigabytes of rasters or vectors, to get the effect you want. Because 9 can transform on the fly, you can even use the same data in many different layers that show different visualizations of that data, and because 9 is fast, all that is fast enough for effective, interactive, "tinker time" to get exactly the effect you want. That's a big help for creativity.

Bernd Raab46 post(s)
#23-Mar-21 08:17

thats really wrong. I can now create much better maps/layouts than in M8, e.g. better formatting , handling legends, showing different maps in one layout.....

After accepting the fact that M9 is not a new M8, and after reading the manual, watching the videos and after a little playing around with "try and error" i found M9 a huge improvement and now i use M8 rarely. By the way, I do not think M9 is not intuitiv enough.

klausk115 post(s)
#22-Mar-21 19:56
lionel

709 post(s)
#27-Mar-21 23:33

Manifold is UI oriented and manifold 9 is SQL and speed Oriented so you can do a lot but need to understand how script interact with SQL code . So you need to understand SQL and the script language you want to use .

Because manifold focus of SQL engine and speed ...( 2 years to wait before SQL engine appear in a new GUI application name manifold studio i think that was not available during a long time ) and i think it is why Manifold 9 appear with now more and more SQL wizard because SQL wizard generate SQL code by using click button and input form without learn SQL.


union

lionel

709 post(s)
#28-Mar-21 00:02

when write SQL i also think of table and edit a table and edit shape in the same time is a breeze wonderfull !

See also how manifold wizard can compute value using wizard where input form can use differents projections ( meter or angle) .

The way manifold 9 manage projection is also wonderfull ...

The feature of manifold 9 ll be more SQL gis wizard and more menu...it is a question of time .

MAnifold 9 is like Space X dragon HMI compare to Space Shuttle Columbia !


union

Manifold User Community Use Agreement Copyright (C) 2007-2019 Manifold Software Limited. All rights reserved.