Hey,
sajolida@???:
> 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.
This kind of interface is getting quite know, because lot a web services
use it to autosync.
But anyway, maybe it's better to have something to perform to enable, so
the user can feel more the states. On the other end, I really would like
to have a very quick way to start :
- I plug my Tails USB stick
- I write my passphrase
- I click [enter]
>
>> > 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?
I agree with the idea to have an iconic feedback, but maybe :
- the padlock is not
- the icon + text is too heavy
>
> 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]
I think there is no enable at this state. A light gray unclickable
enable maybe.
> If the password is correct:
> Persistence [more info]
> [ooooooooooooooooo.................(xx) ] [icon: pad open]
> ([enable] button disappears)
I think it should be possible to disable at this state.
> If the password is wrong:
> Persistence [more info]
> [ooooooooooooooooo.................(xx) ] [icon: pad closed] [enable]
> wrong passphrase, type again
>
> -- sajolida _______________________________________________ Tails-ux
> mailing list Tails-ux@??? https://mailman.boum.org/listinfo/tails-ux
>
--
tchou
%20%5D%20%5Benable%5D%20<=%20make%20it%20a%20button%0A>%20>>%20>%20rather%20than%20a%20label,%20so%20the%20user%20can%20perform%20himself%20too%20the%20checking%20(I%0A>%20>>%20>%20mean%20there%20is%20the%20autochecking,%20but%20it's%20possible%20to%20click%20too%20to%20check).%0A>%20>%20I%20think%20that%20I%20prefer%20having%20a%20button%20to%20enable.%20I'm%20also%20not%20sure%20about%0A>%20>%20the%20autochecking:%20if%20we%20have%20an%20%22enable%22%20button%20then%20it%20is%20not%20strictly%0A>%20>%20needed,%20and%20I'm%20not%20how%20much%20users%20would%20be%20badly%20surprised%20by%20this.%20So%0A>%20>%20I'm%20thinking%20that%20we%20should%20avoid%20it%20if%20we%20already%20have%20a%20button%20for%20that.%0A>%20%0A>%20This%20kind%20of%20interface%20is%20getting%20quite%20know,%20because%20lot%20a%20web%20services%0A>%20use%20it%20to%20autosync.%0A>%20%0A>%20But%20anyway,%20maybe%20it's%20better%20to%20have%20something%20to%20perform%20to%20enable,%20so%0A>%20the%20user%20can%20feel%20more%20the%20states.%20On%20the%20other%20end,%20I%20really%20would%20like%0A>%20to%20have%20a%20very%20quick%20way%20to%20start%20:%0A>%20-%20I%20plug%20my%20Tails%20USB%20stick%0A>%20-%20I%20write%20my%20passphrase%0A>%20-%20I%20click%20%5Benter%5D%0A>%20%0A>%20>%20%0A>%20>>%20>%20I%20don't%20realy%20know%20if%20we%20must%20write%20the%20state%20(disabled)%20or%20the%20possible%0A>%20>>%20>%20action%20(enable).%20The%20Gnome%203%20toggle%20button%20is%20a%20state%20one%20(off/on)%0A>%20>>%20>%20(http://www.dedoimedo.com/images/computers_years/2011_1/gnome-3-bt-menu.jpg)%0A>%20>%20Yes,%20but%20I%20think%20that%20here%20we%20don't%20need%20a%20toggle%20button%20but%20an%20action%0A>%20>%20button%20%22Enable%22%20(as%20you%20proposed)%20so%20there%20is%20no%20doubt%20on%20terminology%0A>%20>%20for%20me.%20But%20yes,%20it%20would%20be%20good%20to%20have%20a%20visual%20feedback%20about%20the%0A>%20>%20state.%20Then%20what%20about%20reuse%20the%20padlock%20metaphor%20from%20GNOME%20Disks?%0A>%20%0A>%20I%20agree%20with%20the%20idea%20to%20have%20an%20iconic%20feedback,%20but%20maybe%20:%0A>%20-%20the%20padlock%20is%20not%0A>%20-%20the%20icon%20+%20text%20is%20too%20heavy%0A>%20%0A>%20%0A>%20>%20%0A>%20>%20That%20would%20probably%20have%20less%20states:%0A>%20>%20%0A>%20>%20%0A>%20I%20think%20there%20is%20no%20enable%20at%20this%20state.%20A%20light%20gray%20unclickable%0A>%20enable%20maybe.%0A>%20%0A>%20%0A>%20I%20think%20it%20should%20be%20possible%20to%20disable%20at%20this%20state.%0A>%20%0A>%20%0A>%20%0A>%20>%20%0A>%20>%20--%20sajolida%20_______________________________________________%20Tails-ux%0A>%20>%20mailing%20list%20Tails-ux@???%20https://mailman.boum.org/listinfo/tails-ux%0A>%20>%20%0A>%20%0A>%20%0A>%20--%20%0A>%20%20%20tchou%0A>%20%0A>%20 "Répondre à ce message")
