GUI and Closed Systems
Vector 16:1, page 86
Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 86
Many systems are designed to enable office staff to do a restricted number of things to a set of master files. Such systems may have some of the characteristics listed below. In particular the system is closed: that is, the operators cannot do things which were not foreseen by the designer. For such systems the effort of producing a GUI front end is a waste of time.
Here is a list of features of a closed system that detract from any benefits that GUI might bring.
1. A Well Defined Menu Structure¶
The Windows style of GUI is incompatible with a well-structured menu, especially one which is designed to limit the places where records are changed so as to give the least danger that records are corrupted, lost or damaged during file interactions. For example when files are accessible to more than a single operator if, at the top level of the structure, the choice has to be made between viewing record details and amending them, then file locking procedures can be limited to amenders; viewers can be given unlimited access to records without any worries. File locking for safety when there are multiple paths between windows with options on them gets very complex.
2. Simple Help Provided Automatically¶
Simple menus where the choice is made by moving the highlight up and down a list of choices are very quick to operate and allow provision of a panel of help different for each choice which is displayed just while the choice is highlit. The rapidity with which help panels can be displayed even on quite slow Pentium PCs, is remarkable. Even a list of choices which has to be scrolled because there are more lines than the screen can accommodate, can have the panels displayed fast enough for any operator to feel there is no delay. There is an example of a simple function to do this in the Appendix. If the menu structure is well designed and the panels of help well thought out such a system can be operated after very little training. Such a design is inherently context-sensitive. It tells you what this option is rather than the Windows help which tries to find out what it is you are trying to do out of such a huge choice that finding what is relevant is often really difficult. In a closed system the range of things one can do is small. The aim is to avoid the delays inherent in the Windows help system and never to cause an operator to have to press an extra key even when learning the system. Training costs otherwise can be quite significant.
3. A Restricted Set of Operations at any Point¶
The aim is to reduce the damage that could be caused by an erroneous key or click and to keep the design simple; less to program and less to learn. There should be a standard key for backing out of any situation without making changes (it is <escape> in the appendix).
4. File Operations that Protect against Partial Amendment¶
There are a few screens displaying details of records for amendment, so the places where amended records are written to files can be limited and controlled so as to reduce the danger of inconsistency between the state of one file and another to the absolute minimum. For example, when a system holds several indexes to give quicker access to some of the information, the chances of a glitch leaving some indexes saved and others not saved can be reduced by putting the instructions that make the saves in as short a sequence as possible. It is even possible to set a flag at the beginning of the sequence and unset it at the end so that if there is a power failure part way through, on restart the system can tell that this process was interrupted and the records of it should be checked.
5. An Instantaneous Response to any Command¶
(or a screen indication of action if the process triggered is a long one)
Programs that operate in character mode using character screens have a great speed advantage over those that operate through the Windows or any other GUI front end. Even with a really old and simple interpreter such as APL*PLUS/PC (I am using version 8.1) the speed of screen writing and reading is so quick one cannot fault the response times. On some legacy systems there were processes when the program displayed a message saying, in effect, "Be patient; the computer is sorting the alphabetical indexes". On quite a slow Pentium one has to pay very close attention if one is to see a flash of colour when the message is displayed; there is no chance at all that anyone could read it. Similarly, when cycling through 8000 components containing packages in a search for records matching a specified set of characteristics, it is a very easy matter to show progress on a bar chart, and the extra time for the whole process is not perceptibly increased by providing the progress bar. [Sample bar chart program in Appendix] So there is no problem ensuring that the operators are never left in doubt about what is going on.
6. Skilled Staff and so Acceptance of Long Type-ahead Sequences¶
The aim is to allow for the staff becoming expert in the use of the system and so learning to type ahead; the response must be fast enough to keep up with the typing or the buffer must be adequate for whenever the response is slower than that. This is not possible to do with Windows as mouse movements to get to the button to click require the button to be on screen.
The use of the mouse slows down even an experienced user such as myself. I have been using mice for eight or nine years and when I had to learn the key combinations necessary to operate Windows 95 without a mouse (my portable’s pointing device failed) I was surprised how much quicker it was.
To build a system with the features listed above is much easier if the GUI can be ignored and everything done from the keyboard. All responses will be faster if the screen is character-based rather than a 640 by 480 or, worse, a 1024 by 768 graphic of pixels and it will be great deal easier to test such a system thoroughly as there are fewer ways of initiating action and fewer paths through it.
Many Windows systems are not adequately tested. On my portable without the pointing device there are many menus that do not properly allow for a keyboard alternative to the mouse click. For example the mouse set up procedure is impossible without a mouse because at one point the key "OK to proceed" didn’t respond to <enter> even though it was marked as containing the focus!
There are other advantages to this approach. Every Window has to be described and takes space even if a table-based approach to Window definition such as Causeway is used. Working in APL*PLUS/PC version 8.1 the DOS address limit means that the interpreter and workspace both have to be contained in the 640K (slightly increased by the virtual workspace if you use it). The menu mechanism shown in the Appendix can be used for every menu in the system and it only takes 50 lines (it can be reduced to thirty or less by removing comments and more extensive use of the diamond separator). In the environment where such menus are used there is a file containing the tables of choices and the corresponding sets of help panels with the list of their names ready for use in the left argument. All these variables are commonly stored in a package so that the calling function can read them, fix them in the workspace, get the user’s choice from the menu and expunge the package and its contents from the workspace, all in a few lines of code and use very little workspace indeed apart from the temporary variables.
Even old computers with slow chips such as 486 and even 386 run fast enough to support such systems.
Simpler systems are also easier to maintain.
Systems on this plan may be faster, more reliable, easier to write, and easier to use, require less training or maintenance and run on cheaper computers; these advantages are comparatively unimportant – the reason people choose them is that they suit their needs better.
Appendix – APL*PLUS/PC version 8.1 functions¶
There are six functions here; QLX is the top level that displays a menu of workspaces each of which will do everything required for one of the options. BOFS displays the menu, shows (SHOWHELP) and removes (REMHELP) the help and returns the rows that were selected. BCHART puts a bar chart on the screen. I haven’t bothered with an example of how it is called. I hope the comments are helpful. The functions MKCLRS and SETKEYS in the QLX set up colours as delta-variables and action keys and their actions. BOX draws lines round a block of text.
∇ QLX;⎕IO;∆A;∆B;∆E;∆I;∆H;∆N;∆S;PAK;PNAMES;OKEYS;⍙;WS
[1] ⍝ ⎕LX function for the demonstration WS AJC 17 JAN 1999
[2] ⍝ Model for top of menu structure of other QLXs
[3] ⍝ Sets up colours (∆A etc), keys, top menu, network globals, current date
[4] ⍝ offers the menu of workspace options with this one highlighted
[5] ⎕IO←0 ⋄ 48 ⎕POKE 161 ⋄ MKCLRS ⋄ 1 ⎕POKE 255 ⋄ ⎕TCFF
[6] PAK←⎕FREAD 38 67 ⋄ PNAMES←∆PNAMES PAK ⋄ ∆PDEF PAK ⋄ OKEYS←SETKEYS ' '
[7] ⍝ 1-line per option menu is in 38 67
[8] AGN:→(¯1 12 =WS←HELPS BOF WSS)/END,THISWS ⍝ WS is row in WSS or ¯1
[9] ⍝ HELPS is a list of help panel names
[10] ⎕QLOAD WNAMS[WS;] ⍝ Each choice is a WS: WSlist in WNAMS
[11] ⍕ ⍝ After ⎕QLOAD next instr never obeyed
[12] THISWS:RUN ⋄ →AGN
[13] END:⍙←⎕EX PNAMES ⍝ PAK & PNAMES itself are localised
∇
∇ R←HELPS BOFS TAB;⎕IO;LWIN;OKEYS;NOH;TRS;TCS;SR;NSP;SUL;SDL;OLDSCR;RWIN;ZWIN;⍙;WINDOW;OHS;SCRN;DNS;UPS;TOP;HWS;OFFSET;SSR
[1] ⍝ R←row from TAB (¯1 if esc). Simple menu AJC 8 JAN 1999
[2] ⍝ TAB is a table of choices - (can be more than a screen)
[3] ⍝ optional arg HELPS is NL of help screens, per row in TAB
[4] ⍝ SR↔no of screen rows - can be varied as needed
[5] ⍝ SUL↔value of TOP when at scroll-up limit
[6] ⍝ SDL↔value of TOP when at scroll-down limit (=0)
[7] ⍝ --------- 1 Set up
[8] ⎕IO←0 ⋄ R←¯1 ⋄ OFFSET← 0 0 ⍝ top left of menu
[9] NOH←2≠⎕NC 1 5 ⍴'HELPS' ⍝ NO Help
[10] ⍙← ¯1 ¯1 ¯1 ¯1 ¯1 ¯1 ¯1 ¯1 ¯1 ⎕WKEY enter,esc,ctrlend,tab,btab,ucsr,dcsr,lcsr,rcsr ⋄ TOP←DNS←UPS←0 ⍝ vars are key values
[11] TRS←1↑⍴TAB ⋄ TCS←¯1↑⍴TAB ⍝ TRS↔TAB rows TCS↔TAB cols
[12] SR←TRS⌊23-1↑OFFSET ⍝ SR↔Screen Rows (BOX adds 2)
[13] SSR←(TRS,2)⍴∆E,∆A ⍝ Tally of selected rows
[14] NSP←SR>1↑⍴TAB ⍝ NSP↔No Scrolling Poss 1∨0
[15] SUL←0⌈(TRS)-SR ⋄ SDL←0 ⍝ Scroll-Up-Limit & Scroll-Down-Limit
[16] LWIN←(⌈0.5×SR)⌊⌈0.5×TRS ⍝ Focus starts at middle
[17] RWIN←(⍉(4,SR)⍴(OFFSET[0]+1+⍳SR),(SR⍴2+OFFSET[1]),(SR⍴1),SR⍴TCS),(SR,4)⍴0 256 ,∆E,∆A
[18] WINDOW←OFFSET,(2+SR),4+TCS ⍝RWIN & WINDOW never change
[19] ⍝ ---------- 2 Construct display. RED↔RE-Display
[20] RED:SCRN←BOX TAB[TOP+⍳SR;] ⋄ RWIN[; 6 7]←SSR[TOP+⍳SR;]
[21] OLDSCR←WINDOW ⎕WGET 3
[22] WINDOW ⎕WPUT SCRN,[1.5]⎕AV[∆H]
[23] DIS:→NOH/WE ⍝ WE↔Windows Execute
[24] OHS←(HWS←OFFSET+ 1 4 +LWIN,TCS)SHOWHELP HELPS[TOP+LWIN;] ⍝ OHS↔Old Help Screen
[25] ⍝ ---------- 3 Windows Execute & select action
[26] WE:ZWIN←LWIN ⎕WIN RWIN
[27] →NOH/SA ⍝ SA↔Select Action
[28] HWS REMHELP OHS ⍝ HWS↔Help Window Start (see[24])
[29] SA:→(ZWIN[1]=esc)/END2
[30] →(ZWIN[1]=ctrlend)/END3
[31] →(ZWIN[1]=enter)/END1
[32] →(DNS←(ZWIN[1]=tab)∨(ZWIN[1]=dcsr)∨ZWIN[1]=rcsr)/DN ⍝ DowN Scroll
[33] →(UPS←(ZWIN[1]=btab)∨(ZWIN[1]=ucsr)∨ZWIN[1]=lcsr)/UP ⍝ UP Scroll
[34] →DIS
[35] ⍝ ---------- 4 Actions
[36] ⍝ DN↔scroll up or cursor down. UP↔scrl down or cursor up
[37] ⍝ END2↔esc - abort. END1↔selection & in ZWIN[2]
[38] DN:UPS←0 ⋄ →(NSP∨TOP=SUL)/ML ⍝ Can't scroll so Move Lwin
[39] TOP←TOP+1 ⋄ →RED ⍝ Scroll up 1 line & → RED
[40] UP:DNS←0 ⋄ →(NSP∨TOP=SDL)/ML ⍝ Can't scroll so Move Lwin
[41] TOP←TOP-1 ⋄ →RED ⍝ Scroll down 1 line & → RED
[42] ML:LWIN←|SR|LWIN+DNS-UPS ⋄ →DIS ⍝Cycle focus in direction req'd
[43] END1:SSR[TOP+LWIN;]←,(2 2 ⍴∆I,∆S,∆E,∆A)[(SSR [TOP+LWIN;1]=∆S);] ⍝ ∆I,∆S are normal & ∆E,∆A highlight colours
[44] ⍝ SR↔Selected Screen Row(s) marked
[45] RWIN[; 6 7]←SSR[TOP+⍳SR;] ⍝ Highlight selected rows
[46] →DIS ⍝ To exit on first selection COMMENT THIS OUT
[47] END3:R←(SSR[;1]=∆S)/⍳TRS ⍝ Output selected rows
[48] END2:→(1≠TEST)/1+⎕LC ⋄ ¯1 DISMSG BOX 'TEST RESULT FROM BOF IS ',⍕R ⍝ DISMSG displays a message and waits for enter
[49] WINDOW ⎕WPUT OLDSCR
∇
∇ R←ROWCOL SHOWHELP H;XS;WINDOW;SR;SC
[1] ⍝ Displays mat H for item that ends at ROW,COL 8 JAN 1999
[2] ⍝ H is (semi-global) name of help panel
[3] ⍝ R is the old contents of window
[4] ⍝ ⎕IO must be zero (set by BOF or BOFS the calling fn)
[5] ⍝ SR & SC could be added to the left arg if needed
[6] H←⍎,H ⋄ SR←24 ⋄ SC←80⍝Get panel SR, SC↔Screen Rows/Cols
[7] →(~TEST)/⎕LC+1 ⋄ ¯1 DISMSG BOX('ROWCOL↔',⍕ROWCOL),'⍴H↔',⍕⍴H
[8] →(SC<ROWCOL[1]+¯1↑⍴H)/TOOBIG ⋄ →(SR<1↑⍴H)/TOOBIG
[9] AL:→(SR<XS←(1↑⍴H)+1↑ROWCOL)/ADJ ⍝ If too big →ADJ
[10] WINDOW←ROWCOL,⍴H
[11] R←WINDOW ⎕WGET 4
[12] WINDOW ⎕WPUT H,[1.5]⎕AV[∆H] ⋄ →0
[13] ADJ:XS←XS-SR ⍝ XS is no of lines H must be moved up
[14] ROWCOL←ROWCOL-XS,0 ⋄ →AL ⍝ Move window start up to fit
[15] TOOBIG:H←BOX 'Sorry help panel too big to fit' ⋄ →AL
∇
∇ ROWCOL REMHELP OHS;XS;WINDOW;SR;SC
[1] ⍝ Removes help for item ending at ROW,COL 20 AUG 1998
[2] ⍝ OHS is previous contents of help panel
[3] ⍝ NB SR & SC must be set at same values as in SHOWHELP
[4] ⍝ They could be added to the left argument if needed
[5] ⍝ NB ⎕IO↔0, set by BOFS which calls this fn
[6] SR←24 ⋄ SC←79 ⍝ SR, SC↔ Screen Rows/Cols
[7] →(SR<XS←(1↑⍴OHS)+1↑ROWCOL)/ADJ ⍝ If too big →ADJ
[8] OK:WINDOW←ROWCOL,⍴OHS
[9] WINDOW ⎕WPUT OHS
[10] →0
[11] ADJ:XS←XS-SR ⍝ XS is no of lines OHS must be moved up
[12] ROWCOL←ROWCOL-XS,0 ⍝ Move window start up
[13] →OK
∇
∇ RANGE BCHART SOF;BAR;CHARS;DISP;⎕IO
[1] ⍝ Display of progress - 15 NOV 98
[2] ⍝ RANGE is total run SOF is progress so far
[3] ⍝ Fixed posn allows calling function to save and restore
[4] ⍝ screen at the end of the task whose progress is shown.
[5] ⎕IO←0
[6] DISP←BOX 1 60 ⍴⎕AV[176]
[7] 15 5 3 64 ⎕WPUT DISP,[1.5]⎕AV[∆H]
[8] BAR←(CHARS←⌈60×SOF÷RANGE)/⎕AV[219]
[9] (16 7 1 ,CHARS)⎕WPUT((1,CHARS)⍴BAR),[1.5]⎕AV[∆A]
∇