GUI Objectives - Defined in user terms

Earlier, I described the objectives for the R3 GUI Simple, Clean VID Requirements. As you know, I've long thought that the R2 GUI had missing pieces and trouble spots. The end result was that coding GUI's in R2 took longer than necessary.

For me, that's the bottom line. I want to see users be more productive in REBOL, not just for the back end, but also for the front end. Sure, those of us who are experts can always get things worked out. We're experts. But, that's meaningless to the 95% of other users. They are not experts. By my metric, if they fail to succeed in REBOL, then I've failed too. It does not matter how brilliant and elegant our system design.

It's that idea that has led me in the last few months over steep mountains, humid swamps, and arid deserts. It's been a difficult journey, tossing concepts I once thought important (like look and feel). Adding new concepts that seemed important because they were used in competing GUI systems (frames, like in Flash), only to discard later when found useless. I've chopped as much code as I've created.

This long process (and indeed I think it's been much too long) got me thinking deeply about how best to clarify the objectives. Then, about a month ago I realized that our objectives are much better described in terms of the user, not in terms of the system. We can build a system many different ways, but I now know that I will only be satisfied if these end-user characteristics/qualities are achieved.

So, I've boiled it down to a simple table, and I will warn those of you who are computer scientists or programming professionals, the table may seem either obvious or unimportant. But, I'd reply, that without being clearly stated like this, we'd never be able to achieve it.

I should comment that in the table below, the skill levels are:

• Novice - a beginner in REBOL, doesn't know anything about our methods of writing functions or objects, but perhaps has coded in HTML or Flash, pays attention to little details like end-quotes or end-brackets, and has an idea in general about how pages are organized.
• Novice+ - pays more attention to details and understands the Internet more than just a rank beginner (e.g. understands that clients connect to servers, send requests, and get responses back, sometimes as errors.)
• Intermediate - an average programmer who knows the basics of REBOL, knows how to correct most simple errors, but has yet to understand the entire system.
• Expert - someone well-versed in REBOL.

The "study time" is how long the user needs to read a web page showing how it's done, and "edit+test" is the time to write it and try it out. Of course, we assume they know how to work a text editor and run R3 with as script. (Of course, eventually, I'd like to see our own little IDE for that.)

Here are the R3 GUI objectives, defined in terms of the user:

	project	skill level	study time	edit/test
1	create a single-page reblet	novice	5 m	5 m
2	create a multi-paged reblet	novice	10 m	20 m
3	define a simple style in stylesheet	novice	5 m	10 m
4	create mini-app with server feed	novice+	20 m	30 m
5	create mini-app with server transaction	novice+	30 m	30 m
6	define a complex style in stylesheet	intermediate	15 m	30 m - 3 h
7	add a new result action	intermediate	5 m	5 m - 30 m
8	modify/extend GUI system	expert	2 h - 1 d	5 m - 3 d

Maybe you are now asking yourself, but what about writing a robust app, like some kind of enterprise-level program? That cannot be directly answered by this table, because it depends entirely on the requirements of the app. However, since most apps are assembled from many smaller pieces, we can conclude that if those are easier to create, then the app overall should be easier to build and maintain.

You will also notice that this table, as a statement of objectives, makes no mention of functions or features. That's because I believe that if the GUI design is easy enough to understand, many of us will add and share various functions or features that we require. I think that approach (rapid enhancement) is better than guessing at variations you might need. And, in fact, I would encourage all of us who are REBOL fans to add to the GUI in this way.

In my next blog, I'll provide one or more script examples, along with screen shots, to begin illustrating how the above objectives have been satisfied.

9 Comments