Page MenuHomePhabricator

Notify community of Book PDF unavailability on-page
Closed, ResolvedPublic3 Estimated Story Points

Description

Background

We need to notify our community that PDFs for books will be unavailable for the short-term directly on the books page. We may do this by either:

  • changing the text on the current banner and keeping the banner the same
  • visually highlighting the severity of the issue on the banner

Design

On page before Creation has started

book-creator-down2.png (1×2 px, 645 KB)

On Manage books

book-creator-down.png (1×2 px, 486 KB)

Copy
Due to severe issues with our existing system, the Book Creator will no longer support downloading a book as a PDF for a short period of time. We are working hard to replace our system and re-enable PDFs within the Book Creator.

While the Book Creator PDF rendering is being replaced, you can try Download as PDF from the sidebar tools for individual articles

learn more link
https://www.mediawiki.org/wiki/Reading/Web/PDF_Functionality

Spec

https://zpl.io/2Z0jwxl

Acceptance Criteria

  • Update current special:book banner with the new banner
  • Place special book banner on beginning of book creator page
  • User download option must appear disabled
  • Display banner on rendering failed page
  • Update MW page with banner text
  • Remove OCG as an option from the book creator

Testing criteria

  1. Go to https://en.wikipedia.beta.wmflabs.org/wiki/Dog
  2. Launch book creator by selecting "create a book"
    1. Ensure banner appears at top of page prior to book creator launch
    2. Ensure clicking "learn more" redirects to https://www.mediawiki.org/wiki/Reading/Web/PDF_Functionality
  3. Select "start book creator"
  4. Add page to book
  5. Select "show book"
    1. Ensure banner appears

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Proposed text:

Due to severe issues with our current rendering system, PDF book printing will be unavailable in the short term. We are currently working on a replacement system we hope to deliver by November 2017. In the meantime, you can download the individual articles of a book using the "download as PDF" functionality from the sidebar. For feedback, please visit the project page here: https://www.mediawiki.org/wiki/Reading/Web/PDF_Functionality

ovasileva added a subscriber: Johan.
ovasileva updated the task description. (Show Details)
ovasileva moved this task from Triage to Backlog - Q2 on the Proton board.

Due to severe issues with our current rendering system, PDF book printing will be unavailable in the short term. We are currently working on a replacement system we hope to deliver by November 2017. In the meantime, you can download the individual articles of a book using the "download as PDF" functionality from the sidebar. For feedback, please visit the project page here:

Few comments on language

  • avoid technical terms, rendering system, functionality etc.
  • let's not expose the details like "month" in product messaging. we should keep it for the "learn more" link to the meta/mediawiki page
  • split the "meanwhile" part from the notice part.

here's a mock

book-creator-down.png (1×2 px, 296 KB)

thoughts?

@Nirzar - looks good, but I think we can still keep the book creator on, just turn off the functionality. Thus, if you want to create a book, you can still do so and only access it online. So I'd say, let's keep the banners on top of the page and add the remainder as is.

text v3:

"Due to severe issues with our existing system, the Book Creator will no longer support saving a book as a PDF for a short period of time. We are working hard to replace our system and re-enable PDFs within the Book Creator."

download as PDF message looks okay.

That was if you want to create a book, you can still do so and only access it online. So I'd say, let's keep the banners on top of the page and add the remainder as is.

oh didn't know that, thanks. will update accordingly

@Nirzar: Are we to implement your mock exactly, i.e. without using the pre-existing warningbox and errorbox CSS classes? If so, can you add a link to the Zeplin mock in the description?

our message system doesn't have things like accessory icons and title etc... i honestly don't have a clear answer since this requires either us creating new messages or use old messages which won't convey what we are trying to convey :( debt biting us again. we can also do one off message right now. and then remove the code later.

@ovasileva the copy looks good, just changing "save" to "download" to reduce confusion with save/publish etc.

Change 379647 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/extensions/Collection@master] WIP: Message boxes about book creator undergoing changes

https://gerrit.wikimedia.org/r/379647

