Back in my OpenView days I can remember when the first web-based user interface for Network Node Manager came out. People were pretty excited since you could then access OpenView from your desktop without having to use Hummingbird or ReflectionX. It wasn’t very good and didn’t have all the features but it was good enough for some tasks.
But I’ll make the claim that it never got better than the native X11 client.
Now granted, I haven’t really worked with OpenView for many years, and in that time both that product and web technologies have improved, but sometimes I have to wonder if writing a web-based user interface is worth it.
The OpenNMS webUI has long been a weak point for the OpenNMS product. Part of that has been philosophical – the idea is that people are busy and thus having a robust and powerful notification system is more important than a user interface that you put up on a big screen, but also part of that has been that good webUIs are hard to write.
Recently some people have been reporting errors in the webUI that we can’t reproduce. We finally nailed it down to Internet Explorer 7. Something changed and now some of our code breaks on that browser. It used to work, and it works on all the other major browsers, but something changed to break it. It’s hard to write to such a fluid platform.
Also, there is the question of state. Ultimately people navigate in a browser via URLs. Someone might go to a particular page in our webUI, bookmark it, exit the browser, upgrade, reboot, turn off the system, go on vacation and when they come back want to go to the same URL and get the same exact information. It is difficult, and sometimes impossible, to make that work all the time.
Another reason we’ve been thinking about the webUI recently is due to a project we are doing for a client in Italy. OpenNMS has proven itself able to monitor tens of thousands of interfaces, but now we have a client with tens of thousands of interfaces on a single device. It’s pretty crazy. In order to display that information on a node page we’ve started using Ext JS. Also, a lot of work went into making the code perform well (by tuning the database queries, for example) with all of those interfaces.
We’re trying to use it throughout the webUI, such as on the front page for the resource graph drop down.
But I keep asking myself why we bother. Why not just make a Java client? Using webstart we could download it through a browser, and now with JavaFX it is even more transparent since you can “easily drag-and-drop a JavaFX application from the browser to deploy to the desktop”.
The feature list for OpenNMS 2.0 has always been focused largely on the user interface, and I’m pretty certain that JavaFX will be the way to go. It will allow us to deliver a richer user experience with less complexity on the programming side. In order to get there we have been adding RESTful interfaces to all of daemons (via jersey) which will expose all of the information that OpenNMS has to pretty much any outside source, including the user interface.
We are sometimes criticized for writing OpenNMS in Java, but in our experience nothing else out there can provide the same level of scalability (think hundreds of thousands of managed objects) while minimizing the programming effort.
When I was in college I used to tinker with old Mercedes-Benz automobiles. I’d buy them for around US$1000 and rebuild them. I’d start with the engine, then the brakes, then the electrical system, etc. The last job of any restoration was the paint.
However, being in college, I would usually run out of money before I got to that stage and I’d have to sell the car. Having a poor paint job always made it harder to sell – people were not concerned that they could get in the car and drive it across the country – they saw dull paint and assumed it was worth less.
I think OpenNMS gets the same treatment. The mechanics of OpenNMS are solid and proven, but since the webUI isn’t flashy it gets dismissed.
With Sun’s new open source focus and tools like JavaFX we should be able to put a nice new coat of paint on the OpenNMS user interface.
Hi Tarus,
In general, UI is indeed the biggest time pit in most projects I’ve been involved with. and Web based UI development is difficult to say the least. UI is subjective, takes a lot more time than expected, etc.
Nonetheless, as you’ve pointed out, it has a big impact on people’s impression of a product software or a car (now anyone who buys a car just based on color of the car?) hence it is important.
We’ve dealt with all of the scale issues you mention, you can handle them in a web UI but it takes a lot of time and expertise to get it right. We had also started with available ajax components (YUI) but had to tweak them a lot to make them work with large data. So the approach we’ve taken is to create components that work with large amounts of data comfortably and reuse these components in building different web pages.
I don’t think JavaFX will be a good solution but time will tell. I love Java on the server but it’s a whole different story on the client. They just don’t work well with other web apps etc. If your users will only use your app and don’t need to integrate it with other apps, then it may work. Still, regardless of the technical merits, my guess is that it will not be attractive to people.
I would think the lessons are clear …
… cosmetics matter to the rest of the world more than they matter to folks who like to tinker with the engine.
… works great .. not too tough … looks great .. not too tough … works great *and* looks great … very tough!
… get to the paint early, before you run out of money!
Good luck with the problem that got this post started!
Tarus,
We must have had the same experiences with NNM.
On the X11 interface front, NNM and eHealth both had outstanding UIs. I am still niggling the devs in IRC when I can and opening enhancement bugs to get the WebUI to those levels. I think an area that OpenNMS falls short (and prevents adaptation for a lot of folks who otherwise would be tickled by OpenNMS’s power) is that ease of use UI that some of the commercial products, at least in the past, had in spades.
I tinker with Toyota Land Cruisers. They are pretty bullet-proof but aren’t the most sexy beasts out there. They are often misunderstood in that they were always designed to go slow very well, at least until Japan caught onto the American luxury SUV trend in the late 80s. Nothing on the planet is better built or as trusted in harsh environments as African Serengetti, Australian outback, Iceland, South America, or anywhere the UN/Red Cross operates.
I guess that is what drew me to OpenNMS too.
JavaFX is painfully slow for now. Perhaps in near future it would be an appropriate choice. But presently it’s not a contender IMO
I have small write up on RIAs here
http://hatimonline.com/2008/12/19/battle-of-rich-internet-application-clients
Well, I like the current GUI: its easy to use and fast. And although I am not a programmer I would expect you will get similiar problems like the one with IE7 even when using a Java GUI. Just think of the different types of JREs out there …
Anyway – I would suggest you to make this design decision based on your technical needs and possible technical improvements rather than just to have a more nice GUI (“more colors”).
At my current employer, we’ve started to switch away from a Liferay portlet-based system, and towards a AIR + Flex environment. It’s cross-platform (well, I don’t know about OS X, but the devs are on Linux, and the users are on Win32), lets us utilise all of the back-office application server and workflows that were written for the portal system, gives the user a much more friendly interface, and apparently can be made to work inside of a browser as a Flash object (we use it as a standalone application right now).
Is it the right answer for OpenNMS? I don’t know. I’ve heard some pretty good swearing from the R&D guys when they were evaluating Flex – it’s still fairly new, and has some quirks. The beauty of the ONMS interface is that it works in a web browser. The downside to the interface is that it’s web based, and thus missing some of the abilities of a thick(er) client.
Potential benefits of a thicker client (and support code):
* It can act as a real-time monitor if a two-way connection is maintained
* Client side data validation – doable with JS in a browser, but possibly more thorough in a thicker client?
* Custom thick clients (or web interfaces) become easier with a published interface
* It’s thicker, thicker is good, right?