Wednesday, July 6, 2011

Zen: Rails-Embedded Version

Where
There is now a version of Zen embedded in Ruby on Rails. (I recommend you use the version tagged v0.0.1. Note that there is no period at the end of the tag. It's bundled as a Rails application, so you'll need to start Rails to test it out play with the code.) The exact same version is deployed at zen-rails.heroku.com. Currently, the easier to remember URL onthesamepage.org gets redirected there, and I expect to maintain a link on onthesamepage.org to zen-rails.heroku.com (or wherever Zen-Rails will be publicly deployed).

What
This embedded version of Zen is open source. It is an incomplete, non-optimized, slow implementation of Zen. (It could be greatly sped up by using a non-source version of the Dojo toolkit, but the source version can occasionally facilitate debugging. Update on 9 August: Although I sped up the page loading a bit today, I expect I can speed it up another factor of 10 - 20 by creating a custom build of Dojo and putting it on a CDN. Update on 17 August: Now zen-rails uses a cross-domain version of Dojo hosted on Google's CDN, so it loads much faster—in about 4 seconds. Update on 20 January, 2013: This has been reverted to a slow version for quite awhile; I should have posted a note saying that before.) This version probably does not work in Internet Explorer, for now. (That should get fixed before too long.) This version of Zen does not and will not include proprietary additions to Zen, which are to be developed later.

The latest changes are:
  • it fixes a bug in the debugging functions that made Zen fail in web browsers Chrome and Safari
  • it uses a cross-domain an AJAX call to retrieve a JSON-serialized description of a web page
Coming Soon
Soon Zen should also be able to store and source components and aggregations of components in CouchDB for cross-domain AJAX access by a Zen web page. A test version of Zen already did that, but Safari's strict implementation of the same-origin policy did not support it, so I expect to use Rails as a proxy to a Zen web page for access to CouchDB.

Friday, June 10, 2011

Zen: What Is It Most About?

I get asked a lot what Zen is really. Most of its proposed features are listed in this blog's first two articles, Zen: First Principles and Zen Project #1: A Web Site and a New Technology to Help People Scale the Web. But this article is an attempt to describe the bare essence of Zen, once and for all.

Zen is not just a web CMS (web content management system or WCMS). It is not just a web page editor. In fact, those features might not be well supported in Zen for awhile. But Zen is supposed to have a much more powerful underpinning than WCMS or web page editing.

Zen is, basically:
  1. A web application, no more, no less: it requires no plug-ins, no local storage, no web workers, no Flash, no HTML5, nothing that only works in Firefox or Google Chrome, nothing "special." Why? Because Zen is meant to be universal, free of web-browser dependencies. If you walk into a solar-powered Internet cafe in Timbuktu, Zen should just work. The only caveat is that it might not work on Internet Explorer 6. The fancy stuff—the "bells and whistles"—will be added later, as options.
  2. An application wiki, i.e., "an enhanced wiki that gives users the option to do lightweight end-user programming within the wiki and with ease," according to Wikipedia. Zen's wiki-ness will use a GUI and instant feedback—requiring no special steps like saving, compiling, copying, uploading, deploying, running, starting up, or publishing.
  3. A basic WCMS that can place widgets within widgets, to any degree of nesting. It is not just for 2-dimensional layouts.
  4. A creator of web sites that can be completely indexed by Google and other search engines. Although Zen will specialize in creating single-page web sites and web applications, it will create indexable web pages for the components of those sites and applications so that all the content can be found by the search engines. (Index-ability is important to search engine optimization. Update on May 19, 2012: See Google's Making AJAX Applications Crawlable article in their Webmasters guide.)
There are other features inherent in Zen's technology, but its essential and most visible features or characteristics are the ones listed above. Zen will eventually be augmented by "fancy stuff"—most notably, HTML5—but those parts are not its essence. Perhaps a "Zen-Plus" will follow on to Zen to add very powerful features, but for now, Zen's essence is as described above.

Monday, October 4, 2010

Zen: First Principles

This is the second in a series of articles on Zen, that began with the article 'Zen Project #1: A Web Site and a New Technology to Help People Scale the Web'. Technical aspects of Zen are described at www.tomelam.com.

Zen has ambitious goals. The key to its success will lie in whether it remains true to its unique set of first principles:
  1. Zen is global, i.e. it exists on the Web.
  2. Zen is a zero-install program, i.e. it provides its basic features without browser plug-ins or extensions.
  3. Zen will provide graphical user interfaces for adding many kinds of widgets provided by HTML and JavaScript frameworks to a Zen web page. Of course, if too many frameworks—or the wrong combination of frameworks—are used in a single web page, trouble ensues. Zen does not in general impose any limitations upon the way the widgets and frameworks can be combined, but there is a very safe and easy-to-use version of Zen for general use by all users.
  4. Zen will "engulf the Web": it will provide a user-programmable widget that will embed a "web browser" in a Zen web page. Again, even non-technical users will be able to "program" this web browser to do such things as make any web page dissectible, editable, rearrangeable, and mash-able. It will be possible to embed multiple copies of the "browser widget" in a web page. The user will be able to use Zen to copy or move widgets and components from the embedded web page into the rest of the Zen web page. This principle of "engulfing the Web" is very difficult to remain true to because it implies that web pages will be analyzed by Zen's special web server, which has proxy capabilities and the ability to internally render JavaScript-enabled web pages. The special web server will also allow any page to be hot-linked. [March 15, 2012: As of now, clicking on the "any page to be hot-linked" link only leads to the top of the blog post. Please skip down to the last paragraph of the post. Something about Blogger.com seems to have prevented a link target inside a post to be accessed.] The special web server will also emulate referral links, thereby allowing a web document that can only be accessed through a referral link (not directly via URL) to be accessed from any Zen-enabled web page.
  5. Zen provides many functions like filter and sort that even non-technical users can apply to data sources just by dragging widgets around in the web page. It will be possible to chain many of the functions together to provide more possibilities for data manipulation.
  6. A user will be able to capture a sequence of interactions with their Zen web page such as moving the mouse pointer over a particular kind of widget (the technicalities of what "kind" means here are not very important in this discussion), clicking on a widget or web page component, typing a single character on the keyboard, entering a string of characters in a box, etc. The range of interaction events that can be captured is from the lowest level interaction with a web page (characters and mouse interactions including the clicking upon submit buttons) through any kind of widget interaction. The user can generalize the captured sequence ("parameterize" it) so that it can be applied to a class of situations. He can store it and attach it to a menu or button so that it can be evoked by choosing the menu item or clicking the button. Thereafter when the user of the page containing the parameterized sequence interacts with the page his interactions with the page are circumscribed: his out-of-sequence input is optionally treated as an error and he can be gently guided to follow the sequence. The capabilities of this Zen sequence capture are somewhat elaborated from the basics described here.
  7. A user will be able to create persistent copies of his Zen web pages. These copies will be saved on the Zen web server.
  8. Zen will facilitate a user creating web pages and web applications that do not include the Zen library. After Zen removes itself from these pages and applications, they will only depend upon HTML, one or more already-well-accepted JavaScript libraries, and a minimum of JavaScript "glue." In another way of speaking, Zen will export such pages and applications. Some part of the Zen library will be required to enable all features of captured sequences, however.
  9. Zen can be augmented with features that break its first principles, but the result will not be Zen.
  10. As an exception to First Principle #1, Zen can be injected into any web page, via web browser add-ons or extensions, to allow the page to be redesigned and mashed up with other content and to gain Zen features. However, only content managed by cooperative JavaScript libraries will be fully compatible with Zen. A cooperative library must facilitate the tracking of every widget and every "DOM element" that the library adds to or subtracts from the web page. (DOM elements are the "atoms" or structural components of a web page. Tables, divisions of a page, paragraphs, lists, and list items, among other things, are represented by DOM elements.) Furthermore, a cooperative library must facilitate the tracking of actions that it can perform in response to the user's interaction with the web page or in response to data received from the web server. (Such prepared actions are called "event handlers." They respond to interaction such as mouse clicking and key pressing.) The word facilitate is a bit ambiguous: it can mean "make it possible" or "make it easy." So far as Zen is concerned, a cooperative library should only have to make possible the things just mentioned, but in its first iterations, Zen might only be fully compatible with libraries that make those things easy.
I might add more first principles to this list later.

I am still seeking collaborations from companies, investors, technology marketing experts, and programmers. Please post your comments.

Friday, September 3, 2010

Zen Project #1: A Web Site and a New Technology to Help People Scale the Web

Ascending and descending, by M.C. Escher
M.C. Escher's lithograph "Ascending and Descending"
In this, the first in a series of articles on Zen, I describe a large and general problem people have as users of the Web. Then I describe a set of technologies I am working on (more fully described at www.tomelam.com), which I call Zen, that could significantly reduce the problem. On average, each of us consumes three times as much information as we did in 1960 and checks 40 web sites a day, according to a 24 August article on National Public Radio's web site. New York Times articles tell us that this makes us impatient, forgetful, anxious, shallow, and unfocused. Information is our crack cocaine, and we should have been in rehab long ago. An information fix is even called a hit! (See below.)

Part of the problem is the difficulty in finding what we seek—even when we know it is on the Web. When we search for something on the Web, we hope that the process will be linear and finite, but we get lost in a strange loop, a tangled hierarchy of searching, scanning, surfing, and subscribing that we try to climb down like a staircase. In our search for digital nirvana, employing bookmarks, tags, annotations, hyperlinks, search, indices, rankings, ratings, and subscriptions, we find ourselves skipping up and down between various levels of metadata and web resources, like the monks trudging endlessly on the paradoxical, looped staircase in Escher's lithograph "Ascending and Descending," shown above. On our way we collect scores of bookmarks and piles of paper notes, and get a headache and short temper, too.

Let us try to outline the stages or hierarchies of the most general search:
  1. Search for an answer to a question using a general purpose or specialized "search engine," typically by entering keywords, phrases, and parameters (e.g., date, tags, domain, URL, links-to, similar-to). Items that match the query criteria are called hits. Hits are presented in lists or in hierarchical outlines and are typically ordered by criteria such as relevance or paid placement. Searching is optional if we can replace the list or outline of hits with a list or outline of resources from categories in a Web directory. Examples of directories of the whole Web are Yahoo! Directory and the Open Directory Project. Many specialized directories of web resources also exist.
  2. Examine brief descriptions, summaries, or snippets of the items in the list or outline, if available.
  3. Open the links to the relevant-looking hits—in new windows or tabs if possible. Evaluate these linked-to resources for fitness to our purpose.
This linear procedure can often miss highly specialized information. Sometimes this happens because we weren't able to choose the best search query at the outset: we didn't have enough information to choose well. Sometimes we might not even know information is available pertaining to our problem. And sometimes we really need information from the "deep web," i.e., data available only behind a form-oriented user interface, such as an airline fare search interface or a phone directory search interface. The "deep web" is generally not indexable by web search engines ("spiders" to be more precise). A better alternative to this hit-and-miss search technique is "idea search," also called "idea navigation." (See Google's idea search and Stewart, Scott, and Zelevinsky's research.) The problem with idea navigation is that it is only in its research phase of existence.

We often resort to trial-and-error variations of our search, but this is usually frustrating. A better approach than the trial-and-error, hit-or-miss approach is to refine each level of hierarchy, as described above, by applying the whole search procedure to that level. That is, we seek information resources, meta-resources (e.g., search engines), and methods of search. A method of search can involve subscription to a forum, wiki, mailing list, social bookmarking service (like Delicious, Digg, and reddit), or social media so that we can make new friends and acquaintances (or communicate with old friends) and get help from them. Or it might be to subscribe to pertinent blogs in an attempt to find out which experts are sharing helpful information on our topic. (See Google Reader and Google Blog Search.) The "helpful information" could be the final solution we are seeking, or it could be a set of new keywords we hadn't thought of or known, or it could be some other forum, wiki, blog, mailing list, chat room, or other resource. The results on topic-specific forums, wikis, blogs, mailing lists, and chat rooms will be pre-filtered by design, avoiding completely irrelevant hits that can swamp the relevant ones in a general-purpose whole-Web search engine. There are many other strategies for refining the levels of search hierarchy.

Other problems arise in our research on the Web and in remembering what we find: too many web pages and no adequate means of keeping track of them. If we open a window for each web page that looks pertinent to our search, we can soon overburden our web browser or our operating system. The browser can crash, or, in the case of Google Chrome, a tab pane can crash. Web browsing can slow to a desperate crawl. If we bookmark our web pages, we lose time navigating the browser's bookmark manager and might not be able to find the bookmarks later anyway.

So what's the answer, prior to the advent of useful "idea browsing"? I propose we make it possible to write the Web as easily as desktop text documents can be written, and to implement some of the original ideas about hypertext like transclusion, so one single Web page becomes our notebook and scrapbook. The reader might think of Evernote or Google Notebook, but the kernel of the technology I'm working on focuses on organizing and tuning the user's view of and interaction with the Web and on being universally usable, globally, by anyone with a reasonably up-to-date web browser, without browser plug-ins. (I will even try to support Internet Explorer 6.) On top of the kernel, many web-server-assisted capabilities can be built.

Zen will allow the user to get close to the process of refining his searches, so that he can keep meta-resources, final results, and records of how he got results at his fingertips, under his control, "programmed" via a simple visual interface. He should be able to "program the Internet" by dragging and flowing links, text, data in microformats, and media from any web page into a web page he controls and saves to a web server. He should be able to use those links as bookmarks. He should be able to organize the links, text, and media in folders, tab panes, accordion panes, and other web widgets and lazy-load them so that time is not taken when he re-opens his page at a later date. Only the open pages or other widgets that contain the links, text, data, and media should be loaded. (That's how a lazy-loaded pane works.) Zen will even allow lazy-loaded widgets to be put into other lazy-loaded widgets. Many of the web-server-assisted services mentioned above and below can easily be codified and automated so that they can be included as widgets on a web page.

The user will be able to share these pages over the Web with other people very easily, in many ways. The special web server will serve his web page and will use its in-built proxy capabilities to enable the user's web page to be composed of content from multiple web sites. Such a composition is called a mashup. The JavaScript inside the user's web page will enable many kinds of mashup to be created even without help from the special web server. These JavaScript-enabled mashups will use certain kinds of mashable content from multiple web sites. Microformats, mentioned above, can assist the mashups to "digest" and pour content from disparate places into the page. For example, much social media, including the present blog, can be accessed via web feeds using an RSS or Atom microformat. This allows the media to be formatted by a news aggregator for human consumption or inserted into a web page.

Various features of Zen will allow development of a web page to proceed smoothly. The special web server will also enable the user's Web navigation to be recorded automatically. Variations of the user's web page will be as easily produced as Git branches, because a Git-like "filesystem" on the web server will record the components of the web page analogously to Git commits. The system must be easy to understand without much training.

I am beginning to program Zen to enable this writable Web. Some description of the technology and some videos of my earliest prototypes of the technology are available at www.tomelam.com. Eventually, I will create a web site offering registrations for people to create their own portals to the Web. These will be real portals: most of the media content in the web pages will be hot-linked, not copied. For web sites that disallow hot-linking, the special web proxy will be used to work around the limitation by imitating web browsers that such web sites expect to deal with. I am hoping that many people will be interested in the technology, and I am seeking collaborations from companies, investors, technology marketing experts, and programmers. Please post your comments.