Review: NetBeans 3.6 Usability

Product: NetBeans 3.6 Reviewed by Matt Stephens May 23, 2004

NetBeans 3.6

This review follows on from our earlier review of the revamped NetBeans 3.6 user interface. That review was based on a very early development build. So, now that NB3.6 has been released and we've all had a chance to use it as part of our development work, let's revisit NetBeans and see how the "proper" 3.6 release fares.

Note that this is more of a usability review than a feature review. NetBeans is big on features (here's a list of what's new in 3.6 - it's impressive). The feature list is one of NetBeans' major strong points. So if we take that as read, let's focus on the areas of this powerful IDE that really need improvement. Usability, despite some recent steps in the right direction, is still depressingly high up on this list.

My overall feeling is that NetBeans 3.6 is a big improvement over the previous version, 3.5.1. The difference in the “feel” of the IDE is just phenomenal. It’s unfortunate, however, that certain vital things haven’t yet been addressed – and that NetBeans has even taken a step backwards in one critical area.

Some of these issues will no doubt be fixed in 4.0; but (despite all their great efforts) the NetBeans team need to do better, because, in terms of which IDE people simply like, the competition is leaving them for dust.

JSP Compilation vs JSP Validation

With the release of 3.6, the NetBeans team made the highly controversial decision to remove JSP compilation support. Appalled developers were quick to voice their disgust at this decision to move backwards. Support for JSP development has always been one of NetBeans’ strong points, so to play around with this area of the product was a brave move to say the least.

In place of compilation, 3.6 offers something they've called "JSP validation". However, this alternative is useless for developers who put Java scriptlets directly in their JSP pages.

For example, the scriptlet

request.getParameer("...")

(‘t’ is missing) would fail compilation (as you’d expect), but surprisingly passes JSP validation with flying colours.
The “official” word from NetBeans Towers is that no one uses scriptlets in their code any more; we all use Model 2 architectures, Struts and so on. So what’s the problem? The problem is, a huge number of developers still do use scriptlets. You don’t always want to completely separate the Java code from the JSP page (despite what ivory-tower purists would insist).

This document on the NetBeans website provides some insight into their reasons for axing JSP compilation.

To summarise, supporting JSP compilation for plug-in server modules was proving difficult and time-consuming, so they decided to get rid of it. Never mind that it was one of the most useful features in NetBeans, and for many people the reason for using NetBeans over its rival IDEs.

To find out whether your JSP page compiles, you have to actually deploy it onto the server and make it compile there by requesting the page through a web browser. This process is fairly quick in NetBeans, but it's still slower than simply hitting F9 and immediately finding out what's broken. In our world of agile development, the feedback loop needs to be kept as short as possible.

The NetBeans crew has indicated that they might reinstate JSP compilation in NB4.0 (and possibly as a plug-in module for 3.6 in the meantime), as there was such an outcry over its removal. For some, however, it may be too late, as the removal of this key functionality from the IDE left a nasty taste in their mouths. There's always a rival product beckoning enticingly at disaffected users...

JDK 1.4

With 3.6, the NetBeans team has made the bold decision to support only JDK 1.4 and higher. That’s fine by me – the JDK is a free download, after all. If you’re working in a corporate environment that doesn’t allow downloads of recent software until they’ve spent a couple of years testing it, then this gives you a good excuse to buck their ideas up, or find a better job where you’re allowed to play with recent technology.

The IDE also works nicely with JDK 1.5.0 beta, but doesn't yet provide 100% support (e.g. code completion). This is set for the NB4.0 release though.

Editor Tabs

Editor tabs can be split using drag & drop

Tabs – much better! The ability to re-order tabs by dragging them around is especially nice. Also, it's great that you can now split the editor window (so you have two or more editor windows showing) simply by dragging an editor tab to a different part of the screen.

There are still a few usability issues though. For example, not allowing the user to configure tab placement (top or bottom of the screen) seems quite high-handed. When the rest of the UI is so flexible and “drag-and-droppy”, it’s a shame that such a dominant feature of the UI is cemented in place.

It's possible to close all tabs by right-clicking on an open tab and choosing "Close all tabs". However, the IDE could also do with a “Close all tabs except this one” option on the pop-up menu. Also, if you have two editor windows side-by-side (each with several tabs open), choosing "Close all tabs" on one of them also closes all the tabs in the other window. Really, the "Close all tabs" action should just be limited to the particular window where you selected it.

While I'm at it, a Close button on the far-right of the tabs would be nicer than having a little “x” on each tab. (See the Firefox browser for an example of how much nicer this can be). The little “x” “buttonettes” can be very difficult and frustrating to line up with the mouse cursor, as they’re only a few pixels across. I often find that I’ve accidentally selected the tab rather than closing it – pretty much the opposite of what I was trying to achieve.

Form Editor

The GUI form editor used to be great (and it also used to be one of the only Swing GUI editors around). But it hasn’t been developed any further for years, and now it’s showing its age. I describe some of the improvements that need to be made in this article [Swing survival guide]. Thinking about how great the GUI editor could be, it’s a real shame that it’s been left untouched for so long.

The form editor is particularly difficult for working with inheritance. If you have a bunch of panels that override a common parent panel, this can become very problematic, because NetBeans simply doesn’t allow you to do this via the form editor. Instead you need to layout the form first, then turn it into a normal class (basically delete the .form file), and do all the overriding manually. It would be great if NetBeans recognised that forms can extend other forms. This means the editor would need to read the parent .form file, and place the parent form as a set of read-only components into the child form that you’re editing.

Component properties seem to be randomly ordered. They’re not alphabetical, but they also don’t seem to be in any particularly obvious order. For example, the “size” properties (minimumSize, preferredSize and MaximumSize) are scattered around. This sounds like a minor gripe, but I quickly found that locating properties became very frustrating when trying to do real work with the form editor.

The form editor layout also isn't quite right. My favourite layout is to use a split view, with the form editor at the top and the code editor at the bottom. This makes sense to me, as I’m never using just the form editor on its own: I’m constantly switching back to the code, e.g. to edit event handlers. While it’s possible to set this view up with NB3.6, it’s a bit fiddly. You have to click over to the source tab, drag it down to the bottom half of the window, then click back to the form editor tab. Trouble is, if you click to other source tabs, the split view remains. Ironically, this was easier in NetBeans 3.5.1 where the form editor had its own workspace, so you could layout the editor windows exactly how you wanted.

It would be much easier if NetBeans provided a “show form editor as split view” option, so it just automatically shows the correct source window for the form currently being edited.

I generally try to avoid mentioning specific bugs in these reviews, as it doesn’t seem fair to the development team. But in this case, the form editor contains a really nasty bug that keeps cropping up. Quite often, I find that I suddenly, without warning, can’t save my work due to a NullPointerException. Several times I’ve lost unsaved work due to this. For a defect as nasty and obvious as this one to make it through to the full release, is, well, pretty bad to say the least.

Mousy See, Mousy Do

The action following a mouse-click selection is on the mouse-down event, not mouse-up. This is a depressingly common error in some GUI applications, and it makes mouse-drag operations much trickier than they need to be.

For example, if you want to drag a source-editor tab onto its GUI editor panel (to create a split GUI editor/source view), it would make sense to start on the GUI editor panel and simply drag the source editor tab onto it. But because the tab selection action takes place on the mouse-down event, holding the mouse down to drag the tab instead results in the editor window switching over to the source editor. The action should take place on the mouse-up event instead!

The same problem also manifests in a particularly annoying way, if you want to move some files into a different folder. Normally you would ctrl-click to select your files, then hold the left mouse button down, drag the files over to the new folder, and release the mouse button. Unfortunately, because NetBeans acts on the mouse-down event and not mouse-up, beginning the drag operation causes the files to become deselected. This can be very frustrating. Try the same thing in Windows Explorer to see how it should work.

"The action takes place on mouse-up, not mouse-down" is a golden rule in UI design. This principle was established well before the days of Windows. For example, back in the Amiga days the principle was called "release verification": you had to release over the target to confirm. Mouse down was not enough.

When you're aware of it, you start noticing this issue all over the place. Unfortunately, NetBeans gets this one consistently wrong, resulting in an IDE that is more difficult to use than it needs to be.

Other Stuff

Finally, here's a mix of random other observations on usability in NB3.6, which don't really fit into the other sections.

“Highlight caret row” (where the line that the text cursor is currently on is highlighted) should be enabled by default. It’s the sort of feature that gives a good first impression, and makes the editor feel polished. So disabling this feature by default just seems odd. Same goes for the text antialiasing option.

The File Search dialog has been integrated into the Output window at the bottom of the screen – it's much nicer this way.

The options panel, although it hasn’t changed much since the last release, seems a lot neater on first startup. As you open up the tree view though, it quickly becomes a mess – hence difficult to find anything. There’s just too much stuff piled arbitrarily into one window. One possible solution would be to create context-sensitive options. For example if you’re in the Java editor, choose Options – NetBeans would somehow magically detect that the Java editing module has the focus, so it filters the Options view just to show options specific to the Java editing module. (There would of course need to be a “show all options” checkbox, in case you’re after some other option).

Conclusion

NetBeans is improving, but (as described in this review) there are still several embarrassing errors in terms of how the UI works. If these could be sorted out then the IDE would become much more usable. The UI design errors highlighted in this review demonstrate that while the NetBeans team sort of get by (and are obviously expert programmers), they're not experts at user interface design. It really does show through in the product.

It's difficult, but the NetBeans team should swallow their pride and bring in a high-profile interaction design guru such as Alan Cooper. If they really want a product that users love to use and love to evangelise about (like the super-faithful and super-loud devotees of Eclipse and IDEA), this simple act would seriously help to turn the product around.

Related Articles:

Sun Java Studio Creator Early Access

User Interface Design Should be a Team Effort

Toolbars in the Dock: Are Dockable UIs All They're Cracked Up to Be?

Recent book reviews:

Refactoring: Improving the Design of Existing Code (Martin Fowler)

Use Case Driven Object Modeling With UML: A Practical Approach (Doug Rosenberg, Kendall Scott)

The Inmates Are Running the Asylum (Alan Cooper)

Message Forum:

Agree/disagree with this review? Please add your comments below!

Post a new message

Good review
Tim Boudreau tboudreau@sun.com
Heap Size in NetBeans 3.6
Jehan Zeb Shah zebjehan@gmail.com
re: Heap Size in NetBeans 3.6
Matt Stephens 

Post a new message

<< Back to Reviews

<< Back to the Front Page