[UI] UI First Discussions - For The Record
Brad Fuller
bradallenfuller at yahoo.com
Fri Aug 24 22:45:42 UTC 2007
All,
WELCOME Everyone!
Ok, I'd like to start off by saying thanks to those who previously volunteered
their time to help us make a more consistent, modern, and most important,
useful user interface for Squeak. Now, all we need to do is figure out what
to do ;-)
I want to first bring everyone up-to-date on the email that has crossed our
desks that didn't make the archive of this mailing list. I'll try to provide
a condensed, but accurate representation, but if I err, please reply and set
the record straight.
I request that you do not reply to this email, but start a new email thread
on the particular topic that is of interest to you. That way, we can easily
search the archives later.
I first sent a message to those who replied to my squeak-dev email regarding
the UI. Here it is:
+++++++++++++++++++++++++++
HI All,
Just putting this out there to see if there is interest in starting a UI team
for Squeak. Each of you have commented on Bill's email outlining some of the
shortcomings of the interface. I would be glad to organize the group and get
it running. I have some ideas, and I'm sure you have plenty. Before that,
just wanted to know if you are interested and could devote time to the
endeavour.
cheers,
brad
if you know others that would like to contribute, please let me know.
------------------------------------------------------
+++++++++++++++++++++++++++
There were several replies that wanted to help, and in various ways. Some to
code, financial support, test, and just review and comment on discussions. We
need help in any way you feel you can contribute.
The ones who originally wanted to contribute were (and I'm not holding you to
it!):
Jan Hussaarts
Jason Johnson
Herbert König
Douglas Rollwitz
Bill Schwab
Andreas Wacknitz
Brad Fuller
------------------------------------------------------
+++++++++++++++++++++++++++
Here are the messages in condensed format:
===
Hi Brad,
Are you working on a new UI for morphic?
If that’s the case or even partially so, why not host
your topic on the morphic list?
It could use the traffic, and eventually the UI stuff
will overlap or conflict with the morphic stuff
anyway. Might just as well deal with it as a morphic
issue.
And I am interested in seeing progress made and issues
defined.
Yours in curiosity and service, --Jerome Peace
---
===
I thought about that. But, I feel that user interface issues go beyond
morphic. There is also MVC (don't know who uses it today, though) and native
hooks such as wxSqueak. My first suggestion to the group was to decide on UI
heuristics or guidelines that applications would follow to help make Squeak
more consistent for the user. Some agreed, some didn't say anything.
In any case, that's why I think it's a separate team. But, if others feel it
is not, I'd like to hear their thoughts.
brad
---
===
Actually I don't have a clear idea on what to really do, I strongly
advocate for KISS!
Imho we should set up another mailing list and inform Juan (Morphic 3)
Noury (easy Morphic GUI), the Ffenestri people and the "Friends of
Morphic". They need not donate time but I think they might have
valuable opinions and experiences and hopefully an interest in the
matter.
And we should take this to SqueakDev.
Let's gather some ideas, find out who is happy with the ideas and
after that see who can commit time into it.
Cheers,
Herbert
---
===
Hi Brad and all,
I don't know how to contribute to a UI team. Nevertheless I can
spontaneously express what I miss on Squeak's UI:
standard widgets. With standard widgets I mean both, standard looking
and standard behaving widgets.
There have been various attempts to resolve the lack of them. Alas all
of them are either unfinished or abandoned.
So, IMO the purpose of a UI team would be to create or harvest these
standard widgets and maintain them in the future.
Regards
Andreas
---
===
Theming implies a lot of refactoring
that needed to happen. Of course, my primary concerns are feel more
than look. But anyone who can work around the system well enough to do
that type of cleanup is someone we should "hire" (or perhaps offer our
services as helpers<g>).
Bill
---
===
I want typical input cursor movement and I know my
users expect it[*], but some Squeakers really like mouse-over
activation. Hopefully we can leave that option in place for those who
want it.
As I said before, count me in, and thanks!!
Bill
[*] well, they would complain mightily if the cursor did not move as
they have learned to expect. "I pushed the mouse out of the way so I
could see, and it started typing over there - fix it." I could go on
like this.
---
===
I'll put this idea out there: what if we started with no code, but UI
guidelines, consistng of both Look and Feel. For instance:
* all menus should take maximum of 8ms to return to the user with the
full menu presented
* File dialogs should look and feel consistent. Here are the rules:
<etc.>
* User's input focus must be consistent. It should not follow mouse but
at the last place mouse pointer selected.
* The World Menu must only consist of: ....
* Critical System Errors should present ....
* Errors are broken into the following classifications: Critical System
Errors, System Errors..., etc.
Ok, they aren't worded so well (because I'm just thinking as I write)
and these may be way off. But, you get the picture. Something simple, clear
and easy to implement.
It takes a lot of thought and experiementation to produce these rules.
But, there are already plenty of Squeak UI precedences set (where maybe we
just gather them by observation and provide the rules as "The State of
Today")
There are also plenty of UI precedence in general in the world - some
horrible some useful. Jef Raskin's Humane Interface, Usability
Heuristics, and even my favorite Donald Norman's "The Design of Everyday
things" andhis Neilsen Norman group.
What do you think? It would provide a framework for all else to follow.
Maybe if we produce successful heuristics, we could begin implementing in the
current squeak (or 3.10) image.
brad
---
===
What you call guidelines sounds much more like requirements. After an initial
requirements engineering there should be some modeling / architecturing. But
somewhere in time there need to be real coding. And I think a new UI with all
of its consequences will need a LOT of it. So I suggest to join forces and,
as I have written before, let's have a look what has already been done.
Regards
Andreas
---
===
> What you call guidelines sounds much more like requirements. After an
> initial requirements engineering there should be some modeling /
> architecturing. But somewhere in time there need to be real coding.
Sure. But, guidelines provide general policies for requirements or for a plan
of action. My suggestion is that we provide these guildelines first before
setting down hard requirements for whatever the team is going to provide. The
UI Guidelines provide a foundation to build all the UI projects that we may
come up with. If we don't have them, each UI widget/product/application would
conform to its own rules. Then, we would be back to where we started and
complained about: an inconsistent Squeak.
brad
---
==
> * User's input focus must be consistent. It should not follow mouse but at
the
> last place mouse pointer selected.
This one is controversial, a lot of people love the old Motif "follow
the mouse style". The best would be to make it configurable imo.
Jason
---
===
> This one is controversial, a lot of people love the old Motif "follow
> the mouse style". The best would be to make it configurable imo.
well.. it was only an example. The real suggestion is coming up with UI rules.
brad
---
===
The recent skinning effort would be a great place to start coding wise.
It should at least be evaluated; if we think it's junk, ok, otherwise,
we should team up to not waste effort. Beyond not losing an
opportunity, I agree that documenting what we want to change is a useful
start. That can be done on a wiki or a mailing list.
Bill
---
===
That's a great idea. we could start by putting up a page on the
wiki.squeak.org site, unless there's a better idea.
brad
---
===
I did a quick search on the wiki and found the following relative links. Do
you know of any work which has been started for Squeak UI?
UIIdeas
http://wiki.squeak.org/squeak/5819
The Squeak User Interface
http://wiki.squeak.org/squeak/5808
Squeak User Interface
http://wiki.squeak.org/squeak/1923
The Humane Interface
http://wiki.squeak.org/squeak/3026
Customizing the Squeak UI
http://wiki.squeak.org/squeak/1008
Omnniuser
http://wiki.squeak.org/squeak/5742
Programming in Morphic
http://wiki.squeak.org/squeak/5802
Skins Importer
http://wiki.squeak.org/squeak/1797
Zurgle Paper
http://wiki.squeak.org/squeak/2949
Fonts
http://wiki.squeak.org/squeak/696
MVC
http://wiki.squeak.org/squeak/1767
Forms, Views, and Windows
http://wiki.squeak.org/squeak/69
Eye Candy
http://wiki.squeak.org/squeak/1301
BitBlt
http://wiki.squeak.org/squeak/189
Morphic for Dummies
http://wiki.squeak.org/squeak/1870
Fun with the Morphic Graphics System I
http://static.squeak.org/tutorials/morphic-tutorial-1.html
Morphic Animation II
http://wiki.squeak.org/squeak/1262
Morphic Animation III
http://wiki.squeak.org/squeak/1264
what's the right tool for text file templates?
http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-November/098364.html
brad
---
===
I looked at the Wessels skin importer, but it was "just
Squeak with skins" and any time a debugger opened, it would revert to
the default look. No doubt that was to avoid meltdowns, but since the
debugger is our friend, it meant that the skins were pretty much useless
for development.
The more recent skinning effort, at least by screenshots and bullet
points, adds some more substantial widgets. It is worth a look, and we
might form a useful alliance. As a group, we might stand a better
chance of getting the results into wide use. Either skinning system
will modify a lot of Morphic, which gives us a place to hang the feel
changes.
Another suggestion would be to invite Rob Gayvert to join us. I would
never suggest that a good look and feel requires native widgets, but
they might add some discipline/structure that could be useful.
Bill
---
===
Won't it be more performant with BltBlt or OpenGL? What would stop us
from duplicating the native widget look inside the BltBlt/OpenGL? Too
much work? Some kind of licensing thing?
Obviously it makes keeping up with the OS'es much easier if we use
native widgets, but I don't think looking a little different is a
problem. After all, Java apps are starting to pick up a bit in my
circle of the word and they don't look so native.
The main thing I see is that the Squeak absolutely must have a way of
opening more then one window. After that though I think BltBlt/OpenGL
could be good.
The reason I suggest OpenGL or BitBlt is simply because it's faster.
It was discussed on a thread on squeak-dev some time back. I believe
it was Bill who pointed out that trying to map Window's own message
sending mechanisms back into objects is tricky and hard to make it
fast. With a more direct rendering it maps much better and runs quite
a bit faster.
I know we all say not to worry about speed but someone has to or your
stuff will simply be ignored.
I believe what Bill suggested earlier that the look itself isn't so
important as how the application responds. It needs to feel
consistent and responsive.
Jason
---
===
Jason,
I am not so much thinking about performance as wondering whether there
might be benefits to surrendering the feel to wx or another library.
One can always do things like Morphic to get better scaling to large
numbers of widgets, so I am not looking at it as using native widgets to
exclusion of emulation. Right now, we have emulation to the exclusion
of native widgets. Recently, I began to wonder whether striking a
balance might force us to get the feel right??? By feel here, I mean
the more basic focus and mouse gesture responses.
Bill
---
===
All,
The main goal of our effort should be to enable / facilitate the building of
applications with a look and feel that adopts the look and feel of the OS
that Squeak is running on.
I do not think OpenGL or BitBlt will help very much.
Perhaps it is better to stick to browser-based screens or build wrappers for
the use of OS-api's.
For me the look is very important. I develop for windows environments and IMHO
the looks of the applications must reflect the general looks of the hosting
environment.
Consistency and responsiveness are prerequisites (that will partially be
covered by the application logic).
The look of Gary Chambers effort (see mail from Andreas) seems to be ok..
Is there any info on the progress? If such an interface (or an interface like
Zurgle) are easy made using OpenGL, then we could use OpenGL.
Perhaps GTK is also an alternative.
Jan
---
===
To adopt the look and feel of the host OS is most likely easier done if there
is a hook into the guts of the host OS and not to duplicate the look in
Squeak. If so, then image portability is severly hindered because of the need
to develop the hooks necessary for the platforms. IMO, one of the top
requirements of Squeak, itself, is portability.
brad
---
===
Support of themes could be an option.
I remember that people are working on modularisation of Squeak.
Another possibility would be the implementation of a OS dependent UI module.
We would then have to take care that there is a common interface, i.e. there
would be no difference between linux and windows.
For me personally image portability is not important.
You think it is possible to use dotnet for the UI? Then we would cover Linux
(via Mono) and Windows.
Jan
---
===
Jan,
Native widgets are certain a way to achieve platform-specific behavior.
One might argue it is the natural way to achieve it. It is not the only
way - one can always emulate.
That said, I am starting to warm up to the idea of bringing native
widows up into the Squeak GUI, if only to force a refactoring of the
input handling.
Whatever you guys want to do to make the interface better is fine by me.
Bill
---
===
Jason,
Guilty as charged :) And I have not changed my mind. Right now, we
have a single native window with emulation therein. Squeak should be
able to use native widgets to a greater extent, and if we reach a point
that allows us to build platform native interfaces, that's great.
However, there will always be a time when realizing that the interface
is just a dynamic picture with a cursor and caret running around will
lead to dramatically better performance than would result from insisting
on rendering everything using a library that expects to put a few
widgets on a dialog box. Imagine using native widgets to render the
cells of a spreadsheet vs. doing it bitblt - no contest IMHO.
We need both, allowing developers to pick the best solution for their
task.
Bill
---
===
> Jason,
>
> Imagine using native widgets to render the
> cells of a spreadsheet vs. doing it bitblt - no contest IMHO.
You have much more experience with GUI's then I, I'm sure, which would win?
> We need both, allowing developers to pick the best solution for their
> task.
>
> Bill
I agree, you have my vote. :)
Jason
---
===
Bill and Jan,
I have mixed feelings when it comes to native widgets.One of Squeak's
strengths is its portability. The more externals Squeak depends on, the more
difficult it will be to do Squeak ports to a new platform (and maintain the
existing).You were talking about Linux. But Linux is just a kernel and not an
operating system. There are countless Linux distributions. Each of it may have
its own versions and hence versions of libraries like GTK or wxWindows. So
you will likely get a new kind of dependency and versioning hell.
I once was a Linux fan (RedHat, Debian and some other distributions).
But then I realized that I was always hunting for new versions and proper
libraries. So I stopped using Linux and now I am using Solaris as Sun does
not release new versions twice a year, breaking compatibility.
And, of course, there is only one Solaris and thus no risk of confusion.
Nevertheless I probably will support OpenGL as it is standardized. But
then we will have to define the version of OpenGL to be used.
Andreas
===
Image portability is important to me. My interest in Squeak (and some
other Smalltalks) is to get off of Windows and more recently to have an
alternative in case Dolphin really does go away. I will long need to
run on Windows, so a cross-platform tool is critical.
I am open to a cleaned/themed Morphic with feel options and fixes, and
increasingly to native widgets. I have no reverence for native widgets,
having long ago realized that they are fine in small numbers and
inefficient for large grids, etc. However, I am starting to think that
native widgets might be good for Squeak in that interfacing to them
might force some needed cleanup. Either way you guys want to go is fine
with me.
If we go native, or add native widgets as an option (perhaps the better
route), I would not start with .NET/Mono, but wx or GTK. Microsoft's
SOP is to kill everything they build, so I think we are better off
keeping them at arm's length.
Bill
---
More information about the UI
mailing list