Reorganizing 'Options'

[Olivier_G]

- I divided options tree into main functional areas. 'Interface' is how program looks and works as a whole. 'Browser' and 'View' are two main functions the program performs. 'Read' and 'Write' define how program works with files to support program operations; 'Read' supports 'Browser' and 'View' and 'Write' supports misc tools. 'System integration' defines how program cooperates with its environment. 'General' is other options.
....
- Do not let user search too much. Both scattering options into many categories and squeezing them on one page are bad.
...

So, you placed under 'General' things that are specific ("other options") and you put directly 'Read', 'Write', 'System integration' on the top because they are... general?

We agreed on the real main categories (Browser, View, Interface)... the other items can be grouped under a 'General' category in order to avoid scattering options, especially at the root.
Trying to separate them into a more complex structure is trying to find some logic when there is none, and obviously makes the use and understanding of options more difficult for everyone.

Give reason for your choices. Otherwise they are worthless.

Done.

Olivier
(...and that was my 300... )

[Xyzzy]

So, you placed under 'General' things that are specific ("other options") and you put directly 'Read', 'Write', 'System integration' on the top because they are... general?

As I've written in a previous post, I used General because it looks nicer than Misc and is used in applications in the same context as option name.

We agreed on the real main categories (Browser, View, Interface)... the other items can be grouped under a 'General' category in order to avoid scattering options, especially at the root.

We should avoiding putting everything into one place as well.

Trying to separate them into a more complex structure is trying to find some logic when there is none, and obviously makes the use and understanding of options more difficult for everyone.

Have you read my reasonings (for Read/Write/System integration)? Are they wrong? How? If not, they seem to be OK, aren't they?

X.

[Xyzzy]

File sequence and Quick slide show are grouped;

Acceptable

Startup options are dispatched between 'Interface' and 'General';

But not all. It is important to let user easily define how XnView behaves when it's started.

'Misc' is grouped with 'Browser'.

Not enough space.

New explanation: 'Thumbnail' and 'appearance' are grouped together.

Not enough space. Any more options and we are in trouble.

No. There is a column 'Show in Preview' that allows you to restrict further what is shown in 'Preview'. Therefore it refers to both file list and preview.

Right. Moved level up.

OK: then I change the name to 'Misc' and still group those options.

Acceptable.

Or even better: I keep 'file sequence' and don't agree with your opinion.

Misleading. Why would I look for option for Quick Slide Show in File sequence options? One defines browsing behaviour for View mode, the other browsing feature, also affected by File sequence options.

Because I put under 'General' all options that do not fit under the other main categories (aka: Interface, Browser, Viewer).

But they DO have their own meaning, see my other post.

X.

[Xyzzy]

Here is complete plan, 35 items:
There is option (or page) name -> New location (remarks for items that may be not obvious)
Other options stay where they are now.
I omitted tree branches creation and not yet included Olivier_G remarks.

Remember last window position/size -> Interface
Use different position/size for browser & view -> Interface
Open HexaView if not a picture -> View (this option affects only View, as Browser file list and preview have their own settings)
Open one View per selected image -> Browser (hovewer about View, it describes behaviour of Browser Open action)
Delete to Recycle Bin -> General>File operations
Confirm file delete -> General>File operations
Disable GIF/JIF/ANI animation -> General>Browser&View (affects both Browser and View)
Enable BMP Animation -> General>Browser&View (affects both Browser and View)
Single ESC to Exit -> Interface
For 'Save as' use same original pathname&format -> General>File operations
After 'Save as', change filename -> Interface
Add 'Exit' to context menus -> Interface
Always on Top ->Interface
Only one instance -> General (I am not sure, but seems to fit)
Use XP style menus -> Interfeace
Use all formats avaliable -> General (it affects all XnView, including System integration)
General>Recent lists -> Interface>Misc (move whole contents of the page to new page)
General>Switching modes -> Interface>Switching modes (move all page to a new location; it describes how interface modes are switched)
Launch Browser at starup -> General>Startup
Startup directory group -> General>Startup
Show tooltips -> Browser>File list (tooltips are displayed only for file list, not fe. for preview)
Browser>Cache -> Browser>File list>Cache (move whole page; cache is used only for file list)
Maximize View when Open -> View>Quick View (affects only fullscreen View run directly form Windows)
Enable navigation with left and right mouse button -> View>Quick View (affects only fullscreen View run directly form Windows)
Hide play bar ->View>Quick View (as above)
Use delayed high quality pictures larger than... -> General>Browser&View (affects both View and preview in Browser)
Slide show -> General>Slide Show (move whole page; imo this has no reason to be in Options, just should be accessible directly from Slideshow window???)
Read>Rotate images based on EXIF -> General>Browser & View
Toolbar -> Interface>Toolbar (move whole branch)
Folder tabs -> Interface>Misc (create an option group for them on this page)
Plugin Adobe 8bf -> General>Plugin Adobe 8bf (move whole page)
Language -> Interface>Misc (change list into drop-down list)
Install -> System integration>Install (move whole page except for options below)
Use Windows folder to save INI file -> System integration (this opion is not about adding XnView appearance to various places in system)
Use registry to save options -> System integration (as above)
Associations -> System integration>Associations

[Olivier_G]

I divided options tree into main functional areas. 'Interface' is how program looks and works as a whole. 'Browser' and 'View' are two main functions the program performs. 'Read' and 'Write' define how program works with files to support program operations; 'Read' supports 'Browser' and 'View' and 'Write' supports misc tools. 'System integration' defines how program cooperates with its environment. 'General' is other options.

As said, I agree on 'Interface', 'Browser', 'View'... therefore, I will focus on the others:
- You say "Read and Write define how program works with files to support program operations". I agree, but I also find that your proposed 'File operations' follow the same logic...
- You say "Read supports Browser and View" but you propose "Browser and View" in General as well...
- "System Integration". Your explanation makes sense to me, and I have nothing to say against that.
There is nothing really "wrong". It's just that the relationship is relatively weak compared to the first 3 main categories.

The reason why I insist on limiting the number of nodes on the first level of the tree is to emphasize those nodes: if you put 'Interface', 'Browser', 'View' and add 4 or 5 more categories, you will actually dilute each of them (and make them less obvious and easy to remember/use). It is important to insist on those 'Interface', 'Browser', 'Viewer' because they are the main elements the user interact with on a regular basis (and they are 'strong': see we agree on them...).
This is why I gathered those additional categories under 'General' and oppose your suggestion to put 'Read', 'Write', 'System integration'... as main categories.

Olivier
PS: Xyzzy, you should probably edit your first message to show directly your structure (be it with 'code' as I do, or with lists in BBCode)... otherwise, less motivated forum members may skip it and not be able to follow the rest of the discussion...

[Xyzzy]

Olivier_G, what about this:

Renamed Quick View to Quick fullscreen.

Code: Select all

General 
	Startup
	Browser & View
	File operations
	Slide Show 
	Read
	Write
	Plugin Adobe 8bf 
Interface 
	Switching modes
	Misc (Languages, Recent lists, Folder tabs) 
	Toolbar 
		Buttons displayed 
		Skin 
Browser 
	Files displayed 
	File list 
		Cache
	Thumbnails 
		Appearance 
		Labels 
	Folder tree 
	Preview 
	Open action 
	Misc 
View 
	Keyboard/Mouse 
	Fullscreen 
	Quick fullscreen 
	Misc (File sequence, Quick Slide Show)
System integration 
	Associations 
	Install 

[Olivier_G]

I agree with the top categories: General/Interface/Browser/View/System integration.
(thank you for editing your message and taking into account previous comments)

I will have to get a closer look at detailled options themselves for more comments, as I removed quite a lot of categories compared to your suggestion (especially in 'General'), and I need to check that it makes sense (ie: logical +enough room). But I woud say that it matches pretty well, overall.

Some quick notes, though:
- I never understood/accepted why there were different Fullscreens (from View, Browser, Startup), therefore my reluctancy to accept 'Quick fullscreen'. But if it must be so, I will change my mind...
- GIF/JIF/ANI and BMP Animation control the way the format is displayed. If you check 'Read', you will notice that it controls how it is Loaded AND Displayed (cf gamma, etc... settings), therefore I consider that it shoud be added in 'Read'. It also makes 'Browser & View' less useful (especially if you see 'Use delayed high quality pictures larger than' as a quickfix for a current flawed implementation of high quality display/zooming).

Olivier

[Olivier_G]

So, my comments...

Code: Select all

General
   Startup
   Browser & View 
   File operations 
   Slide Show 
   Read 
   Write 
   Plugin Adobe 8bf

Remove 'Browser & View': GIF/JIF/ANI and BMP Animations should go under 'Read' and 'Use delayed high quality pictures larger than xxx' should go in 'General'.

Remove 'File operations': they should stay in 'General', maybe in a 'File operations' group.

Remove 'Slide Show': I believe the options here are in the same logic as the settings available in its Dialog and should be removed from 'Options'.

More difficult: Remove 'Startup' (note: most of the current options will go into 'Interface': Always on top, Use XP style menus...).
Contrary to Xyzzy, I believe it's more logical to look directly into the affected element to set startup/open options, rather than into a generic 'startup' category => more opinion would be welcome here!
(this logic applies to: 'Launch Browser at startup'&directory->Browser; 'Open one View per selected image'->View...)

Next...

Code: Select all

Interface 
   Switching modes 
   Misc (Language, Window tabs, Recent files) 
   Toolbar 
      Buttons displayed 
      Skin

I would like the Toolbar options to be removed completely from this centralized 'Options' window to a contextual menu/dialog... just like most applications with lots of options: right click on any toolbar of Word, Excel... Internet Explorer, Opera... ACDSee... Should I go on? (I must have clicked about a hundred times on the small 'file list' toolbar to look for that RMB 'Hide' function... )

Code: Select all

Browser 
   Files displayed
   Open action
   File list 
      Cache 
   Thumbnails 
      Appearance 
      Labels 
   Folder tree 
   Preview 
   Misc

I believe it is possible to gather 'Thumbnails' and 'Appearance' under the same page, by working on the Appearance group (Border/etc... Size and Color should appear on a same line and some other improvements). It would then be possible to put 'Thumbnails appearance', 'Thumbnails labels' and 'Cache' directly under 'File list'. To avoid the 3rd level, they could also go directly under 'Browser'...

Remove 'Misc': move its options into 'Browser' or 'File list' by changing the radio buttons into 2 simple drop-down lists.

I think it's better to move the 'Folder tree' options to a RMB contextual menu... but I am not that definitive about that.

Code: Select all

View 
   Keyboard/Mouse 
   Fullscreen 
   Quick fullscreen 
   Misc (File sequence, Quick Slide Show)

Remove 'Quick fullscreen': I believe those options should stay in current 'Fullscreen' (note: there is more space, as 'use delayed HQ...' is moved to 'General')

Code: Select all

System integration 
   Associations 
   Install

Remove 'Install': just creating 2 groups under the same 'System integration' page should be better.


Xyzzy considers that it is better to have separate categories for options that can be logically organized separately, whereas I tend to group things when possible. Just a different point of view, I guess...
My opinion, though, is that we should avoid categories almost empty, as they add more complexity for little gain.
What are other opinions, here?
(come on... I would like to read more from Pierre, Helmut, Dreamer, etc... )

Olivier

[Xyzzy]

My idea is evolution not revolution, so I assumed as little option layout/type changes as possible. Less mess, less controversy and such changes are subjective. The only exception is changing Language list box to drop down list. Also such approach makes it easier to instantly redesign Options window, so we could propose changes already for this version. And I think current options types are OK.

I also think you are wrong when you try to stuff everything as much as possible. Options tree should lead user to the right option, especially when they are about important features form user's point of view. Remember that we are trying to find optimal layout not for ourselves, but for an average user. Option three should lead right to the option. So also I consider that Languages should stay on its own branch all in all. Changing option would not be needed!

I don't like General>Browser&View as well, but Animations options are like View>File list>Play movie and Play sound options, but affecting both Browser (preview) and View. Said this, in Read there are options for PNG that affect only display, so maybe these should be moved to Browser&View? If Browser&View should stay, there's no reason to move Use dalayed...

File operations- I have doubts, on the other hand there is plenty of space in General and I suppose not much else can appear there.

Slide show- Yes, it should be moved to slideshow dialog. But as we are redesigning Options, it should stay under General for now. If Pierre thinks it's easy to move it completely to dialog, I'm for it.

