Proposal for a new "yes-no" Dialog

[(:@)]

I find the yes-no dialog on my h100 a bit confusing. For example if I want to delete a file, the yes-no dialog displays 'PLAY = Yes' and 'Any Other = No'. I always think I have to press the Play-button for 'Yes' but the real button to confirm is the Select-button. Changing the text to 'SELECT (Button) = Yes' wouldn't be much clearer.
My proposal is to implement the yes-no dialog as a menu with two choices: yes and no.

The pros and cons are:
pros:
* clear
* save some bytes (I guess)

cons:
* only one line for the description text
* much work (especially updating the language files)

[AlexP]

It should say NAVI = Yes, as this is what it is marked as, and we refer to 'select' as.

There was a patch floating around many moons ago for a Yes/No dialogue - you may be able to find it on the tracker, although I suspect it will be so horribly out of date you may as well start again.

[roolku]

I am against it. The current mode  is faster, safer and can be operated blindly. With a menu you need to visually check the current selection, potentially make adjustments, wait until you are convinced that the new selection is stable (you didn't accidently overshoot and/or UI lag is not causing a delay in screen update) and then confirm the selection.

If the labelling is wrong for your target, it is easy to edit the language file. In fact it already is target specific:

  < source >
    *: "PLAY = Yes"
    h100,h120,h300: "NAVI = Yes"
    ipod*,x5,m5,gigabeatf,e200,c200,h10,h10_5gb: "SELECT = Yes"
    player: "(PLAY/STOP)"
  < /source >

if it doesn't work for you, there is a bug somewhere.

[(:@)]

Concerning the "NAVI = Yes": It's my fault (maybe a bug in my own build). I've tested it with an official build and it shows "NAVI = Yes".

There was a patch floating around many moons ago for a Yes/No dialogue - you may be able to find it on the tracker, although I suspect it will be so horribly out of date you may as well start again.

It's not that important that I want to screw up my build with an old patch. But thank you for the hint.

I am against it. The current mode  is faster, safer and can be operated blindly. With a menu you need to visually check the current selection, potentially make adjustments, wait until you are convinced that the new selection is stable (you didn't accidently overshoot and/or UI lag is not causing a delay in screen update) and then confirm the selection.

I don't know if we are talking about the same menu. I don't see the problem operating it blindly, because it will show up as:
Delete xy?
[icon]Yes
[icon]No

Confirm it with select (as it is now) or just move the 'cursor' to the item below and select it. There are only two choices possible, I don't think it will take long to update the selection if 'No' is chosen.

The settings in rockbox can be adjusted through menus and this one is not much different.

[JdGordon]

the proposal is certainly not new... that was one of the first thing I patched when I came to the project... it was rejected...

Using the list widget for the yes no screen would actually make it much easier to blind users, when the move up/down it would say "yes" and "no" and the question can be voiced easily. + there should be a binary decrease if this was changed... maybe ill have a play with this tongiht

[roolku]

I don't know if we are talking about the same menu. I don't see the problem operating it blindly, because it will show up as:
Delete xy?
[icon]Yes
[icon]No

Confirm it with select (as it is now) or just move the 'cursor' to the item below and select it. There are only two choices possible, I don't think it will take long to update the selection if 'No' is chosen.

That is what I have on my gps unit and it is really irritating. I can't count the number of times that I wanted to delete something and accidentally aborted the process as the device registered two key presses and wrapped around back to the "no" when I wanted to select "yes".

The settings in rockbox can be adjusted through menus and this one is not much different.

And I very much dislike the trend to replace what used to be a quick press of a button by long-winded menu navigation. (That by the way is the reason I don't use a more recent version of your sncviewer).  
But it all comes down to preference. I can't understand the people who, for example, prefer the mouse to keyboard shortcuts on the PC.

[pixelma]

That is what I have on my gps unit and it is really irritating. I can't count the number of times that I wanted to delete something and accidentally aborted the process as the device registered two key presses and wrapped around back to the "no" when I wanted to select "yes".

That could be prevented by not letting the setting wrap at all but...
I also don't like this proposal because it introduces one other (unnecessary) button press when you want to chose "no". This is also a bit confusing in my opinion because the operation would stay the same for "yes" and for chosing "no" I have to first navigate down in the "list" (at which point I could be done with the current way) and then have to confirm once more.

[JdGordon]

thats assuming Yes is the default, which imo it should not be

[pixelma]

The default doesn't matter here... it is always an additional button press if you want to chose "the other" option whether it is "yes" or "no".

[(:@)]

And I very much dislike the trend to replace what used to be a quick press of a button by long-winded menu navigation. (That by the way is the reason I don't use a more recent version of your sncviewer).  
But it all comes down to preference. I can't understand the people who, for example, prefer the mouse to keyboard shortcuts on the PC.

Keyboard shortcuts are quicker but the problem is to remember them. I just make the experience that I can't remember the shortcuts anymore after some time of not using them.

the proposal is certainly not new... that was one of the first thing I patched when I came to the project... it was rejected...

It's a pity. A further discussion leads to nothing, since it was already rejected. At least I am not the only one who think this is a better way for a yes-no dialog.

[AlexP]

For what it is worth I tried the patch out first time round, and prefer the current way, as I find it quicker.  

Keyboard shortcuts are quicker but the problem is to remember them. I just make the experience that I can't remember the shortcuts anymore after some time of not using them.

A 'keyboard shortcut' is hardly difficult to remember if it is written on screen!

[Llorean]

Personally, I'd hate to use the list for the Yes/No dialog. It just slows everything down?

I mean, yeah, it unifies the look slightly. But what's the benefit to actually *using* the device? It adds slows the ability of a knowledgeable user to use that screen.

[shotofadds]

Oh crap, there goes my first hit-the-edit-instead of reply button mistake with my touchscreen comment. Apologies to (:@), whose reply I just obliterated

Is it possible to retract an edited post?

[Llorean]

The only solution I've found is "hit back several times, then manually copy and paste the old post back into itself"

[shotofadds]

I tried that, but my browser cache was not forthcoming.

/me repeats "Do not operate heavy machinery whilst hung over" 100 times

Still, I stand by my comment that a list-style screen would be necessary for the touchscreen targets under development.