XnView Software

JohnFredC wrote:

Which action has single click on whole separator if you have 2 possibilities?

Maybe I don't understand the question?

Pierre is not talking about removing the new "Show/Hide one-click Button".

The issue is about my suggestion to have single click on the whole bar to show/hide. Let's look at what happens:
- Resize: I press LMB on the bar, move the bar to new position, depress LMB
- Show/Hide: I click LMB on the bar (ie: quickly press/depress without moving)
=> Isn't it possible to identify correctly this?
(if no -> closed... it's not a big deal)

-To the left is current separator, to the right- thinner
(two pixel-strips removed from every side).
-As Olivier_G wrote, we do not like to remove button.
-If it is a problem with single-click on separator beyond button to show/hide, let's forget about it.
-Maybe if double-click on separator beyond button to show/hide is easy to implement, let's do it.

Olivier_G wrote:

JohnFredC wrote:

Which action has single click on whole separator if you have 2 possibilities?

Maybe I don't understand the question?

Pierre is not talking about removing the new "Show/Hide one-click Button".

The issue is about my suggestion to have single click on the whole bar to show/hide. Let's look at what happens:
- Resize: I press LMB on the bar, move the bar to new position, depress LMB
- Show/Hide: I click LMB on the bar (ie: quickly press/depress without moving)
=> Isn't it possible to identify correctly this?
(if no -> closed... it's not a big deal)

Ok, i add it to the preview panel first to test

xnview wrote:Ok, i add it to the preview panel first to test

Thank you, Pierre...

xnview wrote:Ok, i add it to the preview panel first to test

I like this new separator (thin and nice) in Preview panel. I also love the single click action on separator (although it is more difficult when both directions are available... ).
Overall opinion on new separator design: excellent and doesnt interfere with usual separator movements...

Hello !!

• Sorry, like I said elsewhere already, I don't like that preview GUI at all.

I need a microscope to catch the buttons, and clicking on a so narrow strip is as so acrobatic.

- I liked the simple tab-buttons. It's clear and user-friendly,
and allow a single wider splitter in which we had visible and “clickable” buttons.

• Point noted.

KR
Claude
Clo

Sad I need a microscope to catch the buttons, and clicking on a so narrow strip is as so acrobatic.

- I liked the simple tab-buttons. It's clear and user-friendly,
and allow a single wider splitter in which we had visible and “clickable” buttons.

I agree

Paul

I run 1920 x 1200 and the separators are plenty big enough for me. Really, really like their behavior. This Browser implementation is what I have been hoping for quite a while.

One click! Yay!!!!

Thanks very much!

Please keep in mind that this discussion is about the design of the separator itself (and not the 'tab vs separator' or layout of the preview panel). I mentionned "Preview panel" only because this is where Pierre implemented this new design.

What is compared here is 'New on left' vs 'Old on right:



The new design:
- has the same active thickness and the same buttons size as previous (ie: not harder to use/click)
- takes 50% less space
- looks quite good to me
Several persons supported that new thinner design of separators.

Olivier
PS: I will try to come with a better solution for the Preview panel and 'separator vs tabs' issue. Claude and Paul: I do hear you about the fact that separators are not convenient to switch regularly between features/views. Let's look what we can get there...

—> Olivier_G

Hello !

• First, I guess that to split the topics in excess is not helpful, all these details are linked. Just my opinion…

• Second, even in 1.90 Ax Paul and I had wished wider buttons in the strips, there are messages and pictures about this.

• Third, we would propose for now:

¤ An option even only as an extra-INI entry to get a wider strip and a proportional button size.

¤ Same kind of option to get a bigger —||— cursor to catch the “click on strip” state. Currently, getting the —||— is a quite uncertain handling, it needs Fairy's fingers. Sorry, we have none such fingers…
- For us, it's not usable with more than 600*800…
- I've 1024*768 - CRT 17" - and Paul has much more…

That's all.

KR
Claude
Clo

I think issues like this raise significant accessability questions. It is not just a matter of: "Does X look more cool than Y". And the fact that someone else is able to use a microscopic element on their new high resolution monitor just isn't meaningful to those who cannot do the same. I might follow up later using the other topic concerning possible workaround which might be more accommodating. I'm routinely astonished that others can use high resolution monitors and small GUI elements (and then suggest more of the same).

The first message of this topic is about optimizing the design of the separator only (+it was actually made before the new Preview suggestion).
-> Result: design of the separator has been improved without affecting accessibility, as I explained in the previous message.

It is not 'design optimization' vs 'accessibility'!
On the contrary, I believe that thanks to this first improvement, accessibility may be improved (ie: increasing active area by 50%, without any drawback).

The new separator is 6 pixels large. When using Pixie to check coordinates+colour and controlling cursor status, from left to right:
- on the bar -> pixel 1 is not active; pixel 2 to 6 are active.
- on the button -> pixel 1 to 6 are active, but the cursor changes in some occasion to -||- (move separator) when it shouldn't (doesn't move).
So there is 1 pixel to add on the active area and 1 small bug to correct to improve accessibility.

Now... I like the original suggestion by nightflyer:


There is a 2 pixel outline for 3D effect in addition to the 4 pixels central zone.
-> Pierre, is it possible to include that outline into the active area?
That would make the active area 8 pixels large (compared to 5).

During pointing and clicking activities, every mouse user generates an "area of confusion", which is an area centered on a mouse target (such as a button or control) defined by the statistical spread of that user's "points and clicks" while pointing and clicking on the control, over time.

The shape and size of the area of confusion is dependent on many factors: the size of the control relative to the 2-dimensional display space, it's visual characteristics (ease of identifiability), the user's intrinsic motor control skills, whether the user is left handed or right-handed, the precision of the mouse/mouse pointer "motion capture" interface, the pointer acceleration mode, etc. etc.

The point I was making in my remarks above is: if the new XnView splitter controls are big enough for my personal area of confusion to be tightly confined to the splitter controls (on my moderately high resolution monitor and with my highly accelerated mouse pointer), then on lower resolution monitors the same splitter controls will be relatively larger and should be even easier for the majority of users to accurately click on.

But if the controls don't seem big enough for the majority, start by making them longer, not wider. Longer doesn't use any additional (valuable) display space. Wider does.

And just as an aside: my monitor is almost two years old, not new. One should always design software for the future in which it will be used... not the past.

JohnFredC wrote: And just as an aside: my monitor is almost two years old, not new. One should always design software for the future in which it will be used... not the past.

Different layouts exist for different styles of use. If interested, look and experiment with function as comparitively pictured in other topic. I am not willing to speculate about a "majority of users". My supposed obsolescence might be of some benefit...