Kirill Grouchnikov's Blog

What's the big deal?

I've been following Cafe au Lait for a few weeks now, and it really amuses me. Quotes like "the best Java can or should do is faithfully mimic the native user interface" and "the goal of a Java application is to fit in with other native applications, not to stand out" most certainly indicate that the writer is a strong proponent of a native look and feel, which is kind of bemusing. The Mac UI is shifting constantly, and the upcoming OS X release is supposed to feature a new UI (Illuminous?). Given the history of OS X for the past few years, and numerous native look and feels (Aqua, Graphite, Brushed Metal), it would appear that even Apple's UI designers don't consider the current state of affairs as the best. But i digress.

You need to be able to change the UI around really easily during development — after user testing, or a Steve Jobs encounter session — even after you’ve attached a lot of code to it. That means no RAD tools that write code for you, because once their code mingles with your code, it gets hard to disentangle. Instead, the UI should be described with data, like an Interface Builder ".nib" file.

The obvious target of this quote is NetBeans Matisse which puts the UI-related code in the same file as the business logic (say, event handlers). However, that is misleading at best and fanboyish at worst.

• The code that NetBeans generates doesn't "mingle" with your code. It is kept in one section of code which is folded by default, and the Java editor doesn't allow you to edit it (you can still view it).
• If you do open this class in an external editor, change the generated code and then play surprised that NetBeans doesn't like it (if you don't follow its conventions), think about what would happen if you'd do the same with the NIB file. Or with the good old Visual Studio RC files. Or with brand new XAML / C# extravaganza.
• NetBeans doesn't use any proprietary format and is already supported by Instantiations for editing in Eclipse. Any other major Mac IDE providing support for editing NIB-based UIs?

So, what's the big deal? What's all the bickering about? That NetBeans doesn't use two separate files? Or that a major Java IDE finally provided a decent UI editor? Or that Java developers seem to treat a 5% market as what it is (a 5% market)?

I don't want to reopen the entire native against cross-platform look-and-feel debate again. I just would like to understand the real difference between Interface Builder approach and Matisse approach, as long as each one of these is used as it's designed to.

For some more thoughts read this and this.

Comments

• I think many oppose the fact that netBeans is actually using two stores for the GUI stuff. You have both the .form file, which is proprietary to netBeans, and the source code which is kind of like a read-only/run-only version of the .form file (lose the .form file and you're toast). This is not a problem if you always stay in NB, but as soon as you try to edit anything manually you can never go back again.

  Some things aren't supported in the netBeans GUI editor, such as setting the upper and lower range of the JSpinners. There is no way to do this other than to have you own method which "modifies" the widgets after they are created, in this case by setting a new NumberSpinnerModel which isn't very "clean".

  I understand why nb has taken this route, Eclipse chose another one which is flaky in it's own way, but it would be good if since you have to do everything with the GUI editor, that you could actually do everything with that GUI editor...

  It's not much missing, but what is, is very annoying at times. The bad JavaBean spec is actually one of the problems here, and also I think we're missing Properties support which formalize a contract with the Beans and nb in a better way.

  Cheers,
  Mikael Grev

  Posted by: mikaelgrev on February 16, 2007 at 11:56 PM

• "in this case by setting a new NumberSpinnerModel which isn't very "clean""

  The consequence of this is to waste a few bytes for the garbage collector and to make the initialization process a few microseconds longer... :-) Is this something we should really worry about? I mean, when I read criticism like this I feel for a moment in another world... a world where everything is so perfect, ordered, starting from the customer, up to the project manager, and all the pieces of involved technology are perfect, a world where wasting a few bytes and a few microseconds really hurts... then I wake up and I realize it isn't a big problem. Right? :-)

  Back to Kirill's original post, I agree completely with him. Besides Apple's examples, I'd like to recall that other pieces of software that are very popular, such as Adobe Lightroom, come with their very own look and feel. I was personally able to reproduce a similar l&f and my application is completely done with Matisse.

  Posted by: fabriziogiudici on February 17, 2007 at 01:19 AM

• The speed decrease and size increase it totally irrelevant IMO, and I didn't say that that was the problem and I don't know why you got that from reading my post. :)

  The problem is that some things, similar things, are configured in the GUI editor and some in code. This will lead to inconsistencies when changing the GUI later. Where did I change this, and where is that set - kind of problems. For instance, try to rename the widget when you have set a custom model on it, you'll get a nice surprise!

  When you work on a long lived project the need for configuring and reconfiguring the UI is important. Having the configuration in two different approached complicates this, especially if there and many developers working on the same project.

  Posted by: mikaelgrev on February 17, 2007 at 02:18 AM

• Michael, I didn't say that you said etc... I just pointed out that the only practical consequence of "not very clean" is IMHO neglectable. I agree with you that virtually anything should be configurable in the same way, but - this was the meaning of my post - I never saw a perfect tool. If it does 95% of the things in a clean way, and 5% with some workaround, I find it perfectly acceptable, keeping in mind that it won't be the only imperfect point of my work.

  I know that renaming a widget with a custom model leads to a problem that must be fixed manually: this is a bug, that can be (hopefully) fixed soon. It's annoying, but - again - I value a tool by comparing how much time it save me from doing the things manually. Of course, I hope that NB developers will bring that 5% down to 4%, 3% and such.

  PS Obviously it would be very different if a tool made _impossible_ that remainder 5% of things, but this is not the case with Matisse.

  Posted by: fabriziogiudici on February 17, 2007 at 03:10 AM

• 
  Kirill i agree with your sentiments - i think that native look and feel is not critically important - cos RIAs and desktop apps like iTunes, Windows Media et al, are heavily themed and skinned these days. Having said that, its great having the option both ways (well, many ways), as Swing does

  If Netbeans et al did standardise on a XML file format for describing GUIs, this would distract resources from current Netbeans development, introduce constraints (requiring extensions to the spec later), and lead to teething instability problems - what's the upside? ;) The other IDE's could implement a Netbeans migration kit if they wanted to, without as much difficulty.

  i guess Netbeans could introduce a mode where the GUI is built and configured dynamically at runtime from the .form file rather than initComponents(), but i don't see how would help the average NB user much? Personally i wouldn't want to see the Netbeans team distracted any from their fantastic work on Netbeans 6 with great new features

  Posted by: evanx on February 17, 2007 at 04:54 AM

• In the end, all that matters is that the GUI must be easy to use and pleasing to the user. If both conditions are met, nobody cares (except developers who swear by the "native UIs") whether it's a new look (and even feel) or not. People can adapt. They do it all the time, with web sites, Flash apps and video games in particular.

  There is actually a raging debate among Mac OS X developers regarding that same problem. Many are criticizing newcomers for their "non-standard" UIs. Disco, a CD burning tool, received a lot of flack for that. On the other hand, a lot of developers are trying to create the best UIs they can, and they happily ignore some of the Apple's UI guidelines (which are out of date anyway.)

  A good GUI is good not because of what it looks alike, but because of what it lets the users do and how easily it lets them do it.

  P.S: JFormDesigner, and IntelliJ IDEA if I remember correctly, lets you generate external files containing your UI that you load at runtime. Here is your Java-ified NIB. I even remember a project which let you load .nib files as Swing UIs. It might even still exist.

  Posted by: gfx on February 17, 2007 at 07:34 PM

• (and sorry for this large block of text, I forgot that java.net is not smart enough to turn new lines into the appropriate HTML code... That is a bad UI :-)
  (from Kirill) i took the liberty of adding the paragraphs to your original comments.

  Posted by: gfx on February 17, 2007 at 07:35 PM

• 
  @mikael - instead of modifying the widgets after creation, you can set the model for a component directly in the GUI editor - just click on the 'model' property and set the 'User code' to something like:
  new SpinnerNumberModel(0, 0, 100, 1)

  One reason I would like the GUI form data separated from code construction is to make it easier to design the GUI in matisse (which rocks), and write the backend code in groovy or jruby.
  Currently, to get access to the form widgets, you have to write boilerplate code, or pass in the models/actions to the form constructor.

  
  As for the ages-old native look&feel topic, I think look is less important than feel. I've been using substance as my L&F for jedit under linux, and its the feel differences (e.g. incorrect button ordering in dialogs, middle-clicking on a scrollbar doesn't do the right thing) that are jarring, not the colour/size/skin of the components.
  

  Posted by: wmeissner on February 17, 2007 at 10:07 PM

• It doesn't matter what's the theoretical optimum user interface. It matters that you use the same UI as everyone else. Apple can change their UI. We should not. Details here.
  

  Posted by: elharo on February 18, 2007 at 06:03 AM

• Keeping the GUI layout in two places: a form file and the source, is a code smell and a severe violation of the DRY principle. The right way to implement this scheme is to have the code read the form file at runtime to decide what to display.

  This is how Mac GUIs have worked for decades, at least since ResEdit and Mac OS 6, probably earlier. This avoids locking you into one tool, and prevents problems where multiple views of the same data get out of sync. Matisse fails this criterion badly, and that makes it produce fragile, brittle, unmaintainable code.

  Posted by: elharo on February 18, 2007 at 06:08 AM

• elharo - i've raised two questions, and you didn't answer them. The first is - what tool besides Interface Builder can be used to operate on NIB files. If there is none, then the "locking" part of NetBeans argument is irrelevant. The second question concerned designed / intended use of each one of the tools (Interface Builder / NetBeans). As long as you stay in NetBeans (even if it means locking), what does it matter that it's split between two places? How would that get out of sync?

  Of course, both questions are about Interface Builder against NetBeans, and not about NetBeans against other Java IDEs. My belief is that if you (as the developer) decide to use some IDE to visually operate on your UIs, you shouldn't complain about locking (JSR 198 is simply bound to fial miserably in such a dynamic and highly evolving field as Java IDEs). If you want interoperability and portability, don't use tools for your UIs.

  Posted by: kirillcool on February 18, 2007 at 01:53 PM

• Kirill, if both questions are about IB against NB--Matisse, I think that they are not really comparable. IB goes well beyond Matisse (which seems anyway to borrow "ideas" from IB). IB with Cocoa Bindings and Core Data integration lets you do far more than what you can achieve with NB. I agree that .form files plus source code equals nb files in terms of locking, but in the Mac development world few really care about locking issues. As elharo has pointed out, having the UI completely separated from the code in some sort of resource files is an approach that is born with the Mac (if not already present in the Lisa) and is is a thing to which Mac developers are used to and comfortable with.

  Posted by: apetri on February 19, 2007 at 03:53 AM

• Just take the Matisse UI-code as a resource. Why to touch that code? Write a Controller, let Matisse handle the look.
  For the things that "declarative UIs" use some obscure EL, or worst, some XML tags for "scripting", Matisse just use plain Java user-code.
  I really don't miss Delphi and RC with Matisse.

  Posted by: gustavosantucho on February 19, 2007 at 03:49 PM

• The native "feel" is a lot more important than the native "Look".

  E.g. when you can't right-click in a File Dialog and do the same things that you can do in every native application, THAT'S a problem. When you can't right-click in a text field to do cut & paste from a context menu, but you can with every native app, THAT'S a problem.

  Fancy animations and glossy buttons are irrelevant in comparison.

  Posted by: swpalmer on February 19, 2007 at 08:09 PM

• (disclaimer) I like Matisse.

  But here is the deal... before you can mention Matisse and Interface Builder in the same breath, Matisse needs to get up to speed with what was possible in Visual Basic 3.0 from approx 13 years ago.

  13 years is a long long time in the computer industry.

  Interface Builder kicks so much butt that I don't know whether to laugh or cry that you are comparing them. If I cry it is because we Java programmers are using a language based initially on most of the good ideas of the previous 10-20 years of language development... and yet we have forgotten our roots and become so insular that we don't even think we could learn a trick or two from anywhere else*.

  *With the obvious exception of Ruby, from which it is clearlyimpossible to learn anything of value, since it is derived from Perl. ;-)

  Posted by: rickcarson on February 19, 2007 at 08:55 PM

• The Beans Binding JSR will help Matisse gain features that Interface Builder has now... but I don't know whether to laugh or cry when you bring up the abomination known as Visual Basic ;-)

  Posted by: swpalmer on February 19, 2007 at 09:24 PM

• Personally I think anyone who lays out a UI by hand is off their rocker. How on earth you can maintain an visual application with an IDE manually adding adapters/listeners and the associated code I will not understand
  But I come from a business perspective where perhaps we are not creating a state of art visual masterpieces, rather large numbers of often form driven workflow applications.
  JGoodies is a saviour when it comes to a layout manager in that respect, as is the Mediator pattern for driving UI interaction events

  Posted by: aronsmith on February 20, 2007 at 11:26 AM

