GUI development: should you design it or code it - Dissecting SemanticMerge, Part 3

GUI development: should you design it or code it - Dissecting SemanticMerge, Part 3

Sunday, March 23, 2014 147 Comments

Our question here was: "should we use the designer or code an imperative UI?

As you have just seen using the Interface Builder is really simple, just drag and drop, getting used to the new controls and the UI of the designer and so on.

Xamarin Studio doesn't provide its own designer it simply relies on invoking Interface Builder, which is not bad since they’re not reinventing the wheel.

But, there are some concerns in my opinion:

Each time the Interface Builder modifies one of the .xib files (files containing XML defining the interfaces) Xamarin Studio gets notified and rebuilds whatever linked code it needs. It always worked for us with pet projects but I wouldn’t really like to be in the situation, 6 months after starting the project, with tons of code written, to find some sort of ‘conversion error’ when linking the .h files populated by Interface Builder with the Xamarin code. I hope I’m wrong here, but simply I don’t want to be in that situation.

Now, more about UI designer vs plain code: recently I read this blog post about creating “imperative UIs” with C# in the Xamarin blog. When I found this post we already had finished the SemanticMerge UI programming in “imperative mode”.

There were various reasons why we went the ‘imperative way’ and we coded our entire interface completely avoiding the Interface Builder:

• First we wanted to avoid any potential issue with the ‘automatic conversion’ as I mentioned.
• Prior to starting with Mac we developed a GTK# UI for SemanticMerge, to give it native look and feel on Linux. We used MonoDevelop 4 there, which is great, but its interface designer is… well, far from looking solid. So we went the ‘hardcore’ way and created the entire UI with code. It can sound like an overkill (it *did* sound crazy to me years ago) but read the next bullet point first.
• We’ve been developing Plastic SCM (www.plasticscm.com) with a WinForms UI for almost 9 years now. We always used the Visual Studio designer and… you know what? I hate it. It looks great for a toy application, you just go and drag and drop your controls and everything looks fine. But use it for a decade and you’ll find out:
• That the infamous .resx will break or simply won’t get correctly updated and you will lose alignments or some event handlers from time to time. Time wasted.
• At least the WinForms designer doesn’t enforce good practices: I hate when I find auto-generated names in controls such as Form1 or Label1 and so on. Of course you can ask your team to… not do it this way, but the tool *helps* doing it wrong.
• Suppose you redesign a Form and then you need to move part of the UI inside a new panel and then add more things to the form… well, you’ll need to play with the “anchors”, cut and paste… and pray. BTW the entirely regenerated automatic code will be a nice thing to merge...
• Since it is very easy to just “throw controls on the window” then probably many unneeded ones will hang around, like panels inside panels and other beauties.
• Keep the right margin for buttons and controls in all forms… looks easy, but someone will have to hand write the margin space again and again… wouldn't a constant help?

As counter-intuitive as it might sound (tell it to my younger self coding a MFC UI and missing Delphi), for long running projects I truly believe it is better to go and code the UI: you can refactor code to make it more readable, you’ll think twice before adding a control, you’ll name everything correctly, you’ll just have to slightly modify the code to change the hierarchy of objects inside a window… and you won’t have to depend on error prone UI designers.