Re: [Tails-ux] Porting DAVE to Web Extensions

Delete this message

Reply to this message
Autor: sajolida
Data:  
Dla: Uzair Farooq
CC: anonym, Tails user experience & user interface design
Temat: Re: [Tails-ux] Porting DAVE to Web Extensions
Uzair Farooq:
>> - Some aspects of the download as done by the current extension would
>> also be affected by Web Extensions, especially the pausing and resuming?
>
> Chrome have support for resume/pause.
>
> If we handle download ourself, we can
> also pause/resume programmatically. One thing to note though, Chrome
> does not allow resume after browser is closed.


Meta: I'm putting Uzair Farooq in explicit copy now. He's the freelancer
interested in porting DAVE to WebExtensions. Welcome Uzair!

Regarding resuming, let's differentiate three scenarios:

- *Pause* -- the user intentionally pauses the download:

- Chrome: works and easy to find
- Firefox: works but harder to find (right-click)
- Tor Browser: works but harder to find (right-click)

- *Interruption* -- the download is interrupted by a network failure:

  - Chrome: doesn't work
  - Firefox: doesn't work without DAVE, should work with DAVE
  - Tor Browser: doesn't work even with DAVE because of:
    https://labs.riseup.net/code/issues/10686


- *Restart* -- the browser is restarted

  - Chrome: doesn't work
  - Firefox: doesn't work without DAVE, works with DAVE
  - Tor Browser: doesn't work even with DAVE because Tor Browser is
    amnesic.


>> - It would be less coding work to decide to remove the download part
> from the extension instead of porting it to Web Extensions and Chrome?
>
> Yeah, without the download it'd be less work.


Ok, that's important as well.

So, merging here the other technical details that anonym and Uzair
exchanged off-list we have to choose between the following two options.

Uzair, please correct me if I get some technicalities wrong!

Option A. Keep the download inside DAVE relying on the File and
Directory Entries API [1] which gives access to a virtual, sandboxed
file system:

  1. DAVE downloads the ISO into the sandboxed file system.
  2. It verifies the ISO.
  3. After the verification succeeds, it asks the user where to save
     the ISO in the real file system.


[1]:
https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API

- Pros:

  - Less UX work and redesign of the web interface. Still, users would
    be asked where to save their download *after* the download finishes
    so some details might change. I haven't thought of this much...
  - Better resume experience *only* when downloads are interrupted by a
    *network failure* on Firefox and Chrome (not Tor Browser):
    - The resume experience is not better than option B when the
      *browser is restarted* because with this API we're in a virtual
      file system only in memory so I understand that it's lost when
      the browser restarts.
    - When people want to *pause and resume manually* we're not
      offering more possibility that the vanilla download. Still, we
      might be able to provide a slightly better UX for Firefox where
      this feature is harder to find.


- Cons:

  - We're downloading in memory so users need ~1GB of RAM to download.
  - We're downloading in memory and don't really know how browsers
    behave with ~1GB in memory.
  - The UX of downloading might be weird if everything happens in a
    sandbox while users expect stuff to happen on their real file
    system.


Option B: We move the download outside of DAVE and rely on the vanilla
download mechanism of the browser.

- Pros:

- Less code at the end in DAVE.
- Less coding work overall when doing the port.
- Probably less code at the end in the web interface.
- We're sure that would work fine.

- Cons:

  - More UX work and more coding work on the web interface:
    - Redesign the steps of DAVE, removing the download.
    - Redesign the workflow of the installation scenarios to force
      people to verify. See [2].
  - Worse resume experience when downloads are interrupted by a network
    failure on Firefox and Chrome (not Tor Browser).


[2]: https://mailman.boum.org/pipermail/tails-ux/2017-May/003385.html

We basically, we have:

- A cool idea (option A) that might or might not work well, would be
more work for Uzair and less work for me and would be nicer in case
of network interruptions.
- A safe bet (option B) that will work, will be more work for me and
less for Uzair and that will degrade a bit the UX on network
interruptions.

I would say we should do option B. But I would like:

- More UX comments on option B.
- More technical review of the implications of option A.
- anonym and Uzair to check carefully what I'm saying here :)