@Nirzar, @ovasileva is the "disabling" the whole download section part of this task? - it's in design (Manage books page) but not in the task description.

@pmiazga - now added to the task description. imo, we should only disable the button if that's easier, the entire section if they would be equal difficulty - @Nirzar - would you be okay with that?

@ovasileva no problem, I'll disable the whole section. That's fine, I just had a small problem with disabling the button but I found that there is a Javascript that on page render checks the articles and enables/disables the button. Because of that, I didn't see my changes. I'll update the JS to match new button behavior.

Change 380572 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/extensions/Collection@master] Disable the Download section on Manage Books page

https://gerrit.wikimedia.org/r/380572

This task contains two patches,

@ovasileva -> disabling/enabling download section is driven by a config variable. We will be able to disable/enable that box with SWAT deploy, banners will stay visible unless we manually remove them from the code.

This task contains two patches,

@ovasileva -> disabling/enabling download section is driven by a config variable. We will be able to disable/enable that box with SWAT deploy, banners will stay visible unless we manually remove them from the code.

we'd have to make sure we do both deploys as quickly to each other as possible. The banners will be on the train, right?

@ovasileva Both will go on the train as both are code changes - I can make the disabled look&feel by default. With that, we won't have to change the config but we leave a window to re-enable download box when it's necessary (or even leave it enabled for some wikis)

@ovasileva Both will go on the train as both are code changes - I can make the disabled look&feel by default. With that, we won't have to change the config but we leave a window to re-enable download box when it's necessary (or even leave it enabled for some wikis)

sounds good!

Change 380572 merged by jenkins-bot:
[mediawiki/extensions/Collection@master] Disable the Download section on Manage Books page

https://gerrit.wikimedia.org/r/380572

Change 379647 merged by jenkins-bot:
[mediawiki/extensions/Collection@master] Message boxes about book creator undergoing changes

https://gerrit.wikimedia.org/r/379647

Added testing criteria for first portion. @pmiazga, @Jdlrobson - is there a way to test the banner on saved book pages in the beta cluster?

is there a way to test the banner on saved book pages in the beta cluster?

I'm a little confused. Your steps in "Testing criteria" seem to cover that. The banners show on the book page as does the disabled download form.

I missed presenting banners on Saved Books page - currently, banners are visible only on "Create book" and "Manage book" pages. I'll add a banner to saved book pages.

@Jdlrobson - we also want them for currently saved book pages in the user namespace or the book namespace - check out the acceptance criteria above for examples.

Changing the book pages is something that I and @Jdlrobson have missed during estimation. It brings much more work into this task, also increases a complexity as we have to talk with Ops about caching Collection wiki pages.

Do we want to show those banners on saved book pages? IMHO, it bumps the estimate to at least 5 points. The reason is book pages are normal Wiki pages and it's difficult to modify page content without hacking, also detecting book pages is pretty difficult and requires complicated checks, To show banners we can use
SiteNoticeAfter hook and inject banners into the page but banners will appear above the page title which doesn't look good. We disabled the download box but there is still a possibility to download a book by:

  • create a book
  • save book
  • go to saved book
  • hit "PDF (A4)" in select format to download.

To disable that action we have to:

  • difficult way - edit coll-savedbook_template template on all wikis (on every wiki the template name is different) and remove "select format to download" option. Better UX but more work
  • easier - change the code to disable the "download" page and show some information to users that download PDFs are unavailable. - Worse UX but less work, users will get the information after the click.

Also, we would need a design for a page telling users that download option is not available at this moment.

Because books are standard wiki pages we have to somehow detect those (by checking namespace/category/prefix). For example, User books are stored inside NS_USER namespace with category Book, community books are stored inside NS_PROJECT namespace. It
is possible that user will create a subpage in his namespace and add "Books" category, or edit the current book and remove "Books" category and we will not be able to detect is this a book page.

My recommendation is to create a separate task about showing banners on Book pages and finding the best way how to tackle problems I mentioned above.

EDIT: Added info that there is no NS_BOOK book namespace, we have to test by book name/prefix

