?

Log in

No account? Create an account
Previous Entry Share Next Entry
What should we call the "levels" of Querki?
querki
jducoeur
One of the more radical plans I have for Querki, which I'm about to start playing with, is a UI with multiple "levels", so that you can choose the complexity you're comfortable with.

The thing is, Querki has several distinct audiences:
  • The *vast* majority of users just want solutions. They don't want to build anything, they just want to use what's out there, that suits their data needs. They will be using other peoples' Spaces, and creating Spaces based strictly on existing Apps.

  • Of the remainder, most are just going to want to create relatively straightforward Spaces -- building something customized to their needs but not especially fancy.

  • And then there are the programmers, who will be creating the really fancy Spaces and Apps and tuning the details to be Just So. Querki is *fun* for programmers -- once you have the hang of it, you can build pretty powerful stuff much more quickly than in traditional environments.
The thing is, there's a ton of power here for the programmers, that the average end user not only doesn't *need*, they actively don't *want* it -- it occupies conceptual space for no benefit. There are lots of features ranging from the fine-grained Security page to the Model Designer that are usually irrelevant for that first category.

At this point, I have a fairly good idea of which aspects of the system are useful for which of these audiences, and the notion I want to try is that the folks from the first set will see a much simpler, stripped-down and focused environment, whereas the programmers will see all the bells and whistles. (And the folks in the middle will see some but not all of it.) This is all self-selected, mind, and can be changed at any time.

The question is, what do I call these "levels"? I've been thinking Easy, Standard and Advanced, but in talking with Kate about it last night she reacted quite viscerally against those terms: she thinks they're basically meaningless to the target audiences. She recommended User, Builder and Programmer instead -- names based on the audience rather than the degree of functionality.

I think she's got a good point here, but I think it's worth a bit of brainstorming. So -- opinions? Suggestions? Obviously, we can change these terms later if we need to, but it's always easiest if we can hash out this sort of argument in advance and get it right the fight time...
Tags:

  • 1
I think she's right. You might change User to Member, or Participant, or something similar, but role-based names are really good: "I want to build something, but I'm not a programmer, so clearly I should set this thing to Build Mode."

Hmm. I like Participant, but I think the connotations aren't *quite* right, since this is still aimed at people creating their own Spaces. I'm trying to find a word that means, "I just want to keep track of some stuff, but don't want to do any of this design crap"...

(Deleted comment)
Intriguing approach -- I'll chew on that. Thanks!

I lean very strongly toward's Kate's answer with the exception that I loathe the term "user." there are only two industries that call their customers "users" and illegal drugs is one of them.

People are not users. They're doctors, lawyers, plumbers, painters, secretaries, nurses, architects, and so on. If you don't know something that specific then "customer" or "visitor" works. Slack calls people "team members" which I think is a good workaround. Since I don't know what your people will be doing with their spaces and apps I can't suggest something more concrete but maybe you know.

Yeah, largely agreed. Unfortunately, I'm totally failing to come up with a good term here -- I'm not finding a good English word for "somebody who is trying to manage some data". That one may remain a TBD for a while, but I concur that I'd like a good word, preferably one that isn't already as overloaded as "member" (which is already being used in two different ways in Querki)...

How about Patron? It makes me think libraries, personally, but it's better than user. I don't think creator when I see User, just someone who uses what someone else has created. Or maybe Customer? Or Partner? You might want to steer clear of Programmer since most people would think AUGH CODE! That may be what you're going for, but Designer (as suggested below) is also nice. Or maybe Designer instead of Builder.

User/Builder/Programmer (or maybe Designer) makes sense.

But are they really roles? Or modes (which some roles have access to)? Does a Programmer who is accessing a space they built really want to see all the programmer bells and whistles? Or do they just want to see it as a User would see it, and can switch modes/views if they want to look under the hood?

In practice, they're modes -- switching back and forth *must* be very easy, especially for the cases where someone needs occasional access to one of the Programmer-mode power features, but doesn't want all that complexity in their face most of the time. (Current design is three mouseclicks to change modes; we'll see if we need to make that easier.)

Interesting observation, though. Personally, I'm the sort of person who always likes to have all the levers to hand, but you may well be correct that many/most people would prefer a simpler view most of the time. I suspect we'll learn that one as we go -- for now, this is basically a first-draft experiment, to observe and improve...

She's right. Describe the qualitative differences, not your assessments of ease of use. Besides, your "easy" is not necessarily somebody else's "easy". (A valuable lesson I learned some years back from a coworker: when instructing people, never say "just do X" or "Y is simple" -- because if it's not, you've just left the guy feeling like an idiot.)

As for the "user" conundrum (and I agree it's better to avoid it)... all your users are creators of spaces, right? Or at least that's the distinction you're trying to capture here? "Just make it", "tweak it some", and "customize it out the wazoo", approximately? If that's right, then maybe something like Creator / Customizer / Designer?

"Creator" still feels not quite right to me, but it's an advance on "user" and maybe you can come up with something better along these lines.

Bicyclist, Driver, Mechanic.

... I'm going to have to think about the connotations of those specific suggestions, but I like the metaphor...

  • 1