Subscribe to this thread
Home - Cutting Edge / All posts - Manifold System 9.0.164.8
adamw


7,975 post(s)
#29-Jan-18 17:01

9.0.164.8

manifold-9.0.164.8-x64.zip

SHA256: d0c0d0c0c08da3ac2c2fd93c80556e6f3ec7e92f9eb5830242960ae15a54c386

manifold-viewer-9.0.164.8-x64.zip

SHA256: 2a01dce49e199b995b1eba589d0b7bc028306b9f2d27092631b7204d6840d74e

adamw


7,975 post(s)
#29-Jan-18 17:02

Changes

The system activity indicator in the status bar shows activity for all background tasks, including UI ones. The number of currently running background tasks is shown in the tooltip.

Setting the Select or Transform pane to 'no action' either stops the background task for preview or marks it as not counting for the system activity indicator, whichever is better according to the window that displays the preview.

(Fix) Selecting the item used to create a new saved selection in the Select pane no longer treats it as a valid saved selection for the Edit Query button and the preview.

The Contents pane is reworked to display a single caption for the selected subpane at the top. Clicking the caption for the selected subpane displays a dropdown menu which allows switching to all other subpanes.

The commands switching to the subpanes in the Contents pane use Ctrl-1/2/3/4/5/6 keyboard shortcuts.

(Fix) The Record pane no longer shows the toolbar when there is no active record.

(Fix) The Layers pane no longer shows the toolbar and the layer list when there is no active window or when the component window does not support layers.

The Layers pane recognizes when the data it displays is read-only and disables controls and commands. Temporary layouts and temporary maps are always writable. Tables and queries always appear writable with changes to tables on read-only data sources being kept in the window and being discarded after the window is closed.

(Fix) The layout window allows altering temporary layouts even if the data source for the original component was read-only.

(Fix) Toggling a field in the MFD_META table on and off no longer sometimes makes field values in the toggled fields display as NULLs.

Trying to compute statistics for a big web image (more than 16 M pixels) for the Style pane computes statistics on a small top-level view of the image.

End of list.

tjhb
8,102 post(s)
#29-Jan-18 22:13

The Contents pane is reworked to display a single caption for the selected subpane at the top. Clicking the caption for the selected subpane displays a dropdown menu which allows switching to all other subpanes.

In my opinion this is bad design, a backwards step.

The Contents pane now shows a caption ("Contents"--arguably redundant now), and just one item at a time. Initially "Component".

That is going to be misleading for a new user. What does the Contents pane show me? It shows, um, information about the current component.

The keyboard shortcuts help an experienced user, but their immediacy tends to underscore the lack of immediacy in the user interface, considered visually.

The previous design was better. It showed a list, or menu, of the types of information and functions the Contents pane can show. That was very useful information in itself--which is now pushed into the background. The previous design was not only more immediately understoood, but also truer.

I am a bit worried that recent responsiveness to user feedback on the UI might be turning into "death by entropy"--to quote Dimitri in a different context.

It seems crucial that one person have overall responsibility for UI design, the power to say yes and no, to anyone and everyone. That should, preferably, be someone with design training, or solid visual design ability. But more importantly, that person should stick to his guns.

(For example, please ignore this: The name "Contents" does not suit the pane very well. Arguably, the Project pane shows Contents--like the table of contents in a book. And "Contents" does not suit the Select, Style or Transform panels very well. A better name for the pane might be "Data". Or perhaps not. But who cares? We are already used to "Contents". It is fine.)

No particular UI design will please everyone. Shifting all the time to try to please a larger crowd could get to the point where the UI becomes a "camel". I hope not.

Please consider going back to the mutli-panel interface for the Contents pane? That's just one vote, but from someone who cares deeply about UI design (without any training).

Regardless, the main holes now are not in the user interface, which overall is more than fine, very elegant.

danb


1,630 post(s)
#30-Jan-18 02:30

Please consider going back to the mutli-panel interface for the Contents pane?

Another vote


Landsystems Ltd ... Know your land | www.landsystems.co.nz

lionel

456 post(s)
#30-Jan-18 02:45

Hi

If you use photoshop you ll know that shortcut is the best productive way to go .In a way mouse mouse has only 3 keys ( minimal right left wheel ) to press compare to the number of keys on keyboard that can be press !!

perhaps ctrl x should only open the content instead hide all others item ( title and content) and show only the tittle of other item ( not copntent) .

If i want to see in same time component and Style ..i can't !! ( share @tjhb point of view )

in manifold 8 all pane go in the same column layout where project pane appear

regard's


join image "Because my dad promised me" interstellar from Manifold: Time by Stephen Baxter. power Math destruction

Dimitri


4,902 post(s)
#30-Jan-18 08:11

"Contents" does not suit the Select, Style or Transform panels very well.

I know you're not pushing this, but I disagree with the above. Consider the phrases "Transform contents", "Style contents" and "Select contents" ... fits just fine.

