Closed Bug 222514 Opened 18 years ago Closed 16 years ago

download page

Categories

(www.mozilla.org :: General, defect, P2)

Product:
www.mozilla.org
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: endico, Assigned: fantasai.bugs)

References

(
URL
)

Details

(Keywords: helpwanted)

Attachments

(1 file)

the template referenced in comment 18
7.56 KB, text/plain
Details 
why are download and 'products' separate?

create a better download page. more terse than /products.html
Priority: -- → P2
You didn't even specify what page you're referring to.
Hmm... maybe Endico was talking about the Download | Products | Support |
Developers | About Mozilla nav links.
URL: http://website-beta.mozilla.org/produ...
Also, the Downloads page should link to the Releases page for older versions
such as 1.4.1 and 1.0.1 for Macintosh 9, and to the localized downloads.


And also let's link to the /mirrors/index.html from somewhere on the downloads page.
The last stable build for Mac OS Classic is
http://www.mozilla.org/releases/mozilla1.0.2.html The beta site links
incorrectly to 1.0.2.

And what's up with "stable" builds? Ben removed 1.4.1 from the front page of the
Classic site. And the Beta site makes no reference to it. I mailed Ben about
this and haven't got a reply. I demand an answer about this from mozilla.org.
What about redesigning http://mozilla.org/download.html ?
For five years (if memory serves) we've had /download.html -- why shouldn't we
just modernize the look of that page, regularize the structure undre
products/*/releases/ or whatever that its links point to, and get on with our
lives?  The advantage of linking to existing products/*/releases/ files is that
it lets various product owners update only one file to document their new release.

Making yet another top-level directory /download that contains only an
index.html page that links off to whereever doesn't do anything except add to
the directory-to-regular-file ratio, uselessly.

So maybe we can use the graphic design from
/products/mozilla1.x/download/index.html (which was created in the initial new
website push, and which describes only mozilla1.5 download).

Daniel Wang: mozilla1.5 is our latest quarterly stable release; mozilla1.4.1 is
the latest release off the MOZILLA_1_4_BRANCH "stability branch", which we have
made about once a year.  We support vendors making incremental releases off this
"long-lived" branch, but we promote our latest quarterly stable release to end
users.  Different vendors have different risk/feature tradeoffs, but we believe
that our end users are best-served by getting something more recent than 1.4.x.

/be
I think that's a great starting point.  But note that we do need to massage some of this 
content.  For instance, it's a real fishing expedition to find Mozilla 1.5 from the current 
download.html page(click on Mozilla > click on binary > click on milestone > find Mozilla 
1.5 for the correct platform).

I propose that we do this:
- start with /products/index.html
- delete the Firebird and Thunderbird ad boxes on the right
- delete the bugzilla ad box below Mozilla 1.5
- put the content of /download.html into the All Mozilla Products listing

/bd


Let's make sure to include links to localized versions on this page as well.
we need to have a clearly marked link to a Mac OS 9 download right there on the
download page.


Bart: mozilla dropped OS9 support as of 1.2, IIRC.

/be
Priority: P2 → P1
fixed on branch.

modernized /download.html and changed download link in top nav bar.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
we still need links to localizations and other platforms for each product.  we
can do this after the launch, but it's a high-priority item.

also, the page needs some CSS lovin' so the content will stretch.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
dbaron just checked in fix to make the page stretch
Endico, can you link to
http://www.mozilla.org/docs/end-user/guide/get-started.html ?

"Award Winning Internet Application Suite" link is misleading because it links
"up" instead to an actual award page. If you want to link up, consider a
"product feature" link.

"Includes: browser, e-mail, addressbook, and an HTML editor" <-- Mozilla
includes e-mail? try "mail client"

Endico, how do we make intl pages? Do we put up files like "french.fr" and just
link to it?
URL: http://website-beta.mozilla.org/produ... → http://website-beta.mozilla.org/produ...
Priority: P1 → P2
If English is filename.html,
French should be filename.fr.html
And yes, just link to it; proper content negotiation is blocked by bug 222370
QA Contact: imajes → stolenclover
Hijacking this bug.

Proposed replacement:
  http://mozilla.inkedblade.net/cgi-bin/download
Source code:
  http://mozilla.inkedblade.net/cgi-bin/download-source

I'm still working on it, mind; I've yet to load in data back to the last MacOS9
release.
Assignee: endico → fantasai
URL: http://website-beta.mozilla.org/produ... → http://www.mozilla.org/products/mozil...
Status: REOPENED → NEW
OS: MacOS X → All
Hardware: Macintosh → All
Ok, Myk, it's almost successfully using the Template Toolkit.
Here's the template source:
  http://mozilla.inkedblade.net/cgi-bin/template-source

The only problem I'm running into is that the wrapper script moves the [%BLOCK
wrapper%] directive into the body, leaving the [%pagetitle%] stranded. So the
title of the page is always blank. I can just give it a constant text "Download
Mozilla" if necessary, though.

I haven't yet loaded in the 1.6 data, but I thought I'd post this sooner so you
can review things earlier if you want.
Comment on attachment 140111 [details]
the template referenced in comment 18

Haven't looked at the Perl script yet, but here's my review of the template...

>The only problem I'm running into is that the wrapper script moves the [%BLOCK
>wrapper%] directive into the body, leaving the [%pagetitle%] stranded. So the
>title of the page is always blank. I can just give it a constant text "Download
>Mozilla" if necessary, though.

That's probably ok, but we should figure out some way of fixing this in the
long run.  A quick hack may be to put another case statement into the header
that generates the appropriate page title.



>[%BLOCK wrapper%]

Put spaces between TT directive delimiters and the directives to make them more
readable, i.e. [% foo %], not [%foo%]



> <title>
> [%pagetitle%]
> </title>

Nit: pagetitle -> title (You don't use titles elsewhere in the template, so
"title" is unambiguous enough).



>[%BLOCK platformlisting%]

Nit: platform_listing



>[%BLOCK platformlisting%]
>
>      <div class="section">
>      <h2>Mozilla [%versions.$latest%] (Latest for [%platforms.$platform%])</h2>
>        <ul>
>    [%FOREACH lang = langlist%]
>        <li><a href="[%ENV.SCRIPT_NAME%]?platform=[%platform%]&language=[%lang%]">[%languages.$lang%]</a>
>    [%END%]
>        </ul>
>      </div>

Nit: use two-space indent of all hierarchies (HTML, TT, and mixed) in template
files for better readability, i.e.:

[%BLOCK platformlisting%]
  <div class="section">
    <h2>Mozilla [%versions.$latest%] (Latest for [%platforms.$platform%])</h2>
    <ul>
      [%FOREACH lang = langlist%]
	<li><a
href="[%ENV.SCRIPT_NAME%]?platform=[%platform%]&language=[%lang%]">[%languages.
$lang%]</a>
      [%END%]
    </ul>
  </div>



>            <th>Platform</th>
>            <td><select name="platform">
>                  <optgroup>
>                    <option value="win32" [% 'selected' IF 'win32' == os %]>Microsoft Windows

Why have a single labelless optgroup?

Nit: use closing </option> tags.

