[squeak-dev] Re: Impossible to grab the scroll bar in the Transcript if...

Chris Muller asqueaker at gmail.com
Tue Jun 7 17:29:07 UTC 2016

> after reading your response several times to look for some useful feedback,
> I think I actually found some. Here is what I found:

LOL!  Okay.  Thanks for understanding that I'm passionate about
proposals which I consider to erode the multi-windowing UI metaphor.

> 1. It is advisable to make suggestions about changes to Squeak without
> referring to systems were many people have mixed feelings about. A somewhat
> neutral and objective perspective is more likely to foster fruitful
> discussions.
> 2. Squeak's windows do have borders where the resize grips perfectly fit in
> without covering the window's contents or control buttons. There is no need
> to move the grips to the outside of the window.
> 3. From a user perspective, Squeak's resize grips have a visual
> representation, which is the window border itself.
> 4. The shadow of a window is not part of the window. A click into the shadow
> of a window means clicking next to it or behind it.
> While I totally agree with the points 1 and 2, I kind of disagree with 3 and
> 4. However, this is just my personal experience. I am not aware of any
> studies that confirm or refute these statements.
> Now, just for a moment, let's think about and discuss zero-border windows.
> Apple's Mac OS has been having them for a long time. Once, there was only
> the grip in the bottom right corner to resize a window. Nowadays, there are
> also grips for the edges. Tobias showed me that in a recent version and it
> seems that the edge grips partially overlap the window contents because
> there is no window border. They do, however, not really really into the
> window's shadow. Anyway, the grips do not have a visual representation other
> than the changing mouse cursor when hovering over them. Looking at the OS X
> Human Interface Guidelines, grips are only mentioned very briefly:
> https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/WindowAppearanceBehavior.html
> Microsoft's Windows 10 reduced window borders down to a single pixel. It
> looks like the window borders in Mac OS X. The grips, however, do not
> overlap with the window contents but reach into the window's drop shadow. In
> my daily experience, I had no troubles resizing windows via the grips.
> I have no real experience with Ubuntu/Linux (resp. Gnome, KDE, ...).

Ubuntu 14.04 default settings do the same thing Windows does -- make
resizing grips well beyond the outer edge of the window -- which is
incredibly annoying, because 1) it interferes with the content and/or
edges of adjacent windows, which I sometimes want to interact with (or
resize to be closely side-by-side), but can't because it keeps grabbing
the resizer of the window which I'm not even clicking because,
2) it has defied the physicality of the environment (this is what I
referred to as the "insanity"), and established a new paradigm to the
user that there are "invisible regions" on the screen which are
actually sensitive to input.

> Why was I writing about this? About a year ago, I refactored some magic
> numbers to make the border thickness of Squeak's windows configurable.
> Especially in the face of Hi-DPI, this should work to provide bigger borders
> in the sense of pixels to keep their effective size similar.

That sounds good..

> Then I thought:
> "Why does there have to be a border at all?" ... when it might be used for
> real content instead. But what about the window grips? If they would overlap
> the content, it would be somewhat annoying. Then I discovered the way
> Windows 10 does it, and I liked it.

Invisible grips are gonna overlap either to the inside or the outside
right?  Making the assumption that overlapping to the outside triggers
my sensitivity about this subject, because it assumes and encourages
that modal-thinking revolution.  IMO, we should stand strong against
that and show the world what Smalltalk showed them 33 years ago --
windows are visible and physical, and present an object-centric
interface (rather than command-centric) which, unlike tablet
interfaces, allows seamless integration of disparate domains.


More information about the Squeak-dev mailing list