SqueakMap Package Loader UI
water at tunes.org
Thu Nov 23 21:58:04 UTC 2006
On Nov 22, 2006, at 5:44 PM, Chris Muller wrote:
>> Comments? Suggestions? Rants?
> I like the search bar, although if the search button and filter
> field were to switch places, the flow from left-to-right would feel
> more natural. Besides the input, the entry field should also
> output the current search term (i.e., don't erase the last-used term).
> However, I think the command buttons across the top are a step in
> the wrong direction. Right-clicking is as important as left-
> clicking, not just in Squeak but in mainstream Windows too. No one
> will get very far unless they know, "left click select, right click
Unfortunately, I have been wrestling with ToolBuilder and Morphic
mostly, and can't get this far ideologically with the interface. So
I'm sticking with the button-bar for now on the grounds that it's an
> Squeak should give newbies a simple, consistent interface and just
> a little training. By "simple consistent" I mean showing just the
> objects and then emphatically delineate the concept of "sending a
> message" by consistently letting the context menus represent a
> "message sending" mechanism. Make Squeak "objects all the way up"
> so the mindset will be consistent when we dive through objects "all
> the way down".
I think we need to make it *easy* to produce simple, consistent,
object-oriented interfaces in a single way that can be documented and
moved-forward as a community. ToolBuilder is the closest to doing
that, and it needs work.
Writing apps in Morphic is *hard* - granted, not as hard as some C++
or Java frameworks, but that's not much of a comparison. It's easier
to write a Seaside app than a Morphic app. We're a small community
and need to have a scenario where a single casual Squeak hacker can
crank out an interface in an afternoon. If we hand them a framework
that lets them do that and the user gets simplicity and consistency
and OO-ness for free, all the better.
> So many interfaces today are focused on showing every single thing
> the user can click; for example, laden with long scrolling lists or
> drop-down lists. Their usability is not scalable, and poor because
> they have the user _laboring_ with the computer to find something
> instead of vice-versa.
> With scrolling lists we display every object in the list, now we
> want to add all possible command buttons for all possible object
> selections showing too. Ok, not all commands, just few enough that
> we only *quadruple* the number of widgets the user is initially
> confronted with. So in the end, the user still has to know to
> right-click, so this change hasn't really solved the original
> usability issue.
> I prefer to present a simple, consistent, usable, well-executed,
> object-oriented interface. Do so proudly, not apologetically, so
> that, along with some friendly, basic documentation right in the
> start-up image explaining how things work, we build appreciation
> not resentment for the differences.
Yeah, I agree in principle, but right now that's too much work to do
for any single Squeak app, so I'm going to make the one I've got a
handle on a little better, and think about amp'ing up ToolBuilder
next so that it can do this for the developer.
Let's face it - *none* of Squeak's contextual menus or interfaces are
laid out with any sense of usability. If it's easier in Squeak to
make a window with three unlabeled rectangle panes with menus that
just shove every control protocol into a list and call that an
interface to an application, then it doesn't matter what principles
we exhort, the developer who's squeezed for time (IOW all of us)
isn't going to make a better interface.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061123/fd9dcb0f/PGP.pgp
More information about the Squeak-dev