Is it possible to make mobile, accessible and skinnable client-side Web applications?

Requirements & ideas for a technology code-named proglets

W3C

Bert Bos

W3C Technical Plenary, Boston, March 2, 2005

Bert Bos (W3C) <bert@w3.org>

This talk defines a class of light-weight, Web-based applications that execute on the client-side. They differ from forms and CGI-style applications, in the fact that a part or all of the program logic executes on the client, not just the UI logic. They differ from Java applets, because the technology is targeted at a larger class of programmers and at simpler applications, that are suitable for programming in typical scripting languages.

A lot of aspects could be treated in a talk like this, but we have only 20 minutes. Topics like the choice of scripting language(s), model and syntax of the UI description language, security, session management, predefined programming libraries, supported network protocols, profiles for various devices, packaging, and digital signing will therefore at most be mentioned in passing.

The talk will have to be short, so let's get started: is it possible to make mobile, accessible and skinnable client-side Web applications?

Is it possible?

Yes!

“The End”

Oops, not that short!

History/inspiration

Mosaic supported application/x-csh (not out of the box, because it is a rather large security hole), which probably makes it the first Web client for executing mobile code.

The other technologies mentioned above all have some interesting sides, but also some aspects that make that they are not the solution for proglets. Java is a not a scripting language, but meant for big programming projects. It also doesn't separate the UI from the program. Konfabulator has an XML-based GUI description language and uses Javascript for the program code, but the two are too tightly integrated and Konfabulator “widgets” are not device-independent.

Part 1 – definition of a proglet

The aspects that define a “proglet”

↳ a.k.a. requirements

[skinnable = add skins, not remove skins ☺]

Client-side

Proglet may or may not talk to servers