Nit: put variables before literals in equivalence conditionals (i.e. "os ==
'win32'" not "'win32' = os").

Instead of duplicating platform data in the template, use the data from the
platforms hash, i.e.:

[% FOREACH key = platforms.keys %]
  <option value="[% key %]" [% 'selected' IF os = key %]>[% platforms.$key
%]</option>
[% END %]



>  [%
>    pagetitle = 'Download Mozilla'
>    heading = 'Download Mozilla'
>  %]
>  [%WRAPPER wrapper%]

This would be simpler as:

  [% WRAPPER wrapper
      pagetitle = "Download Mozilla"
      heading = pagetitle %]

Even simpler, enclose the entire SWITCH statement in the wrapper, since every
possible outcome gets wrapped, i.e.:

[% WRAPPER wrapper %]
  [%SWITCH return%]
    [%CASE 'form'%]
      [% pagetitle = "Download Mozilla"
	 heading = pagetitle %]
      <p>Download this award winning Internet application suite.
      Includes: browser, mail client, addressbook, and HTML editor</p>

Nit: heading -> header



>            <td><select name="language">
>                  <option value="en-US">English (US)
>              [%- FOREACH lang = langlist -%]
>                [%UNLESS 'en-US' == lang%]
>                  <option value="[%lang%]">[%languages.$lang%]
>                [%END%]
>              [%- END -%]
>                </select>

Instead of using chomp to remove whitespace, use closing </option> tags to
delimit option labels so that the whitespace generated by the template code
doesn't matter.  HTML is pretty good at dealing with whitespace given the
judicial use of tags, so TT chomping should be reserved for cases where HTML is
insufficient.

Also, this isn't working for me (values come out as "HASH(xxx)"), but I notice
that langlist is just the sorted keys of languages, which is easier to do with
TT's "sort" virtual method:

[% FOREACH lang = languages.keys.sort %]
  [% UNLESS lang == 'en-US' %]
    <option value="[% lang %]">[% languages.$lang %]</option>
  [% END %]
[% END %]

A minor simplification is to use NEXT IF instead of UNLESS:

[% FOREACH lang = languages.keys.sort %]
  [% NEXT IF lang == 'en-US' %]
  <option value="[% lang %]">[% languages.$lang %]</option>
[% END %]



>    heading = "Mozilla ${versions.$ver} Download (${languages.$lang})"
(here and later)

Nit: "Download Mozilla ${versions.$ver} (${languages.$lang})" for clarity and
consistency.



>      [%IF ver < latest%]
>      <p class="important">Updated versions of Mozilla are available in
>        <a href="[%ENV.SCRIPT_NAME%]?platform=[%platform%]">other languages</a>.</p>
>      [%END%]
(here and later)

Updated -> More recent

Also, the box around this sentence stretches past the text itself given a
sufficiently wide screen.  Can that be fixed?



>      <p>[%platforms.$platform%] platform. Please read the <a href="[%relnotes%]">Release Notes</a>
>         for Mozilla [%versions.$ver%] system requirements, installation instructions, and known issues.</p>

Seems like it makes more sense for the platform value to be part of the header
along with the version and language, i.e.:

    heading = "Download Mozilla ${versions.$ver} (${languages.$lang}) for
${platforms.$platform}"
...
      <p>Please read the <a href="[%relnotes%]">Release Notes</a> for Mozilla
[%versions.$ver%]
	 system requirements, installation instructions, and known issues.</p>

If that makes the header too big, you might shorten it to "Mozilla <version>
(<language>) for <platform>".  Or you could just have the header be "Download
Mozilla" and put the version, language and platform values in a subheader or in
the informative paragraph about release notes, etc.  It just seems that the way
it is now splits the identifying information between the header and the
informative paragraph arbitrarily and confusingly.

You also don't need "Mozilla [%versions.ver%]" in the sentence.



>      <dl>
>        <dt><strong><a href="[%uri%]">Mozilla [%versions.$ver%] [%form%]</a></strong> ([%size%])</dt>
>        <dd><p>[%languages.$lang%] language version</p>
>            <p>[%notes%]</p>
>        </dd>
>      </dl>

Since you've already identified that the user is downloading Mozilla and the
version and language being downloaded, I'd suggest making this just "<form>
(<size>)".  All other information is redundant with what already appears on the
page.



>        <li><a href="[%ENV.SCRIPT_NAME%]?platform=[%platform%]&language=[%lang%]">[%languages.$lang%]</a>

"&" needs to be escaped as "&amp;"

Nit: closing </li> tag



>        <li>Download and install <strong>one of the following</strong> complete packages:

The emphasis here should only be on "one", as the rest is self-evident.



>        [%IF buildlist.$english%]

Nit: naming variables according to data structure is considered suboptimal. 
Use "builds" or something like "applicable_builds" or "builds_for_platform" (if
"builds" is already taken) instead of "buildlist".



>        [%FOREACH lang = langlist%]
>          [%build = buildlist.$lang%]
>          <dt><a href="[%build.uri%]">[%languages.$lang%]</a></dt>
>            <dd>[%build.form%] ([%build.size%]) [%build.notes%]</dd>
>        [%END%]

This seems unnecessarily wasteful of vertical space, especially since most
builds don't have notes.  Recommend instead:

	[%FOREACH lang = langlist%]
	  [%build = buildlist.$lang%]
	  <a href="[%build.uri%]">[%languages.$lang%] language
[%build.form%]</a> ([%build.size%])</br>
	    [% IF build.notes %]<some-tag-perhaps-blockquote>[% build.notes
%]</some-tag-perhaps-blockquote>[% END %]
	[%END%]

Also, I'm not sure if I mentioned it before, but "x86", "Mac OS X", and other
prefixes in the build form values are unnecessarily duplicative of platform
information.

Also, I selected "Linux - Tamil" and got so many possible complete packages
that the second step I needed to take (installing the language pack) was off
the bottom of the screen.  This seems like a worse result than showing people
fewer possible complete builds.  I'd go so far as to say that you really only
need to show the English build along with a "more languages" link that turns on
the display of other builds for those people who really don't want the English
base.  After all, the page itself is in English; presumably the user knows
enough English to use it, which means she should know enough to download an
English language build and then install the appropriate language pack.

Also, I've noticed that I was confused several times when I reached this page
about how to get my build.  Although the ordered list is good in theory, in
practice I don't think it explicates clearly enough that there is a two step
process to go through.	I'd recommend language like "First do this: ... Then do
this: ..." instead of the ordered list.  Basic but effective.

>        <li>Install
>            <ul>
>          [%FOREACH name = packs.keys%]
>            <li><a href="[%packs.$name%]">[%name%]</a></li>
>          [%END%]
>            </ul>
>        </li>

Is there ever more than one language pack to install?  If not, then it doesn't
make much sense to put them in a list.	"Install <name>" would be simpler and
better.  If there are sometimes multiple language packs to install, then you
could test for that with "packs.keys.size > 1" and show a list only then.



>      <p>Mozilla is available for [%platforms.$platform%] in the following languages:</p>
>
>      [%INCLUDE platformlisting%]

INCLUDE is costlier than PROCESS because it localizes variables.  Use PROCESS
instead of INCLUDE unless you really need to make non-global changes to
variables in the included/processed block.



>    [%msg%]

Nit: msg -> message (no need for this much brevity here)
This is related to bug 226064
If I make a suggestion : after browsing through the majority of mozilla.org
related bugs and enhancement I feel that what we really NEED is for ONE single
download page that :

Provides links to current Mozilla binary releases in the following linkformats:
FTP links
HTTP links
Bittorrent links (Bug 222261)
Magnet links (Bug 247789)
ED2K links (Bug 247787)
Freecache mirror links (Bug 243449)
.. other mirror links (TUCOWS , Download.com , etc ..

I envision it working like this :

1) You arrive at the Mozilla.org start page.

2.1) You browse to the download page
OR
2.2) You browse to the wanted product's page

