Skip to content
This repository has been archived by the owner on Jun 30, 2018. It is now read-only.

Defining Linearization #174

Closed
WayneEDick opened this issue Mar 27, 2017 · 3 comments
Closed

Defining Linearization #174

WayneEDick opened this issue Mar 27, 2017 · 3 comments

Comments

@WayneEDick
Copy link
Contributor

If we think of a web page linearization means arranging all block level information in a single column or row depending on how your language organizes information. It is a geometric arrangement. Organizing information in a one-dimensional presentation.

Is that what we want, or are we really after a temporal sequence.

What we want is for the use to move from window to window in the direction that is natural to the underlying language, and to be able to perceive, operate and understand all content by following this traversal. Note that a one-dimensional geometric layout is sufficient to satisfy this criterion, but it is not necessary.

I think linearization is really something like this.

Content can be traversed as a sequence of single purpose content units that exhausts all information on the page or within the application.

A content unit (for lack of a better term) is a blob of web content that can be paged through in manner that is compatible with the language in use.

Example: A data table is a content unit. Each cell in the data table may contain a lot of information. Taking left to right language for an example. Each cell should present in a way that word wraps horizontally, but may extent beyond one screen vertically. Both the table and each cell is a content unit. The table is a structure that expresses a functional relationship between rows and columns as representative by the values in data cells. Each cells purpose is to hold the content of the data cell value.

Example 2. A web based Integrated Development Environment (IDE)
For simplicity lets just assume that the normal 2-dimensional layout has on top: Heading Information and Controls (H), Rows of Toolbars (T), A left work pane (L), a right work pane (R), An editor area (E) and some footer stuff (F). Now, H, T, L, R and F all fit on screen, but the content in E, a body of program code may extend for miles. Each area is a single purpose unit. Some fit on screen, some require language compatible scrolling like E. Now, nothing prevents adding controls that H, T, L, R, E and F can each take the entire screen of the user requires it. Moreover, the items that fit on one screen is small print may not fit without scrolling if the font size is say 700%. However any one of them can function like the edit area E without difficulty.

So a sequence of single purpose units H, T,L, R, E, F exists that exhausts the content. The users actual execution sequence might be H, E, T, E, L, E, R, E, F, E, T. Not that the user could experience the application as a sequence of single purpose content units only using scrolling that was natural to the language in use.

I need help with this but I think this is really what linearization is. Reflow to single column is just one implementation.

@DavidMacDonald
Copy link
Contributor

I think expecting text in a table cell to wrap is a big ask of developers. Isn't it?

@steverep
Copy link
Member

Recommend this issue be closed as the Linearization SC did not reach working group consensus and thus will not be in 2.1. Much of the desired content requirements, however, are covered by the Zoom Content SC.

@awkawk
Copy link
Member

awkawk commented Sep 15, 2017

@WayneEDick We've discussed this content on the calls with you, so closing this issue.

@awkawk awkawk closed this as completed Sep 15, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants