Version 1 (Archive)

Title: SCGUI (Server-Controlled GUI)
       Proposed Standard Protocol -
       An X Windows Alternative

Keywords: SCGUI, Remote Access, Thin-Clients,
          X-Windows, Internet Standards, Web
          Standards, GUI

Related Topics:  X-Windows, HTML, CGI, Java,
                 Remote Access, Thin Clients,
                 X-terminals

[start text]
===============================================
Server-Controlled GUI (SCGUI) Proposed Standard
===============================================

A Draft Open Standard
Draft Version/History: 1d (7/00) minor changes,
(1/98) minor changes, first draft 5/97.


SCGUI is a proposed open standard for Web or server based GUI's
(Graphical User Interfaces). It is NOT a programming language,
but an interface protocol to be used between a client (browser)
and a server.

SCGUI is roughly a hybrid of HTML, CGI, and Java. It provides
much more control over the user interface and flexibility than
CGI, yet does not require the sending of executables or program
scripts to the cleint side. In addition, it is NOT tied to any
programming language or operating system.

SCGUI sends GUI object descriptions to the client and receives
user interactions as they are generated. It describes what the
application looks like and describes under what conditions the
application GUI components send data changes or responses back to
the server. The server decides how to act on these responses.

For example, the server may send descriptions and demensions of a
form with a "close" button on it. The client (broswer) then draws
the form and the button on its screen. If the user decides to
click on this "close" button, the browser does NOT directly close
the form. Instead, the browser would first tell the server that
the "close" button was pressed. The server would then decide what
the appropriate action is for this event. For the sake of
example, the server would go ahead and send a message telling the
browser to close the form. All program application logic, such as
if's, loops, database calls, and so forth is done on server.

One can say the store front and sales clerks represent the
client. The store layout and clerk behavior, however, are
controlled by the server. The server represents the possibly
distant headquarters of the store's company.

What Need Does SCGUI Fill?
--------------------------

The closest cousin to SCGUI is probably the X-Windows interface
found on many Unix systems. However, X-Windows is a bit cryptic
for most developers. SCGUI has a strong HTML, Java, and Visual-
Basic influence.

Other than the marginally popular X-Windows, there appear to be
no strong standards to fill the need for flexible GUI's that are
server-controlled.

(The fat client model has failed in our opinion; especially with
large, distributed implimentations. Fat clients may be useful for
desktop publishing, but not for "share-heavy" corporate
information.)

"Why not just use Java on the client side?," you may ask. First,
large complicated programs would require long down-load periods
whenever changes are made in a Java applet. Second, SCGUI can be
controlled by almost any programming language, including COBOL,
thus reducing training and re-write costs.
Third, there is less chance of security problems because the
program execution takes place on the server, not on the client.
Fourth, the current Java GUI layout managers often are difficult
to work with and unpredictable on differing platforms.

Note that SCGUI is not necessarily meant to replace Java or CGI,
but possibly augment it. The SCGUI browser driver can perhaps
even be written in Java. In theory, you can use any programming
language of your choice to control SCGUI. However, if SCGUI
catches on, you may see languages, language extensions, screen
layout builders, or development environments built just for it;
similar to the way HTML editors have popped up for HTML page
building.

What Does the Protocol Look Like?
---------------------------------

Here is a typical example of what the server may send to the
client:

  form/shop.grid/g1.size,5%,5%,95%,95%

This defines grid "G1" on form "shop". (Grids are spreadsheet-
like tables in our context.) The general form of this syntax is:

  form/<form name>.<object type>/<object name>   [continued]
  .<property or method>,<parameter 1>,<param 2>...

As will be shown later, abbreviations can be defined to shorten
the syntax.

The client may send this back when the user presses button 1 on
form A:

  245:form/a.button/1.action,click

The "245" is known as a "session number". It is how the server
knows which client sent what. Note that it is possible to send
more than one line in a given transmission. These examples show
single lines just to keep things simple.

Messages like these go back and forth between the client and the
server as long as the session is kept open. More detail is given
later about session maintanence.

Percents as Primary Sizing Method
---------------------------------

SCGUI uses percents as its primary measuring system.
[I have since changed my mind and suggest a
pixel-based mode also. Some tasks are simply easier
with pixel coordinates.]
This is because pixels, twerps,
and other existing units out there are
too arbitrary. Different machine makes or screen resolutions
cause chaos with these traditional methods. Percentages keep the
relative sizes of all items the same. This also makes them
scalable for different screen sizes.

Form sizing is based on the percent of screen (browser) view area
width. Take this example:

  Form/a.size,10%,10%,90%,90%

This says that form "a" will take up 80 percent of the viewspace
(browser viewing area). The cordinates are, from-x, from-y, to-x,
to-y (top left corner to bottom right corner). Unlike high-school
math, "Y" goes down instead of up. There is a margin of 10% on
all sides of this form. To fill the entire left half of the
viewspace, we could say:

  Form/a.size,0%,0%,50%,100%

Objects on a form are specified relative to the form size, not
the viewspace size; with one important exception described later.

The user should have the option of "magnifying" or scaling the
viewspace. For example, if a user selects a "viewrange" of 120%,
then a form that specifies a size of 100% (0 to 100) will still
have a 20% margin in this new viewrange. This way users with
higher or lower resolution screens can adjust for differences.

See the Notes Section for more details on percentages and
scaling.

Generous Use of Scroll-bars
---------------------------

Many of the problems with current GUI development environments is
that forms are used for the purpose of arbitrarily dividing
related objects. For example, if a data entry form has 80 fields,
programmers often divide these into 4 or 5 seperate forms. The
user must then figure out how to go back and forth between these
5 seperate forms. This arbitrary division is un-natural for both
the programmer and the user.

Instead, SCGUI can act more like a Web browser in that you can
put a whole bunch of objects on a form and not worry about
seperating them into screen-sized chunks. Scroll bars
automatically appear if any object is specified (or moved)
outside the 0 to 100 percent range. For example:

  form/foo.size,10%,5%,60%,130%

This form stretches down below (outside) the viewspace. A
vertical scroll-bar will automatically appear so that the user
can go to all areas of the form.  (Perhaps "page" is a more
accurate description than "form".)

The following text-box specification will result in a horizontal
scroll-bar because the text-box object stretches beyond the
original right border of the form:

  form/foo.textbox/1.size,95%,15%,135%,23%

This example causes the form to grow to accomadate the new
object.

Remember we said that object coordinates are relative to the form
containing it, not the screen. But, if the above example
stretches the form, do any existing form objects then stretch
also? Yes, but only to a point.

As a rule, sub-screen objects (such as buttons) will scale only
up to 100% of the viewspace size. Thus, if the form stretches to
200% of the viewspace in both x and y directions, the sub-screen
objects will then scale based on the viewspace dimensions instead
of the changed form dimensions.

Note that the coordinate start point is still relative to the
upper-left corner of the form, and not the viewspace even if this
rule is applied. The 100% maximum scale rule prevents a lot of
messy problems that we will not go into.

We apolize for not being able to supply visual examples. However,
if you draw some samples, you will see it is quite logical.  A
developer does not have to use these scroll-bar and scaling
techniques if they want to stick with the old-fashioned approach
to GUI building. This can be done by keeping screens relatively
small and in view.

If you can find a more logical and straight-forward way to
specify a screen-independant coordinate and scaling system, then
we will eat this proposal without sugar!

Assume defaults
---------------

The SCGUI browser is fairly forgiving in that likely defaults are
assumed in many cases. For example, if button X is specified on
form B, but form B has not be defined yet, a form B is
automatically created with a default size of say 70% by 70% of
the viewspace width.

As another example, by default only button clicks, double-clicks,
right-clicks, and form closings trigger "actions". (A function or
control key can be used on Macs instead of a right mouse button).
Actions are events that result in notification or data being sent
to the server.

These defaults can be over-ridden by the "sendwhen" or "act-on"
properties, which controls when an object sends results or
actions to the server. Thus a text-box can be made to send
immediate notification and/or text when its text has been
changed.

Thus, the order or existance of many declarations does not matter
as much as in other languages. If the developer does not like
this vagueness, perhaps a setting such this could be available:

   environ.declare,on

This would not allow the first example, which assumed that it was
OK to create form B even though it was not declared before
objects were placed on it. However, this could generate an run-
time error and shut-down the application if the application
forgets declarations like the form B example.


An Example
----------

The sample below involves 2 forms. The first form has a text
entry box and a button. When the user presses this button the
second form appears and pops out in front. The second form has a
grid and a menu bar. The grid has 11 rows and 5 columns. The top
row of the grid serves as column titles.

The user then double-clicks on one cell, which does nothing
interesting in our example, then changes the contents of cell
2,3. Finally the user selects "Exit" from the "File" menu item to
close the application. The notes after the example will clarify
some details.

[send] urlstuff://it.them/scg-bin/sample    [start form link]

session/245.start
form/a.size,10%,10%,90%,90%
form/b.size,20%,20%,80%,80%
form/b.menu,"File (Print)(Exit) Help (Contents) (Index)"
form/b.grid/g1.size,5%,5%,95%,95%
form/b.grid/g1.dim,11,5,1,0    [11 rows, 5 col, 1 fixed row]
form/a.title,"Test Form 1"
form/a.textbox/1.size,10%,5%,15%,30%
form/a.textbox/1.charwidth,25    [max chars]
form/a.button/1.caption,"Press here for grid form"
form/a.button/1.coord,50%,60%
form/a.show,modal
...
(user puts "stuff" in textbox, then
  user presses button on form)
[send] 245:form/a.button/1.action,click
[send] 245:form/a.textbox/1.value,"stuff"  [see note]
...
form/b.show
short,"gr1","form/b.grid/g1"     [create abbreviation]
$gr1$.act_on,dbl_clk    [act on double-click]
$gr1$.cell,1,1,"A field"    [put a column heading]
$gr1$.sendwhen,exit_cell    [when to send change]
...
[send] 245:$gr1$.action,dbl_clk,3,4   [picked cell 3,4]
(for our sample, we will not respond to the
  double click.)
[send] 245:$gr1$.cell.value,2,3,"87.23"    [user changed cell]
[send] 245:form/b.menupick,"File (exit)"

session/245,end

NOTES
------------------

- The "[send]" clause above is only for the reader to distinquish
between what is received by the client and what is sent. Its does
not actually appear in the contents.

- Changed contents, such the value of the textbox above, by
default only send the new (or updated) contents when the user
presses a button on the same form or the form is closed. The
"sendwhen" clause can override this behavior. For example, above,
the SendWhen clause is given to the grid to indicate to the
client to send cell updates when each cell is finished being
changed (such as when another cell or object gains focus).

Note that the "act_on" clause is somewhat similar to the SendWhen
clause. However, Act_on describes which action to send, not when
to send user data.

Also, there is a "SendUpdate" clause from the server that will
cause the client to send all pending value changes. There is also
a SendAll clause that tells the client to send all user-changable
values, whether updated or not.

- How is font sizing done with percents? There are at least three
approaches to this sticky issue. One is to use the largest font
size that allows given text strings to fit completely within a
text-box or label container box (not necessarily visable).

Another approach is to use purely scaleable fonts. This includes
the ability to scale both vertically AND horizontally. Thus, the
aspect ratio may be variable. The font would then scale to
perfectly fit the text container.

This may require the implimentation of vector-based font(s) on
the browser and perhaps on the server (for font-metric uses).
Although this approach is not common, it is probably the most
generic because it does NOT depend on existing fonts defined by
the operating system (be it Windows, Mac, Unix, etc.)

(Perhaps fancier font controls can be reserved for a "level 2"
implimentation of SCGUI. The second level would be for heavy-duty
word-processing, publishing, and other WYSIWYG applications that
need fine control over fonts and multi-font sizing. The basic
level 1 implimentation would be for general business transaction
and database operations, which is where the primary focus of
SCGUI should be until it flurishes.)

The third approach is to add little scroll buttons to the text
container. If the specified text does not fit in the container,
then the user can scroll it around. This is our least favorite
solution.
We beleive the developer should be able to choose between the
first approach (largest available), or the second (vector fonts).
The first approach is more attractive, while the second is more
generic.

Note that this font discussion mostly applies to server
(application) generated text and labels, since allowing user-
entered text to "slide" beyond the visible text box is a common
GUI convention. (There should also be a user text-length limit
option similar to CGI forms limiters.)

- Double_clicks by default always send an "action" statement. The
above example really did not need the "Act_on" clause to specify
sending actions when the grid is double-clicked, but it was
included to demonstrate how actions behavior is altered. For
example, if you want the user to have a pop-up detailed
description of a button when they right-click on it, you could
use:

  form/x.button/but1.act_on,right_clk

Then, when the user right-clicks on this button, the client
sends:

  123:form/x.button/but1.action,right_clk

