Android Design

http://developer.android.com/design/index.html

by rtsuk • 15 years ago

437 137 15 years ago

developer.android.com

aw3c2• 15 years ago

I know it is silly and offtopic but that gorgeous website's navigation does not work without Javascript for no good reason.

alexchamberlain2• 15 years ago

I like the density-independent pixel concept...

kevinh• 15 years ago

The website felt odd to me. It's clearly aimed at developers, given the subject material, but it felt like it was written as an ad for prospective buyers.

It listed a bunch of features and user interface methods that apps should have, but I couldn't find any resource for actually implementing what they suggested, apart from the link to the android developer page at the end.

alexchamberlain2• 15 years ago

Isn't it for Designers, rather than Developers?

notatoad2• 15 years ago

Designers, managers, or any other project stakeholders. Many of whom may have the same understanding as customers.

wattjustin• 15 years ago

I completely agree. The wording is so basic and kind of insulting as seen here for instance, "Text fields allow the user to type text into your app. They can be either single line or multi-line." Very elementary for either a developer or a designer to read.

feralchimp2• 15 years ago

If the goal is to bring devs in from other platforms, who might have all kinds of crazy notions about what Android dev entails, erring on the side of over-simplification will give more people the sense that "hey yeah, not so hard."

aChrisSmith• 15 years ago

I think it might be too early to pass judgement. I would hope that over time Google releases sample applications, better widgets, and so on to take care of the boilerplate. (Similar to HTML "grab and go" type sites.)

wmf• 15 years ago

Do they have a schedule for when Google's apps will follow these guidelines?

deniz• 15 years ago

This really appears to be for Android 4.0+. Google's core apps follow these guidelines but Android 2.3 down seems to be left behind.

I'm not sure as an Android developer I'm ready to leave those users behind just yet which means a lot of extra work maintaining 2 different sets of UI code. The action bar is the killer.

jc4p6• 15 years ago

As an Android developer for many years I was excited when I read the blog post about the site. When I went to the site, I was very disappointed. I've spent the better part of 10 minutes on the site so far and haven't seen anything other than marketing text and screenshots of what my phone looks like.

How do I make these "beautiful designs" work across all Android phones? How do I use an Actionbar on a non 3.0+ device without external libraries? How can I supply a consistent look and behavior for my application when some android OEM keyboards don't even offer the same modules as other ones?

How am I supposed to follow these guidelines when every Google application has a different implementation of the Actionbar itself?

Pewpewarrows2• 15 years ago

The link at the bottom to the core developer site shows you how to implement most, if not all, of what they discuss here. Though it would be nice if they had links interspersed throughout the design text to their tutorials and API guides about the UI features.

http://developer.android.com/index.html

jc4p6• 15 years ago

That's definitely true, I don't know why they didn't put a "click here for more technical info!" next to each point.

The things that really bother me are:

1. If I implement one of the new themes they're discussing on the linked page, it only works in 3.9% of Android phones on the market, so if I want my apps to look like Google's on older phones I'm left to implement my own version of the themes. This is the same thing that happened when they announced "Homepages with square buttons for activities are the new way you should do everything!" and didn't release source code for how to do it for years afterwards with the Google I/O app, so every app that tried it did it a different way.

2. How am I supposed to use the action bar if Google's own applications can't decide on how to use it? Look at the "What's up with the bar" section of this blogpost: http://minming.posterous.com/google-currents-yet-another-con...

drivebyacct25• 15 years ago

The announcement for and docs of the Action Bar specifically point to libraries that can be imported pre-3.0 to provide the Action Bar.

veeti2• 15 years ago

You mean the ActionBarCompat example which is so minimal that only the simplest apps can use it? It's lacking almost every feature of the action bar.

joshsharp• 15 years ago

Agreed. Very frustrating for "building blocks" to show things like "scrollable tabs" that I'd quite like to use, where in fact no such standard implementation seems to exist! It's all well and good to display UI best practices, but give us the actual widgets you're talking about, otherwise the whole thing is pointless.

mdwrigh22• 15 years ago

Are you talking about a ViewPager?

http://android-developers.blogspot.com/2011/08/horizontal-vi...

notatoad2• 15 years ago

Guidelines are not tutorials. This might not be what you wanted, but this is what a design guidelines document looks like.

Pewpewarrows2• 15 years ago

This is a long overdue but very well put-together UI and Usability Guide for Android Developers. My only qualm from reading it thus far is the very last section under Navigation [1] regarding System-to-app navigation:

"For the Back key, you should make navigation more predictably [sic] by inserting into the task's back stack the complete upward navigation path to the app's topmost screen."

No. This piece of advice is the sole reason why the back button is confusing to users. Injecting activities artificially onto a user's Back Stack based on some arbitrary and imaginary path that they might have taken to get there is horrible. If I'm in the middle of reading a book and get an email notification, and I touch that notification to quickly read the email, that Back button better damn well take me BACK to what I was doing. Don't take me UP to the list of emails in my inbox. This is where the average user will become lost and not understand why they aren't taken back to reading their book, and will just end up touching Home out of frustration.

Bad Google!

[1] http://developer.android.com/design/patterns/navigation.html

estel• 15 years ago

I'm not sure where I stand on this; and it's possible the context should determine the behaviour. But equally, perhaps Google just want consistency?

jra101• 15 years ago

The ideal behavior would be if the app is launched via another app it should not touch the back stack. If I launch the email app from the home screen or app folder, it should populate the back stack so that hitting back brings me from the email I had open to the inbox.

dminor• 15 years ago

I happen to like this functionality and don't think it's confusing at all. As long as pressing back eventually gets me back to where I was before it's just fine.

barrkel• 15 years ago

In the email app (not the gmail app, the email app) I frequently have to press back 20 or more times, bouncing between earlier emails I read, before I get back to the app that I was on before the email notification popped up.

Whatever way you look at it, that's pathological behaviour.

natrius• 15 years ago

Google Voice follows (or used to, at least) your advice, which led to endless frustration. You'd tap a notification to read a text, then have no way at all to get to the main screen of the Google Voice app. In Android 4.0, Google Voice has an app-specific back button that helps, but I think Google's advice on this is correct.

kenjackson• 15 years ago

I'd think that the "typical" behavior would be to go back to what you were doing. I'm playing "Angry Birds", notification shows for text message. I click it, read the notification, hit back to get back to Angry Birds.

I don't see how inserting items between the text message and Angry Birds is a good idea.

What apps should have, is a way to always get to the apps main screen in the app. But changing the back button behavior seems confusing.

rryan• 15 years ago

This was a huge frustration for me on 2.x. I'm glad they're suggesting that people insert fake activities to fix it.

Here's an example -- from the homescreen, click a Music widget. The Music app opens and shows the song I was listening to. I want to go back to the playlist I was playing from so I hit back. Instead, I'm dumped back to my home screen. you have to hit the Google Music icon in the top-left to go back within the Music app. I don't mind having to hit back a couple of times because I've learned that you can just keep hitting back and you'll eventually get where you were.

webjprgm• 15 years ago

I've only used an Android phone once for 5 min (my Mom got one for Christmas), but that was enough to run into Back button confusion.

My assumption was that it would take me up the stack, since when I entered the Mail program and navigated down, Back took me back up. But when I entered from some other place (like the settings app) then back wouldn't take me up to inboxes.

I'm sure it would have made more sense if I realized it was a system-wide Back and not an app-only Back.

nightpool• 15 years ago

There has to be some kind of middle ground here, some kind of way to do it that gives you quick access for transitory things, like email and text messages, but also lets you get back up the stack. Maybe if artificialy adding things to the stack was disabled when you're coming from notifications, but not otherwise?

romey• 15 years ago

I disagree. I think the confusion is caused by users not intuitively understanding the context of the android "back". In a web browser, if you click a link to a sub-page on a different domain, you don't expect the back button to take you to the home page of that domain, you expect to go to the previous site you were browsing. Do any android devices have something akin to the right click on the back button in web browsers, that shows the back stack?

russell_h• 15 years ago

The problem is that the "Back" button has replaced onscreen upward navigation in Android apps. This means that the back button cannot function strictly as a means of returning to your previous activity if upward navigation is going to be possible. The options are for apps to build upward navigation into their UI (how its done on the web) or for apps to push their entire navigation tree onto the stack, regardless of how you get to a given location. Google seems to be opting for the latter option.

gjulianm• 15 years ago

