Comments on: 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

Comments:

Peter Wood 19-Sep-2008 21:09:36	These look a great set of objectives but cover only one aspect, development time. I believe that users also have other requirements of a GUI which lead to other objectives. Clearly, speed is one. I'm absolutely sure that this is one of your GUI objectives, it's just not written down. Another, very important one, is that the GUI fits into its environment. For example, clicking on the icon in the toolbar under Windows hides the application, quitting the application from the top menu under OS X, etc., etc.. I'm sure there are a number of others.
Philippe 20-Sep-2008 11:07:48	What is very interesting with REBOL is the readibility of the code. To show a window in few understandable lines make a good example and a good challenge for a novice. So, we have to build and keep the complexity inside the readibility (an example is the deprecated "layout" function vs the positions and coordinates of the widgets). I want also some common and global behaviors in REBOL : in VID, an graphical object is related to a feel, and may react to stimulis. But why not in "classical" object (make object!) to produce objects with time/feeling specific reactions. Maybe, it's stupid ? Another point is the look and the beauty : recently, I use a very simple application made in Flash to push defects in a repository . These app was very, very beautiful and efficient.
Brian Hawley 20-Sep-2008 12:00:48	I am really glad to hear that you have been continuing one of REBOL's greatest strengths: No unnecessary complexity, either in code or concepts. You can always find many different ways to do things, but REBOL programmers (when given the chance) try to think through and find the cleanest, best way to do the task. There may be some unusual stuff in there, but almost always there for a reason. That is the real reason that REBOL is so small. I think that you have focused your objectives in the right place, and that chart looks you are on the right track. Too many times programs, libraries and APIs put their focus more on functionality than on usability, and the result is that people can't function anyways because they can't get the tool to do what they need to do. So this seems promising. I look forward to your examples, and documentation of the core conceptual model. I'm not worried about speed - most speed is algorithmic. Unless there are conceptual blocks to faster algorithms, we will be able to make this fast.
-pekr- 20-Sep-2008 14:31:10	Interesting note about frames concept removal. I thought this one is about to stay and that scene concept was removed. I kind of liked the aproach ... it will be interesting to see, what the actual concept is except that everything is gob! on low level :-)
Norm 20-Sep-2008 22:33:22	To me the table may not aim to development time per se; that could be the effect of expressiveness. Rebol lowers the bar; small tasks can be adressed spontaneously, no need to discuss budget, neither to code for hours. Html was infectious because simplicity, but javascript was dull. Imagine a searchable gui language in a good functional language. You know a good language when things becomes excuses to get back at it. Rebol is near natural language; visuals of that nature can get viral.
shadwolf 22-Sep-2008 19:53:54	hum .... When I happend to loose time in rebol GUI is when i have to reinvent the wheel because that wheel doesn't exists in rebol. So i would plant the probleme more in the optic that when a widget is not existing I have to invent it. And when that happends I'm focusing on the "how to show" more than on the "what to show". How to show is I have a bunch of formed data how do I represent it on screen in the better understandable way for my users. The what to show is how do I compose the bunch of data. I think basically like peter wood said rebol GUI R2 way is incomplete in many ways. First the set of common widgets is missing, but we can invent exotic widgets(widgets you will never see anywhere else, like the ones Cyphre designed a couple of years ago (the translucid menu he did still amaze me alot). And as r2 GUI was designed to feet alot of different OS it doesn't have a proper support for all the OS specific things that makes an application more "fun" tu use. Or at least closer to what a normal user is used to see. So in my opinion the variety and number of buil-in default widgets shoud be enhanced. And the possibility to create new exotic widgets should still exists. And the top of the mountain would be that the "exotic" widget when people like them are then integrated into rebol VM as a built in widget to allow each and every one to use it widely. That's what we done with ashley when he started rebGUI. At the very begining it was all basic and fonctionnal and then we (or I ???) goes to the exotic way to bring some show room to the rebol graphic power. Rebol GUI is powerfull because it's all made as an engine. But as the concept wasn't pushed to it's limit then the realisation of exotic widgets reveal to be painfull. But that doesn't means the concept is wrong.
Shadwolf 22-Sep-2008 20:11:55	the graphic is interresting but for a novice to do a simple "page" in 5 minutes learning and 5 minutes writing that means: 1) Good documentations the problem for me in rebol wasn't to get first steps documentation but to get "ok now I know how to step daddy how do i run" documentations ^^ .This means how to move from the novice stage to the expert stage (thank you anamonitor cyphre and rebol community source code for those endless inspiration sources.) 2) What do we define as a simple page ? And mostly cloning the html system is not in my opinion the best way. Html was designed in 70's to format text. But the thing is that text is boring and not fast to assimiliate. For example those that don't read english will not understand what I'm trying to explain. And many times a diagram is more explicite than a tone of text (example: data base designing SQL SCript (text format) Vs Db Designers (MERISE format)). I like VID because it was an intent to simplify the approach of GUI conception. Most of the other langages that had a Graphical library does GUI designers to not have to write a tone of line of code but without touching the main problem those zillions of borring stupid and interrestless lines of code to compose a window and it's content.
shadwolf 22-Sep-2008 20:24:15	I like to write widget that auto write them selfs according to the user specific need. One example we the table widget I designed for RebGUI 0.38. That's a very unique feature and very rebolistic feature. When the widget becomes its how dialect that's when you start to see all the potential of rebol and the dialect concept in general.
shadwolf 22-Sep-2008 20:27:03	I like to write widget that auto write themselfs according to the user specific needs. One example was the table widget I designed for RebGUI 0.38. That's a very unique and very rebolistic feature. When the widget becomes its own dialect that's when you start to see all the potential of rebol and the dialect concept in general. (sorry double post the first one was too fuzzy)

Post a Comment:

You can post a comment here. Keep it on-topic.