Live data from Hacker News

Android Bootstrap

github.com

11–20 of 25 posts

Re: Android Bootstrap

#11
post #2

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.

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.

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.

Re: Android Bootstrap

#13
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.

Re: Android Bootstrap

#14
post #2

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.

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.

> This is for mobile HTML 5 development.

This isn't for mobile HTML5 development.

Re: Android Bootstrap

#15
post #2

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.

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.

Re: Android Bootstrap

#16

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…

Following UX/UI patterns make sense, but not design - especially if you plan to be cross platform.

Re: Android Bootstrap

#17
post #15
post #2

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.

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.

On the other hand, big apps with their own style probably have already chosen to not look like Bootstrap.

Re: Android Bootstrap

#20
post #16

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…

Following UX/UI patterns make sense, but not design - especially if you plan to be cross platform.

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.

Post reply on HN