9 ms·

As an owner of a Nexus One, I have to say this is one of the downfalls of Android. The lack of an equivalent "Human Interface Guidelines" that there is for iPho

As an owner of a Nexus One, I have to say this is one of the downfalls of Android. The lack of an equivalent "Human Interface Guidelines" that there is for iPhone and shockingly, the app approval process leads to a very inconsistent experience (due to ambiguous cases like this) between different applications; resulting in a poorer user-experience.

lftl 16y ago
I'd go one step further and say that some of this is even a design flaw in the platform. Depending on developers to check a system setting to see if they should make updates is absolutely backwards. The OS should provide an API that allows an app to request an update, but is denied if the user's settings don't allow it.
jparise 16y ago
There actually are Android User Interface Guidelines, albeit less comprehensive than Apple's equivalent: http://developer.android.com/guide/practices/ui_guidelines/index.html http://developer.android.com/guide/practices/ui_guidelines/i... ... but it is certainly true that there is no review or enforcement mechanism in place to help developers conform to these guidelines.
- eli 16y ago
  It's also just that Android is an immature platform. Apple has no way of enforcing its UX guildelines on OS X apps, but yet most applications are at least pretty close. (well, mostly)
  - glhaynes 16y ago
    Could also be a matter of developer cultures.
    - macrael 16y ago
      I think that is a fair reason for the current state of Mac applications, as theirs is a cultured built over many years between a relatively small number of people. But the iPhone has brought a hoard of developers who are new to the platform, so I find it hard to believe that a real, distinct culture has formed yet when compared to Android developers.
