Susan:
> I agree that the lock should show the state.
I'm attaching to this mail four new mockups. I made them with Glade, the
software to create Gtk interfaces, so they use the actual widgets,
colors, fonts, etc. Still, It was my first time with Glade and I had
problems with images so for example the (?) link is smaller than what it
should be.
Susan: do you think that this is enough in terms of contrast or do you
still think that we should do something different that what's provided
by Gtk by default? Like using bold as you suggested.
> I suggest testing by asking users to explain whether it is locked or
> unlocked to make sure there isn't any ambiguity. "What will happen
> when you press that button?"
>
> My earlier comment about encrypted storage being locked or unlocked
> is In regard to the technically naive concept of encrypted = locked.
> So an unlocked encrypted container might not make much sense for some
> people.
I understand what you mean here and I never thought about it this way
before, so sharing your mental model is very precious. The way I see it
is is more like a treasure chest with a lock on it:
http://vignette1.wikia.nocookie.net/clubpenguin/images/4/4b/Treasure_Chest_Costume_icon.png/revision/latest/scale-to-width-down/500?cb=20120517150232
When you unlock the chest, you can access the treasure (the data) but
the treasure is still in the chest. Here, when you unlock the encrypted
storage, the data is not really decrypted (as in "copied elsewhere in a
decrypted form"): it's still encrypted on the USB stick but you can
access it while Tails is running because you opened the lock.
So for example, I don't think we want the user to believe that their
data has been decrypted. And we thought that the lock metaphor would
help. But maybe there are things that could be improved to transmit this
better.
> However, I prefer the alternative you chose of putting the lock state
> on the button with the text label, provided it tests well with users.
> If it is confusing, then moving the lock off the button would be the
> next thing to try.
>
> The lock by itself on the button would be ambiguous, but next to that
> strong label I think it could work. Testing it with users is the only
> way to be sure.
As you can see, in the new mockups I tried both: having the icon inside
and outside the buttons. The "inside" version looks nicer but the
"outside" version is probably less ambiguous.
I also made the labels of the buttons shorter because I don't think that
the longer version is helping here.
Spencer, would you be up to printing these and testing them quickly with
different people?
%20link%20is%20smaller%20than%20what%20it%0A>%20should%20be.%0A>%20%0A>%20Susan:%20do%20you%20think%20that%20this%20is%20enough%20in%20terms%20of%20contrast%20or%20do%20you%0A>%20still%20think%20that%20we%20should%20do%20something%20different%20that%20what's%20provided%0A>%20by%20Gtk%20by%20default?%20Like%20using%20bold%20as%20you%20suggested.%0A>%20%0A>%20>%20I%20suggest%20testing%20by%20asking%20users%20to%20explain%20whether%20it%20is%20locked%20or%0A>%20>%20unlocked%20to%20make%20sure%20there%20isn't%20any%20ambiguity.%20%22What%20will%20happen%0A>%20>%20when%20you%20press%20that%20button?%22%0A>%20>%0A>%20>%20My%20earlier%20comment%20about%20encrypted%20storage%20being%20locked%20or%20unlocked%0A>%20>%20is%20In%20regard%20to%20the%20technically%20naive%20concept%20of%20encrypted%20=%20locked.%0A>%20>%20So%20an%20unlocked%20encrypted%20container%20might%20not%20make%20much%20sense%20for%20some%0A>%20>%20people.%0A>%20%0A>%20I%20understand%20what%20you%20mean%20here%20and%20I%20never%20thought%20about%20it%20this%20way%0A>%20before,%20so%20sharing%20your%20mental%20model%20is%20very%20precious.%20The%20way%20I%20see%20it%0A>%20is%20is%20more%20like%20a%20treasure%20chest%20with%20a%20lock%20on%20it:%0A>%20%0A>%20http://vignette1.wikia.nocookie.net/clubpenguin/images/4/4b/Treasure_Chest_Costume_icon.png/revision/latest/scale-to-width-down/500?cb=20120517150232%0A>%20%0A>%20When%20you%20unlock%20the%20chest,%20you%20can%20access%20the%20treasure%20(the%20data)%20but%0A>%20the%20treasure%20is%20still%20in%20the%20chest.%20Here,%20when%20you%20unlock%20the%20encrypted%0A>%20storage,%20the%20data%20is%20not%20really%20decrypted%20(as%20in%20%22copied%20elsewhere%20in%20a%0A>%20decrypted%20form%22):%20it's%20still%20encrypted%20on%20the%20USB%20stick%20but%20you%20can%0A>%20access%20it%20while%20Tails%20is%20running%20because%20you%20opened%20the%20lock.%0A>%20%0A>%20So%20for%20example,%20I%20don't%20think%20we%20want%20the%20user%20to%20believe%20that%20their%0A>%20data%20has%20been%20decrypted.%20And%20we%20thought%20that%20the%20lock%20metaphor%20would%0A>%20help.%20But%20maybe%20there%20are%20things%20that%20could%20be%20improved%20to%20transmit%20this%0A>%20better.%0A>%20%0A>%20>%20However,%20I%20prefer%20the%20alternative%20you%20chose%20of%20putting%20the%20lock%20state%0A>%20>%20on%20the%20button%20with%20the%20text%20label,%20provided%20it%20tests%20well%20with%20users.%0A>%20>%20If%20it%20is%20confusing,%20then%20moving%20the%20lock%20off%20the%20button%20would%20be%20the%0A>%20>%20next%20thing%20to%20try.%0A>%20>%0A>%20>%20The%20lock%20by%20itself%20on%20the%20button%20would%20be%20ambiguous,%20but%20next%20to%20that%0A>%20>%20strong%20label%20I%20think%20it%20could%20work.%20Testing%20it%20with%20users%20is%20the%20only%0A>%20>%20way%20to%20be%20sure.%0A>%20%0A>%20As%20you%20can%20see,%20in%20the%20new%20mockups%20I%20tried%20both:%20having%20the%20icon%20inside%0A>%20and%20outside%20the%20buttons.%20The%20%22inside%22%20version%20looks%20nicer%20but%20the%0A>%20%22outside%22%20version%20is%20probably%20less%20ambiguous.%0A>%20%0A>%20I%20also%20made%20the%20labels%20of%20the%20buttons%20shorter%20because%20I%20don't%20think%20that%0A>%20the%20longer%20version%20is%20helping%20here.%0A>%20%0A>%20Spencer,%20would%20you%20be%20up%20to%20printing%20these%20and%20testing%20them%20quickly%20with%0A>%20different%20people?%0A>%20 "Reply to this message"){kind=icon}