3.1) You select the wanted product
OR
3.2) You select download from the wanted product's page

4) You select your platform ( Clever javascript can make the detected platform
of the browser the default (already prechoosen) choice )
Highlight the most predominant platforms ( Windows , Linux and Mac )
If there is only one available platform for the product choose that automaticly
( Camino is only available for Mac )

5) You are presented with a choice of download methods for the english version
of the wanted product :
I imaging one one row with :

Freecache mirror, other top mirrors , HTTP , FTP , Zip file , netinstaller and a
link titled "More mirrors" (which leads to a page with even more mirrors)
The reason I put mirrors first is because the average user that just want the
file quick will click on the first link presented to him. This way the mirrors
would be used much more.

And one row under that with :
Bittorrent , Magnet , ED2K. (Separated visually on this second row to signify
that theese are special download links)

Following these two rows would be infomation about the file.
It's filename , it's size , it's creation date , it's MD5 and SHA1 hashes (and
possible it's ED2K hash too)

Under this info box would be links to "Localized versions" and to "Older versions"

If implemented like this we could in one big swoop fix ALL the following bugs :
Bug 243449 , Bug 247787 , Bug 247789 , Bug 222261 , Bug 226064 , Bug 159999 and
this one ofcourse.

The pages would either be seperate html pages where each choice send you to the
next (works in all browsers and you can link to a specific page if needed), or a
one big page using clever CSS to hide/show sections as you choose.

I prefer the latter , as long degrades gracefully in non-CSS browsers.
We can't asume that users that wish to download a Mozilla product have a recent
browser.
*** Bug 249871 has been marked as a duplicate of this bug. ***
(cf.bug 239871, marked as duplicate) 
[Localized builds]
While not being perfect, making an interim link to
http://www.mozilla.org/projects/l10n/mlp_status.html
would help. (It's currently quite deeply buried).
(I couldn't find any link regarding Thunderbird and Firebird localization, but
they exist, e.g. http://www.thunderbird-mail.de/)
Getting the product for _my platform_ and in _my language_ should be an easy
step on mozilla.org since I believe this is what most people want when going there.
Currently, it's fine when I need english-win32, but completely unacceptable if
you need sth different!

The new, now online page (I like the layout) did not bring any improvements for
this issue..(at least I can't see any)

What's the plan?
The plan, I think, should be to take the scripts given in comment 17, bring them
in line with Myk's review requirements, and update their download data. Then
make copies for Firefox and Thunderbird.

I don't have time to work on this right now; if anyone wants to take it over,
feel free. (You will need to know Perl.)
Keywords: helpwanted
Mozilla's flagship products are now Firefox and Thunderbird. Thanks to the
language auto-detect script and all.html, foreign people can easily download
their localized builds.
http://www.mozilla.org/products/firefox/all.html

I suggest you mark this bug fixed.
Fixed by website revamps. Or something.
Status: NEW → RESOLVED
Closed: 18 years ago → 16 years ago
Resolution: --- → FIXED
Product: mozilla.org → Websites
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.