The contents pane is the workshop / laboratory / operating theater / artist's studio. The project pane is the library / card index / table of contents.

You could make a case for renaming the Project pane to "Contents" or "Browse" and the Contents pane to... ? ... not quite sure. "Studio"? "Tools" (ugh...)? The Project pane ended up with that name as a matter of inertia from 8.00 and use in other GIS packages. I think Contents ended up at that name for lack of a better suitably colorless, uninspiring and generic name, perhaps also being under the influence of ESRI's nomenclature they are starting to use.

I agree ESRI is not always the primary touchstone for the latest stylistic trends in graphics arts design, programming, etc., but they do have a certain influence that should not be ignored. I don't remember exactly how that happened but if there was an ESRI influence that's not automatically a bad thing.

tjhb
8,102 post(s)
#29-Jan-18 23:38

There is also an elephant in this Contents pane room.

The assumption from the start has been that we would only ever want to show or see one of

  • Component
  • Layers
  • Record
  • Select
  • Style
  • Transform

at one time.

That is not the case!

For example, it would often be useful to keep Component and/or Layers visible, while we are editing Styles. Or to keep Record visible, when adjusting Select. Or to keep Select visible, when performing a Transform.

[BTW I think this an ideal example of when the design team should actively solicit user input from a range of users in advance of decision--rather than waiting for voluntary, perhaps aleatory, feedback after the fact. The submissions model is good, but very far from perfect for Manifold products.]

However, I would much prefer that the current situation prevail for the official release, and perhaps be revisited and revised in 3 or 6 months' time.

I would rather see development invested in interpolation functions, curvature functions, for example.

That's just me, but I think for all users there are higher priorities than getting the UI details exactly right.

adamw


7,975 post(s)
#30-Jan-18 07:36

Thanks a lot for the posts.

First, it is very pleasing to hear that the UI no longer seems to be a bottleneck and that we should perhaps start switching to doing more of the analytical stuff with raster and vector functions (a lot to do there, we have big plans), etc! Thank you. We think we have quite a ways to go with the UI still, but in general, we also think we got most of the fundamentals and we can now split resources between continuing to add things to the UI and significantly extending and improving analytic capabilities.

Regarding the Contents pane, the decision to collapse the captions into a single caption was not made on a whim. We have long been concerned with the amount of space those captions occupy. We liked the design in all other respects, using a lot of space for captions was the only thing we didn't like. We have been discussing many variants of the design over time, most of them we threw away, we never saw them in the builds, not even cutting edge. If the design implemented in this build will prove to be worse than the previous one or otherwise deficient, we'll change it - but let's give it some time. As you say, a couple of months.

Regarding seeing one vs multiple subpanes - the restriction to only see a single subpane was a conscious decision. We wanted to let the user focus on a single task at a time. This does have its limitations, but it also has enormous benefits in that it minimizes the complexity. Some subpanes hosted in the Contents pane the user might theoretically want to show separately (Layers and Record, or Record and Style). But many combinations conflict, specifically those that have previews (Select and Transform - cannot have both panes showing previews on top of each other, it is confusing). Given that we are generally going in the direction of having more previews and not less (and we are planning to add things like clicks that interact with the active pane - eg, click a specific location to put it into the parameter box for a transform - this works much better if there is only one active pane), we decided to put all of the panes besides Project into Contents where they cannot conflict with each other.

Hope this helps see our thinking regarding the Contents pane and the UI in general.

Mike Pelletier


1,496 post(s)
#30-Jan-18 16:37

Generally, more clicks close together (within reason) is better than long mouse movements across the screen so I like the new arrangement. Also, it's best to offer flexibility in docking vs. not docking for different tasks and screen sizes. It would be nice to have an option too close all tabs/panes to maximize the area maps/tables/etc.

Would it make sense to create more tabs then just Project/Contents and put panes that conflict in the same tab? Seems like there is more real estate in the upper right corner that would allow for more tabs.

If there are other tabs/panes that you are planning but don't show yet because the functions are not yet ready, it still might be good to show them now (grayed out) so that folks can see the long-term picture of how the UI will work.

adamw


7,975 post(s)
#30-Jan-18 16:46

We'll see about having more tabs. There are pros and cons.

As regards future panes, we have at least three more planned (although that number can change and some of the plans are long-term) and that's not counting custom panes created by addons which we also want to have (need a bit of support from the object model). :-) It's a lot of panes and it makes sense to assume that by default every new pane conflicts with all other panes.

Dimitri


4,902 post(s)
#30-Jan-18 07:59

The assumption from the start has been that we would only ever want to show or see oneof

Nope. Not at all. It is not at all about wanting to see only one pane. Heck, any design which allows undocking as Manifold does is clearly not prejudiced against letting people have many windows floating about to see all sorts of things at once. Manifold loves the idea of people being able to add displays to the flight deck of their GIS starship.

