[Pydotorg-redesign] Download pages

[Richard Jones]

I just skimmed through amk's revised beginner's guide, great stuff!

The download pages seem a little confused though - the one linked from the
beginner's guide mentions python 2.2. Could we maybe simplify the main
download page so it's more friendly to beginners and do away with the
duplicated page?

Also, I believe the source downloading text could be improved. Currently it
says "download Python-2.3.tgz, the source tarball, and do the usual 'gunzip;
tar; ./configure; make" dance.'

Perhaps more explicit, useful instructions could be given, like 'download the
source archive Python-2.3.tgz, unpack and build. Typically "tar zxf
Python-2.3.tgz" will unpack, and then in the Python-2.3 directory type
"./configure && make install" to build.' Or something similar?


Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : http://mail.python.org/pipermail/pydotorg-redesign/attachments/20030811/b0930877/attachment.bin

[Skip Montanaro]

Richard> The download pages seem a little confused though - the one
Richard> linked from the beginner's guide mentions python 2.2. Could we
Richard> maybe simplify the main download page so it's more friendly to
Richard> beginners and do away with the duplicated page?

I think that would be great. I made some suggestions here:

http://mail.python.org/pipermail/pydotorg-redesign/2003-August/000189.html

but the followups talked to other content in that note. In short, I think
it would be great of the main feature of the download page was a table of
download links. Much as we like to gripe about SourceForge, presenting the
key download options in a single table makes it easy to find what you're
looking for and what all the options are. I'm sure most people know what I
mean. Unfortunately, SF is down at the moment so I can't provide a link to
an example, so those of you who maybe don't will have to scrounge around for
something visual.

Skip

[Richard Jones]

Post by Skip Montanaro
Richard> The download pages seem a little confused though - the one
Richard> linked from the beginner's guide mentions python 2.2. Could we
Richard> maybe simplify the main download page so it's more friendly to
Richard> beginners and do away with the duplicated page?
http://mail.python.org/pipermail/pydotorg-redesign/2003-August/000189.html

Excellent suggestions, I'm all for them. I just can't offer any help
implementing them at the moment :(


Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : http://mail.python.org/pipermail/pydotorg-redesign/attachments/20030811/3530646e/attachment.bin

[Skip Montanaro]

Attached is a quick knock-off of the one-table-for-all-sizes idea. It's
obviously rough and incomplete (no actual links and it's missing most older
versions). It does give something to throw darts at though. Obvious issues
that occur to me:

* Sean Reifschneider's got a helluva lot of different RPMs. I only
included about half of the 2.2.3 RPMs in the example table. His
"three versions to rule them all" suggests that maybe the table needs
another level of hierarchy.

* I included an empty Notes column. This should probably be numbered
links to a set of footnotes below the table (or on another page). I
think there will probably be too many notes to embed their text
directly in the table.

Skip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pydotorg-redesign/attachments/20030810/ac915e33/index-0001.html

[Richard Jones]

Post by Skip Montanaro
Attached is a quick knock-off of the one-table-for-all-sizes idea.

Might I suggest "built" instead of "binary". Just thinking about the
non-programmer newbie types we'll probably be directing at/near this table.

Post by Skip Montanaro
* Sean Reifschneider's got a helluva lot of different RPMs. I only
included about half of the 2.2.3 RPMs in the example table. His
"three versions to rule them all" suggests that maybe the table needs
another level of hierarchy.

Yeah... maybe link to a separate table further down the page?

Post by Skip Montanaro
* I included an empty Notes column. This should probably be numbered
links to a set of footnotes below the table (or on another page). I
think there will probably be too many notes to embed their text
directly in the table.

That would definitely be much cleaner, yes.


Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : http://mail.python.org/pipermail/pydotorg-redesign/attachments/20030811/9666ef8a/attachment.bin

[Skip Montanaro]

(Did you send this to pydotorg-redesign as well? It appears not. We need
more inputs, now fewer, at this point. ;-)

Post by Skip Montanaro
* Sean Reifschneider's got a helluva lot of different RPMs. I only
included about half of the 2.2.3 RPMs in the example table. His
"three versions to rule them all" suggests that maybe the table needs
another level of hierarchy.

Johannes> See my mockup (attached): further options on a different page.

Post by Skip Montanaro
* I included an empty Notes column. This should probably be numbered
links to a set of footnotes below the table (or on another page). I
think there will probably be too many notes to embed their text
directly in the table.

Johannes> What kind of notes are you thinking of? I think notes
Johannes> pertaining to a specific releases should be on that releases
Johannes> page. I'd also like to have notes for a specific platform on a
Johannes> different page.

I was thinking of a note explaining why UNWISE.EXE was necessary, or one to
distinguish the three categories of Sean's RPMs.

The problem I see with your suggested layout is that you ask the user to
select the version twice. For example, all your Windows links point to
windows.htm. Presumably they've already told you which version they want by
clicking on a specific Windows link.

Johannes> I see the /download/ page as an *entry point* where a user
Johannes> should be able to download the most popular packages right
Johannes> away. When a user has different needs, he/she can go to one of
Johannes> the more specific pages.

I see three possible organizations:

* A single download page containing just about everything people would
need, with an occasional jump to another page or to some text farther
down on the download page. This is what I'm proposing.

* A platform-centered download page - first click takes you to Windows
or Linux or Source or whatever page, from which you select the version
you're interested in. This has the disadvantage that version info is
scattered around and maybe duplicated.

* A version-centered download page - first click the version you're
interested in and then select the platform. This is similar to the
current setup. Aside from not being able to easily identify the
precise file(s) you want to download, it scatters (and maybe
duplicates) the platform information across several pages.

Most FTP setups are more-or-less like the third option: they tend to be
organized hierarchically by version, but there is no immediate platform
information available when you are staring at the various files. You have
to dive into a README file if the authors provided one.

Skip

[Aahz]

Post by Skip Montanaro
Johannes> I see the /download/ page as an *entry point* where a user
Johannes> should be able to download the most popular packages right
Johannes> away. When a user has different needs, he/she can go to one of
Johannes> the more specific pages.
* A single download page containing just about everything people would
need, with an occasional jump to another page or to some text farther
down on the download page. This is what I'm proposing.
* A platform-centered download page - first click takes you to Windows
or Linux or Source or whatever page, from which you select the version
you're interested in. This has the disadvantage that version info is
scattered around and maybe duplicated.
* A version-centered download page - first click the version you're
interested in and then select the platform. This is similar to the
current setup. Aside from not being able to easily identify the
precise file(s) you want to download, it scatters (and maybe
duplicates) the platform information across several pages.

Depending on what you mean by "everything", there's at least a fourth
option that I suggested on pydotorg this morning: keep the current setup
(more or less), but add a set of "quickie" download links on
/download/index.html for only the current version. That would be
source, Windows, and Mac. Note that the current setup sort-of combines
options two and three. I don't object to switching to option one, but I
think I'd prefer it be a separate page and still have the quickie links
on index.html.

[Johannes Gijsbers]

Post by Skip Montanaro
(Did you send this to pydotorg-redesign as well? It appears not. We need
more inputs, now fewer, at this point. ;-)

Sorry, just switched to a different MUA and pushed the wrong button. :)

Post by Skip Montanaro
The problem I see with your suggested layout is that you ask the user to
select the version twice. For example, all your Windows links point to
windows.htm. Presumably they've already told you which version they want by
clicking on a specific Windows link.

No, they've told me they want more information about other versions
available for the selected platform. At least, that's what I was
thinking, but it seems that is confusing. Maybe Aahz' approach would
be better then: a combination of quickies (like in my table) and a
list of links to more information for other platforms (like on the
current page).

Johannes

[Guido van Rossum]

Post by Richard Jones
Also, I believe the source downloading text could be
improved. Currently it
says "download Python-2.3.tgz, the source tarball, and do the usual 'gunzip;
tar; ./configure; make" dance.'
Perhaps more explicit, useful instructions could be given, like
'download the source archive Python-2.3.tgz, unpack and
build. Typically "tar zxf Python-2.3.tgz" will unpack, and then in
the Python-2.3 directory type "./configure && make install" to
build.' Or something similar?

I doubt this would make much of a difference. People who don't
already know what the gunzip/tar/configure/make dance is are unlikely
to get it right even with more elaborate instructions. They should
probably use the Windows installer anyway. :-) (Or for Linux, the
RPMs.)

--Guido van Rossum (home page: http://www.python.org/~guido/)