Previous Entry Share Next Entry
Easy vs. hard problems to solve
device
jducoeur wrote in querki_project
While I'm on the subject of usability, it occurs to me that it's worth stating upfront: I'm not especially *worried* about things like accessibility, or even usability in general. I'm not a UX specialist, but I do know my way around the field -- 35 years of engineering, much of it on UIs, and keeping myself decently informed about the state of the art is enough that I'm at least vaguely competent here. Querki's going to need a bunch of experimentation and evolution, and I'm hoping I'll be able to hire one or two true UX folks to work with me on it, but most of the sorts of problems we're talking about in the previous thread are in some sense "easy" -- they just require asking the right questions, discipline, engineering and hard work to deal with them, and I have good confidence that we *will* be able to address them well in the long run.

Which doesn't mean that Querki is trivial from a UX point of view. There is a *far* harder problem that I hope to address, which probably qualifies as "interesting" from a research viewpoint:
How do we enable ordinary users to design Spaces?
The thing is, when you get right down to it, Querki is a database system. It's a weird, forgiving, easy-to-use database system, but it's still fundamentally a database system. Writing a Space or an App involves things like shaping data, designing screens, and yes, even a little bit of lightweight programming.

For anybody with a technical background and the interest to try, I expect Querki to be fairly easy to pick up. But for folks who have never done this stuff? Who not only have never programmed, but have never been taught to think rigorously about data?

That's going to be the terribly hard, interesting problem. It's a bit audacious to even make the attempt, and I'm honest with myself that we may not succeed. (The business plan actually assumes that 90-95% of users just use pre-canned Apps, and never even try to customize them, let alone solve a problem from scratch.) But *damn* -- that is a *fun* problem. How do you build a system that works with the novice user to suss out their problem, help them understand the structure of the implied data, and fleshes out the Models and Properties from there?

It's going to be at least a year before we even seriously start to play with this, and it may well be impossible. The are plenty of interesting lesser UX challenges before then, like writing Querki Explorer. (The interactive data explorer and report designer, which I at least have a semi-concrete design for.) But my hypothesis is that it can be done, and that we'll learn a hell of a lot in the process...
Tags:

  • 1
My experiences indicate two things:

1. You will have more success if people can dip their toes in in some incremental fashion: learning by making small tweaks and customizations to something they're familiar with rather than having a large "now you build a Big New Thing from scratch" chasm.

2. You will have virtually no success unless you involve multiple users (of the targeted sort) in the process. What we expect they expect / want is so, so often wrong...

You will have more success if people can dip their toes in in some incremental fashion: learning by making small tweaks and customizations to something they're familiar with rather than having a large "now you build a Big New Thing from scratch" chasm.

Yep, definitely the plan. Indeed, that's pretty much the whole *point* of Querki -- it's designed to not just allow but somewhat encourage very quick, sloppy, incremental design. That's one of the main motivations for the rather strange, non-square way that it thinks about data: the whole system is designed so you can say things like, "Oops, I forgot a Property" fifty records in, and make it relatively easy to add that, or to say, "These five Things need an extra Property".

I actually expect to break the brains of some engineers who are deeply used to thinking in terms of square relational databases, or programmers who are used to strongly OO structures. Querki is neither: it's basically duck-typed, where the "type" of a Thing is mainly about which Properties it happens to have. It has a lot of flavor of both relational and OO, because both are often convenient, but deep in its heart, Querki is intentionally *very* sloppy about the notion of "type".

This is one of those advantages of my having ten years' experience with ProWiki -- it's abundantly clear that even I prefer to work incrementally when I'm building a new Space. And that suits my biases, which is that, instead of spending lots of time discussing specs and stuff like that, I prefer to just *build* something, run it past folks, get their opinions and iterate quickly. (Even the initial Wedding Site is doing a fair amount of that.) Querki is designed so that the time from initial conception to working first draft of a Space can often take under fifteen minutes, and you enhance it from there.

