[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3590 [Website]: torproject.org/download is very confusing
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs