Design by Code - Why you don't really want a WYSIWYG layout editor for Android

Sep 07 2010

Why you don’t really want a WYSIWYG layout editor for Android

Why you don't really want a WYSIWYG layout editor for Android

DISCLAIMER: I’m on the Android team at Google. The views expressed in this post are mine alone and not those of my employer.

One of the major complaints about Android development is that the layout preview tool in the ADT plugin for Eclipse lacks true WYSIWYG editing capabilities. Critics think that it’s difficult to write layout XML by hand, and that this results in poor user interfaces in Android apps. Well, I think all that talk is rubbish… and short-sighted. Sure, it’s easier to drag and drop buttons next to each other rather than having to first define a LinearLayout or RelativeLayout, but there are a number of problems with this. And, as the history of another popular subfield of UI design has indicated, designing by code and by hand, will win in the end.

What’s wrong with visual layout tools?

The inherent problem with WYSIWYG layout tools for Android stems from the variation in user interface components across devices. Android is intended and designed to run on a plethora of devices, with a variety of screen sizes, screen densities, natural orientations (portrait, landscape), and available user input methods (trackball, D-pad, touchscreen). Visual layout editors will inherently bias the UI designer toward one such configuration. Even with blatantly obvious and beckoning configuration selection controls, a layout editor restricts the designer’s field of view to just one permutation at a time. Given that there are already thousands of such permutations across Android’s current 60+ devices, this doesn’t really scale.

Visual layout editors arguably also place a lot of emphasis on the aesthetics, rather than on logical definition and structure of the UI. Even though some users may claim otherwise, a user-friendly UI is first a comprehensible one (implying an emphasis on logic and rationality), and maybe then an aesthetically-pleasing one. It must first and foremost make sense to its users by evoking a coherent and unambiguous conceptual model¹. Beauty in user interface design should be a by-product of a great solution to a content interaction problem, not the other way around. Focusing on logical placement and layout of UI elements should be priority #1… only after this exercise is complete should the design focus shift to adherence to good visual design principles.

A brief detour

Consider for a moment the multi-decade-old field of web design. Ask any world class, modern day web designer what tools they use. Not one of them will answer with Adobe Dreamweaver or some other WYSIWYG tool. If they’re using Dreamweaver, it’s likely they’re spending more time in the Code view than in the Design view. You’re more likely to hear responses including pencil & paper, Photoshop, Fireworks, OmniGraffle, Visio, Coda, TextMate, Notepad (or the ++ variety), etc. These tools fall fairly unambiguously into either the pure visual design, information design, or code editing categories.

But it wasn’t always like that. Back in the late 90’s and early 2000’s, WYSIWYG tools such as Dreamweaver, HoTMetaL, Microsoft FrontPage, were all the rage and visual editing was seen as a must-have feature. However, at the same time, no one really thought much about accessibility (WAI-ARIA), standards-compliance, graceful degradation, browser compatibility, document semantics, latency, network optimization, et cetera. It’s no secret that the WYSIWYG tools were partly to blame for the overall poor quality and flexibility of the underlying markup plaguing the web. It was, and still is, simply too difficult to make a visual, markup-generating tool that does all these things right while maintaining interactive freedom and simplicity in its own UI. To date, and to my knowledge, Dreamweaver is the only tool that’s really survived—largely because of its innovation in addressing many of these areas. Nevertheless, Dreamweaver still doesn’t get you all the way there, and can prove to be more a burden than an aid. For that reason, many designers and developers choose to hand-write their HTML these days.

There are similar areas of growing importance in Android user interface design. Accessibility, localization, layout performance optimization, and device independence are not things that Android designers and developers can afford to ignore. The breadth of device types and user demographics is large, and growing every day.

So what is the solution?

Well first, I’m not saying the current state of layout design on Android is sufficient. It definitely isn’t, as many Android apps in practice suffer from poor user interface design. I’d attribute this to the complexity of the layout framework, the lack of a good set of ‘defaults,’ and also the relative inexperience with the Android layout system in the design and developer communities. Something clearly needs to be done to improve this.

Unfortunately, there isn’t a silver bullet—there isn’t a single thing that’ll just kill the issue entirely. However, there are a lot of ways this can, and will, improve. The formation of a strong community around web design exponentially improved the quality of web sites and web apps. I think the same can, and should, happen with Android. Such a community can help to grow the wealth of knowledge and resources available to newcomers. The good news is that two such communities are currently forming on Stack Overflow and the User Interface Stack Exchange. I strongly encourage you to participate!

It’s also up to the Android framework and documentation maintainers—we at Google and the carrier and OEM stakeholders—to seed the community with great resources and articles that both clarify and formalize Android UI best practices and patterns. Several resources to this effect exist now², and this is going to get better over time.

One specific type of resource I’d like to see (and maybe work on myself) is a set of layout templates that address some common UI tasks. Such a layout template library could help take the guesswork out of correct approaches for common tasks, as well as provide UI designers and developers with a set of sensible defaults that’ll server as better starting points than a simple, blank XML document.

All in all…

As more developers and designers start working with the platform, fueled by the growing numbers of end users activating Android devices, ad-hoc resources and tools will arise naturally and will make things easier for others. Coupled with the continued investment of Android framework stakeholders, barriers to code-driven layout design will be broken, and app UIs on Android are going to get really, really good… I’m confident about that. It’s really just a matter of time.

Thanks for reading! If you’ve got thoughts on the subject, and especially if you emphatically disagree, I’d love to discuss in the comments!

UPDATE: also make sure to read Reto’s great counter-post: Why You Might Want A WYSIWYG Layout Editor for Android.

¹For more on conceptual models and usability, see The Design of Everyday Things, an absolute must-read, by Donald Norman.

²A small selection of currently available resources on the subject is shown below: