Markdown Cheat Sheet

# Headline 1
## Headline 2
### Headline 3

~~strike through~~

[link text](

> Quote text
***Johnny Author***

![image alt text](image url)
***Image caption, description***

Horizontal rule

Inline Code
`var name = "John Doe";`

Code block with syntax highlighting
``` codelanguage
function foo() {
  return bar;

Bulleted list
- item 1
- item 2
- item 3

Numbered list
1. item 1
2. item 2
3. item 3

The Holo Grail?

Android Design Guidelines: A Realistic Approach

The Discussion

Users and even developers seem to be still uneasy with design guidelines when it comes to building mobile software, especially with the Android platform. The design guidelines published by Google give an amazing perspective into the thought process behind the system user experience design. However, there’s definitely some confusion around what to do with these guidelines.

Design guidelines: The Holy Grail for developers?

I hear this one frequently. It’s at the heart of many design arguments among different companies’ teams and even members of the community. Users and developers are sticking to the term “Holo” in a very passionate way. I would even argue that the term has taken on more than it actually is.

A personal example: Opoloo has an application on the Play Store called “Timer”: a very simple countdown timer that closely follows Holo design. We released a dark theme for the application after having received a significant amount of requests from our users. In this dark theme we decided we would go with an orange color instead of the blue we used in our light theme. The amount of emails we received asking for a dark theme that contains the Holo Blue were overwhelming. The main reason for them requesting the blue color (as explicitly stated in the requests) was that they thought only blue could really be considered Holo. This was my first experience with the very passionate Holo fan. And yes: there’s a lot of them.

I don’t agree with the argument that our decision to use orange instead of blue was against the design guidelines. Here’s an excerpt from the design guidelines — it is the first paragraph on the ‘Color’ page.

“Use color primarily for emphasis. Choose colors that fit with your brand and provide good contrast between visual components. Note that red and green may be indistinguishable to color blind users.”

My idea during the building process was that, in the dark theme, the orange provided a good contrast against the darker background. The feedback we received was not what I expected. Users were shocked we could make such a mistake.

It was not a mistake. The use of color is extremely important in UI design and this is not dictated by Google. There are no constraints for colors to be used in applications. Especially with a strong branding, color is absolutely something to get right.

May I ignore the guidelines if they don’t fit my purpose?

This is a very tricky question. After all, they are design guidelines, not strict rules. On the other hand, straying too far from the design guidelines could alienate your users on the platform they use everyday. This could have a very negative impact on your product, especially in a competitive mobile environment. Among the most important areas of the design guidelines that should only be ignored at your own peril are navigation, selections, notifications and app structure. Interestingly enough, most of these do not necessarily dictate UI design. The most important concepts center around user experience. You want your app to behave like it belongs on the platform.

How you design the different elements to fit your brand is where you can help set your app apart from others. Just because every app has an action bar does not mean every app looks the same. There’s a lot of freedom within the structures provided, so spending time on polishing content presentation is sure to make your app unique. One particular design pattern seen more recently in applications is the fly-out menu (the one that slides out from the left or right of the screen). Personally, I have never felt this works in the context of all the other navigation structures on Android. Even certain teams inside Google have tried to implement this pattern. It feels very foreign to me, mostly because each implementation does something different and users are left guessing. Before you dive into using this method, spend some time thinking to see if you can work navigation differently. Challenging, yes, but it could be very rewarding.

The guidelines as a useful resource

The entire “Getting Started” section focuses on creative vision, design principles, and the UI overview. None of these sections tell you what colors to use, how tall to make your content items, or what type of navigation controls to use. They simply provide you with an understanding of Android as a platform. In further sections they give recommendations on sizing items, typography and iconography, especially in places where your application will display items in the context of the System UI. It won’t look very appealing if you decide to have a red notification icon when the rest of the icons on the user’s phone show in white. In your application you have the freedom to choose even the color of the actionbar icons you use. Fitting the style in the guidelines is the way to go, but nothing says they have to be white or gray. This is great for your users because the feel of the application is like the others on their phone and you are able to use branding and content to make it different. The idea is to be consistent with what you do. Changing how users access settings, contextual menus and so on, could impact the their ability to find those features in your app. The most important take-away from the design guidelines is not how to design your app, it is how to design the user experience.

An Exercise

The best way to work with the design guidelines is to spend time with them. Take something like a book journal application. An application where users can keep track of the books they have read. Think of this application in terms of Android navigation and get creative with the content side of the application. Feel free to mock screens up and share them on the Google+ link for this post. I think you’ll be surprised with the different designs and styles people come up with, even when thinking in terms of the same design guidelines.

Publication Paradigms for Longform Web Content

Transitioning from a blog to an online magazine

Lines 1.0 – Simple Responsive Publishing for Ruby on Rails


Sie erreichen uns per . Wir publizieren unregelmäßig auf unserem Blog, sowie Github und Dribbble.