Thu Jul 29, 2010
A GUI is Really a Computer Language
A computer language is a way to tell a computer what to do. You can do this both with a GUI and with a regular computer language. Learning a GUI is like learning a Computer Language. They are both complicated. There are three differences.
- One is that a GUI is not consistent like a computer language tends to be.
- A second is that a computer language packs a lot more power.
- The other is that sometimes you can just learn a tiny bit of a GUI and start using it, when to practically use a computer language you generally have to learn a large chunk of it first.
Visio is a good example of this last. I use it a lot and yet I only know a tiny bit of it. I always use the basic shapes stencil and just use it as a simple drawing package, yet I can do some pretty cool things with it. Another example is the web browser. It has a few basic functions. An example of a GUI you have to know a lot about to use is Visual Studio. I use it extensively, using many of its features. I still have more to learn just like most computer languages I know. But you need to know a fair amount about it to use it productively.
Given the 'tiny piece' learning potential of a GUI and the 'packed with power' packed nature of a computer language, we could merge the two in some way and have some sort of GUI that really is a computer language, that is easy to start with, and has the power of a major language. Truly they are both languages. We can do this.
[0]
comments (626 views) | | [0]
Trackbacks
Posted by: Jon Grover | Jul 29, 10 | 12:55 pm
Tue Jul 27, 2010
Why Don't we have a Graph Browser like a spreadsheet program?
In mathematics there is a diagram called an edge graph. It consists of a bunch of circles (vectors) each containing some element with a bunch of lines (edges) between them describing relationships and in many cases transitions between the circles. Its a basic mathematical way of representing systems.
We could have a tool for these graphs much the same was as Excel is for tables. It could include formulas like a spreadsheet program, data like a spreadsheet program, animation of tokens moving about the diagram, sub diagrams, general edge formulas, definitions and meanings, colors etc. It is the perfect way to represent certain kinds of information and it doesn't exist. Visio has some of these features, but it is waaaaay too complex for simple edge graphs. In addition, many GUI's could use such a tool for specific parts of themselves especially for things like work-flow. But there is no general tool.
I would like to see a simple edge graph GUI, especially one that can be ported to various applications as needed. We can do this.
[0]
comments (67 views) | | [0]
Trackbacks
Posted by: Jon Grover | Jul 27, 10 | 12:40 pm
Tue Jul 20, 2010
You can't Control a GUI
There are no control structures. You can click through a sequence of operations on a GUI however... If you want to tell a GUI to perform the same sequence 1000 times there is usually no way to do this aside from clicking through the sequence by hand 1000 times. If you want a conditional control structure so that one sequence operates on one kind of data and another on another kind of data, there is no IF-THEN in a GUI to do it. There is no CASE, there is no NOT, there is usually no ability to make subroutines, and yet the code behind the GUI can do all of these things. In the code behind they are simple. In the GUI there is no way.
We could come up with a way to include control structures in a GUI. First we would have to be able to trace a sequence of operations. Then we would have to have some sort of way of entering the control structures to use the traces. We could do it. The code is already there in the code that runs the GUI. We can do this.
[0]
comments (92 views) | | [0]
Trackbacks
Posted by: Jon Grover | Jul 20, 10 | 1:27 pm
Fri Jul 16, 2010
If GUI's understood people they would not need so much junk.
GUI's are filled with fields. Fields for this piece of data, fields for that. You need a field for every piece of data the application might need whether you needed it for a particular session or not. So GUI's end up with hundreds of half filled fields and unfilled fields, each with a little piece of data in it, each of which a user has to deal with in their head, which the GUI and application does not understand the relationship of.
To fix this we need information data structures. these would be generic data structures for holding information rather than data. here is a simple example. For some patients, we might only have the first and last name. For others we might also have middle name, nick name, alias, maiden name, internet handle and so on. What if the user could tell the GUI which name parts they wanted to store, and the GUI could display name fields as needed. Instead of having a dozen name fields on a page, a GUI might have just the three needed. And what if we had an information data structure that would facilitate the selection. And this is just a simple example.
We could really use information data structures through which users can interact directly with GUI's. We can do this.
[0]
comments (69 views) | | [0]
Trackbacks
Posted by: Jon Grover | Jul 16, 10 | 1:22 pm
Mon Jul 12, 2010
API's are the wrong way around the problem of GUI's.
The right way around the problem of GUI's is to fix the problem with GUI's themselves. API's are fine for programmers, but most people are not programmers. If you expose some a programming interface that's an API. If you expose some of the actual code in the program in a way that can be reset if broken and saved as changed, that's different. That gets around the problem of GUI's.
So what do you need to expose? You need to expose a control structure for some operations in the GUI so they can be run multiple times programmatically. You need to expose filters so they can be changed. You need to expose preferences and business rules. You need to display application status so the user knows what's going on. You need to expose the GUI structure so users can reorder their own GUI Instances. You need to expose the data itself so users can see and even modify it. You need to display the structure of the data. You need to expose a trace of what the user has done in a session and you need to expose information in some format rather than just data. Finally you need to display the program architecture so they can ask you to write more stuff. We can do this.
[0]
comments (85 views) | | [0]
Trackbacks
Posted by: Jon Grover | Jul 12, 10 | 9:02 am
Fri Jul 09, 2010
What Is a GUI anyway?
A GUI is something that stands between you and the computer you are trying to work with. Computers can analyze, store, create, display, connect, explore, and interact with data, information, people, and the world. GUIs provide a push button machine to allow a few of these things at a time, in a very limited and controlled way so that a user doesn't have to know and is not allowed to work with the underlying data that makes all of these things possible. It stands between you and all these wonderful things by allowing certain circumscribed operations with them, and it also prevents nearly all operations you might want to perform that were not part of the GUI's design to begin with.
We can make GUI's that provide the controlled interaction with the universe, but then also open up into a far richer interaction where people might want this. We can do this.
[0]
comments (77 views) | | [0]
Trackbacks
Posted by: Jon Grover | Jul 09, 10 | 1:07 pm
Wed Jul 07, 2010
GUI's don't know anything from anything
The reason for those awful field and screen GUI's is that GUI's don't know English or any other human language. In other words they don't know the meaning of anything. Informatics is based on drawing meaning from data, but once you have done that, guess what, your GUI will no longer understand what you're doing. This is strange because you probably got that information from the GUI.
Here's the real problem. Because programs only understand data, you have to do all of your interaction with them through data. This means that you end up usually looking at the 'grey face' of the GUI, and filling in fields here and there without the GUI being able to guide you toward where you need to fill stuff in. That would be the first benefit of having GUI's understand the information you are working with. It could guide you toward the fields involved. But GUI's don't understand the information so this does not happen.
We need a system that allows the application of simple information to data in such a way that a GUI can use information rather than data. To do this we need some new generic data structures for storing information rather than just data. With this we could make less deadening GUIs. GUI's would actually work with our minds rather than just our fingers. And I've been working on a some of the information oriented data structures. One is the
endeme. And a new one I have started working on I call the 'salad'. We can do this.
[0]
comments (56 views) | | [0]
Trackbacks
Posted by: Jon Grover | Jul 07, 10 | 12:23 pm
Tue Jul 06, 2010
GUI Tutorials Are Hugely Inconsistent
Have you ever tried to read a GUI tutorial? They suffer from a number of problems. Sometimes they leave out large numbers of steps so you actually have to know the GUI before using it. Sometimes they go the other way and describe individual steps in multiple full sentences complete with screen shots and arrows. Sometimes they are for a different version of the GUI than the one in front of you. Usually they do not cover enough of the GUI to really give you an education and nearly always they are hard to reference later. Finally they are inconsistent in style, grammar, terminology, and organization. The problems come down to granularity, consistency, completeness, and applicability.
I have a solution. It's called GUI Action Trace, or 'GAT' for short. It treats every operation using the same syntax. This fixes the granularity, consistency and terminology problems. Once you've learned the syntax, you can read any GAT and work within an expected granularity, terminology, and style. GAT can be collated into GAT files which can contain an exhaustive collection of operations. This handles the completeness problem. Once these files exist, they can be labeled with version information. This handles the Applicability problem. In order to make sure it covers each procedure with enough detail for those who do not know the GUI, it has to cover every click with some sort of symbol. Finally, you would no longer have to worry about finding the balance between either insulting someone's intelligence or not giving them enough information. GAT will provide a standardized level of detail that both teacher and learner can come to expect.
This leaves one problem. GAT looks complicated and ugly. If you don't like my version of GAT, you can make your own. I'm not married to mine and as a lazy idea person I'd be fine if someone else's good idea got implemented rather than mine.
GAT may be even more important as a trace than as a tutorial system as a number of the articles here mention a trace.
I'm sure we can do something better than the tutorials we have now. We can do this.
p.s. my earlier version of GAT was called SANGUIN, and a pattern was built for it at the Portland Pattern Repository
here.
{}OR { steps } OR { steps } decision block, do this or that, alternative
(three spaces) between steps
[X_\] [X] check box [X] check, [_] uncheck, [\] toggle
[[]]<<>>|| [[double click]] doubled/multiple levels/actions
> > command line type a command on the command line
: Label: label of a field
= ^ =Row ^Column identifies a cell by row and column
( ) (assumed label): when a field label is missing but assumed
_<>_ _<variable text>_ text input
^ [^V] control character
[ ] [ALT] special key
' 'literal text' literal text input
[ ] [click] [mouse down mouse up]
> navigation > from > to navigation
" "Computer response" when the computer says something
-- -- comment comment or non-GUI action
_[ _[X] close page
* (*) radio button radio button selected
<>\/ <selection>\/ dropdown, <> select 1, <<>> multiselect
+ [+] tree [+] open node, [-] close node
~ ~ step missed or not documented
| |2d area page, list, multiline textbox etc.
Examples:
---------
[menu > item] select the item on the menu
[menu > |title] select an item from the menu, the new page uses the item label as its title
[Start >> Calculator] starting from the start button navigate to the calculator
[item > RMB > operation] right click on an item and select the operation
-- TO ... -- comment at the beginning describing the operation
_[OK] click the OK button, it will close the window
~ ~ ~ ~ missed recording four steps in the process
|[tab] select the tab
||Panel panel inside a page
|||Sub-panel panel inside a panel inside a page
[<item>\/] select one item from a regular dropdown
|<item>\/| select one item from a dropdown that shows a scrollable list
[_<item>_\/] either type some text or select an item from the dropdown (combobox)
|<<items>>\/] select one or more items from the dropdown (mulitselect)
[+]node1 > node2 > node3 drilldown in the tree through nodes node1, node2, node3
(Address): [_<url>_] type the url in the address bar in a browser
[File > |Save As...] >> project step 1: open the save as dialog, step 2: navigate to the 'project' directory
-- load paper into the feed tray a step in the process that is not part of a GUI
=row [^column > RMB > Start] click the right mouse button on the cell (the column in the row) select 'Start'
{ _[OK] } OR { _[X] } close by clicking OK button or the X in the upper right corner of the window
[0]
comments (58 views) | | [0]
Trackbacks
Posted by: Jon Grover | Jul 06, 10 | 2:03 pm
Sun Jul 04, 2010
GUI's really get under my skin
You might think I hate GUI's. Actually I don't. I try not to hate anything. Sometimes I even like them, especially free-form editors. But GUI's often really get under my skin.
Especially the ones I have to deal with while programming. I'm afraid I've been spoiled. I started programming at a time when there weren't GUI's. You could actually do things with a computer, rather than staring at a GUI and only being able to do things the GUI programmer chose to allow you to do. With objects and classes you can add new methods to them if you have to. With GUI's you are stuck. Many times I have been using a GUI program and said to myself. Now I want to build onto this GUI program so that it can do such and such with the data and structure it already handles. But GUI's are not designed to be extensible. Yes there are API's but then we're not in GUI-land anymore. We are in programming land. Most GUI's don't have API's. Most GUIS are what you see is what you get, and even then you only get to see a little of it at a time. It makes them hard to work with. So why don't GUI's allow extensibility?
We really could build GUI's with extensibility. You don't have to be Google to make things that people can use in new ways. We can do this.
[0]
comments (49 views) | | [0]
Trackbacks
Posted by: Jon Grover | Jul 04, 10 | 12:49 pm
Sat Apr 24, 2010
GUI's are Grey
GUI's are grey. And I don't mean the color although many actually are grey. I mean that there is a deadening sameness to them. Each page looks very much like the others. (I guess this is called either standardization or branding depending on whether you are in the app or web world). The pages are hard to tell apart (well except for maybe drawing packages). Looking at a page looks like another looks like another. It's hard to tell a difference from any distance. So your mind does not pick up useful information like 'this page is for this' and 'that page is for that'. Tabular info needs to be laid out on a tabular page. Relationship info needs to be shown as a circle and edge graph. Some pages need to be crowded. Others need to be sparse. Anything to give the user the sense that this page is different from that and is different from the other. Put some sort of animation on one page, but not others. Make one page grey, another red, another blue. Lay things out in a circle on one page, a diamond on a second and a square on a third.
--
GUI makers could make the pages different. It would be easier for my mind to tell them apart. My mind would say 'I've been here and I remember a bit of what this page is about'. We can do this.
[0]
comments (597 views) | | [0]
Trackbacks
Posted by: Jon Grover | Apr 24, 10 | 8:02 pm