Categories
Learn

The salesman and the developer

http://swombat.com/2012/5/11/salesman-developer

BY DANIEL TENNER

A salesman and a developer go on a bear hunting trip.

They arrive at the cabin in the woods and start unpacking the car, moving stuff into the cabin, getting things ready for a week of bear hunting in the wilderness. The salesman quickly gets bored of this and says:

“Tell you what, you continue unpacking and getting everything ready, and I’m going to go and find us a bear.”

The developer sighs and nods (he’s used to salesmen), and continues setting up while the salesman vanishes in the woods.

Half an hour later, as the developer is about three quarters done with getting things ready (the cabin is now all neat and tidy at last), he hears a very loud growl as he comes out of the cabin. Twenty metres away, the bushes start shaking. Out shoots the salesman. Right behind him, a huge, snarling, drooling, roaring monster of a bear. It’s twice the size of a normal bear, and it’s very, very angry.

As the developer hides behind a chair, the salesman runs right up to the cabin, with the bear on his heels, and just as he’s about to go through the door he quickly leaps to the side. The bear crashes past him right into the cabin, and the salesman deftly closes the door right behind, locking the bear in. Loud noises can be heard as the bear begins trashing the inside of the cabin.

The developer emerges from behind the chair. The salesman cheers and says:

“Woohoo! That’s the first one. Now, you kill him and skin him, I’ll go find us another!”

Two perspectives

There are two ways to understand this story, and which way you favoured largely depends on whether you’re a “builder” type or a “sales” type.

If you’re a builder type, you see this as a great story that illustrates a common problem with salespeople: they don’t seem to care about what happens after they make the sale. Actually delivering the project is hard work, but by then the sales guys have moved on to something else, so they don’t care (and, as an additional problem, in some industries the salespeople will sell stuff that can’t be realistically delivered).

However, if you’re a sales type (like my cofounder, Paulina), you have a different perspective on this story. It’s yet another story that makes fun of salespeople while completely discounting just how hard it is to not only find that damn bear, but bring it back and get it through the door.

Who’s right, then? Both, of course. In business, you need both to find and sell clients, and the ability to then deliver what you sold them. One without the other is not a business.

Sales is not optional

Many people who “do startups” these days are from a technology background. In other words, they’re builders rather than salespeople. And, like all builders, they tend to disregard sales as something that can happen later, something secondary that we’ll solve when we get to it.

Well, sales isn’t secondary. Speaking as a builder type myself, and having experienced businesses both with competent sales and without, I now believe that having someone whose job it is to go and find clients willing to give you money from day one is so important, that I would not start any company without such a person.

Sales don’t happen without someone energetically pushing the product, service, or whatever it is you’re intending to sell. Some may dream of products that sell themselves, like Dropbox or the original Apple II, but even awesome products like those took serious sales effort to get off the ground. Apple had Steve Jobs, one of the master salesmen of his generation, pushing the product everywhere he could and striking bold deals to get the company off the ground. Dropbox endlessly tweaked their referral scheme before they went viral.

Some few businesses like Google or Facebook or Instagram get to figure out the business model later. They can do without sales, perhaps. But this model only works in one place in the world, and unless you’re starting up in the Silicon Valley bubble, your business is not a business without sales.

Categories
Learn

Monkeys, Bananas, Step Ladders And Water Sprays.

Posted: June 11, 2012 | Author: John Ford

Many of you may have heard the myth of the monkey/ladder/water-spray experiment, which put like that sounds rather odd. What not so many people know is that said experiment is not a myth. In 1967, it was conducted by G R Stephenson, under the title ‘Cultural acquisition of a specific learned response among rhesus monkeys’ .

The experiment ran as follows. Stephenson collected 5 monkeys and locked them in a cage. From the ceiling of the cage, he hung a bunch of bananas, which could only be accessed by a step ladder leading to them, which the monkeys could climb. There was, however, a catch. Every time a monkey started to climb the step ladder, that monkey was sprayed with ice-cold water. Not only that, but the other 4 monkeys were sprayed with cold water as well. This was repeated every time a monkey attempted to climb the ladder until the monkeys became conditioned: no monkey must climb the step ladder.

Stephenson then replaced one of the monkeys with a newcomer. Just one. Fairly quickly, the newcomer spotted the bananas and went for the step ladder. But the other monkeys – knowing the drill by now – quickly rushed to stop the newcomer, screaming and snarling at him and even scratching him. Without any intervention by the scientists – with no water even being sprayed on him – the new monkey immediately became conditioned as well.

Stephenson then went on to replace the other monkeys in turn. Remarkably, every time a new monkey was added and went for the step ladder, all the monkeys that had been conditioned rushed to stop him, screaming, snarling and scratching. Even those who had never been sprayed before joined those who had in beating the new monkey.

Eventually all of the monkeys had been replaced. None of them had ever been sprayed with cold water, yet none of them dared to climb the ladder to get the banana. When the final new monkey was added, they rushed to uphold the rules as before.

The new monkey would be justified in questioning this behaviour. And what could the other monkeys say? They had never been sprayed. Yet if they were to answer, they would probably say something like this:

“That’s just the way we do things here. It’s just how life is.”

That sounds familiar…

Initially, the learned response not to go up the step ladder made sense. But soon it was rendered redundant – the scientists had not sprayed any of them since the first of the new monkeys was added – yet it continued to be upheld…

Human beings are also (and even more so) creatures of habit. We are used to going through life obeying social norms or customs, that were adopted for a reason that must have been important at some point in time. But how many of those are outdated and should be changed or  be improved on? Fortunately we have the capacity for change. Although as the new monkeys found out to their cost, it is not always easy to fly in the face of popular beliefs.

Nonetheless, this experiment highlights the remarkable power of behavioural conditioning, mob mentality and the importance of questioning social and cultural beliefs and customs.

 

http://blog.ladders-online.com/2012/06/11/stepladders-monkeys/

Categories
Learn

FYI

Military slang terms used by various branches of the United States military during World War II.

SNAFU

SNAFU, which stands for the sarcastic expression situation normal: all fucked up, is a well-known example of military acronym slang. It is sometimes bowdlerized to all fouled up or similar. It means that the situation is bad, but that this is a normal state of affairs. It is typically used in a joking manner to describe something that’s working as intended. 

The attribution of SNAFU to the American military is not universally accepted: it has also been attributed to the British.

SUSFU

SUSFU (situation unchanged: still fucked up) is closely related to SNAFU.

FUBAR

FUBAR (fucked up beyond all recognition/any repair/all reason), like SNAFU and SUSFU, dates from World War II. The Oxford English Dictionary lists Yank, the Army Weekly magazine (1944, 7 Jan. p. 8) as its earliest citation: “The FUBAR squadron. ‥ FUBAR? It means ‘Fouled Up Beyond All Recognition.”

TARFU

TARFU (totally and royally fucked up or things are really fucked up) was also used during World War II.

BOHICA

BOHICA (bend over, here it comes again) is an item of acronym slang which grew to regular use amongst the United States armed forces during the Vietnam War. It is used colloquially to indicate that an adverse situation is about to repeat itself, and that acquiescence is the wisest course of action.

Categories
Learn

Surprisingly Good Evidence That Real Name Policies Fail To Improve Comments

from TechCrunchTechCrunch 

YouTube has joined a growing list of social media companies who think that forcing users to use their real names will make comment sections less of a trolling wasteland, but there’s surprisingly good evidence from South Korea that real name policies fail at cleaning up comments. In 2007, South Korea temporarily mandated that all websites with over 100,000 viewers require real names, but scrapped it after it was found to be ineffective at cleaning up abusive and malicious comments (the policy reduced unwanted comments by an estimated .09%). We don’t know how this hidden gem of evidence skipped the national debate on real identities, but it’s an important lesson for YouTube, Facebook and Google, who have assumed that fear of judgement will change online behavior for the better.

Last week, YouTube began a policy of prompting users to sign in through Google+ with their full names. If users decline, they have to give a valid reason, like, “My channel is for a show or character”. The policy is part of Google’s larger effort to bring authentic identity to their social media ecosystem, siding with companies like Facebook, who have long assumed that transparency induces better behavior.

“I think anonymity on the Internet has to go away,” argued former Facebook Marketing Director, Randi Zuckerberg. “People behave a lot better when they have their real names down. … I think people hide behind anonymity and they feel like they can say whatever they want behind closed doors.” For years, the national discussion has gone up and back, between critics who say that anonymity is a fundamental right of privacy and necessary for political dissidents, and social networks who worry about online bullying and impact that trolls have on their community.

Enough theorizing, there’s actually good evidence to inform the debate. For 4 years, Koreans enacted increasingly stiff real-name commenting laws, first for political websites in 2003, then for all websites receiving more than 300,000 viewers in 2007, and was finally tightened to 100,000 viewers a year later after online slander was cited in the suicide of a national figure. The policy, however, was ditched shortly after a Korean Communications Commission study found that it only decreased malicious comments by 0.9%. Korean sites were also inundated by hackers, presumably after valuable identities.

Further analysis by Carnegie Mellon’s Daegon Cho and Alessandro Acquisti, found that the policy actually increased the frequency of expletives in comments for some user demographics. While the policy reduced swearing and “anti-normative” behavior at the aggregate level by as much as 30%, individual users were not dismayed. “Light users”, who posted 1 or 2 comments, were most affected by the law, but “heavy” ones (11-16+ comments ) didn’t seem to mind.

Given that the Commission estimates that only 13% of comments are malicious, a mere 30% reduction only seems to clean up the muddied waters of comment systems a depressingly negligent amount.

The finding isn’t surprising: social science researchers have long known that participants eventually begin toignore cameras video taping their behavior. In other words, the presence of some phantom judgmental audience doesn’t seem to make us better versions of ourselves.

Categories
Learn

Stating the Obvious

by Joshua Porter  |   August 1st, 2012  |  shortlink: http://bokardo.com/p/2107

It could be that your users are always attentive, always aware of what’s going on with you and your product or service. They are always up-to-date with what you offer, where they are in their progress with you, what account they’re logged in with, what payment plan they’re on, and what they were doing last with your product.

Or, it could be that they’re just like the rest of us and trying to stay afloat while their attention is being pulled in a thousand directions at once and could use you reminding them what seems like it should be obvious.

A couple points about obvious:

  • Obvious almost always isn’t. With the sheer number of different world views people have these days one person’s obvious is another person’s revelation.
  • Nobody minds when we state the obvious. Not even geniuses. That’s because it’s a helpful part of normal human communication…where we set context in talking with others. It builds confidence that we understand each other and are on the same page. It is often necessary before jumping to that the next step in the lifecycle.
  • In UI design, obvious is usually about describing a user’s current state. As I wrote about in Designing for the Next Step, communicating the current state is a crucial part of preparing someone to take the next step. To gain confidence about where we might go we first need to know where we are.

The other day when I logged into Google on my iPhone I was presented with a simple little message telling me what account I logged in with. (I have three Google accounts…I think)

As a designer it would have been super easy to assume that this wasn’t necessary…indeed for a while Google didn’t tell you what account you logged in with, but then it became frustrating when you tried to access your Gmail or Calendar when you were logged in with a different account. By stating the obvious (that you just logged in with a certain account) Google is making it more likely that you don’t have this frustration anymore. (granted the mere fact that we log in with different accounts to the same service is a problem in itself…this is a decent solution for the current structure of Google’s service)

In short, stating the obvious too often gets a bad rap. But when the first priority of user interface design is clarity, often the most important thing we can do is to state the obvious.

Categories
Learn

Designing For Android: Tips And Techniques

By Jamie McDonald

http://mobile.smashingmagazine.com/2012/07/26/android-design-tips/

Android is an attractive platform for developers, but not all designers share our enthusiasm. Making an app look and feel great across hundreds of devices with different combinations of screen size, pixel density and aspect ratio is no mean feat. Android’s diversity provides plenty of challenges, but creating apps that run on an entire ecosystem of devices is rewarding too.

Android devices in various sizes.
There are hundreds of Android devices with different screen sizes and resolutions. (Image credit: Android Design. Used under Creative Commons license.)

At Novoda, we build Android software for brands, start-ups and device manufacturers. We often work with visual designers who are new to Android. The new Android Design site is the first resource we recommend. You should definitely check it out. However, there is plenty more to pick up! The goal is to create apps that people love to use. Thoughtful UX and aesthetically pleasing visual designs help us get there.

This article provides a set of practical tips and design considerations for creating Android apps. I’ve tried to include something useful whether you’re crafting pixel-perfect graphic assets, finding an optimal user flow or getting your hands dirty developing XML layouts.

Pixels

Visual design is hugely important in the perceived quality of an app. It might even improve usability. Most developers have some exposure to UI patterns, but developers with visual design skills are rare. They really need you. Delivering high-fidelity mock-ups, drawable resources (i.e. graphic assets) and guidance to developers is the best way to deliver an aesthetically pleasing experience to the end user.

Scale Nicely

Android is a platform of many screen densities. There is no set of resolutions to target, rather a density independent measurement scheme for graphics, widgets and layouts. This is covered in depth in a previous Smashing article and the official documentation, so I’ll just add a mention of this neat web tool for calculating density pixels.

Screen densities.
Optimize graphics for different screen densities. (Image credit: Android Design. Used under Creative Commons license.)

It’s not always practical to hand optimize graphic assets for each density. The platform can scale resources down reasonably well. However, it’s always worth testing designs on low-end devices and optimizing resources that scale badly.

Be State Friendly

Touch states provide important confirmation of clicks and selections. When customizing widgets such as buttons, it’s important to create drawables for all necessary states (such as default, focused, pressed and disabled). The focused state is essential user feedback on devices that support directional pad or trackball navigation.

Size is important too. Touch input is imprecise and fingers occlude the UI as they interact with the screen. Touch targets should normally be at least 45 density pixels in width and height.

Use Fonts

Android has two fonts: Droid Sans and Roboto. Roboto was released in Ice Cream Sandwich (Android 4). It’s been compared to Helvetica, but it’s a little condensed, which is great for small screens. You’re not limited to Roboto or Droid Sans, though. Any font can be packaged within an app in TTF format (with some memory overhead).

Roboto font.
Roboto is Android’s new font, introduced in Ice Cream Sandwich. (Image credit: Android Design. Used under Creative Commons license.)

Use 9-patch Drawables

9-patch drawables allow PNGs to stretch and scale nicely in pre-defined ways. Markings along the top and left edges define the stretchable areas. The padded content area can optionally be defined with markings along the bottom and right edges. 9-patches are essential for creating and customizing UI widgets.

Draw 9-patch.
Create scalable widgets with Draw 9-patch.

It’s possible to create 9-patches manually, but the Android SDK comes with an nice, simple tool called Draw 9-patch. This makes it quick and easy to convert a regular PNG in to a 9-patch. It highlights the stretchable area and displays previews of the resulting drawable with different widths and heights.

Handle Design Legacy

Honeycomb (Android 3) and Ice Cream Sandwich (Android 4) modernized Android’s visual design with the Holo theme. However, some device manufacturers have a poor reputation for keeping platform versions up-to-date. Some of today’s most popular devices will never be upgraded to Ice Cream Sandwich.

Meetup screenshot.
The Meetup app makes everybody feel at home with separate Gingerbread (Android 2.3) and Ice Cream Sandwich widgets.

So what can be done? There are two options. Deliver the current look, feel and experience to all devices or use a separate set of widgets styles and drawables for Gingerbread and below. Both approaches are valid. Would your users prefer modern or comfortably familiar?

Showcase the Brand

Sometimes clients fear that sticking to recognized UI design patterns will make their apps less distinctive. I think the opposite is true. As patterns like the action bar become ubiquitous, they fade into the background. Users can spend less time wondering how to use an app and more time appreciating how elegantly your app solved their problem. That experience is much more valuable for the brand than a one-of-a-kind UI for the sake of differentiation.

Color navigation screenshot.
The original Color app had an online FAQ for the UI controls. Make sure that navigation is intuitive.

Branding can be expressed through design of icons, drawables and widgets, as well as in the choice of colours and fonts. Subtle customization of the standard platform widgets can achieve a nice balance of brand values and platform consistency.

Create High-Fidelity Mock-Ups

High fidelity mock-ups are the best way to communicate visual design to developer responsible for implementation. The Android Design website provides templates in PSD and other formats. It’s important to try mock-ups out on real devices to confirm that they feel right, with UI components sensibly sized and placed. The Android Design Preview tool allows you to mirror mock-ups directly from your favourite design software to an attached Android device.

A practical approach for mock-ups is to work against the screen characteristics of the most popular devices. Ideally, create mock-ups for each alternative layout required by screen size or orientation.

Polish

Attention to detail is key. Become involved in the development process to ensure that your designs are realized. As a developer, I would always prefer to work with active designers than those who deliver mock-ups and resources before disappearing into thin air. Designs need to be iterated and refined as the app develops.

Animated transitions provide some visual polish that many Android apps lack. Developers might not include such things on their own initiative. Make them part of the design when they make sense. Aside from transitions, animations are a great way to keep users distracted or entertained when the app needs to make them wait.

User Experience

Android has patterns and conventions like any other platform. These help users to form expectations about how an unfamiliar app will behave. Porting an iOS experience directly to the Android platform almost always results in a poor user experience.

Back buttons in Android and iOS.
Back is a platform affordance in Android. In contrast, labeled back buttons within the app layout are the norm for iOS.

The back button is the best illustration of the interaction differences between Android and iOS. All Android devices have a hardware back button or on-screen navigation bar (including back button). This is universally available as a feature of the platform. Finding a back button within an Android app layout feels weird as an Android user. It makes me pause to think about which one to use and whether the behaviour will differ.

Design User Flows

At the very simplest level, Android apps consist of a stack of screens. You can navigate in to the stack with buttons, action bar icons and list items. The platform back button allows you to reverse out of the stack.

The action bar mirrors a web convention, where the app icon to the left of the action bar usually takes you to the top level of the app. However, there is also the up affordance, intended to take advantage of structural rather than temporal memory. This is represented by a backwards facing chevron to the left of the app icon. This signals that pressing the icon will navigate one level up in the information hierarchy.

Up affordance.
The up affordance allows the user to navigate up an information hierarchy instead of going to the top level of the app.

The purpose of the up affordance might be subtle at first. Android apps can have several entry points in addition to the launcher. The Intent system allows apps to deep link each other and home screen widgets or notifications might take you directly to specific content. The up affordance allows you to navigate up the information hierarchy regardless of where you came from.

Try user flows on potential users with wireframes or mock-ups and iterate. Prototypes on real devices are ideal because they allow you to test in realistic mobile environments. This might seem like a lot of effort, but remember, you only need to try things out with a few users.

Be Platform Consistent

UI patterns are your friend. It’s much better to think of these patterns as tools than constraints. Users would prefer not to have to learn to use your app, so patterns provide familiar hints about how to navigate and interact.

Action bar is the most widely adopted Android pattern. It tells you where you are and what you can do. It’s a native feature of the platform since Honeycomb and the excellent Action Bar Sherlock library makes it available on older platform versions too.

alt
An example of the dashboard and action bar patterns.

The dashboard pattern is also quite widely used. These grids of icons are usually presented to the user when they launch an app. Dashboards provide top level navigation and describe the primary areas of the app.

alt
I worked on the Songkick app, where we used a dashboard draw out the content of the app with full-bleed images.

The  workspaces pattern can be implemented with the ViewPager component. This allows users to swipe screens left and right between content. This can be used in conjunction with tabs to provide a more fluid browsing experience with tabbed data.

ViewPager swiping.
ViewPagers allow users to swipe left and right. Page indicators or tabs make this navigation discoverable.

The ribbon menu is an emerging navigation pattern. This allows us to launch the user directly into content and provide the top level navigation in a menu, which slides in from the left side of the screen when you press up.

Ribbon menu
The ribbon menu is an alternative to dashboard navigation.

Tablet optimized apps often take advantage of multi-pane layouts. A single tablet screen can display the content of several separate phone screens side by side. Optimising for tablets can involve creating several alternative layouts for different screen widths. Sections of UI can be designed once and laid out in different configurations for different screen sizes. Multi-pane layouts help to avoid overly wide list items and sparse layouts.

Multi-pane tablet layout
The Economist news app uses multi-pane tablet layouts so users can explore the hierarchy of content on a single screen.

These are familiar and proven UI patterns. They’re the best tools for starting to sketch out your app layouts and navigation. However, they shouldn’t discourage you from trying something new. Just ensure that the app behaves predictably.

Design Responsively

Android is a platform of many screen sizes. The devices that I can lay my hands on in our office compose a spectrum of screen sizes from 1.8 to 10.1 inches (as long as we ignore the Google TV). With variable screen area, Android has something in common with responsive web design. There is no getting away from the fact that design and implementation of a responsive experience across the full range of devices takes a lot of work. Supporting every screen is the ideal, but there are also sensible strategies for coping with the diversity of the platform.

Knowing a little about your target users and popular devices can help focus efforts and avoid premature optimisation. A good default strategy is to target popular, middle sized phones (3.2″ – 4.6″) and then optimize as necessary with alternate layouts and user flows for particularly small (<3″) devices and tablets.

It’s always best to be orientation agnostic. Some devices have physical keyboards that require the device to be held in landscape. The on-screen keyboard is also easier to use in landscape. Text entry on touch screens is awkward an error prone, so let’s at least give our users the benefit of the landscape keyboard.

Understand Mobile Interactions

People interact with mobile apps differently from websites or desktop software. Mobile apps rarely have the undivided attention of a user and most interactions use touch input, which is not as precise as we might like.

Mobile interactions can often be measured in seconds. We recently developed a location-based app that allows users to check-in at bars. We counted the clicks on user paths such as check-in, considering whether each step could be avoided or simplified. We specify everything that an app should do as user stories. The most frequent stories should be as quick and easy to accomplish as possible. It’s particularly important in this scenario, because the user might be under the influence of alcohol…

Optimize First Use

First launch experience is crucial. Apps are often installed in response to a real world problem. If the first run isn’t satisfying then the user might never return. If the app requires sign up, offer preview functionality so that users get a feel for the experience. They probably need to be convinced that it’s worth filling out that sign-up form. Also consider using analytics to measure points where users drop off in the launch and sign-up process.

Many apps launch with a tutorial. This is usually an admission that the app is too complicated, but if you’re sure that you need one, keep it brief and visual. You might also want to use analytics to confirm that a tutorial serving a purpose. Are users that complete the tutorial more active? How many users just skip the tutorial?

Bring the App to Play

User experience considerations shouldn’t end in the app. It’s worth putting a bit of thought in to the Google Play Store listing to ensure that it’s immediately obvious what the app does and why the user would want it.

These Graphic Asset Guidelines will help you to create promotional material suitable for the various contexts and scales in which they appear. Some of these graphics are a pre-requisite for being featured too.

Layouts, Styles and Themes

Android has a visual layout editor and it’s getting better all the time. However, I still find myself developing XML layouts by hand. This section gets down to implementation details, covering some best practices for crafting maintainable and performant layouts. Visual designers might want to skim this section, but some awareness of implementation details can’t hurt.

The most general purpose layouts are RelativeLayout and LinearLayoutRelativeLayout should be favoured for efficiency, whilst LinearLayout is useful for distributing space between views using weights. GridLayout was new in Honeycomb. This is useful for creating complex layouts on large screens without nesting. Nesting layouts too deep is bad for performance and code readability alike!

Let the Framework Do the Work

The Android framework provides automated resource switching based on folder structure. This means that you can have separate graphic assets and layouts for different screen sizes and densities by arranging them in the correct folders. It goes much further than that. For example, you could switch color resources for different platform versions or even animation durations for different screen sizes.

Resource folder structure.
The framework provides automatic resource switching.

Since Honeycomb, it’s also possible to switch resources on available screen width in density pixels. This is a move away from the bucketed small, normal, large and extra-large screen size switching. It facilitates responsive design and allows multiple layout switching points (perhaps switching to a tablet-optimized layout at 600dp with another alternative at 800dp). It’s typical to have multiple layout files with different configurations of the same components for different screen characteristics.

State list drawables make being state-friendly easy. These allow you to specify different drawables for different states of a UI component in an XML file. As mentioned earlier, representing states properly provides important user feedback.

01 <selector xmlns:android="http://schemas.android.com/apk/res/android">
02  
03   <item
04     android:state_focused="true"
05     android:state_pressed="true"
06     android:drawable="@drawable/my_button_pressed_focused" />
07  
08   <item
09     android:state_focused="false"
10     android:state_pressed="true"
11     android:drawable="@drawable/my_button_pressed" />
12  
13   <item
14     android:state_focused="true"
15     android:drawable="@drawable/my_button_focused" />
16  
17   <item
18     android:state_focused="false"
19     android:state_pressed="false"
20     android:drawable="@drawable/my_button_default" />
21  
22 </selector>

