jducoeur: (querki)
[personal profile] 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...

(no subject)

Date: 2016-06-28 01:59 pm (UTC)
dsrtao: dsr as a LEGO minifig (Default)
From: [personal profile] dsrtao
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."

(no subject)

Date: 2016-06-28 02:01 pm (UTC)
From: [identity profile] goldsquare.livejournal.com
Taking words out of your post: Solutions, Creators, Developers.

(no subject)

Date: 2016-06-28 05:42 pm (UTC)
drwex: (WWFD)
From: [personal profile] drwex
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.

(no subject)

Date: 2016-07-06 01:24 pm (UTC)
From: [identity profile] meranthi.livejournal.com
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.

(no subject)

Date: 2016-06-28 06:26 pm (UTC)
mneme: (Default)
From: [personal profile] mneme
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?

(no subject)

Date: 2016-07-03 10:17 pm (UTC)
cellio: (Default)
From: [personal profile] cellio
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.

(no subject)

Date: 2016-07-12 10:30 am (UTC)
From: [identity profile] jon-libby.livejournal.com
Bicyclist, Driver, Mechanic.

Profile

jducoeur: (Default)
jducoeur

October 2025

S M T W T F S
   12 34
567891011
12131415161718
19202122232425
262728293031 

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags