Choosing a Content Simplification Option

[Justin Obara]

On 2013-06-05, at 12:00 PM, "Cheetham, Anastasia" <acheetham at ocadu.ca> wrote:

> 
> 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.

My understanding of option 1 is that the onus will be on the integrator to provide the correct styles. In some cases this may mean piggybacking on the responsive styles, others it might be slightly alternate styles. These decisions will be up to the designer/integrator of the site. In terms of work for us, we'll need to support a mechanism for switching between styles; which may be a class on the body. Our demo and integrations that we perform will need to have these design decisions thought out and implemented, and can be used as examples for others.

> 
>> 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 ocadu.ca           Inclusive Design Institute
>                                        OCAD University
> 
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work