I think this in an interesting discussion. Sometimes the user presses back to go to the previous screen, sometimes to go to the parent element (i.e., when you're seeing an email and press back to return to your inbox).

For me, the best solution would be make the back button come back to the previous screen, ignoring where they are. So, if you are playing Angry Birds, tap an email notification and then press back, you return to Angry Birds. But, also, in screens in which the user may want to go to the parent element, developers should put a button to go "home". In the email screen, a button to go back to inbox, in the Music app a button to go to the Music app initial screen...

kefs2• 15 years ago

... or users can just be given the option and decide for themselves.

http://i.imgur.com/ym4W4.png

cuu5083• 15 years ago

I'd be wary of configuration settings like this, they sidestep the problem and create another one--you still have potentially confusing navigation and now there's more clutter in configuration screen. In this case, the configuration setting is badly named too, 'Manage "Back" button' makes sense to the developer, less so to the user.

There are useful settings that help me accomplish the task, and then there are not so useful settings where developer simply couldn't decide. I particulary dislike configuration UIs that devote whole section of toggles and switches for configuring the configuration screen itself.

nl6• 15 years ago

No, no.

Config settings like that are a way for lazy designers to avoid making hard decisions.

Joel Spolsky wrote about this over 10 years ago:

Every time you provide an option, you're asking the user to make a decision. That means they will have to think about something and decide about it. It's not necessarily a bad thing, but, in general, you should always try to minimize the number of decisions that people have to make.

and

"But wait!" you say. "It's important to have options for advanced users who want to tweak their environments!" In reality, it's not as important as you think. This reminds me of when I tried to switch to a Dvorak keyboard. The trouble was, I don't use one computer. I use all kinds of computers. I use other people's computers. I use three computers fairly regularly at home and three at work. I use computers in the test lab at work. The trouble with customizing your environment is that it just doesn't propagate, so it's not even worth the trouble.

http://www.joelonsoftware.com/uibook/chapters/fog0000000059....

fbailey• 15 years ago

Now that's only an option, if users understand what will happen and why they should change this setting. "Manage Back Button" is not an understandable option. So instead of solving the problem you just defered to the user. That's not design, that's just lazy.

greggman• 15 years ago

WRONG! :-)

The way you suggest is why Android's back is confusing. If I hand you my phone and put you on a particular screen and ask you "if you press back right now where will you end up" you have no idea

Even if it's your own phone if it's been a few minutes, hours since you last used an app you'll have no idea.

Here’s what I hope is an objective fact about the Android back button. IT’S NOT PREDICTABLE!

The way it works is that each app has a “stack” of screens. Pressing the back button pops the current screen off that stack revealing the screen below. If there are none you are taken to the home screen. The problem is let’s say you start the Messaging app. The first screen is “list” of conversations screen. You pick a conversation and now you are on the “conversation” screen. From the conversation screen you press “back” and you get the “list” screen. Press back again you get the “home” screen.

Now let’s take another senario. You are in the browser. You get a notification that you have a new message. You select the notification for the message. You are taken to the “conversation” screen. You press home and do something else, say listen to music. Later you decide you want to send a message to someone. You go the home screen and pick the messaging app. Since the app is still running you see the “conversation” screen. You press back you get the “home” screen. WTF!

In the first case it went “conversation”->”list” in the second case it went “conversation”->”home”

Notice in this case, even if you had an amazing memory and could remember that you happened to launch the messaging app from a notification an hour ago or last night or something you still have no direct way to get to the “list” screen. The only way there is to select the messaging app either from the home screen or the recently used list. You’ll get the “conversation” screen. You press “back” and you’ll exit the messaging app back to the “home” screen. Now you have to navigate the home screen to the screen that has the messaging app icon on it so you can re-launch the messaging app and have it start in on the “list” screen.

Android should never have had a back button in the first place. If there was no back button there'd be no way to make it inconsistent. Switching back to another app would be come the simple habit of holding home for a moment and picking the app you want to go back to and you'd always be able to predict where any button will take you.

I applaud them for trying to fix it but putting in the guidelines, which may or may not be read by the majority of devs, seems unlikely to fix the problem.

noveltyaccount• 15 years ago

Totally agree with you. WP7 behaves the way you describe.

nextparadigms4• 15 years ago

I agree. Please get rid of the way the back button currently works, Google. It should only go back within the app, and that's it. Just like your browser back button on your PC, doesn't affect any other app in the system.

And while you're at it, pretty consider getting rid of all the buttons altogether, and just use screen gestures, kind of like in N9's Meego. I keep getting this feeling that being there all the time, they are just wasting precious space.

