3 ms·

I'd be interested in reading more about this - I'd love to show it to some designers I work with. At the moment, I'm struggling to get the designers to acknowl

I'd be interested in reading more about this - I'd love to show it to some designers I work with. At the moment, I'm struggling to get the designers to acknowledge that Android and iOS need to be designed seperately. iOS designs can look pixel-perfect due to having only 2 resolutions to care about (ok, iPhone 5+ have taller screens, but same width) Android is a whole different story.

youngtaff 13y ago
Slide 86 on of this talk by Stephanie Rieger will help http://www.slideshare.net/yiibu/designing-for-diversity-how-to-stop-worrying-and-embrace-the-android-revolution http://www.slideshare.net/yiibu/designing-for-diversity-how-... (whole slide deck is worth looking at)
Zigurd 13y ago
This is how I introduce Android to teams that are making their first serious non-game app: 1. How to scale the app across all screen geometries: a. Let Android choose the layout from among the alternatives you create for different geometries b. This means different numbers of Fragment objects can be displayed c. This means different functionality can be available d. This means you have to organize functionality in a hierarchy (for the smallest screens) that can be unfolded and flattened (for the biggest screens) 2. Then I get into Activity and how the code that used to be in activities should be organized into Fragment subclasses, and about top-level layouts. 3. Then I get into Relative Layout and how to make your layouts "stretchy" enough that you don't have to specify a different layout for every combination of size, density, orientation, and text size. 4. Now that the coders and designers understand how they fit together in making a UX that "folds up" and "unfolds" I teach the designers how to check in to the client's repos, and how to edit layouts in Eclipse, so they can be responsible for their own work getting into the project and build and run the app to see how their layouts work. This is still a vast simplification, leaving out things like Android remote methods and high-level (Intent) IPC and how hat affects UX, and numerous other areas where Android is substantively different from iOS's app environment.

youngtaff 13y ago

Slide 86 on of this talk by Stephanie Rieger will help http://www.slideshare.net/yiibu/designing-for-diversity-how-to-stop-worrying-and-embrace-the-android-revolution http://www.slideshare.net/yiibu/designing-for-diversity-how-... (whole slide deck is worth looking at)

Zigurd 13y ago

This is how I introduce Android to teams that are making their first serious non-game app: 1. How to scale the app across all screen geometries: a. Let Android choose the layout from among the alternatives you create for different geometries b. This means different numbers of Fragment objects can be displayed c. This means different functionality can be available d. This means you have to organize functionality in a hierarchy (for the smallest screens) that can be unfolded and flattened (for the biggest screens) 2. Then I get into Activity and how the code that used to be in activities should be organized into Fragment subclasses, and about top-level layouts. 3. Then I get into Relative Layout and how to make your layouts "stretchy" enough that you don't have to specify a different layout for every combination of size, density, orientation, and text size. 4. Now that the coders and designers understand how they fit together in making a UX that "folds up" and "unfolds" I teach the designers how to check in to the client's repos, and how to edit layouts in Eclipse, so they can be responsible for their own work getting into the project and build and run the app to see how their layouts work. This is still a vast simplification, leaving out things like Android remote methods and high-level (Intent) IPC and how hat affects UX, and numerous other areas where Android is substantively different from iOS's app environment.