Commit b9e4db03 authored by Tails developers's avatar Tails developers
Browse files

Merge remote branch 'origin/master'

Conflicts:
	wiki/src/blueprint/UEFI/syslinux.mdwn
	wiki/src/doc/get/verify_the_iso_image_using_other_operating_systems.pt.po
parents 1f6486ad c4780c62
......@@ -123,3 +123,5 @@ Miscellaneous test results
"SYSLINUX 4.02 debian-20101014 [..] ifcpu64.c32: not in a COM32R image".
Manually entering `menu_486` or `menu_amd64` bypasses this issue.
See also [[!tails_ticket 7173]]
* Boots fine on Asus Z87 Pro motherboard (Tails 1.1~beta1) off a USB
stick installed with Tails Installer.
......@@ -68,6 +68,11 @@ Other desirable features
- Be able to use that extension to verify other ISO images, testing images,
older ISO images, etc. In that case the user would be warned about the
deprectated or experimental status of the ISO image.
- Be able to use that extension to check the GPG signature. On top of
verifying the checksum, this would provide TOFU authentication. Then, if the
user downloads a genuine app and a genuine key on first use, then she will
be protected from a later compromision of the HTTPS certificate of
tails.boum.org.
Technical insight
=================
......
......@@ -59,7 +59,9 @@ None
# WhisperBack
- `GnuPGInterface`: **no python3 version, unmaintained**
- `GnuPGInterface`: **no python3 version, unmaintained**; replace it
with [Isis's fork](https://github.com/isislovecruft/python-gnupg)?
(ITP: [[!debbug 754120]])
- `gtk`: deprecated, replaced by `python3-gi` and `gir1.2-gtk-3.0`
- `gobject`: deprecated, replaced by `python3-gi`
- `webkit`: deprecated, replaced by `python3-gi` and `gir1.2-webkit-3.0`
......
......@@ -18,109 +18,69 @@ usability-wise.
So, we have to improve the greeter UI to make it more ergonomic and
easier to use.
Design
======
Current proposal
================
Clarify specification
---------------------
It would help a lot to clarify some areas of the greeter
specification. This may involve revisiting a few past decisions:
* Do we still want the first screen to look like a Windows (NT4)
login screen?
* Do we still want a second screen for options? Or another way to
show it?
* Do we want the look to depend on whether the Windows theme was
opted-in?
* How much do we want to optimize for first-time users?
Usability study
---------------
* Draft several User eXperience (and layout) options
* Make them testable
* Make an usability study:
- catch testers (Tails users and/or newbies)
- make them test, see what they do and ask them what they think
We may want to ask input from UX experts, and/or pay one to run the
usability study.
### References
<http://design.canonical.com/2013/08/usability-testing-how-do-we-design-effective-tasks/>
Prototypes
==========
Some proposals to test!
## Goals
After working on a prototype and do UX testing with Numa people, we arrived to
the proposal described here.
My goals for the interface was:
**WARNING**: these complex SVG files are often not well rendered in a browser.
They are thus exported as PNG. If you update the SVG please also update the PNGs.
- read in "natural" order: top to bottom
- no hidden windows/options
- easy to adapt to right-to-left languages RTL
- inspired/similar to GNOME3 "system preferences"
Flow
----
## Screenshots
[[!img greeter-flow.png align="right" size="" alt=""]]
Please test the script below, which lets you try the user experience!
<a href="greeter-flow.svg">source</a>
The greeter started from DVD:
1st screen
----------
[[!img greeter.png align="right" size="" alt=""]]
When started from DVD or freshly installed media:
The greeter started from USB with persistence:
[[!img greeter-1st-screen-dvd.png size="" alt=""]]
[[!img greeter+persistence.png align="right" size="" alt=""]]
<a href="greeter-1st-screen-dvd.svg">source</a>
The greeter started from USB with persistence once language selected:
On a media with a persistent volume:
[[!img greeter+persistence+kbd.png align="right" size="" alt=""]]
[[!img greeter-1st-screen-persistence.png size="" alt=""]]
The greeter once the administration password option clicked:
<a href="greeter-1st-screen-persistence.svg">source</a>
[[!img greeter-opt-adm.png align="right" size="" alt=""]]
On a media with saved language and a persistent volume:
The greeter once the keyboard option clicked:
[[!img greeter-1st-screen-langsaved.png size="" alt=""]]
[[!img greeter-opt-locale.png align="right" size="" alt=""]]
<a href="greeter-1st-screen-langsaved.svg">source</a>
The greeter once the windows camouflage option clicked:
[[!img greeter-opt-persistence.png align="right" size="" alt=""]]
## How to test
Download everything in [[tails-greeter: revamp UI/mockups]], or better clone the git, go to the
directory and:
$ ./mockup.py [-v <variant>] [-p]
Dependencies: gtk3, python gobject introspection (basically debian wheezy)
## Questions
Advanced options
----------------
I'd like to hear about:
[[!img greeter-advanced-screen.png size="" alt=""]]
- your overall impression?
- should keyboard selectable independently from locale in one click?
- your navigation experience?
- where should the locales box be?
<a href="greeter-advanced-screen.svg">source</a>
(Note that some answers were sent on tails-dev already.)
Next steps
==========
## Remarks (add yours!)
Roadmap:
- add a symbol if option was visited/activated
- activation of presets in persistence: when?
* paper UX testing
* share and discuss results and refine SVG mockups
* design user interface graphics
* implement UI in glade and integrate into the greeter
Resources
=========
UI / UX documentation
---------------------
* [GNOME's studies](http://live.gnome.org) on the subject
Related tickets
---------------
......@@ -138,173 +98,4 @@ Past work
* `feature/single_toggle_button` branch in tails-greeter repo
UI / UX documentation
---------------------
* [GNOME's studies](http://live.gnome.org) on the subject
Feedback
========
This is feedback about the *current* greeter.
Report #1
---------
User interface is confusing.
The combination of "green/red icons + the check mark + pushed button" is
really hard to grasp.
How about a big push button labeled "Persistence", maybe with an icon?
The current behaviour for "More options?" is also problematic... How about
having a "More options" button at the bottom, near the "Login" button?
Ideally, this would require a "Back" button on the "Administration
password" scren, but even without it, I think the result will be easier
to understand/use.
> How about using checkmark boxes or Yes/No radial dials, or not use
> them at all? Entering a password into a box means it's enabled, and
> leaving it empty implies you don't wish to use the feature. The text
> in my example here is a bit big though:
[[!img menu.png align="right" size="" alt=""]]
Report #2
---------
A few impressions after the publication of the screenshots. Great job
by the way!
The buttons ON/OFF are sometime confusing, as it's hard to know if it
reflects the actual configuration, or the ability to modify this
configuration, i.e. if the option is *actually* activated or if
clicking on this button will toggle this option ON. I hope I'm clear
enough :)
Please also keep in mind that some use small screens, and can get
blocked if the cannot see the validation button.
Last point, as I will have to use Tails-greeter *at each boot*,
I would like to be able to handle it easily with the keyboard, to save
a lot of time.
That said, thanks a lot for the great job!
Report #3
---------
Indeed, this is a great polishing of the user interface, at least in
terms of appearance. I failed to download anything from the mockups
page though so be aware that this opinion is based on the screenshots
only
I do have some corrections and suggestions though, from the screenshot
it is apparent that it allows to choose "Portugues" (with a eacute) as
a region/locale, which is not! It is a river and neighborhood in Porto
Rico. "Portugues" (with a ecirc) is the correct word for Portuguese in Portuguese.
Now as for if "Should keyboard selectable independently from locale in
one click?", I would say yes as I use it in the current greeter. I do
this for two reason: First in case my tails session gets owned the
attacker will perhaps not know from which country I am though I am
aware in that situation I probably have far worse problems as far as
de-anonimization goes. And second, I am fluent in English, and
I prefer to see the menus and the documentation in English (as are
more complete). Having to scroll down to get the Portugal keyboard in
the current greeter is quite annoying though and I often wonder why
are the other languages more obscure keyboards (like without dead keys
and etc) before the more default options. Perhaps ordering
alphabetically by languages and after all the defaults keyboards then
again the lesser keyboards in this new greeter? (btw why is Portuguese
absent from the locales screenshots?)
A last, but most important imho suggestion: no matter how ergonomic
you can make the greeter it will always have some usability problems,
but there is a way to minimize this! There is already a todo ticket
for choosing language at installation time ( see:
[[!tails_ticket 5501]])
but then if someone got hold of your tails she/he could see from where
you are and what language you speak. Now, if a new feature in the
greeter was implemented - "Greeter Password" (pass-phrase would be
overkill in this case as usability is preferred) - language, locale,
but also camouflage, read only options for persistence, keyboards and
other options to come in the greeter, could be defined at installation
time and accessed at boot time with a few keystrokes from universal
keys in keyboards. Or perhaps you have two greeter configurations and
could setup two passwords.. If you think this feature could be useful
perhaps you could revamp the greeter with this in mind for a future
version? ;)
Okay that's its :) the overall opinion of the greeter from the
screenshots is that you made an amazing job :-) congratulations and
thanks :-)
Report #4
---------
- The clean, fresh design is nice!
- Is "English" preselected? Hopefully the "English" language option is
preselected so the most common use case doesn't require an additional click.
Maybe a little checkmark to the left of the current language could indicate
this. This would let the user know they can skip past this step without
clicking anything more if we have already selected the most common option.
- The on/off rocker switch example is confusing. As others have mentioned,
'off' or 'on' could be interpreted as either the current state or is the action
to be taken when clicked. A possible alternative would be to use radio buttons
and add one more option "Default theme" that is the prechecked radio option. I
would rename the entire panel so just "Camoflage" or "Theme" instead of
specifically "Windows Camoflage". Doing both of these (using radios and
renaming the panel) would also allow for adding another theme like OS X by just
adding a new radio option.
- I might rename "Bridges" to "Tor Bridges" for clarity even on a user's first
use.
Otherwise looks great.
Possible roadmaps
=================
0. **done** Decide what DM and language / UI toolkit we will use for the
greeter in Wheezy
0. **done** Adapt following plans accordingly
0. Gather more input from people who have strong opinions about the
t-g UX: the idea is to encourage work on the greeter by bringing
early positive input rather than late negative feedback.
This should happen in [the dedicated
thread](https://mailman.boum.org/pipermail/tails-dev/2012-October/001781.html).
0. Clarify specifications (see the *Design* section above)
0. research a bit the pending questions
0. raise these topics for discussion among Tails developers
0. Implement plan A or plan B
0. Update documentation
0. Send software and documentation for translation on tails-l10n
Plan A - incremental UI changes
-------------------------------
The idea is to draft a new possible version first, and then we can
decide whether we want to ship it right away, or create other options
and benchmark them through a full-blown usability study.
Alan committed to lots of things in this plan, but not to
any deadline.
0. Ask for ideas
0. Propose one or several prototypes
0. **Next thing to do**: make some testing happen by various kinds of
users
0. Extract something useful from the result
0. Implement the chosen proposal in a dedicated branch of the greeter
repo
Plan B - full UI rewrite with usability study
---------------------------------------------
0. Design and sketch prototypes
0. Organize a usability study
0. Implement the winner idea
*This page is kept as an archive. It contains remarks on a prototype that we
already tested and got feedback for. They are not relevant anymore.*
# Design
## Clarify specification
It would help a lot to clarify some areas of the greeter
specification. This may involve revisiting a few past decisions:
* Do we still want the first screen to look like a Windows (NT4)
login screen?
* Do we still want a second screen for options? Or another way to
show it?
* Do we want the look to depend on whether the Windows theme was
opted-in?
* How much do we want to optimize for first-time users?
## Usability study
* Draft several User eXperience (and layout) options
* Make them testable
* Make an usability study:
- catch testers (Tails users and/or newbies)
- make them test, see what they do and ask them what they think
We may want to ask input from UX experts, and/or pay one to run the
usability study.
## References
<http://design.canonical.com/2013/08/usability-testing-how-do-we-design-effective-tasks/>
# Prototypes
Some proposals to test!
## Goals
My goals for the interface was:
- read in "natural" order: top to bottom
- no hidden windows/options
- easy to adapt to right-to-left languages RTL
- inspired/similar to GNOME3 "system preferences"
## Screenshots
Please test the script below, which lets you try the user experience!
The greeter started from DVD:
[[!img greeter.png align="right" size="" alt=""]]
The greeter started from USB with persistence:
[[!img greeter+persistence.png align="right" size="" alt=""]]
The greeter started from USB with persistence once language selected:
[[!img greeter+persistence+kbd.png align="right" size="" alt=""]]
The greeter once the administration password option clicked:
[[!img greeter-opt-adm.png align="right" size="" alt=""]]
The greeter once the keyboard option clicked:
[[!img greeter-opt-locale.png align="right" size="" alt=""]]
The greeter once the windows camouflage option clicked:
[[!img greeter-opt-persistence.png align="right" size="" alt=""]]
## How to test
Download everything in [[tails-greeter: revamp UI/mockups]], or better clone the git, go to the
directory and:
$ ./mockup.py [-v <variant>] [-p]
Dependencies: gtk3, python gobject introspection (basically debian wheezy)
## Questions
I'd like to hear about:
- your overall impression?
- should keyboard selectable independently from locale in one click?
- your navigation experience?
- where should the locales box be?
(Note that some answers were sent on tails-dev already.)
# Remarks (add yours!)
- add a symbol if option was visited/activated
- activation of presets in persistence: when?
*This is feedback about the current greeter as shipped in Tails 0.X. They do
not show the current state of design.*
Report #1
---------
User interface is confusing.
The combination of "green/red icons + the check mark + pushed button" is
really hard to grasp.
How about a big push button labeled "Persistence", maybe with an icon?
The current behaviour for "More options?" is also problematic... How about
having a "More options" button at the bottom, near the "Login" button?
Ideally, this would require a "Back" button on the "Administration
password" scren, but even without it, I think the result will be easier
to understand/use.
> How about using checkmark boxes or Yes/No radial dials, or not use
> them at all? Entering a password into a box means it's enabled, and
> leaving it empty implies you don't wish to use the feature. The text
> in my example here is a bit big though:
[[!img menu.png align="right" size="" alt=""]]
Report #2
---------
A few impressions after the publication of the screenshots. Great job
by the way!
The buttons ON/OFF are sometime confusing, as it's hard to know if it
reflects the actual configuration, or the ability to modify this
configuration, i.e. if the option is *actually* activated or if
clicking on this button will toggle this option ON. I hope I'm clear
enough :)
Please also keep in mind that some use small screens, and can get
blocked if the cannot see the validation button.
Last point, as I will have to use Tails-greeter *at each boot*,
I would like to be able to handle it easily with the keyboard, to save
a lot of time.
That said, thanks a lot for the great job!
Report #3
---------
Indeed, this is a great polishing of the user interface, at least in
terms of appearance. I failed to download anything from the mockups
page though so be aware that this opinion is based on the screenshots
only
I do have some corrections and suggestions though, from the screenshot
it is apparent that it allows to choose "Portugues" (with a eacute) as
a region/locale, which is not! It is a river and neighborhood in Porto
Rico. "Portugues" (with a ecirc) is the correct word for Portuguese in Portuguese.
Now as for if "Should keyboard selectable independently from locale in
one click?", I would say yes as I use it in the current greeter. I do
this for two reason: First in case my tails session gets owned the
attacker will perhaps not know from which country I am though I am
aware in that situation I probably have far worse problems as far as
de-anonimization goes. And second, I am fluent in English, and
I prefer to see the menus and the documentation in English (as are
more complete). Having to scroll down to get the Portugal keyboard in
the current greeter is quite annoying though and I often wonder why
are the other languages more obscure keyboards (like without dead keys
and etc) before the more default options. Perhaps ordering
alphabetically by languages and after all the defaults keyboards then
again the lesser keyboards in this new greeter? (btw why is Portuguese
absent from the locales screenshots?)
A last, but most important imho suggestion: no matter how ergonomic
you can make the greeter it will always have some usability problems,
but there is a way to minimize this! There is already a todo ticket
for choosing language at installation time ( see:
[[!tails_ticket 5501]])
but then if someone got hold of your tails she/he could see from where
you are and what language you speak. Now, if a new feature in the
greeter was implemented - "Greeter Password" (pass-phrase would be
overkill in this case as usability is preferred) - language, locale,
but also camouflage, read only options for persistence, keyboards and
other options to come in the greeter, could be defined at installation
time and accessed at boot time with a few keystrokes from universal
keys in keyboards. Or perhaps you have two greeter configurations and
could setup two passwords.. If you think this feature could be useful
perhaps you could revamp the greeter with this in mind for a future
version? ;)
Okay that's its :) the overall opinion of the greeter from the
screenshots is that you made an amazing job :-) congratulations and
thanks :-)
Report #4
---------
- The clean, fresh design is nice!
- Is "English" preselected? Hopefully the "English" language option is
preselected so the most common use case doesn't require an additional click.
Maybe a little checkmark to the left of the current language could indicate
this. This would let the user know they can skip past this step without
clicking anything more if we have already selected the most common option.
- The on/off rocker switch example is confusing. As others have mentioned,
'off' or 'on' could be interpreted as either the current state or is the action
to be taken when clicked. A possible alternative would be to use radio buttons
and add one more option "Default theme" that is the prechecked radio option. I
would rename the entire panel so just "Camoflage" or "Theme" instead of
specifically "Windows Camoflage". Doing both of these (using radios and
renaming the panel) would also allow for adding another theme like OS X by just
adding a new radio option.
- I might rename "Bridges" to "Tor Bridges" for clarity even on a user's first
use.
Otherwise looks great.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
version="1.2"
width="451.00049"
height="262.4079"
id="svg3375">
<defs
id="defs3" />
<metadata
id="metadata4">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title></dc:title>
</cc:Work>
</rdf:RDF>
</metadata>
<g
transform="translate(-14.218434,-20.592282)"
id="layer1">
<rect
width="450.32156"
height="261.72467"
x="14.553504"
y="20.928417"
id="rect2985"
style="fill:none;stroke:#000000;stroke-width:0.66648185px;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1" />
<flowRoot
transform="matrix(0.66433109,0,0,0.66433109,170.05553,11.197367)"