babebridou2• 15 years ago

My motivation for debating the two uses of the back button is whether I prefer a smooth OS integration (back as in back in time) or whether I prefer displaying more ads and am willing to capture the user inside (back as in up within my app).

It has unfortunately little to do with UX, since both end up being confusing on edge cases (Astro's horribly enraging "press back twice to 'exit'", the conversation or gmail app issues people mentioned in this thread).

I personally tend to prefer back as in back in time but I know for sure opinions vary.

bookwormAT• 15 years ago

What confuses me about this guideline is it suggests the back button behaves the same way as the new up button introduced in Honeycomb?

This is what I was told at the Android developer labs in Paris last November, in a Session about Ice Cream Sandwich Design:

http://developer.android.com/guide/topics/ui/actionbar.html#...

schrototo• 15 years ago

Of course the real problem isn't which back button behavior too choose, it's that there's a choice to be made at all.

Both back button behaviors are perfectly valid and convincing arguments can be made for each, so the choice is pretty much arbitrary. But if Google doesn't enforce any particular behavior and leaves it up to the developers, the only possible result is confusion.

Additionally one could make the argument that the whole back button concept itself is inherently confusing, precisely because the right choice of behavior isn't obvious.

gbog• 15 years ago

Weird, I just read the docs and none of the comments seem to relatr. The guidelines from an app with hierarchy is to have back and up buttons one all pages but home, up is on top left, back is in nav bar, bottom left, and this even when they point to the same target. Back is about click history, up is about information architecture. It makes sense.

starwed2• 15 years ago

Since no one else has mentioned it, ICS has improved how you navigate among apps.

The three omnipresent buttons are now back, home, and recent apps. Recent apps pulls up a visual stack of everything you've used recently, so the ICS expectation would be that users would hit that key if they want to navigate among apps.

CrazedGeek• 15 years ago

How do phones with hardware buttons access the recent apps list? Same as in 2.3 (long-press home)?

drcube• 15 years ago

I like Android, but the back button is totally useless to me. It only works in the simplest of cases, namely when opening an app and not navigating beyond that, I know I can press the back button to get to the home screen.

Otherwise, my workflow basically goes: press home button, use the task manager to kill everything, then visit an app and navigate top-down to where I want to go. Rinse and repeat for the next app. Like others have been saying, the back button is inherently either arbitrary or confusing, and I don't know how to fix it.

It should be replaced as a permanent UI feature with a task switcher button. I don't know how a modern operating system can get by without some sort of taskbar equivalent. I need to know what apps are open, and be able to navigate to them and close them as needed. Why has this not been implemented? I'd suggest putting this into the slide down top bar if there weren't full screen apps that totally break this function. Therefore, I suggest replacing the back button with a task switcher. I won't be holding my breath.

ge0rg2• 15 years ago

Utterly worthless. This looks like a web designer on crack had too much time to promote the beauty of the new Android.

However, from a developer's point of view this is almost unusable. By not providing the according XML/Java code, we are forced to reimplement everything from scratch, making smaller and larger errors, introducing inconsistency and making the look and feel not quite the same between apps.

Then again, it fits well with the current way Google is doing UX design (http://minming.posterous.com/google-currents-yet-another-con...).

manmal2• 15 years ago

Some of the pieces DO work (48dp as hit-target is a good advice, and colour palette etc. is pretty usable). I think it's a good start for all the Android devs (non-designers) who put apps together which are 99% crappy looking. I am quite frustrated however that they do not tell us how to get the same behaviour on older devices - they should release a look-and-feel compatibility library or something. Actionbar is also very inflexible (tabs with buttons in one row, anyone? adjustable tab width?) and making the same code work for 2.x - 4.x devices is just plain spaghetti.

f7u12• 15 years ago

I found the site by way of an @AndroidDev tweet [1], and I was incredibly frustrated. Their old documentation [2] was completely useless, and this is even worse. Am I supposed to purchase and learn proprietary design tools to develop an effective Android app? This turns me off to the platform as a whole.

[1] https://twitter.com/#!/AndroidDev/status/157570583800971264

[2] http://developer.android.com/guide/practices/ui_guidelines/i...

drivebyacct25• 15 years ago

All of the UI elements are available in source provided by Google. Koush (on Twitter) tweeted with Tim Bray about them being split out into a more-easily-consumed library.

ge0rg2• 15 years ago

Yes, they are hiding somewhere in the multi-gigabyte Android source code. At least the basic default elements. And their style formatting.

And then there are the closed-source Google apps which at least slightly resemble the UX guidelines given on that site.

And then there are the more complicated UI elements which provoked the creation of fork projects to allow for the reusability and compatibility not provided by the Google devs, like http://actionbarsherlock.com/ and http://viewpagerindicator.com/

adpowers• 15 years ago

Ha! I love that they are using Hipster Ipsum:

http://developer.android.com/design/static/content/ui_overvi...

http://hipsteripsum.me/

emehrkay2• 15 years ago

I like the date picker

http://developer.android.com/design/building-blocks/pickers....

jc4p6• 15 years ago

Fun fact: the up and down arrows work exactly opposite how you expect them to.

emehrkay2• 15 years ago

Hilarious because i've been flip flopping on how they worked. The arrows seem to be a paradigm from mouse-based computing, can you scroll these lists like on ios?

dprice1• 15 years ago

To me the huge irritation with time picking in a lot of Android apps is that they usually force me to specify a fully populated "minutes" field. IIRC, in iOS most apps instead round to ~5 minute intervals. 99% of the time, that is what I want. If you round to 5 minute intervals, there are only 12 possible minute values, not 60. This makes it a lot less work to find what you want and get that calendar appointment scheduled or that alarm clock set up.

Samuel_Michon• 15 years ago

Looks a lot less intuitive than the UIDatePicker in iOS, which is styled like a slot machine [1].

Does anyone know whether you can manipulate the controls by dragging, or do you really have to use those little up and down buttons?

[1] http://blog.blackwhale.at/wp-content/uploads/2011/05/UIDateP...

jc4p6• 15 years ago

You can drag them.

See my other comment here: http://news.ycombinator.com/item?id=3458159

briguyd• 15 years ago

Swiping works just fine.

manmal2• 15 years ago

Swiping works, but due to its minimalistic design, I first expected it to count up when I swiped up - while it did the contrary. It behaves like the iOS slotmachine, but clearly the affordance is broken.

justincormack• 15 years ago

It is quite annoying, if you say want to move a meeting to next Tuesday you have to work out the date, as you get no day of week indicator. And changing date and also time involves two pickers. Every time I use it I wonder if it could be improved...

resnamen• 15 years ago

I despise it. One of my Gmail labels is set to sync content for 365 days. I nearly got RSI spinning that damn thing with my thumb until it hit 365.

sp3322• 15 years ago

Um, you can just tap the number and it will bring up a 10-key keypad. You can just type "365".

njs123453• 15 years ago

This is great! If apps start following this it should significantly improve the Android user experience, as well as making it much easier to design good Android apps.

krosaen• 15 years ago

I like this bit on using multipane layouts to be flexible on both tablets and mobile:

http://developer.android.com/design/patterns/multi-pane-layo...

Good advice for rich web apps too.

georgechen3• 15 years ago

Am I missing something? I'd like to get my hands on the templates, mocks, wirefames, etc. Let me play with those (as a designer) and I'll be able to better follow the specs and guidelines.

Note: Microsoft (for once) actually one-up Big G. here. They provide the PSD and fonts for Windows Phone 7 on MSDN + the UX Guidelines.

Also, for Apple, 3rd party made all the PSD and templates for them...

mdwrigh22• 15 years ago

There's some third party work done for Android as well: http://designmodo.com/android-kits-developers/

georgechen3• 15 years ago

Thanks. Nice. But since Big. G. is heavily pushing ICS, they should really put the ICS files up there.

amirkhella2• 15 years ago

I've recently updated Keynotopia templates to include Android ICS UI components for Keynote and PowerPoint (http://keynotopia.com/android-prototyping-templates/)

nielsandersen• 15 years ago

Great resources on your site. Should you ever feel inclined to port your stuff to Axure you have at least one paying customer right here.

njs123453• 15 years ago

One of the nice features of the Android hierarchy viewer (provided with the Android SDK) is that it lets you dump your app's visual structure as a PSD with layers - very useful for working with a designer. Ask your developer!

georgechen3• 15 years ago

I will! Thanks! I assume that's new in ICS?

nextparadigms4• 15 years ago

I agree. I don't understand why they aren't linking to those resources as well, or maybe I missed them.

amirkhella2• 15 years ago

I think this is the most consistent UI for Android so far. It still feels a bit more like a "style guide" rather than "human interface guidelines", but it's a great step forward.

Kudos

evanw• 15 years ago

Regarding the Design Principles page: http://developer.android.com/design/get-started/principles.h...

I love that they included the ICS home screen's "glass desktop" effect in the "Delight me in surprising ways" section (http://developer.android.com/design/static/content/principle...). It's a completely unimportant feature, but the first time I swiped past the edge of my rightmost homescreen and saw the effect, I appreciated the attention to detail.

Where I disagree is with their "Pictures are faster than words" suggestion. I completely agree that many things are best said with images, but I've had a hard time identifying the function of several features in the icon-driven UI's featured in both ICS and in new Google web redesign. In ICS's Gmail app, I'd understand the words "Mark Unread" much quicker than the "sealed envelope" icon which I had to experimentally discover.

It's also interesting to note that in ICS Gmail, Mark Unread is an icon and Report Spam is text, where in web Gmail, Mark Unread is text and Report Spam is a stop sign.

drivebyacct25• 15 years ago

I'm not saying it's right or good usability, but the new "picture based buttons" can be long-pressed for a textual toast-style popup that tells you what they do.

radley• 15 years ago

Google is heavy on logic but weak on intuition. Why their designs seem to look good but are hard to follow.

vlokshin• 15 years ago

Simply put, and coming from an Apple fan-boy, this is REALLY nicely done. I honestly think this will significantly improve the usability of the platform as a whole by attracting the right designer/developer talent.

JacobIrwin• 15 years ago

For Android/Google on web, it's possibly the most apple.com-like designed page I've seen yet.

swanson• 15 years ago

I kind of agree with the sentiment that a few others are having. I've spent the past 4 months working on an Android project and when I opened this page I was in shock.

Everything looks so awesome and shiny - but where is the actual implementation? Is this stuff just a ICS theme (I haven't used it myself as our app is in 2.2 land)?

Others pointed out to check the "Developer" link - but that is just the standard Android docs I've been digging through for months already. Searching for things like "Index Scrolling" (which would be awesome to add to an app) or "Switches" doesn't return anything useful - so what are the Building Blocks and how do I get them into my app?

This page should either a) include demos (or links to the demos if they exist already) or b) be embedded in the code docs (android.widget.GridView should show the screenshot and UI guidelines).

myko2• 15 years ago

I think by Index Scrolling it means to use the SectionIndexer interface: http://developer.android.com/reference/android/widget/Sectio...

It would be amazingly helpful if they would link from the 'Android Design' page to the docs exactly what they are talking about.

pax• 15 years ago

Why did choose to put 2 phones on the homepage? Because one phone has 3, the other 4 buttons? Isn't that still a bit redundant. (If it where not for a design-centric page it wouldn't have troubled me)

