I'd like to get your ideas on compiling a list of UI guidelines or heuristics that Squeak developers should follow. A few have mentioned they liked the idea, but I'd like to hear from the whole group. Is it a dumb idea or maybe a good one but tough to follow through? Too tough for our first go-round? (which I should mention now: I think we need to find a couple of "jobs" that we can accomplish fairly quickly to provide some success to the group.)
If you think it's a good idea, we could discuss one at a time and when we have a statement that we like, we could place it on the squeak wiki on a "Squeak UI Guidelines" page.
As I mentioned before, there are already plenty of Squeak UI precedences set and maybe we could start with those that have been successful. Most of the successful ones are ubiquitous and thus sometimes hard to see cuz we're so used to them, (for instance, the fact that you can edit what you see is a basic and powerful attribute of Squeak. No need to go to a special "editor" like a text editor or graphics editor to edit a morphic. )
We could also discuss ideas that others have had, such as Jef Raskin's Humane Interface, and if applicable bring them into our domain.
brad
I'd like to start with something complete and then talk about how Squeak differs and whether or not that difference is desirably Squeaky.
This page has a good start with which to compare:
http://en.wikipedia.org/wiki/Human_interface_guidelines
I'm (historically) partial to IBM CUA, but I know it isn't exactly sexy.
On 8/24/07, Brad Fuller bradallenfuller@yahoo.com wrote:
I'd like to get your ideas on compiling a list of UI guidelines or heuristics that Squeak developers should follow. A few have mentioned they liked the idea, but I'd like to hear from the whole group. Is it a dumb idea or maybe a good one but tough to follow through? Too tough for our first go-round? (which I should mention now: I think we need to find a couple of "jobs" that we can accomplish fairly quickly to provide some success to the group.)
If you think it's a good idea, we could discuss one at a time and when we have a statement that we like, we could place it on the squeak wiki on a "Squeak UI Guidelines" page.
As I mentioned before, there are already plenty of Squeak UI precedences set and maybe we could start with those that have been successful. Most of the successful ones are ubiquitous and thus sometimes hard to see cuz we're so used to them, (for instance, the fact that you can edit what you see is a basic and powerful attribute of Squeak. No need to go to a special "editor" like a text editor or graphics editor to edit a morphic. )
We could also discuss ideas that others have had, such as Jef Raskin's Humane Interface, and if applicable bring them into our domain.
brad _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
I noticed the wyoGuide is released under the wxWindows license, which is essentially LGPL and should make it a friendly base from which to fork. I presume a fork would be necessary as I doubt wxWindows is particularly Squeaky.
On 8/24/07, David Mitchell david.mitchell@gmail.com wrote:
I'd like to start with something complete and then talk about how Squeak differs and whether or not that difference is desirably Squeaky.
This page has a good start with which to compare:
http://en.wikipedia.org/wiki/Human_interface_guidelines
I'm (historically) partial to IBM CUA, but I know it isn't exactly sexy.
On 8/24/07, Brad Fuller bradallenfuller@yahoo.com wrote:
I'd like to get your ideas on compiling a list of UI guidelines or heuristics that Squeak developers should follow. A few have mentioned they liked the idea, but I'd like to hear from the whole group. Is it a dumb idea or maybe a good one but tough to follow through? Too tough for our first go-round? (which I should mention now: I think we need to find a couple of "jobs" that we can accomplish fairly quickly to provide some success to the group.)
If you think it's a good idea, we could discuss one at a time and when we have a statement that we like, we could place it on the squeak wiki on a "Squeak UI Guidelines" page.
As I mentioned before, there are already plenty of Squeak UI precedences set and maybe we could start with those that have been successful. Most of the successful ones are ubiquitous and thus sometimes hard to see cuz we're so used to them, (for instance, the fact that you can edit what you see is a basic and powerful attribute of Squeak. No need to go to a special "editor" like a text editor or graphics editor to edit a morphic. )
We could also discuss ideas that others have had, such as Jef Raskin's Humane Interface, and if applicable bring them into our domain.
brad _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
On Fri August 24 2007, David Mitchell wrote:
I noticed the wyoGuide is released under the wxWindows license, which is essentially LGPL and should make it a friendly base from which to fork. I presume a fork would be necessary as I doubt wxWindows is particularly Squeaky.
The very first issue I have with xyoGuide is it does not seem to focus on user interface issues, but on how things should look and should be. What I mean by that is, take Chapter 2 for instance. It starts out with a description and picture of an example application with the text:
"A frame layout usually has some standard elements like title bar, menu, optional toolbars, optional status bar, etc."
Pictures are great, but presuming that a user interface would usually consist of a menu bar, with a File Menu, Edit Menu, etc. is dangerous, and is how the HCI world got into the mess it's in.(Ok, they said "usually", so they are a bit off the hook)
So, in their case, BookMorph violates this very first premise. But, to me, BookMorph is a clean interface and serves the user very well.
On 24-Aug-07, at 5:40 PM, David Mitchell wrote:
I'm (historically) partial to IBM CUA, but I know it isn't exactly sexy.
As it happens I was one of the reviewers of the original CUA documents waaaaaay back. It was certainly comprehensive - in my opinion far too comprehensive. The problem I saw was that it came fairly close to the union of all the sets of UI flibbery that IBM knew about. But, almost anything was better than the mess that prevailed in those distant days. Even Windows looked good.
I do like most of Jef's Humane Interface ideas and we pretty much agreed to differ on the bits I didn't like. It would certainly make an interesting project to implement the principles for Squeak. The Apple guidelines are pretty good and certainly well documented.
Perhaps the key initial activity needed for a better Squeak UI is to try to understand what is there so it is possible to work out what widgets exist and what ones are needed. Does anyone know how many kinds of button there are? If we can build a catalogue of what is needed and list of what is there then we can make some kind of plan for 'fixing' things. After we have a decent base set of widgets (and of course the underpinnings to allow creation of others) then it is possible to work through them to make everything self-consistent.
Morphic is a reasonable implementation technology but many of the current widgets built with Morphic are nasty. It would be nice to see a better bottom layer (under morphic unless anyone wants to rewrite everything) that can take advantage of OS facilities for accelerated graphics; Sophie has been using a binding to the Cairo libraries for example. Tweak has many interesting points but the version Sophie has been using (and I have no idea how out of date it might be) has been the cause of much gnashing of teeth when trying to debug or work out wtf is happening when.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: LOW: Launch on Warning
On 8/25/07, tim Rowledge tim@rowledge.org wrote:
As it happens I was one of the reviewers of the original CUA documents waaaaaay back. It was certainly comprehensive - in my opinion far too comprehensive.
Isn't it always with IBM? :)
Morphic is a reasonable implementation technology but many of the current widgets built with Morphic are nasty. It would be nice to see a better bottom layer (under morphic unless anyone wants to rewrite everything) that can take advantage of OS facilities for accelerated graphics; Sophie has been using a binding to the Cairo libraries for example. Tweak has many interesting points but the version Sophie has been using (and I have no idea how out of date it might be) has been the cause of much gnashing of teeth when trying to debug or work out wtf is happening when.
tim
Yes, with my MVP suggestion I don't mean Morphic couldn't be used. In Dolphin (sorry to harp on it, but it's the best I've ever seen) the view part really feels like a black box, at least to me. I never understood how to create a new widget, and based on how some of the "goodies" widgets looked I don't know if there even was a clean way.
So if we had the mechanisms set up for the Model and Presenter objects to communicate to the View space then Morphic or anything else would work as the view.
Then we could have a tabbed "chooser" view for selecting Morphs for your GUI you're building. If you create a new Morph you can select what kind of Morph it is and it shows up in the GUI builder after that.
I think Tim's idea of cataloging what is there is good. And when we catagorize we would also need to look at implementations so we can document which ones are good to go, and which ones are good in concept only but need a rewrite.
On Fri August 24 2007, David Mitchell wrote:
I'd like to start with something complete and then talk about how Squeak differs and whether or not that difference is desirably Squeaky.
that could work. I just browsed the Apple doc, and it looks that it could provide some help. http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuid...
I also think we should not forget the ST-80 Orange book contributions and the work done by those before the Mac and Windows I/F was even thought of. There are some good fundamental ideas back in the day.
(My concern is that we don't start with the assumption that current I/F practices (e.g. MS Windows I/F, Mac I/F) are something that users want today and are the best way to design. I propose that we seriously challenge those assumptions for the betterment of Squeak.)
Thanks to Brad for starting the list...
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org] On Behalf Of Brad Fuller Sent: 25 August 2007 1:00 am To: ui@lists.squeakfoundation.org Subject: [UI] Squeak UI guidelines/heuristics
I'd like to get your ideas on compiling a list of UI guidelines or heuristics that Squeak developers should follow. A few have mentioned they liked the idea, but I'd like to hear from the whole group. Is it a dumb idea or maybe a good one but tough to follow through? Too tough for our first go-round? (which I should mention now: I think we need to find a couple of "jobs" that
we can accomplish fairly quickly to provide some success to the group.)
If you think it's a good idea, we could discuss one at a time and when we have a statement that we like, we could place it on the squeak wiki on a "Squeak UI Guidelines" page.
As I mentioned before, there are already plenty of Squeak UI precedences set
and maybe we could start with those that have been successful. Most of the successful ones are ubiquitous and thus sometimes hard to see cuz we're so used to them, (for instance, the fact that you can edit what you see is a basic and powerful attribute of Squeak. No need to go to a special "editor" like a text editor or graphics editor to edit a morphic. )
We could also discuss ideas that others have had, such as Jef Raskin's Humane Interface, and if applicable bring them into our domain.
brad _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
-
Brad Fuller -
David Mitchell -
Gary Chambers -
Jason Johnson -
tim Rowledge