10 Things NetBeans Must Do to Survive
October 27, 2003
Update (November 16, 2003): Since this article was written, a new release of NetBeans, 3.6, has been announced - along with a completely rewritten windowing system. So a couple of items from this article can now be safely crossed off the list.
There’s a war going on out there. Java IDEs are battling it out in an increasingly intense struggle for developer mindshare. It’s depressing, however, that one of the most powerful of those IDEs, NetBeans, also seems to be the least talked about. That’s bad.
When I first started using NetBeans (years ago), the alternatives were a text editor with Javac, Visual Café (which sure crashed a lot – it was sometimes referred to as Visual Crashé), or JBuilder (which at the time was doggone slow, and doggone expensive). NetBeans stood head and shoulders above these “alternatives”.
However, the competition has been fast catching up for a while. In some cases it’s painfully evident that they have even overtaken, and left NetBeans chewing cud contentedly in their wake.
So with that in mind, I’m presenting some open-minded suggestions (in no particular order) for things that I believe NetBeans absolutely must do in order to remain relevant – not just that, but to leap back to the front of the pack, and stay there.
This shortlist is really based on a combination of personal frustrations with using NetBeans and programming the OpenAPIs, and observations of the IDE-related things that currently seem to make other programmers "tick". So from that point of view, it's a "personal" shortlist - but I've also tried to be unselfish with the list, and to base it on what I genuinely think the NetBeans project needs to do in the near future.
I should also point out that I'm actually a great fan of NetBeans, but here I'm mostly focussing on the negative things - because, well, that's what we do on this site...
1. Improve the windowing system
The windowing systems in both Eclipse and IDEA are lovely. They look the part, and they feel kind of groovy when you drag the windows around. When something this fundamental is just right, it almost doesn’t matter if the rest of the IDE is lacking in features.
The windowing system has historically been something of a problem in NetBeans. In earlier versions, every window – filesystem explorer, title panel, each Java editor and so on – had its own first-class window (clogging up the Windows taskbar). This was thankfully fixed. In more recent versions, if you drag an editor window across its shiny purple JInternalPane it judders painfully across, even on powerful 2GHz+ PCs.
The biggest problem, however, is that the windowing system just doesn’t work the way it should. We ran some usability tests at our company (because one of our projects is based on the NetBeans platform), and it was noticeable that several people were confused by the differences between “attaching” a window and “docking” a window. Why’s there a difference? To make matters worse, windows can also be made to “reside” in different places.
There should just be one operational metaphor, and all window operations should cling rigidly to that metaphor. Keep the windowing system as simple as possible, and keep it consistent! Ideally there shouldn’t need to be any menu options at all for manipulating windows (though it’s important to have them there as a secondary control, of course). The user should be able to “snap” windows next to each other, and drag them away again. Where appropriate, they should also be able to “drop” a child window inside a container window (e.g. drop a Properties panel inside the Explorer panel). Once it’s there, it should be easy to simply drag it away again.
At the moment in NetBeans, windows are a pain to manipulate. The menu options are non-intuitive, which is a shame because the only way to manipulate the windows is through the menus.
Another problem is that the windows love to jump out of the IDE and go exploring in the Windows desktop. Either it’s an MDI application or it isn’t. At the moment NetBeans sits in a sort of undecided middle ground, where it sometimes behaves as a “sovereign” full-screen application, and sometimes behaves like a cluster of separate windows.
The windowing system gives the impression that (along with the rest of the UI) it’s been designed by programmers. This wasn’t so bad when NetBeans was “just” an IDE, but now it’s also a platform for building other applications (not just for use by other programmers). Non-technical users are using the platform as we speak, and likely being horribly confused by the confused mess of a UI.
The good news is that the NetBeans windowing system is being rewritten for NetBeans 4.0. Apparently an early release of the new system will be available later this year – let’s hope it cuts it in all the right areas! The initial indication, from this interview on netbeans.org, is that the new UI has been designed by programmers again, rather than an independent usability expert. It seems that little thought has been given to the ways in which users will want to use the windows on a day-to-day basis. I’m hoping to be proved wrong though!
2. Improve Usability
Despite its great features, NetBeans isn’t always particularly usable. In fact sometimes, it can be really frustrating. I’ve covered the windowing system (which I really do find clunky and embarrassing); other issues include:
The Options panel. The options panel is, dare I say it, a confusing mess. Low-level NetBeans platform options are mixed in with application-level options. It’s very difficult to find what you want. Often you think you’ve found the options for a particular item, but it turns out to be just a declaration of that item’s existence! (There are moves afoot to improve the Options panel – these improvements can’t come soon enough).
Properties panels. Two problems spring to mind: first, there’s no obvious difference visually between the read-only left side of the panel and the writable right-hand side. The other problem is that when you want to edit something on the right, you have to click the field twice. Why? (To be fair, the Properties panel has actually been rewritten ready for 4.0, and in fact the new version looks amazing. I can’t wait!)
The GUI editor. The editor itself is fine, and in fact is one of NetBeans’ strengths. However, the default window layout just always seems wrong, and never seems to be in the same place next time you reload the IDE. Frustrating.
The wizards can also have a slightly clunky feel. Sometimes when you intuitively press Enter to confirm something or move to the next panel, the IDE just pings at you instead. (Also see the comment about keyboard use later in this article).
I could list several other UI “annoyances”, but this probably isn’t the right place. The right place should be the UI section of netbeans.org, but it doesn’t seem to have a huge amount of activity. True, the UI has improved in recent versions: but it still has a long way to go.
To survive, NetBeans really needs to focus on usability. That means approaching everything in its UI from a task-oriented perspective: analyzing what people are doing and why, and removing anything which detracts from those tasks.
3. Improve the Default Look & Feel
Unless there’s an unbreakable mandate from Sun that NetBeans must ship with the default Metal look & feel, the team really should follow the example of IntelliJ and ship with a UI that makes the first-time user gasp with joy and appreciation, rather than cringe at this ugly monster facing them.
You might think this is a trivial issue, but we programmers are surprisingly driven by form and aesthetics. It matters enough to make programmers like or dislike the IDE from first appearances – and that counts for a lot.
This problem might in fact be fixed with the release of JDK 1.5, which supposedly will have an improved default look & feel. They may even get rid of the intense, shiny purple background. We can but hope.
4. Keep Enhancing the Java Editor
The NetBeans crew are probably already thinking: “Jeez, there’s no pleasing some people!” In fact, NetBeans’ Java editor is already very, very good. I was using Eclipse recently, and found myself really missing some of NetBeans’ ease-of-use features. But there’s always room for improvement. Get complacent, and the competition will quickly overtake.
Additionally, because the Java editor is essentially the core feature of the product, it needs to be the thing that genuinely “wows” people. Its creators need to constantly strive to find new and innovative ways of making Java programming faster and easier (generally this means less keystrokes to achieve repetitive tasks).
So, this is a bit of a cop-out suggestion on my part because I don’t have anything specific to suggest – just generally “keep up the good work, but don’t stop there!”
5. Slow Down on the APIs
The NetBeans APIs are evolving at a rapid rate. This is, on the surface, a good thing, because it’s a sign that the product is continuing to develop, to have new features added, and also that it’s being redesigned internally to generally make it better.
The problem arises because it’s so darned complicated to find out how to do anything in NetBeans. The recently released NetBeans book [amazon.com], though useful and packed with detail, was obsolete in certain details before it even hit the shelves – the APIs are changing that fast. It’s even worse now that NetBeans 3.5 has been released, and the TopManager class has been removed. This means that nearly all the examples in the book don’t even work. Bad decision! (The examples can be made to work via openide-deprecated.jar, but a user who’s just bought the book to learn how to program NetBeans would not know this. Surely the stuff in the book should “just work”?)
Really, the team now needs to hit upon the preferred API format (XML seems to have become the preferred choice, allowing modules and UI elements to be plugged into NetBeans in a “declarative” fashion), and concentrate instead on the features. The APIs themselves should not have to change at such fundamental levels any more.
Additionally, somebody somewhere really needs to hit the “reset” button, move all the old documentation (including mailing list archives) out to an archive area of the website, and start afresh with relevant, up-to-date documentation focussed exclusively on the latest version. No historical baggage to overwhelm people who just want to find out how to customise the properties panel, for example. Version 4.0 should be a perfect opportunity to do this.
6. Make the APIs Simpler
This item conflicts with the previous one, because of course you can’t make the APIs simpler without fundamentally changing the APIs (and probably breaking backwards-compatibility in the process). But NetBeans would definitely benefit from a simpler API.
If NetBeans is supposed to be a suitable base for building new applications, it needs to be as easy as possible to build those applications. Currently however, NetBeans’ flexibility (a good thing) makes custom module writing a very complex task (a bad thing).
The main competitor for NetBeans in this area isn’t Eclipse, as you might think – it’s simply “rolling your own”, building a Swing application from scratch, adding in APIs as needed rather than building on top of a core platform of APIs. If you’re building a complete application rather than a plug-in module, then currently it only really makes sense to build on top of NetBeans if your application is also a type of IDE.
Currently a lot of classes need to be extended just to do fairly simple things (like define a custom file type and launch the file into its own editor). It would be nice just to be able to define, say, a MyFileType class and a MyFileEditor class, and bob’s your uncle. Unfortunately there are a lot more hoops that need to be jumped through.
Cookies and actions are another area that could do with being simplified. Much of the time, the extra flexibility given by these loose-coupling design patterns just isn’t needed. Of course, the problem then is that some programmers do need this extra flexibility: so it shouldn’t be removed entirely, just moved further into the background.
Another issue is that there is an awful lot of crossover between the APIs. From an aspect-oriented perspective, “concerns” twist and turn through the different APIs like ribbons, with no respect for boundaries. To use the previous example of loading a custom file, this relatively simple process involves trekking through various classes in the Filesystems, Explorer, Nodes, Datasystems, Actions and Window APIs to get the job done.
By “ClosedAPI” I don’t mean that it shouldn’t be possible to extend the classes: rather that the complexity of its parent OpenAPIs should be closed off, hidden from view until the user needs them. So for example, opening a file could simply use an abstract DefaultFileType class that has two public methods, open() and close(). The complexity – including the node representation, custom file loader and so on – should be encapsulated away, but exposed via protected methods so that the user can still get to them should he need to.
If this “ClosedAPI” is clearly delineated as a separate API, then new programmers could be pointed to it, and there would be clearly defined boundaries of what they need to know in order to get productive quickly.
One possibility – which solves the above issues – would be to add a simplification layer in front of the OpenAPIs, so that “power coders” who need this extra flexibility don’t have to lower themselves to a stunted, Visual Basic-style API (from their perspective). For the rest of us, a much simpler “ClosedAPI” would suffice a lot of the time, and sure would speed up development time (not to mention reduce maintenance costs as there’s less code to maintain, and reduce training time to get new recruits up-to-speed on the requisite APIs).
Most of these classes should extend what’s in the OpenAPIs, and for the most part should simply provide a default implementation of the stuff that we mostly find we have to implement regularly for various tasks. That would make it easy for the user to override whatever bits they do need to customise.
7. Lose the “NetBeans is slow” stigma
Version 3.5 primarily addressed performance and responsiveness issues. And in fact, today’s NetBeans really isn’t too shabby when it comes to that “snappy” feel. But the stigma still remains. Mention NetBeans in a crowd of Java programmers, and the first response will probably still be: “Ugh, slow!” So the slowness stigma is more to do with image and perception than with actual slowness.
In fact, now that NetBeans actually is faster and more responsive, the remaining stigma could be addressed by making the UI more aesthetic. If it “seems” whizzy, then users will simply appreciate it more.
Similarly, keyboard use should be examined more closely, and attempts made to make the UI more usable using only the keyboard, with as few keystrokes as possible. This means the input caret going to the right place after the previous option was selected. The user will love you for this simple courtesy. And he will get the impression that the IDE is more responsive – because it takes him less effort to get things done. An example of where NetBeans gets this right is when you load a new file into the Java editor. The input caret goes into the editor window, ready for typing without an additional mouse click. But there are loads of other places that should do the same thing, but which don’t.
Plus, on a practical note: on startup, the IDE has lots of stuff enabled by default, which makes startup slower. Much of this should be switched off until the user asks for it – Tomcat especially.
8. Offer built-in refactoring support
The competition has leapt ahead of NetBeans on this one.
Developers have been clamouring after this for a while now. The response on the NetBeans-users mailing list has been that it isn’t that big a deal, and anyway there’s a commercial module available that you can pay for. Refactoring is increasingly a fundamental ingredient of modern programming, and programmers are rightly demanding refactoring tools as a basic standard part of their IDE. Test-Driven Development (TDD), which makes heavy use of refactoring, has been popularised by agile methodologies (particularly extreme programming). People nowadays expect their IDE to offer refactoring as standard. If it doesn’t then the IDE just seems incomplete.
NetBeans already has excellent support for JUnit, so it’s a real shame that they seem to be ignoring refactoring.
9. Make More Noise
No one’s really talking about NetBeans in the industry. However, everyone’s talking about IDEA and Eclipse. It’s depressingly noticeable. The release of RAVE might help, but then people will be mostly talking about RAVE not NetBeans (even though RAVE is based on NetBeans).
NetBeans needs more press releases and interesting projects (refactoring springs to mind!)
Eclipse has “bagged” the prestigious AspectJ open source project (even though it isn’t in any way exclusive to Eclipse). NetBeans badly needs to get on the aspects bandwagon. An AOP module, for example, could allow debugging of aspects in some innovative new way. Aspects could also be woven into the NetBeans platform. If it’s built from the ground up with aspects, then NetBeans development should generate developer interest in all the right ways.
People also need to be made aware of just what NetBeans is already capable of. The existing projects need to be highlighted more often. We should be seeing articles like “Unit testing with NetBeans” in programmer magazines.
10. Stop using that… brown colour scheme on their website
The colour scheme is more important than you might think. It isn’t really a matter of taste (some people are bound to chime in that they like the brownness). Instead, it’s a matter of image. NetBeans needs to put forward an image of hi-tech, modern, cutting-edge software development. The brownness just doesn’t help.
This was an affliction that used to affect Java itself, until Sun apparently caught on and moved away from the brownness. The connection was probably Java coffee beans… brown. And probably the same thought process has gone on at NetBeans.org. Unfortunately, the brownness just makes the product seem old-fashioned. It’s great to be different, but not at the expense of your product’s “street-cred.”
NetBeans has the apparent advantage that it’s the official Sun Java IDE. However, this isn’t that big an advantage in reality. Programmers will just use whatever IDE they feel “hits the mark”.
A big advantage that NetBeans does have is that it’s still a great IDE. It’s full-featured, well integrated, has good built-in support for CVS, XML, Ant, JUnit and so on. It’s also a decent base on which to build a better IDE. Given what the IDE is already capable of, the suggestions in this article might seem almost trivial. However, they’re also the reason why NetBeans is rapidly losing both market share and developer mindshare.
The NetBeans developers (for whom I have a huge amount of respect) need to focus on the right things in order to bring NetBeans back to the head of the pack.
<< Back to Soapbox