Startup- I do not agree. This is important to easily find how application behaves on startup. Browser/View define options for XnView when it's already running. At startup there is no XnView running yet. These are very distinct options.

Toolbar options - no, I completely disagree. XnView is not MsOffice style applicaion and hiding options on RMB on Toolbar is strange. We should not support bad design and MS idea to put toolbar configuration in such place is bad (EDIT: OK, at least for me it is completely unexpected solution). BTW, in MS office you can still manage toolbars from options dialog. Options for interface elements that cannot have it's own Options button (or something similar) should go to Options. Period.

Thumbnails etc- No. Not enough space- options redesign required. Any more option added and there is problem.

Misc - no. Options redesign required.

Quick fullscreen is really 3rd mode of XnView operations. It has its own purpose and options. It should stay.

Install should stay. It has many options and takes a bit space.


X.

[Olivier_G]

Well... my idea is redesigning from scratch, based on the options used by XnView. So you may call it 'revolution'...
This includes: check which options should belong to the main panel, structure the Options tree, organize layout on each panel, optimize each option design, etc... (and always in order to improve the interface for the average user)

I also consider that more time/discussion/'controversy' in order to reach an agreement is an advantage: it usually means that people are more involved. It also implies that we don't change things every other day: changing an option a little at each release is a pain for most people who needs to re-adapt to the new layout. Touching the interface should be carefully planned.
Therefore, the amount of change/work is secondary to the goal of reaching the best interface. And implementing part of this redesign as quickly as possible for the 'next release'... is not exactly what I am looking for.

All this being said...

I also think you are wrong when you try to stuff everything as much as possible. Options tree should lead user to the right option, especially when they are about important features form user's point of view.

Well: I just think that you try to separate, while being reasonnable... and that I try to group, while being reasonnable (I don't ask for a single panel... as much as you don't ask for a separate panel for each setting). As this is very subjective, I would like to get more feedback from other forum members. Guys???

File operations: if you check the screenshot in this message, you will see how it is possible to have strong groups in a single panel (layout, use of bold for group title...).

Slide Show options: we agree that it should move... as soon as it can be implemented in its own Dialog.

Startup: because I would look for 'Launch Browser at startup' under 'Browser'... there is only 1 option left in 'startup' in my 'logic' ('Start XnView maximized'). More opinions would be useful, though...

Toolbar: I think contextual options are easier to find/remember/use and more straightforward.

Misc: Yeah! let's redesign and improve!

Not quite decided for Quick fullscreen, Install, and a good solution for Browser&View&co...

Olivier
PS: once we agree on most categories, I will list the whole Tree with the corresponding options... and suggest Name/Group/Design changes.

[Clo]

Olivier_G

Hi !

- Please, check your PMs…

KR
Claude
Clo

[Xyzzy]

Olivier_G:

So maybe we should propose 2 solutions- mine, that requires no changes in options themselves (just moving them around) and yours, with more changes (making Options window bigger as well)?

X.

[Olivier_G]

So maybe we should propose 2 solutions- mine, that requires no changes in options themselves (just moving them around) and yours, with more changes (making Options window bigger as well)?

Please, no. I believe we can and should first reach some kind of 'ideal' interface (without taking into account the amount of changes) before proceeding so.
The amount of changes is probably not that important. It is even possible that this 'ideal' interface could be implemented quickly and directly.
This would be the perfect solution (of course: Pierre will have to confirm).

Please, check your PMs

Done and answered .
Thank you for the input about Interface possibilities regarding XnView. I think that I will focus on organisation of options, and consider the current interface as 'appropriate' for now.

Olivier

[Xyzzy]

Olivier_G,

There is no such thing as ideal interface.
I do not feel competent to make 'complete redesign'. I had my last user interface classes ~10 years ago, and problems then were quite different than they are now.
I just want to sort out some options a bit, so that they are easier to find and more logically layed out.
All my changes are quite trivial to implement I believe, so the probability that Pierre uses them is higher.
I do not agree with your tendency to stuff as much options as possible on every page.
For me, your design is like going from one mess to another.

X.

[Dreamer]

I would like to get more feedback from other forum members. Guys???

Too long posts.