The Making of Xamarin Studio
Xamarin Studio is our brand new version of MonoDevelop. It contains everything MonoDevelop has, but is extended with support for iOS, Android and Mac development, and it is Xamarin-branded as part of our mobile platform.
Yesterday, we released Xamarin Studio to the public, and merged about a year’s worth of work that we developed in private to the public MonoDevelop repository.
All software grows organically, especially large-scale software like an Integrated Development Environment. Organic growth is fantastic, but like a lawn, it needs to be trimmed down every once in a while to make it look pretty.
When we launched Xamarin, we knew that we needed to do two things: make Visual Studio a first class citizen for iOS and Android development (which we just announced) and also that we needed to modernize and streamline MonoDevelop for mobile development.
Improving the quality of MonoDevelop on Mac and Windows fell in the following categories:
- Fix crashers and bugs
- Complete some important features that people depend on
- Update many old elements of MonoDevelop and refine its UI, develop its own voice
- Keep up with all the needs of iOS and Android developers as those platforms evolved
Bug Fixing and Stability
Shortly after we launched Xamarin, we triaged and organized the bugs that our users were running into, and started a systematic process to fix those bugs. We hired great hackers from the Mono community and got to work.
Some bugs were in MonoDevelop, some were in Mono, and a large number of them were in the Gtk+/Gtk# stacks when running on OS X and Windows.
We worked closely with Lanedo, a company that specializes in Gtk+ consulting, to improve Gtk+ on OS X and Windows by fixing many of its bugs and tuning its performance. As a result, it’s in a much better state today. Lanedo has been upstreaming those fixes and improvements back to the Gtk+ community
Our own team revamped our Gtk# story on Windows. We fixed various bugs in the stack and the binding itself and we came up with completely new and up to date packages for it.
Designing Xamarin Studio
While we were busy working on the bug fixes, Nat worked with the Xamarin Studio team and external designers to put together various prototypes for the appearance of the user interface.
One of those organic growth problems that we had experienced was the toolbar. The toolbar was popularized by Microsoft Office and it became a general dumping ground for commands. Over time, the age of the design started to show. Operations like cut/copy/paste, that have been a staple of many applications, was always there, mostly because, well, it was there. After decades of using software, I still struggle when I see the copy/paste/icons to figure out which one is which. Or to figure out what most of these things do:
Typically using the toolbar meant hovering until a tooltip appears and repeating this operation until you find your command, or just going to the menus where things were ordered in place.
So when we looked at this toolbar, we realized that many of these operations really could go elsewhere. Cut/copy/paste and file operations have standard keyboard bindings and menu entries. Debugging could be context sensitive, history navigation is better suited close to the buffer. Searching could be more central.
So we started prototyping, these are some designs that we considered:
Using combo boxes and some debug buttons:
Moving the status bar to the top:
The search button was not quite right. This one adds a search entry on the right:
You will notice that early on, we decided to go with a Beagle-like prioritization of the search results.
A little inspiration from Firefox for placing the button:
That just felt too odd. Moving to the left made it more natural:
You can see above how the debug buttons are contextual. They show up while debugging an application, but not during regular development.
This is what it currently looks like:
An important change that we made was to simplify the rather confusing Configuration/Platform selector that comes from Visual Studio and MonoDevelop. We came up with a smart system that instead shows the Configuration and the target device (Simulator, Device), and automatically determines the correct Platform.
If you have complex Configuration/Platform then the Configuration combo behaves like the one you are used to.
We inherited a very large code base with many features, and MonoDevelop was originally developed entirely using the Gtk# APIs. Rewriting the code to have two backends, one for Windows and one for Mac, was going to burn a lot of our resources.
Instead we came up with a different approach. We added platform-specific code in various places where the native platform would be exposed. For example, contextual menus are now drawn using the native theme, file dialogs are system dialogs, and the Gtk+ behavior and theme has been tuned to be closer to each platform’s guidelines.
Using native context menus.
One interesting thing happened. OS X Lion and Mountain Lion started to look more like our own theme, and started to look closer to the UI that we had. With almost no effort, our internal designs were all of a sudden closer to Apple’s new designs.
Native file dialogs.
We still wanted to have our own personalized touch, give Xamarin Studio its own personality, so we created a new Gtk+ theme that builds on the native features and makes it ours (you can see our xamarin-gtk-theme on GitHub).
This is one of the early mockups that we used to define our style, though it has has evolved since it was created:
Early prototype of the look we wanted to create
In parallel with improving the look and feel of our existing GTK# based UI, Lluis designed and implemented Xwt, a C# API intended to create user interfaces that are backed up by native controls on each platform. It transparently uses Cocoa on OS X, WPF on Windows and Gtk+ on Linux.
Xwt approach is unique in that the focus is in providing fairly high-level controls that have strong semantics associated. For example, the idea is to expose a “file selector widget” instead of giving the user a general purpose box, button, text and letting the user implement his own. Instead, the idea is to use controls that have more semantics, and let every backend implement it in the best way possible.
With this, we are starting to write new dialog boxes and new interaction components completely in Xwt, which gives us the native look and feel. When we find limitations, we introduce a new high-level semantic control.
At one point, we noticed that the prototype that we had for navigation was distracting:
Black hot spots draw the attention away from the editing
While at the time I knew what bothered me, I could not explain the reason. A few months later, as part of a discussion on twitter on double-spaces Woody Zuill said this:
@migueldeicaza The more useful ‘rule’ I was taught was to avoid ‘hot spots’. A hot spot is anything that unintentionally directs the eye.
— Woody Zuill (@WoodyZuill) November 11, 2012
Needless to say, we fixed that at the time, but I was happy to get a better understanding of why it was distracting.
Passion is the secret ingredient that made Xamarin Studio possible.
The team involved really loved the project, and cared about the details. The team went beyond implementing the original designs, and kept on iterating, experimenting and going back to the drawing board over and over. All while maintaining the public version of our products.
One of the products of passion that came out of this exercise was a cross-platform animation framework that we used to provide smooth animations of various parts of the IDE.
Our code completion engine was based on NRefactory. In the past year, we rewrote NRefactory to use Mono’s C# compiler to perform the parsing and provide the semantic information to the IDE to provide correct code completion.
Although we introduced this in MonoDevelop 3.0, we made significant improvements to code completion on the Xamarin Studio branch, and it is now available for everyone to use.
While we achieved a lot with this particular iteration of Xamarin Studio, we have ambitious goals for its UI. Most of the work will now take place in the public MonoDevelop repository, but we are keeping a few surprises up our sleeves 🙂
If you want to try Xamarin Studio today, go to our download page.