barrkel 16y ago
I'm less concerned by the UI. I think the market will gradually sort out; and I don't really mind that my file manager has a distinct look to my twitter feed, etc. I am more bothered by the chaos on the SD card, and the apparently complete lack of guidance from Google on standard locations. It's just a mess of root directory folders of arbitrary names. You hope that your selected media directory names won't conflict with something that an app may choose in the future. (I personally use _music, _video etc. both to avoid conflict and to come up top in most alphabetical listings.)
- whalesalad 16y ago
  That's interesting.. because while I agree, I rarely look inside of my SD card. I've rooted too, so use it frequently for that purpose (flashing a rom). I agree more with the previous commenter though, because while Android does have their own UI guidelines, no one seems to follow them. There are a ton of really ugly and poorly designed (not just in a pixel sense, but workflow sense) Android apps out there =(
- blasdel 16y ago
  The SD card in Android is a gibbering nightmare in far more ways than that. For starters, that it's necessary at all! The first devices all had only 256mb of flash, but then the OS got bigger than that (can't upgrade older devices cleanly!), so they just doubled that to 512mb instead of doing anything sensible. Is there a single "Google Experience" Android device with more built-in Flash than that? What's worse is that they use it sparingly themselves but essentially force everyone else to -- Apps don't fit in the onboard flash, you can't even run Apps from the SD card, so everyone has to hack together their own asset system. Now the SD card isn't removable without breaking your running apps! It's a heap of ill-considered shit. Nobody would even propose these idiocies at Apple, much less get them past their manager. Even Windows Mobile wasn't this bad, but mostly just because they didn't try to do very much. The Android team thinks they're clever -- but when the WM diaspora (http://www.xda-developers.com/ http://www.xda-developers.com/) are the community that fixes up your shit, you're clearly not.
  - torpor 16y ago
jsz0 16y ago
They need to start moving away from using the Menu button. It's silly to have this big touchscreen that requires physical button presses so often. Tap, Menu, Tap, Menu, Tap. It's just not a smooth experience.
- nuclear_eclipse 16y ago
  I disagree completely; it's silly to have a big touchscreen that's filled with buttons to do things that aren't part of the normal application workflow. Having a standardized Back button allows me to reflexively hit a button with the expectation of returning to the previous screen without needing to pay attention to what application I'm using or where the UI designer decided to place the button onscreen. Having a standardized Menu button allows developers to place options or advanced workflow mechanics in an easily-discoverable location without needing to dedicate screen space to more buttons. This means more of the gorgeous touchscreen can be devoted to content I care about, and not the buttons that every application should have in the first place.
  - sagarm 16y ago
    Having a standardized back button means that when I hit "back," I have* a hard time predicting what it's going to do. Same for "menu." Sometimes "back" goes back in history (e.g., browser), sometimes it goes back to the last activity (if I got here via a notification). Menu doesn't always work, and I have to tap it to see if what I want to do is in the list of options. The iPhone's approach of putting these buttons on the screen has the major advantage that they are only visible when they actually have a purpose. Usually, the buttons are also labelled more specifically than simply "back" or "menu." For example, if you're looking at your folders in the Mail app, the back-equivalent button is labeled with "Accounts," indicating that hitting it will take you back to the accounts list. Also, the lack of a "menu" button discourages developers from just shoving everything into a menu. The result is that more common operations end up directly accessible (and immediately visible), while less common operations (if any) are usually tucked under a menu-equivalent "more" button. The potential inconsistency in semantically-similar button placement between applications is mitigated through HIG enforcement. In practice, it's not an issue. tl;dr: putting buttons on the screen instead of using physical buttons increases predictability. * That said, I've gotten pretty good at predicting what back will do after several weeks of using my device (with the notable exception of GMail, which breaks back button behavior spectacularly). This was a huge pain point when I first got my device, though.

lftl 16y ago

I'd go one step further and say that some of this is even a design flaw in the platform. Depending on developers to check a system setting to see if they should make updates is absolutely backwards. The OS should provide an API that allows an app to request an update, but is denied if the user's settings don't allow it.

jparise 16y ago

There actually are Android User Interface Guidelines, albeit less comprehensive than Apple's equivalent: http://developer.android.com/guide/practices/ui_guidelines/index.html http://developer.android.com/guide/practices/ui_guidelines/i... ... but it is certainly true that there is no review or enforcement mechanism in place to help developers conform to these guidelines.

eli 16y ago
It's also just that Android is an immature platform. Apple has no way of enforcing its UX guildelines on OS X apps, but yet most applications are at least pretty close. (well, mostly)
- glhaynes 16y ago
  Could also be a matter of developer cultures.
  - macrael 16y ago
    I think that is a fair reason for the current state of Mac applications, as theirs is a cultured built over many years between a relatively small number of people. But the iPhone has brought a hoard of developers who are new to the platform, so I find it hard to believe that a real, distinct culture has formed yet when compared to Android developers.

barrkel 16y ago

I'm less concerned by the UI. I think the market will gradually sort out; and I don't really mind that my file manager has a distinct look to my twitter feed, etc. I am more bothered by the chaos on the SD card, and the apparently complete lack of guidance from Google on standard locations. It's just a mess of root directory folders of arbitrary names. You hope that your selected media directory names won't conflict with something that an app may choose in the future. (I personally use _music, _video etc. both to avoid conflict and to come up top in most alphabetical listings.)

whalesalad 16y ago
That's interesting.. because while I agree, I rarely look inside of my SD card. I've rooted too, so use it frequently for that purpose (flashing a rom). I agree more with the previous commenter though, because while Android does have their own UI guidelines, no one seems to follow them. There are a ton of really ugly and poorly designed (not just in a pixel sense, but workflow sense) Android apps out there =(
blasdel 16y ago
The SD card in Android is a gibbering nightmare in far more ways than that. For starters, that it's necessary at all! The first devices all had only 256mb of flash, but then the OS got bigger than that (can't upgrade older devices cleanly!), so they just doubled that to 512mb instead of doing anything sensible. Is there a single "Google Experience" Android device with more built-in Flash than that? What's worse is that they use it sparingly themselves but essentially force everyone else to -- Apps don't fit in the onboard flash, you can't even run Apps from the SD card, so everyone has to hack together their own asset system. Now the SD card isn't removable without breaking your running apps! It's a heap of ill-considered shit. Nobody would even propose these idiocies at Apple, much less get them past their manager. Even Windows Mobile wasn't this bad, but mostly just because they didn't try to do very much. The Android team thinks they're clever -- but when the WM diaspora (http://www.xda-developers.com/ http://www.xda-developers.com/) are the community that fixes up your shit, you're clearly not.
- torpor 16y ago

jsz0 16y ago

They need to start moving away from using the Menu button. It's silly to have this big touchscreen that requires physical button presses so often. Tap, Menu, Tap, Menu, Tap. It's just not a smooth experience.

nuclear_eclipse 16y ago
I disagree completely; it's silly to have a big touchscreen that's filled with buttons to do things that aren't part of the normal application workflow. Having a standardized Back button allows me to reflexively hit a button with the expectation of returning to the previous screen without needing to pay attention to what application I'm using or where the UI designer decided to place the button onscreen. Having a standardized Menu button allows developers to place options or advanced workflow mechanics in an easily-discoverable location without needing to dedicate screen space to more buttons. This means more of the gorgeous touchscreen can be devoted to content I care about, and not the buttons that every application should have in the first place.
- sagarm 16y ago
  Having a standardized back button means that when I hit "back," I have* a hard time predicting what it's going to do. Same for "menu." Sometimes "back" goes back in history (e.g., browser), sometimes it goes back to the last activity (if I got here via a notification). Menu doesn't always work, and I have to tap it to see if what I want to do is in the list of options. The iPhone's approach of putting these buttons on the screen has the major advantage that they are only visible when they actually have a purpose. Usually, the buttons are also labelled more specifically than simply "back" or "menu." For example, if you're looking at your folders in the Mail app, the back-equivalent button is labeled with "Accounts," indicating that hitting it will take you back to the accounts list. Also, the lack of a "menu" button discourages developers from just shoving everything into a menu. The result is that more common operations end up directly accessible (and immediately visible), while less common operations (if any) are usually tucked under a menu-equivalent "more" button. The potential inconsistency in semantically-similar button placement between applications is mitigated through HIG enforcement. In practice, it's not an issue. tl;dr: putting buttons on the screen instead of using physical buttons increases predictability. * That said, I've gotten pretty good at predicting what back will do after several weeks of using my device (with the notable exception of GMail, which breaks back button behavior spectacularly). This was a huge pain point when I first got my device, though.