there• 15 years ago

because part of that site talks about compatibility with different devices.

the phone on the left is a nexus s, which has the (now) older style of dedicated hardware buttons. the nexus prime on the right is apparently what newer devices are supposed to have, which are software buttons that are actually just part of the main lcd and the operating system reserves a section of the screen to draw them in software.

the big benefits of the newer style are that they can be hidden while playing movies or in other situations where they are not needed, they can be rotated when the device is rotated, and, maybe most importantly, the operating system now gets to control which buttons are there and in what order they're in. an annoying thing about the hundreds of different android phones prior to this was that every manufacturer seemed to put the 3 or 4 hardware buttons in a random order that made them inconsistent.

rwc• 15 years ago

I know some will criticize this is ticky-tacky, but it's one small thing that, when added with a lot of other little details, make Android feel like it's still designed by engineers.

They've "touched nearly every pixel" and "App icons are works of art in their own right" but the contact name on their contacts icon is "Lorem Ipsum". Not exactly a warm, human feel.

http://developer.android.com/design/static/content/design_el...

alex_c• 15 years ago

"Lorem Ipsum" is more of a designer thing.

sp3322• 15 years ago

Lorem Ipsum is supposed to show you the "experience" of the design, and leave out any emotional or cognitive associations you might have with specific text. It's used as a content-free placeholder in design. It really has nothing to do with "engineers".