Instead, the issue is entirely about the response to user actions a non-modal pane must have. That is difficult enough with just one non-modal pane, so difficult that the whole reason people reflexively default to modal dialogs is to dodge those difficulties. When a modal dialog is open, it seizes the user interface. No need to wonder which window responds to whatever the user does and to sort out possible conflicts, because you know it is just the one modal pane that has seized all focus.

Non-modal panes are very different: you can build interfaces that are fluid and natural with one non-modal pane, but the user interface rules become so intricate with more than one pane that, historically, the cost of educating users in the labyrinth of limitations and special case behavior rules that arise is far greater than what you gain by having more than one pain.

For example, it would often be useful to keep Component and/or Layers visible, while we are editing Styles. Or to keep Record visible, when adjusting Select. Or to keep Select visible, when performing a Transform.

I agree that would be useful, but as reporting widgets/displays, not as active panes. Perhaps an alt-click on the panel's caption could undock it into reporting gadget. That is a new interface idea, to allow panes to be undocked as viewbots of sort, which report their contents but which are not active as panes if they are not clicked into activity (at which point the previous pane automatically switches to read-only display widget status).

There are very many nuances to that idea that take a lot of time to think about and engineer, as the idea of a display that sometimes is a non-modal pane and sometimes not is a very non-routine thing. I'm not even sure it is possible within the sort of engineering expense that makes sense to apply to such a thing (for example, if the choice is between an Internet Map Server now or this thing as being the same engineering effort, we would do IMS).

For now, we don't do that because it is one non-modal pane that is the listener to user actions, switched into whatever regime is the right one to respond. The automatic switching by context (for example, the Record panel popping to the fore when you alt-click an object in a drawing) works naturally within that system as well. It works very well despite the complexity of context switching in a parallel system, etc. As you've pointed out, there are bigger fish to fry.

As for the more compact design for Contents pane panels, well, I like it a lot and it is a simple matter to implement. A big reason for it can be seen in the following two illustrations, the old and the new.

The old design wastes an enormous amount of screen real estate for blank captions. That's a crime for small screens and dead space/distraction even on large screens. I grant a single click on the panel you want is quick, but a click-click to the panel you want is pretty darned near as quick given the proximity of the clicks.

The ctrl-<number> shortcuts are a plus for those who want them, not a key part of the UI. Like all second or third tier keyboard shortcuts they aren't for everyone, but having them is no downside whatsoever for those who do not use them. If you don't use them, the new interface is plenty fast.

I understand that for beginners or people who haven't used the system for a while there is a certain utility in gadgeting up the interface with all the possible choices always on display. But it takes just a click to remind yourself what is there (third screen below), if you use the system for more than a few minutes you'll be refreshed, and having all the options hanging around as blank captions is both expensive in real estate and also distracting, not at all "quiet cockpit" for regular users.

How this thread started is a good illustration of the expense and distraction: no point in being wasteful of real estate because some of us use three or more monitors. A compact, efficient interface is also good for many monitors, and it becomes a life-saver with single screens and especially the smaller devices often used in the field.

The old interface on left and new interface on right:

The new interface with a single-click anywhere on the caption bar...

I remind everyone that in the old design you had to click at least once on a caption to switch from one panel to another, and often the click could be far apart, at the bottom of a pane or the top. In the new design you have to click twice, but the clicks are close together all at the top.

Attachments:
contents_new.png
contents_new2.png
contents_old.png

lionel

456 post(s)
#30-Jan-18 09:54

Yes it is better that the pane we use are not disturb by

title that are not use because those titles appear first

before the pane we need Access.

Regard s


join image "Because my dad promised me" interstellar from Manifold: Time by Stephen Baxter. power Math destruction

apo37 post(s)
#30-Jan-18 10:54

I fully agree with the new way to select the panes. Any new software ask to get used to it and this is not a problem. In the case of Manifold we such an amount of functionalities and features it is necessary to densify the information in the panes and this new "switch among panes" modus is fine. Good job, Thank's

lionel

456 post(s)
#29-Jan-18 23:03

Hi

Strange this is the official 9 not cutting edge but like cutting edge in zip format !!! Before the name was "manifold-future-9.x.y.z-x64.zip" .....

If i have a look to the post realtive ot new cutting edge version .... I can see that when version go from 9.0.163.z to 9.0.164.z then the name of the file switch from manifold-future to manifold .

regard's


join image "Because my dad promised me" interstellar from Manifold: Time by Stephen Baxter. power Math destruction

adamw


7,975 post(s)
#30-Jan-18 07:41

Yup, 9.0.163.x builds were called 'Manifold Future' and 9.0.164.x builds became 'Manifold 9' (and the installation packages lost the '-future' suffix).

Dimitri


4,902 post(s)
#30-Jan-18 08:16

See the announcement, which relates to that and provides some other useful info.

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