Main Page Content
What Shall We Do With The W3c Dom
Recently I was writing one short article and one far longer chapter on the JavaScript DOM. Much to my surprise, I seem to have thought of something new during this writing. For the article I created a simple example script that allows the user to add or remove form fields at wish. Concluding the article, I concluded that the W3C DOM allows the user far more control on his web pages.
The idea
After some more thought I decided that this idea might lead to a radically new way of creating web pages and that I urgently needed the opinions of my peers. So I wrote a mail to Evolt and my own WDF-DOM list with the following theory:
Basically, since the W3C DOM allows us to completely rewrite the page according to the wishes of the user, we should design web pages in a new way. We no longer need to take serious decisions about how the site will work, how the navigation, the forms and the other elements interact with the users. Instead, we can offer the user a way to create his/her own web page, with exactly those elements and that interaction he/she wants, likes or needs. Thus one web page can look completely different for two users.
At its most extreme, usability specialists no longer need to decide how the web page will work and how the user would like to interact with it. Instead, they should decide how the "control panel" of the page should work, how the users can create their own page with a minimum of fuss.
On the whole the reactions were positive. Some members brought up practical problems (how to store the user's private interface, that sites might start to look alike if users can redesign them at will). While these considerations are not unimportant, they should be deferred to the future. The first question is: should we give the user such control, exactly what will this control consist of, and what will this control be good for?
Interestingly, no one referred to any article or website about this theory. It seems that no one has thought of it before (or, at least, has written about it), which in turn might mean that I'm the first one to think of it. Good for my ego, but it also means that we're groping around in the dark. (And if anyone does know about an article that discusses this idea, I stand ready to be corrected).
So we've got a new idea. Is the idea worthwhile?
What's it about?
First of all, let's make the idea itself somewhat clearer. The reactions showed that people thought I was talking about users influencing the design of the site or calling up new data. I meant neither.
Sure, we can write a script that allows the user to pick a design of his choice or even to upload his own background images (and incidentally, we don't need the W3C DOM to do this). Sure, ideas like the Semantic Web might allow us to request and control data flows in the future, but structures like it aren't operational yet.
What I meant is the users influencing the presentation of the data, not design-wise but interaction-wise. Let's return to my simple example script. The idea is the following:
- Users can enter short CD reviews. Each review consists of a set of form fields.
- How many reviews does the form allow? In the past we web developers had to decide on a certain number. Maybe we could add some DHTML to make the form more usable, but the users couldn't change the maximum number of reviews.
- In this example, though, the user can choose exactly how many reviews he wants to enter. If he needs more form fields, he clicks on the button and gets them. If he wants to remove a review, he clicks on another button and the review is completely thrown away.
- Submitting the form sends all reviews to the server.
In this example the user cannot influence the design of the site. He doesn't need to, either. Nor can he influence which data he views. Instead, the script allows him to personalize the form itself, so that entering data becomes a much easier job and he can choose how many form fields he needs. So the user is allowed to control the interaction, but nothing else, of the page.
This is what I meant.
Problems
Members saw some problems with the new idea. Some of the more interesting are:
- The idea will meet with resistance, especially from marketing departments, but also from users themselves. It's a new idea, and thus it's viewed with suspicion.
Reaction: True, but unavoidable. It will take a few years for mainstream sites to use this concept. So what? - Personalization through server side applications is already commonplace.
Reaction: True, but the W3C DOM is not a server side application. For instance, when a user personalizes the page through the W3C DOM he doesn't have to wait for the page to reload. Is this enough difference to choose the W3C DOM over server side applications? - It's a good idea, but only for portal-like sites.
Reaction: True. We have to find out which sites this idea will work best for. - Only people who have experience with building UI's will actually use the scripts.
Reaction: I'm not so sure if this is true. Many users don't want to be bothered with this kind of functionality, but some of them will. And if it becomes commonplace to have such personalization, more and more people will start using it. - For users who don't want to personalize, we need a good default UI.
Reaction: True, of course. - All possible combinations of UI elements have to be rigidly tested.
Reaction: I don't agree. We need to design the individual UI elements, but we leave it to the user to combine them. If a certain combination turns out to be unworkable, the user will change the UI. - Sites may lose their unique look-and-feel.
Reaction: I don't know. If the users can influence the graphical design of the site it might happen, but my idea isn't about the graphical design. - The result may be something else than a website.
Reaction: It's too early to decide on this. But if websites are not quite website-like any more, won't that be a fascinating development? - There will be flaws in the implementation of the scripts, and the user has to deal with them.
Reaction: Possible, of course. But it all depends on how the scripts are implemented. As long as the data (and maybe the design) are divided into comprehensible blocks, there will not be such problems.
None of these problems strikes me as unsolvable.
What kind of site?
Of course a lot depends on what kind of site you're making. I made the following division:
Sites it will work for:
- Portals
- Intranets
- Library/reference site
- Newspaper sites
- Intranets
Sites it won't work for:
- Corporate sites, since the exact design is too important to allow users to change it
- Entertainment sites, for the same reason
In short, it will work on sites that offer a lot of information. It won't work on sites where user experience is more important than information.
Ideas
So what shall we do with the W3C DOM? It all depends on good ideas. It might be possible to open a new chapter in user interaction, but we need some good, solid, above all practical ideas.
The IHT site, the best practical implementation of the unique possibilities of the W3C DOM so far, offers the users limited control over their environment. They can adjust the font size, and can switch between a 1 and 3 column layout.
How could this interface be extended?
We could think of offering the user however many columns he'd like, or to view several articles simultaneously. Maybe someone else has more ideas...Another good idea is to use the W3C DOM to program a wysiwyg-like application that allows people to create their own websites.
But we need more ideas. We need, say, a dozen scripts that implement this idea in a small way. Then we could start evaluating them, see which functionalities are unique and which aren't, which functionalities the users like, which functionalities offer a true chance to build websites in a radically new way.
Please use your imagination and write a practical W3C DOM script that allows the user control of his environment.