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