I don't intend to be rude to you, so please don't take any of this personally; unless you are of the people that implemented any of the 'popular' commercial UIs, in which case - "Thhhhhhhpurb" (attempted web-rasberry)

Why bother creating yet another look and feel when we all use and are experienced with what comes with our native operating systems?

Maybe because all of them are absolute junk. Windows is apalling, Mac is cretinous, Gnome & KDE make windows almost look good, Acorn is ridiculous. I just about tolerate Acorn because I'm so used (innured?) to it, but really guys, they're all just pathetic.

1. Allow the use of native windows and widgets through an interface

that means you can write code that will work across most of the deployed platforms with the look and feel of those platforms.

This is just about doable. Portability in this is really difficult; I worked on a big project attacking it at ParcPlace. It shewed promise, but involved major work in FFI, callbacks, fixing bugs in the native widgets themselves. A mojor pain. During the work, we noticed that hardly any major applications actually used the native widgets anyway. M$ were particularly prone to this. There was a pretty damn good paper on this in the OOPSLA 95(?) proceedings.

2. Develop a completely new and different user interface/experience

that will be wicked and weird and beautiful and, generally, make people's jaws drop.

I think that's what many of us are working on.

Perhaps both could be done, but it seems to me to be a waste of time to write code to make Squeak look like another operating system.

Web browsing presents a quite different UI to most OSs, and offers at least a chance that we can force open the door to something better. One of the things I particularly dislike about all the .NET BS is the transparent attempt by M$ to make the web look like windows. Yuck.

I was trying to put forward the following:

Proposition: Either do something radically different from current user interfaces or use those interfaces.

It would be helpful to provide arguments in support of that proposition, rather than merely to state it, and then to aver once more that the proposition should be applied in the case of Squeak.

There is a fundamental difference between Squeak and Java, Python/TkInter and Tk/Tcl: Squeak delivers on the promise of "write-once, run everywhere."

Its execution is pixel-for-pixel identical cross platforms. This is, IMHO, a good thing -- indeed a very good thing. Having worked in the gaming business, where the costs of ports in multimedia games are ENORMOUS, I am awed by the ease this can be accomplished in Squeak.

As most regular readers are by now tired of hearing, I wrote my wife's Birthday present some years ago in Squeak on an Office PC: a multi-media game with music and sound. I downloaded it the day before onto her iMac (yeah, I tried it a few times with earlier versions in truth, just to be sure -- but it doesn't make for such a great story), and it ran pixel-and-sound-identically without change.

This is scary cool. It is a wonderful thing. And it owes much to some of the fundamental design principles of eschewing design principles at every opportunity. Almost everything is written in Smalltalk -- and thus almost everything works almost everywhere.

Using native windows -- even abstracting so that similar paradigms cross-platform can be used, cost Tkinter and Java dearly in terms of real write-once-run-everywhereness.

Of course, there are other arguments that may lead one to prefer native widgets. At the end of the day, I suppose, in the end, it depends why you are using the system. Thus, the axioms leading you to your conclusion should begin there -- rather than with the ipse dixit conclusion that native widgets should be supported.

At 4:44 PM +1000 7/2/00, Karl Goiser wrote:

G'Day,

I'm sorry. I just feel so stupid at not being able to get my point of view across.

My argument is not that Squeak shouldn't be identical across all platforms. It should - that's what I'm saying!

*snip*

So, if people *must* have native widgets in Squeak, surely the best thing to do would be to abstract them as far as possible via some api so that the same code would work on other platforms?

I'm not suggesting that the code should be identical across platforms. I'm suggesting something far deeper -- that the execution of the code should appear identical across platforms. For many applications, a general transliteration, if you will, of a least-common-denominator GUI model, is probably a good thing. For the stuff I deal with (multimedia and games), that doesn't cut it. Until you can assure me things will look the same regardless of the machine I am running, I continue to have to "port" the application from format to format to make up for the nuances lost by the LCD GUI model.

Unfortunately, the devil in user interfaces is precisely the nuances. Consider Jef Raskin's remarks in this regard from his book, The Humane Interface. When you simplify the model, you simplify what I can do with that model. Sure, the broad strokes cross over. For my purposes, however, that will not be enough, and I must write the strict details once for every platform on which it runs.

Just like in Java Just like in Tk/Tcl Just like in Python/Tkinter

Its not awful (how can so many successful languages be wrong)? Its just not "write once/run everywhere."

Squeak is.

While I actually prefer cross-platform over native widgets I also hate the waste of development time to recreate working solutions, to reinvent the wheel.

You can spend enough development time to recreate what you could get by simply embedding for example the internet explorer as a widget in Windows applications. Or on Linux, by using the qhtml widget or their rich text editor or whatevever.

Agreed that having to roll-you-own GUI solutions to recurring problems, such as displying lists of information for selection, binary options, chose-from-various options, and the like, is wasteful; provided, however, that there is agreement as to a "best way" to accomplish same. For example, if we believe that the "standard widget set" is the ideal for these interactions, by all means it is useful to implement them in Squeak.

I still consider the question quite open, however, as to how best to present the user with various controls and alternatives -- and acknowledge that the "standard widget set" may well be inadequate in comparison to some novel solutions. Accordingly, if your specification REQUIRES a "standard widget," by all means build one and share the same.

In the meanwhile, I am open to the possibility that pink plane Squeakers may well find another, perhaps a better, way.

And that's just the end product. Even if we assumed that the end-user-look-and-feel were completely specified, there still remains substantial dissent among designers as to how to present access to that core "API," whatever it is.

So many tools, so little time. I don't know what is the best way, but surely there is a better way than merely to duplicate or approximate existing tools to make existing GUIs.

That being said, I agree with Mr. Aust that a solid-looking widget set that is easy to use may well be a real-nice-thing-to-have. I have offered some MVC widgets and look forward to others to find a way.

On Mon, 3 Jul 2000 12:50:54 +1000, Karl Goiser squeak@wattle.net wrote:

Specifically: have a method that can be called which will display an html page with form data and return the contents of the fields...

The web browser I am porting & working on supports forms...

Later, Jon

-------------------------------------------------------------- Jon Hylands Jon@huv.com http://www.huv.com/jon

Project: Micro Seeker (Micro Autonomous Underwater Vehicle) http://www.huv.com

IMHO, feel is more important than look.

Squeak not only looks different, but it feels different. From my experience, people would actually accept a different look - at least if it looks professional (read boring or elegant). Squeak's colorful windows will perhaps irritate a business customer, but a more uniform look (flat or 3D doesn't really matter) is okay.

However, popping menu bars, popup menus, missing menu bars, the way keyboard selection works, strange (from the viewpoint of Windows or Unix) keyboard shortcuts and so on makes it difficult if not impossible to use a Squeak MVC or Morphic UI for a typical commerical application.

Different people have different goals. A few goals are

* exact look and feel of one platform, best implemented with native widgets

* classic look best suited for data entry programs

* web page-style look best suited for information systems

* something that's different to <insert hated platform>

* something really innovative

* something that allows one to create business application in Squeak

I'm currently in favor for the last point. I believe that it's not required to perfectly immitate one look but if you look at most UIs, you'll notice that they all fell quite similar. I believe you can define and implement this meta-feel which will be suficient for people to work with the application. The look might be customizable to further ease acceptance of the users.

I don't want to experiment with innovative UI concepts right now or makeup something that's different just for to be not similar to an existing look. People should find the look and feel familiar because this is what makes an UI "intuitive".

bye -- Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf