Tuesday, September 07, 2010

Why You Might Want A WYSIWYG Layout Editor for Android

When I read "Why You Don't Really Want A WYSIWYG Layout Editor for Android" by my friend and colleague Roman Nurik and my initial reaction was - hmm, actually you know, I really think I might. We discussed it via email briefly, but figured you guys might enjoy reading both sides of our discussion.

Roman makes a lot of really good points - particularly on the importance of designing a coherent model for user interaction. This must not be underestimated. His ideas for UX templates sound awesome, and I totally agree that there is no silver bullet to solve the difficulties around creating great UIs.

Where we disagree is on the effect that visual layout editor could have on the quality of Android app UIs. My experience tells me that a good visual editor would have a positive effect on the quality of Android UIs, while also making it easier for beginners to get started.

Fine tuning by hand is always going to be a necessity - but getting started visually can make life a lot easier.

Visual layout editors for native platforms can make assumptions that HTML editors can't

Before joining the world of Android, I spent 10 years writing winforms apps - 5 years of Delphi followed by nearly the same of C# .NET. I've spent a lot of time with the UI tools from Borland and Microsoft.

Using web / HTML design tools to evaluate the usefulness of native layout editors is a little misleading - the reason you don't use Frontpage or Word to build webpages is because the HTML they produce is a thing born of hate - there's no reason an Android layout editor can't produce beautiful XML.

It's also worth noting that the disappearance of WYSIWYG web-dev tools coincided with the rise of Web 2.0 - when HTML made way for Javascript and CSS. I haven't seen anyone who hates themselves enough to try and create a WYSIWYG Javascript layout editor.

If we're going to compare the success and potential of visual layout editors we should be looking at native tools like Microsoft's Visual Studio and Expression Blend.

Whenever I design a new UI I start with pen and paper

Like Roman, I always start by sketching. It's the easiest way to get a feel for the the user experience workflow I'm after. This works because brain-pen-paper is the shortest path to visualizing my ideas.

Moving from pen to PC creates a barrier, but it's a price worth paying to see how my design actually works in right context.

I'm not so attuned to the Matrix that looking at XML lets me see UI, so having to turn my sketches into XML requires an additional context switch: from visual design to writing code and then back to visual layout. By using a layout designer I can continue to think visually and adapt my design without having to translate back and forth from code to images.

Witness the popularity of AppInventor

If you're not familiar with the classes and UI metaphors of a development language this context switch is brutal. You're constantly interrupting yourself by searching the docs for the name (and attributes) of the class you need.

With a visual designer you can browse the available controls and glance at their properties. The barrier to getting started and creating your first UI is significantly reduced, and your ability to experiment, test, and discover are enhanced.

It's important to remember that the built in controls are just a first step. I think of them as stencils, many of which will be replaced with better, customized solutions as the app develops. At my first job they remarked that I was "not just building the car from scratch, but engineering every nut and bolt." They seemed surprised that I took this as a compliment.

Native Visual Designers are designed for variable hardware

The size of application windows in Windows have never been fixed. WinForms layout editors are used to develop for an environment where different screen sizes are assumed. In fact your windows are expected to be dynamically resizable.

One of the beauties of WYSIWYG is that you can make changes to the presentation context and instantly see it's effect on your code. In Winforms that meant dragging your form around to make it bigger and smaller and see how your UI reacted. Having that ability in Android would be great - particularly as you can witness the changes in layout and assets as you modify the screen size and resolution without the context switching.

Users will use your app if it solves a problem. They will stay loyal if using them brings then joy

Roman suggests that "Visual layout editors arguably also place a lot of emphasis on the aesthetics". I don't think that's true. If anything, traditional WYSIWYG UI tools have done the opposite - resulting in uniformly depressing, drab UIs.

Not that this is better.

No matter what though, you are going to need to get your hands dirty in amongst the XML to get your layout right - and it's likely to be pretty early on in the process.

A rich visual layout editor is neither necessary nor sufficient to guarantee a great UI

Lazy developers will create rubbish user interfaces. If you want to use a visual designer because it's faster to drag-and-drop than to write out XML then you're doing it wrong. I believe that a good UI designer can make it easy to dynamically modify the look and feel of each component beyond being a simple drag and drop layout tool. By baking in some of the best-practices for UI development you can help codify successful UX.

