torproject.org/download is very confusing
The torproject.org/download page is very confusing. Here's a sampling of download pages that are from other projects with lots of options, but a simple download page:
Activity
We agreed today to rework the download page into the following sections:
- clients, this is tor browser bundle for available OSes
- bridges, this is bridge by default bundle for available OSes
- relays, this is relay bundles for available OSes
- source code, this is the source tarball
Trac:
Status: new to acceptedReplying to phobos:
We agreed today to rework the download page into the following sections:
- clients, this is tor browser bundle for available OSes
- bridges, this is bridge by default bundle for available OSes
- relays, this is relay bundles for available OSes
- source code, this is the source tarball
A fine question is how to display this information? in a wizard to ask the user what they want? or to simply only list these 4 choices under each OS section on the download page.
Replying to phobos:
A fine question is how to display this information? in a wizard to ask the user what they want? or to simply only list these 4 choices under each OS section on the download page.
I think it makes more sense to keep the sections by OS. Also, this will make it easier to implement OS detection features per https://trac.torproject.org/projects/tor/ticket/3248
My initial approach to simplifying the page was to format things a bit better, and list only the most stable packages for each OS, with a small link referring the visitor to the appropriate project page or elsewhere for unstable versions. This saves trying to explain the difference between stable and unstable and trims the options down to the most relevant choices for most visitors.
I also used jQuery for OS detection and an accordion menu that automatically opens the appropriate section based on the visitors detected OS, further simplifying the initial choices displayed. If javascript is disabled it just displays all sections, much like the current download page.
Here's a rough preview of everything in action: http://jmtodaro.com/tor/test/download/download.html.en.htm . The layout still needs a bit of work, but it should give an idea of what I have in mind.
Love it? Hate it? Any feedback and/or suggestions are most welcome!
Trac:
Cc: N/A to design@jmtodaro.comI've updated the design a bit:
http://jmtodaro.com/tor/test/download/download.html.en.htm
Looking for some feedback.
Replying to jmtodaro:
I've updated the design a bit:
http://jmtodaro.com/tor/test/download/download.html.en.htm
Looking for some feedback.
The good:
I like the autodetect of OS, and the roll-up of content not related to your OS. I like how with javascript disabled, it defaults to all expanded. I like how the warning isn't hidden, no matter which OS you select.
The not good:
The OS icons are too small. Does the version matter? The (sig) and what's this? links are duplicated by the right-hand side widget box that says "what is the sig link", can we remove the big widget? This would also bring the "having trouble?" box higher or 'into the fold' so to speak. The front page of the torproject.org website uses an icon for tor browser, orbot, tails, etc. Can we re-use those icons as a visual reinforcement?
Replying to phobos:
The not good:
The OS icons are too small. Does the version matter? The (sig) and what's this? links are duplicated by the right-hand side widget box that says "what is the sig link", can we remove the big widget? This would also bring the "having trouble?" box higher or 'into the fold' so to speak. The front page of the torproject.org website uses an icon for tor browser, orbot, tails, etc. Can we re-use those icons as a visual reinforcement?
Sounds good to me, but I do have a few concerns about the following:
I think the version number could matter to existing users who might be checking to see if they are using the most current version? However, it probably doesn't really warrant the level of importance reflected in the current layout. I'll try to work it in a bit better.
And also, yes we could reuse project icons, but what about packages like "Expert Bundle" that don't really have one associated with them? My concern is that it won't really look right in sections with multiple packages, if some packages have visual reinforcement and others don't. Nor do I like the idea of reusing the same icon on multiple packages, such as using the "Tor Browser" icon (or a generic onion, say) on the proposed bridge, relay, & exit bundles. If we have a unique graphic for each package then great, but I don't think it's worth doing otherwise.
I've just uploaded the latest iteration of the page for review at http://jmtodaro.com/tor/test/download/download . This version also supports the selection of localized packages where available (requires javascript).
Replying to jmtodaro:
I've just uploaded the latest iteration of the page for review at http://jmtodaro.com/tor/test/download/download . This version also supports the selection of localized packages where available (requires javascript).
I like this latest version much better. The language selection dropdown is nice as well.
I like it!
The "Download unstable" links don't seem to work for me. I'm not sure if they're meant to work at this stage in the demo.
Also, I wonder if the "Installation Guide for ..." links at the bottom of each section are too well hidden. Ideally we should make packages where users don't need instructions, but we're not there yet. In any case, the instruction pages you link to don't apply to TBB. Perhaps we should move the 'guide' link into the "Vidalia Bundle" part of each section?
Replying to arma:
The "Download unstable" links don't seem to work for me. I'm not sure if they're meant to work at this stage in the demo.
Well, they won't really work until live, because all of the links are relative (and I'm not going to upload the whole site to my host =). But everything should be pointing where it's supposed to now.
Also, I wonder if the "Installation Guide for ..." links at the bottom of each section are too well hidden. Ideally we should make packages where users don't need instructions, but we're not there yet. In any case, the instruction pages you link to don't apply to TBB. Perhaps we should move the 'guide' link into the "Vidalia Bundle" part of each section?
Oh, yeah, you're right. How about this?
http://jmtodaro.com/tor/test/download/download
If all looks good, I'll go ahead and integrate everything into the wml/css and put the patch together.
Replying to jmtodaro:
Replying to arma:
The "Download unstable" links don't seem to work for me. I'm not sure if they're meant to work at this stage in the demo.
Well, they won't really work until live, because all of the links are relative (and I'm not going to upload the whole site to my host =). But everything should be pointing where it's supposed to now.
Also, I wonder if the "Installation Guide for ..." links at the bottom of each section are too well hidden. Ideally we should make packages where users don't need instructions, but we're not there yet. In any case, the instruction pages you link to don't apply to TBB. Perhaps we should move the 'guide' link into the "Vidalia Bundle" part of each section?
Oh, yeah, you're right. How about this?
http://jmtodaro.com/tor/test/download/download
If all looks good, I'll go ahead and integrate everything into the wml/css and put the patch together.
This looks good. Let's go with it and we'll test it live for millions of people.
Can we please include a link on that page that says "Show packages for all operating systems"? I run Linux but often need to find links to or information about packages for other systems. Another option would be to make it more clear that the OS headings at the top of the page are actually links you can click on.
-
Replying to runa:
Can we please include a link on that page that says "Show packages for all operating systems"? I run Linux but often need to find links to or information about packages for other systems. Another option would be to make it more clear that the OS headings at the top of the page are actually links you can click on.
I think you might be a special use case for the download page.
That said, I would welcome some visual trick or cue to make it more obvious that they are headings you can click on. I wonder what would work well.
Replying to arma:
Replying to runa:
Can we please include a link on that page that says "Show packages for all operating systems"? I run Linux but often need to find links to or information about packages for other systems. Another option would be to make it more clear that the OS headings at the top of the page are actually links you can click on.
I think you might be a special use case for the download page.
That said, I would welcome some visual trick or cue to make it more obvious that they are headings you can click on. I wonder what would work well.
A down-arrow symbol near the right end of each bar would help.
How about something like this?
-
https://torproject.org/download/download-easy.html.en includes a link to e.g. https://torproject.org/download/download.html.en#linux
But when I load that page, my browser goes to the #linux anchor, and then my javascript expands the operating system stanza based on autodetecting my OS.
The result is that anchors into the download page don't go to where you intended them to go.
Similarly, check out https://www.torproject.org/download/download.html.en#warning and where it sends you.
Frankly, 'download-easy' in it's current state isn't ready to be set as the default download destination. I recommend we switch back to the new 'all downloads' page until I can take care of https://trac.torproject.org/projects/tor/ticket/3926 .
This is "velope". I provide help-desk support on the #tor channel and have been following development, including the website, very closely for several years. It's great to see improvements in graphic design.
The present download-easy page is indeed ragged, but restoring it and making it the default was definitely the right decision. Only TBB should be listed on the primary landing page for new users. There are lots of packages that need to be listed on the full download page, but new users shouldn't see them, regardless of their platform. There are just too many important but conflicting needs to be met with a single page. Two are definitely necessary.
But the two-page solution raises a design issue. When the aim was for a single page, sectioning by platform and doing the auto accordion was a sensible way of shortening the display. On the download-easy page, obviously there is no need for sections.
Since download-easy addresses the need for a short and simple primary page, the question is whether sectioning by platform on the full page is necessary or helpful. Almost all packages will be available on the top three platforms, so repeating them in three sections complicates maintainence and greatly lengthens the expanded page. The language pulldown menu is great. Why not handle platform selection with a nearby pulldown also?
Sectioning could still serve a simplifying purpose to separate stable versions from others, and the accordion could default to displaying only the section for stable. In reality, there are at least three types of versions that need to be convenient available: stable, alpha, and experimental (or "technology preview"). Perhaps ideally much of this would be moved off to a separate development section of the site, but that seems like a challenge for much later. Also, if an accordion remains, many users would appreciate an "Expand All" button, which needn't consume much space.
A similar issue applies to the download-easy page (#3926 (moved)). There should be no need to have an expanded page with three packages that are identical except for platform. Just a single download button with platform and language pulldowns. Once you have a vertically short layout like that, there's no need for the other visual duplication: the colored warning bar on top.
Replying to cypherpunks:
Since download-easy addresses the need for a short and simple primary page, the question is whether sectioning by platform on the full page is necessary or helpful. Almost all packages will be available on the top three platforms, so repeating them in three sections complicates maintainence and greatly lengthens the expanded page. The language pulldown menu is great. Why not handle platform selection with a nearby pulldown also?
I agree that since the 'all downloads' page is no longer the default, then we should not try to detect the os on it. I also agree that sectioning by package rather than os probably makes more sense in this case. I was not aware that we were going to switch to the 'download-easy' page by default. Had I known I would have built the 'all downloads' page with this in mind.
I would love to use a pulldown for platform selection, but the problem is that this functionality will not work for users without javascript enabled. If we do not care about supporting users without javascript, then it should be quite doable. Alternatively, I can look into a server side solution, but I don't think the page would be any easier to maintain or translate if it is generated with python or whatnot.
Also, if an accordion remains, many users would appreciate an "Expand All" button, which needn't consume much space.
If we agree to re-sort and get rid of os detection on the 'all downloads' page, I don't think the accordion would really be necessary anymore. This really only made sense when it was the default download page.
A similar issue applies to the download-easy page (#3926 (moved)). There should be no need to have an expanded page with three packages that are identical except for platform. Just a single download button with platform and language pulldowns. Once you have a vertically short layout like that, there's no need for the other visual duplication: the colored warning bar on top.
You would only see the expanded version if you do not have javascript enabled. If javascript is enabled then os detection will ensure you see only the one for the detected os. (per the 'javascript-enabled' image). We can do a single section with pulldowns only if a.) we do not care about supporting users without javascript or b.) are willing to implement & maintain a potentially complicated server-side solution.
I'm pretty sure we probably want to keep the colored warning bar on both pages, but I would like to move the full list of warnings to it's own page so it can be linked to from both 'download-easy' & 'all downloads'. No need to duplicate it in both places. We could then maybe use the freed up space on 'download-easy' for a small section linking to alpha and experimental versions?
From velope:
Replying to jmtodaro:
My idea about handling platform selection was founded on handling language selection with a pulldown, as it currently appears on the full download page. Language selection is needed for TBB everywhere and for all packages containing Vidalia. How do you intend to handle language selection when javascript is disabled?
I wish we could require that javascript be enabled, since the idea of torbutton is to make it reasonably safe. But of course new users come to the website without Tor, and the conservative ones could reasonably have it disabled.
Server-side code would require coordination with the mirror sites, which, though underpublicized and underutilized, are an important tool, because the main website is censored.
I wonder whether any further tricks with CSS are possible. Otherwise, if neither of the above requirements can be abandoned, it might be necessary to abandon pulldowns and go back to lots of text links, unfortunately.
Not sure why you say "sectioning by package" for the full download page, since that sounds like one section per download button. I meant sectioning by development branch, i.e. stable, alpha, experimental (not sure of the exact count or terms). An accordion seems optional and perhaps handy for a long list, but it would have to be completely expanded by default, because we must avoid missing out on QA feedback from knowledgeable users because of not noticing the latest packages.
The list of warnings is a critical element that shouldn't be on a separate linked page, I'm sad to say. That material represents the major misunderstandings and dangerous usages of Tor that we deal with every day. The text should be tightened, perhaps with more links to deeper details on other pages, but it probably can never be tiny.
On the current download-easy page, the bottom text "Looking for something else? View All Downloads" seems just about perfect. I don't see any need for "Advanced Choices" to be detailed on this page.
Replying to cypherpunks:
From velope:
Replying to jmtodaro:
My idea about handling platform selection was founded on handling language selection with a pulldown, as it currently appears on the full download page. Language selection is needed for TBB everywhere and for all packages containing Vidalia. How do you intend to handle language selection when javascript is disabled?
Currently I'm handling it by simply not displaying it for users without javascript. All of the translated packages are still available on the TBB project page.
I wish we could require that javascript be enabled, since the idea of torbutton is to make it reasonably safe. But of course new users come to the website without Tor, and the conservative ones could reasonably have it disabled.
I'm certainly open to requiring javascript, as it would simplify my job tremendously. However I am under the impression that we want to retain some level of compatibility with javascript disabled.
Server-side code would require coordination with the mirror sites, which, though underpublicized and underutilized, are an important tool, because the main website is censored.
A server-side solution certainly isn't my favorite option.
I wonder whether any further tricks with CSS are possible. Otherwise, if neither of the above requirements can be abandoned, it might be necessary to abandon pulldowns and go back to lots of text links, unfortunately.
I'm not sure if you are referring to language pulldowns or platform pulldowns here. We didn't link every language on the main download page before, they've always been available on the TBB project page. I added it as an extra feature because I thought it would be helpful, but it was not a requirement.
Not sure why you say "sectioning by package" for the full download page, since that sounds like one section per download button. I meant sectioning by development branch, i.e. stable, alpha, experimental (not sure of the exact count or terms). An accordion seems optional and perhaps handy for a long list, but it would have to be completely expanded by default, because we must avoid missing out on QA feedback from knowledgeable users because of not noticing the latest packages.
By "sectioning by package" I mean instead of Windows, Linux, & Mac sections, we use TBB, Vidalia, & Expert sections (for instance), with the platform-specific versions listed within.
I am in agreement about the accordion; it is only really useful if the 'all downloads' page is the default download page, as I was led to believe it would be.
The list of warnings is a critical element that shouldn't be on a separate linked page, I'm sad to say. That material represents the major misunderstandings and dangerous usages of Tor that we deal with every day. The text should be tightened, perhaps with more links to deeper details on other pages, but it probably can never be tiny.
I disagree, the full list is currently being linked elsewhere from the current semi-broken 'download-easy' page. What's the difference if it is linked to from both pages? Just having it on the page doesn't force the visitor to read it, it just adds to the confusion and clutters up the page. The bright yellow warning at the top of the page should emphasize the critical nature of this information. Those who are interested will click the link to read the full list of warnings. I agree that the full text could be cleaned up & made a bit friendlier, but my opinion is that enough information is there to warrant its own page.
On the current download-easy page, the bottom text "Looking for something else? View All Downloads" seems just about perfect. I don't see any need for "Advanced Choices" to be detailed on this page.
The 'Advanced Choices' currently on the page is a remnant from the last time that page was worked on. That page has existed for some time, but I was told it wasn't ready to go live, so it has not been updated. At all. It has actually been visually broken a bit by the updating of the 'all downloads' page.
That's why I was a bit shocked that we switched to it right after I had just finished making the 'all downloads' page (which was the default download page at the time this ticket was opened) less confusing. This is also why I suggested we go back to the properly working 'all downloads' page as default until I can give 'download-easy' some attention. Please note that 'Advanced Choices' is not included in my mockup here (#3926 (moved)). Any further discussion/suggestions specifically regarding the download-easy page belongs in that thread. I wish we would not have switched to 'download-easy' at least until this ticket (#3590 (moved)) was fully closed.
Replying to jmtodaro:
I sympathize with your discomfort at having the download-easy page abruptly restored as the default. I always believed it should be so, and said so, but was not part of the decision process. Again, despite the current awkwardness, it's the right basic idea and needs to be there while things are being worked out.
First looking at just languages, there are translated packages not just for TBB but also for anything that has Vidalia. So the pulldown issue applies to lots of packages on both pages.
I don't believe it's acceptable to force any users to supplemental pages for any package, so both languages and platforms need to be accommodated directly. Nor does it seem a good idea to have to maintain lists of packages on more than two pages. If the two pages are done right, there should be no need for listing packages on the TBB project page. But doing so has been a necessity for Erinn while the rest is in upheaval.
For javascript users, the full page would indeed be better with pulldowns for both language and platform, so there would be no need to duplicate the listings per platform. For non-javascript users, the pulldowns can be suppressed and a table of text links for the platform X language matrix displayed instead. Not pretty, but it would be only backup functionality for those users and would still avoid the need to maintain and list distinct packages by platform that don't provide any different functionality.
I appreciate the fact that the warnings are long and duplicated but remain uncomfortable requiring users to click to see them. It's almost certain that they aren't “interested” in them. Unfortunately some inconvenient education is a requirement. For me this is a secondary issue on these pages; to others it might be more critical.
velope quoting from irc:
armadev: velope: wonder if the download page vidalia download button wants a language pull-down like tbb has velope: the pull-downs are exactly the issue. velope: they rely on javascript to munge paths. armadev: ah velope: _if_ pulldowns can be used, they should also be able to be used for selecting platform, which vastly shortens and simplifies the pages. armadev: so no non-english for you unless your javascript is on and you know where to look velope: if they cannot be used, the concise buttons and pulldowns have to get verbose again, or non-english non-javascript users have to be shunted off to some other page, which seems terrible. rransom__: Put the long list of links to packages for each language in a <noscript> tag? velope: plausible. one complication is that it would be great to get rid of the repetitive platform entries, but that introduces a platform X language multiplier. rransom__: The packages could be listed in a table, with platforms as columns and languages as rows. armadev: can the download link be a form/cgi that 302's you to the real download link, with a pulldown bar nearby to pick a language that gets POSTed to the form? rransom__: weasel won't like CGI. armadev: well, a form rransom__: Something has to turn the values in the form into a URL. That can either be JavaScript on the client or some program on the server. rransom__: Relying on a program running on the web servers makes mirroring www.tpo more difficult and much more dangerous. velope: look, if you relax either or both of the requirements that cgi can't be used and javascript can be disabled, solutions become easy. velope: but with those requirements upheld, it looks like we can't implement the new nice graphics, at least no without having some large backup table like rransom__ mentions. armadev: velope: i am inclined to think that needing javascript to pick a different language is ok. i fear that a table would be horrible to use and look at. velope: armadev: ok, that would be a major break in the logjam. now how about javascript for selecting platform? having a platform pulldown would greatly simplify the full download page. or perhaps a compromise--don't require javascript on the tbb download-easy page (for new users), where the expansion is minor. armadev: velope: what would it mean if you don't have javascript? you can't see some platforms? velope: well that's what we're mulling over. on the tbb download-easy page, with no javascript it's reasonable to display three buttons as shown in jeremy's draft. velope: but for the full download page, jeremy agrees that it doesn't make sense to section by platform, which lengthens the page (experimental packages haven't even been accommodated yet). velope: so the full download page could be greatly condensed by using pulldowns for both language and platform, but, if no javascript, that means either no platform choice or substituting a table of links. velope: --a table of links providing the platform X language matrix. velope: (i'm still wondering if the javascript-just-for-the-sake-of-pulldowns challenge could be worked around with some CSS trick, but i don't know yet.) rransom__: You *can* do pulldowns with CSS only, but it's a PITA, and you can only put a list of links on each pulldown. rransom__: I think the big ugly table would be less bad. velope: perhaps acceptable if it only appears as a no-javascript backup armadev: i'd be more fine with thatFor javascript users, the full page would indeed be better with pulldowns for both language and platform, so there would be no need to duplicate the listings per platform. For non-javascript users, the pulldowns can be suppressed and a table of text links for the platform X language matrix displayed instead. Not pretty, but it would be only backup functionality for those users and would still avoid the need to maintain and list distinct packages by platform that don't provide any different functionality.
This sounds like a reasonable solution to me. I particularly like rransom's suggestion: "The packages could be listed in a table, with platforms as columns and languages as rows."
However, this would not avoid the need to maintain the full list, as even though it isn't always displayed, it will still exist within the page and be displayed under certain circumstances. We would actually need to maintain both the table layout and the javascript code controlling the dropdown menus. I think I can minimize this maintenance with efficient usage of the wml 'define-tag' and/or includes. But addition/removal of packages, etc. will need to be manually done in both areas.
If we want to keep maintenance the simplest, we should consider just a straight table based layout for the full page. Seeing as how it isn't the primary download page any longer, the need to make it pretty is less important in my opinion. Also, the scary, million package, table-based listing could be a good thing in a way, as it will encourage the less knowledgeable folks to just use TBB.
As for the proposed primary download page (download-easy), I still think that the way my current draft is intended to function will be the way to go. If javascript is disabled, we can simply display an 'Other Languages' link that goes to the relevant section on the proposed full page (with packages organized into tables) instead of the dropdown.
I appreciate the fact that the warnings are long and duplicated but remain uncomfortable requiring users to click to see them. It's almost certain that they aren't “interested” in them. Unfortunately some inconvenient education is a requirement. For me this is a secondary issue on these pages; to others it might be more critical.
I stand by my opinion on this matter. However, I agree to go with whatever the general consensus may be.
From velope:
Replying to 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.”
I find this comical, as we used to have a big table, sorted by package, and we tried sorted by OS. It was completely confusing and few understood it without staring at it for 20 minutes. it's the reason download-easy was originally created. Maybe we can improve it with UI treatments, or maybe we just need one omnibus package that does it all and prompts the user on first extract what they want to be in life (client, exit relay, bridge, etc).
From velope:
Replying to phobos:
An omnibus package is a fine idea that deserves its own enhancement ticket, but it does nothing to move the website forward in any realistic timeframe.
It's good to hear additional rationale and support for the download-easy page.
The fundamental cause of confusion with earlier full-download pages was simply that there were too many links in total (platform X language X signature) for any organizing approach to completely succeed. What's different now is that javascript pulldowns can visually collapse the matrix so that the eye doesn't get so lost. We suppose that non-javascript users will be in a small minority, but sub-tables by package are needed to support them. Good design has a chance of minimizing their confusion.
By the way, in case it isn't clear from the previous discussion, when I say "package" I mean, for example, that the stable bridge-by-default bundle, the unstable bridge-by-default bundle, and the experimental bridge-by-default bundle are three separate packages, each with their own main entry and each with their own non-javascript table. In other words, I don't believe the current approach of adding an 'unstable' link to the stable entry is workable. Logically there could be an additional pulldown for stable/unstable/experimental, but the corresponding non-javascript table would be horrendous or impossible. Also, we don't want users accidentally downloading a package that appears to run on their platform but is wrong for them, and at the same time the other-than-stable packages need to be very visible for their target audience. That's why the top-level sectioning should be by stable/unstable/experimental. (And if eventually there is a split onto a third page, one or more of those sections are what would be split off.)
The current state of the pages is an important step forward, but clearly significant work remains to get them fully functional, usable, and attractive. I have a repository that builds the website and am willing to help with the WML guts, but I don't want to conflict with other development or go in an unfavored direction. In that regard, knowledgeable and specific feedback and guidance would facilitate accomplishing more.
mentioned in issue #3593 (moved)
moved to tpo/web/trac#3590 (closed)
mentioned in issue tpo/web/trac#3593 (closed)