• Say what you like about VB as a language, as a tool for slapping together a quick and dirty user interface it is head and shoulders above anything Java has ever offered.

  Matisse is a step in the right direction. But if you don't realise you are playing catch up - you won't run as hard as you need to, to actually catch up.

  And Interface Builder could learn a trick or two from it I'm sure.

  There is a _reason_ why so much software is written in VB, and it for sure isn't because their For Loop has superior syntax.

  Now, as it happens, VB apps are notoriously ugly, so much so that when people see an ugly VB app, they just shrug and think "oh well, it is VB, what do you expect". But for some reason other languages don't get the same free pass and get criticised when users of those languages create ugly apps.

  It _is_ possible to create an app in VB that doesn't look hideous. Interestingly the skills required to do so are almost identical to those required to not make a hideous Java app. And in both cases it takes significant work and thought.

  Posted by: rickcarson on February 20, 2007 at 04:49 PM

• aronsmith;
  You are right, for a lot of apps, the visual designer is not so important. People often miss that a lot of "enterprise" or "business" apps often have hundreds of "screens". These are often forms, or graphical layouts, which are either automagically generated, have some meta language to describe them or their own little formats. That said, these GUI builders are definetly good for prototyping, and it's just plain easier to implement static layouts with these tools.
  Going back to the "native look and feel" discussion. I think native look is important, but I think sometimes people are too obsessed by it. More important is general UI design and usability. For example, look wGetGUI, which looks like a native app, but it's a GUI disaster at all levels ...
  http://sellmic.com/blog/2007/02/20/usability-matters/
  

  Posted by: augusto on February 20, 2007 at 05:02 PM

• Agreed, usability has nothing to do with following a particular LAF. Its all about, well usability, a did one advanced comp sci course at University and gees I wish I did more because it is an awesome subject. My favourite book so far is http://www.oreilly.com/catalog/designinterfaces but I am sooo hungry for more knowlege on patterns that I can apply to my apps - when you get it right it can truly blow you away.

  Posted by: aronsmith on February 20, 2007 at 06:04 PM

• Come on Kirill, you can't be serious that you don't understand what the big deal is.

  - code is not "mingled", than what the hell do you call a class where a certain percentage of the file is untouchable generated code and the other part is written by you? (And depending how you normally lay out your code the generated code _will_ be in several different places, not just one block). I'm sorry but to me "mingled" sounds exactly right.

  - yes, an external editor... like... Eclipse maybe? You know that different people might use different tools and in large and/or diverse corporations you might find that it's pretty difficult if not downright impossible to have everybody use the same tools. And in this case you must EDUCATE them that whenever they see a foo.form file they should take extra care with the foo.java file! That just doesn't work, if only for the fact that it suddenly makes refactoring your code extremely dangerous. (The refactoring will work, the code will compile, the non-NB developer will think everything is okay... until another developer wants to change the GUI and finds that the form can't be loaded anymore).

  The comparison with NIB and RC just completely misses the point: they are both completely independent of the code! You could edit them with any tool to your liking without effect on any code that uses them. The form+java combination just isn't the same as a NIB or RC file. The java file contains code written by the developer, it should be possible for other developers to edit that part of the code using whatever tools they normally use without any problems.

  So yes Mantisse is definitely a decent UI editor but using it in large projects with a diverse batch of tools has proven a mayor pain in the butt (especially if you have to work with people who don't use MVC and therefore have lot's of business logic in their forms).

  Posted by: quintesse on February 21, 2007 at 01:23 AM

• I've never considered that generating code it is a good solution. It is obvious and understandable why that generated coded must by frozen up, but this reason it is the key of not having IDE interchangable code. The solution I see consist in managing UI layout related code or directives as XUL or JAXML or F3 scripts (or whatever standardized method) and layout implementations in JDK so that form projects could be opened, interpreted and modified by any Form Builder.

  Posted by: linus on February 21, 2007 at 02:08 AM

• UI editors suck unless they enforce MVC
  I don't use them for writing Art. But make those robots use them

  Posted by: lz_mordan on March 27, 2007 at 08:40 AM

This work is licensed under a Creative Commons License.