Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android Design

developer.android.com

Post reply on HN
Print view View original

71–80 of 143 posts

Re: Android Design

#71

Post by keeperofdakeys »

nightpool wrote: post #39
rryan wrote: post #26

Earlier quoted context omitted.

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 wit…

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?

You would be able to tell if the user had previously used the app, gotten to a state, switched out, then went back to the app to find that state or if the application was pushed to a certain state when it was opened.

Personally though, I would prefer the back button system-wide only. You can easily provide a UI element to take you to the top of the stack (especially since when an app is forced into a state, you only want to get to the top of the stack). Sometimes I even get confused when the back button takes me back a webpage in the browser.

Re: Android Design

#72

Post by [deleted] »

Pewpewarrows wrote: post #9

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…

[deleted]

Re: Android Design

#73

Post by fufulabs »

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.

Re: Android Design

#74

Post by greggman »

Pewpewarrows wrote: post #9

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…

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.

Re: Android Design

#75

Post by zalew »

dprice1 wrote: post #62
jc4p wrote: post #19

Earlier quoted context omitted.

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

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 sche…

I'll sound like wierdo, but I always set uneven minutes to alarms, so there's less chance they overlap each others' snooze alerts. (yep, I have a problem with getting up and have to set up 3 alarms next to each other)

Re: Android Design

#76

Post by jc4p »

BrianHV wrote: post #38
jc4p wrote: post #22

Earlier quoted context omitted.

If you scroll them they actually remove the arrows and make a lot more sense. Before you drag: http://i.imgur.com/4MUXO.png After you press to drag: http://i.imgur.com/BqXMY.png To be fair, it's a huge improvement over: http://i.imgur.com/2exF7.png

As a day 1 Droid user after 10 years on Palm OS, I was stunned that the control in your third picture made it into a release, and even more stunned it persisted so long. On Palm OS you could pick a time with a maximum of three taps. There's no reason it should take more than five: one for each digit plus AM/PM. I'm not a fan of the swiping, but you're right. It is a huge improvement.

At my job the application we're currently working on is aimed for Android 2.1 and above so we can't the new TimePickerDialog.

I actually had testers come up to me and report bugs about the Android TimePickerDialog as bugs in our application saying that it didn't work as expected and it was against the UI specifications (which of course only have pictures for the iPhone version of the application).

I had to actually replace them with two dropdown sliders and a button so that the testers would be happy.

Re: Android Design

#77

Post by nl »

mhaymo wrote: post #60
nl wrote: post #59

Earlier quoted context omitted.

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 t…

Does that second part really apply to mobile development though? Most people only use one phone, or maybe two, for anything more involved than making a call.

They also use a tablet or two, maybe an ebook reader, maybe a TV running the same OS, etc etc.

Re: Android Design

#78

Post by nl »

duckworth wrote: post #65
nl wrote: post #54

Earlier quoted context omitted.

This consistently confuses me too (and I much prefer it when application insert artificial pages). I've thought about it some, and I think the problem is that the back button lacks the concept of context . In the music app example, when I first use it I get the front screen, then choose a song. Then I press the home button, put my phone away and at some point the song stops. Now, some hours later I open up the music…

The biggest problem for me is the uncertainty and inconsistency. Do you always remember the previous screen you were on in any app hours ago? What if you got to the song from some other screen? I would constantly have to "guess", what is this app going to do, take me back to where I previously was or to a higher level in the app. It needs to be consistant, back is back and navigating within the app needs to be obviou…

The back button in browsers is often used as analogy, but how many tabs/windows do you have open in your browser? What if pressing the back button in the browser switched you to a word processor because that is what you were looking at before.

Re: Android Design

#79

Post by radley »

evanw wrote: post #41

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 a…

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

Re: Android Design

#80

Post by feralchimp »

wattjustin wrote: post #8
kevinh wrote: post #4

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.

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.

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."
Post reply on HN