Programming with
a dose of satire.
| Articles |
|
Geek Fiction Lifecycle Design Programming Soapbox  Reviews |
| Use Case Driven |
 |
| Agile UML |
 |
| Get Controversial! |
 |
|
| ||||||||
 |
 |
|||||||
|
Reviews |
||||
Review: NetBeans 3.6 New Windowing System
For years, the NetBeans user interface has been widely criticized as clunky, unintuitive, wasteful of space, generally not behaving the way it should, and so on. NetBeans 3.6 (due in March) aims to change that. In fact, the windowing system has been totally rewritten. This accompanies a new-look properties panel. Both of these new elements really "look the part". But do they address enough of the shortcomings of the system they're replacing? A quick overview of the new windowing system (including screenshots) can be found here. Until recently, there was never going to be a version 3.6 of NetBeans. After 3.5.1 (released back in July), the next release was going to be the "big one", 4.0, which is still a long way from being finished. Meanwhile, the competition is eating away at NetBeans' market share. So Sun/NetBeans wisely decided to introduce an earlier release, 3.6, to get the windowing system "out there" as soon as possible. This should also give NetBeans a fighting chance of competing with its rivals (IntelliJ/IDEA, Eclipse, JBuilder and so on). I like to think that the NetBeans crew read this recent article, held a council of war, and decided to bring forward the release of the new windowing system. But it's more likely that they just woke up and smelled the coffee for themselves. At the time of writing, a very early development build of NetBeans 3.6 can be downloaded from here. It's only just been integrated into the main codebase, so is understandably more than a little bit flaky at this stage. So this review doesn't focus on the bugs (that wouldn't be fair). Instead we concentrate on the UI enhancements, and question whether they "make the grade" (especially given the high quality of the competition).
Overview of the new UI When analyzing a new user interface feature, it would be a mistake to treat it as an isolated component - especially an item as fundamental as the windowing system. Therefore we need to look at the user interface as a whole, and look at how the windowing system affects it. The first, really noticeable difference is that the Workspaces are gone. These always struck me as a bit clunky anyway - and they took up a lot of screen real-estate. So their disappearance is welcome. Instead, when you open up a particular type of editor (e.g. GUI editor) the required windows for that editor appear. Much simpler! The status bar (which used to be situated to the right of the Workspace tabs) has been moved to a new panel at the bottom of the IDE window. So in reality, there probably isn't any actual gain in screen real-estate. But it just feels as if there's more room now! Keyboard navigation has obviously been given some thought. For example, it's easy to switch between editor windows via the keyboard. The current editor can be maximised by pressing Shift+Esc - a nice touch. An important new development is that by default, NetBeans 3.6 starts up using the platform's native look and feel. So under Windows XP, it'll use the WinXP look & feel. Those who prefer the old Metal look & feel can still configure NetBeans to use this instead. It should be noted, however, that the new window and properties panel components don't seem to vary very much (if at all) with the look & feel. If you switch to Metal, the window system still looks very much like Windows. For example, you don't get the "rubber grip" effect on handles, scrollbars etc. This may or may not be a bad thing depending on your point of view (whether you like or dislike Metal, for example). However, this is an initial bad sign - that the new UI components are distinctly non-standard, and don't conform to the look & feel. This immediately defeats one of the more important selling points of Swing - that you can switch look & feels to look like the native system you're running on. A really nice development would be if Sun's Swing team picked up these new UI components and incorporated them into the javax.swing package (with improved look & feel conformance, of course).
Common Tasks Let's examine some basic day-to-day IDE tasks, and see whether the new UI helps or hinders us in achieving these tasks. Task 1: Switch rapidly between 30-40 open editor windows I can see this task raising a few chuckles, but a lot of people do work this way, and with good reason. When working on a large project (or just working very fast), it's more important to quickly switch between Java files (without interrupting your thought process) than to pause and do some window/tab management (close current tab, search the explorer for the next file, load it up and so on). The main problem with this approach (or at least, with NetBeans' support of this approach) has always been that the multi-line tabs swiftly accumulate. They grow and grow in height, until they take up more room than the editor window itself. Then you end up with a keyhole display of the Java source, and a big mountain of tabs beneath it. The approach in NetBeans 3.6 is simple: don't allow the tabs to spill over more than one row. Instead, left/right arrow buttons appear on either side of the tab area. There should really be an option to switch back to multi-line tabs for those that prefer it, but if there is such an option I couldn't find it.
Strangely, there are two sets of left/right buttons for scrolling the tab row. The set on the right (circled in red on the above screenshot) behave as you'd expect (simply scroll the tab row left or right). But the other set (circled in yellow) behaved very strangely. With lots of editor windows open, try predicting which editor will open up next when you click the left or right button. You can guarantee that it won't open the one you predicted. A much better approach would be to not actually open a different editor when you click the left/right buttons. I was actually surprised when I clicked the right button and a different editor opened up. The left/right buttons should simply scroll the tab row left or right. Then to open a different tab, simply click the relevant tab once it's scrolled into view. Of course, scrolling through 30 or 40 open files would soon become incredibly tedious to say the least. Luckily, if you want to access another file that's open but not currently visible, there's also a new "open files" list, alphabetically sorted, which pops up to allow you to open the new file. Not everyone will like this new approach (particularly the loss of multi-line tabs), but I found it to be a neat (if slightly quirky) solution to the "tab mountain" problem.
Task 2: Open two Java editors side-by-side In every version of NetBeans until 3.6, this has been a surprisingly difficult thing to do. Sure, the window system could cope with it, but the UI was so clunky that you had to feel your way through lots of unintuitive steps to get to the point where you finally have two Java editors side-by-side in the same window. In NetBeans 3.6, the process is much easier. The new windows have great support for drag-and-drop. So the new process is as follows: Open both Java files so their editor tabs are side-by-side. Drag the tab of the "inactive" editor somewhere onto the active editor's window. If you want the split to be vertical (left and right panes), drag the tab to the left or right. If you want the split to be horizontal (top and bottom panes), drag the tab to the top or bottom.
It couldn't get much easier than this. Well actually, one simple enhancement would make this even easier: the ability to drag a file from the explorer window directly onto the editor window. If you drag onto the editor area, the editor should split; if you drag onto the tab area, the file should simply open into a new editor tab. The new UI really invites attempts at dragging & dropping various things. The dnd windowing system creates a real feeling of a dnd environment. Unfortunately, it quickly becomes evident that only a few parts of the IDE have drag & drop support. The rest blithely ignore your attempts to drop an object on them, and respond instead with the impolite "null target" mouse pointer. Result of these frequently occurring little disappointments: the user will quickly start to resent the IDE more than they love it.
Task 3: Split the same editor so you can view different parts of it simultaneously I was expecting to catch the new UI out with this task, but it was surprisingly easy. Just right-click the current editor tab, choose "Clone Document" (gives you a second tab with the same name), then drag the inactive tab onto the active tab, as in the previous task. Easy!
Task 4: Change a property In previous versions of NetBeans, the properties panel has always been a bit clunky. You have to click it twice to edit something. Thankfully, the new version is a lot nicer to use. Single-click property editing at last!
Task 5: Check What Project You're In This is a strange one. Up until NetBeans 3.5, the project name was shown in the main window title. Bizarrely, in 3.5 they removed this. Now (unless I've missed something) there's no obvious way of determining which project is currently open. This still appears to be the case in this early development build of 3.6. A lot of IT projects are of course very large and complex. In such projects, teams split them into multiple "sub-projects", each represented as a single project in the IDE. As a result, it's important to be able to see at a glance which project you're in. Why this useful snippet of information was removed from the NetBeans title bar is a mystery.
Task 6: Quickly Open an External Source File This one's easy: if you're in Windows Explorer, just drag a text file directly onto the NetBeans editor window and it opens up. Well okay, that's just wishful thinking. In reality NetBeans just responds with its usual "null target" mouse pointer - as if the IDE is pretending to look the other way when you're trying to get its attention. Currently to open a file that's not mounted in the filesystem, you have to either mount the directory as a new filesystem, or open the file via File.. Open File. This leads to the Java file dialog, which then requires you to navigate to the file you wanted to open. This can be really frustrating when the file is right there in an adjacent Windows Explorer window. All this shortcoming does is highlight the lack of integration between NetBeans/Swing and the native operating system - but it's a problem that would be very simple to solve, with just a little more thought.
Task 7: Mount a filesystem Usually when working with a project in NetBeans, I've just created a new directory to house the source files (via Windows Explorer). Next, I launch NetBeans and use "Mount filesystem" to access the directory just created. The obvious thing to do, then, would be to drag the new directory from Windows Explorer onto the Explorer panel in NetBeans. As usual, though, this is met with the "null target" mouse pointer, and NetBeans pretending to look the other way, whistling nonchalantly. Instead, I have to right-click the Filesystems root tree node, choose Mount Filesystem, and navigate all the way to the new directory - even though I can see it right there in the Windows Explorer window. This lack of integration is a common malaise amongst many GUI applications. But that's definitely no excuse to skimp on drag & drop support (not to mention other forms of GUI shell integration).
Conclusion The new NetBeans UI is a vast improvement over the previous version. I can't stress enough how big an improvement this is. Viewing the IDE now, it's like it is NetBeans, but it's not NetBeans. It's uncanny. The new UI isn't perfect by any means: there's still room for improvement in terms of user interaction. In other words, the user's life could still be made easier (and thus their coding tasks made more efficient). But even so, hats off to NetBeans for such a big improvement. NetBeans is once again ready to play with the big boys. Given the magnitude of this change, the NetBeans team will have their work cut out to get this production-ready, even by March 2004. Although there was never supposed to be a 3.6 release before 4.0, they would be wise to plan for a 3.6.1 maintenance release as well.
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! Message Index:
The Messages: Re the multiple arrows and L&F of the property sheetI did the rewrite of the property sheet and collaborated on the componentry & look and feel for the new window system, so I'd like to share our plans with regard to a couple of the issues you brought up: Multiple arrow buttons at the top of the editor: The left and right buttons that are part of the tab row are intended to represent "clipped" tabs - a tab partially visible and partially not. Clearly this doesn't work if they don't look like tabs, though. In fact, on Metal and XP look and feels you will see partial right-hand tabs. The initial UI spec for Windows classic which your screen shot is of was designed slightly differently, hence the pseudo-arrow button on the right in Windows classic. At any rate, these will be made consistent in the near future and it will be done in a way that it's obvious that the things on the right and left are tabs, not buttons that do unpredictable things. Re the look and feel of the property sheet: I have a bunch of work in progress on a CVS branch to bring it into line with the look and feel - this work is almost finished, so that will be showing up in development builds within the next month or so. The truly industrious can follow the instructions at http://www.netbeans.org/issues/show_bug.cgi?id=31896 to build it now. This is great feedback! Particularly the idea of dragging files from Explorer to the editor is a good one, and that never would have occured to me (probably because I'm so used to the way NetBeans works after four+ years of working with it). It's a wonder what a fresh set of eyes can find! Best regards, Tim Boudreau Tim Boudreau tboudreau@sun.com Prague, Czech Republic Mon Nov 17 22:24:43 GMT 2003 re: Re the multiple arrows and L&F of the property sheet Hi Tim, Thanks for the reply. I'm glad the review turned out to be useful! After this, probably the only "essential" item that NetBeans still lacks is built-in refactoring support. I know a lot of programmers who prefer to pay for IDEA, so that they get this feature as a core, integrated part of the IDE... Matt Stephens London, England Tue Nov 18 13:05:40 GMT 2003 New UI outside Netbeans..? Hi All, The new look and feel is much better. My question is... Can the new UI components be used outside of netbeans for other apps ? (ie. Docking etc..) License wise is this ok ??? Finally is anyone testing this new version against the 1.5beta ?? Thanks Andrew Andrew Tierney andrew@castlesoft.com.au Australia Thu Nov 20 22:53:32 GMT 2003 re: New UI outside Netbeans..? You can build on top of the NetBeans framework by basing your code on the "platform" build. The platform is basically NetBeans with all the Java editing stuff taken out. Their licensing allows you to use this in your own applications. See http://www.netbeans.org/products/ for more info, and http://www.netbeans.org/downloads/platform/development.html for the download... Matt Stephens London, England Fri Nov 21 13:34:56 GMT 2003 Knowing the current project. I agree with you, the current Project should be easy to find. There is a work around until this is fixed. Go to Window >> Project to open the Project window. The title on this window will say "Project Something". Even if you hide the window as a tab next to Filesystem and never use it, at least you can look and see what the current project is. Dan Martin dmartinREMOVETHIS@ANDTHISdmartin.org Saint Louis, MO, USA Fri Nov 21 16:50:15 GMT 2003 Reusing the winsys License wise, it's no problem. Certainly you could do it - I don't know how much work it would be to do so - the window system is tied to NetBeans concepts like TopComponents (top level components that can affect the current contextual selection) and docking modes (generally, tabbed containers representing places you can put TopComponents). So I don't know how much of NetBeans infrastructure you'd need to drag along with you to do it. At the same time, NetBeans makes a good platform for building non-IDE applications, and if you use it, you'll of course, have the window system along with it. Re testing it on 1.5 - yes, I've been running NetBeans recently at work with Sun internal builds of 1.5. Other than the java parser getting confused, everything's been working well enough to be productive with it, but it depends on the build. And I know Sun's QA folks have been doing at least some preliminary tests with internal 1.5 builds, because I've had one 1.5 specific bug filed against me. Re the tabbed component that is the heart of the winsys, we've had some discussions about separating it as a library - not with the intent of encouraging anyone to use it stand-alone component, but because that would make it easier for look and feel writers to provide a look and feel for it. Though it's written as a standard Swing component, we don't have any intention of *supporting* its use outside NetBeans. BTW, I don't think the fact that we wrote our own tabbed control is a statement about the quality or usefulness of Swing components. It was simply a design decision where we looked at our requirements for painting and behavior, and looked at JTabbedPane, and decided that what we needed (bulk adds and removes of components, data model based contents, highly granular change notification events, ability to apply complex changes en banc which generate a single event describing the change in gory detail) diverged enough from what JTabbedPane does that the maintenance burden would be lower with a component written to those requirements. Most uses of a JTabbedPane don't involve anywhere near that kind of complexity. Tim Boudreau tboudreau@sun.com Prague, Czech Republic Sun Nov 23 11:51:04 GMT 2003 Project Management Improvements? I think one of the biggest problems with Netbeans and Eclipse is the project management. JBuilder's is much nicer and easier to use. JBuilder allows you to define libraries that contain sets of jar files, they can be user, project or JBuilder based. In Netbeans, Jars have to be mounted individually which is a pain and then they clutter up the FileSystem tab. Also in JBuilder, there is a drop down that allows you to switch between active projects. On Eclipse, you see all projects in your workspace in the main tree. I hope both Netbeans and Eclipse update their project management features. jjct jjct1@yahoo.com Boston, USA Tue Nov 25 02:09:37 GMT 2003
|
||||
All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright © 1998-2008 Matt Stephens. ALL RIGHTS RESERVED.
