Web technologies in GUI apps - user-interface

What's your experience in using web technologies (HTML, XML, CSS, JavaScript) to implement part of the functionality of a GUI application? Pros and cons, please.
No servers, relational databases, AJAX, or cookies for session management, nor an existing webapp either, but rather a GUI app that uses web widgets (like Qt WebKit) to render and handle substantial parts of the UI, while taking advantage of a GUI framework to achieve an even richer interaction and better desktop integration.
I've already validated that the approach is possible using PyQt. Content can be rendered from the file system or from strings, and URL requests (images or clicks) can be captured and served by the form's event handlers. CSS and JavaScript are supported, perhaps with some limitations.
# ...
self.webView.page().setLinkDelegationPolicy(
QtWebKit.QWebPage.DelegateExternalLinks
)
#...
class TotiMainWindow(QtGui.QMainWindow):
def linkClicked(self, url):
pass # events arrive here
Note: This question is different from this one and this one made before, among other things because there is no requirement to use web technologies on the GUI, but there is the requirement that the application should work without a network connection available, and should integrate well with the default desktop over different platforms, without previous infrastructure requirements (no .NET, Java, browsers, or database servers).
Note: I posted a different version of this question on PMS but found very little experience with this approach there.
Closing Note
I just found most of the information I was looking for in a series of blog posts by André Pareis.

I think the largest advantage to using web markup like HTML/CSS and other web technologies is that desktop apps may very well have their days numbered.
As we speak, Google engineers are working on the Chromium OS, which essentially consists of a single GUI application... the browser...
Now, while nothing may never actually come of it, there is clearly a rising trend in the number of applications accessible through a web browser, accessible anywhere. It seems to me that this is the future of application development.
By using these technologies, this becomes one less headache you have to deal with when or if you determine that your app should be available as a web application.
Update: A few years ago, we developed an Agent Desktop for our call center that is essentially a local application that opens sockets to integrate with the phone system. The user interface the agents use is built with HTML, CSS, and JavaScript, and the experience is stunning. When we released our latest update in 2010 with a professional CSS redesign, our agents were all very impressed with not only how easy it was to interact but also how easy it was to use.
In the future we will port this 100% to the browser, but for now it needs to be a local application because of the COM integration with the phone system.

We did exactly this for a project back when Windows XP was new.
This gave my team several benefits:
A good-looking UI with relatively little effort
Easily change the style of the UI in a consistent manner using CSS
Relatively simple integration with C++ (invoking functions from the ui and vice versa)
The drawbacks we saw were:
Some not-so-good firewalls considered accessing internal resources (ie other html pages in the ui) to be a web request
Adding and accessing the needed resources could in some cases be a bit cumbersome
It was possible set properties in Internet Explorer that would prevent JS from running in the application
Note that some of Windows XP:s programs are using this approach.
This probably works best with small, more Wizard-like parts of the ui (which our ui consisted almost entirely of).
I have since then not really been involved in ui projects, so I cannot really tell you whether this approach is still valid... I know that MFC-based applications will let you use HTML-based dialogs though.

In a similar situation in 2005 I created a stand-alone webapp using XForms, CSS, JavaScript, XML and XML Schema for offline data retrieval and verification. With a good XForms -> HTML + JS transformer (Chiba) it did the job with no bug fixes after the initial release. It was used for 6-12 months (IIRC) by about a dozen engineers for a project gathering test data in the tunnel of the Large Hadron Collider. The biggest surprise of that project was just how much you get for free when going for a web platform, even for offline use. Highly recommended.

The major problem is that it reduces your development speed, or the quality of your user interface. A lot. Unless you're using Seaside, it is much faster to develop a desktop app.

There is quite some number of applications built on top of Mozilla platform. It isn't 100% web technology, as instead of HTML you use XML based XUL, but the rest is indeed web stack (JavaScript, CSS). The most successful of these it the OpenKomodo and it's commercial big brother Komodo IDE.
On the other hand, as far as Qt goes, the newest version 4.7 you can build GUI using QML language. Don't let the name mislead you, it's not markup, it acctually JavaScript with app-specific extensions.

Related

Web Application in place of a more traditional UI?

I am considering using a web application in place of a traditional UI to control an imaging system. The UI will allow the user to do things like change settings, upload scripts, start/stop data acquisition, view data, etc... Rather than a monolithic UI that "does everything", an embedded controller would interact with system hardware and control the process, receiving commands from the UI over a local network.
I would probably use a javascript toolkit or perhaps some .Net technology to build the web application. A few of the advantages I see are:
Access UI from any browser.
No software to install.
Access remotely if necessary.
View status/data from multiple computers simultaneously.
Modular (separation of concerns)
Data as a web service.
A few of my concerns would be:
Lack of a comprehensive widget toolkit.
Supporting multiple browsers, this may not be as bad as I think now with HTML5.
Updating the UI from the server.
My questions are, Is this common? Is it a bad idea?
If it's really subjective, I understand, however, I just wanted to see if there is an obvious answer, like "DON'T DO IT!!!!"
It is very common. I do it all the time, particularly for a closed community of users such as you will have.
It might be different if this was a public facing device, but it is not.
You are going to support more devices by saying "you must have an HTML 5 browser" than if you said "You must have a PC" or "You must have a Mac"
In terms of your concerns, I do not see any of them as being an issue.
It is easier to deploy a UI upgrade once to the imaging controller than many times to all of the client machines.
There are all of the widgets that you could ever want available for HTML 5 compatible browsers
You answered your own question about cross browser issues. HTML 5 browsers are free so there is no downside for people to upgrade to them and you have the entire weight of the world wide web pushing them to upgrade to take advantage of what can be done with HTML 5 so users have a big incentive to upgrade. I do not run into any push back when I require a closed group to use an HTML 5 compatible browser. And if you want to be kind to those that don't have html 5, you can always use modernizr.
It is a good idea - and there is plenty of examples and ways of doing what you want to do.

Node.js for "traditional" sites

I'm digging into Node.js now and the whole idea seems brilliant to me. But I'm interested in what the benefits of using Node.js are when developing "traditional" sites with a bit of AJAX and no realtime features. When I say traditional, I mean the sites that one usually builds using MVC frameworks on platforms like PHP, ASP.NET, etc.
I know that the Express framework is popular, but the question is more about what I would gain by switching to Node.js rather than simply "Can I do MVC in Node?".
Node has the advantage of
having a rich open source community with third party modules that solve most problems
having a low level API with a minimal amount of "default" bloat
reducing language context switching
having a decent level of performance
allowing you to manipulate the HTTP server programatically within your application
I guess this url: How to decide when to use Node.js? -is all you need.I am making this as community wiki.

Capuccino alternative with a comparable looking UI?

I'm looking for a set of Javascript based UI components for a web app I'm building and have found that many of the best looking web apps were built with the Capuccino framework; see http://www.getflow.com/, http://www.picsengine.com/home/ and http://timetableapp.com/ for examples.
However, I'm not a Cocoa developer and have no interest in learning Objective-J. Ideally, I'd find a set of components that provide the visual end result of Capuccino apps without the underlying weight of the framework.
I have seen the Aristo jQuery UI them (http://taitems.tumblr.com/post/482577430/introducing-aristo-a-jquery-ui-theme), but jQuery UI just doesn't seem to have the depth of components available in Capuccino.
I realize this may be a long shot, but I figured it can't hurt to ask. :)
Thanks.
As another option, there is jQuery UI: nice if you are already familiar with jQuery, with the plus side of not being too heavyweight, but may not have all the components you need pre-defined. A nice thing is that it encourages to write the HTML in a way that degrades gracefully when your application in older browsers.
Maybe sproutcore is an alternative for you, although it requires you to hand-code everything in javascript from scratch. It offers most basic components and is easily adjustable to your personal design goals. Sproutcore is used in Apples Mobile Me and in some other big projects.
Another possibility might by vaadin which offers a rich set of prebuild controls and is based on Googles GWT javascript compiler. But it only makes sense if you are developing in a java environment.

JSF vs Flex

I want to settle on a GUI framework, and use AJAX, as simply as possible.
Assuming adequate skills in both JSF and Flex, but not too skilled at AJAX/javascript, and assuming Java as the language for the application, and using a DB, which is a good choice, or both have equal set of pros/cons?
Try using Richfaces. As RichFaces library will provide ready made Ajax Enabled JSF Components. You can use them in your JSF Application.
RichFaces is a rich component library for JSF and an advanced framework for easily integrating AJAX capabilities into business application development. The RichFaces components come ready to use out-of-the-box, so developers can immediately save time in taking advantage of component features to create Web applications that provide greatly improved user experience more reliably and more quickly. RichFaces also includes strong support for the skinnability of JSF applications. RichFaces also takes full advantage of the benefits of the JSF framework including lifecycle, validation, and conversion facilities, along with the management of static and dynamic resources.
http://www.jboss.org/jbossrichfaces/
...and the pros of Flex are:
Flex Framework-built SWF files runs in the Flash Player JIT, which is 100x faster than browser-native JS, unless you've got a JS Jit-enabled browser which uses SquirrelFish, for example. So user performance may vary considerably, whereas the Flash Player works at the same performance across all browsers, all platforms.
The Flex Framework is open source, so you can customize it to your heart's content. And since it runs on the Flash player, it runs the same everywhere. Unlike an AJAX framework, where you usually have to be highly expert at browser compatibility coding to customize it.
Flex tools are also free, as the Flex SDK is open source.
Having said that, you can code desktop apps in AJAX using Adobe AIR, without using Flex or ActionScript, if you want to.
How to make HTTP requests with Flex:
http://www.adobe.com/devnet/flex/quickstart/httpservice/
AJAX using JQuery (one of many JS frameworks):
http://docs.jquery.com/Ajax
Both of these are pretty simple once you've played with 'em a bit. You specify a URL and a callback function to read the text response once it's finished loading. Assuming you're familiar with the pros of Flex, the pros of JS are:
It doesn't require a browser plugin
You don't weigh down the page with the Flex framework.
You'll probably find more developers in the market who are familiar with it because the development tools are free and the code is usually visible to anyone who wants to learn from it.

Choosing between Ajax, Flex and Silverlight [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Ajax, Flex and Silverlight are a few ways to make more interactive web applications. What kinds of factors would you consider when deciding which to use for a new web application?
Does any one of them offer better cross-platform compatibility, performance, developer tools or community support?
Here's a quick rundown of each area (with lots of helpful links):
Cross-platform compatibility
Ajax works in any modern browser that can run JavaScript. Flex requires Flash or anything else that can handle SWFs but, once that's installed, it's a total freeride as far as compatibility. Silverlight is tricky and misunderstood so carefully consider your userbase before going with this MS foray into the rich web applications arms race. Also keep in mind that Silverlight is still in Beta, so it may become more widely used and installed in the future as it is developed.
Performance
I'm fearful of making too many statements about performance because it really depends on how much you are willing to optimize and the exact nature of your application. Also, some technology stacks are just never going to be very fast. Some people out there have been making comparisons, but again, it depends on a great many factors (even the version of the browser from which you are testing!). It's probably best to choose based on other factors and optimize once you've started to develop.
Developer tools
There are the "golden standard" dev tools for each of the three:
Ajax has basically unlimited options, depending on the rest of your technology and architecture choices. The big questions you're actually faced with are which libraries to rely upon, and Google has voiced a pretty well adopted answer with things like Web Toolkit. When you get right down to it, it's just XML and JavaScript, right?
Flex is from Adobe and, just like with Flash development, you'd better stick with their homegrown tools because--well--they're making the standards as they go along.
Microsoft has positioned Microsoft Expression Blend versions 2.0 and 2.5 for designing the UI of Silverlight 1.0 and 2 applications respectively. Visual Studio 2008 can be used to develop and debug Silverlight applications (from Wikipedia).
Community support
There is both official and unofficial community, corporate, and open-source support for all three options. Whichever you are already integrated with and which makes you feel most at home are very individual things, but I'll offer this advice: stick with what you know. If you are a MS developer and have MSDN as your homepage, you are probably going to think the Silverlight documentation and forums are really helpful. Flex has a very similar story; the forums are pretty good and if you're a Flash person already, you're going to be right at home with their documentation and user community.
On the other hand, Ajax is basically all over the place because you can implement so many different ways and use so many widely-varied libraries. Each library can have it's own forums to visit and mailing lists to lurk within for answers.
Once again, all three have corporate giants trying to foster their communities and to get the best support possible to the developers that will give them greater market share in the future.
The choice should in my opinion be mostly based on the nature of the application you'll be building (for example, if you need to manipulate vector graphics, Ajax is pretty much out), but here are some general guidelines:
Ubiquity
Ajax -- Supported by all modern browsers across platforms
Flex -- Runtime (Flash Player) has very wide installed base for Windows, Mac OS, Linux. Linux version was a bit buggy the last time I checked, though
Silverlight -- Runtime has quite low installed base (and no Linux support) at the moment
Choice of programming language
(Unordeded because of subjectivity, but note that Silverlight offers the most choice. Also note that the existing language experience of developers in your team should be taken into account.)
Silverlight: Any .NET language (C#, Visual Basic, IronPython(?), IronRuby(?)) (and XAML for UI definition)
Ajax: JavaScript (and XHTML for UI definition)
Flex: ActionScript 3 (and MXML for UI definition)
API Stability and compatibility
Flex -- Runtime is the same across platforms and browsers, more mature and stable at the moment than Silverlight
Silverlight -- Runtime is the same across platforms and browsers, less mature than Flex/Flash, v2.0 is still in beta
Ajax -- Compatibility problems across browsers (may be mitigated via Ajax libraries, though)
Web/Browser Integration
Ajax -- Content is native inside browser, based on standards: searchable by browser and search engine crawlers, subject to any standard UI practices the browser and operating system have established
Flex and Silverlight -- Content not native to browser (i.e. runs in its own little "sandbox/rectangle"): not necessarily subject to established UI practices for the given platform
Developer Tools
Ajax -- Your favorite code editor, browser and debugging toolkit for the browser
Flex -- Flex SDK is available for Windows, Mac OS and Linux for free and can be used with your favorite code editor. A Command-line debugger is included, but the Adobe-provided profiler is only available in the commercial Flex Builder IDE
Silverlight -- AFAIK, The SDK is available for Windows for free and can be used with your favorite .NET development tools
The web runtimes like Flex and Silverlight all offer enticing things, but come with two big costs:
They run only within a rectangle on the page, and don't interact with normal web widgets
They are only available to people who have that plug-in installed
Even the nearly-ubiquitous Flash isn't installed on every web browser, so by choosing to use a plug-in runtime you're excluding part of your audience.
In contrast, JavaScript (or Ajax) is available on pretty much every browser, and interacts better with normal web pages, but is a more primitive and restricting language. Using it for complex animations can be tricky, and you'll need to test your applications in more versions on more platforms to make sure it works.
Cross-platform compatibility isn't the issue it used to be, so the issue is this: Will you gain more in the features of a plug-in library than you'll lose in the audience you exclude?
My own answer has so far always been JavaScript/Ajax, but I'd re-evaluate that in any new project.
What is your audience: public web site or an intranet business app? Adoption rates are not relevant if you have a controlled audience who will install what is needed to run your app. However, if you need the largest possible audience to make your web startup a success then it may be critical.
What is your goal? Building something for the lowest cost? Learning new technology?
Can you leverage your existing skills? If you already know .NET then Silverlight gets a boost. Learning Flex may be interesting and useful, but is it more useful to you than more experience with .NET technologies? Remember to consider the opportunity cost of learning something totally new.
I don't see a clear technology winner at this point, and likely there won't be one for a long time, so the choice will come down to fairly subjective factors.
Other than what's already been mentioned here, another huge thing to consider is what your UI is going to be.
If you're going to be using a lot of advanced UI controls like trees, lists, tab controls, etc then consider the following:
JavaScript/HTML - No native support for anything beyond things basic drop down boxes, buttons, and text fields. If you want something like a tree control or tab control then you'll have to roll your own or find a third party library.
Adobe ActionScript - Native support for a wide array of advanced UI controls
Silverlight - 1.0 had very limited UI controls, but 2.0 will be adding many more and I'm sure we'll continue to see controls added in future releases.

Resources