tchou wrote:
> Persistence [more info]
> [type your passphrase to unlock....(xx) ] [enable] <= make it a button
> rather than a label, so the user can perform himself too the checking (I
> mean there is the autochecking, but it's possible to click too to check).
I think that I prefer having a button to enable. I'm also not sure about
the autochecking: if we have an "enable" button then it is not strictly
needed, and I'm not how much users would be badly surprised by this. So
I'm thinking that we should avoid it if we already have a button for that.
> I don't realy know if we must write the state (disabled) or the possible
> action (enable). The Gnome 3 toggle button is a state one (off/on)
> (http://www.dedoimedo.com/images/computers_years/2011_1/gnome-3-bt-menu.jpg)
Yes, but I think that here we don't need a toggle button but an action
button "Enable" (as you proposed) so there is no doubt on terminology
for me. But yes, it would be good to have a visual feedback about the
state. Then what about reuse the padlock metaphor from GNOME Disks?
That would probably have less states:
Initial state:
Persistence [more info]
[Type your passphrase..............(xx) ] [icon: pad closed] [enable]
After clicking on enable
Persistence [more info]
[ooooooooooooooooo.................(xx) ] [icon: spinner] [enable]
If the password is correct:
Persistence [more info]
[ooooooooooooooooo.................(xx) ] [icon: pad open]
([enable] button disappears)
If the password is wrong:
Persistence [more info]
[ooooooooooooooooo.................(xx) ] [icon: pad closed] [enable]
wrong passphrase, type again
--
sajolida
%20%5D%20%5Benable%5D%20<=%20make%20it%20a%20button%0A>%20>%20rather%20than%20a%20label,%20so%20the%20user%20can%20perform%20himself%20too%20the%20checking%20(I%0A>%20>%20mean%20there%20is%20the%20autochecking,%20but%20it's%20possible%20to%20click%20too%20to%20check).%0A>%20%0A>%20I%20think%20that%20I%20prefer%20having%20a%20button%20to%20enable.%20I'm%20also%20not%20sure%20about%0A>%20the%20autochecking:%20if%20we%20have%20an%20%22enable%22%20button%20then%20it%20is%20not%20strictly%0A>%20needed,%20and%20I'm%20not%20how%20much%20users%20would%20be%20badly%20surprised%20by%20this.%20So%0A>%20I'm%20thinking%20that%20we%20should%20avoid%20it%20if%20we%20already%20have%20a%20button%20for%20that.%0A>%20%0A>%20>%20I%20don't%20realy%20know%20if%20we%20must%20write%20the%20state%20(disabled)%20or%20the%20possible%0A>%20>%20action%20(enable).%20The%20Gnome%203%20toggle%20button%20is%20a%20state%20one%20(off/on)%0A>%20>%20(http://www.dedoimedo.com/images/computers_years/2011_1/gnome-3-bt-menu.jpg)%0A>%20%0A>%20Yes,%20but%20I%20think%20that%20here%20we%20don't%20need%20a%20toggle%20button%20but%20an%20action%0A>%20button%20%22Enable%22%20(as%20you%20proposed)%20so%20there%20is%20no%20doubt%20on%20terminology%0A>%20for%20me.%20But%20yes,%20it%20would%20be%20good%20to%20have%20a%20visual%20feedback%20about%20the%0A>%20state.%20Then%20what%20about%20reuse%20the%20padlock%20metaphor%20from%20GNOME%20Disks?%0A>%20%0A>%20That%20would%20probably%20have%20less%20states:%0A>%20%0A>%20Initial%20state:%0A>%20%20%20%20Persistence%20%5Bmore%20info%5D%0A>%20%20%20%20%5BType%20your%20passphrase..............(xx)%20%5D%20%5Bicon:%20pad%20closed%5D%20%5Benable%5D%0A>%20%0A>%20After%20clicking%20on%20enable%0A>%20%20%20%20Persistence%20%5Bmore%20info%5D%0A>%20%20%20%20%5Booooooooooooooooo.................(xx)%20%5D%20%5Bicon:%20spinner%5D%20%5Benable%5D%0A>%20%0A>%20If%20the%20password%20is%20correct:%0A>%20%20%20%20Persistence%20%5Bmore%20info%5D%0A>%20%20%20%20%5Booooooooooooooooo.................(xx)%20%5D%20%5Bicon:%20pad%20open%5D%0A>%20%20%20%20(%5Benable%5D%20button%20disappears)%0A>%20%0A>%20If%20the%20password%20is%20wrong:%0A>%20%20%20%20Persistence%20%5Bmore%20info%5D%0A>%20%20%20%20%5Booooooooooooooooo.................(xx)%20%5D%20%5Bicon:%20pad%20closed%5D%20%5Benable%5D%0A>%20wrong%20passphrase,%20type%20again%0A>%20%0A>%20--%20%0A>%20sajolida%0A>%20%0A>%20%0A>%20 "Reply to this message")
