Feedback to "It's Worse on a Browser"- Murphy's Law,
to Murphy's Law
Just finished reading
your timely Aug 2001 article on browsers vs custom interfaces,
and I agree wholeheartedly with most of what you say. What we
really need is a way to combine the usability of a custom interface
with the portability of a browser interface; so far, there doesn't
appear to be a good way to do this.
You did note that "Keyboard
accelerators are very useful in a desktop application, but cannot
be used in a browser." This is incorrect -- both Internet Explorer
and Netscape (and probably Opera, though I haven't checked) can
Indeed, we use this
capability in our own embedded HTML interface to provide one-key
access to the most common features of our own web-based interface.
Unfortunately, this doesn't work on Unix-based versions of Netscape,
but it is still substantially better than no keyboard shortcuts
For more information,
see for example:
In Niall Murphy's column
in the Aug 2001 issue of ESP, he states "The simpler solution
is to allow access to the data, and let the receiver manage the
user interface. The data itself can be transmitted over a socket
using a proprietary application-level protocol." What he really
should be recommending in this situation is SNMP. This is what
it was designed for. It's simple to implement, STANDARD, and supported
by a wide range of platforms.
I would agree that
SNMP is a good match in some cases, but it is not really a general
solution to the problems I describe. SNMP (Simple Network Management
Protocol) is designed for network management and so is a good
match if you are managing routers, bridges or other devices that
handle network traffic of some kind, and if the data you are interested
in is related to that traffic.
While it is true
that you can define a MIB (Management Information Base) to hold
pretty much anything you like, I do not think it is appropriate
to use that mechanism for general data about a device. If my device
is a train carriage and I want to know its position, or the temperature
of the break pads, then I could report that with SNMP, but it
is not what SNMP is designed for. If I want to know if train carriage
is connected to the network, and if it is successfully communicating
with other train carriages then SNMP is a reasonable match.
I would also question
your assertion that SNMP is Simple. If I want to design a MIB
then I need to get into the details how ASN.1 works - this is
not trivial. If we are only dealing with a few parameters then
a simple text exchange on a socket where one node can write:
"set speed 100"
or obtain information with
then you have a simple protocol that can be implemented in a fraction
of the time that it would take to understand how SNMP works, much
less implement it on your system.
Admittedly on some
platforms SNMP will be available with your TCP/IP stack, avoiding
the most painful part of the task, and it is still a better way
of getting raw data around than http, which was the main thrust
of the article that you were commenting on.
I read you article
and have some questions. I agree that a web browser is not ideal
for a GUI. However, given the architecture today, if one wanted
to use a GUI independent of platform with a http server, what
choice do they have? Currently, other than custom designing an
interface, we are forced to use a web server when performing remote
Jet Propulsion Labs
Your point is completely
valid. The alternative to a http server is to write a custom interface.
The whole point of my article is that the custom interface you
create will be a better user interface than the browser based
interface. Now it may involve extra work, but that is the trade-off
- in many cases extra work to provide a better product is a worthwhile
investment. I am not suggesting that this is the route for all
products, but I wrote the article because so many products were
going down the browser route without even considering the options.
From: "Michael Hardt"
Subject: Article on browser interfaces in Embedded Systems Programming
I thank you for putting
into words my experience with the recent mania for using browser
interfaces. Last year I was initially attracted to plans to convert
all existing applications on our frame relay network to the web-server
/ browser architecture. We wanted to reduce deployment and update
problems, and we wanted to make applications available regardless
of the processing power and OS on the client PCs. I ran into most
of the problems you describe. I was stunned at how difficult it
is to implement simple Win32-type controls via http.
I'm reminded of this
almost every time I try to fill out an online form when I have
to scroll through a list of countries to "USA" and a list of states
Thanks for your
comments - it is always good to hear back from readers. Unfortunatly
many of the decisions on these matters are made by someone who
estimated the cost of maintaining and distributing client software,
and this may be a big number, but the cost of "difficult to program"
and "bad usability" are harder to measure.
The last column
was mostly about the usability issues, but I am considering doing
a follow up in a couple of months about the programming difficulty.
existed, it would need a number of modes to imitate all the different
browser versions. Programmers doing web sites accept code that
has very little static checking - if your C compiler gave you
the same behaviour you would be furious. There is also huge difficulty
involved once you have to allow for the interactions between HTML,
a C library to generate the pages, as is often used in embedded
Your article on web-enabled
solution for embedded devices, posted on embedded.com was helpful
to some extent. I have to develop a rich GUI for the device, installed
with Linux OS. I have already tried out with HTML solution, but
the page-refresh time is beyond acceptable criteria. Few of the
constraints I am bound with are,
OS : Linux
Flash Memory : 16 MB
RAM : 256
The web server and
Web-based GUI are required to run on the same device. Also device
can be controlled from the remote system, not necessarily > running
on Linux. The reason for choosing web-based solution is to go
for "write once and run anywhere" philosophy. And as you guess
the communication is over TCP/IP.
Pls. throw light on the right technology that can be deployed
with all constraints mentioned.
If they are on the
same device then the browser approach is bound to be expensive.
You have to run a web server (small resources) and a browser (big
resources) and all of the input/output for the application has
to be in html which is not great for controling a system (OK for
output only). and you still need XWindows or MicroWindows or something
like that, which the browser runs on top of (usually).
The biggest problem
with the page refreshes in HTML is that after each request you
have to update an entire page, you can not just refresh one small
piece in the middle that has changed, and leave eveything else
as it is.
What I would do
is the following, but please allow for the fact that I am not
familiar with all of the requirements of your system. Write the
application with a text based interface - call this process the
server process. You can then run the server from the command line
(unix shell) or get another process to control it. You can then
write the GUI process and commands (button pushes, slider changes
etc). get transformed in to text messages to the server. Replies
from the server get reflected on the GUI - maybe not as text.
The reply "speed=10" from the server may cause a bargraph to show
the speed on the GUI. If the data is more complex - say a graph,
then a series of numbers is passed.
The next question
is how to write the GUI. Well if you have XWindows or Qt or Microwindows.
you can use that API to write the GUI. It is a bit harder than
writing HTML, but usabilityt will be a lot better.
Now for remote clients:
If the client is also linux, then the same GUI can run, but the
text commands have to pass from one machine to another - easy
to do with sockets - the server will not even know that the requests
are now remote. Now for non-linux clients. If you have managed
to keep the text interface simple, and managed to keep all of
the hard work in the server then it should be very easy to write
a Visual Basic (or Borland C++ Builder, or Visual C++ or whatever)
client program that sends text messgaes to the server. You have
lost the "write once-run anywhere" properties of a web server,
but wrtiing a dedicated application will have far better results.
If most of the work is on the server, then writing and maintaining
these clients will not be difficult.
If someone is at
an unsupported client then they always have the option of telneting
to the linux box and using the text interface - assuming that
the text interface is usable for a human, which probably depends
on the complexity of the application.
If you still want
web access, then a web server sitting somewhere on the internet
could serve a page that sends requests to your linux box and converts
the replay into HTML, which means you still have a web interface,
though it may still suffer from the page refresh problems you
describe - but maybe not if the browser is now running on a Pentium-PC
with loads of resources instead of sharing a machine with the
This text based
server approach is the way GDB works - you can run it from the
command line, but there are plenty of GUIs (like VGD - Visual
GNU Debugger) which run by launching gdb as a process and then
running a GUI as a seperate process. If you press the "halt" button,
the GUI sends the "stop" text command.
In general I think
that you will find the "write once and run anywhere" philosophy
only really works for the simplest applications, and often creates
more problems than it solves. I have seen it justified in some
projects like network routers, where the web/HTML based interface
is for maintainence only, and the quality of the interface is
not of much concern to the customers.
I hope this helps