fufulabs• 15 years ago

Isn't ICS like just around 0.5%(or was it 5%) of Android handsets as of December 2011? This design guide is ALL about ICS and nothing about the 99% of the Android handsets used by people.

thetrendycyborg4• 15 years ago

in 2 years everyone will have ics or better. carrier contracts.

nailer• 15 years ago

That's kinda sad, compared to Apple, Microsoft, and RIM. ICS fixes bugs too. People shouldn't have to deal with them until they buy a new phone.

feralchimp2• 15 years ago

I'm going to assume the internet has already somehow collectively dealt with the fact that the Android name for a drop-down list control is a "Spinner."

thetrendycyborg4• 15 years ago

it doesn't always drop down. Sometimes it "drops" up, like if the element is at the bottom of the phone. You can "spin" through options. Makes sense.

problemspace• 15 years ago

I tried browsing this on my old Android phone... I couldn't get past the first page. I hope "people should be able to read your content" is one of the guidelines...

helpbygrace• 15 years ago

Does anyone know how to see Roboto font as anti-aliased in Windows7? In my windows 7, Roboto font looks really jagged and weird.

AliCollins• 15 years ago

Likewise on my XP Laptop in Chrome...and I have Roboto TrueType font installed. Then un-installed the font, and it looks far better!!

