Re: A successor to framesets

On Wed, Apr 1, 2015 at 4:56 PM, Sean Hogan <shogun70@gmail.com> wrote:
> HTML framesets were the original single-page-application.
>
> Despite the flaws (mostly not being content-first), at least servers
> were emitting reasonably simple HTML including real hyperlinks and
> forms.
>
> What would framesets be like if we designed them today?
>
> In the linked video I make the case for a successor to framesets.
> It is 25 minutes but that is unavoidable.
>
>     https://youtu.be/qVdAc8_ppao
>
> The first half illustrates *why* this is important / better than alternatives,
> with actual demonstrations (which you should try for yourself to
> ensure I'm not cheating).
>
> The second half provides some insight into how I've approached this,
> again with demonstrations.
>

The demonstrations in the video may need some explanation /
justification, so here goes.

1. "Modern" web-development seems to assume that Javascript in the
browser is guaranteed to be available.
Sites developed with JS frameworks - such as AngularJS - may give
little to none consideration to scenarios where browser-scripting
fails. Angular's own documentation site - https://docs.angularjs.org/
- is one such site.
But there are more failure modes for browser scripting than just
"javascript disabled".
(Angular's doc site is used for these demonstrations).

a) The JS framework doesn't support the browser (4:00).
Typically frameworks officially won't support older browsers (like IE8
in this example).

b) Site-specific code crashes (4:20)
Although Angular supports IE9, the site-specific code made an
assumption about available JS features -
specifically that `window.console` was always available.
On IE9 this caused initialization to crash.
However, opening the browser's dev tools would make `window.console`
available and allow init to succeed.
Thus even if the site-developer was manually testing on IE9 he might
not be aware that the site would fail for the end-user.

c) Single-Point-of-Failure (5:10)
If scripts are sourced from a different domain to the web-site and the
scripts server is down or blocked then init cannot begin.

d) The browser doesn't know when the *content* is ready (not in video)
This affects search-engines and web archives.
e.g. an archived page from Angular's docs which doesn't contain the
primary content -
    https://web.archive.org/web/20141021094927/https://docs.angularjs.org/api/ng/function/angular.forEach


2. There have been some suggestions that server-rendering of
landing-pages is sufficient to work-around the potential failure of
browser scripts. In general this will give a false sense of security
(see 2:10).

https://mobile.twitter.com was initially designed to be
fully-functional without JS (still is on Chrome and IE).
https://twitter.com renders landing-pages on the server, but because
it was designed as a JS framework site
it is limited to read-only mode when JS fails - cannot tweet, reply,
follow, etc.


3. For some (cherry-picked) scenarios JS frameworks provide behavior
that could be likened to highly evolved framesets (see Angular /
frameset comparison at 6:40).

While the JS framework based site offers a better UI, at least the
frameset site was emitting HTML pages which were viewable and even
usable without the frameset. (skip to 8:20 for a look under the hood
of both approaches)

This is also makes the frameset site more amenable to archiving. e.g. see
   https://web.archive.org/web/20011124054818/http://java.sun.com/j2ee/sdk_1.2.1/techdocs/api/javax/activation/CommandObject.html

which is not only readable content generated 15 years ago, it was also
archived from a site that ceased to exist over 5 years ago.


4. Frameset sites often look and feel a bit clunky.
Framesets also have several issues and potential failure modes, including:
- frameset-first not content-first (so the URL in address-bar doesn't
match the primary content)
- the content markup needs to be aware of the frameset layout
- frames are a new window context (relatively heavy and framed content
can not simply inherit CSS and JS context)

It can be hard to look at a "modern" site and imagine reworking it as
a frameset site, even an evolved frameset site.
But there's no reason evolved framesets should have the same issues /
requirements as the original frameset design -
it should be one of the goals of a frameset redesign that it is
compatible with any fully-functional-without-JS web-site.

a) A documentation set created by 18 year old HTML generator software
(with no frameset capability)
can be transformed into an evolved frameset site (based on Angular's
documentation site)
without *any* modification to the content (except the addition of a
single boot-script to each page)

See 13:20 for the site overview. Skip to 20:00 for the evolved
frameset demonstration.

Naturally on browsers which do not support history.pushState (e.g.
IE9) the frameset isn't applied
and the site is unenhanced (but still fully-functional).

b) A very simple site intended for smaller devices - single column,
primary-content only, fully-functional without JS - can be transformed
into an evolved frameset site
without *any* modification to the content (except the addition of a
single boot-script to each page)

See 0:29.

Note that this site has a multi-page Table-of-Contents which the
evolved frameset transforms into the typical expandable/collapsible
T.O.C. using a fully declarative recursive-transclusion.

Naturally it is possible for the end-user to switch-off the frameset
enhancement if desired.

c) It should be possible to implement the twitter.com UI with an
evolved frameset approach on top of the fully-functional-without-JS
mobile.twitter.com

See 22:40 for a demonstration using a JS bookmarklet to boot the
frameset enhancement.


> I'll continue later with details of the differences / enhancements
> required to make the frameset concept live up to today's expectations.
>
> regards,
> Sean

Received on Tuesday, 7 April 2015 13:00:05 UTC