[tor-bugs] #3590 [Website]: torproject.org/download is very confusing

[Tor Bug Tracker & Wiki]

#3590: torproject.org/download is very confusing
-------------------------+--------------------------------------------------
 Reporter:  cypherpunks  |          Owner:  phobos  
     Type:  defect       |         Status:  accepted
 Priority:  normal       |      Milestone:          
Component:  Website      |        Version:          
 Keywords:               |         Parent:          
   Points:               |   Actualpoints:          
-------------------------+--------------------------------------------------

Comment(by cypherpunks):

 From velope:

 Replying to [comment:29 jmtodaro]:

 Looks like good ideas are beginning to flow in the same direction. We
 might get out of these woods yet!

 With javascript disabled, indeed a table of links seems to be the only
 reasonable way to statically present the platform/language matrix. I
 envision a table organized like the abbreviated example below, based on
 text from the TBB project page. (As a side note, there is a current
 discussion about providing SHA-1 checksums in addition to GPG signatures,
 so in the future there might actually be three links for each
 platform/language combination.)

 ||LANGUAGE||WINDOWS||APPLE||LINUX||
 || || || || ||
 ||English||(en-US) (sig)||(en-US) (sig)||(en-US) (sig)||
 || || || || ||
 ||Deutsch||(de) (sig)||(de) (sig)||(de) (sig)||
 || || || || ||
 ||Vietnamese||(vi) (sig)||(vi) (sig)||(vi) (sig)||

 The current effort to reduce the number of standard packages may succeed
 in a narrow sense, but for various internal and external causes, the
 actual number of packages that need to be listed shows no sign of going
 down, and more need to be added to the current page. Certainly not all
 users coming to this page will be experts accustomed to lots of
 complexity. For example, the relay and bridge bundles are targetted at
 nonexperts who are interested in helping to grow the network. Therefore it
 is very much worthwhile to implement the javascript pulldowns and continue
 to push for a page as attractive and compact as possible.

 With javascript enabled, a translated package would appear similar to the
 TBB button in the current version, except that in addition to the language
 pulldown, right next to it would be a platform pulldown, with both
 pulldowns defaulting to the detected values. The signature link will have
 to be moved, and javascript will have to modify its pathname value
 according to the selected platform and language (that is, appending
 “.asc”).

 As for maintenance, we should definitely utilize the strengths of WML.
 Even if developers are maintaining the page, markup in frequently edited
 text should be minimized, to improve readability and avoid breakage. WML
 tags are one mechanism. Embedded Perl can be great at generating
 repeating, parameterized patterns. Actually, all the per-package details
 could be captured in literal Perl data that an out-of-the-way function
 could read in order to generate the markup, so the maintainer would only
 have to copy-and-paste and edit the literal data. For the sake of the
 translators, it is helpful to keep the majority of translatable strings
 positioned close together in the source files. Obviously this constraint
 is already violated with the versions.wmi and lang.wmi files, but we
 should try to follow this wherever possible.

 When a particular package is released, sometimes not all the platforms can
 be made available at the same time, so it must be possible to customize
 the set of platforms. A similar situation holds for languages, but all the
 non-English languages can be handled as an invariant group: if
 translations are available for a package, the same set of languages are
 available on all platforms.

 Your idea of redirecting non-javascript users from the download-easy page
 to the full download page with tables sounds reasonable. However, please
 note that both pages need to list additional TBB packages now or in the
 near future (all designed for new users). First, the TOR IM Browser Bundle
 will likely be reinstated (definitely for Windows only), to include
 everything in the regular browser bundle plus a custom-built Pidgin app.
 Second, multiple-file split versions of the other packages are available,
 at a minimum for Windows, and probably for at least one other platform as
 well. These are to accommodate users with poor Internet connections and
 also for working around filesize limitations when emailing from the GetTor
 system. See the existing torbrowser-split project page. It would be
 advisable to coordinate with Erinn on these items. If all cannot be
 achieved in the current phase of work, it would be great to design so as
 to accommodate them in the near future.

 I respect your keeping to the high road of design with the warnings issue.
 I don't wish to debate it endlessly, and it's not my decision to make, but
 allow me to speak bluntly and approach it from another angle. There is
 unlikely to be a “general consensus” on this point (or any other here).
 Those warnings have grown like weeds over time because of very real and
 potentially dangerous situations that arise in supporting users. If the
 warnings are moved off to a secondary page, the next time that similar
 situations become prominent incidents, somebody who ignored this
 discussion will say, “Whoa! Why aren't we taking every possible step to
 keep those warnings directly under the noses of ignorant users?” And they
 will be moved back. This has nothing to do with me personally. As a
 contributor, there are at least two anticipatory responses you can have to
 this scenario. One is: “I'm making the right design decision, and if they
 want to screw it up and make it ugly later, it's not my problem.” Another
 is, “If that's probably going to happen anyway, I'll make it look as least
 ugly as possible now.”

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3590#comment:30>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online