[prev in list] [next in list] [prev in thread] [next in thread] 

List:       eros-arch
Subject:    [eros-arch] A new GUI system is an opportunity - some ideas.
From:       Eyal Lotem <gnupeaker () yahoo ! com>
Date:       2003-11-03 23:34:31
[Download RAW message or body]

A new desktop is a great opportunity to change things
for the better:	

(A) No strong arbitrary distinction between levels of
the graphic containment hierarchy (desktop vs. window
vs. widget/etc).  Instead, just as the user can mess
around with his windows on his desktops, he should be
able to build his own "windows" containing whatever
widgets from whatever programs.

(B) Completely separate program logic from the GUI
look, in the inspiration of the project formerly named
Berlin (http://www.berlin-consortium.org/).  This
should allow the user to use the same program code
from command-line, the GUI, and even expose a designer
to the user where he can build his own optimized
dialogs to control the same program logic.
Also note that the high-level data flow between the
program logic and the GUI would probably be the
preferred protocol point to travel on a network due to
low bandwidth use.
This should also have the side-effect of removing the
responsibility of keyboard operability from the
application, as well as many internationalization
benefits, etc.

-----
Note that points (A) and (B) effectively kill the
relationship between the GUI widget/window hierarchy
and the program logic, which communicates with the GUI
system via capabilities, having no idea how the GUI
displays its data.
In fact, I see no reason why the "physical layout" on
the GUI should be reflected by the capability model at
all.
-----

(C) Eliminate surprises/modal windows.  In most
current window systems, events are sent to the user in
the form of modal popups that must be acknowledged to
continue work.  
Not only that, but the surprising dialog box also
remaps the meaning of the keyboard keys, clickable
positions on the screen, etc.  I've hit "enter"
(yes/ok) on random questions and dialogs that popped
up many times.
A better alterantive could be an "event area" where
events are shortly described and "pulled" by the user
in his convinience, avoiding distraction.

(D) Overlapping windows:  It seems to me that one of
the most appearant features of windowing systems today
are user-controlled window coordinates, where windows
can overlap/partially hide each other.
From my experience, and also watching others, users do
not really ever overlap windows (on purpose).  Usually
users spend their time "tiling" the windows or just
maximize them all (and on *nix, maximize/tile in
separate desktops).
Modern GUI's of certain applications (Visual Studio,
multiple KDE applications) use the concept of "panes"
which are similar to Windows but do not overlap and
are tiled automatically - this seems to be far more
convinient.  Perhaps only panes should be used.

(E) Prioritizing screen-estate:  Note that new Window
Managers usually support a "smart" window placement. 
This uses a heuristic based on the idea that uncovered
desktop space is cheaper than covered desktop space,
and allocates windows on uncovered desktop space.   It
stops working well once all of the desktop is covered.
My suggestion would be allowing applications to
prioritize their data such that screenestate showing
data is valued more than screenestate not showing data
(as for important vs. unimportant data).  This would
allow hiding less important data when no more
screenestate is available.
If for example, a "pane" grows, or a new pane is
created (by a user or an external event), it would be
preferrable if the text currently in focus/being read
was not hidden/obscured.
Ofcourse "important" is subjective and therefore the
user can be involved in the selection of "important"
data, or importance-determination policies, rather
than the user tediously moving, resizing and scrolling
his windows.

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/
_______________________________________________
eros-arch mailing list
eros-arch@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/eros-arch
[prev in list] [next in list] [prev in thread] [next in thread]