The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Desktop app GUI done with HTML + javascript

We are currently doing a test project, which is to replace a desktop app's QT-based interface to a HTML+javascript-described GUI. The idea is to reduce the coding workload, and just have a web developer to be responsible for the UI look & feel. Every time the app is activated, it'll go to the server and pull down the latest GUI graphics etc. to be stored in the local directory, so it is not so reliant on Internet connectivity. The server can also "push" the changes to the app. As of now, the project is a success: we can use javascript + html to do every design that we did for the QT version, and the app functions as normally as the QT version.

Now the problem: we've been asked to provide a list downsides of such an app, and we can't find any in our current lab environment.

Has anyone done a similar project and can share what potential pitfalls are?
Michelle Johnson Send private email
Tuesday, July 04, 2006
Downsides compared to what? Without knowing the ins and outs of the application and technologies available to you it's a difficult question to answer. If you have kick ass web developer / web development team then it the argument for using something like ClickOnce or Flash are less for example.
Tuesday, July 04, 2006
What rendering engine are you using for the HTML?  If it's a system-provided one, how are you preventing system upgrades from breaking your app?

How natural does the interface feel?  My experience suggests that many users strongly dislike interacting with things that feel like websites but aren't; people have expectations of how a desktop app will behave, and badly-thought-out HTML violates most of them.  Witness how quickly Microsoft's attempt to HTML-ify Windows died.  That's all anecdotal, of course, but I hope you've done some market research on this.

How robust is your layout?  Many HTML layouts don't resize well, but users expect to be able to resize most kinds of desktop application.

I'm slightly disturbed by your saying "WE can't find any [downsides] in OUR LAB ENVIRONMENT".  The implication is that you haven't sent your prototype out of the lab and into the hands of people who haven't been involved directly in its development.  If that's the case, then get it out of there and get some real users or maintenance coders to tell you what the downsides are.

If you've done proper testing with both users and maintenance coders and you still can't find any downsides, then it's even possible there aren't any in your particular case...
Tuesday, July 04, 2006
I'm working on a new type of "browser" that will allow anyone who knows only HTML + javascript to make a desktop application.

Basically it's like HTA but much better because it lets you have complete control over the user experience, it lets you do tool bars, dockable tool windows, custom context menus, modal dialogs, modify window chrome, etc. It also lets the javascript do *anything* like access files and create any COM object and draw using GDI (it uses MSHTML for the browser engine).

I call it the "Web Based Desktop", but the name may change before it's released for beta. You can look for a beta in about 2 months.
Wayne B Send private email
Tuesday, July 04, 2006
And before you say anything about security...this is not an end user's an application framework, so the developer decides what code is executed on the end user's machine, as usual.

The javascript can come from anywhere (local file, embedded in the exe, or a URL), but at no point does the end user specify which URL/location that is...the developer does.
Wayne B Send private email
Tuesday, July 04, 2006
Wayne B - Gecko, XUL and XPCOM are pretty much what you are trying to do.
... Send private email
Tuesday, July 04, 2006
Not really. Gecko, XUL and XPCOM are a set of low level tools. My idea is much higher level. For instance: Can you add a system tray icon, menu or balloon tips to the Windows task bar with XUL and XPCOM? How much work is it?

My product lets you do something like this:

var oSysIcon ="iconName", "http://localhost/icon.ico");

oSysIcon.visible = true;

With very few lines of code you can do things like make a window that is oddly shaped, shell out a command or listen on a TCP port.
Wayne B Send private email
Tuesday, July 04, 2006
Sorry to have hijacked your thread Michelle. My comment for you is that using HTML for the GUI works very well and you should definitely consider using this technique.
Wayne B Send private email
Tuesday, July 04, 2006
It sounds like a good idea. I like having an app the looks like a desktop app without the extra browser toolbars etc. I like the familiarity of designing the interface with HTML and JavaScript. I don't like using Swing or SWT to design interfaces.

I've had some success using Java and JDesktop Integration Components (JDIC) to create customized interfaces. The shell is with Swing and the actual interface utilizes IE or Firefox to display HTML and run JavaScript. Hooks and listeners can be created for cummunication between the backend and interface. AJAX can even be utilized if you're into the hype. Throw in Mozilla Rhino and you could have a complete HTML/JavaScript solution that utilizes the Java Jar files. Have fun. There are loads of possibilities.

From an interface standpoint, it's important your designers have a solid understanding of both desktop interface design and web interface design. Both interfaces types have drawbacks in addition to universal interface issues and it will be difficult not to create new ones as these hybrid interfaces come to light. I like to think of what I would like in an ideal desktop interface. I then think through how I can simulate that with HTML and JavaScript. Finaly, I think through how HTML and JavaScript could be used to enhance the user experience, for example, with CSS users can now easily choose a legible font size without much additional work by the designer. STOP! Is there anything that is a hinderance? Will the user find any unexpected behaviors? Where is the visual feedback? Where is the navigation? is it consistant? What happens when enter is pressed? Can I use OS shortcuts...?

WayneB: I wish you and your product well. While JDIC will hande tray Icons and much of the other functionality you mention, sifting through everything to DIY is not for everyone.
Thursday, July 06, 2006
In Mozilla, the theory was the HTML/JavaScript programmers could write GUIs.  In reality, coders were balkanized.

Non-Mozilla HTML/JavaScript people would look at XUL and say, "It looks like HTML and JavaScript but there's a bunch of weird tags and unknown new function calls.  It looks familiar, yet not quite right or understandable."  Some HTML/JavaScript guys would pick up the extra stuff but a lot would just say, "Forget it."  Often, C++ people would just end up writing the HTML/JavaScript; that was far easier than trying to "outsource" that part to a web person.

And, of course, when a feature or issue crossed the JavaScript/C++ boundary, it was a pain.  The JavaScript guy would give up; he couldn't fix serious problems from inside the pure JavaScript prison.  The C++ guy would end up coding and debugging C++, the JavaScript/C++ boundary and the pure JavaScript.

In the end, it's not clear if any time or effort was saved.  Being HTML-like (or an HTML superset) isn't the same as being HTML.

I look on with interest on all these efforts but the problem is popularity.  You've got to become super-popular before your "extensions" become common knowledge and expected of every HTML/JavaScript guy.  Until then, having the web guy do GUIs is a theory, not practice.
Daniel Howard Send private email
Thursday, July 06, 2006
1) You get ALL the downsides of web apps including but not limited to browser incompabilities, lack of keyboard shortcuts, stateless communication, etc.
2) Browsers have different security rules for local pages and remotely delivered ones. This may or may not bite you.
3) You're breaking new ground, so any web developer won't do. You'll need one of the best ones and (s)he is going to be expensive.
Peter Monsson Send private email
Sunday, July 09, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz