I just had a brainstorm, and I feel like I should commit it
to writing somewhere, so why not here?
One of the big parts of what makes it difficult for normal
users to be as effective with a computer as a programmer is
that they can't interact on an abstract level. This is why
command lines are great for programmers (and I use that term
widely), but not so useful for normal people. cat `ls
-t` > time_sorted.txt is not a way most people are
going to think. They would want to make each intermediate
step concrete, perform the tasks and ensure that each is
correct then move to the next. This takes more time, is
more prone to errors -- but, for most people, that's all
they can do.
Anyway, it would be nice to change that, but that wasn't
what I was thinking about. I was thinking about web page
Templates are hard to manipulate in a graphical, WYSIWYG
environment. That's why DTML, PHP, ASP, JSP,
whatever-it-is-that-Cold-Fusion-uses, etc., exist. You can
deal with simple templates in a graphical client -- fields
exist which get replaced when the page is served up. But
repeating fields, conditional fields, etc., are much harder
to deal with. Graphical editors simply can't deal with
these. How, for instance, would you deal with a table has
repeating rows? The HTML-oblivious designer doesn't even
know that there's a distinction that the table begins
with <table> (but can't be seen), and then the
row begins with <tr>, and then you put in real
content. How are they going to show that the row should
repeat, but not the entire table?
Okay, so that sucks. All designers should know HTML. I
really don't think that's so hard, mostly people are just
scared off by the initial learning curve. That's true with
most higher computer skills. It would be nice to change
that, like I said, but that's not what I'm thinking of now.
So why not just implement a truly WYSIWYG web page
editor? It will show at least an example of the actual
output that a person browsing the page will see -- with all
fields replaced, repeating done, etc. You'd have to allow
easy changing of examples, to explore all the possible ways
the page could render (with no results, one result, many
results... etc). Sounds great...
Oh, but it's hard. How are you going to communicate with
the server to get this rendering? Doing an FTP upload, then
querying the server, is hardly the sort of thing that can be
done as the user types. Just like rendering proportional
fonts and paginating used to be way to much to do as the
user typed. Which is to say, it is hard, but similarly
difficult things have been worth it in the past.
The optimizations that would have to exist, I think, would
be to implement at least a subset of the server environment
on the workstation (or actually run right off the server),
and to have a template language that could be interpretted
incrementally. (Though quite probably, the incremental
thing wouldn't be necessary for a reasonably quick
The other boundary would be that the designer would still
have to write in an abstract way. Sure, they'd see
the repeating fields or whatever, but they couldn't write
those repeating fields -- they'd have to write something
that represented the notion of an element that repeats in
But, again, this has been done before -- that is, people
have adapted to this sort of thing. The WYSIWYG word
processor only allows you to input data in the abstract.
You don't handwrite on the screen at the location you would
like the text to go (thankfully!).
Instead, when you want to go down, you hit the
Enter key. When you merge paragraphs, you go the
beginning of the second paragraph and hit
Backspace. These aren't concrete ways to interact
with the document. But people don't realize they are
abstract. They create an internal model of how the word
processor works. They realize -- even if they can't
articulate it -- that there is an invisible character that
represents a paragraph break. They realize that some, but
not all, line breaks are caused by this. Just like people
learn that tapping peddles and twiddling wheels can control
cars, the ability to manipulate a document in the abstract
is in the grasp of nearly everyone.
What WYSIWYG gives is feedback. Some people can visualize
things and work with very little feedback, but for most
people it is nearly essential. So if you have a truly
WYSIWYG editor, it just might make sense to people to make
complicated and dynamic templates.
How the interface might actually work, I'm not sure. But
the idea really intrigues me.