astrodust2• 15 years ago

"Android Design"

    .../index.html

It's the little things that matter. This is shameful for a company so big.

ranebo• 15 years ago

I'm confused, why does this matter?

astrodust2• 15 years ago

From a technical perspective, littering your URLs with implementation debris is not a good idea. What if you want to revamp the site, put it in a shiny CMS, and now it's in PHP or JSP or does it even matter? You have all these references to `index.html` you have to maintain or you'll be wrecking your linkage.

Bury those. If you're doing a plain HTML site, use MultiViews to hide the extensions. They're not important to the content.

When I see `index.html` in a URL, it's never a good sign. It's done by a sloppy "web designer" that knows how to use DreamWeaver and FTP things to the server. They make a tremendous mess for the next team that has to come along and somehow upgrade the site without breaking everything.

It's not 1998 any more. You can afford to script your pages, have clean URLs, and still get great performance.

kizza2• 15 years ago

Interesting how they make sure to say that you shouldn't use bottom tabs like in iOS. For my project I decided to do exactly that instead of using an Android standard action bar, because:

1:The bottom bar fits 5 items. An action bar needs to have the app name as well, which means it can't have 5 items anymore. Having a "More" option is just dumb.

2:The iOS bottom bar has text underneath its icons and the action bar doesn't. I'm afraid the icons I have aren't obvious enough without text.

3:This is a conversion from iOS so the images are already made

4:Getting an Android action bar to work on older versions is very difficult. The Android compatibility library doesn't help here, and the third party libraries I looked at were not mature enough. I'm doing this work as part of a fixed price contract so I can't waste days getting it to work reliably.

Bottom line: Android apps would look a lot better if doing things the right way was also the easiest way.

thetrendycyborg4• 15 years ago

you can break out tabs into a separate action bar or use scrollable tabs. You're using elements from another platform your users don't use. You're just going to confuse or annoy them.

kizza2• 15 years ago

For sure, but like I said, I don't have days to spend making half-baked action bar code work.

saket123• 15 years ago

This site is really useless. As an android developer I was hoping for more steps rather then another marketing docs. Its funny how little android provides out of the box and I have to just keep searching source to find how things are implemented and best way to implementing such designs. Sad state of affairs as I have to waste most of my time trying to understand these designs and corresponding code designs in source.

Another thing I hated about the website is how sparse it is in technical details. If Google really hopes us to make use to these pattern why not release some of these as widgets or templates.

fdb• 15 years ago

I find the "app structure" schematic (http://developer.android.com/design/patterns/app-structure.h...) a very useful visualization to see the screens of an app in one glance.

Any ideas how they made this schematic?

nodata• 15 years ago

I wish they'd make this searchable. This is from Google after all.

Does a button marked "on" indicate it is already on, or that pushing the button will make it "on"? I'd like to see that standardised.

buro9• 15 years ago

All we need now is an accessibility document for Android.

Accessibility is notably absent from the design doc.

funkyboy2• 15 years ago

Finally!. Isn't too late? Are OEM and carriers going to follow the same principles? Or they can build whatever skin/mess they want as they did so far?

funkyboy2• 15 years ago

Google, good work on the Android design guidelines, but is that enough to tame the wild west in the marketplace and the current "anarchy"?

Android Design

Related Stories