7 ms·

Android Bootstrap

150 points by dragos2 13y ago

Gnewt 13y ago
Why would one implement this instead of using Android's builtin widgets? Android apps have always felt better to me when they use the UI recommended in the Android style guide.
- avenger123 13y ago
  This is for mobile HTML 5 development. If one was using the native implementation, there would be no need for this as you have pointed out. This could be a good use case for sites that have a "mobile version" but don't want to/need to mimic the full android look but get close. EDIT: I am definitely wrong on this (didn't read the docs careful enough). Thanks for the correction on this everyone.
  - ctz 13y ago
    I don't think Android Bootstrap has anything to do with HTML5. It's a set of themes for native Android apps duplicating the style of Twitter Bootstrap.
    - dragos2 13y ago
      And it actually look very good. (https://dl.dropboxusercontent.com/u/5727009/screenshot-1384122081508.png https://dl.dropboxusercontent.com/u/5727009/screenshot-13841...)
      - mayanksinghal 13y ago
        I really can't differentiate between Disabled buttons and Rounded buttons. There would also be very little differentiation between the a basic button with no icon (because there isn't a good icon for everything) and the text input. Android design guidelines and 'language' is very different, and people expect the apps the buttosn to have some depth and clarity because of it. I, personally, would hate to have any of the apps that I use move to this style.
  - lnanek2 13y ago
    No it isn't. Read the README. It is a library for native Android apps to use.
  - alok-g 13y ago
    Responsive frameworks like Bootstrap are already designed to work across desktops and mobile devices including Android, so there would be less of a motivation to make it specifically for Android. This is a native app boilerplate that creates the look and feel of Bootstrap.
  - taspeotis 13y ago
    > This is for mobile HTML 5 development. This isn't for mobile HTML5 development.
- lnanek2 13y ago
  Agreed. We already have icon placement in TextEdit controls via the drawableLeft, etc. attributes. And if your app doesn't have a theme font of some sort you are better off using the Roboto system one so you don't look strange for no reason. I guess the only real use is for the icon font, but people were doing that already and it's best practice to generate one with just the symbols you need.
- lnanek2 13y ago
  Agreed. We already have icon placement in TextEdit controls via the drawableLeft, etc. attributes. And if your app doesn't have a theme font of some sort you are better off using the Roboto system one so you don't look strange for no reason.
- radley 13y ago
  Resources, not widgets. Because the built-in resources are very Google-brand looking. Big apps have their own style. They'll follow UI norms, but don't need to look like Google made the app.
  - estel 13y ago
    On the other hand, big apps with their own style probably have already chosen to not look like Bootstrap.
snyff 13y ago
Success button with an Apple logo... nicely played ;)
swanson 13y ago
Cool project! Unfortunate naming collision with Donn Felker's http://www.androidbootstrap.com/ http://www.androidbootstrap.com/ though :(
- hayksaakian 13y ago
  Having not clicked through, I upvoted thinking this discussion was about what you mentioned.
aferreira 13y ago
One thing that I like about Android is that developers can choose to minimally style buttons and similar UI elements and these differences will be applied to whatever the base device theme is. This means that users will get a consistent user experience throughout various applications and won't have to run around trying to figure out what's a button and what's a text input. Sadly, this project essentially destroys all of that work and something tells me it won't work correctly on the most customized devices (like the old Motorola RAZR running 2.3 for example). Nice idea but I don't think it makes much sense in it's current state.
- radley 13y ago
  Following UX/UI patterns make sense, but not design - especially if you plan to be cross platform.
  - thwarted 13y ago
    What's the logic here? If you're cross platform, most people are most likely not going to be using your app on more than one platform, so there's little to be gained from a "consistent experience across platforms" angle. It's rare that the same person or team is doing both iOS and Android development, and the languages and layout methods are different anyway, so there's little to be gained on the development side in terms of reuse. Maybe it makes sense if you only have one "mobile PM" who handles both, but this seems shortsighted considering how quickly the platforms change and, especially on Android, how many devices and carrier customized builds you need to test on. I suppose it makes sense from a branding perspective, but any designer worth their weight should be able to come up with a distinctive branded experience that doesn't revamp the entire, default, builtin experience on the device.
    - aferreira 13y ago
      I can see where he's coming from, my company is actually at fault on this exact point. The initial target was iOS and then clients requested Android compatibility as well. Designs for iOS are completed and implemented and are then re-used for Android. The excuse is 'consistent user experience' but really they just don't want to do the same job twice for a platform that generally has less usage and provides less profit (in our case at least). I took matters into my own hands and there are noticeable differences between the two applications. There was of course some backlash (I flat out refused to put a 'back' button on the action bar for example or move the sliding menu to the right side) but in general the look and feel is consistent across the two platforms. That doesn't (and won't) stop me from using native controls such as text inputs and dialogs that users on Android are quite familiar with. In case someone has no clue what the hell I'm talking about I'd be happy to share some screenshots via pm.
finalight 13y ago
no point having bootstrap for android since android API already have method for different platform version detection
bjoe_lewis 13y ago
I was looking for something exactly as this. Say, you want to building a quick-quick app for quick.com, supposedly native. This might actually work.

150 points by dragos2 13y ago

Gnewt 13y ago

Why would one implement this instead of using Android's builtin widgets? Android apps have always felt better to me when they use the UI recommended in the Android style guide.

avenger123 13y ago
This is for mobile HTML 5 development. If one was using the native implementation, there would be no need for this as you have pointed out. This could be a good use case for sites that have a "mobile version" but don't want to/need to mimic the full android look but get close. EDIT: I am definitely wrong on this (didn't read the docs careful enough). Thanks for the correction on this everyone.
- ctz 13y ago
  I don't think Android Bootstrap has anything to do with HTML5. It's a set of themes for native Android apps duplicating the style of Twitter Bootstrap.
  - dragos2 13y ago
    And it actually look very good. (https://dl.dropboxusercontent.com/u/5727009/screenshot-1384122081508.png https://dl.dropboxusercontent.com/u/5727009/screenshot-13841...)
    - mayanksinghal 13y ago
      I really can't differentiate between Disabled buttons and Rounded buttons. There would also be very little differentiation between the a basic button with no icon (because there isn't a good icon for everything) and the text input. Android design guidelines and 'language' is very different, and people expect the apps the buttosn to have some depth and clarity because of it. I, personally, would hate to have any of the apps that I use move to this style.
- lnanek2 13y ago
  No it isn't. Read the README. It is a library for native Android apps to use.
- alok-g 13y ago
  Responsive frameworks like Bootstrap are already designed to work across desktops and mobile devices including Android, so there would be less of a motivation to make it specifically for Android. This is a native app boilerplate that creates the look and feel of Bootstrap.
- taspeotis 13y ago
  > This is for mobile HTML 5 development. This isn't for mobile HTML5 development.
lnanek2 13y ago
Agreed. We already have icon placement in TextEdit controls via the drawableLeft, etc. attributes. And if your app doesn't have a theme font of some sort you are better off using the Roboto system one so you don't look strange for no reason. I guess the only real use is for the icon font, but people were doing that already and it's best practice to generate one with just the symbols you need.
lnanek2 13y ago
Agreed. We already have icon placement in TextEdit controls via the drawableLeft, etc. attributes. And if your app doesn't have a theme font of some sort you are better off using the Roboto system one so you don't look strange for no reason.
radley 13y ago
Resources, not widgets. Because the built-in resources are very Google-brand looking. Big apps have their own style. They'll follow UI norms, but don't need to look like Google made the app.
- estel 13y ago
  On the other hand, big apps with their own style probably have already chosen to not look like Bootstrap.

snyff 13y ago

Success button with an Apple logo... nicely played ;)

swanson 13y ago

Cool project! Unfortunate naming collision with Donn Felker's http://www.androidbootstrap.com/ http://www.androidbootstrap.com/ though :(

hayksaakian 13y ago
Having not clicked through, I upvoted thinking this discussion was about what you mentioned.

aferreira 13y ago

One thing that I like about Android is that developers can choose to minimally style buttons and similar UI elements and these differences will be applied to whatever the base device theme is. This means that users will get a consistent user experience throughout various applications and won't have to run around trying to figure out what's a button and what's a text input. Sadly, this project essentially destroys all of that work and something tells me it won't work correctly on the most customized devices (like the old Motorola RAZR running 2.3 for example). Nice idea but I don't think it makes much sense in it's current state.

radley 13y ago
Following UX/UI patterns make sense, but not design - especially if you plan to be cross platform.
- thwarted 13y ago
  What's the logic here? If you're cross platform, most people are most likely not going to be using your app on more than one platform, so there's little to be gained from a "consistent experience across platforms" angle. It's rare that the same person or team is doing both iOS and Android development, and the languages and layout methods are different anyway, so there's little to be gained on the development side in terms of reuse. Maybe it makes sense if you only have one "mobile PM" who handles both, but this seems shortsighted considering how quickly the platforms change and, especially on Android, how many devices and carrier customized builds you need to test on. I suppose it makes sense from a branding perspective, but any designer worth their weight should be able to come up with a distinctive branded experience that doesn't revamp the entire, default, builtin experience on the device.
  - aferreira 13y ago
    I can see where he's coming from, my company is actually at fault on this exact point. The initial target was iOS and then clients requested Android compatibility as well. Designs for iOS are completed and implemented and are then re-used for Android. The excuse is 'consistent user experience' but really they just don't want to do the same job twice for a platform that generally has less usage and provides less profit (in our case at least). I took matters into my own hands and there are noticeable differences between the two applications. There was of course some backlash (I flat out refused to put a 'back' button on the action bar for example or move the sliding menu to the right side) but in general the look and feel is consistent across the two platforms. That doesn't (and won't) stop me from using native controls such as text inputs and dialogs that users on Android are quite familiar with. In case someone has no clue what the hell I'm talking about I'd be happy to share some screenshots via pm.

finalight 13y ago

no point having bootstrap for android since android API already have method for different platform version detection

bjoe_lewis 13y ago

I was looking for something exactly as this. Say, you want to building a quick-quick app for quick.com, supposedly native. This might actually work.