Choosing a Content Simplification Option

Cheetham, Anastasia acheetham at
Wed Jun 5 16:00:59 UTC 2013

I guess it's good Colin asked his questions, because my recollection is not quite what Michelle described. Comments in-line below.

On 2013-06-05, at 11:43 AM, Michelle D'Souza wrote:

> Option 1 - Responsive Layout
> In this design, when simplify is on, the small screen experience is delivered to the user. Although we still need to explore how we'd do this technically, it likely means that we would fetch and include the small screen stylesheet in the page.

My understanding was that the only thing this option would do would be to narrow the view, triggering whatever responsive designs the website already has. I did *not( have the impression that this would involve us fetching stylesheets, merely adding a designated class to the body. The website's responsive styles, triggered by a media query, would also have to be triggered by the presence of the class.

The mock-ups show a slider for this option, providing various widths. We decided we'd start with simply two widths, the default and a minimum (i.e. an on-off switch), and that we could expand it to a multi-value slider in a future iteration.

> Of course, we need to ensure that we can remove it when simplify is turned off. At a minimum, this would require the implementor to create a style sheet for their site that implements the small screen behaviour - essentially a linear layout with the most important information at the top of the page. On an existing site without a responsive design, this could mean a lot of work on the implementor's part. 

Yes, this requires that the integrator have some responsive designs, and the resulting layout would be whatever their designs were.

> Option 2 - Table of Contents
> This design involves stripping out most of the content on a page and replacing it with a table of contents. The table of contents should allow the user to access all content that would otherwise have been available on the page. By default, we'd likely use the 'article' tag to denote the content that would remain on the page. In this case, the implementor's most difficult task would be to create the site wide table of contents that we would be displaying. We will need to create an API for how the implementor would communicate the table of contents to us, but it likely follows our general communication strategy of plain JSON objects. 

I concur with this description, and will add a few details that I remember:
- The table of contents is expected to be a full site map of the site (provided by the integrator), plus the headings on the current page (i.e. in the content that is left on the page after simplification).
- The table of contents is a floating menu, collapsed initially.
- The integrator would be able to override the default "article" selector for identifying "important" content.

Anastasia Cheetham     Inclusive Design Research Centre
acheetham at           Inclusive Design Institute
                                        OCAD University

More information about the fluid-work mailing list