(Yes, I should make this an indexed story rather than a news-y post… guess what? I tried that and got an error message, probably related to my attempt to use quotes in the title… indicative of the very thing I’m writing about).
I see now that the thing that is driving me (to post items like this) is a strong urge I gained back in the days when I worked on ‘Novice Programming Environments’ (visualizing Prolog execution, analyzing pro-hacker debugging war stories, etc): namely, trying to understand the user’s mental model of what the underlying virtual machine is doing. Understand this, and you have the key to a huge number of bugs. Even better, you can pre-empt those bugs for future users. For new projects, you can even re-design the virtual machine to be more harmonious or perspicuous. For well-established pieces of software, where it’s hard to effect such re-design, there’s a powerful recommendation you can make: provide a more transparent explanation of the inner workings of the virtual machine.
If you sugar-coat things, or hide the truth too much, it haunts you in the end– conversely, if you make it clear (or clearer), then users can cope surprisingly well. I have many examples of this: an easy one is setting the Windows ‘folder view’ option for school kids to show (rather than hide) filename extensions! Hiding filename extensions, and displaying cute icons, is supposed to be more user-friendly. Ha… Guess what? When 8-year-old kids can see that they’ve accidentally saved their document as ‘foo.html.txt’ instead of ‘foo.html’ they understand in an instant why it doesn’t behave properly anymore. Moral of the story: less sugar-coating, more underlying ‘visible workings’ of the machine, at least up to a point, and certainly when the user is ready for it.
So how is this relevant to Radio Userland?
Well, I, and hundreds (or thousands) of others, as I see from the various discussions around the web, face an uphill struggle, and most of us ain’t that dumb. We’re just trying to get to grips with the underlying virtual machine, which differs in many ways from what we’re used to. So far, so normal… the real issue is whether recurrent headaches can be avoided in an elegant way. What follows is a typical case:
I swapped servers (from the weblogs.com site to my own) using Prefs… Basic… FTP Option… but then swapped back again the next day. This was an unhealthy thing to do, I quickly learned. I found that it was exceptionally difficult to get the true link to my home page restored. Some browsing around the internal Folders, various discussions, and quick cruising via Google looking for
led me reasonably quickly to a blog entry describing a case in which Jon Udell had expeirenced the exact same problem
. This made me feel much better, as he knows a lot more about this stuff than me, yet was experiencing similar headaches… he conveniently posted a sanity-saving link to a specific fix suggesed by Lawrence Lee
(you have to run a script that would be impossible for novice-to-medium users to come up with themselves).
So, what to conclude? Well, the outcome is good: whereas last week I would have cursed and moaned at this appalling degree of opacity, this week I’m in a constructive mood. My previous post talked about the problem of the Radio UserLand life-cycle virtual machine that consists of
‘edit’ -> ‘publish’ -> ‘render’ -> ‘upstream’
But there’s actually more to the virtual machine though:
‘edit’ -> ‘post’ -> ‘publish’ -> ‘render’ -> ‘upstream’
This extra step is illustrated by the menu item Prefs… Weblog… Three buttons or one… which informs you "The three buttons are Post, Publish and Post & Publish."
Now, I’m the first to admit that I’m trying to run before I can walk. I’ve read no documentation, and I’ve only been at this for a few hours… I first downloaded Radio Userland a few days ago, and have done a few posts and spent a moderate amount of time trawling around trying to debug some things that went wrong. On the other hand, I’ve built a lot of sites, written a lot of code in my time, and feel that even with a radically different execution model, it needn’t be this opaque. Remember, it’s not the difficulty I’m discussing, it’s the opacity.
Probably someone has solved this already, but if not, here’s a first-pass suggestion: provide an extra ‘dashboard’ panel in the Radio application that does more than the existing ‘Status’ monitor display, and in particular shows a linear-life-cycle-progress-status display (along the lines of ‘edit’ -> ‘post’ -> ‘publish’ -> ‘render’ -> ‘upstream’ ) that is orthogonal to the existing ‘events’ information that you can access from your local site.
Now, this is only my mental model of the RU virtual machine, and it’s undoubtedly still a bit shallow… but it’s an important step. Most users (I maintain) are used to a model that is either ‘edit’ -> ‘save’ or ‘edit’ -> ‘save’ -> ‘publish’ and this simpler model will be the source of numerous predictable misconceptions and bugs, including certain surprises when hidden things happen during the render and upstream phases. All of these are pre-emptable with the aid of a bit more transparency.
Which reminds me… the problem I had making this posting into a story… what happened? Well, I clicked on the Events menu on my local home Radio Userland page, and saw the following entry in the log:
Upstream: Can’t upstream because "Error evaluating #title: Can’t compile this script because of a syntax error.."
So my opening hunch was correct… well, maybe my dashboard suggestion would have helped me out a little here: although the events log indicates it was an ‘upstreaming’ error, my mental model of the UserLand life cycle tells me it was probably a rendering error. Seeing the state transitions more clearly, with some status lights and a list of ‘pending’ and ‘processing’ items in each stack, would help a lot! The same is probably true for RSS feed behaviour, which I’ll aim to address in another article.
[imported from Marc’s original Radio Userland blog; time and date preserved from original]