It has been quite some time I wanted to do a redesign on The Verge app due to their not-so-great UI/UX. Just to be fair, they have just pushed a new update which is a lot better than the previous version that I am referring (and I didn’t see that coming!). The new version is smoother, and it has Nav Drawer navigation (which coincide with my new redesign, but I am not surprised because it’s a natural choice) and scrollable tabs, which are definitely welcomed UI patterns. While my redesign might be slightly similar to their new update, I still want to publish them because I think there are still many room for improvement to achieve better user experience.
Below are all the mock ups that I have done (07/10/2012 – updated with tablet version), and I have included some comments for my choice of UI patterns:
What do you think? Don’t hesitate to hit me with your comments/suggestions/critiques!
In Android UI/UX tips #3, I have looked into some apps with the following UI/UX problems:
Hidden Status Bar (UX)
Outdated Action Bar and low-res icons (UI/UX)
Bad offline handling (UX)
Obstructive UI elements (UI/UX)
Hiding Status Bar? Do it Properly!
Some of the app designers/developers didn’t realize that the Status Bar is actually part of the System Bars, therefore if you decided to play around with it to get the maximum screen estate for your app, you have to do it right.
Let’s take RepliGo Reader as the first example. The app is actually pretty good in terms of features and UI, but I didn’t quite like the way it handles the Status Bar. It only allows the user to choose between Always Hide or Always Show option during Reading Mode, which is kind of limited. If they can also include a Show/Hide Together with Other Controls option, then it will be a pretty great user experience, and this should be the default behavior. Look at Google Play Books app, it handles the Status Bar nicely.
Another app that worth mentioning for this issue (which actually bothers me since Jelly Bean) is the stock Gallery app in Jelly Bean. This app has two issues with the Status Bar:
In Landscape mode, Status Bar disappeared and there is no way to bring it back.
This is one bad UX example in stock app. Given the importance of the Status Bar in Android device, my suggestion is don’t hide it in any screen mode unless the user is well aware of some method to call it (tap anywhere to show it, for example).
In Portrait mode, the black bar of the Status Bar permanently stays on the screen in Viewing Mode (only in Jelly Bean).
I am not too sure if there is anyone noticing this but this is pretty frustrating for me. I have been using Gallery app to view my app mock up in full screen (which I just need to trim off the bottom Navigation Bar), and it doesn’t work anymore because the black bar of the Status Bar is now taking up the Viewing Mode space as well. Thus, if you are going to hide the Status Bar in your app, hide it completely!
Use the new Action Bar and High Resolution Icons
With the release of the awesome ActionBarSherlock library that allows the developer to implement the ICS/JB Action Bar with full compatibility from Android 2.x, personally I am not too sure why there are tons of great apps still decided to stick with the older (and less aesthetic) Action Bar design and/or low resolution icons. Besides making your app feel aged, it doesn’t give any good impression to your user if your app using lower resolution icons – remember, Action Bar is one important UI element in Android Design which is always visible to the user. Some examples below (I am sure you can find more):
So, forget about the old Action Bar and start designing/redesigning/developing Android app using new Android Design!
Properly Handle Offline Situation
It’s true that most of the apps nowadays require internet for their full capability, either to get new information or for syncing purpose, however, we cannot expect our user are always connected to the internet, therefore you have to properly handle the situation when the device goes to offline.
I had this issue with The Verge app which actually crashes when I try to play around with the app offline. Definitely not a user experience that you would like to introduce into your app. Handle it with a simple toast or a warning message regarding the offline status would have solve the issue.
Obstructive UI elements is a no-no
It is so awesome that Android developers have numerous of great libraries for certain UI elements implementation, but once you have used those libraries; you are basically responsible for everything that you decided to show to the user.
One bad example of this is, again, The Verge app, which shows the Pull-to-Refresh indicator and overlapped with certain UI elements in the app (one of the examples shown above). I am not too sure the complexity in technical terms, but I assume it won’t take months to remove it? Publishing your app in such condition will only give bad impression for your app overall quality.
Hope these UI/UX tips help! As usual, don’t hesitate to leave your comment!
I was thinking to do a redesign of it after their official release, and now I finally did the redesign after playing around with it for some time to understand most, if not all, of the features in the app. Below shots are my redesigned µTorrent app (5 shots):
My redesigned µTorrent app has a pure Android Design and Holo themed with the heavy use of its’ brand color. It make full use of the notification center of Jelly Bean which allows quick actions and individual torrent control (Resume, Pause, Stop) is possible in the main screen.
What do you think of my redesigned µTorrent? Feel free to let me know 🙂
After publishing the 1st Android UI/UX Tips, it seems that I am able to find more UI/UX mistakes in various apps (perhaps I become ultra-sensitive now?), so here it is, Android UI/UX Tips #2 to inspire Android Designers/Developers in developing app with awesome UI and UX.
Don’t Make it Hard for The User
If your app have some awesome features that simplify user interaction, think thoroughly when to/not to remove it from your app.
One example that I would like to show is the Update button in Play Store app. When there are more than one apps require update, the Update button is very useful. Updating all the apps will only take one touch. But, when there is only one app having update, the Update button mysteriously disappeared. The problem is, now to update that particular one app, three touches are required (Select the app > Click Update > Click Accept & Download). I personally do not see any use case requires such interaction design – if you can do the same for multiple items, you should be able to do it for a single item.
Consistent with Android Design
In Google Drive app, most of the dialog in the app are using the basic button, which looks really ugly and inconsistent with Android Design. The buttons in default dialog in Android should be (I am not sure) already using the borderless buttons, so I am just feel like asking the Google Drive developers:
Why make the dialog looks like a Microsoft Windows dialog?
No Double Up Combo, Please
Astro File Manager has a new update with refreshed UI, and it comes with a double Up combo! As I mentioned in my Google+ post, it is definitely unnecessary and downright ugly. Just use the app icon for better identity establishment. Perhaps the app designer want to help enhancing the Up affordance?
Consistent with Icon for User Interaction
Again, it’s Google Drive. In the Detail View of a file/folder, you can see there is a Done button (Tick icon) in the Action Bar, and a Cross icon near the file name. You might think that the Cross icon is meant for the file/folder itself, perhaps for deletion or discarding changes? Nope. It behaves exactly the same as the Done button, and this is really a confusing design. In Android, the Cross icon usually meant remove, discard, or cancel. This is not Microsoft Windows. Just stick with the Done button at the Action Bar and it will be just nice.
That’s all for Android UI/UX Tips #2! Hope it is inspiring!
In Android Design, Action Bar is one of the important UI elements for great app. Besides providing navigation feature to the user, Action buttons in the Action Bar is crucial in user interaction as well, which provides great user experience if it’s done right.
Previously I have published the Action Bar Icon Design Photoshop Template which can be used as a design template for Action Bar icons and export it for all screen densities. Creating an icon, sometimes, is a pretty enjoyable experience – thus, I have used the design template to create 20 Action Bar Icons over the weekend (preview below) which have both Holo Dark and Holo Light version, as well as for all screen densities. The icons for xhdpi screen density are ready to be used in the Android ICS/JB Photoshop GUI Design Kit 3.0.
That’s not all. In this Icon Pack, I have also included 142 stock Action Bar and Tab Icons which are fully generated at the Android Asset Studio for quick mock up/development usage. Sure, I am aware that they are already included in the official Action Bar Icon Pack, but I prefer a slightly different folder structure in organizing the icons (as well as ldpi version), therefore I have them included in this icon pack. If you already have the official one, you can ignore that folder in this icon pack. 😉
More Action Bar Icons are in the draft stage and will be included in the subsequent icon pack. If you are looking for more professional Android icons, check out the awesome Android Developer Icons 2 at androidicons.com.
This work is licensed under the Creative Commons Attribution 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/ or send a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain View, California, 94041, USA.
Realizing that it is almost impossible to write a post for each of the UI/UX tips that I have in mind (except those worth a discussion), I have decided to occasionally come out with Android UI/UX Tips.
So in the 1st Android UI/UX Tips, I will look into some official Android apps by Google (Google+, Google Drive, Email), as well as TED app, and talk about some UI/UX mistakes in them and their possible UI/UX improvements.
Avoid Using Confusing/Inappropriate Color
Color, especially when it is related to interface elements, is an important factor in designing great UX. When it is used correctly, it can provide immediate feedback or information to the user and create confidence in user interaction.
Google+ Send Button
I am not sure if it is a bug, but the Send button in Google+ app doesn’t change color (or the grey level) to indicate the button state. This is definitely one bad UX example. Due to the nature of touch interface (there is not mouse over or tooltip), users will have to rely on the visual clue for the state of user interface element. Change the color of the Send button to a darker grey when there is some text entry should already solve the confusion.
Action Bar Icons in TED App
The Action Bar icons in TED app are designed well for their action (although they seem to be a little bit ‘fatter’), but they have an inappropriate grey color – they looked too much like disabled buttons, or in other words, the grey color is very unfamiliar. Sure, you can argue that the color choice is due to the pure white Action Bar in the app, but the app doesn’t use the suggested Action Bar icon color for light theme. Using the color scheme meant for Holo Light (#333333, 60% Opacity), they will definitely give more confidence and familiarity to the user, as well as consistent with Android Design Guideline on Iconography.
Deleting Message in Google Drive
Even though Google Drive is a pretty unpolished app, I still would like use it as an example. In Google Drive app, when you confirm a file deletion, the Deleting… wording is in a welcoming green color. For this case, I would prefer not to ignore the language of color. Every color has their own associated meaning – Red means Stop/Attention, Green means Go, Orange indicates Warm and Blue indicates Cool. Therefore, it probably make more sense if the message is in red color to grab the user attention about the file deletion. It will be even better if those dialogs in Google Drive get a revision.
Avoid Unnecessary (And Ugly) Navigation
Navigation, one of the most important part of touch interaction, can cause serious user frustration if it’s not done right. Fortunately with the official Android Design Guideline for Navigation, it should not be a difficult task to do it right. But if you want to know how to do it wrong? Check out the stock Email app.
It’s a surprise to see the stock Email app doesn’t have that swipe navigation system found in official Gmail app. In the stock Email app, a button-based navigation is used in Detail Views. It does not only take up some precious screen estate, but it is also destroying the aesthetic of the app, especially in Landscape mode. Swipe navigation and the thin indicator in Gmail app is already a much better solution for this. Otherwise, integrating the navigation buttons into the Action Bar is also a feasible solution (Just to be fair, the Phone version of Email app does have the navigation buttons integrated in Action Bar, and I am not sure why it doesn’t do the same on Tablet version).
Hope these tips help in crafting awesome app with great UI/UX elements. More tips coming in the very near future (if I have any)!
Heavily inspired by Sebastian Tibichi’s Google Play Icon Template, this Action Bar Icon Design Photoshop Template is made for Android App Designers/Developers in designing and generating Action Bar Icon in different dpi. While there is already an awesome online Action Bar and Tab Icon Generator in Android Asset Studio, Action Bar Icon Design Photoshop Template goes a little bit further – It can preview your designed Action Bar icon in properly sized Action Bar (which is customizable), and it can be used offline.
How to use?
1. Edit the Action Bar Icon Smart Object set at 512×512. Design the icon. Save the smart object. Remember to set the following properties for the icon based on the Holo theme:
Holo Light – Icon Color: #333333 and 60% opacity
Holo Dark – Icon Color: #FFFFFF and 80% opacity
2. Check all the icons generated for different dpi. If everything looks OK, hide the folder HIDE THIS BEFORE EXPORT before export.
3. Use the option Save for Web & Devices. For the dropdown option Slices, select All User Slices. Save to the preferred directory. 4 images at different resolution for different dpi (64×64, 48×48, 32×32, 24×24) will be generated.
Feel free to use it and share this to any awesome Android app designers/developers! Don’t hesitate to leave a comment here if you have anything in mind!
Back in December 2011, I released the first version of Android ICS GUI Design Kit and since then, it has been downloaded for about 9000+ times. Not a huge amount, but at least I hope it already helped some app designers/developers in making quick app mockup. And since Jelly Bean is released, I have decided to update the design kit with some new Jelly Bean UI elements, and a brand new stuff in it – Application Design Templates (ADT).
Details
Similar to 1.0, the main motivation of doing this is just to provide some stock elements of Android 4.0+ (Ice Cream Sandwich/Jelly Bean) in a single .psd file so app designer can really focus on creating awesome mock up to show their developers/clients. Some of the elements (very minor though) are just single layer of image, but they should be pretty adequate for quick mock up purpose.
In 3.0, I have included two .psd file in the Design Kit – Building Blocks and ADT.
In Building Blocks, it contains most, if not all of the stock ICS/JB UI elements that can be used to build an app mockup in Photoshop. Most of them covered both Holo Light and Holo Dark themes, so you can easily drag and drop the properly grouped UI elements to your app design.
As for the ADT (not to be confused with the Android Development Tools which is a plugin for the Eclipse IDE), it serves as a starting point for the app designers/developers of the app design. You have the choice to select the design template that start with different amount of tabs and holo theme, and the design in Photoshop starts from there.
So what’s inside the new Android ICS/JB Photoshop GUI Design Kit 3.0:
Building Blocks
Soft button
App Login Screen Example
Homescreen (Updated with Jelly Bean Homescreen)
Launcher Screen
Option Bar (Top and Bottom)
Menu
Keyboard
Notification Center (ICS and Jelly Bean Notification Center)
A few weeks back, I came across the StandOut Android library from my Google+ stream that helps developers in implementing the floating app (something like the Pop up play in Samsung Galaxy S3). It looks interesting at first, but not so much after playing around with it from the user perspective.
Multitasking with floating app?
Floating apps are fun, and the implementation does open up some new possibilities in app design and it does show that true multitasking (not to confuse with the recent app switching function) is possible in Android.
However, it doesn’t make much sense to have such feature on smaller screen devices (eg. Phone). Take the Pop-up Play feature on the Samsung Galaxy S3 as an example, I don’t really see how it can help in multitasking, in fact, it has the potential to create annoyance to the user when it is used – the user have to move it around just to see/perform any action below the pop-up window. Check the video I attached below and you can get what I meant:
Another thing that is really worrying is the inconsistency of UX introduced by these floating apps, even if they are running on the bigger screen devices. It can become even worse when you can resize and move them around in an environment that is designed to run a single app at a time. Not to mention the ugliness it can introduce if there isn’t any proper design guideline. I don’t need another Windows.
Does it really make you a better multitask-er when you have four or five window floating around on a mobile device? When you need a second parallel running app alongside the current one, most probably you would want to do a cross reference on documents, or chatting with friends while watching football match, or attach a file into an email, which most of them involved only two activities at once.
Therefore in my opinion, to do a proper multitasking (on a tablet only, of course), it has to be a system level feature, and it should at most, involved only two activities at a time.
Multitasking in Android
Samsung Mini apps
Samsung tablets already have several in-house apps allowing the user to multitask, which they called them Mini Apps. Similar to the pop-up play, I don’t particularly like them – They usually have limited functionality (that’s why they are called Mini Apps) and they are more like a hack rather than a properly designed multitasking feature.
Cornerstone
Onskreen have some very interesting development here. In their video demonstration, their 3-way Split View seems to be working pretty well. It’s a great indication that Split View Multitasking is definitely possible, although I am less favor in their way of screen splitting. App launcher within split view is a good idea, though I would prefer to make the entire multitasking feature less complex.
Multiscreen feature in Samsung Galaxy Note 10.1
This is a relatively new feature in Samsung Galaxy Note 10.1. It inherited a lot from their own Mini Apps, but now they decided to make them run in half of the screen, splitting the screen to run two apps in that bigger screen size. However, most likely this feature will only be available in their in-house apps, so not all Android apps are supported natively.
My Concept of Split View Multitasking
Above is my concept for the Split View Multitasking, heavily inspired by both the Snap Multitasking in Windows 8 and Onskreen Cornerstone. It is definitely not a complete idea, so suggestion/critique is always welcomed.
The user can initiate the Split View Multitasking by drag-and-drop the app from the app switcher list to the running app (I called it Task Grouping) or just use Add to Split View button, and there will be an indicator to know which app is in the active mode (so the system features like keyboard or Back button will correspond to the correct app). App in the Left View (which is a smaller part) will reset the UI to Phone UI even though it is running on the tablet. App in the Right View (a bigger part) will still be using Tablet UI in Portrait mode.
Consistent UX
It is designed to have a consistent User Experience. The user knows what to expect from it and it won’t have any content blocking issue like in the floating apps. No resizing option available, therefore all well-designed app should be able to run with intended design during the Split View Multitasking.
Multitasking limitation (in a good way)
My concept limits the multitasking to only two activities. Well, no doubt this limitation might be frustrating for some, but considering the processing power that a tablet device have, this might be a better option. Plus, are you really able to multitask when there are more than 2 activities in front of you?
Make full use of universal and responsive app design
One of the great advantages of Android 4.0+ is the unified platform support, which runs on both phone and tablet with specific UI, and this should be the case for all Android apps. A well-designed universal app should be able to resize based on different situation and run with proper UI (this is also important now with the release of Nexus 7 with TVdpi density), therefore supporting for Split View Multitasking should not be a huge issue.
Possible Limitations of My Concept
Universal app design
Not all apps are designed to be a universal app which can run on both phone and tablet with responsive UI.
Aspect ratio
The concept is based on the famous 10.1 tablet resolution of 1280×800 which is 16:10. There are already quite a few number of Android tablet designed with 4:3 resolution, which will not quite fit with the concept above.
Discoverability
Discoverability, as always, can be a big challenge for the designer/developer when there is a new UI Pattern/User Interaction, especially in System Level.
Conclusion
With the processing power available on mobile devices, a simple multitasking feature is definitely something we should look into – but no, floating apps is definitely not an option. With the Multiscreen feature available on the Samsung Galaxy Note 10.1 and some third-party developments on true multitasking, I hope that these are already sufficient to push for some official multitasking feature in the upcoming version of Android.
If you have anything to share regarding this topic, feel free to share and comment!
Well, this topic might be a little bit old since the last bunch of discussions, but I still have a little bit more to talk about this UI pattern that I have missed in my last writing and also some new idea popping-up since last month.
I personally still think the Side Navigation (a.k.a Fly-in menu, Sliding Menu, Nav Drawer etc.) in Android is pretty interesting even though it is not a relatively new UI pattern – it allows a fresh (and better?) navigation style on small screen mobile devices, and it helps in efficient use of screen estate for content. A number of apps are already using it (each app has slightly different kind of behavior and interaction though) even though it is not (yet) an official Android UI Pattern, which is always great for Android development scene because innovation doesn’t stop at stock design/pattern. However, I really think it’s time to have some consistency and guideline for this UI pattern for better user experience because I can foresee more apps will be using this, only with different kind of behavior. Some of the official Google apps like Google+ and YouTube are using it mainly for navigation purpose, but unfortunately they are not good example since the Side Navigation implemented has different interactive behavior.
More tips and suggestions
Some extra suggestions from me since the last one if you are looking into Side Navigation for your app:
Don’t confuse the user
This is like the #1 UX rule if you really care about the user. The latest update of Google+ app during the launch of Jelly Bean is pretty awesome, and I think most of the Android user will agree with me. The Card Style pattern (which is another interesting UI pattern) offers some fresh experience into social networking app, and the redesigned Side Navigation menu since the last one is great – but not the visual indicator for it. The Up affordance are still used for it, and it will further confuse the user with the Up affordance when there is already user confusion in Up and Back affordance in Android 4.0+. My suggestion: If you really have no better idea on the visual indicator, use an icon for it (eg. Facebook and Prixing), or just the app icon (eg. Evernote), but please do not use the Up affordance to confuse the user.
Bezel Swipe, please
As mentioned previously, I still think Bezel Swipe is a great match with Side Navigation. It is very easy to understand, and bezel swipe isn’t something hard to perform on a mobile device, though I would have to agree that discoverability might be an issue for it. Another reason that I think Bezel Swipe should be there – most of the apps that have Side Navigation, for example Google+ and YouTube, allow the user to touch and hold the main activity and swipe-closing the Side Navigation (try to hold the main activity and swipe to left side), and this user-perceived closing animation can introduce the user expectation of swipe-right-to-reveal gesture for Side Navigation. Try Dolphin Browser HD and Prixing, I think it is completely make sense.
Improve Discoverability (and create curiosity)
Well, this isn’t something new. Every now and then, there are new UI patterns and new user interaction invented in mobile apps. To make the user aware of your new UI patterns and/or user interactions, what you can really do is improve the discoverability of those new patterns. As I said, Bezel Swipe/Side Navigation might have issue in discoverability, so just don’t stop there after the implementation.
Introduce it in the first run tutorial and let the user play around with it.
Make the Side Navigation a little bit more obvious when the user first running the app – a great example for this is the Prixing app which make the Side Navigation panel ‘jump’ when the user first entering the app, creating user curiosity.
Use a good indicator to represent the Side Navigation.
They are not perfect solution for the discoverability issue, but those are some possible improvements.
New indicator?
After some suggestions in the previous post, I am still actively thinking for new indicator that can be used for the Side Navigation. Below are some of my new idea, what do you think?
Conclusion
I really like Side Navigation pattern and I think it is especially useful in mobile devices with small screen, but it’s pretty important that the user experience that comes with it has to be carefully crafted so it doesn’t cause user frustration and confusion. If you are looking for some reference while implementing, I strongly suggest you to look into Prixing.
For developers, if you are looking for library for this UI pattern, you must check out the SlidingMenu library by Jeremy Feinstein. It uses Bezel Swipe which I prefers a lot and generally it has quite some good reviews.
#androiduiux 