I'm pretty confident that anybody who has experience playing with data is going to enjoy that aspect of things. My concern is more for people who are at a loss when I ask the question, "What sorts of things is this Space trying to work with?". Engineers are taught to be able to quickly break problems down like that, but my sense is that most folks don't quite know how to think about it like that. That's the really interesting and hard problem: how do we make a tool like this accessible to the man in the street, who doesn't yet have the *cognitive* tools for it?

You will have virtually no success unless you involve multiple users (of the targeted sort) in the process. What we expect they expect / want is so, so often wrong...

Oh, absolutely, and I'm deliberately shying away from assumptions about the results here. Indeed, this is the area where I most expect us to have to go back to UX first principles, doing a *lot* of interactive interviews, paper prototypes, and stuff like that. Even figuring out how to *start* is going to require talking with a lot of people. But it's a fascinating problem...

Querki is intentionally *very* sloppy about the notion of "type".

Burbling a bit further, because it actually goes to the heart of this project.

It's not as if folks haven't tried to make a database for the common man before. Most attempts have been colossal failures, and Querki is built around a core assertion about that: they have approached the problem from the wrong direction. Folks have historically taken existing rigorous technology concepts like SQL, HTML and programming and tried to make them accessible.

I am contending that that's just broken -- that it's just a dolled-up attempt to make people think like computers. That works for programmers, but most folks don't want to do it. The only way you're going to actually succeed is by starting from how people *want* to work, and making the computer cope with that.

There are a bunch of aspects to this, which are driving many decisions. One of the big ones is to trample all over the traditional separation of concerns. In the industry, we are used to having nice, clean lines between data, UI and interaction -- the MVC model formalizes that. But the average person does not give a good goddamn about that: they just want it to work. So Querki intentionally runs in the opposite direction, blending those concerns in the name of ease of use. (The closest comparison to this attitude is probably Rails -- like Rails, the separation of concerns *exists*, but the system makes tons of assumptions so that you don't have to think about it as much.)

This is also why Querki very deliberately is reinventing all of the wheels, creating a new DB structure, a new programming language and a newish display language, all optimized for ease of use.

If I had ten million dollars and a staff of 5-10 UX experts, I'd start this out with a year of formal research and study, to get this *seriously* right from the beginning. In fact, I have no money and no *time*, so I'm going precisely the opposite way: I'm starting out with a lot of assumptions based on my own experience with the prototype, some intuitions and observations based on my experience as an applications engineer, and building *something* as fast as possible.

That *will* suck -- but it gives us a starting point. From there, the plan is to start iterating and enhancing Querki very quickly, and praying that I haven't made any *fundamentally* bad assumptions.

Right now, I'm involving all of you in conversations. I'm trying as quickly as possible to move beyond that, though: to get to the point where it is feasible for y'all to start *using* the system, and we can begin to have some meatier and more concrete discussions about the details. The results of that will initially be skewed to the techies, but the hope is to be inviting some less-technical users to join the fray as soon as possible...

Vaguely apropos, one of my favorite design principles, which was the engineering mantra on a project many years ago, is "make the easy things easy, and the hard things possible."

A different project had a somewhat similar mantra, "give 'em enough rope," which was shorthand for "letting users do what they want is more important than protecting them from doing the wrong thing."

Vaguely apropos, one of my favorite design principles, which was the engineering mantra on a project many years ago, is "make the easy things easy, and the hard things possible."

Yep. Indeed, one of Querki's tentative marketing blurbs is, "Easy problems should have easy solutions".

That said, I should be clear that Querki is explicitly *not* trying to solve every possible problem. The hard things often will *not* be possible in Querki, kind of intentionally. I'm not trying to replace existing databases and web frameworks; rather, I'm trying to create a system that is much, much, much easier to use for the 75% of problems that are really pretty easy -- the "casual databases" that really don't deserve more than 15-20 minutes to set up.

In other words, I am *somewhat* following the Apple direction, of doing a limited number of things easily, and deliberately not trying to do everything. I expect that the scope will gradually increase, but I doubt Querki will ever match something like Rails for power. I'm pretty comfortable with that...

  • 1
?

Log in

No account? Create an account