GUI's hide what you're working with, in a bad way

Let's say I have a database that I want to interact with. I can write SQL statement to do lots of stuff with it without a GUI application. The Query analyzer in SQL Server lets me type in SQL and get back a result. There are a couple problems though.

It's hard to write a good query if you don't know the organization of the database; and there are queries you want to run over and over and it would be good to have them embedded into some sort of application so you can select them and run them. Therein lies the rub. Those applications hide too much. You can't change the query even a little bit when you use them, and because they just end up being buttons with names, they generally hide the tables and the table names. How can you really work with something you don't know much about?

A solution would be either: a generic database browser or a User Interface in the shape of the database ERD with modifiable embedded queries. Which will work better depends on your user's needs. Both will show the user what they are actually working with. The database browser will show tables, data, columns, and links through foreign keys. Make the rows vertical and the columns horizontal and the display will fit well on a screen. It will allow browsing through the database but isn't so good for either queries or security. If you need security and complex queries use an ERD based system, not a GUI (by this I mean a field and screen system that most database applications are). The UI layout will show how the database is structured, and yes you can page and scroll it so that a really large one can be used, and you can have the queries under buttons positioned on the relations between tables. Either that or have the links sitting in the most detail heavy table in the query. have them editable and resettable, and have a place to create new queries. This may be part of why users seem so dumb. maybe it is because we GUI builders are hiding what they need to know from them.
--
So why don't GUI's represent the data underneath? It would sure expose the knowledge of what's actually going on to the user. The user could use the knowledge to know what new features to ask for. The user could also use the database intelligently. We can do this.

[0] comments (211 views) |  | [0] Trackbacks

GUI's Create user Dumbness

The GUI hides what's going on underneath, so when something goes wrong

• The user has no clue about what went wrong and just says 'it doesn't work'.


• It ends up being the work of only IT people to figure out what the problem is.


• Huge silos get built between the professions of user and IT.

The problems are:

• Users become helpless in the face of errors.


• users can't help much when something goes wrong.


• Users use the systems less intelligently than they could.


• Many features are barely used.


• Users don't know what computers can really do for them.


• There is little pressure on the software world to create really new things.


• The software development world stagnates.


• Developers end up writing more or less the same program over and over.


• Creative people leave the programming profession.


• Creative programs do not get written.


• Companies without the new products necessary for them to keep growing die.


• Competition in the software world weakens.


• One company becomes a monopoly in parts of the software world (Microsoft).


• The software indstry stagnates still further.


• Most new ideas get channeled into one area (social networks).


• The creative atmosphere thins out in other areas of software (AI, intelligent agents, artificial creativity).

The core of the problem is that the mental structure of a GUI and the mental strucure of a program are very different.
So people don't ever really learn to use computers.

The best fix I have for this one is to start building representational user interfaces.
When the user interfaces represent the program underneath then users can start understanding what they do and how they work. Maybe programs can even be set up so they can drill down into the program and users can change or reuse the things they need to do new things rather than just what the program has been written to do.

We can do this.


[0] comments (226 views) |  | [0] Trackbacks

GUI's Don't Loop Well

What if you have to perform a fifteen click operation on each of 10,000 items. In a GUI this would require 150,000 clicks. Carpal tunnel here we come. GUI's are really atrocious when you want to do things more than a couple times.

If you could store a trace of what you did and then write a loop around the trace this would handle it. Why don't GUI's allow you to write a little control structure and apply it to a little trace? I have developed a notation called GAT (Gui Action Trace) which could be a trace that could then be used as part of a facility to repeat a set of actions.

We can do this.

[0] comments (168 views) |  | [0] Trackbacks

GUI's Ossify Companies

...or perhaps applications ossify companies. GUI's and applications get built or configured based on the company's business practices. Then they don't get changed which means the company's business practices don't get changed, so the company stops changing. This means it no longer changes due to market changes and eventually dies. If the GUI automatically changed along with the application this would cut the technical resistance to change in half, but that would mean that the applications would determine the GUI rather than the users, and since the applications and the GUI's are our slaves and must do what we say, this is socially unacceptable. Everything a programmer has to do ossifies a company. making a GUI, making a program, building a database, debugging. Programmers have certain weapons against ossification: layering and object orientation, but this only works up to a point.

What if we found a system that allowed programs and applications to play well together. We would have to find a way to make a fast language or structure that was not compiled. Doing this at the right granularity would allow programs to work together. Standards could be the glue that holds things together. I guess we've tried all this. I wonder if endemes could help. They would help with the GUI side by making it easier to find a function in an application. If the GUI's were gotten rid of and the user had a more representative way of interfacing with a program - that is more representative of the underlying structure of a program, then they would better know the sea they were swimming in. Just a few ideas, but I guess my main point is, the ossification of applications and therefore companies becomes extreme when we use GUI's. We can make applications and systems more felixible by replacing the GUi paradigm with something else. We can do this.

[0] comments (169 views) |  | [0] Trackbacks

GUI's Can't be Modified.

OK, I'm back to ranting and raving about GUI's.

