Fixing the look of squeak in 3.9.

Tim Rowledge tim at rowledge.org
Sun Jun 19 00:21:42 UTC 2005


Raymond Asselin <raymondasselin at sympatico.ca> wrote:

> Le 2005/06/18, Josh Gargus <schwa at fastmail.us> écrivait :
> 
> >
> >On Jun 18, 2005, at 4:21 AM, Chris Schreiner wrote:
> >
> >> This LookEnhancement; what a pleasant changeset :-)
> >
> >I agree; it looks great.  Can anyone with a slow computer (Tim? :-) )  
> 
> Josh,  I don't know why :)  but I found this one...a good one !

Hey! No fair! Just because I use an unusual machine. Of course, it _does_ make
me utterly immune to windows targetted viruses. And as OSX becomes more popular
I'm sure blackhats will start to target them too and I'll be immune to them.
There hasn't been a virus to affect RISC OS in, ooh, seven or eight years maybe.

Yes, the price I pay is a machine that is significantly slower than the latest
wintel lump but honestly, the RISC UI is so much less horrible than windows
that it is almost completely worth it. OSX is certainly nicer than windows but
I still find RISC OS more usable.

Now, as for look and feel stuff for Squeak, the suggested LookEnhancments-jrp.
12 is quite reasonable as a small but definite improvement. I certainly prefer
the black text on white background.  A lot of the following commentary is not
specifically the 'fault' of the suggested improvements, so please don't think
I'm blaming Ben & John.

The window frame is ok in general.

I'm not convinced by the very flat appearance of the frame buttons,
particularly not by the ugly grey circle that appears when you press them. I'd
also point out that the 'collapse circle' is really ugly; a decently anti-
aliased one ought to be easy to cache. In general something supposed to be a
button ought to have some visual separation from its background. It should have
a clearly different but related appearance while it is pushed.

The inner frames are too thick in my opinion and rather intrusive. I'd say make
them thinner and mark the divider-mover part with a dark line rather than
making the whole thing thick enough to fit a dot inside. There is an old and
very annoying problem with the divider stuff in that the cursor changes and
seems to jam up the UI - an artifact of uncompleted event driven changes I
suspect. I suggest the divider should have movability only in a marked place
(the centre, normally) and not along its entire length. I'll note in passing
that morphic produces divider behaviour at the top of the 'instance|?|class'
buttons as well even though no visual divider exists. Nasty.

Window resizing handles - nicer than assumed ones all over the place. More
clear difference to the divider handles would be good. The performance when
resizing is appalling on my machine, suggesting some optimisation would be
beneficial. One UI facility I find useful on RISC OS when risiezing is that if
you drag the resize handles to/past the edge of the screen, the topleft moves
up & left so the window can grow.

Window moving. Morphic seems to assume that if you grab something in a place
that does nothing else you obviously want to move it. I really hate that for
windows. Especially since there seem to be small but too-easily touchable
places in every window.

Roundedcorners. Yuck. So utterly passe and kindergarten-winXP.

Buttons in the system browser look so vague that it's hard not to see them as
inactive. Rounded corner buttons in a line like that look awful. Some ofthem
perform an action that will open another window (browse etc) some open a menu
(inst vars etc) and the 'source' button seems to have a square shape and opens
another kind of menu. In general, the typical buttons in morphic fail miserably
at providing any feedback about what is happening. A good example is in
Monticello, where the only clue you have that some long running process is
active is that the faint outline of a button is barely visibly different. Two
things should be changed to improve this, first the different button states
need to be more discernable, and secondly some stronger feedback for long
running activities would help. As an example, perhaps having a timer that
starts when a button is pressed and when the action is still going after (say)
0.3secs there is visual feedback. We could be simpleminded and change the
cursor but perhaps changing the button to add an eggtimer icon would be nicer.
It would keep working if theu ser moved the mouse outside the Squeak window for
example. We already have a suitable timer machanism to activate help balloons.

Let's see. What else can I ramble on about? Menus - yes, now there's a subject.
About 50 pages worth actually but let us try to be brief. Icons in menus are
fairly pointless. Working out what would be a good icon is difficult.
Displaying them simply wastes time in what should be one of the core 'optimised
till it bleeds' areas of the UI. (The other utterly crucial one is text
selection/display) Hierarchical menus would be a big improvement over those
silly ellipsis entries (see the world menu for example) at least if they are
presented quickly enough - a menu should appear within 50milliSeconds, not
after a second or so of laying out icons, shading, adding movies, sending the
item texts off to a webservice for translation and then burying in peat. One
nice facility in RISC OS menus is that selecting an item closes the menu but
right-click (what we call adjust-click) selects the item, triggers the action
BUT does not close the menu. The menu can be revised if the action requires it.
You can then select (or adjust) again. It's like sticky menus but temporary and
I think more useful for that.

I'm sure I can extend the critique if anybody is interested - and as I said
above, this is mostly not aimed at Ben & John but at the general state of the
Squeak UI.


tim
--
Tim Rowledge, tim at rowledge.org, http://www.rowledge.org/tim
Strange OpCodes: TOAC: Turn Off Air Conditioner



More information about the Squeak-dev mailing list