The people Coding standards Design Rewrite rule TODO DONE Sun Java
Javadocs Class Hierarchy Index NAWS MTRX security servlets Skang Squeal & Stuff zen developer
NAWS stands for Not A Widget Set, it will not be a widget set, it will be a single, generalised widget and a single generalized widget container.
The idea is roughly this -
NAWS should allow pixel perfect layout on any OS/JVM combination. This is very
important, it gives the GUI designers the freedom from differences that has been
sorely lacking on the web.
All widgets should be shaped, so that you can have two roundish widgets
snuggling up to each other. All widgets should be font sensitive, this could
break pixel perfection though. The shape should be definable by a mask graphic,
or a combination of graphics primitives.
Labels should be able to display multiline flowed text or a graphic, with the
graphic being a .png, .jpg, .gif (in that order of preference), and with
animation support. Labels should be able to be attached to all other widgets as
prompts. Labels should have automatic disabled graphics (ghosting) created and
the option of supplying one. So that a widgets prompt gets ghosted when the
widget gets ghosted, and to provide ghosting support for the other widget types.
Labels can have a different text / graphic for the mouse hover state. Label
graphics should naturally be paintable.
Borders are shaped outlines that can be put around anything. Not really a
widget, just a decoration. When using graphics, the border could be part of the
graphic, so no actual border is needed. Might be able to make Labels as
containers do the job of Borders.
Buttons are Labels that can be clicked. Alternate text / graphics for the
clicked state should be catered for. Radio buttons can be handled by widget
notification. Checkboxes are buttons that are sticky. The difference between
Checkboxes and toggled Buttons is purely cosmetic.
Icons are movable Buttons.
Text editing fields are Labels that allow the text to be edited. Masks and
validation should be built in.
Progress indicators are Labels with two graphics where the first graphic is
slowly revealed by chipping away at the second overlayed graphic. Default
graphics should be supplied.
Containers should be automatically scrollable if needed. Actually, Containers
could be just Labels that allow sub widgets, but I don't think I will go that
far B-). On second thoughts, I might.
All else is really just a Container with several of the basic widgets in them. A
List is just a collection of Buttons. A Menu is not very different from a List
with sub Lists. Choices are Lists where the selected item is usually all that is
shown. A ComboBox is a Choice with a Text at the top. Scroll bars are containers
with a movable Button in them. Spread sheets are grids with Label widgets in
them, but this is generalised, so any widget can go in a cell. The cell being
edited at the moment is a TextField. Tabbed panes are a row of Buttons that
select different skins for the pane. A Toolbar is a strip full of Buttons. A
Tooltip is a popup Label. Trees are a collapsible set of Buttons.
Since Skang does fine with just a Frame; Dialogs, Windows, etc are just a
container with various decorations / border widgets. Close, minimize, maximise,
etc are just Buttons. Resizing bars are just movable Buttons where the edge of
the container follows the Button. Split panes are a simialr thing. Title bars
are also similar, but the entire container follows the Button.
I think I have covered the basic widget types. More complicated things like file
and colour choosers are left as an exercise for the reader.
Except for the basic widget and container, the entire thing should take about as
many lines of code as there are lines of text just used to describe them B-). In
other words, I write a shaped, clickable, editable, movable, scrollable Label
that allows sub Labels, and has excelent graphics support, all else is just
convenience wrappers around the Label class.
The major advantages are that all widgets act the same, and the code is kept
small. I should be able to do better than Swing in a whole lot less than two
megabytes (the size of Swing). Since everything is generalized, weird things are
too easy to do. Wanna put a ComboBox in your TitleBar? ScollBars in your Menus?
Have a throbber that is a rotating Earth with clickable countries? All very easy
to do. Clicking on the Buttons of a rotating container could be hard for the
user though B-).
I have about a books worth of ideas on how to design user interfaces, both for
software and actual real world objects (sometimes refered to as hardware). I am
very good at UI design. I don't have time to write my book at the moment, but I
should point out how this affects NAWS. NAWS should have the ability to wrap
it's skins around a 3D object.
A simple example, the user is in a 3D space (VRML world for instance), and there
is a cube sitting in front of her with the NAWS version of matrix.skang running
on one side of the cube. She can walk up to the cube and start clicking on it.
She can pick up the cube, rotate it, walk around it, etc, and so long as she can
still see the widgets, she can still use them.
A complex example, the user (in her VRML world) is carrying around a mobile
phone object, which is your usual blobby mobile phone shape. Someone else sends
a Jabber message to the user, and a keyboard / monitor combination pops out of
the mobile blob and allows the user to have a Jabber conversation. The mobile
phone blob has widgets all over it for controlling the mobile phone functions.
Some of them are on opposite sides, and she needs to rotate it to get to them
all.
Then there is our throbber, which will morph into a network health indicator. It
could be displayed as a VRML sphere with country shaped widgets that you can
click on to zoom in on a particular country to see more details. It must still
rotate of course B-).
While I am on the subject of 3D, machines that can't handle the full 3D should have
fallback options, to an isometric view, then an overhead veiw. Even beafier machines
should degrade gracefully. We should have a target FPS, with each object informed of
how long it gets to render itself, and making decisions about complexity of rendering
based on that.
All windows are alpha blended together with, say a 50% transperancy. and solid colours
for the widgets of the current window. This should result in very dark or very light screens.
In the former, text is white, in the later, text is black. First mouse wheel moves you
up and down the stack of windows at the current mouse location. First mouse wheel pushed
(That is the middle button) and scrolled moves you up and down, but takes the current window
with you. Unless the current widget uses the mouse wheel or middle button off course. If using
Space Orbs, we have enough axis to go around. Up and down go up and down windows, twisting
scrolls things. Up and down aare good uses of buttons four and five on my mouse. Just allow
the user to map buttons as they see fit.
Have the transparency of windows between you and the current window increased
to say 75%. Make the two transparency levels adjustable, or have window transparency depend on
depth in the stack (four windows plus a desktop, desktop is 0%, deepest window is 20%, next is
40%, etc,).
Then we can have lot's of useful little animations in the windows, to provide a very dynamic
environment. Widgets can throb slowly, all at different rates. Anything needing attention
can flash quickly. Backgrounds can swirl, rotate, or scan slowly. On the desktop, you have
a system console with a background image, or "screen saver". The desktop can be the 3D world
you are in, the windows are floating in front of you, then you will need a two wheel mouse
AND a Space Orb.
Any "screen saver" can be a background, or a privacy screen (with password). Privacy screens
in the real world take over your monitor while you are away, requiring a password to go away,
which is how current screen savers work. In the 3D space, your windows are visible to others,
but only as the screen saver animation. Each window getting it's own privacy screen lets out
information about number, size, and relative position of windows, so we need an option to screen
the entire desktop. Indiviual windows, or the whole desktop, can just be invisible to others.
Default to privacy screens in a 3D world, and allow some ACTIVE method for users to share
windows. Active means that you can't leave yourself open accidently.
In the 3D space, we need a new name for the "desktop", cause we don't actually carry a desk with
us when we walk around. "Fogtop", "ClothesTop", "HUD", I'll think of something good sooner or later.
Got it! Wearable Information Device - WID. WIDs, containing windows, containing widgets! Or maybe
use "wedges" / "widges" for windows? So, with WIDs, Widges, Widgets, and 6 degrees of freedom, we
have a WWW6 (3W6 / 3w6 / Triple W 6 [ = 3 x 2 x u x 6 = 6u6 = 36u] ?) interface, instead of the
outdated WIMP interface. "WIDGE" = Wearable Information Device Gizmo Enclosure B-).
"WIDGET" = Wearable Information Device Gizmo, Enclosed Thing (I know, I'm getting desperate, but
it matches Thing.class in matrix-RAD, which Widget.class is a sub class of).
All this from a dream I had last night, possibly inspired by the new Amiga "Every window can be
transparent and shaped" stuff, which I have only seen a couple screen shots of. Gotta have a
good look at this new Amiga stuff now.
This file was last modified on Saturday, 30-Oct-2004 11:23:15 EST