Look! The Future has arrived again!

Only 15 years after I was working at Trenza at build a 3D front end to the Web (wow, somebody is *still* running the website), and only 20 years after we wrote the first draft of VRML (points to Wikipedia for getting the history of the name right), it looks like it is steam engine time for a 3D Web again.

The emergence of the Oculus Rift has gotten some folks at Mozilla experimenting with how you could incorporate a 3D front end to the web experience. We'll see whether they learn from the mistakes of the past. There are good reasons why it didn't take off before, primarily because it's been a solution in search of a problem: far as I can tell, nobody's taken seriously the issue of how to use 3D to *navigate* the Web except Mark Pesce and me.

If I had the cycles, I'd probably be all over this -- after all this time, I *still* have yet to see a good implementation of my Portals proposal for how online 3D *ought* to be structured in the large scale (written almost exactly 20 years ago, and I still think I'm right). But now that the game Portal (and the latest X-Men movie) has taught everybody that non-Euclidean spatial connectivity can be fun, folks might actually be receptive to it...

What should "skill levels" be called?

[Posting this here, to get a wider range of inputs than the dev journal.]

Querki is, by pretty much any standard, a complex and sophisticated piece of software. I'm following the KISS principle as far as I can, but the fact of the matter is that it is *not* all that simple. There are a large number of levers you can pull if you want to make it really sing.

That said, most people aren't going to need or want most of that functionality. So I am planning on trying something of a crazy experiment: having distinct "levels" of Querki. This has nothing to do with paid vs. free, or anything like that. Instead, it's purely a matter of letting the users choose the experience they would like to have. As currently designed, I am planning on three levels, with roughly this functionality:

• Easy -- the UI exposes only the most core functionality. This level is designed to let you build relatively simple Spaces, using the core Types and the most common Properties. A few basic Functions show up, but not many. When Apps come along, you'll be able to use those. The target audience here is the true general public, who (I believe) will mostly want to use Apps, tweak them a bit, and *maybe* create very simple Spaces themselves. They aren't likely to create QL expressions of more than 2-3 clauses. There might be some extra hand-holding.


• Standard -- this UI exposes all of the commonly-used Properties and Functions. (Probably several times as many as Easy.) Some of the common meta-Properties will be visible. The ability to create Apps will be visible. The ability to create Model Properties will be exposed, and in general most of the UI functions will be visible. The target audience here is folks who want to try some serious tinkering, but don't want to be presented with the full gamut of bells and whistles.


• Advanced -- the "this goes to 11" setting, mainly intended for sophisticated programmers who are building complex Spaces, and App developers. It exposes all of the non-internal Properties and Functions. (Again, 2-3 times as many as in Standard.) Exposes all of the meta-Properties, letting you do things like create your own User Value Types. Lets you build fully-custom CSS. Etc.

These levels aren't necessarily hard and fast -- I suspect that we will need the ability to temporarily swap into a higher level to do specific things -- but the intent is to help people find their comfort zone. For most typical users, I'd like to provide them with a UI that is clean and focused, and not full of crap that they will never, ever want to use. For people like me and mindways, I want to have all the tools at my fingertips when I need them.

(Note that taming Advanced is an important part of this. There are a large number of Properties that I expect relatively few people to use, and I would like them to *not* be in everyone's faces all the time.)

So the first question at hand is, am I on crack? This seems like an obvious approach to me, but I honestly can't think of a system that does anything quite like this. It's a very coarse-grained way of doing things, but that's kind of the point: I don't want the typical user to be faced with a wall of switches to turn on and off, I just want to be able to define a few core profiles that fit expected usage patterns.

The second question is, does the broad notion of the levels seem right? They match my intuitions of the right buckets, and in fact much of the system is *already* tagged with these three levels. (This has been in the works for over six months now.) But I'm kind of going by gut instinct here.

The third question is, are the names appropriate? The overall term was originally "User Levels", but I decided that sounded pejorative. Internally, the code currently is named "Skill Levels", which doesn't sound quite as bad, but I'm not sure it is right. (I'm halfway tempted to just call them "Flavors", or something like that, to remove any sense of one being better than the others.) The names of the three levels above are the best I've come up with so far, attempting to make each one sound reasonably positive (and attractive to their target audiences), but they are by no means final.

Opinions welcomed. Taming Querki's complexity is one of the really *big* challenges for this project, and this seems like a straightforward way to take at least a first stab at it. I'm under no illusions that we're going to get it all right to begin with, but I'd like to put a stake in the ground before we start getting a non-trivial number of people involved, and I'm trying to puzzle out what a best guess would be...