Drop downloads view and/or templates

[agjohnson]

Maybe a change for the application: drop project downloads template view. Downloads are visible in the version object listing.

[humitos]

I found that this page was not created yet, https://beta.readthedocs.org/projects/docs/downloads/

However, now we have this nice dropdown that shows all the formats available for that version:

It would be good if you can considering incorporating "multiple files per file type" here as well. We are pretty close in the to support multiple-files per version here and it would be good to have the UI ready for this: readthedocs/readthedocs.org#2045

[agjohnson]

I think I want to kill /downloads entirely, but this was also before supporting multiple download files per format. I think attaching downloads to built versions is still the most obvious UI though.

Does the API response return what I need for multiple files yet? This download list is populated solely by the API.

I'm not sure exactly how I'd make this particular list show the multiple files yet. There are two cases to support, single PDF and multiple PDF, and could make a submenu pop out if there are multiple files.

[humitos]

Does the API response return what I need for multiple files yet? This download list is populated solely by the API.

No. The backend is not implemented yet.

I'm not sure exactly how I'd make this particular list show the multiple files yet. There are two cases to support, single PDF and multiple PDF, and could make a submenu pop out if there are multiple files.

This is why I wanted to mention this here. The current UI looks great for one single file per download type per version. However, it will gets tricky when supporting multiple files. I thought it could be useful to know we are going in this direction when designing this page.

[agjohnson]

Roger. I'll need the API changes first then, but the UI change shouldn't be hard.

[benjaoming]

Multiple PDFs

It would be great with some extra feedback UI-wise, in case you see special needs. I think this requirement is important to structuring the API and how the build process should detect and upload PDF files and if there's any meta data on top of that (hoping there isn't).

How should PDF files be named and labeled? When there was only a single PDF file, the name absolutely didn't matter, it could just be "Download the whole documentation as a PDF file".

But now we might have PDF files that are generated per section. And we might have custom build processes that name the files themselves etc.

Does it then make sense that the UI

1. Still handles when there is only 1 PDF file, so it's "Downloads --> PDF file"
2. With multiple files, we start to show options based on file names? So it could be "Downloads --> PDF: section1.pdf"
3. The dropdown could show 5 downloads and have a "See all" linking to a full listing?

Do we have compelling use-cases for multiple PDFs that might require more than what we can simply extract from the filename? (it's also a good option to simply not do that and just stick to file names)

Edit: The context of the above is just to have the best-possible understand before making some backend/API decisions, the rest can follow :)

[agjohnson]

How should PDF files be named and labeled?

I'm assuming we'd use filename as other options are complex for a first pass. We could decide to order our list of PDFs by filename (user controls order by filename), or could order by creation date (user controls order by build order). I think there are arguments for both, but either is fine.

Still handles when there is only 1 PDF file, so it's "Downloads --> PDF file"

👍 I was going to point this out too. Keeping the UX the same for single PDF file builds is a really good bet for now.

With multiple files, we start to show options based on file names? So it could be "Downloads --> PDF: section1.pdf"

This seems the most reasonable, though there will be other options we can explore next iteration for getting a title/etc. Filenames are going to be the most basic implementation of this, so it's fine to start there and add some better UX later.

The dropdown could show 5 downloads and have a "See all" linking to a full listing?

I think it's safe to put all files in the download menu. I don't think we'll see a project with an overwhelming number of files output from a single version. I'm also describing getting rid of the project download listing view. The offline formats are only listed in the version listing view at the moment, which mimics what we do to link to HTML output.

[benjaoming]

Awesome, thanks, this makes it pretty clear what the backend needs to support 👍