''' The Need for a way to tell people how to use a GUI '''

The problem with a GUI is that using it requires rote memorization for every operation you want to perform. In other words, you have to memorize by rote memorization each step in each process, ie, each button click, each drop down selection, each tab selection, each place to apply a click etc. For people with high inductive and visual aptitude, this is easy.

For people like me missing one or the other aptitudes this becomes a huge obstacle to getting work done. I can stare at a screen for hours and try various things and never come up with the right sequence of actions on the GUI to get what I want done done. I can search the web for hours and never find a good description of how to do it that I can stand, understand and use. Even when I succeed with these things it takes an awfully long time and is both a huge waste of time and a significant disincentive to using anyone else's work.

For people like me with low VisualAptitude and/or InductiveReasoningAptitude a formal language for performing GUI operations could really help, and I'm a programmer!

''' GAT, A Proposed Notation for telling people how to use a GUI '''

GAT is such a language. GAT stands for GUI Action Trace. It is based on the idea of notation for being directed to click a button looking like a button in ASCII:  [button]  . GAT is a language like any other computer language. And it can be learned like any other computer language, but once you've learned it, using any GUI can become many times easier, and even if no-one has written a gat file for a particular operation, a gat user can use it to record what they did, so they can do it again without having to go through all of the pain and research necessary the first time.

Here is an example of a .gat file I wrote to record how I added a drill-down to another report in the Report Server GUI

 -- TO add a drilldown to another report (Report Server) --

 >>>   [[<report solution>.sln]]   [View > Solution Explorer]
 ||[Solution Explorer]   [[<report>.rdl]]   [RMB > Field > Properties]   
 |[Navigation]   (*)Jump to report   [<report>\/]   #[Parameters]
 examples of passed parameters:
 (row 0) X Parameter Name [<parameter>\/]   (row 0) X Parameter Value [<field value >\/]   
 (row 1) X Parameter Name [<parameter>\/]   (row 1) X Parameter Value ['<Expression>'\/]   
 |Expression   [+]Globals   |[['UserID']]|   _[OK]   _[OK]   _[OK]   _[X]

 12345678901234567890123456789012345678901234567890123456789012345678901234567890

As you can see, the example above runs through each GUI action from beginning to end without leaving out steps, and without having a bunch of extra English descriptive 'fluff'. It may look complicated but it is far easier for people without visual and/or inductive aptitude because it is a formal system. Once you have memorized the limited symbology, you are done. No more rote memorization of visual actions on a GUI. You can actually look up how to do something and follow the directions. If you're wondering, the aptitude I'm missing is InductiveReasoningAptitude.

This was discussed six years ago at GuiShorthand, and I was hoping that perhaps the industry has progressed enough since then to perhaps come up with a solution to this problem. Thanks. --JonGrover

-----

I'm kind of the opposite. I am a visual thinker who comes from a family of artists and very nearly became a professional artist myself instead of going into IT. (Sometimes I still wish I did, even though the money would likely be tighter.) Many software people have a higher linguistic aptitude than I do and "think in language" first. I generally have to build a somewhat "mechanical" model in my mind of things so that I can picture a process or device in order to reason about it and play around with it. It works fairly well, for one can turn just about any concept into a visual. However, it does make it difficult to communicate with linguistic-oriented people or source code. --top

----

CategoryGui