Extract Values

It’s good practice to keep layout XML clean of explicit colours and dimensions. These can be defined separately and referenced in your layouts. Defining colours and dimensions separately promotes visual consistency and makes things easier to change later on. Extracting these values allows switching of dimensions on different screen sizes, orientations and platform versions. This is useful for tweaking padding for small screens or increasing text size for readability on large screens, which tend to be held further away from the face. Perhaps res/values/dimens.xml contains:

<dimen name="my_text_size">16sp</dimen>

whilst res/values-sw600dp/dimens.xml contains:

<dimen name="my_text_size">20sp</dimen>.

Use Styles and Themes

A good technique to keep layout XML maintainable is to separate the styling concern from the positioning concern. Every View in a layout needs to have at least a width and height attribute. This results in a lot of boilerplate, which you can eliminate by inheriting from a set of base parent styles.

01 <style name="Match">
02   <item name="android:layout_width">match_parent</item>
03   <item name="android:layout_height">match_parent</item>
04 </style>
05  
06 <style name="Wrap">
07   <item name="android:layout_width">wrap_content</item>
08   <item name="android:layout_height">wrap_content</item>
09 </style>
10  
11 <style
12   name="MatchHeight"
13   parent="Match">
14   <item name="android:layout_width">wrap_content</item>
15 </style>
16  
17 <style
18   name="MatchWidth"
19   parent="Match">
20   <item name="android:layout_height">wrap_content</item>
21 </style>

Recurring sets of attributes can be moved into styles. Widget styles that occur almost universally throughout the app can be moved into the theme. If a particular type of button always has the same text color and padding, it’s much cleaner to specify the style than duplicate these attributes for each occurrence.

1 <style
2   name="MyButtonStyle"
3   parent="MatchWidth">
4   <item name="android:padding">@dimen/my_button_padding</item>
5   <item name="android:textColor">@color/my_button_text_color</item>
6 </style>

We save four lines of attributes when we add the button to a layout. The layout file can be concerned with just the positioning and unique attributes of widgets.

1 <Button
2   android:id="@+id/my_button"
3   style="@style/MyButtonStyle"
4   android:text="Hello, styled world!">

You can take this further by overriding default button style in a theme and applying it to an Activity or the entire app in the AndroidManifest.xml.

01 <style
02   name="MyTheme"
03   parent="@android:style/Theme.Holo">
04   <item name="android:buttonStyle">@style/MyButtonStyle</item>
05 </style>
06  
07 <style
08   name="MyButtonStyle"
09   parent="@android:style/Widget.Button">
10   <item name="android:padding">@dimen/my_button_padding</item>
11   <item name="android:textColor">@color/my_button_text_color</item>
12 </style>

Optimize

The include and merge XML tags allow you to drop reusable sections of UI into your layouts, minimizing duplicate XML when the same set of views occurs in multiple layout configurations.

1 <include
2   layout="@layout/my_layout"
3   style="@style/MatchWidth" />

A relatively new addition to the Android Developer Tools is Lint. This tool scans the resources in a project and creates warnings about potential performance optimizations and unused or duplicated resources. This is incredibly useful for eliminating clutter as an app changes over time and it’s certainly worth checking lint for warnings regularly during your development process.

Debug

Sometimes layouts just don’t turn out how you expected. It can be hard to spot bugs amongst all those angle brackets. This is where Hierarchy Viewer comes in. This tool allows you to inspect the layout tree of an app running in the emulator. You can inspect the detailed properties of each view.

Hierarchy Viewer.
Inspect your layout trees with Hierarchy Viewer. Those colored dots can tell you about your layout performance.

Hierarchy Viewer has a couple neat tricks for visual designers too. It allows you to inspect screens in zoomed pixel perfect mode and export the layers of a layout as a PSD.

Conclusion

So you’ve been introduced to the platform and the tools. What next? Ultimately, the best way to get a feel for Android is to use it every day. The most satisfying app designs have a few things in common: platform consistency, attention to detail and clean visual design. The first two, at least, can be picked up by using and analysing existing Android apps.

Android has come a long way in the last few years. The platform and the apps have become gradually more refined. Functionality is not enough at this point. There are almost half a million other apps out there, and users want polish.

Resources

(jc)