You can't change a GUI. You are stuck with what you've got. If you have an operation you would like to do often, you would probably like to have a simple way to do it. If the GUI provides a complicated and long string of actions to perform it you can not change this. You have to click and click and click each time you want to do it. No code, means no ability to change things. Code means control of the way things operation. No code means the GUI builder controls how things operate. IF the GUI builder doesn't know what you are going to do with their program, they can't set it up to work efficiently for you.

Why don't GUI's expose little bits of code so that you could modify some portion of the way they GUI operate and also have a reset button if you mucked the code up? We can do this.

[3] comments (223 views) |  | [0] Trackbacks

A First Pass at a Design for The Singularity

Human relationships have progressed through six orders.
The seventh is upon us. I forecast that the revolution will be in 2014.

	2^0	| 1 self
x2
	2^1	= 2 partnership (one-on-one)
x4
	2^3	| 8 family
x16
	2^7	= 128 team
x256
	2^15	| 32,768 tribe\hierarchy (B)
		- with a person at the top
x64K
	2^31	= 2,147,483,648 civil society (F)
x4B
	2^63	| 8*10^18 cyber society - 8 quintillion people - 9,223,372,036,854,775,808 (J)
		- At 1 billion people per planet, that's 8 billion planets.
		- At 1 billion agents per person that's 8 billion people
		- with the person at the top
x2^64
	2^127	= what would this be?, it's not even imaginable to me (Network)

Here is the same progression again focusing on the expected number of people for each order, showing group size:

1	self	|
2	pair	= each interacts with 1 - (1 other) - God is a friend
8	family	| each interacts with 2 - (1 mother, 1 father) - God is the father
128	team	= each interacts with 8 - (2 chiefs, 4 members, 2 others) - God is the captain - there is only one God, the 

creator of the universe
2^15	tribe	| each interacts with 128 - (2 hierarchs, 4 above above, 8 above, 16 below, 32 peers, 64 others) - God is 

the top of the hierarchy, bad: there are many gods
2^31	civil	= each interacts with 2^15 - (2K competitors, 4K vendors, 8K customers, 16K market) - God is the most 

important, bad: god is everything
2^63	join	| each interacts with 2^31 - (120M deciders, 250M organizers, 500M services?, 1B people in the world) - God 

weaves the spread, bad: I am the center?
2^127	network	= each interacts with 2^63 - (2^127 agents)

What if every person in the world had a separate intelligent agent (an artificial person) to interact with every other person in the world as part of the next order. How would that do?

How out of a billion agents do you rise to the level of attention?

- to conceive, select, grow, implement an idea
- to work/create together
- to alert each other
- to broadcast a message to many
- to converse
- to help each other
- to understand each other
- to know each other so that we can know the significance of the contact
- to 1 build a partnership
- to 2 marry each other
- to 3 build a team
- to 4 build a hierarchy
- to 5 build a civil market
- to listen to many
- and the agent would make decisions
- and the agent would interact with other agents in order to determine priority
- the agent would become an entity
- sales vs honesty (fix this problem)
- therapy/support
- navigating the spread

- and the agents would have 2^127 interactions 'links' - but you need to develop the agents first

- what can an entity do? create, analyze, decide, interact, learn/grow, love, attack, ignore, search/find, follow/obey

Here is the history structure within which each of these orders has/will occur:

----1	226B yrs
-W-
-V-
-U-
-T-
----2	14.1 B yrs
-S-universe/stars
-R-planets
-Q-quickening/life
-P-oxygen
----3	881,942,216 yrs
-O-animals
-N-land
-M-massive/size
-L-flowers
----4	55,121,389 yrs
-K-lemurs
-J-jungle/monkeys
-I-apes					64 ice ages
-H-hominids				32 ice ages
----5	3445086.8 yrs
-G-humans				16 ice ages
-F-family				8 ice ages
-E-stone				4 ice ages
-D-killing/language			2 ice ages
----6	215317.92 yrs
-C-consciousness/minds/cold		1 ice age
-B-teams
-A-artifact/technology
 @-merging
----7	13457.370 yrs
+A-agriculture/cultures	age		hexadecade	quartade	4096ade
+B-barbarian		-------		-------		-------		-------		-------
+C-civilized		1792 years	112 years	7 years		160 days	10 days
+D-dark/decycle/alphbet	897 years	56 years	3.5 years	80 days		5 days
----8	841.08564 yrs
+E-enlighten		448 years	28 years	640 days	40 days		sleepless
+F-federal		224 years	14 years (era)	320 days	20 days
+G-generator		112 years	7 yrs		160 days	10 days
+H-holocaust/computers	56 years	3.5 yrs		80 days		5 days
----9	52.567853 yrs
+I-internet/agents	28 years	640 days	40 days		sleepless - whatever was before does not impinge
+J-join			14 years	320 days	20 days
+K-krobotics		7 years		160 days	10 days
+L-loss			3.5 yrs		80 days		5 days
----10	3.2854908 yrs = 1200 days
+M-			640		40 days		sleepless - whatever was before does not impinge
+N-network		960		20 days
+O-			1120 days	10 days
+P-			1200 days	5 days
----11	75 days
+Q-queen of ?		1240 days	sleepless
+R-return?		1260 days
+S-			1270 days
+T-			1275 days
----12	4.6875 days = 112.5 hrs
+U-
+V-
+W-
+X-

