> This week in Switzerland, Rohit extolled the virtues of declarative
> user interfaces and I sat there and listened, wondering, "Yeah, why
> haven't Web <form>s changed in the last four years?"
You skipped the big reason: because everyone is working around them with
operational code: scripts, to some degree, and Java/mobile code to a lesser
degree. Evolution of declarative form hooks stopped after Mosaic went under in
favor of commercial browsers. Operational code is a form of lockin.
Perhaps the public release of Communicator will allow up to innovate new form
tags, but the flipside is unviersality: there's no way in hell we're fgoing to
see "Best Viewed with OpenScape".
Form tags, as a declarative, across-the-board UI thing, requires forceful
leadership to update -- W3C, in short, dictating the need back to its core
members. It's not a pripority there, either; and the dayt of massive HTML
upgrades is passed. It's amazing to me, also, it's lasted this long without
major complaint.
Or do people not have the imagination to ask, "why can't any UI display I see
on my desktop OS end up on a web page without writing custom platform-specific
code?
But everyone's going Turing-complete: even W3C's DOM.
(which brings up the question: what should W3C's SUB group be doing?)
> Worse, when we gave our talk on XML in Basel, it became painfully clear
> that just because you can specify new elements and new attributes using
> XML, that you cannot necessarily ascribe to those new elements and
> attributes some new behaviors -- for example, how DOES one write a
> <form> DTD that appropriately encapsulates the behavior of <form>s as
> they exist on the Web today? The short answer is, you can't: that's not
> something that DTDs can do.
Nor should it, butt-head! DTDs are Data defintions, at best data dictionaries.
They are not for BEHAVIOR. It is appropriate to say an attribute is of
semantic type location, hence amenable to viewing on a map, in a list, in 3d,
etc. But not to say, "you must pick two locations more than 5 miles apart,
...".
Semantic/behavior defintions will always require some scripting, true, so what
seems to be pointed at is a hook for the "semantic style sheet" == DOM Level >
1.
But what of the declarative? Well, that's the hook. The key is to attach a
data type to attributes, an URL which describes the controlling authority for
hte namespace of possible values ( iata.org/citycodes ) and hence, provides a
proper key for searching out plugins to render such (
javasoft.com/catalog/travelwidgets/jmapper ).
> <form>s on the Web today are powerful, yes, but clearly they do not
> represent the be all and end all of declarative UI design. For the most
> part, the only thing I can type into a form is text; not a signature
> written from a stylus, not a jpeg image (though I guess I could just
Bzzt! jot has been a supported INPUT TYPE for a long time; digital ink was
supported in Mosaic releases. But it's not an INPUT TYPE that's caught on, no,
not even with the Pilot's popularity.
> give a URL pointing to that image), and certainly not an XML-marked up
Bzzt! file upload.
> business card that I can drag and drop onto the <form> and have the
> appropriate argument fields automatically fill in. The functional
Bzzt! The *effect* of this has been long wished-for; see OPS. But, the
standard hook would be as simple as adopting a convention for input names:
fileds names fname and lname -- or better yet, filed names as URLs themselves,
which Hallam-Baker even proposed lo many years ago. If there's a standard key
to index off of, "template" fillin becomes very likely -as well as
'drag-and-drop' fillin. See #1 below.
> description used in <form>s today -- "it's a text stream" -- is not as
> useful as knowing what *type* of text stream it is: e.g., Fedex tracking
> codes. Knowing the type allows me to automate the use of that
> information better. WIDL for markup is a giant step forward, but a full
> solution needs to incorporate the User Interface as well.
Bzzt! WIDL *isn't* used for markup. The original developer/publisher of an
input form doesn't change to accomodate any of this. WIDL files are external
metadata about pages.
Now, I *would* like to replace InterfaceBuilder with <forms>: what's stopping
me? What are the blocks to describing any typicsl NeXTstep UI in XML?
> I guess the startling revelation here is that the UI community has done
> lots of work on declarative UIs, but they don't seem to want to (and/or
> they just plain cannot) talk with the Web community. Meanwhile, the Web
> community, rather than extend <form>s, has moved to more operationally
> specified UI's using VBscript, JavaScript, &c.
Bzzt! Not a lot. We are studying a few isolated examples, like Szekeley et
al's HUMANOID; and a handful of model-based systems that hook constraints to
data members (e.g. SELF). But there isn't any research precedent to core
formats for describing UIs, especially in a platform-independent UI --no,
molre importantly, media-independent UI. Even the work on screen decomposition
for audio and nonvisual use is based on the crudest of input equivalences --
screen scrapers -- rather than the rich affordances of declarative <forms>.
> What the Web needs now (lest declarative UIs be swept into the dustbins
> of history to make room for operational UIs) is someone (preferably in
> the UI community) to do some work on improving <form>s. So here are
> some FoRK ideas of things to add to <FoRM>s that I scribbled down on the
> airplane back from Zurich:
Lose the cutesy caps. INTeRCaPS are for kids!
(and FoRK is the only one around here...)
0. Who has been thinking about this since Dave Raggett's original whinging?
> 1. STRICTLY TYPED ARGUMENTS.
Attach a URL descirbing the attribute to every XML attribute in the DTD
syntax. Will XML-Data handle this?
> 2. DYNAMIC DATA LOADING.
> 3. STREAMING UI RENDERING FROM Universal Resource Identifiers.
Bzzt! Same thing, butt-munch! Lots of times you see long lists of choices for
a pop-up or scroll list. And we defintely do not (yet) see dynamically
generated lists that might be updated in real time. It would be cool if data
sets could themselves be indirected by urls as streams. Lay out the UI, then
watch the lists populate or maps get filled in with points.
Any fragment of XML should eventually be deferred-loadable using EMBED, AUTO
with the eventual catalog mechanism for compressing fragment context. Then you
can really have a temporal, in additional to logical, tree structure to any
XML document.
> 4. MORE UI WIDGET TYPES.
A tree-type would be a perfect example of this. Imagine a sys-7 folder view
that can update the folder and collapse and expand branches -- and not just as
UI 'sugar' over a complete representation of the tree ("use style sheets to
suppress display of this branch") but as dynamically sourced data.
> 5. DRAG-AND-DROP WELLS.
Bzzt! Learn some hiearchy, low-man! This is, at best, 3b -- always go with a
triad: TYPING, DYNAMISM, and WIDGETS in this case.
That said, offering semantic hints like "this text field is really
fedex.com/usa-packageid" makes it possible to pull in script verifiers for
usa-packageid ("hey, the computed checksum is corrupt!"), user interfaces (a
gui that looks like a fedex form visually; a barcode scanner hook), and
automation ("hey, let's pull this usa-packageid from our inventory system on
the mainframe"). And oh yeah, from a browser UI-standpoint, it makes it
possible to set defaults for fields you see often, and to offer drag-and-drop
hooks form data similarly marked up as output in one page onto input of
another -- just use fedex.com/usa-packageid as the url describing the content
of an XML <PACKID> block element in an XML airbill DTD...
[interested readers will see the transparent appeal to the same arguments for
urls-as-typename philosophy as embedded in PEP]
> Care to elaborate, Rohit? :)
You scuzzball, you're always baiting me with your crappy recycling of my ideas
to get me to set the record straight when I should be out watching bmbettes in
70mm. Screw you!
Rohit