Note that grid cell actions also send back the cell coordinates
(which start at 1, not zero). Perhaps allow wild-cards to specify
all buttons on a form:

  form/x.button/*.act_on,right_clk

Right-clicks also always send actions by default, so these are
just illustrative. A more useful example would be:

  form/x.button/1.act_on,mouse_over

Thus, if the mouse moves over button 1, the client would produce
something like:

  123:form/x.button/1.action,mouse_over

The server can then send:

  form/x.statusbox.text,"Send new mail"

Thus you can provide button descriptions at the bottom of the
screen when the user puts the mouse cursor over a button. (You
may want to use the MouseLeave action to clear it). Nifty, aint
it!

(Perhaps optional button descriptions should be built into the
buttons so that the client can react faster. However, we
personally prefer heavier use of right-clicks to describe objects
to the user.)

- Although drag-and-drop should perhaps wait until level 2
implimentations (described above), here is a possible syntax:

  123:form/1.list/1.dropped_on,4,form/1.list/2.dragged_from,3

This would happen if the third item from list 2 was dragged and
dropped on the 4th item of list 1.

- What about dimming (greying) of non-active menu options or
buttons? Personally we never liked this feature of GUI's because
the system rarely told the user why they are dimmed, which can be
frastrating. However, since we are not here to re-write stupid
entrenched ideas, here is dimming for a menu choice:

  form/1.menu.dim,"File (Save_as)"

This would dim the "Save As" option. Note that parenthises are
used to indicate menu level. Underlines are used to indicate
words that are together, but do not show up on the client.

Picking a non-dimmed menu would look like this:

  123:form/1.menu.picked,"File (Print)"

- Grouping is used to group related objects. For example, radio
buttons and form tabs are implimented by grouping forms or radio
button titles. Example:

  form/1.radio/1.groupto,X
  form/1.radio/2.groupto,X
  form/1.radio/1.Caption,"Pick this"
  form/1.radio/2.caption,"Or this"

By assigning both to group "X", the client knows which radio
buttons to make mutually exclusive. ("X" does not have to be
predifined as a group). Tabs would be assigned like this:

  form/1.tab,Y,"A tab"
  form/2.tab,Y,"B tab"

This will group both forms together (group "Y") to make them a
tab set. The grouped tabbed form will take on the size and
position of the largest member form.

- Tab Alternative

An alternative to the above form of tabbing is perhaps instead of
having seperate forms, have one big long form as if the smaller
ones were glued end-to-end. Then tabs would appear above the
view-window of this long form. Selecting a tab will then take the
user to the specified place. It is sort of like the "#"
hyperlinks in HTML, except that the tabs stay visable at the top.
Example:

  form/x.tabref,230%,"Planning"

This would place an invisable control or marker on the form at
position 230% (y), which could be reached by selecting the
"Planning" tab. The user can still scroll down to this position
from the top if they so chose not to use the tab. Interesting
concept wouldn't you say?

- Unicode Support is given by formatting strings as such:

  form/x.button/donebut.caption,"[UN]1234,2238,0019"

The unicode integer values follow the [UN] clause. (I sure wish
Visual Basic 4+ would have implimented it this way.)

- The "coord" property shown in the example is the "lazy" way to
size buttons. "Coord" just specifies the upper left corner of the
button. The width and length of the button is then dependant on
the caption (title) given to it. It is still possible to use the
"size" method if one wants full control over button size.

Perhaps semicolons can be used to specify multiple methods and
properties:

   form/1.line/B.draw,0%,50%,0%,5%;color,"#203040"

- Planes. SCGUI supports "scrollable planes". These are useful
for displaying more complex interfaces like Gantt charts,
calendars, and so forth. Here is an example plane definition:

  form/x.plane/x.view,10%,90%,10%,90%;
       span,200%,400%

This specifies a window on the form and the total area of the
plane. To envision this, imagine cutting out a square hole in a
regular-sized peice of paper, and then placing this on top of a
larger peice of paper. The larger peice underneath can slide
around to let you view different portions of it through the hole.
(Note: the scroll-bars are within the specified view-area, not
outside). The concept is somewhat like frames in web browsers.

Here is an example individual Gantt bar definition:

form/x,plane/x,box/1,10%,10%,10%,40%;drag,"10101"

The "1010" is a movement capability map. The first position
indicates if the item (a box in this case) can be moved
horizontally (1 = yes). Position 2 is whether the box can be
moved vertically. Position 3 is whehter the box can be stretched
and shrank horizontally. Position 4 is whether the box can be
stretched and shrank vertically. Finally, position 5 indicates if
changes in size are sent back to the server when the operation is
done (as apposed to when the server asks for it.)

For our Gantt chart example, we only want the bar to move and
stretch horizontally. (If the user drags the bar to a ridiculous
position, it is up to the server to put it back in the right
range and/or notify the user).

- Even though sizing is not based on pixels, borders and line-
widths will still be pixel-based. This is done because scaling
that results in fractional values for widths (say 1.5 pixel
widths) often produce undesirable (ugly) and inconsistant
results. Example of pixel-based width:

   form/f1.line/L1.width,2

This example specifies that the line is to be 2 pixels wide. Note
that the default would be 1 pixel wide. Use negative widths to
fill in rectangles.

For ultra-high resolution monitors, the pixel widths should
perhaps be multiplied so that lines do not appear too thin.)

- Image sizing can be percent based or pixel based. This option
is given because interpolating pixels in images can produce
undesirable effects. The image will always fit within the bounds
of a percent-sized rectangular container in either mode.
If the developer selects pixel-based sizing (PBS), then the image
will be sized to the nearest whole-number match, with 1 actual
pixel per screen pixel being the mininum. If the result is
smaller than the container rectangle, the image will be placed in
the middle of the container with room to spare. (Perhaps a
background color for the container can be given.) If the PBS
image is larger than the container, then scroll-bars are given.

- Time-outs: The client is to send at least one command every 1
minute. This way the server knows the client is still alive and
connected. A "noop" instruction can be used if the user has not
done any actions within a minute. Example:

    245:noop

- Here is a Pop-up message box example:

  popup.msg,"Do you want to quit?","Yes","No","Help"

Possible reply:

  345:popup.response,"No"

Since popups are modal, there is no need to specify an object
name. The number of buttons is not predefined.

- The "fixed" row in the grid example refers to the ability to
keep the top or left row(s) or column(s) stationary relative to
scrolling. This is so that column or row headings can be seen no
matter which cell is being viewed.

   form/b.grid/g1.dim,11,5,2,1

In this example "2" is the number of fixed rows to be used as
column headings. The last digit, 1, means that the left column
stays in view. This is equivelent to the "FixedRows" and
"FixedCols" in Visual Basic.

There are at least two ways to impliment grids. The first is
"static, but with resizable cells", such as the traditional
Visual Basic grid control, the second is "dynamic, but not
resizable", such as the way the popular web browsers display
tables. They both have their merits, so SCGUI will not define
which approach to take. Note that if the browser type of grid is
implimented, then if the user types new data in a cell, it may
have to automatically expand to show this data.

- Percents do not have to be whole numbers. Example:

    form/1.size 3.52%,2.8%,98.4%,66.6667%

- Textbox formats can be specified:

    form/B.textbox/1.format,"#####.##"
    form/B.textbox/2.format,"999-99-9999"   [SSN]

"#" excepts digits and signs, "9" excepts only digits. "A"
accepts any text, "U" converts all text to upper-case, and "*" is
used for password prompts. We will let you worry about
international monetary formats.

- Checkbox example:

    Form/1.checkbox/1.size,20%,20%,40%,28%
    Form/1.checkbox/1.caption,"Master Card";value,"No"

- Example image on a button (icon):

  form/2.button/5.image,"FTP://place.com/image1.gif";
    alt,"Search"

Note that we are not attempting to define which Internet protocal
to use, just how the SCGUI syntax will appear. "Alt" text is used
in the case that the image cannot be found or loaded fast enough.

- If an error occures on the client side, the client sends and
error message back to the server. The server can choose to act on
the message or ignore it.

   123:form/2.error,"Form has no such property: Value"

- For common operations, SCGUI does not need high band width.
Normal modem speeds of 14,400 and 28,000 should be plenty for
common operations. Large graphics are another matter no matter
which protocol is used.

- Perhaps do allow pixel-based coordinates because they are so
popular. Why buck a trend. Here is how to switch on pixel-based
coordinates:

  environ.coordtype,pixel

- Perhaps have a background and/or delayed sending option
  for edit boxes, etc. This allows some preliminary validation
  to take place before a formal form submission.

-----------------------------------------------
Conclusion

Please let us know if you disagree with parts or all of this
proposed standard. We beleive it to be general-purpose, generic,
screen resolution independant, language independant, relatively
simple, logical, and powerful. There are still many details to be
defined, but this document should be enough to give one a feel
for the concept.
------------------------------------------------

SCGUI Usage Rights
------------------

SCGUI is meant to be an open public standard. All we ask is the
following:

1. Credit for proposing and defining the basics of SCGUI.

2. Any additions or changes to the SCGUI language become public
domain. (This only includes the language, not programming code)

3. Any prioprietary extensions be clearly labeled as such in the
vendor's documentation.

4. Any standards body that takes over SCGUI must make all
rejected ideas public knowledge along with the reason for the
rejection. (This is a good way to learn from past mistakes.)

Spread the word and enjoy it! Its the next big thing!

-B. Jacobs-

[end]