Older blog entries for ianb (starting at number 2)

I've been sorely in need of some recreational programming lately, something that just seems amusing to me. I've been thinking of writing some interactive fiction, because that's always seemed interesting. But I hate puzzles, and I hate trying to figure out the right word to do something. And of course the can-opener-in-search-of-a-can situation. So I'm trying to figure out a good compromise. I really like Interstate Zero -- I'd love to make a game like that.

Anyway, I'm trying to figure out what the right balance is between freedom and flexibility. Should conversations be multiple choice in essence? Without that, conversations pretty much don't exist in IF. Should everything else be multiple choice? I enjoyed Choose Your Own Adventure, but...

I should probably think about plot and storyline first, though.

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.

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 language).

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 the abstract.

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.

I was pondering various things last night while I lay awake in bed, and I remembered MUQ, which I hadn't thought about in a while (a language/server/persistent programming environment for developing MUDs). It seems like it got a long way, developed by one person who really wanted it to succede, and then for whatever reason his interest faded off. Maybe his ambitions were accelerating slightly faster than his progress, which is discouraging.

Even though it's aging as we speak, it still seems like a more thoughtful and robust solution than I've seen before. A not-so-ambitious project built on it (like a shared world with tile-based graphics or something) could be quite effective. It would still require a lot of work from the author, as well as others... another aborted effort probably wouldn't be useful, though.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!