What should we call the "levels" of Querki?

Jun 28, 2016 09:55

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

querki

Previous post Next post
Up