[Dev] Native Platform Integration [was User interface]

[John Anderson]

I generally agree with Curt's conclusions (although probably I'm biased
having influenced the design of NextStep).

If you don't make your application work like other applications on the
platform, users won't like it. Most users get used to the subtle
behavior of native controls, and the interaction between applications,
on the platform they use -- this is particularly true on Macintosh and
Windows which have a farily consistent interface. It's less true in
Linux, but as Linux evolves I believe it will standardize as well.

On a different note, we'd like to do themes, and XUL would make this
easier than wxPython. However, if you had to rank all of the features in
terms of importance, themes are closer to the bottom than the top.

MVC is a top priority.

John Anderson

Curt Hibbs wrote:

>Michael R. Bernstein wrote:
>  
>
>>The main difference between XUL and wxWindows is that a XUL app will
>>look exactly the same on every platform, whereas wxWindows uses the
>>native widgets on each platform.
>>
>>Depending on the scenario, this is either good or bad.
>>    
>>
>
>In UI discussions there is usually a lot of talk about native platform
>look-and-feel. What is often overlooked (and, in my opinion, more important)
>is native platform integration. This was a hot topic last January on
>comp.lang.ruby. Here is an excerpt from a post made by Sean Russell that
>made a pretty clear case:
>
>== begin quote ==
>One thing that *n?x users tend to be blind to is the importance of
>cooperation between an application and the desktop.  In my mind,
>look-and-feel is a minor issue compared to how well an application
>integrates with the environment in which it is running.
>
>Consider: StarOffice and KWord.  My wife is an author, and is not what you
>would call a computer afficianado.  StarOffice is a much better word
>processor than KWord (at the moment).  It is more feature complete, and it
>doesn't suffer from the printing problems that plague KWord.  KWord is
>currently WYSI*not*WYG.  Despite this, she uses KWord.  Why?  Because the
>current version of StarOffice/OpenOffice doesn't support copy/paste from
>the X clipboard.  This means she can't copy from Netscape, or Konqueror,
>into StarOffice, and this is unacceptable.
>
>Also consider NeXTSTEP.  Still, in my mind, the best windowing environment
>on the planet.  You could drag and drop from practically any application to
>any other.  It supported complex data types in the clipboard the likes of
>which I haven't seen on any other OS, to this day.  It was /integrated/,
>and it worked fabulously well.  The GUI wasn't complex; the widgets weren't
>multi-hued animated superbuttons, but it was a joy to use.
>
>*n*x users don't see this, because they traditionally haven't had it.  KDE
>and Qt are bringing this to the Linux community, slowly, and I ask you KDE
>users to consider: don't you find yourself trying to find KDE versions of
>your applications, not because they look the same as your other KDE apps,
>but because they integrate better?  They dock, they answer to the window
>manager requests (a-la smart-starting when you log out and in again), and
>so on.  Windows users are more used to it, but they generally tend to think
>of it as an appearance issue.
>
>I propose that the strongest argument for using native toolkits is to gain
>this integration with the user's desktop.  You can emulate look-and-feel,
>but you can't emulate integration.
>
>So the goal becomes one of getting a toolkit through which applications can
>integrate into the native environment, while providing a maximally portable
>API.  This is what SWT attempts to do; it tries to use native widgets, when
>they are available, and provide abstract widgets when they aren't.  In this
>way it provides an API which is portable, but is reasonably lightweight,
>fast, and integrated.
>== end quote ==
>
>WxWindows (like SWT mentioned in the quote above) uses native widgets where
>possible and because of this, delivers a higher level of integration with
>the native platform than most other toolkits (including XUL).
>
>Curt
>
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
>Open Source Applications Foundation "Dev" mailing list
>http://lists.osafoundation.org/mailman/listinfo/dev
>  
>