Bit Notes:
> Instead of asking people to write down long url, open page on other device or print it I prepose following:
Thanks for your proposals and sorry for taking a while to answer you.
> Let’s remember all user choices in WA as a binary number.
> Example based on router-sajolida-20150325.odp:
I understand that WA means "web assistant".
> 1) OS select.
> "Windows" choice encoded as "00"
> "Mac" is "01",
> "Debian/Ubuntu" is "10"
> "Other" is "11".
>
> User choses "Mac", we store "01"
I'm not sure to understand what you mean here by "store". Are you
referring to a session cookie or something?
In my current design for URL scheme I use the URL itself to uniquely
identify a step according to the base OS, destination media, etc. Did
you see this already:
https://tails.boum.org/blueprint/bootstrapping/assistant#url
> 2) Dest. media
> "USB" is "0"
> "DVD" is "1"
>
> User choses "USB", we add "0" to "01" and get "010"
>
> 3) Install from scratch, code "1", user number is "0101"
> 4) Don’t have a CD burner, code "1", user number is "01011"
>
> We arrive at the reboot point, and show following message:
>
> You need to reboot and ….
> After you rebooted you should open web assistant and enter the number "11" (that’s "01011" converted into decimal) to continue from where you left off. Please write this number down.
>
> After user enters "11" we can parse it to get original choices.
If I understand correctly, your solution involves a web form and some
code to process the input given by the user to this form. If I
understood correctly, then I think that this has two downsides in
comparison to the currently proposed solution as we would have to:
- Add a question at the beginning of the assistant for people to enter
such number. In the current design we don't have this extra step as we
tell people to write down the direct URL of the step where they need to go.
- Add some backend code to process such a number. We don't like writing
backend code and we try to limit our amount of work as much as possible.
On the other hand, your solution could be implemented with HTTP
redirections (using rewrite rules) to provide shortcuts to the longer
URL scheme that I'm proposing.
> Upsides:
> Very easy for user.
I'm not sure that I would call this "very easy" or "much easier" in
comparison to the currently proposed solution. As the downside of your
solution is that those abstract number are not meaningful: there is no
semantic relation between the number "11" and the fact that you want to
go back to installing Tails on Mac without a DVD burner. On the other
hand, this is made more clear with a URL like /install/mac/usb.
Keep in mind that those URLs are also meant to be:
- Given by frontdesk as an answer to a support request.
- Listed on a sitemap (for frontdesk for example).
But of course they are shorter. We're probably facing a dilemma here and
we need to choose between meaningful URLs (mine) and short URLs (yours).
Note that if we think that it is important to have shorter URLs than
mine, then we can investigate other shorter URLs and use HTTP
redirection as proposed earlier.
We could have for example: /install/mac/usb → /imu or something similar.
> We can collect this numbers at the end of assistant for full statistics if it won't cause privacy issues.
We could already collect logs from the server to know which pages are
visited and from where (through HTTP Referer) and analyze the paths of
the users. I'm not sure how much of those logs are kept by boum.org
(maybe none), but that would be a solution that reuses the
infrastructure of the webserver instead of writing custom code as you
propose.
I haven't written anything about this in the blueprint yet, but that's
definitely something that we want to investigate. While of course,
keeping in mind the possible privacy implications this has.
> We know every user choice at every stage, no need to maintain lots of identical pages with substitutions for media type/OS/etc. We can just create a template for a page and generate versions for all the different OS's/media types/etc. For this optimisations we need to have full understanding of
We are currently thinking about using ikiwiki to implement this set of
pages and we will definitely use some kind of templating mechanism to
avoid duplicating content that is similar amongst all scenarios.
> Downsides:
> Every change in hierarchy will throw off this number to an unexpected page. If this will be implemented as offline documentation this can cause trouble. We could perhaps have version of assistant in number ("1-11"), but this complicates things. Perhaps Q/A hierarchy should be done right for the first time, so we will update only articles without changing hierarchy?
Whenever our URLs are to be interpreted by some code (for example Tails
Upgrader) we put a version number in them, but here I think that it is
OK to consider that people are going to follow the assistant across a
very short period of time, and that they won't be confused if ever we
change the hierarchy of pages once in 6 months from now.
> Not that many possible values for reasonable length of code (13 bits for 4 dec digits). DK if this is enough.
> Concerning statistics and privacy: if the adversary will benefit from such statistics and he has a capabilities of stealing internal system data then it's trivial for him to get same info by counting hits on various pages of wiki. But why we need this stats?
I think that our users can have a legitimate reason to be worried about
us storing too many stats. Because an attacker could still them from us
at some point in time and analyze their history or our users can be
concerned about us profiling them, etc. Still from a usability point of
view, doing stats on the path that users follow on your website can help
us find dead-ends, most requested features, common loops, etc.
--
sajolida
