Author/map info should be option to switch off or on
Since MM24.1 Mindmanager registers automatically author info, both at topic level and at document level. These info can be shown or hidden on request.
When a map is published via HTML5, the filter prominently displays the Author Info at the top of its panel (there called Map Info). If you are not interested in (sharing) this info, or even if you consider the display of this info contra-productive you have only one choice: going back to legacy display setting or even going back to MM23.
IMHO the Author Info is so redundant and its size and position in the HTML5 filter panel so dominant and so ugly that its presence could become a show stopper for my HTML5 maps (one of them attracting more than 7,000 visitors).
My Idea, suggestion is:
- Please, make it possible to keep the Author Info out of sight under all circumstances, which implies removing it from the (published) filter panel entirely.
- If 1. is not possible, please, move the Author Info from the top to the bottom of the filter panel in order to keep it out-of-sight.
Best regards,
Pieter van der Hijden
I like this idea
It should be possible to select properties, elements, tags, and signs before exporting to HTML5 – similar to exporting to a Word document: first select, then export. The current proposal is limited to enabling or disabling the author's name and date. However, more selection options would provide greater flexibility and customization.
It should be possible to select properties, elements, tags, and signs before exporting to HTML5 – similar to exporting to a Word document: first select, then export. The current proposal is limited to enabling or disabling the author's name and date. However, more selection options would provide greater flexibility and customization.
Hi René
My short term goal is to be able to disable the Author/Map info that has been messing up my published maps. The biggest annoyance is the published HTML5 map. It prominently displays this unnecessary data against my will, against privacy regulations, against company policy to not clutter the maps, against company policy to strive for a uniform user experience across all their products, and is unmanageable for me. In the desktop window, Author info is even shown in every info card (even when it is unchecked in the Topic Info Display Settings)!
You are addressing an even wider problem: setting options at different levels:
Close inspection turns out that this is not always the case indeed. So I agree with you here improvements are certainly possible.
Best,
Pieter
Hi René
My short term goal is to be able to disable the Author/Map info that has been messing up my published maps. The biggest annoyance is the published HTML5 map. It prominently displays this unnecessary data against my will, against privacy regulations, against company policy to not clutter the maps, against company policy to strive for a uniform user experience across all their products, and is unmanageable for me. In the desktop window, Author info is even shown in every info card (even when it is unchecked in the Topic Info Display Settings)!
You are addressing an even wider problem: setting options at different levels:
Close inspection turns out that this is not always the case indeed. So I agree with you here improvements are certainly possible.
Best,
Pieter
Hi Pieter,
I try to reduce this to a simple formula.
If I send a mind map to another person, whether for editing or viewing, I have to be able to decide what they get.
No matter HTML5, co-editing or for revision.
René
Hi Pieter,
I try to reduce this to a simple formula.
If I send a mind map to another person, whether for editing or viewing, I have to be able to decide what they get.
No matter HTML5, co-editing or for revision.
René
Fully support your thinking on this one. I think you summarised it very well with 'I have to be able to decide what they get', René, while Pieter provided a nice list of options we would require.
Fully support your thinking on this one. I think you summarised it very well with 'I have to be able to decide what they get', René, while Pieter provided a nice list of options we would require.
Thanks, Wilhelm, for seeing the mutual advantages and overlap.
I agree with having to "decide what they get approach". That is in the HTML5 solution still a challenge:
Thanks, Wilhelm, for seeing the mutual advantages and overlap.
I agree with having to "decide what they get approach". That is in the HTML5 solution still a challenge:
---