(It's not about CGI, JSP, PHP, HTTP or online forms)

When talking about “Web applications,” people typically mean a centralized application that is accessed over the Web. The Web browser is used to display the UI for the remote application, but doesn't execute the application itself. The UI is a form, with more (XForms) or less (HTML forms) local validation and reformatting.

Proglets aren't like that. They are more like what used to be called mobile code, programs that are easy to download, need no installation, and run on many different platforms. The point is not that they interact with some remote application. Instead, they are the application.

Of course, it is perfectly possible to use a proglet as a front-end for a remote application. In fact, it might sometimes do a better job of that than a form-based interface, depending on how well the proglet is written. Most applications nowadays communicate with others, and proglets will be no exception, but whether it does or not and what protocols it uses is not part of the definition of proglets.

No installation needed

But also: download, save, and run off-line.

Like HTML pages, proglets can be stored either locally or on a server and can in both cases be started with something as simple as a mouse click. They should download quickly and run without further installation (except as needed for possibly dangerous or privacy-invasive operations, see under Safe below).

One proglet = one URI

... <a href="foo.proglet">foo</a>

... <object data="foo.proglet">...

A single URL is enough to address a proglet, so that it is possible to link a proglet from an HTML page, or include it as an HTML <object>. The proglet may in turn contain multiple resources, such as program modules or UI definitions, which may have their own URLs as well (just like an HTML file may have images and style sheets). Some compound format, such as TAR, ZIP or JAR, may be needed.

Easy to write

Programming language:

UI description language(s):

This means the language(s) they are written in should be fairly high-level, with good support for strings, implicit data-typing with no (or optional) type declarations, using a familiar programming model and syntax, probably Algol-like, maybe with optional OOP facilities. For the (G)UI, a declarative pattern-action language, like CSS, is probably best. There should also be high-level APIs to libraries for reading/writing (or GET/PUT) files on the network.

This distinguishes proglets from Java applets: the programming language is less suited for complex tasks, but better suited for inexperienced programmers; also the UI is not part of the program, but separate, replaceable and written in a different language.

Accessible

Two methods:

⇒ necessary that proglet declares its list of functions

Proglet is still functional without its UI

(See example of declaration later)

Probably the best way to ensure that, is to make the user interface optional, similar to the way CSS is optional for HTML. A user can read a correctly written HTML document with his own UI, ignoring the style sheets provided by the author; likewise, a user should be able to use a proglet without any of the UIs provided by the author. In most cases, the default UI that the user agent offers will be “functional,” rather than optimal and when the author has provided a UI for the particular platform of the the user, the user will want to use that instead. Nevertheless, the possibility to run without the UI is important, not also for accessibility, but also for being able to connect (“pipe”) proglets together.

This is an important part of what makes proglets different from XUL, Flash, Java applets, Konfabulator widgets and DHTML. The program doesn't know what UI is attached to it. There are no variables in the program that represent GUI controls.

Device-independent

Device-independence achieved in the usual way:

Of course, some proglets cannot run everywhere: a jukebox needs a device with sound output…

Device-independence is partly achieved with the same means as accessibility, i.e., abstracting the application from its UI, but also it requires careful thought when designing the standard libraries (built-in functions) of the proglets language(s). Not all functions can be provided by all platforms, but the APIs can be designed in such a way that it is easier to program a fallback, than to let the program crash.

Safe

Proglet is as easy to load as a Web page ⇒
should also be as safe
(no use turning off scripting ☺)

Since a proglet can be opened with the same ease as a Web page, they should be as safe as well. They should run inside some sort of “sandbox,” with no access to the user's file system or other system resources, unless the user explicitly grants access. A system of permissions is probably needed, so the the user can grant access to some resources, but not others: access to persistent storage, read/write access to one directory or to a whole file system, access to system information (CPU type, OS type, etc.) or personal information, limits on CPU and memory usage, etc.

Privacy

Proglet may be front-end for remote service

Needs P3P

HTTP: use header

Other protocol: … TBD

Proglets may send information to remote servers, just like Web forms, and should thus declare what those servers do with the information. If the proglet is downloaded by HTTP, a normal P3P header in the HTTP is probably enough. Otherwise the proglet itself should link to a P3P policy (see metadata below.)

Persistent storage

Despite not having access to the user's file system, a proglet should be able to store data on the user's machine, so that it can resume a previous session after being restarted. This persistent storage is a virtual file system, that is only available to a particular proglet, or to the group of proglets sharing some cryptographic key. The user can grant each proglet a certain amount of persistent storage, including none at all.

Cooperating proglets

Multiple proglets executing in parallel should be able to communicate. The persistent storage mentioned above may include functions for file locks or semaphores for that purpose.

Network operations

Libraries for HTTP, Webdav, SOAP, sockets? …

Trust zones

A proglet can access the network (e.g., to act as a front end for a remote database or to act as a chat program). It needs a socket API (BSD sockets) and probably also a higher-level API, to GET/PUT from/to URIs. Maybe the latter should include WEBDAV and SOAP. Which servers a particular proglet can access is a function of some trust settings in the user agent.

Source code

User agent provides View source

To help spread the technology and to encourage re-use (rather than re-invention) of algorithms, it should be possible for a user to do a “View source” on a proglet, in the same way as on an HTML page. This also helps improve proglets, since interested users can provide patches to the author.

Extensible

The first version of the proglets language(s) won't be perfect and it good to calculate with updates. As computers become more powerful, new built-in functions can be added as well. New UI paradigms may also emerge, necessitating extensions to the UI definition language (or development of a completely new UI language).

Multiple languages

Should there be support for multiple programming languages? A virtual machine? In a later version?

Maybe not in the first version, but in a later version, it would be useful to allow different programming languages, since not all programmers like the same language. E.g., it might be possible eventually to allow proglets to be written in Java as well, so complex programs can be written more easily.

Integration with the Web

Integration is dependent on the facilities provided by the user's platform, but if the platform has both a user agent for proglets and a browser, it should be possible to cut and paste text between them, click on a link to a proglet in the browser, display the proglet in-line in the browser, etc. One of the built-in functions of the proglets language should be a function that directs a browser (if present) to open an HTML page or some URL. (The browser and the proglets user agent may be single program, but need not be. Some platforms may offer only one of the two.)

Not for high-speed graphics?

(Real-time VR games are hard to make device-independent…)

The program part of a proglet cannot directly access the graphics hardware or any input devices (joystick, mouse, keyboard, etc.), because of the requirement for device-independence and accessibility. It has to communicate with the UI manager of the user agent via a serialized stream of commands or events and thus is less suitable for programs such as shoot-em-up games or movie players. Since such programs aren't very device-independent to begin with (they require graphics output), that doesn't seem to be a big drawback. Of course, a proglet should be able to demand its environment to play a movie on its behalf, e.g., by sending the URL of the movie to the platform's browser.

The UI manager, of course, can access the graphics hardware (depending on the platform), so this restriction doesn't mean that proglets are excluded from using graphics acceleration, texture mapping, etc. It just means that communication between the program and the UI involves a parsing and interpretation step, that makes it slow for the program to quickly display large amounts of data, unless the data was stored previously by the UI.

Skins

Not just standard UI controls

Each UI provided with a proglet is, of course, a “skin” for it, but what is meant here is the type of skin consisting of irregularly shaped, colorful images, that make applications such as sound and video players so hard to use (but beautiful to look at). Proglets should be able to have controls that are specially drawn for that application, rather than taken from the standard library of GUI widgets. Ideally, these graphics should be scalable, so they adapt to the user's default font size, either because they are made with a scalable image format, such as SVG, or because the author provided them in various sizes. Probably each kind of GUI widget (window, button, label, etc.) should allow its default look to be overridden by one or more images, while keeping its other characteristics, in particular accessibility features, such as keyboard access.

Graphics output

If the UI is a GUI, it should be able to draw graphs and display images (possibly remote images). This probably means that one of the GUI widgets should be a 2D canvas widget, that can draw on itself.

Metadata and icons

A Proglet should include somewhere in its package of program modules and UIs things like version number, author, feedback address, digital signatures, P3P policies and also one or more icons, that can be used to represent the proglet in a list of book marks or in a directory of downloaded proglets.

Documentation and manuals

If the proglet is a package, it could also include any manuals

Other things in a proglet package could be documentation (for developers) and manuals (for users). The manuals (a.k.a. help files) could be in HTML and cross-linked to the UI, so that users can ask for help and the user agent can display the relevant manual page. Or the user agent can hand the manual page to the platform's help viewer or to a browser.

Localization

When the proglet is downloaded over HTTP, language negotiation can be used to get the version of the UI (and of any manuals, icons or other resources) in the user's preferred language. The proglet itself can also be available in several versions, but that should be less common, since users typically interact with it through (one of) the proglet's UI(s).

application/proglet

A MIME type of its own

The fact that a proglet has its own MIME type is very important. It allows better content negotiation than when a proglet were sent under some generic type, such as application/xml, application/zip or even application/octet-stream.

What the MIME type designates is yet to be decided. It could be a package such as a zip (jar) or MIME multipart message, or it could be a catalog file that links to all the program and skin modules; or both.

Part 2 – towards a solution

A programming language, some UI description languages, some libraries…

A single
program


PC
interfaces,

handheld
interfaces,

car
interfaces, and

appliance
interfaces.

A (hypothetical) example

Proglet package
Skins Program
# Parse the message from the program and
# send each button its part:
/(.)(.)(.)(.)(.)(.)(.)(.)(.)/:
  b1 $1; b2 $2; b3 $3
  b4 $4; b5 $5; b6 $6
  b7 $7; b8 $8; b9 $9.

window main
  title = "Tic Tac Toe"

button b1 (main)
  value = "."
  location = "0 0 20 20"
  /x/: value = "X".
  /o/: value = "O".
  ACTIVATE: print "set 1\n".

# ... 8 similar buttons omitted...

button reset (main)
  value = "Clear"
  location = "0 60 60 20"
  ACTIVATE: print "reset\n".
require Webapp

# Declare the commands the program accepts:
declare_commands [
  ['set', INTEGER],
  ['reset'] ]

def make_move(board)
  # If the game isn't over, make an intelligent move...
  # [...code omitted...]
end

board = ['.', '.', '.', '.', '.', '.', '.', '.', '.']
ready? = false

while c = get_command
  if c[0] == 'reset'
    board = ['.', '.', '.', '.', '.', '.', '.', '.', '.']
  else if board[c[1]] == '.'
    board[c[1]] = 'x'
    make_move(board)
  end
  board.each {|s| puts s}
  puts "\n"
end
# Another UI...
# Another UI...

A (hypothetical) example

Proglet package
Skins Program
# Parse the message from the program and
# send each button its part:
/(.)(.)(.)(.)(.)(.)(.)(.)(.)/:
  b1 $1; b2 $2; b3 $3
  b4 $4; b5 $5; b6 $6
  b7 $7; b8 $8; b9 $9.

window main
  title = "Tic Tac Toe"

button b1 (main)
  value = "."
  location = "0 0 20 20"
  /x/: value = "X".
  /o/: value = "O".
  ACTIVATE: print "set 1\n".

# ... 8 similar buttons omitted...

button reset (main)
  value = "Clear"
  location = "0 60 60 20"
  ACTIVATE: print "reset\n".
require Webapp

# Declare the commands the program accepts:
declare_commands [
  ['set', INTEGER],
  ['reset'] ]

def make_move(board)
  # If the game isn't over, make an intelligent move...
  # [...code omitted...]
end

board = ['.', '.', '.', '.', '.', '.', '.', '.', '.']
ready? = false

while c = get_command
  if c[0] == 'reset'
    board = ['.', '.', '.', '.', '.', '.', '.', '.', '.']
  else if board[c[1]] == '.'
    board[c[1]] = 'x'
    make_move(board)
  end
  board.each {|s| puts s}
  puts "\n"
end
# Another UI...
# Another UI...

A (hypothetical) example

Proglet package
Skins Program
# Parse the message from the program and
# send each button its part:
/(.)(.)(.)(.)(.)(.)(.)(.)(.)/:
  b1 $1; b2 $2; b3 $3
  b4 $4; b5 $5; b6 $6
  b7 $7; b8 $8; b9 $9.

window main
  title = "Tic Tac Toe"

button b1 (main)
  value = "."
  location = "0 0 20 20"
  /x/: value = "X".
  /o/: value = "O".
  ACTIVATE: print "set 1\n".

# ... 8 similar buttons omitted...

button reset (main)
  value = "Clear"
  location = "0 60 60 20"
  ACTIVATE: print "reset\n".
require Webapp

# Declare the commands the program accepts:
declare_commands [
  ['set', INTEGER],
  ['reset'] ]

def make_move(board)
  # If the game isn't over, make an intelligent move...
  # [...code omitted...]
end

board = ['.', '.', '.', '.', '.', '.', '.', '.', '.']
ready? = false

while c = get_command
  if c[0] == 'reset'
    board = ['.', '.', '.', '.', '.', '.', '.', '.', '.']
  else if board[c[1]] == '.'
    board[c[1]] = 'x'
    make_move(board)
  end
  board.each {|s| puts s}
  puts "\n"
end

Conclusion

We can design a proglet technology that is…

Proglets are a category of Web resources that doesn't exist yet. They are complementary to Java Applets, forms and other static documents. They provide a solution for the abuse of HTML and Javascript for simple applications.

It is possible to design them so that they are usable by inexperienced programmers and still remain accessible and device-independent.

Just like HTML documents can be styled with CSS, proglets can have multiple alternative “skins,” even on the same device.

Because the program and the UI are separated and the program declares its functions, a functional (but boring) interface can be synthesized automatically, ensuring accessibility in the case the author didn't provide a suitable skin for the user or the device.

Links

Essays:

This talk: http://www.w3.org/Talks/2005/0302-proglets-Boston/all