Gradual engagement is the process of moving a user through an application or service – actually engaging with it, and seeing its benefits. With gradual engagement, new users are not just presented with a registration form and then dropped off a cliff. Instead, registration is either postponed, or handled behind the scenes and the first time experience is focused on giving people an understanding of how they can use a service and why they should care to.
Something I am experimenting in my current product workflow is gradual engagement. We are going to let users use the app but gradually get them to sign up through various hooks - in-app and outside.
Hooking up analytics is high on my priority. With data, I can play with the workflow and tweak after release.
From Max Rudberg’s ‘If you see a UI walkthrough, they blew it’
[Clear, Rinse, and Solar] These apps have chosen to reduce details to achieve a minimal UI, but in the process the UI has also become harder to use. Unfortunately a UI walkthrough is quite an inelegant way to explain the core functionality of an app. It can be a frustrating obstacle before you can dive into an app, and you have to remember all of those new ways of using it once you get in.
Clear, Rinse and Solar have minimalistic theme and the gestures are hidden. Without walkthrough, users will have hard time using the application.
I think walkthroughs are not bad as long as you provide in-context message and highlight features that are key for user experience. On the other hand, you have work to do if you hide your key feature and it requires a walkthrough to learn. Users just rush through these screens and don’t have patience to read and / or remember.
I have done a mix of few things to highlight features / usage during first run:
There is no clear formula - it depends on your application and UI. It is not bad if you have a walkthrough - make sure that your UX is not totally broken if user skips it.
Facebook documentation for Graph APIs are bit poor. One that I came across few weeks back was that you could publish pictures by providing a pictures URL.
You can also publish a photo by providing a
urlparam with the photo’s URL.
There is not much documentation after that. If you missed that line, you won’t know - it is not mentioned anywhere else. Posting pictures by providing the URL is a blessing for both the users and the developers.
If you building a cloud service like us, you cannot afford to download the photo from the cloud and upload it to Facebook. It is inefficient and chews up user’s bandwidth. With few pictures, you can probably max out their data for the month. With all the downloading and uploading, at least one of the threads will be working hard and leads to all kinds of lags and instability.
Instead of sending the data, all you have to is to POST with photo’s URL to publish the pictures. Here is an example:
// POST to Graph API endpoint to upload photos
. $album_id . "/photos?"
. "url=" . urlencode($photo_url)
. "&message=" . urlencode($photo_caption)
. "&access_token=" .$access_token;
As a Program Manager / Product Manager, you have to watch out for these things to build better and efficient application. It is a small detail but it would have caused a bad experience for the user. User Experience (UX) is more than UI and IxD.
When Google+ iOS app came out last year, my first impression was that someone familiar only with Windows Phone Metro theme wrote that app. The side swipe for filters (All, Nearby, etc.) was not what a user would expect from an iOS app. If you add more filters to your list, the swipes grew. When you try to swipe, it scrolled sometime.
It gave more prominence to text and deprecated photo and video experience. Zoom to photo UX was broken. Trying to read comments and annotations of a post was hard. Overall, it was a bad UX. I hope no UI / UX designer was involved in the first release. If there were one, I would like to get his perspective on these.
The new overhaul is refreshing. I was happy to see the swipes go away. Filters are prominent and easy - users can act on it with ease using their thumb.
Users come to social network to look at pictures, videos and then links / text. This design overhaul puts the media first - photos take the width of the screen and are crisp against black background. +1s and comments are easy to see and add. Animation for new post is nice touch.
I hate to see the controls not disappearing when you act on the media. I would love to have the controls disappear on a tap on picture so you can see just the picture. You will get to see the pictures in full screen - you don’t need to have two step process to see the pictures in full screen and a tap to get back.
Previously, you had to go into a home screen and then select an option. It was unnecessary. Glad to see the home screen go away now in favor of panel based UX. I would have given search, settings and notifications at the bottom some differentiation and space but it works OK.
Writing a post UI is functional and safe. Don’t know how many users will get the subtle differentiation between ‘X’ to remove location vs tapping on location text to pick a new location from a list.
Few glitches but a good and a much needed overhaul.
I came across Kindle Fire’s Usability Findings by Jakob Nielsen. It reinforced the need for adaptive web design (or multi-device web design).
For 7-inch tablets to succeed, service and content providers must design specifically for these devices. Repurposed designs from print, mobile phones, 10-inch tablets, or desktop PCs will fail, because they offer a terrible user experience. A 7-inch tablet is a sufficiently different form factor that it must be treated as a new platform. Furthermore, these mid-sized tablets are so weak that suboptimal designs — that is, repurposed content — won’t work. Optimize for 7-inch or die.
If you take a platform / device agnostic look at the usability findings, it is pretty clear that you need to design web sites for different sizes. Otherwise usage of web on these devices drops as the size of the tablet shrinks. (Source 1 and 2) It is a catch-22 to write a native app for unproven platform but mobile web could solve the problem or at least it will provide you with data on whether you are getting enough users to invest in a native app.
The web application we are building is adaptive and it is pretty sleek to see the content and menu slide around when you resize your browser or load it on mobile phones.
If you need more information on adaptive web or multi-device web design, I would recommend Ethan Marcotte’s Responsive Web Design. I read this book and Luke Wrobleski’s Mobile First earlier this year to get a better understanding on UI / UX theoretically. I instinctively made lot of correct choices in the past years but it was very fulfilling to read the theory and backing by UI/UX experts.