A Proposal For The Addition Of Color-Reactiveness To The GNOME Desktop

[Bowie Poag <bjp primenet com>]

----------------------------------------------------------------------------

----------------------------------------------------------------------------

   A Proposal For The Addition Of Color-Reactiveness To The GNOME Desktop

----------------------------------------------------------------------------
Written By Bowie J. Poag                                            05/19/98
----------------------------------------------------------------------------


Document Overview:

  I. Introduction
 II. Descriptions of Color-Reactive Elements
III. Behavior, Methodology and Implementation
 IV. Usage Examples
  V. Questions And Answers 
 VI. Conclusion

Appendix:

  A. Image, depicts placement of a color-reactive element within a window.
     (387x300 JPEG, 23KB)
     Location: http://www.primenet.com/~bjp/Appendix-A.jpg  

  B. Archive, contains 8 Lamps and 8 Beacons in a variety of image sizes.
     (ZIP Archive, 200KB)
     Location: http://www.primenet.com/~bjp/Appendix-B.zip 


[ I. Introduction ]

                 A Brief Overview of Color-Reactiveness

For the seven month period spanning from July 1997 until late January
1998, I was involved in an OS development project called InSight. Part of
my role within the InSight development group was to study pre-existing
interface designs in an attempt to further understand which aspects of
contemporary interface designs would still be viable and useful for users
for the next 5 to 7 years. 

Within that seven month timeframe, we developed several improvements (and
outright replacements) for pre-existing interface devices. One of the
earliest of which was the concept of a "color-reactive" desktop; in where
specific elements of the desktop had the ability to express their status
via changing color. This certainly isn't a very new (or complicated) idea,
as similar thoughts and manifestations of this basic idea have existed in
other platforms for years. Color-reactiveness is merely the result of an
idea whose refinement has taken several years to fully gel, and evolve into
something which could now be construed as beneficial to the user. The
development of "Color-Reactiveness" is simply my contribution to the
overall refinement process.

So what is it? :)

The quickest analogy I can point to is that of a 'mood ring' for 
applications. For those of you who don't know what a mood ring is, it's 
a novelty piece of jewelry that can change the color of its gemstone
depending on a person's mood..Well, according to folklore, at least. (Its
actually changing color due to skin temperature, but we'll ignore that for
the sake of explaining the concept..)

A mood ring, and a color-reactive desktop element are both objects which
employ color to convey the status of the object to which it is tied; The
person wearing the ring can be thought of as an application, and the mood
ring itself can be thought of as the color-reactive element.

Looking past the amusing folklore of the Mood Ring, we can develop a table
of the person's emotional state as it relates to color, like so:

 State     Color       Depending upon the emotional state of the person
 ------    -----       wearing a mood ring, the ring will appear to change
 Sad       Blue        color. At one moment, the personal can be happy,
 Happy     Green       and the ring will be Green; within minutes, the 
 Angry     Red         person may become bored, and the ring will slowly
 Bored     Aqua        shift its color to Aqua. The status of an application
 Nervous   Yellow      on the desktop can be conveyed in the same manner;
 Tired     Purple      using color as a means to convey operational status.


Applications which employ color as a means to convey operational status are
known as "color-reactive desktop elements". Quite literally, a mood ring
for an application. We even have specific names for them, depending upon
how they're used; as a Lamp, or as a Beacon.

[ II. Descriptions of Color-Reactive Elements ]

A. Lamps

 A lamp is a window element whose color is tied directly to the operational
 status of the application which uses that window. Simply put, its like
 a little status LED for that paticular application. As you use the program,
 its lamp changes color depending upon whats happening, and depending upon
 what you'de like it to reflect -- CPU usage, program status, etc.

 Lets say you have an e-mail checker. You've told it to check your mailbox
 every two minutes for new mail. So, most of the time, the lamp in the
 window remains blue--just sitting around, waiting for something to do.
 Every two minutes, it turns yellow, to indicate that it is busy checking
 your mailbox for new mail. If no mail is found, it goes back to blue.
 If new mail IS found, it turns yellow, or even begins flashing.

 (See Appendix A)

B. Beacons

 Beacons are like miniature lamps, meant only to be used when applications
 are in an *iconified* state. Lets say you have a window open on your
 desktop. It has a lamp in one corner of the window. Now, lets say that you
 click the iconify button, and collapse the entire application into an icon
 on your desktop; since you still want to monitor whats going on within that
 application, have it collapse down into a beacon, instead. At least that
 way, you will be able to see visually whats going on with the application
 without having to constantly re-open, and close them back down again.

 Here's an example: You're downloading 5 different .RPM's via FTP. You can
 collapse each one down into a beacon who's color reflects whether or not
 the download is proceeding without any problems. At this point, you just
 have 5 little beacon icons down at the bottom of your screen, and you are
 able to monitor their progress just by checking to see if they are all
 still glowing a nice shade of green. You could even have it so that the
 color was a function of how fast the transfer was going. Bright green
 could indicate a fast transfer, and red could indicate a slow or dead
 transfer. Get the idea?

 (See Appendix B)

[ III. Behavior, Methodology and Implementation ]

A. Behavior

 In order to fully understand how Lamps and Beacons behave, you must
 keep in mind the fact that the color of the lamp (or of the beacon) can
 be tied to a variety of "behavior sets" (explained later). As pointed
 out earlier, the color may be dependant upon CPU usage, process status,
 or directly tied  to events which may occur within specific
 applications. These are types of behavior sets. Lets think
 about a few practical examples before we tackle the details of how to
 go about implementing such an idea.   

 Lets say one of the above-mentioned FTP transfers begins to stall. One
 of the beacons begins to glow red, and stays red for several minutes.
 Simply pop it back open, kill or restart the transfer. The instant you
 kill that process, the other four beacons begin to glow more brightly,
 since you have just improved the speed of the other four by freeing up
 a little bandwidth.

 Beacons make the task of babysitting multiple applications a breeze. An
 entire 3D rendering package could be collapsed down into a single beacon;
 A beacon which could be told to turn green when the rendering of a scene
 has been completed, for example. There is no longer any need to
continually pop the application back open to see whats going on.

 A "behavior set" dictates what actions will produce what colors, much
 the same as the examples listed in the Introduction portion of this
 proposal. 


B. Methodology

 Since the behavior of color-reactive elements should be consistant
 thruought the desktop, a centralized point of control is needed (in the
 form of a Control Panel, for example) to allow the user to top-level
 control. From there, it would also be wise to allow the applications
 themselves, if given permission to do so by the user, to dictate their
 own behavior sets. Ultimately, the user must have total and complete
 freedom to dictate the appearance and behavior of color-reactive
 elements on his or her desktop. 

 There are two ways to go about changing the appearance of a Lamp, or
 of a Beacon on the desktop. With InSight, the plan was to simply change
 icon on the fly, by loading in the appropriately-colored icon in its
 place, if need be. The second way, which takes considerably more CPU
 time to pull off, involves hue-shifting the image data within the icon
 +/- 180 degrees to achieve the desired color. 

 The first method requires a small cache of colored icons to be present,
 and ready to be loaded in. Ususally, about eight different colored
 lamp icons (and eight beacon icons, respectively) are enough to handle
 most situations. Appendix B (mentioned above) contains a small archive
 of example lamps and beacons in different colors for you to look at,
 and experiment with. The eight colors are Clear, Blue, Aqua, Green,
 Yellow, Amber, Red, and Purple.

 Thats right, the raw image data has already been provided for you. These
 icons are in all respects ready-to-use.


C. Implementation

 Here's how to go about constructing a control panel to handle behavior
 sets for color-reactive desktop elements. 
 
 The user should be presented with a list of potential "states", (like
 Busy, Idle, Sleeping, Error, etc) and then be given the ability to map
 colors of their choice for each state.

 The "Color Transition Table" allows the user to specify the physical
 behavior of the Lamp, or Beacon. A whole big row of "C" means simply
 "for this behavior, the color always remains clear" ..Just the same
 as a repeating sequence of "BRBRBRBRBRBR" would make the lamp
 rapidly flash between Blue and Red, over and over again. To slow down
 the rate of blinking, imagine a sequence like "BBBBRRRRBBBBRRRR".

 Get it? This is a little difficult to understand for some people, so,
 take your time.

 The Color Transition Table allows the user to specify the sequence of
 colors it shows to indicate each specific "state" .. Like if you wanted
 to get the user's attention, you would probably want to make the Lamp
 or the Beacon flash rapidly. This can be done by alternating the sequence
 of colors, like drum beats in a song. To use an analogy, the lights on a
 police car can be thought of as color-reactive elements. When the police
 car is in a state called "Pursuit", it's behavior is Red, Blue, Red,
 Blue, Red, Blue.

 Here's how to read the table:

 RRRR = Red Red Red Red, and RBRBRB = Red Blue Red Blue Red Blue. To make
 a Lamp or a Beacon flash like its on fire, a sequence like ROYOROYOR
 will make it strobe from Red to Orange to Yellow to Orange to Red,
 repeatedly. Now do you get it? :) 

 The Color Transition Table allows for a tremendous amount of flexibility
 when dictating the precise behavior of color-reactive desktop elements.
 By simply changing the entries in the table, you can do everything from
 solid colors, to wild rainbow effects, just by playing with the order of
 colors for each state.
 
 Have a look:

+--
| ----------------------------------------------------
| Example Behavior Set #1:
|
| Key:  A = Aqua    C = Clear   O = Orange  B = Blue
|       Y = Yellow  V = Violet  R = Red     G = Green
|      
|
| State               Color Transition Table
| ------------------  --------------------------------
| Idle                CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC \
| Sleeping            BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB  \
| Low CPU Usage       VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV   > Solid Colors.
| Moderate CPU Usage  RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR  /
| Heavy CPU Usage     OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO /
| Severe CPU Usage    YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
| Attention           GGGGGGGGCCCCCCCCGGGGGGGGCCCCCCCC \  See how you can
| Error               RRCCRRCCRRCCRRCCRRCCRRCCRRCCRRCC  > set the behavior
| Busy                ACCCACCCACCCACCCACCCACCCACCCACCC /  to blink stuff?
| ------------------  --------------------------------
+-- 

 This is what the behavior set would look like if you wanted to:

 Clear color for Idle
 Blue for Sleeping
 Violet for Low CPU Usage
 Red for Moderate CPU Usage
 Orange for Heavy CPU Usage
 Yellow for Severe CPU Usage
 Slow Blinking Green/Clear for Attention
 Fast Blinking Red/Clear for Error
 Normal Blinking Aqua/Clear for Busy


[ IV. Usage Examples ]

Color, in this case, can be shown as a function of CPU usage:

 Dead                     Clear
 Light                    Purple
 Moderate                 Blue
 Heavy                    Green
 Severe                   Yellow
 Extremely CPU-Intensive  Red

Or, as in this case, as a function of process state:

 Zombie                   Clear
 Sleeping                 Purple
 Idle                     Blue
 Running                  Green
 Waiting                  Yellow
 Segfault/Dead Stop       Red

Or, simply as a user cue, like in a 3D Rendering package:

 Waiting for User Input!  Blue
 Busy...                  Yellow
 Rendering..              Green
 Error!                   Red
 Finished!                Clear


As you can see, instead of using simple solid colors, lamps and beacons
can be made to -flash- colors, like flashing red to indicate a
catastrophic failure, and alert, or even an incoming message.

A pager program, or email checker could be collapsed into a beacon that
would turn green whenever you had a new message waiting for you to read.
A packet sniffer could be made to flash red whenever suspect ICMP packets
are recieved. An FTP client could use its Lamp to indicate the various
stages of connection to a host, or the progress of a file transfer. These
are just a few ideas I came up with off the top of my head --  The
possibilities for implementation are endless. 

[ V. Questions & Answers ]

Q: "How in the world are you going to tie all of this to the OS? ..And
    do it without dragging the entire system to a crawl?"
