Bug #11269
Consider linking to /install/download from /install
20%
Description
People are complaining that the IA forces people who only want to download (because they already know how to install) to go through 4-5 pages before getting there. Since we have /install/download, why not add a shortcut from /install to it? I also want to link to it from the release notes.
Subtasks
Related issues
Related to Tails - |
Resolved | 2016-01-29 | |
Related to Tails - |
Resolved | 2016-05-27 | |
Related to Tails - |
Rejected | 2016-05-27 | |
Related to Tails - |
Rejected | 2016-05-27 | |
Has duplicate Tails - |
Duplicate | 2016-04-25 | |
Has duplicate Tails - |
Duplicate | 2016-04-26 |
History
#1 Updated by sajolida 2016-03-21 03:52:04
- Assignee changed from sajolida to tchou
- QA Check set to Ready for QA
- Feature Branch set to web/11269-download-only
#2 Updated by sajolida 2016-04-01 10:39:02
- blocks #8538 added
#3 Updated by Anonymous 2016-04-12 15:00:48
I’d really like to have that link too.
Why not even have a small menu on the bottom of /install/ to all proposed installation methods directly? Instead of needing to click through the second screen? It’s really painful imo.
#4 Updated by sajolida 2016-04-22 05:52:11
> Why not even have a small menu on the bottom of /install/ to all proposed installation methods directly?
Note that there is already a list of direct links to the overviews of
each installation scenarios in /doc. I’m not against a discrete menu on
/install but regular users should be used to go through the
documentation and are likely to find these direct links already.
Newcomers shouldn’t be throw into scenarios without understanding
there’s usage and differences.
#5 Updated by sajolida 2016-04-26 09:34:08
- has duplicate
Bug #11377: Tails Installation Assistant Issue added
#6 Updated by Anonymous 2016-04-27 05:20:37
- has duplicate
Bug #11379: Direct ISO download link added
#7 Updated by Anonymous 2016-04-27 05:42:29
Any news on the review, @tchou?
sajolida wrote:
> > Why not even have a small menu on the bottom of /install/ to all proposed installation methods directly?
>
> Note that there is already a list of direct links to the overviews of
> each installation scenarios in /doc. I’m not against a discrete menu on
> /install but regular users should be used to go through the
> documentation and are likely to find these direct links already.
> Newcomers shouldn’t be throw into scenarios without understanding
> there’s usage and differences.
On top of your proposed change I’d like to suggest to
- add quick links on the first screen of the installer, so we can save one click and delete the second screen.
- in the installation assistant itself consider adding a “Timeline” on top, with clickable items so that we can jump to the last screen directly if we want to, because for example, we already know that installation will take x hours and don’t care reading this twice.
- rename the green button in the sidebar to “Install”
- add the link you added to the install page under this green button too. If you consider it necessary, state on top the download page something like “This is insecure, please consider using installation assistant”.
These modifications would reintroduce a certain flow.
#8 Updated by sajolida 2016-04-28 06:12:16
> * add quick links on the first screen of the installer, so we can save one click and delete the second screen.
Can you clarify with URLs what you mean by “first” and “second” screen?
If the first screen is /install and the second screen is /install/os.
Then deleting /install/os could actually mean merging /install and
/install/os. If that’s your proposal, then please create a separate
ticket to discuss this together with tchou. I’m personally all for it
but don’t want to discuss this further here as it’s off-topic.
> * in the installation assistant itself consider adding a “Timeline” on top, with clickable items so that we can jump to the last screen directly if we want to, because for example, we already know that installation will take x hours and don’t care reading this twice.
On which URL are your proposing this: /install/debian/usb/overview or
/install/debian/usb?
> * rename the green button in the sidebar to “Install”
The button in the sidebar is currently labeled:
Install
Tails 2.3
2016-04-26
So I’m not sure to understand your proposal as it already includes
“install”, but maybe you’re talking about a different button…
> * add the link you added to the install page under this green button too. If you consider it necessary, state on top the download page something like “This is insecure, please consider using installation assistant”.
You mean a link to /install/download below the green button (“Install
Tails” in the sidebar?
#9 Updated by sajolida 2016-05-05 05:01:51
- related to
Bug #11024: Give a direct download link for the ISO image added
#10 Updated by Anonymous 2016-05-27 10:20:26
- related to
Feature #11493: Installation Assistant: please merge /install and /install/os added
#11 Updated by Anonymous 2016-05-27 10:24:45
sajolida wrote:
> > * add quick links on the first screen of the installer, so we can save one click and delete the second screen.
>
> Can you clarify with URLs what you mean by “first” and “second” screen?
> If the first screen is /install and the second screen is /install/os.
That’s what I was referring to. Sorry for not making it clearer.
> Then deleting /install/os could actually mean merging /install and
> /install/os. If that’s your proposal, then please create a separate
> ticket to discuss this together with tchou. I’m personally all for it
> but don’t want to discuss this further here as it’s off-topic.
Created https://labs.riseup.net/code/issues/11493
> > * in the installation assistant itself consider adding a “Timeline” on top, with clickable items so that we can jump to the last screen directly if we want to, because for example, we already know that installation will take x hours and don’t care reading this twice.
>
> On which URL are your proposing this: /install/debian/usb/overview or
> /install/debian/usb?
On all of them: https://tails.boum.org/install/win/index.en.html, https://tails.boum.org/install/mac/index.en.html and https://tails.boum.org/install/debian/index.en.html
Something like step 1 - step 2 - step 3. Where the currently active step is visually distinguishable from the others.
I’ve created a ticket https://labs.riseup.net/code/issues/11495
> > * rename the green button in the sidebar to “Install”
>
> The button in the sidebar is currently labeled:
>
> […]
>
> So I’m not sure to understand your proposal as it already includes
> “install”, but maybe you’re talking about a different button…
Correct. I think i missed this change.
> > * add the link you added to the install page under this green button too. If you consider it necessary, state on top the download page something like “This is insecure, please consider using installation assistant”.
>
> You mean a link to /install/download below the green button (“Install
> Tails” in the sidebar?
Yes, at least a link to https://tails.boum.org/install/download/ and maybe even to https://tails.boum.org/install/download/openpgp/index.en.html
Created https://labs.riseup.net/code/issues/11494 for this.
#12 Updated by Anonymous 2016-05-27 10:27:08
- related to
Feature #11494: Add a direct download link under the Install button in the Tails sidebar added
#13 Updated by Anonymous 2016-05-27 10:32:00
- related to
Feature #11495: JavaScript to provide links to all previous steps in installation assistant added
#14 Updated by Anonymous 2016-05-27 10:32:55
I’ve created discuss-tickets to track all my new proposals.
I hope that this will unblock the fact that this ticket is still waiting for review.
#15 Updated by sajolida 2016-05-27 16:33:55
> On all of them: https://tails.boum.org/install/win/index.en.html, https://tails.boum.org/install/mac/index.en.html and https://tails.boum.org/install/debian/index.en.html
So on all of what we call the “steps” but not on what we call the
“overview”. It makes sense.
> Something like step 1 - step 2 - step 3. Where the currently active step is visually distinguishable from the others.
Right. I agree that this would be an improvement. Still, I don’t
consider it as an important bug enough to fix as part of our contract
with Hivos, so I won’t add it to my plate but will be very excited about
reviewing patches. This sounds like something to be written in
JavaScript, no?
> Yes, at least a link to https://tails.boum.org/install/download/ and maybe even to https://tails.boum.org/install/download/openpgp/index.en.html
I’m afraid that with this proposal we’re over-reacting to the problems
that have been pointed out by regular users until now. Right now,
starting from the homepage, people are 5 screens away from download
(/install, /install/os, /install/win, /install/win/usb/overview,
/install/win/usb). Once we have Bug #11269 and Feature #11493 people will be 2
screens away from download (/install, /install/download). I think that’s
a huge improvement already and I’m not sure being 1 screen away from
download is worth it, especially if it leads more people than expected
to not follow the installation instructions and run into troubles.
So I propose that we don’t do this for now, fix Bug #11024, Bug #11269, and
and also contrast our feelings with stats on hits on
/install/download/openpgp. Doing stats now would be unfair until we
solve the last bits of
#16 Updated by sajolida 2016-05-27 16:53:11
> I hope that this will unblock the fact that this ticket is still waiting for review.
This review is assigned to tchou as I consider it part of our Hivos
contract. But tchou has been missing in action for 4 months now so I’m
starting to wonder whether we should take this over and move forward
without him…
If we end up moving forward without him we will need someone to review
my branch anyway, so maybe you can have a look yourself now and tell me
if you’re happy with my branch to solve this specific issue.
#17 Updated by Anonymous 2016-05-29 21:15:49
Hi sajolida.
I tried to review this and I saw your branch modifications but I fail to build the website. Here is the error I get after having merged current master into your branch:
internal error: download.html cannot be found in wiki/src or underlay
Any idea what that’s about?
#18 Updated by intrigeri 2016-05-30 08:01:39
> internal error: download.html cannot be found in wiki/src or underlay
I think I’ve just fixed that with commit:3a13831.
#19 Updated by SpencerOne 2016-05-31 12:26:45
>
> I’m not sure being 1 screen away from download is worth it
>
The download would be most usable if it appeared on the first screen in the experience.
Unless latency brings some unseen value.
>
> especially if it leads more people than expected to not follow the instructions
>
Forced compliance through dark patterns can degrade the intended experience.
https://tails.boum.org/install/index.en.html would benefit from a direct download link (:
#20 Updated by BitingBird 2016-06-29 05:54:33
- Status changed from Confirmed to In Progress
- % Done changed from 0 to 20
#21 Updated by BitingBird 2016-06-29 05:55:08
- Assignee deleted (
tchou)
Assigning to u. who tried to review it earlier :)
#22 Updated by Anonymous 2016-06-30 02:52:26
- Assignee set to sajolida
- QA Check changed from Ready for QA to Dev Needed
Hi,
i managed to build the wiki now. Thanks.
So, what you’ve implemented improves the situation but it feels a bit like a bad joke unfortunately.
We click on the green button “install Tails” and arrive at the first screen of the installation assistant. There I now see a link to “download only”. but this link brings me to t.b.o/install/download. Where I can’t download only, actually. No, instead I now have the choice between Bittorrent and the FF extension and i can eventually find the small link leading me to “download and verify with PGP”. So 3 clicks again to just download the ISO and Signature. That’s not quite what I or other people had in mind I believe.
I understand that you want to make it harder to make mistakes, but this feels a bit like the invention of keyboard layouts which aimed at wokring with old typing machines where the metal letters should not intersect. Looking at our user base, I think we really need to come up with something better.
My new idea would be:
- in the sidebar under the green button add a link “expert install” to the old ISO/openPGP page.
- and add a link “download only” there too.
- the big green button would still link to the installation assistant.
What do you think?
Oh, and also, this first screen should disappear anyway, so it feels wrong to just add this link there.
#23 Updated by sajolida 2016-07-02 10:19:22
Note that this was assigned to tchou because:
- He is the designer of this and probably wants to have his say on how things evolve.
- This is part of a paid contract.
#24 Updated by sajolida 2016-07-11 10:05:28
First of all, let me say that your review made me quite angry. I took
time to keep calm and answer to it as good as I can.
> So, what you’ve implemented improves the situation but it feels a bit like a bad joke unfortunately.
My work was very serious and absolutely not meant as a joke.
> There I now see a link to “download only”. but this link brings me to t.b.o/install/download. Where I can’t download only, actually.
The title of this ticket is “Consider linking to /install/download from
install” and I did just that. The purpose of the ticket was to allow
people to download an ISO image without going through the installation
instructions, but to me this doesn’t depend on the download method. In
other words, whether you only want to ISO image or whether you want to
learn how to install Tails, the different download methods should be
presented in the same way.
You’re saying “where I can’t download only” while /install/download is
actually about downloading only: I can use two of the three supported
download and verification methods right from this page, though indeed,
the one you are personally interested in, the direct HTTP download with
OpenPGP verification, is still one click away. Also note that Bug #11024 is
still not resolved for people in Firefox with Javascript so the link to
HTTP+OpenPGP is more hidden that what I want it to be (the version
without JavaScript is closer to what I want).
We took for granted while working on this download page that we always
wanted to couple a download technique with a verification method to
discourage unverified downloads. Based on this we decided to provide a
direct download link only as part of the OpenPGP verification (I think
that we decided that during the April meeting). If you want to question
this assumption, feel free to do it but that’s not the purpose of this
ticket.
So we have to present three download and verification methods: DAVE,
BitTorrent, HTTP+OpenPGP. Our assumption was that only a small portion
of our base (maybe 10-20%) would prefer the OpenPGP verification while
the vast majority wouldn’t know OpenPGP and thus prefer DAVE and
BitTorrent (maybe 40-50% each). We structure our design base on this:
HTTP+OpenPGP is small to give it way less importance because it’s
relevant to way less people and completely obscure for anybody who might
otherwise end up there by mistake.
Going back to the statistics I did on the website in May and comparing
the hits on /install/debian/usb (graphical) (20882, 82%) and
/install/expert/usb (openpgp) (4677, 18%), our assumption seems to hold
true: ~20% of people willing to install Tails from Debian or Ubuntu are
ready to do a command line OpenPGP verification. That’s not including
Windows and OS X users for which I expect the percentage to be much lower.
The discussion on how to weigh the different download and verification
combinations is still open to discussion, for example in Bug #11209 and I’m
completely open to proposal. Actually, Bug #11209 is blocking Bug #11024 because
I found it hard to integrate this link in the current layout for Firefox
with JavaScript. Help is welcome. So yes, the link to HTTP+OpenPGP could
be bigger or different, etc. But it’s not the purpose of this ticket
either. And yes, to be frank, I’m going stick with optimizing our design
for people who don’t even know what OpenPGP is about and I don’t even
want them to wonder whether they know what OpenPGP is about. These are
the people that I want to convert to Tails and I expect them to continue
being the vast majority of our user base.
> No, instead I now have the choice between Bittorrent and the FF extension and i can eventually find the small link leading me to “download and verify with PGP”. So 3 clicks again to just download the ISO and Signature. That’s not quite what I or other people had in mind I believe.
> I understand that you want to make it harder to make mistakes, but this feels a bit like the invention of keyboard layouts which aimed at wokring with old typing machines where the metal letters should not intersect.
There are a lot of myths about the design of the qwerty keyboard.
Studies have proven that it’s not as bad for speed as its detractors
pretend (it’s faster than random or alphabetically ordered keyboards)
and that the history of its layout is more complex than “slowing down
the typist not to break the machine”. See for example:
http://repository.kulib.kyoto-u.ac.jp/dspace/bitstream/2433/139379/1/42_161.pdf
> Looking at our user base, I think we really need to come up with
something better.
I think we have a different vision on what our user base is or what it
should be.
> * in the sidebar under the green button add a link “expert install” to the old ISO/openPGP page.
I’m strongly opposed to this.
> * and add a link “download only” there too.
> * the big green button would still link to the installation assistant.
I’m open to changes in the green button and I’m fine with adding a
“Download only” link below it pointing to /install/download, saving
one-click to people who already know how to install.
But I feel like we still don’t agree on some of the basic assumptions
that I’m trying to clarify in this ticket (for example, for whom we are
designing for and whether ISO verification is part of the process or
rather a bonus). And this makes it hard for me to agree on proposals of
concrete changes.
#25 Updated by sajolida 2016-07-11 10:12:46
- Assignee deleted (
sajolida) - QA Check deleted (
Dev Needed) - Type of work changed from End-user documentation to Discuss
In the end it seems like we should choose between this ticket and Feature #11494, as doing both would be duplicate.
#26 Updated by Anonymous 2016-07-11 10:35:35
- Assignee set to sajolida
Sorry if my comments made you angry, that was definitely not the purpose.
Thanks for the clarifications. I do completely understand what you are trying to do, who you are designing for and that you are trying to protect users who don’t even know what GPG is. But we have both types of users and the analysis of the stats in https://mailman.boum.org/pipermail/tails-project/2016-May/000512.html seems to show that too. I think we need to take all of them into account.
#27 Updated by sajolida 2016-07-12 00:19:52
- Status changed from In Progress to Resolved
- Assignee deleted (
sajolida) - Type of work changed from Discuss to Website
I want to take care of all of them of course, but differently. I want to design first for this vast majority who doesn’t know about OpenPGP while also accomodating the ones who do even if the design might not be as good for them. It’s a fundamental concept of design to first know and decide for whom you are designing (the users, their needs and wants) and that you can’t design for everyone — and that you shouldn’t. Even semingly “universal” projects like Windows are not designed for everybody and I personally dislike it (also) because it doesn’t fit my needs. I don’t want Tails to become Windows, I’m just using it as an example here.
I completely agree that our first design of the assistant was too harsh on power geeks and digital activists versed into OpenPGP, which is a minority and a population that can probably live without as much help as the others but it’s also an important share of our user base. And I’m glad that people like you are pushing to fix this for them.
Anyway… so I’m merging this for the time being. If we ever get to do Feature #11494 we can revert this small change.
#28 Updated by Anonymous 2016-07-12 00:37:32
sajolida wrote:
> I want to take care of all of them of course, but differently. I want to design first for this vast majority who doesn’t know about OpenPGP while also accomodating the ones who do even if the design might not be as good for them. It’s a fundamental concept of design to first know and decide for whom you are designing (the users, their needs and wants) and that you can’t design for everyone — and that you shouldn’t. Even semingly “universal” projects like Windows are not designed for everybody and I personally dislike it (also) because it doesn’t fit my needs. I don’t want Tails to become Windows, I’m just using it as an example here.
Understood.
> Anyway… so I’m merging this for the time being. If we ever get to do Feature #11494 we can revert this small change.
Cool :)
#29 Updated by intrigeri 2016-07-12 10:50:03
> Going back to the statistics I did on the website in May and comparing the hits on /install/debian/usb (graphical) (20882, 82) and /install/expert/usb (openpgp) (4677, 18), our assumption seems to hold true: ~20% of people willing to install Tails from Debian or Ubuntu are ready to do a command line OpenPGP verification.
I’d like to nitpick a little bit here, about this usage of statistics, mostly out-of-context since I have not read what this ticket is about recently. My intent is to help us use stats better, and reason + communicate better about them within our team, as a way to improve our shared understanding of what’s happening, and of what we’re creating.
To be able to draw such a conclusion about what our userbase is ready to do from these stats, one needs to make the assumption that the IA is leading everybody to the path that’s the most appropriate for them… which is a big (though perhaps implicit/unspoken?) part of the debates that I’ve seen on this topic in the last 6 months. Chicken’n’egg! :)
In other words, these stats tell as much about what the IA encourages/discourages people to do, than about our user population itself. E.g. these numbers may simply confirm that the current installation assistant is successful at encouraging a great number of people to use non-OpenPGP verification methods, instead of the OpenPGP one (also see the OpenPGP detached signature downloads, that went down from 20-35k/month last year, to 5-10k/month since the release of the IA). I personally believe that the behavioral change we see here is great for the vast majority of our users, but we can’t use these numbers to confirm that we were right to trigger that change: that would be a logical fallacy. See what I mean?
In particular, these stats don’t help us evaluate how many users we’re pushing out of the OpenPGP path, while they would be able to go this way and would benefit from it. My understanding is that this question is a big part of the debate I’ve seen, or at least an important part of the underlying implicit reasons that lead people to disagree with the new design.
#30 Updated by sajolida 2016-07-13 05:24:18
Just to clarify a tiny bit the methodology and logic behind these stats.
These are stats on the share of our visitors who choose “Expert” instead
of “Debian” on /install/debian where the alternative is phrased between
“Install from Debian or Ubuntu” and “Install from Debian and Ubuntu
using the command line and GnuPG” with relatively equal weight on the
screen but, I admit, a slight advantage for /debian over /expert because
it’s displayed first and with a more neutral phrasing).
I expect these stats to reflect the self-reported technical confidence
of our audience (whether they are confident with the GnuPG and the
command line). The stats on /install/{debian,expert}/usb/overview and
/install/{debian,expert}/usb are consistent: ~20%. It doesn’t tell us
about whether they are confident about GnuPG outside of the command line.
So these are not really about which percentage of our user base choose
OpenPGP verification over DAVE or BitTorrent as presented on the
download page (very unequally this time I admit) since the download page
comes later on, during the step-by-step instructions.
> To be able to draw such a conclusion about what our userbase is
> ready to do from these stats, one needs to make the assumption that
> the IA is leading everybody to the path that’s the most appropriate
> for them… which is a big (though perhaps implicit/unspoken?) part of
> the debates that I’ve seen on this topic in the last 6 months.
> Chicken’n’egg! :)
I felt that the hot debate was amongst which verification technique is
favored when downloading the ISO, for example on /install/download.
I used stats on /install/{debian,expert} to be more neutral.
> In other words, these stats tell as much about what the IA
> encourages/discourages people to do, than about our user population
> itself.
Given the logic I described earlier, I don’t think that “as much” is
fair here and I still think that these stats give a good overview of the
self-reported technical confidence of our user base, with definitely a
bias towards less-technical options but a minor one (at least in the
screen we’re talking about).
> In particular, these stats don’t help us evaluate how many users
> we’re pushing out of the OpenPGP path, while they would be able to
> go this way and would benefit from it.
To benefit from the OpenPGP verification, from a security point of view,
you need to go through the WoT. I really don’t think that many Debian
users (since this is the base population for these stats) that would be
able to go this way are pushed out of the OpenPGP path on /install/debian.
#31 Updated by intrigeri 2016-07-13 06:42:37
> Just to clarify a tiny bit the methodology and logic behind these stats. These are stats on the share of our visitors who choose “Expert” instead of “Debian” on /install/debian where the alternative is phrased between “Install from Debian or Ubuntu” and “Install from Debian and Ubuntu using the command line and GnuPG” with relatively equal weight on the screen but, I admit, a slight advantage for /debian over /expert because it’s displayed first and with a more neutral phrasing).
The styling also makes them not that equal to my eye: the non-tiny text is “Install from Debian or Ubuntu” vs. “command line … GnuPG”, and for the latter the text that describes the actual action (“Install from […]”) it is about is displayed so small on my screen that it’s not obvious at first glance that it’s another option to do the same thing.
> I expect these stats to reflect the self-reported technical confidence of our audience (whether they are confident with the GnuPG and the command line). The stats on /install/{debian,expert}/usb/overview and /install/{debian,expert}/usb are consistent: ~20%. It doesn’t tell us about whether they are confident about GnuPG outside of the command line.
> So these are not really about which percentage of our user base choose OpenPGP verification over DAVE or BitTorrent as presented on the download page (very unequally this time I admit) since the download page comes later on, during the step-by-step instructions.
Thanks a lot for clarifying! I understand better then.
>> In other words, these stats tell as much about what the IA encourages/discourages people to do, than about our user population itself.
> Given the logic I described earlier, I don’t think that “as much” is fair here and I still think that these stats give a good overview of the self-reported technical confidence of our user base, with definitely a bias towards less-technical options but a minor one (at least in the screen we’re talking about).
I beg to disagree, but I think I understand much better now why you feel differently about it than I do, and we have better things to do than debating about whether the advantage given to the non-OpenPGP method is “minor”, “slight”, or anything else, so I’ll leave it at that :)
>> In particular, these stats don’t help us evaluate how many users we’re pushing out of the OpenPGP path, while they would be able to go this way and would benefit from it.
> To benefit from the OpenPGP verification, from a security point of view, you need to go through the WoT. I really don’t think that many Debian users (since this is the base population for these stats) that would be able to go this way are pushed out of the OpenPGP path on /install/debian.
I’ll stick to methodology — I’m not willing to enter this debate here and now so I’ll shut up :)