Do we want a reader screen

[ianvanhoof]

I am talking about a button that shoves everything into a 1 column cascade view. Much like medium. What do you think?

[camhayes]

I've thought about this a lot over the last year or two. My answer is that I'm not 100% sure.

Pros: Accessibility

• Allows us to clean our styles for users with non-blindness vision problems. (Read mode should interface minimal design - black/white, larger font, better for dyslexia without multi column text spanning).
• Zoom text degrades more gracefully with 1 column.
• Allows us to implement alt. reading environments, such as night mode.

Quality of Life

• Substitutes best for tablets and other devices that straddle the "mobile-ish" range.
• Can be more easily printed or displayed in a hybrid class.

Cons:

• The layout being displayed to the user is less predictable (we do not know who will be using a reader mode, and why that may not be the best thing, if that case can be argued).
• May be an annoying feature if someone accidentally turns it on.
• Will require some more thought from anyone designing an LO, and how the content may cascade (This argument has less to do with us, and more to do with some of our teammates that do not consider mobile/single column layout. I would argue this is a pro, ideally, but in practical application, will require some coaching and moderation - maybe we mark this as a consideration).
• Will need to be added to the testing checklist for every custom development (i.e., how does this look at 100% width on a 1440p 27-inch monitor). Again, not inherently a bad thing for us to be doing, but still a consideration.
• We would need to strongly consider how any widgets may appear in reader mode. Should reader mode still have interactivity?

Generally, I lean toward saying "yes" to this idea, I just try to be mindful of where this feature could cause a headache for us or our users. over the value we gain by having it. If we were to go down this road, I think we would need to consider it's implementation as being more than just making all of the content columns 100% width. The design should be simplified, with most of the non-typographic styles removed (and probably even removing the entire slide concept). We should also consider any additional presentation options (like contrast changes, or nightmode features, and whether or not to extract content from widgets). If we do not do these things, then why implement a reader feature, when the user could instead ctrl+ until the columns respond?

Thoughts?

edit: markdown formatting

[ianvanhoof]

Generally, I lean toward saying "yes" to this idea

So do I, which is why we are having this conversation.

it's implementation as being more than just making all of the content columns 100% width.

I was thinking...I am already scraping the slides recursively for the table of contents. I was going to use the same method just not stop at the headings. Using this method we can pick and choose what we would like to appear in reader mode.

Will require some more thought from anyone designing an LO

Not any more thought than you do now when checking the responsive breaks while laying content out normally...when you "Scrub the page" as it were. ahem.

when the user could instead ctrl+ until the columns respond.

That would just put it in mobile "stacked" view which isn't what we want. I was feeling more of a cascade. Think...a built in Readability or Instapaper. Yes, one could use it for accessibilities sake, but this is more for straight up reading than anything else.

Should reader mode still have interactivity? I wasn't worried about the interactive elements not being included in this view for the simple fact that I don't think they have any business being there. I was thinking that the goal of a reader view is to get rid of the UI, and interactive elements, so the reader can focus in on the content alone.

Thinking out loud here...we could also quickly offer dark and light color options based on our existing color palettes.

[camhayes]

I think we are on the same page, and I'm having trouble playing devils advocate by figuring out problems other than potentially non-existent "what if's". The only things that come to mind are:

• Browser performance
• Being able to switch back and forth between modes
• Determining what to do with content that is validly designed for selective release (or interactive release, rather).
• Image resolution scaling (consider 100% width x1024 images on a 1440p 27-inch monitor).

[ianvanhoof]

Yeah browser performance could become a show stopper, but we won't know until it's built if it will slow down anything. Thinking out loud again, maybe it only builds itself once the button is hit. Just like the audio button. That way we can avoid heaping more things on top of that initial load.

Determining what to do with content that is validly designed for selective release

Anything like that would be stripped out, and just displayed. I am just worried about how that would work on the page more so than if I would do it or not.

I am also not that concerned with the image thing. I was going to run the content area, just like we do our main content area, and keep it centered with a max width of 1024px. That keeps the control of such things in our hands, and keeps the line length where we want it to be.

It could be a separate fork as opposed to a feature branch...

I am getting convinced at this point.

What is your final say?

[camhayes]

I say try it. If it becomes more of an issue than a benefit, we either hit the drawing board or scrap it.