| Re: Re: Guidelines and Concepts
Oct 20 2012 on group FluiDE (New Computer Interfaces Discussion) |
An addendum in honor of Windows 8.
I am now thinking of all GUI's as special cases of what I have decided to call a stasis (plural stases) - I hope I will be forgiven. A stasis is an array of pairs of a pixel value and an object identifier. I am think of everything being an object and "stasis" is really an object class and a GUI is an instance ot a stasis array along with a folding number (call it A). Then the stasis array corresponds to a rectangular array. The dimensions of the array are A by N/A where N is the length of the array.
The stasis code displays the stasis pixels on a screen and sends a message to the corresponding object if the pixel is "touched". That's all there is to a GUI.
I intend applications to begin by bringing up an instance of their own of the stasis class. In the object-oriented model I am using all the instances of an object class share the same code so more gUI's is almost free.
I expect somebody to come around asking about touch screen based GUI's. This is my answer to them. There are, of course, some more details to work out before anything is actually implemented. |
|  | | Re: Guidelines and Concepts
Sep 22 2012 on group FluiDE (New Computer Interfaces Discussion) |
My goal remains simplicity. I fear this is already getting too complicated. My thinking is focussed elsewhwre. Here is an example of my present thoughts.
The underlying purpose of the interface is to present the user with a "display" of alternatives from which the user can select one.
If we use icons of about 24 by 24 pixels - which I think is appropriate for a touch screen - we can present up to around thousand alternatives on a desktop computer. This should be more than enough.
People can know more than a thousand icons (look at Chinese writing) but most people will not. So the first luxury we might add is the equivalent of tool tips. Tool tips don't work well on a touch screen (they tend be hidden by the hand) so I would add a bar at the top of the screen (other places on the screen also tend to be covered by the hand) where the tool tip is displayed. If you put you finger on an icon and leave it there for a while (dwell a bit) its text version is displayed in the status bar. To make the icon react you tap the icon (or dragi it).
Each icon reacts by sending a message to an object. Some of these objects will be utilities (like a file system) others will be applications.
Each of these other objects will have its own interface. Since it is generally agreed that interface consistency should be a design goal I want to make the basic interface no more than a case of a methodology any application (or utility) can use.
That boils down, at least conceptually, to where boot-up leaves a single icon which when conceptually tapped brings up what I called the interface and the interface itself is a rather dull utility.
The default interface would be a rectangular array of icons filling (potentially) the screen But everything should be customizable. |
| | | Re: Prototype
Sep 11 2012 on group FluiDE (New Computer Interfaces Discussion) |
Good Show. I downloaded the material on SourceForge but I haven't had time to examine it. I got discouraged because I couldn't do graphics as easily as I wanted. If there was a useable frame buffer out there I couldn't find it. I like the idea of using HTML5. Even if we have to run in a browser that better than not running at all. |
| | | Re: DE - Taskbar, Groups and Desktops
Apr 16 2012 on group FluiDE (New Computer Interfaces Discussion) |
I found the animation interesting and clarifying.
My concern is that it perhaps goes too far in supporting a single way to use the desktop. I would rather aim for something more generalized and customizable.
For example, I personally would prefer to start with a screen full of icons representing what applications and "documents" (meaning application instances) that I am currently using. Then I click on (or navigate with keys to) the one in want and it fills the screen.
I would dedicate one of the keys to bringing back the desktop. I personally have no use for more than one application instance at a time except at occasional moments where I would prefer to split the screen rather share one screen with two application instances.
But that is just the way I work. I know there are people whose screens always show a dozen or more different windows. I think a really useful new GUI should customize either way and other ways besides.
I think that I could say what I am describing as my personal way implies the task bar fills the entire screen and disappears when an application is selected.
By the way I seem to assume I am the only user of my machine (or at least of my screen). In any kind of a multi-user situation I think I talking about what happens the instant I establish my identity. |
| | | Re: Re: Some thoughts
Apr 12 2012 on group FluiDE (New Computer Interfaces Discussion) |
Hi, I'm back. Got distracted and got called away on family business.
I believe that the fewer features an OS has the better. The only excuse for a new feature should be that it provides something that could not be done otherwise. The OS itself could then be supplemented by utility libraries.
Some people use the phrase Operating System to mean what I called the OS plus all of a collection of utilities. What I mean by the OS may be no more than a wrapper around the kernel.
I am still intrigued by interactive fiction. It is sort of the ultimate text application. Even if we get listening-talking computers the text versions and speech versions should be in exact correspondence (especially for the deaf).
What happens in an interactive fiction is simple. The computer displays some text. You respond. The computer replies and so on ad infinitum. This should be very easy to do - but it isn't. I can write a program (I use 1990 ANSI C) and compile it (GNU C) and run it in an unattractive console.
How does a GUI differ? I could (and people have) added pictures to what the computer presents. I could (and people have) changed the user text response from typed input to selection of a button from a presented list of alternatives. A classical GUI is only about one step further.
The additional step is doing other things with the mouse. I can think of three -
(1) dwelling to bring up tool tips and the like
(2) dragging and dropping
(3) picking out points in an image
I would think of text as a image and moving the cursor to a point in the text and clicking - in order to relocate the insertion caret - is an example of (3). But it is possible to do the same thing without the mouse. Even a point on a map can be located without a mouse. So maybe (3) doesn't count.
Likewise drag and drop.
To handle dwelling without a mouse I have to get more desperate but it can be done.
The key to GUI's seems to be that we have a two-dimensional array of pixels and a means to focus on one of these pixels and send that pixel a message. I have suggested that we maintain another two-dimensional array parallel to pixel array with the address where the message should be sent.
I observe that I really think the only way programs - all of them - should interface with a display is via a frame buffer. Is there any reason why this should be not assumed from the very beginning ?
|
| | | Re: Status of the project
Mar 23 2012 on group FluiDE (New Computer Interfaces Discussion) |
Well, I am sort of semi-dropped out and have no real investment in this any more. I agree with the long-range goals but not with the short-range ones.
I think it is of little value to rush to prototypes and the like until we know exactly what we are doing. So far I can detect no consensus - except maybe on dark frames around lighter-colored workspaces and even that can be overdone by putting things in the frame - I find print of any color on a black background almost unreadble.
I don't know if I can help at all in my frame of mind but I will continue to hang in there - at least for a while.
I agree that Google groups would make these conversations much easier to carry on - but I observe a rather wide-spread prejudice against them (usually in favor of Usenet). |
| | | Re: Re: Re: Re: My experience with HUD
Mar 11 2012 on group FluiDE (New Computer Interfaces Discussion) |
The human mind and the computer are very different. The human mind excels at recognizing patterns. It is so good that it sometimes recognizes patterns that aren't there - like the canals on Mars. I think technical analysis of the stock market is in the same boat - reading patterns into a random sequence.
The computer is not very good at patterns. After all these years - and massive effort - we still cannot use computers to comprehend natural human language. [Opinions on language vary - I see it as the triumph of pattern recognition).
The trick is get man and machine to work together as a team. I don't think we have done very well on this so far - but it is a great goal |
| | | Re: Re: My experience with HUD
Mar 11 2012 on group FluiDE (New Computer Interfaces Discussion) |
Not about GUI's. About the word "Mongoloid".
I understand that you may not have had contact with persons with developmental disabilities. And, yes, this is a family matter. Mongoloid is considered offensive and degrading and, to be honest, I hadn't heard it for years.
There are many causes of developmental disability and Down(s) Syndrome is only one. Many people with Down Syndrome have the characteristic facial features that led to the term Mongoloid.
There is no clear-cut dividing point where a person can be called disabled and capabilities vary widely. But, yes, there are people who will never be able to use a computer. My daughter talks but does not read or tell time - but she is great with icons. But no one is so foolish as to let her cross a street by herself.
It takes all kinds. |
| | | Re: Re: Folder Types
Feb 26 2012 on group FluiDE (New Computer Interfaces Discussion) |
I find the Nautilis emblem system of no use. At least I think that is what you have in mind. There are several difficulties. The most significant is that it is way too high level.
I have folders containing on the order of a hundred text documents about dozens of different matters. I think there is no hope of controlling them with icons. Not the least problem would be remembering which icon went with which file. In practice I just ignore the icons.
I should use more folders - perhaps - but Nautilis is slow and clumsy to use if one is constantly changing files. Sometimes I just open everything in gedit at once and use the gedit tabs to find the file I want.
Icons would work better if I could create a new and unique icon for each new file (or folder). This is impossible if we assume ordinary graphic art. But maybe artificial pictures would help. One idea (which fails if you are color blind) is to divide the icon into, say, nine equal boxes (three by three) assume a palette of, say, sixteen colors. Then you can make 9*16 = 144 different icons. But I would reject that idea because it is ugly - if I had no other reason.
I am convinced that for many users the name hierarchy will always be the way to go. We just need to make it easier.
But underneath all these names and icons each file has a unique identifier. Whatever file management we adopt is an interface between the user and these unique identifiers. I am arguing that to some extent the interface can be graphic but, in the end, it must be textual.
By the way the idea of executable folders isn't mine. I borrowed, I think, from Visual Basic. |
| |
Search people
Current visitors
New users
Birthdays
Most active users
Back
|
|
