How APIs can support good design - a wish list to Google
In my opinion there is an even more significan factor. When a developer opens iOS developer tool xcode for the first time he or she will immediately see many available UI components. The components are not limited to simple components but there's also more complex components like header bar and tab bars are available by simply dragging and dropping.
The Android Eclipse plugin provides number of components but they are limited to simple buttons and layouts. Everything more complex the developer must either build from scratch or find a third party library.
Android community has created a large amount of UI libraries and open source components that can be used to speed up app development. While I appreciate work of these developers tremendously having to continuously use third party libraries and components creates problems in app design when looking at the bigger picture.
Additions to Android API I would like to see in the Ice Cream Sandwich release:
- Action Bar API - A continuation to the Honeycomb action bar API that can be used in smartphones an tablets.
- Dashboard Layout - Addition to the default layouts that can be used to build smartphone dashboard landing page easily.
- Workspaces layout - This paging layout is difficult to build right. It is also one of the things that can be very confusing to users if apps have many different implementations.
Why it is important to include them into the Android SDK?
When every developer either implements or uses a third party library to create their version of commonly used components like action bar or workspaces it means that multitude of implementations can greatly vary in quality, functionality and visuals.
In the Honeycomb release we saw a big step towards the right direction. Google included action bar for tablets into the Android SDK. Result of this has been a much more consistent look and feel of Android tablet apps than it would otherwise have been.
For the upcoming ICS I'm hoping to see more of this. Having out of the box support for action bars, workspaces, quick actions and dashboards would be a nice surprise. Additionally, adding the same components to the backwards compatible compatibility lib would open a new era in Android app design and development. Suddenly we would see a flood of Android apps I the market that look consistently Android. We would have an easily identifiable style of Android app.
Path of least resistance
We developers are lazy. Actually, developers learn to be lazy because it has huge positive implications to their work (when being lazy in right places). Finding a ready solution to any problem often saves hours of work and produces better results. A well designed library is likely to produce better and more stable results than coding the solution from scratch.
Whether building a solo app or being a part of a larger app team developers are likely to prioritise a ready solution over a custom component. If the Android SDK had a selection of well designed and customisable complex components developers would use them and designers would prioritise solutions using them.
The new Android Market app
I wrote a post about the new Android market app and UI patterns used to create it. I also mentioned my hope that we could be seeing a glimpse of new and upcoming APIs in the app. Unfortunately I was wrong.
Android Market apps is a great example of a lot of the UI design patterns done right. I'm still hoping that Google would extract them to the Android SDK libraries.
Why 3rd party libraries are extremely valuable
I don't want to make this post sound like I think that third party libraries should not exist. On the contrary! I think UI design patterns should rise organically like they now do. Third party libraries like the GreenDroid and Action Bar Sherlock lead the innovation. Patterns could not rise if they didn't exist.
When designers and developers invent new ways to solve common problems we need third party libraries to drive adoption of these solutions. But when the UI design patterns mature and gain critical mass they should be included into the code SDK to guarantee consistency throughout the platform.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)