- The editor is much faster
- Building is a lot slower
I've tried playing around with "Make project automatically" et al, without success. Has anyone successfully improved the building times?
I currently have automatic builds disabled, and make runs before launch. Which configuration would you recommend?
iosched$ git push — The I/O 2012 Android app source is now available
The source code for the Google I/O 2012 Android app is now available at http://code.google.com/p/iosched!
Every year a few of us Googlers spend a few [really long] weeks preparing an app for the conference. The app serves two primary purposes. The first is, of course, to help conference-goers find their way around Moscone and attend the sessions they find most interesting. The second, and arguably more important purpose of the app, is to serve as an open-source example of the Android team's latest and greatest Android development best-practices.
This year, the app contains tons of best-practice examples, including:
• providing handset/tablet optimized layouts in a single APK
• maintaining compatibility with Android 2.2 and later
• allowing horizontal swiping with action bar tabs
• deep-linking with intents
• loading and caching images
• providing infinitely-scrolling lists (the public Google+ stream component)
• handling multiple-selection with the contextual action bar
• providing interactive app widgets
• using OAuth 2-authenticated Google APIs such as Google+
• using sync adapters and Google Cloud Messaging
• supporting Android Beam
• providing a unique Google TV "lean-back" experience
• and much, much more
So if you're an Android developer, head on over to the open source project at https://code.google.com/p/iosched and check it out!
Note: we've temporarily left out a few things, including YouTube integration, the Google +1 button, and the new Google Analytics SDK. Keep an eye out for updates to Google Play services at https://developers.google.com/android/google-play-services; we'll be updating the app source code as services become available.
"the tab bar won’t be coming to Facebook for iPad, as it sees the drawer as still a good fit for bigger screens"
Navigation Drawer, for Facebook anyway, is a good fit for larger devices but for phones their usability testing pointed to a tab bar.
There is nothing inherently wrong in what people have come to call “skeuomorphic” design. The choice of fewer constraints gives you a wider selection of tools to work with. Glossy bevels, generous drop shadows, intricate textures, strong gradients and more – all of these justly belong in a rich skeuomorphic visual palette. There’s no shortage of examples of strikingly beautiful visual design. Design that combines multiple textures, gradients and materials in a consistent form. Design that exercises restraint in how the rich palette is used. Restraint in how elements are chosen, which elements are left out and, most importantly, how the chosen elements are combined together.
On the opposite hand of the spectrum, if you will, is the “flat” design. Design that chooses to constrain itself to a very small number of visual elements. Sharp corners, solid colors, simple shapes, absence of drop shadows or, for that matter, absence of a global lighting model. The stark beauty of flat design is particularly impressive given the constrained choice of the tools. One may even be led to believe that the simplicity of this palette translates directly into the simplicity of the overall design iteration spiral.
This couldn’t be farther from the truth. Tighter constraints that result in a reduced palette do not necessarily obviate the need for restraint. Restraint is not only which tools you choose from that palette. It is also – and much more so – about how you combine the tools together. How you define and implement a visual language that stays true to the flow and shape of the interaction.
It is trivial to create a bad skeuomorphic design. There are entire blogs dedicated to ridiculing poorly-executed mashes of garish textures, exaggerated lighting and gaudy 3D controls. It’s not surprising to see these sites – and most recent blogo-bashing of skeuomorphism – focusing on pure visual aspects of such interfaces. On the other hand, as more designers dip their toes into the field, we see an increasing number of badly executed flat designs. The drive-by critics focus, this time around, on the usability blunders.
When you constrain yourself to simple shapes, solid colors and lack of depth, it becomes much easier to sacrifice usability. A hurried design executed from a rich skeuomorphic palette will look garish, but at least there are enough visual tools to help set the different pieces of content apart. With so many textures, gradients and shapes to choose from – and little restraint – one can still create a fairly usable interface. Usable in the sense that a button “looks” like a button – something that can be pressed to initiate some kind of an action. When you directly migrate this hurriedness into flat design, it is much easier to end up with an interface that jeopardizes the structure of your content.
Flat design necessitates deliberate definition of the visual language. How do you convey the logical structure of your content and maintain the logical separation of blocks in the visual realm? How do you convey the behavioral difference between the different blocks? How do you convey the logical importance and relationships between the content blocks?
When everything is a flat rectangle, and you only have a few accent colors to use, you have to exercise a much higher degree of restraint in defining that visual language. When your tool palette is restrained to a very few elements, you cannot afford to use the same element to mean two different things with no significant user-facing distinction. If your buttons and your section headers are the same flat solid-fill magenta rectangle, but the section headers are not tappable, you are not exercising enough restraint in how you’re using your palette.
It is hard work to create a strikingly beautiful, aesthetically pleasing and well-behaving skeuomorphic design. The restraint that the designer must exercise at every turn of the spiral to use the rich variety of tools at his disposal takes attention, energy and time.
It is hard work to create a strikingly beautiful, aesthetically pleasing and well-behaving flat design. The restraint that the designer must exercise at every turn of the spiral to use the small variety of tools at his disposal takes attention, energy and time.
Finally, skeuomorphic and flat are just two extremes of the same spectrum. One does not have to go from one extreme to the other. There’s enough space in between to carve out your own, unique niche. The closer you get to one of the ends, the closer you get to the “extreme” choice of your tools – be it the rich palette of skeuomorphism or the small palette of flat. But the size of the palette has nothing to do with the next phase of the spiral – defining, refining and restraining your usage of that palette.
"Don't use right-pointing carets on line items
A common pattern on other platforms is the display of right-pointing carets on line items that allow the user to drill deeper into additional content.
Android does not use such indicators on drill-down line items. Avoid them to stay consistent with the platform and in order to not have the user guess as to what the meaning of those carets may be."
This part in particular seems very hand-wavy:
"...in order to not have the user guess as to what the meaning of those carets may be."
* Are users 'guessing' as to the meaning of these carets? I find this argument highly dubious.
* Are drill down line items more discoverable when we remove the carets?
Android design should be informed by usability studies and usage analytics. Do we have this data?
This Beautiful Stop Motion Toy Story Might Just Break Your Heart
Using stop-motion animation and imagery from Google Maps Street View, director Tony Jenkins provides a look at how a lonely desk toy manages
Google ‘Nexus Prime’ Android 4.0 phone could launch in October
Google's third-generation "Nexus Prime" smartphone — which will likely be the first Android 4.0 "Ice Cream Sandwich" phone to hit the market
Official Google Blog: Introducing the Google+ project: Real-life ...
Introducing the Google+ project: Real-life sharing, rethought for the web. 6/28/2011 10:45:00 AM. Among the most basic of human needs is the