Creating a compelling user experience is about more than just laying out controls on an Activity. You need to spend a lot of time thinking about what workflow you're trying to support, and how to make the user journey pleasant if not an outright joy.


  1. I think half the problem is the fact that you guys *are* shipping a layout preview mode with the ADT plugin that gives first time devs the impression they can construct their UI visually. Unfortunately it only works for the most trivial of layouts. Add a custom view and you'll get some sort of NullPointerException error which will render the entire view completely useless. You wouldn't give something like that to an end user, so why give it to developers?

    Also, many devs aren't aware of or don't understand the usefulness of tools like the Hierarchy Viewer. Integrating this into the Eclipse toolchain would make a lot of sense.

    You mention the Microsoft tools, but surely Apple's Interface Builder is of interest, especially in the latest Xcode incarnation. Its been part of OS X development from day one - a platform (along with iOS) that has become renowned for its application interface beauty.

  2. Well, I agree with you, mostly.

    I've been developing Windows apps in Visual Studio since version 2003 and it's one thing I miss most of the time when I move to another platform (Android or not). There just isn't a good layout editor elsewhere besides Visual Studio.

    Of course, this is not enough for rich and compelling UIs on Android but it sure would help a lot. There's a ton of apps out there that simply have an horrid UI. Maybe the developer is lazy or maybe he's not so comfortable doing everything by hand. A visual layout editor would help a lot, at least to position and align elements.

    One of the reasons I haven't really digged into Android development is because of that. I don't have the time nor I want to be bothered with learning every single aspect of the XML code necessary to develop a simple UI. With a visual editor I could do that much faster and tweak the finer details in the code if I really have to. But that would save me a lot of time.

    A good visual layout editor, like Visual Studio's, would make for better UIs in Android, I'm sure of that. Specially with proper Anchor and Dock properties, that would probably suffice for different screen sizes as long as developers are aware of their importance.

    That's the way I see it...

  3. To comment on the comment above mine I just want to say that I don't even know how the developer tools from Apple look like and I don't know how good or bad the visual editor is.

    But one thing's for sure, UI wise, most apps for Apple devices are way ahead of most Android apps. They are simply gorgeous to look at and that's for sure one thing I miss in Android (note: never owned an iPhone).

    Surely not every single Apple device's developer is an expert on UI design, is it? Which means, something is quite right with their developer tools and something is quite wrong with Android ones.

  4. Good call on the iPhone tools. I didn't call them out as I haven't actually ever used them. What do you guys think? Are they compelling?

  5. If you're developing apps with a full team, you'll start with a capable UX designer (well, you'll start with some ideas, maybe even something like user stories, but let's stick to the visual side of things). The UX designer... let's just say I know a few very capable ones and they tell me they have no tools. But what they all agree they want, is essentially something in between Visio and Illustrator. They care about where UI elements are placed, what (relative) size they are, but most importantly how they act (i.e. how one button leads to another screen).

    Then, you get a capable UI designer. Their tools of choice are usually Illustrator and Photoshop.

    With the results from both these people, you start implementing the UI. I can tell you immediately that no amount of visual editing will let you even get near to what the previous two guys cooked up together.

    Really, there's not much point to WYSIWYG layout editors.

  6. About the iPhone tools: Interface Builder is generally considered to be the worst part of Apple's iPhone dev kit, at least amongst the people I know.

  7. @unwesen I totally agree. One of my best practices for Android is "hire a designer". That's already three people in your team though: a UX designer, UI designer, and a developer. You probably want an architect and tester in that team too. For a team of that size I'd be surprised if they weren't hand-crafting everything. Definitely the way to go if you can afford it.

    A lot of ideas start with a single person sketching on a piece of paper. I think good tools will make it easier for them (and resource constrained teams) to create better products.

  8. Fantastic counter-post, Reto!

    Visual, direct-manipulation tools at the very least useful, but they can lead the developer down the road of narrow focus (tunnel vision). This is especially harmful for Android, where devices do and will vary much more than just by resolution.

    I suppose it's theoretically possible to build a great tool that'll 'do things right' and keep designers on their toes... but I'm worried that properly addressing localization, theming and overriding styles, layout re-use (via or otherwise), etc. would carry with it an encumbrance on the layout editor's complexity and ease of use.

    And undoubtedly, these types of tools are very useful for beginners. I stand behind my belief, though, that there's so much more excellence to be achieved when code-driven layout is embraced :-)

  9. By the way, same here with Borland and VS tools -- used them for a long time. Borland C++ Builder and Visual Studio's layout tools are really fantastic for their purpose.

  10. @Roman Knowing the eng team, I have no doubt anything they produce would be up to the task of keeping developers honest :)

  11. Having read Romans excellent post, I even got on my soap box http://kgutteridge.co.uk/blog/2010/09/07/why-a-wysiwig-tool-for-android-might-be-useful/

    I love your point about developer lazyness, in my mind its nothing to do with believing that a WYSIWIG tool is faster, its just that the iteration time with a designer can be easier as they can take the lead of the controls and really show the developer how a UI should interact. Back in the J2ME days we regularly used Flash for this purpose once you had passed the paper stages

  12. @Jeff Gilfelt There's a workaround for that NullPointerException: inside your custom widget, never call findViewById when isInEditMode() returns true. Don't know why... Also a bit of a pain to then make sure you don't use anything that you would have set using findViewById. But it does make your widget safely visible in the editor. :-)

  13. In an early project phase, quite often a UI gets redesigned a few times as new ideas are generated when using / testing the first prototype. Being able to get to this first prototype early and trying out ideas with less effort would speed up that phase of development.
    Final tweaking in XML may be necessary to get ultimate beauty / sleekness ...

    If an editor would also generate template code adding IDs etc. then the coding task will be easier and the program source would become much more uniform and easier to maintain, especially for the poor sole who has to change your code two years later.



  14. Basic4android is a new development environment that targets android devices and it has a powerful visual designer. The designer has built-in support for multiple layouts.

  15. TIME!!! The part you nobody seems to be talking about here is TIME! To build graphics with strings is like asking a blind person to be an interior decorator. At a minimum, you have added a 2nd step to the process (thou it is much worse the that). Go the the text, edit the line, open the 'preview' see what it looks like... back and forth. It fundamentally a flawed approach.

    We are not asking for "click to code" here, I understand the value there but, really a double click to take you to your code is NOT what we are talking about, it's the HOURS of guess work to make the layout the way you want to SEE IT. To not provide the ability to SEE the design as you design it, is beyond my compression.

    That fact that the Andriod folks don't understand this is clear. In fact they not only have it wrong here, they released the same but, exact opposite in App Inventor! Here you have Graphics to make CODE, instead of CODE to make graphics....

    Rest assured that the market will prevail and some talented group of people WILL come up with a great designer package the people will flock to it and our design TIMES will come down and the screens will become more useful...

  16. Anonymous1:56 am GMT

    wilmsoft is exactly right. We have UX and UI designers and they create compelling flowcharts and precise PSDs- then we waste days trying to convert those images into usable XML.
    Compile app- nope wrong gravity. Change XML, recompile, nope margin too wide, etc. XCode for iphone is not THAT great, but getting from layout to code is a lot faster than the android process.

  17. Anonymous11:39 pm BST

    If a company made a design toolset like Microsoft's Expression Blend for Android layout XML they would make a killing. I cant believe this doesnt exist yet. Developers should be able to make it work and then the designers should be able to edit it to make it pretty, or vise versa. This is how web dev works and how WPF dev works. Such a design tool can also enforce the constraints of the platform and hardware. The current prosses of Compile, tweak, compile is far too slow. The speed and quality of developing beautiful Android apps would be greatly improved. Developers should not be trying to implement the design with code. This is why many are moving to a hybrid webkit UI for the sake of speed to build UI's even though they are of lesser quality.

    Also, Andriod layout XML is surprisingly similar in function to Microsoft's XAML. There is much more to it than layouts. There are also shapes, vector graphics, animations, etc. So a good design tool would like Blend is posible. When can I buy such a tool.

    Maybe this is due too the open source nature of this platform. The tools tend to lag far behind those of Microsoft. Its too bad.

  18. Anonymous12:37 pm BST

    Hi, I'd just like to mention GTK+ and Qt as two other toolkits with WYSIWYG editors provided (Glade and QtCreator) that work great with dynamic-sized windows.

    And, by the way, although being mainly a GTK+ developer, I love Qt Creator feature of automatically layouting a form based on the widgets positions (that means, it is capable of getting the "absolute" positioned form and convert it to a nested layout form... and yes that works well most of the time).

    Of coure I'd appreciate something similar to this in Eclipse ADT.