Short Courses on Computer Graphics, Image Processing and Computer Vision |
Let me know what you think |
Short Comparison of Windows Application Programming Interfaces (APIs) and Browser APIsCopyright © by V. Miszalok, last update: 2009-07-17 |
Introduction
A Border Containing a Resizing Text
between Two Resizing Buttons
C1: Java Application
C2: Windows Forms Application
written in C#
C3: WPF Windows Application written
in C#
C4: WPF Windows Application written
in XAML and C#
C5: WPF Browser Application written
in XAML and C#
C6: Silverlight Browser Application
written in XAML and C#
C7: Java Applet
C8: JavaScript Browser
Application
C9: Flash Application
C10: JavaFX Application
Its hard to write a good user interface even for simple
programs. Most interfaces are ugly and buggy and far from being
self explaining to the customer. The amount of code for a usable
surface normally takes 50% of the overall code. Many
Application programming interfaces = APIs provide
tools for writing surfaces. This course compares a lot of modern
APIs for Windows- and Browser-applications. (not including APIs
for MAC OS, Linux and for dedicated Systems as Facebook, Google
Maps, iPhone, PayPal, YouTube etc.)
The program that serves as sample for comparison is very simple:
Two buttons and a text field that have to adapt themselves to a
resizing window or Html page.
Such a fluid layout is called a liquid Graphical User Interface =
liquid GUI or fluid GUI is intended to behave
reasonably at any big or tiny display- and window-size. In case
of browser applications
It comes out that the differences in necessary code volume and
resulting elegance are higher than expected.
lines of code | look and feel | Op.System + Browser |
Example's drawbacks | |
GUI+API for EXEs
running on the desktop = dektop applications |
||||
Java | 64 | 0 | all OS | Button size doesn't follow font size. |
WindowsForms | C#: 53 | 0 | Windows | Button size doesn't follow font size. |
WPF written in C# | C#: 58 | ++ | Windows | |
WPF written in XAML and C# | C#: 19 + XAML: 16 | ++ | Windows | |
Silverlight Out of Browser | C#: 20 + XAML: 14 | ++ | all OS | |
JavaFX Desktop | JavaFX: 45 | + | all OS |
Too slow, needs a launcher program |
Adobe AIR | ? | ++ | all OS | |
GUI+API
for programs running in a browser = web applications |
||||
WPF | C#: 15 + XAML: 14 | ++ | Windows IE + Firefox |
|
Silverlight | C#: 20 + XAML: 14 | ++ | all OS all browsers |
|
Java Applet | 50 | 0 | all OS all browsers |
Strange behavior at start |
JavaScript | 44 | + | all OS all browsers |
IE and Firefox need different code. Font-zoom isn't linear. |
JavaFX | JavaFX: 45 + JavaScript 50 |
+ | all OS all browsers |
Too slow |
Adobe Flash+Flex | ActionScript: 7 + MXML: 16 |
+ | all OS all browsers |
Doesn't cover complete window width. |
Several GUI+APIs appear in the dektop rows and in the web rows of the GUI+API table above (Java, WPF, Adobe) because the sharp gap between classical desktop and classical browser applications nowadays seems to vanish. The new Rich Internet Application GUIs = RIAs contain elements of both worlds. The success of RIAs not only depends on the attractivity of beautiful GUIs but on the acceptance by RIA programmers and how they get along with the technology while producing RIA software.They need a powerful IDE = Integrated Development Environment. And their related RIA designers need powerful WYSIWIG tools. The main competitors on the IDE-market are Sun with Java+JavaFX, Adobe with Flash+Flex+AIR and Microsoft with WPF+Silverlight+Expression Studio.
The crucial problem of RIAs is the sad fact that search engines do not see them. Google, Microsoft Live Search and Bing and Yahoo just see and crawl static HTML pages and never detect any RIA-code or RIA-wrapped content. The only way to be found is the presence of external links to such a RIA page. |
|
1. Informational Pages are happy to be rendered by a browser which provides an URI, back- and forward navigation on a history, refresh and stop loading, bookmarks and a menu with "Save", "Edit", "View", "Print".
2. Web applications are browser-pages for heavy interactive needs. They are based on "Views" rather than pages. Such a "View" is a dynamic GUI presentation of a state of a page and the state transitions are mostly programmed using AJAX. But the browser buttons usually create a lot of problems. The buttons "Back", "Forward", "Refresh", "Stop Loading" cannot be disabled and often result in an interaction disaster. Users have to learn not to touch these browser buttons when using a Web application.
3. Internet-enabled applications do not run in a browser but offer content as browsers do. They handle their own navigation and "Views" and provide a much safer user experience as Web applications do and they offer the freedom of GUI-design as native desktop applications do.
Drawbacks of I-e applications:
3.1. The user must install them plus their runtime libraries which takes time at first use.
3.2. The user must have the right to install something on the computer.
3.3. The user must trust them.
3.4. Deinstallation is necessary after last use.
Click the Talk!-button and resize the browser window !
top of page: |