with 7.03125 hrs left over

[0] comments (198 views) |  | [0] Trackbacks

GUI's Have No Formal Notation.

GUI's are not formal languages and they do not adhere to a formal language. Although they are as complicated as computer languages they suffer from the lack of formalization. When you work with a computer language there is a consistent format to what you are working with. These are called formal languages. Formal languages mean that you don't have to learn a different configuration for every operation. They mean that you can learn the formalism and then rely on what you've learned as you learn new part so the language. They mean that you know what to expect. Even with a new language you know there's going to be a formal language in there somewhere. GUI's are not like that. Every one is different. No formal notation exists to describe them. You can't learn one GUI and then expect to use your knowledge to learn others. You can't even take a step back and look at a formal representation of the GUI to see how it's structured.

There could be a formal notation for GUI's. It would help as we tried to learn the next GUI. We can do this.

[0] comments (195 views) |  | [0] Trackbacks

GUI's make it hard to figure out what went wrong.

If I am going to complain about GUI's, it makes sense for me to probably come up with something better. The better UI would perhaps include the best of GUI, a little bit of file editing (code like) and a search feature beyond anything we now have. The search feature would be based on endemes and focused as its context on the application at hand. Anyway, here is this week's rant about GUIs.

Lets say you use the SQL Server Reporting Services Report Designer to build a report, then store it in SharePoint, then run it from either SharePoint or a C# program. Most of this is handled with GUI's. If something goes wrong, you get the useless message 'An error has occurred during report processing. (rsProcessingAborted) Query execution failed for dataset 'MyList'. (rsErrorExecutingCommand) For more information about this error navigate to the report server on the local server machine, or enable remote errors '. How do you tell where the error is? Is it in Sharepoint? SQL Server? Your Stored Procedure? Your Dataset? Your Report? The way the connection is stored in SharePoint? Your C# program? The browser? Because none of these systems allow you to use breakpoints you can't tell which failed. In this case it turned out to be permissions on my stored procedure. It could just as easily have been any of the others; but the error doesn't say anything about permissions problems. It doesn't say anything about a stored procedure. And yes I've tried enabling remote errors and it has never worked.

Another error I have had complains about not being able to connect to the database. How was I to know it was some checkbox or other in SharePoint? The error mentioned the database, not SharePoint.
--
Why don't GUI's have debuggers? Even if you can't change the code inside, seeing where things go wrong could be really helpful. We who build user interfaces can do this.

[0] comments (251 views) |  | [0] Trackbacks

GUI's Lack Memory

GUI's have no memory. GUIs don't have the ability to retain the sequence of what you just did with them. When you click, and drop, and click, and drop, and type, and bring up, and close etc, there is no memory in the system of what you just did. How on earth can you figure out the long and convoluted series of actions you took with the GUI so six months down the road you can do it again? Then lets say you have to grind through a dozen of these complex sequences a week. How can you possibly remember all of them? Or even a few of them. GUI's are not easy. They are a pain in the brain. At least they are for me because I have a weak memory. Are computers really only for those people with great memories. come on!
--
GUI's could have traces so that you can repeat or at least re-read what you've done? You could go tho the trace page ad see what you have done and even copy it out and paste it into a user manual. We can do this.
[0] comments (202 views) |  | [0] Trackbacks

GUI's hide the functions you need to use, in remote places

I have for years had trouble with GUI's. For those who don't know, a GUI is a graphic user interface and is what you nearly always see these days when you open a program. I have trouble with them. I have scoured the net looking for others with my particular difficulty and have found little comment and nothing organized. So I have decided it is time for someone to speak up. This is the first in what will hopefully be a series of articles on the trouble with GUI's. Mostly it will be rants about the difficulties. If I am successful, it will also include a few solutions to the problems I describe.

The things you need to know about are hidden behind GUI's and you have to go through one two three or more buttons, menus drop-downs etc to find them, if you can find them. When you look at a GUI all that is there at the start is a few buttons, links and menus in a grey (or sometimes colorful) screen. Grey does not convey much neither does color. So where do you look for the function you need. Well you have to start going through each menu, drop-down, button and link to find it. You are likely not to recognize it when you do. It often won't have the name you expect it to have. And it may be some obscure little check box off in the corner of some obscure screen, many levels deep in your search, by which time if you actually reach that screen you may be so tired of looking at screens or just tired in general that you don't have the mental energy left over to notice it as it goes by. The number of places to look for something often makes this a gargantuan task, and then once you've found it you have to go through the same process again for the next thing. Think of having to search a disordered library without an index for a single book by having to read the title page inside every book until you come to the right one. Then consider that there may be a closet that you don't know exists with even more books. This is what I face every day when I use GUI's.
--
GUI's could have indexes. Web sites often do, or they use Google. We who build GUI's can do this too.
[0] comments (227 views) |  | [0] Trackbacks