Next steps for MP

[JohnFredC]

Just hanging new tool after new tool onto the menus doesn't have priority for me. MP is already excellent, but needs further modularization to fully support the functionality it already does have!

A good tool could be made legendary!

Hence, much more work on the MP infra-structure needs to done. The core integration of MP tools that are already implemented "piece-meal" but which are common to multiple tasks throughout MP is still sorely incomplete:

For instance (no particular order):

• 1. Unified label UI: all labels should be edited from a dedicated "Label design" dialog. Standardize the "select label" UI control clusters at all points in MP where labels are possible. Allow user to save any number of labels and use them anywhere without having to redefine them.
  
  2. Rationalization of the control UI/data structure for layouts, thumb styles, themes, etc. etc. as I have suggested many times in the past. IMO it is crazy to have such control over thumbs appearance/size/labels, etc, but not to be able to save/restore/switch between individual thumb styles or connect them to layouts/folders, etc. Esp. irritating (and non-productive) is how resizing the thumbs initiates re-caching of thumb images!!!
  
  MP already has the customization options to be a chameleon software for many different purposes, from kiosks, to newbie tool, to advanced media management, but the means to switch easily between these different rolls is essentially lacking.
  
  An effort to unify all the layout-related customization into one UI would not add complexity to MP, it would reduce complexity!
  
  3. Re-examine modal vs. non-modal UIs for every relevant feature and implement to non-modal (either floating non-modal dialog or tab) where warranted. The current experimental "Batch Convert Tab" is a good start, but slide show, "strip of images", many features not yet implemented would also benefit from a tab-based UI.
  
  4. Implement some sort of "project" UI metaphor and data structure, where MP reopens previously open groups of tabs, etc. ("Save/restore MP project", for instance). The new load "List of images" is a big step toward such an approach, though the list only populates the browser.

These are all long-standing requests of mine argued at length in both the XnView legacy and MP forums. None would interfere with the use of MP as a simple image browser, but they would greatly simplify/enhance the user experience and make the entire tool more flexible, more efficient to use, and easier to support for the developer.

Sorry to word things so strongly, but once there are many different tool/features, revisiting these issues becomes nearly impossible.

As always, thanks for listening (er, reading)!

[xnview]

• 1. Unified label UI: all labels should be edited from a dedicated "Label design" dialog. Standardize the "select label" UI control clusters at all points in MP where labels are possible. Allow user to save any number of labels and use them anywhere without having to redefine them.

Could you explain me more this one?

2. Rationalization of the control UI/data structure for layouts, thumb styles, themes, etc. etc. as I have suggested many times in the past. IMO it is crazy to have such control over thumbs appearance/size/labels, etc, but not to be able to save/restore/switch between individual thumb styles or connect them to layouts/folders, etc. Esp. irritating (and non-productive) is how resizing the thumbs initiates re-caching of thumb images!!!

MP already has the customization options to be a chameleon software for many different purposes, from kiosks, to newbie tool, to advanced media management, but the means to switch easily between these different rolls is essentially lacking.

An effort to unify all the layout-related customization into one UI would not add complexity to MP, it would reduce complexity!

Yes, need more thinking...

3. Re-examine modal vs. non-modal UIs for every relevant feature and implement to non-modal (either floating non-modal dialog or tab) where warranted. The current experimental "Batch Convert Tab" is a good start, but slide show, "strip of images", many features not yet implemented would also benefit from a tab-based UI.

First, we must see how 'batch convert' works and what is missing...

4. Implement some sort of "project" UI metaphor and data structure, where MP reopens previously open groups of tabs, etc. ("Save/restore MP project", for instance). The new load "List of images" is a big step toward such an approach, though the list only populates the browser.

But what is saved in "MP project"??

[XnTriq]

1. Unified label UI: all labels should be edited from a dedicated "Label design" dialog. Standardize the "select label" UI control clusters at all points in MP where labels are possible. Allow user to save any number of labels and use them anywhere without having to redefine them.

Could you explain me more this one?

• Usability: Unified Label Interface
• Conditional labels for thumbs and info

4. Implement some sort of "project" UI metaphor and data structure, where MP reopens previously open groups of tabs, etc. ("Save/restore MP project", for instance). The new load "List of images" is a big step toward such an approach, though the list only populates the browser.

But what is saved in "MP project"??

• XnView MP & theme » Post #67645

[JohnFredC]

2XnTriq
Thank you Mr. Librarian!

2Pierre
"Unified Label UI" sounds complicated, but isn't. It simply means:

"One tool to design them all, one tool to apply them"

STANDARD CONTROLS

• In any MP tool where there is a possibility for the user to display a label (thumbs, full screen info, view info, tooltips, etc... anywhere!) there should be a standard set of controls to restore/select a saved label from a combo-box list or start the label editor.
  
  Something like this:
  
  
  
  Clicking the "Label Editor" button would open the label editor tool (see below).

ONE (1!) LABEL EDITOR

Currently in MP there are three completely different label design tools:

• • Options>Browser>Tooltips
    View>Info
    Thumbnail>Labels
  Each has something to recommend it, but really, 3 different editors????
  
  Better to combine all label editors into one tool in its own options section: Options>General>Labels
  
  Now... perhaps you may object that each different type of label is displayed in each a different type of control and therefore the labels are not compatible with one (only) control type... well, if they aren't, then force compatibility by designing the label data structure around the needs of the most complicated label (thumbs, perhaps?).
  
  A label originally designed for the thumbs (with different colors, perhaps) could be forced to display in the simpler full screen info control by simply ignoring the color specified in the label design and using the user-selected textcolor for that view.

[xnview]

Currently in MP there are three completely different label design tools:

• • Options>Browser>Tooltips
    View>Info
    Thumbnail>Labels

Each has something to recommend it, but really, 3 different editors????

Labels for thumbnails can't be merged, a standard label editor can't used here...
But for Options>Browser>Tooltips & View>Info, it's the same editor, what is the difference?
Is it better to open another dialog to enter text, instead to have edit text directly??

[JohnFredC]

Hi Pierre

You wrote:

Labels for thumbnails can't be merged, a standard label editor can't used here...

OK, Why not use the thumbs editor for ALL labels? It's the best one. Please re-read what I wrote above. I have added an highlight:

Now... perhaps you may object that each different type of label is displayed in each a different type of control and therefore the labels are not compatible with one (only) control type... well, if they aren't, then force compatibility by designing the label data structure around the needs of the most complicated label (thumbs, perhaps?).

A label originally designed for the thumbs (with different colors, perhaps) could be forced to display in the simpler full screen info control by simply ignoring the color specified in the label design and using the user-selected textcolor for that view.

If the user assigns a saved label (created by the thumb label dialog) to Info or Tooltips (for instance) MP could warn the user: "Label color formatting will be ignored"

Simply ignore (or parse out) the color data and concatenate the text of individual lines of the thumb label for use in info or tooltips.

[xnview]

Hi Pierre

You wrote:

Labels for thumbnails can't be merged, a standard label editor can't used here...

OK, Why not use the thumbs editor for ALL labels? It's the best one. Please re-read what I wrote above. I have added an highlight:

It's not possible Most of labels used in thumbnails are single label. Custom label is slower...

[JohnFredC]

Hi Pierre

You wrote:

It's not possible Most of labels used in thumbnails are single label.

This is why all these issues need to be decided before development starts and why I wrote:

revisiting these issues becomes nearly impossible.

But it isn't too late to address the label infrastructure:



Modern computers just get faster and faster. A little thing like parsing a label definition cannot add significantly to the label display time, esp. if the action (for Info, Tooltips, etc.) actually simplifies the label for display! The time the user spends in an in-efficiently designed label editor will far exceed that, over time.

It's the total cost to do something: User interaction cost+ computer processing cost + display cost = Total cost that should be the metric for the design, not the individual time of any one component. The most "expensive" thing is the user interaction cost. Processor cycles are much cheaper.

[JohnFredC]

Hi Pierre, it's me again...

You wrote:

Is it better to open another dialog to enter text, instead to have edit text directly??

This is the modal vs. non-modal argument, which I tried to address with my little "control cluster" example:



My proposal offers both modal ("Label Editor") and non-modal ("Text") access. You could implement a text box control instead of a combobox control, if that would be better.

But the specific design of the label editor isn't the issue.

IMO there is a preference in the UI design community to suppress "redundant" controls. But this preference leads to modality, the least efficient UI paradigm. Hence, I am not opposed to redundant editor instances (displayed in each Options category... Info, Tooltips, etc). In fact, the best of all possible worlds would show the full editor in each Option panel, a completely non-modal paradigm. But the editor instances should all be the same editor.

Finally, there is no contradiction to the above in having Options>General>Labels also!

Whatever makes the user's entire interaction with labels the most efficient works best for me.

[xnview]

My proposal offers both modal ("Label Editor") and non-modal ("Text") access. You could implement a text box control instead of a combobox control, if that would be better.

But the problem is "labels" for tooltips & info are multiline, not single line....

Finally, there is no contradiction to the above in having Options>General>Labels also!
Whatever makes the user's entire interaction with labels the most efficient works best for me.

Hum, i'm not sure that having all labels settings in the same panel will be good... (Perhaps i'm wrong)
What think others users?

[JohnFredC]

Hi Pierre!

You wrote:

But the problem is "labels" for tooltips & info are multiline, not single line....

I wrote:

Now... perhaps you may object that each different type of label is displayed in each a different type of control and therefore the labels are not compatible with one (only) control type... well, if they aren't, then force compatibility by designing the label data structure around the needs of the most complicated label (thumbs, perhaps?).

...and...

Simply ignore (or parse out) the color data and concatenate the text of individual lines of the thumb label for use in info or tooltips.

Just iterate through the individual lines/labels assigned to the thumbnail cartouche and concatenate the label texts with carriage returns + line feeds for use in Info/Tooltips, etc... That concatenation process would occur in the "Conversion" step of my flow diagram (see above).

That's essentially concludes my argument for a single label data structure and tool. Time for others to step in.

Probably none of it matters to the majority of users, anyway.