In recent TechCrunch's Mobile First CrunchUps panel there was a discussion about why iOS apps look better then Android apps. The panel's consensus seemed to be that as iOS has been around longer so it is more mature platform. Android has since caught up and the difference is going to even out. The panel also brought out a good point about designer mind share still being on iOS's side as iOS was the first next generation mobile OS to the market and most people who were interested about mobile jumped aboard back then.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?
Consistency
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.
Your sentiment is spot-on, but your expectations are unrealistic.
ReplyDeletePrimarily, the issue is time. As I write this, it is August 10, 2011. Devices with Ice Cream Sandwich may ship in October 2011. Ice Cream Sandwich code should have been finalized back in April or May. Whatever is in there is in there -- public pleas to the contrary notwithstanding.
Whether we like it or not, device manufacturers are set up to need a fairly stable OS several months before devices ship. That's one of the reason you see patch releases for Android -- flaws were uncovered after it was too late to change what was going onto the firmware, or features dragged on too long and had to be updated over time (see the two-tier NFC support in the SDK).
Had you framed your post as "things that would be good to have in the SDK sometime", I probably would not be posting this comment. The fact that you tied your request to Ice Cream Sandwich -- thereby setting up Android to fail -- is disappointing.
Also, please bear in mind that the core Android team still tries to keep the firmware as small as possible (to help enable lower-cost devices for emerging markets), and so Android will never contain every conceivable widget.
Great post Juhani and good point Mark. I thought the same about keeping it slim and small... Maybe "second-party" libraries like the FragmentsAPI provided seperately by Google could solve that problem.
ReplyDeleteMark, thank you for your comment. Your point is, of course, very valid. On the other hand I'm not expecting Google to jump into development frenzy based on this post. What I'm hoping is that they have already done them and currently doing final QA on the components. They hired Matias Duarte to lead UX on Android and his ideas are already visible in the Honeycomb release (Action Bar is already part of the Android SDK in the release). That is why I still hope to see further UI advancements in the upcoming release.
ReplyDeleteThomas, thanks! Yeah, in my opinion that could be a good and safe solution for the first step. I believe it could be easier for Google to implement a separate library first. It would also bring UI consistency to older Android phones.
This comment has been removed by the author.
ReplyDeleteHi, Juhani! I couldn't say it better than you. I agree totally with your opinion.
ReplyDeleteAbout the size of the firmware and platform Mark was saying, I would argue with the new Android Market example: It was done with *existing* components.
I don't think Google would need to only create new components. They could provide component libraries separately which would use existing base framework components. It would even be better if Google promote/create some opensource project. The project would get more developers with design orientations which would improve the quality of the components themselves and the applications which use them.
I don't code for iPhone, but you answered one question I had for a long time: the interface of iPhone apps are consistent because there are already a lot of widgets which satisfy the design needs of developers. I don't know how many iPhone apps need custom made widgets but by having a rich component library makes them create the interface more effortlessly.
With my little Android development experience, what I want to say is that there are a lot of ways of doing the *same* Android widgets, and this is nice, but it also has its drwabacks as you have some component library projects with compoments which do almost the same. It would be better if they were working together.
I know this is the nature of opensource projects and not everybody will agree with everybody but I think that by having a promoted Google project for custom components would give developers the consistence and "easibility" of creating Apps for Android.
I can give another example about the new Android Market. There was an article talking about swipe and tabs. There is also another example from tabs of google docs. If I want to use that component I can't because it is not available. :(
Thanks to Jake Wharton ViewPagerIndicator https://github.com/JakeWharton/Android-ViewPagerIndicator which itself is based on Patrik Åkerfeldt https://github.com/pakerfeldt/android-viewflow ViewFlow, I could get a design similar to that in my application. But note: *it is not* the same. It would be awesome if Google could provide the component somewhere and I could use it on my apps.
Sorry for long post, I just had those ideas floating in my mind for wuite sometime and I didn't know where I could express them until I saw your article!
And congratulations for your awesome site! To me this site is going in the direction I'd like to see Android UI design patters to go so more developers can learn and create better Android apps.
Hi Francisco,
ReplyDeleteThank you for taking time to write such a well thought out comment and argumentation. Thank you also for the kind words :)
I think you perfectly summarised the point I wanted to make but failed to fully explain in the original post.
Cheers!
Hi Juhani!
ReplyDeleteYou are welcome and again, thanks for your site!
I'm glad you could understand what I was trying to say. I thought it could get too much confusing.
Cheers!