What should "skill levels" be called?

[jducoeur]

[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...

Comments

[metahacker.livejournal.com]

I think it's important that "Easy" sounds really attractive. People want to believe that they're uber competent, and then they get into hot water, and they blame the system. If you can brand the "typical user" level in a positive way, that may help.

"Easy" is an interesting word; Staples has rebranded it as a preferable thing, but for too many people it sounds too...easy. Too simplistic, like it was Fisher Price. Almost like "Dumb mode"; many people will shy away from that. Maybe we can borrow a metaphor from, dunno, automatic transmissions or something. In any case, I think you want to brand this as the "Standard" mode, and the other two as varieties of advanced. "User Mode"? (Except 'user' is a terrible word.) "App Mode"? Also, I suspect many people will never create QL expressions, of any length, unless you give them some serious hand-holding (like Scratch, perhaps).

As for #2 vs #3, I wonder if you can call 'em something like "Editor" and "Enthusiast". Even #2 is going to snow many people, so you want it to sound like a challenge...


Second, orthogonal thought: perhaps these don't need to be monolithic levels? Perhaps it should be more granular. What are the touch points--where do people encounter these differences? Does it make sense to tweak them differently?

This leads to a explosion of possibilities, and the way to cut through that is to pull 3-6 illustrative workflows for a person-in-that-role. Or maybe you don't need this sort of thing; I'm not sure. I keep thinking of HyperCard, which hid its complexity very well...

[dsrtao]

[Standard] [Power User] [Developer]

[metahacker.livejournal.com]

Power User sounds too awesome. By Dunning-Kruger it will pull in all the incompetents who think they're competent.

Hence why I went with a role-based name rather than something based on abstract descriptors correlated with perceived self-worth. You want people to actually understand why each level exists.

[jducoeur]

Yeah, I have to admit that since writing this post yesterday I've been having qualms. In principle, the more-granular approach seems good (indeed, I'm fairly sure that the coarse-grained version would need "escapes" up to a higher level for exception cases), but I'm not at all sure what that would look like.

I keep thinking of HyperCard, which hid its complexity very well...

Yeah, I sometimes think that I am a bit handicapped, never having used HyperCard. I get the impression that there were worthwhile ideas there for me to steal.

Hmm. I think I should probably pause on this "feature" for now, let it percolate, and ponder this more-granular thought. The same notion was occurring to me yesterday, and when you and my gut agree on such things it usually suggests that I should take the notion seriously. The core question is how to make the elements available in such a way as to make them easily available when you need them, but to not even take up brain space if you don't...

[laurion]

Never too late to glean what you might. I think I still have my HyperCard manual sitting around if you'd like to peruse it. I agree that it did a good job of hiding the complexity, both behind a gui-oriented approach for new users, and the smalltalk inspired scripting language for the intermediate users.

[jducoeur]

Hmm -- yes, it would probably be a good idea for me to look that over at some point, probably at least when I'm at your house...

[alexx-kay.livejournal.com]

1) No, you're not on crack. You're just doing a fairly unusual thing of trying to build a system that actually appeals to all those kinds of users. The only other product I can think of offhand that *tried* to do this has been Microsoft Office, and they've made rather a hash of it.

2) I think they're right to start with. Once you have substantial amounts of user data, you can see if there are other natural levels (and whether specific functionality got put in the 'wrong' level).

3) Agreement with metahacker that the simplest level needs to both be the default and sound attractive to most users.

[hudebnik.livejournal.com]

I presume you've got Alan Cooper et al's About Face $VERSION. He talks a lot about how to aim a product at three classes of users -- beginners, intermediates, and power users -- and points out that for substantial software products (like Querki), the overwhelming majority of your users are "perpetual intermediates" -- they got quickly through the beginner level but are unlikely to ever be power users -- so that's the common case to optimize for.

I think Cooper generally favors giving people a smooth slope from beginner to intermediate to power-user, rather than making the transitions explicit, but there are arguments on both sides of that. For an example on the other side, see DrRacket, a Scheme programming IDE designed for education: the UI doesn't change much, but the language subset is explicitly user-selectable between "Beginning Student", "Beginning Student with List Abbreviations", "Intermediate Student", "Intermediate Student with Lambda", "Advanced Student", "Full Racket", etc. (once you're at "Full Racket", you can plug in or write your own language dialects).

I don't remember what Cooper says about naming the levels in user-facing stuff.

[jducoeur]

I presume you've got Alan Cooper et al's About Face $VERSION. He talks a lot about how to aim a product at three classes of users -- beginners, intermediates, and power users -- and points out that for substantial software products (like Querki), the overwhelming majority of your users are "perpetual intermediates" -- they got quickly through the beginner level but are unlikely to ever be power users -- so that's the common case to optimize for.

Intriguing -- no, I don't have this. (Remember that I'm not a UX specialist, I'm a programmer with 35 years of on-again/off-again UI development experience. The result is that my instincts are well-honed, but I don't know the UX field as well as a real professional would.)

That matches my instincts, although Querki is an even weirder case because it will eventually have multiple modes of usage. The plan is to implement "Apps" later this year, and I expect *most* users to never do anything other than use Apps. The line between "App user" and "Creator" is intentionally blurry -- the ability to tweak your Apps is central to the design -- but I expect to see some bifurcation there.

Anyway, useful food for thought, and I'll look up Cooper's work. Thanks!

[jducoeur]

(Oh, I see -- this is Cooper of Cooper Design. Okay, I know him indirectly: I worked closely with his company a few years ago, designing the UI for the product I built at Memento...)

[hudebnik.livejournal.com]

About Face is sort of the "default textbook" in UX, I gather -- although I'm far from a UX expert myself. One of my first-week Noogler classes was a one-hour lightning overview of UX, and I recognized a lot of adages from Cooper in the slides.

BTW, I believe $VERSION is up to 4; I have version 3 on my shelf, having gotten rid of versions 1 and 2 to save shelf space.