Planning poker (not sure if it’s still commonly used now?) shouldn’t be a stranger for you if you work in agile software development environment. During the estimation practice today, I suddenly have the idea to make a really simple concept app that simulating the planning poker cards for use during the estimation.
The concept app is really simple – I used the card UI for the poker cards, so in order to change the card, you just need to swipe left or right. The card will just show the number in sequence and nothing else. It comes with light and dark themes.
I have a feeling that this app is really simple to develop, any taker?
During the 25 billion app downloads celebration at Google Play Store, I noticed mSecure – Password Manager was in the 25 cents list, and after I reviewed the screenshots, I immediately buy it – not to use it (at this moment), but to redesign it. It really surprised me when I found out the app is actually selling at $9.99 with this pretty dated and ugly user interface (and possibly bad user experience).
So I started to play around with the app, and as expected, I got really frustrated using the app even though I am just trying to do some simple stuffs – a redesign is definitely required. I start sketching using my GUI Sketching Kit and transfer my sketching to the digital version, and it was pretty fun! It turns out to be pretty inspiring, and I am actually thinking to work with some great developers to make this design a real working app (Any taker? Let me know if there is such possibility!).
Anyway, below are all the mock ups for the redesign:
What do you think? Do you like this redesign? Hit me with your comments/suggestions/critiques!
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!
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)!
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.
After a rant about the app screenshots in Play Store, another not-so-great UX in Play Store that I experienced for quite some time is a pretty frustrating one, and I thought this is something Android Designer/Developer should avoid at all costs.
Last Position or Top of the List?
Imagine this scenario: You are scrolling through a long list, and found something interesting in the middle of the list, so you click on that item to get more information. After that, you want to go back to the list and continue the search.
Question: When you go back to the list, do you expect to go back to the position in the list where you left off, or to the top of the list?
My answer: Definitely the position in the list where I left off.
Back to Top of the List Shouldn’t Be Automatic
But Play Store app developers don’t think so. In My Apps section, both INSTALLED and ALL tabs are having this UX mistake. Want to try yourself? Grab you device, go to Play Store > Overflow button > My Apps. Go to ALL tab, scroll down a little bit deeper, click on any app. Once you enter the details page of the app, click Back button or Up button. Now, see check the list. You are on top of your list. Frustrating, no? You can find the same UX mistake when you are searching for apps in Play Store app too.
I don’t recall any of the official Google apps giving me such frustration. I am not too sure if there is any specific reason from them to design/implement it in such a way, but I don’t see any value or advantage except causing user frustration and confusion.
Back to Top shouldn’t be automatically done until the user requested it, or at least the user should be aware of it. So, please, Android Designer/Developer, avoid this UX mistake at all costs.
#androiduiux 