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
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
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
- 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:
||create a single-page reblet
||create a multi-paged reblet
||define a simple style in stylesheet
||create mini-app with server feed
||create mini-app with server transaction
||define a complex style in stylesheet
||30 m - 3 h
||add a new result action
||5 m - 30 m
||modify/extend GUI system
||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
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.
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.
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.
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 :-)|
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.
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.
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. |
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.