

Android Bootstrap - dragos2
https://github.com/Bearded-Hen/Android-Bootstrap

======
aferreira
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
Following UX/UI patterns make sense, but not design - especially if you plan
to be cross platform.

~~~
thwarted
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
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.

~~~
thwarted
_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_

Yeah, this is a sign of a bad PM, who doesn't understand the market or mobile
ecosystem enough to realize that the targets are completely different.

On the other hand, if the interface was designed to be completely unique and
skirted all the specifics of the deployment platform, in an attempt to be
branded or for reuse of designs, that's reasonable. Often, however, it is
obvious that the design was optimized for another platform than the one you're
using it on. "Custom back button" on Android, indeed.

~~~
dragos2
I too am faced with the "custom back button" on Android. I just smile and
carry on.

------
swanson
Cool project!

Unfortunate naming collision with Donn Felker's
[http://www.androidbootstrap.com/](http://www.androidbootstrap.com/) though :(

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

------
Gnewt
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
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
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
And it actually look very good.
([https://dl.dropboxusercontent.com/u/5727009/screenshot-13841...](https://dl.dropboxusercontent.com/u/5727009/screenshot-1384122081508.png))

~~~
mayanksinghal
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.

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

------
bjoe_lewis
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.

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

