Skip to content

Improve the "download files" table #10448

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mattip opened this issue Dec 7, 2021 · 10 comments
Closed

Improve the "download files" table #10448

mattip opened this issue Dec 7, 2021 · 10 comments

Comments

@mattip
Copy link

mattip commented Dec 7, 2021

What's the problem this feature will solve?
The list of downloads for a project like numpy is hard to navigate. The layout looks like

Filename, size File type Python version Upload date Hashes
numpy-1.21.4.zip, (10.6 MB) Source None Nov 5, 2021 View
longname, size Wheel pp37 Nov 5, 2021 View
longname, size Wheel cp310 Nov 5, 2021 View
longname, size Wheel cp310 Nov 5, 2021 View

It can be difficult to find the proper file in the list.

Describe the solution you'd like

  • The table should be sortable by clicking on the headers (I can't simulate that with github markdown).
  • It would be nice if the information was parsed for the user by PEP 425 tags, like
Python tag ABI tag Platform tag Download Hash
None None sdist 10.6 MB View
cp310 cp310 manylinux_2_12_x86_64.manylinux2010_x86_64 21.2 MB View
cp310 cp310 win_amd64 19.4 MB View

If desired, the current table could be added as well but hidden behind a css-fold (is that what this is called?) like

Complete listing
Filename, size File type Python version Upload date Hashes
numpy-1.21.4.zip, (10.6 MB) Source None Nov 5, 2021 View
longname, size Wheel pp37 Nov 5, 2021 View
longname, size Wheel cp310 Nov 5, 2021 View
longname, size Wheel cp310 Nov 5, 2021 View

Additional context

Thanks!

@abitrolly
Copy link
Contributor

The code which generates DOM markup is here https://github.com/pypa/warehouse/blob/5c78122a57257a2e76fe883d78500416784d6111/warehouse/templates/packaging/detail.html#L313 but I am not sure where to add the JS that will add the sorting behavior.

I would also separate sources from binary wheels into separate tables and provided links to the same info exposed as JSON.

@mattip
Copy link
Author

mattip commented Dec 7, 2021

Maybe because up to now the pages have no javascript. This may be a design decision, to support users without javascript. In this case those users would not be able to reorder the table. I am not a front-end dev, so I can only cheer from the sidelines, but maybe a start would be to propose reformatting the page. A subsequent task might be to add javascript for row ordering.

@callmekofi
Copy link

I had a similar situation. I completely agree with Mattip. It will better if the table is sorted out according to headers.

@nedbat
Copy link

nedbat commented Jan 25, 2022

Before getting to JavaScript/sorting/dynamism, it would at least help to adjust the layout to acknowledge "verylongname" files. We're at the point where not only is the table wider than my laptop screen, but the filenames themselves are starting to have to wrap:
image

@abitrolly
Copy link
Contributor

That's some 4x4 drive packages for manylinux. :D Are you sure there is no mistake with so many manylinux specifiers in one filename?

@di
Copy link
Member

di commented Jan 25, 2022

Yes, it's valid, this is a 'compressed tag set': https://www.python.org/dev/peps/pep-0425/#compressed-tag-sets

@di
Copy link
Member

di commented Jan 26, 2022

Regarding @mattip's original issue: I'm doubtful that displaying the various tags (in addition to the filename) would actually be helpful for the average user here. I think anyone that's aware of what a ABI/Platform tag is could get this same information from the filename. A better approach would be using these tags to create more human-friendly labels for each file, similar to what @tiran suggests in #10308 (and then making these filterable in the UI).

Regarding @nedbat's comment, I agree that this UI doesn't handle long filenames well right now. I think #10646 should resolve it.

@mattip
Copy link
Author

mattip commented Jan 26, 2022

Agreed that #10646 is a good step forward.

@mattip mattip closed this as completed Jan 26, 2022
@abitrolly
Copy link
Contributor

#10646 does a good thing by separating sources and binaries, but it actually makes it harder to scan for necessary info.

The good UX fix is multilevel table with necessary platform filters.

image

An alternative #10646 is to contract long filenames dynamically as coverage-6.3-...amd64.whl, highlight full name on hover, and provide a link to JSON or CSV version of the table with full info. But again make sure the fields that users need to make a choice are transformed into visual aid, such as table columns.

I could show how it may look like after #10469 is merged.

@webknjaz
Copy link
Member

xref #9066

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants