User Interface Design w/ Embedded Web Server

Don't move to a web server, then. Because the chances that you'll manage to reproduce any kind of involved GUI using a reasonably simple embedded webserver (no javascript or other contraptions, *definitely* no Flash) are essentially zero.

Just ask yourself how the best interactive websites you've seen yourself compare to your existing GUI, and don't forget to cross-check what techniques they used --- some of which are way out of reach for an embedded device's web interface. That should give you a feeling what you can, and more importantly, what you can't do.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

It's not embedded management specific, but

is an excellent place to read about web usability. There are both guidelines and case studies.

Yes, there was cli, then snmp, sometimes corba, now this. Unfortunately, emergence of a new management interface does not automatically result in the previous one going away, so half the time one ends up supporting all of the above!

The main trap to avoid is one you may be teetering on the edge of already. It is important to think of your web management project *as a web management project*, not as a conversion or reimplementation project of any sort. If you design with a conversion mindset, then you will produce a godawful kludge of a management application implemented over http, and you will eventually throw it out. If you design with a fresh start mindset you may be able to produce a nice web-esque management interface that is both powerful and intuitive.

If you really feel that your product cannot be operated usefully from a web-style interface, then the conventional alternative is to construct a Java management application and plonk that in as the "web" interface. IMHO, this is a questionable path, no matter how popular it is.

--
Grant Taylor - gtaylorpicante.com - http://www.picante.com/~gtaylor/
   Linux Printing Website and HOWTO:  http://www.linuxprinting.org/

: Don't move to a web server, then. Because the chances that you'll : manage to reproduce any kind of involved GUI using a reasonably simple : embedded webserver (no javascript or other contraptions, *definitely* : no Flash) are essentially zero. :

Um... javascript and flash both run on the BROWSER, not the server.

I would recommend that you look into 'boa' if you're needing an embedded webserver. Also, check out the axis web cameras if you'd like to see a somewhat decent UI for a product. (hint: search for 'axis camera 2.33' and you'll find tons of them, some without passwords...)

--buddy

--
Remove '.spaminator' and '.invalid' from email address
when replying.

Have a look at my article for Embedded Systems Programming at

Title: It's Worse on a Browser, August 2001.

In short the artcle says you are probably better off the way you are - my article warns about some of the ways in which the interface will suffer on the web. Niall Murphy

=========================== See the User Interfaces for Embedded Systems Page at

Thanks, Niall.

I actually read your article back then and it helped to convince me not to do an embedded server at that time. I was just wondering if there have been any advancements over the past two years that I have not been privy to.

I recognize your experertise in this space, but let me suggest an alternate perspective...

It may be easier/better for the device to serve up its own interface, in order to keep target and client in sync and improve accessibility. (Though clearly this has to be balanced with device cost.)

If you need a rich GUI, why not have the device serve up a feature-rich Java client, offering many of the best features from both approaches? It'd let you keep the device low-powered (though with lots of flash for storing the Java code for download), shifting the overhead of a rich GUI to the powerful client PC.

Case in point: Years back, Bay Networks (now Nortel) took the position that their networking gear was 100% configurable via SNMP, using their own thick GUI client. It sounded great in theory. In practice, it experienced a host of issues.

• Client software had to sync versions with the target device, creating issues for customers with multiple devices. New features required regular client upgrades. But bugs in new releases meant one client couldn't manage all devices.

• The client had to be installed - a huge issue for operational support environments where ad-hoc access was needed (e.g., from home). Or where a compatible PC platform wasn't available.

In either case you've got to contend with supporting software issues at the client PC. Are we at a point where Java is deployed broadly enough to depend on it's presence?

I can see how Nortel expierieced all of those problems, but did they solve them with a Java client - I would be impressed if they did, but I fear that they would just have replaced them with issues of ensuring that the client devices would run the appropriate JVM to support the client - though maybe these would be less troublesome than the situation you describe..

Having said that, the main point of my article was that serving the GUI from the client solved lots of deployment problems for the vendor, but the result is a worse experience for the user (not necessarily the installer/administrator). Generic GUI's like HTML can not hope to be as good as a native GUI. Java can come closer, but is still far short of a native Windows or X application.

If you want to trade off user-experience against ease of deployment, that is your choice (and easier deployment may be the right choice in some cases, but in those cases I would prefer to be the supplier, not the customer).

=========================== See the User Interfaces for Embedded Systems Page at

At last word, they were still slugging away with the same approach. Admittedly, theirs is an extremely complex example, but nonetheless an experience that made an impression.

Agreed. But I've seen some pretty impressive Java clients (e.g., Oracle has several) - there are even Java-based VPN clients now. As an observer, it seems Java is being used successfully to deliver some pretty rich features.

I was hoping the deployment issues of JVMs might have been overcome in the 2 years since your article; it sounds like that may not be the case yet?

Cheers, Richard