[metrics-team] JavaScript on metrics.torproject.org

tl tl at rat.io
Wed Jan 6 21:30:06 UTC 2016


Hi,

Karsten, Letty and me recently had a conversation about the use of JavaScript on https://metrics.torproject.org. The problem space in brief is that the metrics site needs nice visualizations which need nice interfaces which can profit very much from some nice JavaScript whereas there are a lot of nice people who very reasonably insist on deactivating JavaScript in their nice Tor browsers. So: what to do?
A side aspect of this discussion is that the metrics website needs a technical overhaul. It’s based on some hard to maintain servlet/JSP and while we’re on it we could as well port it to some JavaScript/Node based framework on the server side if we decide to use more JavaScript anywy.
Following are some notes from the discussion.

+

Possible outcomes:
1. Don't require any JavaScript, works without issues in high
security mode.
2. Only require JavaScript for some visualizations where it makes
sense, users will have to switch to medium-high security to watch those.
2b. For visualizations that require JavaScript to be really useful,
provide a simplified version that works without client-side JavaScript.
3. Require JavaScript for most visualizations by first looking at
making them as usable and as useful as possible, rather than worrying
about users having to change their Tor Browser security setting.

Benefits and possibilities of using JavaScript
- Ability to load new data from the server, based on user input,
rather than pre-loading all the data that the user might want to look at.
- Handle user input more directly than via HTML forms which require a
server round-trip.
- Let the user decide whether they want to lower their security in
order to look at a visualization, rather than making that decision for
them.
- It's sufficient to host static content, which can be mirrored much
more easily than dynamic content.

Possible approaches for passing on JavaScript
- Avoid full page reloads by using iframes.
- Investigate more graph frameworks than just D3.js, including
gnuplot, R/ggplot2, others.  A major reason for using D3.js is its
tight integration with user input elements.
- Make heavy use of CSS 3 features/tricks.
- Add tooltips to canvas.

Next steps:
- Find out why the bubble graph takes so long to load.  Try to avoid
the parts that take long in future graphs.
- In addition to the bottom-up approach taken here, also take a
top-down approach by thinking about contents and only worry about
possible implementations later.

Next steps after that:
- Think about possible web frameworks, like Angular.js if we decide
to use JavaScript or Django if we decide against it.
- Look into alternatives to Bootstrap, like Bourbon.io.

+

So far, so unclear. Input welcome!


ciao,
thms
----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/metrics-team/attachments/20160106/7c809838/attachment.sig>


More information about the metrics-team mailing list