Reading
|
PanelSoft User Interfaces and Usability for Embedded Systems |
Feedback to "It's Worse on a Browser"- Murphy's Law, August 2001Hi Niall, 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 recognise keyboard shortcuts with a little custom Javascript. 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 at all. For more information,
see for example: Regards, 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. Andy Kunz Niall's reply: Andy, 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: 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. Hi, 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 applications. Chi-Wung Lau Niall's reply: 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" Mr. Murphy, 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 to "Illinois." Thanks again. Michael Hardt Niall's Reply 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. Things like JavaScript have no good debuggers, and even if one 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, JavaScript and some server side technology like JSP pages, or a C library to generate the pages, as is often used in embedded apps. regards, Hi Niall 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 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. Maulin. Niall's response 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 server. 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 some, Niall Murphy |
|
|