Change 381252 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/extensions/Collection@master] DONOTMERGE: Detect book pages

https://gerrit.wikimedia.org/r/381252

@pmiazga - okay, we can skip the book pages.

sorry, was in a meeting while typing that. What I meant was, can we remove both PDF options and the wikitext options. Then, the only link left would take them to the book within the book creator where they can see the banner.

If so, we can skip the banners for these

at. What I meant was, can we remove both PDF options and the wikitext options. Then, the only link left would take them to the book within the book creator where they can see the banner.

Not sure exactly what you mean. Do you mean this?:

Screen Shot 2017-09-28 at 2.31.25 PM.png (262×976 px, 93 KB)
)

If so, technically yes.. we can do so for English Wikipedia, but it would be better if this change comes from the community since it requires an edit to the wiki and we certainly cannot fix the templates for all the different language wikis... (templates are not shared across wikis)

at. What I meant was, can we remove both PDF options and the wikitext options. Then, the only link left would take them to the book within the book creator where they can see the banner.

Not sure exactly what you mean. Do you mean this?:

Screen Shot 2017-09-28 at 2.31.25 PM.png (262×976 px, 93 KB)
)

Yes.

If so, technically yes.. we can do so for English Wikipedia, but it would be better if this change comes from the community since it requires an edit to the wiki and we certainly cannot fix the templates for all the different language wikis... (templates are not shared across wikis)

Hmm...what would selecting PDF do here if we don't make the change? Nothing?

The "PDF" link will redirect to Collection page that shows the PDF generation progress or a page with a link to download the PDF file when the file is ready ( rendered and stored in the cache). That page is not blocked yet - we blocked only form by disabling it. I can disable that page but we would need some information on this page telling users that PDF generation is broken. We can render banners there but I don't think it's sufficient.

This is how the "download" page looks like:

(link) https://en.wikipedia.org/w/index.php?title=Special:Book&bookcmd=rendering&return_to=Book%3A13th+Floor+Elevators&collection_id=8d71bd41ed09e4f682f3af493303ad514b8915fe&writer=rdf2latex&is_cached=1

Screenshot from 2017-10-02 13-59-03.png (724×1 px, 99 KB)

This is how the "rendering is in progress" page looks like:

Screenshot from 2017-10-02 13-57-05.png (842×1 px, 95 KB)

When the rendering is done it will redirect to "download" page.

If we want to block "PDF" button we need to change the copy on both pages and

  • disable pdf rendering if not started yet (on progress page)
  • disable re-rendering (download page)

The issue is that, once we remove OCG, the "download" and "rendering in progress" pages will no longer exist. I was asking what would happen in that situation. I agree that since it's a template, we should really just leave it to the community to change. What would it look like if we added the banner above the title? Not the best in terms of UI, but at least it would give users an idea on why some of the links on the page might not be working.

after speaking with @pmiazga, we have decided to keep the rendering failed page and display the banner there. Updating acceptance criteria accordingly.

ovasileva updated the task description. (Show Details)

In a scenario when the user asks to render a book with the non-existing writer (example: links in saved_book template use hardcoded rdf2latex writer, after disabling OCG this writer will not exist) will result in an error page.

Screenshot:

Screenshot from 2017-10-02 15-18-59.png (655×1 px, 81 KB)

In a scenario when the user asks to render a book with the non-existing writer (example: links in saved_book template use hardcoded rdf2latex writer, after disabling OCG this writer will not exist) will result in an error page.

Screenshot:

Screenshot from 2017-10-02 15-18-59.png (655×1 px, 81 KB)

just to clarify, we decided to place the message on this page (rendering failed)

No, not yet. Not sure how to update steps for the new change as it's difficult to test. I'd like us to work that out before pushing to Anthony.

Screen Shot 2017-10-04 at 8.03.27 PM.png (582×1 px, 115 KB)

tested on the beta cluster. looks good!

Change 381252 abandoned by Pmiazga:
DONOTMERGE: Detect book pages

Reason:
We decided to drop that idea and do not show banners on book pages

https://gerrit.wikimedia.org/r/381252