This white paper presents a profoundly unique, personalized, and adaptive approach to the creation of web experiences—a radically new approach usable by a very broad class of people. It links to live prototypes of web-page-editor interfaces to demonstrate that it could be possible for end users to build their own web pages from scratch and decide every detail of their web pages' look and structure simply, easily, and quickly, without any prior learning. The possibilities go far beyond just editing web pages, which this paper also intends to show. The code name for this approach and its implementation (under development) is Zen. The unique selling point (USP) of Zen will be in-context, instant-feedback, full-featured editing of website or web app structure, function, and styling. In particular, Zen will make it easy for users to create any kind of valid HTML structure in web pages without getting into the complexity or distraction of code and will make it easy for them to create basic-level programs using visual-programming principles adopted from successful visual-programming languages for children. Most importantly, all this "development" and its deployment can be continuous, carried on by a website's users of all levels of experience. Since, with Zen, deploying and sharing a new application could be as simple as clicking a Share or Deploy button, self-organizing user communities might develop altogether novel applications.
Many user-programmed systems for customizing websites are described in the book No Code Required: Giving Users Tools to Transform the Web 4 but no system for creating web apps. With Zen, many kinds of web apps will be created as simply as are the applications written by children in specially designed visual programming languages. (Specific references to these child-oriented systems are provided later in this paper.)
Though many of the problems of creating end-user programming environments have been overcome to some degree or other, there is one obstacle to it that still has no embeddable (library-based) solution—as opposed to a framework-based solution. That is a problem that arises from the stateless nature of the Web. To illustrate, we take an example of a typical program that asks a user's name and greets him accordingly:
The flow of this program is obvious, but even such a simple program must be written on a platform that hides complexity: it must be halted, waiting for a response. This is true no matter what the programming platform is. For desktop applications, the operating system provides system calls, a scheduler, and library functions that allow program flow to mirror the thread or process of the program, as in the example. For web apps there is no underlying operating system to support the halting and restarting of the program. However, some languages, such as Scheme, support continuations,5 which allow programs written in that language to be halted and restarted using language-level mechanisms (as opposed to operating-styem system calls and library functions). Zen will utilize continuations to simplify the end-user's programming tasks.
PRINT "What is your name?" INPUT "(Enter your name.)", $name PRINT PRINT "Hello, "; $name; ", how are you today?"
Now, a quarter of a century later, the position of the A-grade web browsers5, 6, 7, 8 as the central applications for online sharing seems unshakeable. Yet till today, not one A-grade web browser has full-fledged web-authoring capabilities. (We shall discuss the browser features contentEditable and designMode later, since these do not, without external programming, constitute web-authoring capabilities.) The direct descendents of Berners-Lee's early web-page editing application are visual web-page editors in three broad categories:
All the well-known WYSIWYG web-page composers, whether standalone or embedded,
treat web-page composition like word-processing—that is, like a layout
or 2-D-drawing problem—rather than as an organizational
(structured, semantic, dynamic-design) problem.
Typically visual web-page composers are designed
merely to provide a gentle approach to HTML editing,
leaving out important aspects like styling based upon semantic meaning;
span elements; reactive widgets; and dynamic (AJAX-enabled) web pages.
They often sport a button to switch to an HTML-source view.
Their interfaces are reminiscent of IDEs or RAD tools provided by frameworks
used by web-developer frameworks.
Indeed, WYSIWYG web-page composers are sometimes included in IDEs.
The HTML they produce tends not to be "clean," in the sense that it contains
excess pieces of HTML, and not well-behaved, as explained by Nick Santos.9
The HTML they produce gets dirtier and dirtier as the user makes more and more
changes to the web page.
is that the jobs they are tasked with are extremely difficult and not well supported by web browsers.
Piotrek Koszuliński, lead developer of CKEditor, has written
a detailed technical explanation10
of why the key browser feature supporting web-page editing—
both flawed and indispensable.
Some of his points are:
<b>for the bold command.
contentEditable"are incomplete and/or inconsistent and buggy."
contentEditableuncovers many large difficulties in correctly handling composition events (which allow multiple keystrokes to form an accented letter, a complex Japanese character, or a letter with a diacritic) without breaking editing on an iPad, the keystrokes for jumping over words, shake-to-undo on the iPhone, spell checking, and screen readers.
Nick Santos explains how HTML is not well behaved in WYSIWYG editors.
For example, he says, all the forms:
should be treated the same by the WYSIWYG editor.
An edit to any of these forms should be treated the same,
but, as he says, "For many ContentEditable implementations on the web,
some invisible character or empty span tag may slip into the HTML,
so that two ContentEditable elements behave totally differently (even though they look the same)."
According to Dan Dascalescu,11 in a survey of about 60 in-browser, WYSIWYG editors, only one editor could paste images directly from the clipboard.
Here are screenshots of a few of the many composers in this class, leaving aside the composers tied to heavyweight integrated development environments:
Maqetta, although its development is inactive, provides an interesting and unique approach to WYSIWYG web-page composition, in that it
[This section is to be expanded to cover a representative set of WYSIWYM composers.]
WYMeditor is the best-known WYSIWYM web-page composer.
The values driving Zen's development are:
We have explored the values and principles behind the creation of the Zen system. Now let's explore some of the practices to be followed in Zen's creation.
Present-day WYSIWYG and WYSIWYM web-page composers immediately confront the user with web-page structure details, requiring the user to prematurely optimize his web page. With these composers, the web-page under construction is dominated by a pallette of HTML elements with which the user can "paint" a web page. Some of these composers offer the user a view of the web page that is strewn with icons representing HTML elements.
Zen will take a different approach. In Zen, HTML elements making up the web page will represent themselves at the top-level view, with all the obscurity of detail that implies, but when Zen's node browser is open, Zen will be show a view of the web page with all borders and margins styled in such a way that, to the extent possible, all block boxes, inline boxes, and inline-block boxes21 are visible (Figure 7).
(Other display styles besides block, inline, and inline-block will be modeled by Zen in a subsequent release.) Zen will provide whatever kinds of object-browsers are necessary to unobscure details of the page-as-an-object. Although the details have not yet been worked out, hope and inspiration are provided by the 3D View tool, and by the Tilt 3D add-on, for the Firefox browser (Figure 8).
The user will be able to select any node that can be the target of a mouse event. In node-selection mode, passing the mouse pointer over nodes will highlight them one at a time (Figure 9).
When the user wants to add an HTML element to his web page,
Zen will first present a choice of block, inline, and inline-block box types,
because in Zen's paradighm, the visual behavior of a box is mainly determined
by its display sytle, not by HTML tag type.
This is demonstrated by the w3schools.com's
"Tryit Editor" page for converting
<li> HTML elements into a
Using Zen's paradigm, with virtually zero learning, the user could intuitively mock up a web page
using only block, inline, and inline-block boxes,
and convert it piece by piece into semantic markup.
Or he could set the HTML element tag of each element immediately when adding
it to the web page.
Zen will allow the user to inspect and manipulate these boxes in a way pioneered and developed by Smalltalk and Smalltalk variants, using inspectors and browsers to inspect live web-page objects. For a relatively gentle introduction to Smalltalk-style inspectors and browsers, see Cincom Smalltalk's tutorials (Figures 10 and 11). The specific HTML tag of an HTML element will be a detail to be drilled down to rather than a primary detail of interest.
In spite of these strict limitations, Zen as a building block for web servers and web frameworks is anticipated to be a game-changing addition to present-day website and web-app techniques. In some cases, Zen might even be developed to itself reflect changes to content, structure, and style back to sources, using a bit of code on the back end (i.e. on the web server). Perhaps, for example, in WebDAV-enabled websites—Zen could relatively easily be leveraged to rewrite web-page source, including stylesheets. On the other hand, using Zen only as a low-level, embedded, solid building block, it should be possible to augment web frameworks of many types to achieve a new, higher level of interactivity and customization in web applications.
[This section is to be greatly expanded.]
Presently, the customization of templates, plugins, and modules for website builders and web CMSs and the creation of novel comment systems, forums, wikis, and presently unimagined communication systems are far outside the bounds of casual web authorship.
Some concessions to manipulability are necessary so that Zen can successfully edit all webpages. When HTML elements are grabbed Zen should temporarily apply suitable styles to HTML elements like high-contrast borders to make them visible during element selection. When the display-style property of an HTML element is none, Zen should make it possible for users to temporarily set it to another value so the element can be seen. Likewise, wherever desired, Zen should employ similar tactics to make all elements visible and manipulable, whether they are too small; too big; too transparent; or animated. Zen should employ intuitive, adaptive, custom cursors with contrast and distinctive patterns that show up with whatever colors are behind them. The animations in Figures 14 and 15 are actual screen recordings of rough-prototype GUIs for rearranging NodeLists that contain just blocks or just inlines, respectively:
[This section needs a complete overhaul. Possibly the spectrum analogy should be taken out.]
We must determine the scope of the issues Zen will address, which appears to be huge. Zen is meant to offer a uniquely democratizing way of creating web experiences by avoiding code and instead allowing a Zen user a way to directly manipulate every parameter of his web page to which a metaphor can be applied: block elements can be resized by grabbing their edges; block, inline, and inline-block elements can be grabbed and rearranged; etc. Every time the user changes an aspect of style via Zen, Zen will optionally apply the change to the memory-resident stylesheet holding the previous value of that style or to a new memory-resident stylesheet specific to the element selected for the style. Other options, such as applying the change to a selector chosen or created by Zen, will be offered (to be determined).
There are many difficulties or problems in implementing simple ideas on the Web due to complexities at the Red End and the leaky abstractions at the Violet End. First we shall list just a few of those problems—not in a very systematic way, but almost like a small collection of anecdotes. After creating an initial small list of problems, we shall take an initial, inadequate stab at listing a set of "solutions". After this first, inadequate attempt, we shall delineate the method we are adopting to conquer them with a set of technologies I have loosely been calling "Zen". Finally, we shall attempt to discover a systematic way of cataloging problems with the Web experience so that functional specifications can be created for software layers and modules to improve the Web experience systematically.
Problem #1: Paucity of means for nontechnical people to author Web documents and websites. One of the biggest problems or shortcomings of current web browsers is their lack of authoring facilities.
Problem #2: No utility for Web copy/cut/paste/mashup. To effectively manage the tremendous load of linked information raining down on him, the Web user should have a robust utility for managing hypermedia in the native environment in which he encounters that hypermedia—the Web environment. A utility built upon the Web can have features that a desktop utility cannot have, foremost of which are instantaneous change and ubiquitous access. The Web user should have high-quality, proven Web user interface shortcuts most appropriate to manipulating information from the Web—for example, the "Rich Interaction" patterns described in the Yahoo Design Pattern Library—so he can quickly clip, mash together, and rearrange information from the Web. This interface must interwork with any A-grade web browser. Incomplete, specialized, "opinionated" services, such as EverNote and Instapaper, do not support the ad hoc creation of drawers, panels, and dialogs, which are necessary to cut, paste, transclude25, organize, associate, link, tag, and hide blocks of information. This problem is inherently related to Problem #1, but it is also related to various Web standards, such as the X-Frame-Options standard.26
Problem #3: Limits to the ability to remember paths through the hypermedia sphere. In 2016, decades after the invention of virtual memory, web browsers still can't get enough memory, causing themselves and their host operating systems to malfunction, to crash, or to function poorly. Never mind the waste of the Web user's time. When the "too many tabs" problem forces the user to close tabs, or causes the browser to slow to a crawl, or crashes the browser, the reminders to the user about how he discovered the Web pages he visited get lost. This is a travesty because many of the user's research insights are won by a hard, painful, lengthy search.27 For now, the problem can only be somewhat ameliorated by adopting rare, non-free tools, such as the Tabs Outliner plugin for the Chrome web browser.28 The right juxtaposition, encapsulation, and highlighting of blocks of information would make it unnecessary to keep open many browser tabs at once and would make it possible to record the user's path through the hypermedia sphere. To make these kinds of arrangement easy, a new utility is necessary.
Problem #4: Bookmark managers inbuilt to web browsers are inadequate for their main purpose. They are too slow to respond to user input. Furthermore, they do not have even the most basic, useful organizational utilities— for example, an interface, such as the desktop's drag-and-drop interface for folders and files, or automatic Web-page-content indexing and retrieval based upon content. Many web services that analyze websites could be proxied automatically by the Web browser: services such as Alexa.com (formerly providing free information), the WHOIS service, and Yahoo's free web service that provides semantic analysis of a website and provides a description of that website.29 Inbuilt bookmark managers are tied to a particular web browser, which forces dependency upon the user—not a good thing.
Problem #5: Lack of personal ownership of bookmarks. Web services such as Xmarks, which archive a user's bookmarks, force the user to give up ultimate responsibility for his own bookmarks and put the bookmarks into the hands of a company or organisation that could go out of existence or suspend services.30, 31, 32 Xmarks was even made unavailable for awhile in India by court order.33 In the last few years there has been panic34, 35 and uncertainty36, 37 surrounding the spate of security breaches by web services that have revealed clients' sensitive data, such as usernames, passwords, and credit-card credentials.38, 39 There should be a utility to make a Web user's bookmarks available offline and/or on the user's own website.
Problem #6: There is no universally available bookmark file facility. Online collaboration is not supported by good integration of bookmark files with the OS desktop. For example, on a Mac, dragging a URL from Safari's address bar to the desktop creates a file with type "webloc" that MS Windows does not understand by default. It is possible to create a file with type "url" that Windows, Mac, and Ubuntu all understand, but this is not currently happening.
Now we shall make our first foray into describing Zen. How do we propose to solve the problems listed in "Introduction"? Which of the following do we want to focus upon?
Whichever path we choose—the creation of an isolated silo of technology or the utility belt of tools—there are some data-wrangling capabilities it seems Web users should be getting for free, but aren't. These could be part of a Zen Manifesto:
There is a very specific set of user needs that a "Zen website" could uniquely fulfil. At least some of these are:
If there is a site objective, then there must be a website. If that website has a tight focus, it must be oriented toward a particular segment of its entire potential user population (that is, anyone who comes to the website). My initial attempt to segment users was this:
Some Zen website use cases could be:
How to convey the proper central concept behind the "Zen website"? Is the central concept for the Zen website all about being "on the same page"? Would a better encapsulation of the gestalt of Zen be "own the web" or "your web" or "my web" or "mash the web"? Possible catch phrases to encapsulate the gestalt of Zen are:
mecould convey the personalization aspect of Zen.