Table columns in "Download Files" section are disproportionate

[sourcenouveau]

The table columns in the "Download Files" section of a project page are not proportioned well. Filename, Size & Hash are all crammed into a single tiny column, while three less important things (File Type, Python Version, and Upload Date) take up 75% of the width.

I am not able to visually scan for the files I want because the filenames are so wrapped.

Case in point: https://pypi.org/project/numpy/#files
Compare to: https://pypi.python.org/pypi/numpy

One potential solution could be to put data on two lines, something like this:

Filename	Size	Hash	Type	Python Version	Upload Date
numpy-1.14.2-cp27-cp27m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
	4.7 MB	SHA256	Wheel	cp27	Mar 12, 2018
numpy-1.14.2-cp27-cp27m-manylinux1_i686.whl
	8.7 MB	SHA256	Wheel	cp27	Mar 12, 2018
numpy-1.14.2-cp27-cp27m-manylinux1_x86_64.whl
	12.1 MB	SHA256	Wheel	cp27	Mar 12, 2018

[brainwane]

@emddudley Thanks for the bug report, especially for the specific example case of NumPy. I see how this is especially annoying in releases with, say, five or more packages.

I want to check: When you are scanning a list of packages, are you pretty much always looking for the same metadata (that we could perhaps present in a different column), such as the platform the wheel was built for?

[sourcenouveau]

I look for the ABI (cp27m vs cp27mu) and platform (win vs manylinux1 vs none and x86_64 vs amd64 vs i686).

I sometimes also check the "local version label", for example the +mkl in the filename below:
numpy‑1.14.2+mkl‑cp27‑cp27m‑win_amd64.whl

Sometimes I check the version to confirm the absence of a local version label.

I typically look for the file extensions. I trust that more than the inferred file types.

Here is another case where I check for the above information:
https://pypi.org/project/protobuf/#files

[dstufft]

Local versions aren't allowed on PyPI, if someone managed to upload one, that's a bug.

[sourcenouveau]

I got that filename from a third-party site. On PyPI I check for the absence of the label. Things don't work if I get the wrong wheel. But now that I know PyPI doesn't allow local version labels, I suppose it wasn't a reliable way to check...

[brainwane]

@emddudley I appreciate the further data -- thank you! This will help our designer think about how to solve this. She'll look at this issue within the next few business days. Thanks again.

[nlhkabu]

thanks for this feedback @emddudley - we definitely need to do something about this. I will add this point to our upcoming user tests - it will be interesting to see how others are reading this table and what data they think is important :)

[brainwane]

@nlhkabu A user pointed me to #929 which also demonstrated concern about this. I like the screenshot in #929 (comment) but am not sure whether it was a mockup or not :) @techtonik could you clarify?

[brainwane]

@emddudley In a few minutes this will be live on test.pypi.org and pypi.org so you can see whether the improved table style solves this problem for you. Please let us know! Thanks.

[sourcenouveau]

@brainwane: I cleared my browser cache but I am not seeing any difference.

[di]

Likely hasn't fallen out of the cache yet.

[sourcenouveau]

It's better and I could work with it in its current state.

I do still have some nitpicks though. The remaining issues I see are the table cell padding and the handling of very long filenames.

The table cells are padded such that an entire line of text could fit between rows. I think this slightly hinders visual scanning. I do understand that the padding may be consistent with other parts of the site, and that there may be other usability considerations. Still, my preference is less padding--my eye is better able to compare the shape of the text without actually reading it. Compare the following.

Current padding:

Reduced padding:

Secondly, very long filenames still seem like a problem. Again, they disrupt scanning. The only time I see these long names are with OS X wheels, and I am guessing that it is rare that anyone reads the entire OS X platform string. Just as an idea, what if very long filenames were abbreviated with an ellipsis, and you could view the full name by hovering the cursor and viewing a tooltip?

[brainwane]

@emddudley Sorry for the delay. @yeraydiazdiaz is this something you could address in #3783?