Matthew Denis Richard Sloly wrote:
Doug,
Re: " . . . the UI look (such as the SystemWindows) has improved modestly from 2.8 to 3.0 to 3.2, if you've been following. Squeak 2.8 started up in the ancient MVC interface, which is a direct descendent of the original Xerox PARC overlapping windows UI of the 70's, since you mentioned interest in GUI history."
Sorry to say, I am new to Squeak, so have not been following that long. Do you by any chance have documentation/screenshots of these versions of Squeak?
The Screenshots page on the Swiki has some pictures, see http://minnow.cc.gatech.edu/squeak/683 . (Specifically, the "Morphic" screenshot near the top is a (crowded) screenshot of 3.0, and the "MVC" screenshot is what 2.8 and earlier versions looked like when starting up.)
However, in the current version of Squeak (3.0 or 3.2), the older MVC interface is still available, it's just not the default. (Morphic is the default now.) To try it MVC, select "open..." from the World Menu in Squeak, and then "mvc project" from the submenu. Then click on the newly opened ("Unnamed") project window to enter MVC. Then try opening some windows, etc.
Also, this is a long shot, but how hard would it be to simulate/emulate the original "Xerox PARC overlapping windows UI of the 70's", as well as applications that would have been typical to it? From a marketing perspective, I think Squeak would benefit greatly from a more explicit relationship to its roots in Xerox PARC.
It would be pretty easy to emulate, since the current MVC UI isn't too drastically different than the original Smalltalk-80 UI. They even share some of the same code base. (exactly how much is hard to say) If you look at old screenshots of Smalltalk-80 at Xerox, or in the Smalltalk-80 books, it doesn't look too much different than the current MVC UI. They share the same funky scrollbars, etc. A few things would need to be changed back such as window titlebars, in order to look just like Smalltalk-80.
In regard to the fonts, I figured that inertia was the reason for the longevity of New York, and appreciate that fonts are not the highest priority in terms of development. However, interface policy (though I realize that this may be an overly conservative notion) is an issue if Squeak is going to be marketed beyond the programming community. This is something that its present community (of mostly programmers) needs to consider carefully. Is this what you want, and if so what is the timeframe and/or milestones by which you wish to achieve this goal?
I think this is important to at least part of the Squeak community. I don't think it's been a goal of Squeak Central, but perhaps with the newly forming Squeak Foundation, it will receive some attention. There's no "timeframe and/or milestones" yet, though. :)
Of course before form must come function, and design decisions must be made in the context of applications. I would suggest the following: a word processor and/or desktop publishing (in this case integrated with all word processing tasks, as a framework for creating a full office application suite, which would include HTML and email editing), Photoshop/gimp type image manipulation and typesetting toolset. I am not sure how you would segment and prioritize the development of these applications but I think that they would be basic to general purpose work environment, and would be a means by which to start doing the design work within Squeak, starting into motion a feedback process between programmers and users of a real-world (testbed) applications. In the interim, to make migration to Squeak easier, it would be good to have a conversion path for graphics, as well as all major file formats (text, audio, and visual), as well as an SDK to encourage such migrations.
Some applications may be more appropriate to Squeak than others. For example, I wouldn't be surprised if no one ever creates a full-fledged word processor for Squeak, although it certainly could happen. (Squeak is not necessarily an operating system, so it doesn't have to be a general purpose work environment for everything.) Some of those other apps might make sense, though. (and could be used as a usability testbed)
Anyway, this is all pie-in-the-sky speculation on my part. As I said before, I am relatively new to Squeak, and I am not a programmer. My perspective on Squeak is more limited to applications, so all of the above must be mitigated by the bigger picture programming paradigm for Squeak, which would be up to you guys.
Is there a way to keep Squeak flexible enough for experimentation while providing a consistent UI policy where needed/desired?
I think so. :)
- Doug Way dway@riskmetrics.com