A: "The code responsible for color-reactiveness can (and should) be
    tied directly to /proc, or something which watches /proc for you.
    Updating the color of a Lamp or Beacon should only occur maybe 4
    to 6 times per second, optimally. Yes, I did my homework, and yes,
    I actually sat down and did the math. Updating the color of the
    Lamp or of the Beacon that frequently shouldn't take much effort.
    Setting up a watchdog process which monitors /proc (as opposed to
    hitting up /proc directly) makes it possible to do stuff like remote
    monitoring of other systems across networks, which was part of the
    original plan with InSight, to begin with."


Q: "Nice idea, but just -how much- CPU time is this going to take?"
A: "Next to nothing, if done right. No more CPU time than it takes to
    animate a GIF file on a web page, if done right. However, I would also
    imagine that the CPU toll would be proportionally heavier when several
    windows are open, or many, many Beacons are present on the desktop.
    Certainly, the CPU penalty would never be so severe as to cause an
    unneeded hinderance to the machine."


Q: "I'm a little fuzzy on all of this...Errrr... So, lemmie get this
    straight.. Color-reactiveness is when the OS is monitors the status
    of each process present on the desktop, and changes the little light
    up in the corner of the window to reflect whats going on, according to
    a set of user-specified colors configured ahead of time...?"
A: "Bingo."

Q: "Why didn't you just use traffic lights as an analogy?"
A: "Because traffic lights aren't really color-reactive. Traffic lights
    use a separate lamp for each state (red for stop, yellow for warning,
    green for go, etc) ....Lamps and Beacons only employ ONE light,
    respectively, which has the capability of showing SEVERAL colors.
    Traffic lights are a poor analogy."

Q: "I'm not quite sold on the idea..Color-Reactiveness seems like more of
    a gimmick than something really useful to me. Convince me that its
    not just eye candy."
A: "Allright. How many times have you had applications inexplicably lock
    up on you without any real indication of what went wrong, without
    digging up the process list, or looking at 'top' to find out what
    happened? How many times have you had to babysit an entire screen full
    of progress windows, all of which having their own progress
    indicators? How often have you been bugged by annoying and obtrusive
    pop-up windows telling you when something has been completed? How
    often have you wanted to know at a glance whether or not something
    you're running is performing up to snuff? Color-reactive desktop
    elements can alleviate ALL of these problems, quickly, and elegantly.
    As long as we have the opportunity to do so, we should include it
    -now- before anything has really been set in stone. 


Q: "How are Beacons different from Lamps, again?"
A: "Beacons are smaller versions of Lamps. Lamps are little gadgets which
    sit directly on the window frame of an application. When you iconify
    the application, it turns into a Beacon.. A little icon on your
    desktop with a tiny little Lamp up in the corner, so you can still
    watch it and see whats happening inside the application without it
    being open."


Q: "When did you come up with this stuff?"
A: "During my work with InSight, around September of 1997. It was one of
    the first ideas we came up with regarding how to improve modern GUIs."


Q: "Why GNOME?"
A: "Why not? And why not KDE, for that matter? :) *hint hint*"


Q: "No, I mean, why should GNOME incorporate this idea into the design?"
A: "Alot of reasons. For one, it would set GNOME apart from its
    competitors, as being an innovative (and more importantly, a NEW)
    improvement to traditional GUIs. Linux needs to set itself apart from
    all the bloat, bullshit, and hype intrinsic to other platforms by 
    addressing the problems contemporary users face when dealing with
    GUI's in general. Color-reactiveness is a useful idea, fairly easy to
    implement, and would only take a minimal amount of system resources to
    pull off. Above all that, its just plain cool to have. :)"



Q: "What if you *DO* end up having a ton of windows open on one screen,
    and your system begins to slow down as a result of having to
    continually update all these little lights?"
A: "A smart programmer will write the code responsible for handling
    color-reactiveness such that this never happens. If the total number
    of Lamps and Beacons on a screen exceeds a known threshold, the 
    frequency of updating them should be reduced to compensate for the
    load they incur on a system. Simple load balancing."
 

Q: "I noticed that you have 'Clear' colors...What are they for?"
A: "To indicate that nothing is happening, usually. Clear lamps and clear 
    beacons are just there for the sake of completeness; Sometimes, you
    wouldn't want a color-reactive element to show anything at all."


Q: "Dont you have an animated example or some code to show us?"
A: "While I do code some C/C++, I dont know nearly enough to write the
    code to demonstrate it under X11. All I can do is write, and
    illustrate the idea."

Q: "Ok..How is color-reactiveness beneficial to the user?"
A: "Lamps and Beacons provide information about program status in a quick,
    at-a-glance fashion. The same concept can also be applied system-wide,
    to provide similar information about hardware and OS status..Not just
    application status. Use your imagination, and you'll begin to see how
    this whole concept can be applied nearly universally to any OS/GUI."


Q: "I still dont get this Behavior Set stuff. Can you try explaining it
    again, using plain English?"
A: "Oh, fine. I'll try again. See, every application you are running on
    your machine will invariably pass through different states of
    operation. A program can be asleep, or busy, dead, or idle, for
    example. The whole concept of color-reactiveness rests on this very
    idea. The specific colors (or patterns of colors) you wish to
    represent these different states form whats called a "Behavior Set"...
    That is, for every individual state (sleeping, idling, running, etc)
    there is a corresponding behavior that the lamp or beacon will
    exhibit. For example: Lets say you want it so that every time a
    program crashes or locks up on your system, the OS will cause the Lamp
    or Beacon to flash red, on and off, continuously. You specify this in
    the Control Panel (mentioned in Section III) responsible for
    color-reactiveness. For the behavior of 'Error' , you should specify
    RCRCRCRCRCRC, etc..RCRCRCRC is shorthand for 'Red, then Clear, then
    Red, then Clear..' .......NOW do you get it?"


Q: "No. I don't. Try explaining it again."
A: "Aargh! Behavior Sets are what you set up to dictate the how the Lamps
    and beacons are supposed to look, depending on whats going on! A 
    Color Transition Table is WHERE you specify how each state is going
    to look." 

Q: "Oh, I see -- Finally! RRRRRRRRR kinda means that the lamp goes from
    Red to Red, to Red, to Red, to Red, to Red, to Red.. In other words,
    it just stays red!"
A: "Yup.. Good. Now you get it."


Q: "Where did you come up with this whole idea?"
A: "I didn't. The idea has been floating around for years, in one form or
   another, with different intended uses..I just sat down and thought
   about it at length, and added my $0.02 to the refinement process. At
   first, we thought we were the first (within InSight) to come up with
   the idea, but some later digging revealed that our idea turned out to
   be a slight variation of two or three separate ideas that different
   people have had over the past 10 years or so. In our case, the idea was
   inspired by a Taco Bell color-changing Dennis Rodman cup. You could
   make his hair color change to different colors depending upon the
   temperature of the drink you had in it. :) And so, color-reactiveness
   was born."


Q: "Where should I go if I still have questions?"
A: "Address them here, on the mailing list, publically, or via email.
    since this document is invariably going to attract the opinions of
    a few idiots, its always wise to stick with the original source of the
    information. Always refer to this (the original) document, and
    read it carefully -- There are many things here which are worded
    very, very carefully. If you still have questions, go ahead and
    ask, but be weary of the answers you get from people who don't have
    a full grasp of this concept..and there will be many. And as always,
    feel free to e-mail me. My address is listed below."


[ VI. Conclusion ]

I propose that the Gnome desktop not only -feature- this design innovation,
but figure it prominently in the general layout of each window as per the
reccomendations listed above, and shown in the appendices. Lets go for it!
Its a simple concept to understand, a simple concept to implement, and
its function ultimately justifies its inclusion. Its as simple as that.


							Bowie J. Poag
						        
---


Questions or comments?

Bowie J. Poag - bjp@primenet.com     University of Arizona, Comp. Sci.
ex-InSight Core Development          Tucson, Arizona.
Tel: (520)/327-5259