asknative
Social travel app
Joined as a Co-founder and the sole designer of asknative. Our mission was to connect travelers and nomads, who seek unique travel experience, to natives around the world to find hiddent gems in cities.
Role // Web designer / Full-stack developer
Year // 2013-2014
Using // Sketch / Ember.js / Ruby on Rails
Goal
Build an application that takes the mobile experience to the web, while focusing on simplicity, speed, and ease of use.
Pregame
Before getting started, I did some research on web MVC frameworks that would improve the development speed, and create a more fluid experience for users.
It went down to Angular and Ember.js. At the time I was doing research, Angular was more popular, had more documentation, and was more mature. But Ember.js had the appeal of being similar to Ruby on Rails, which for me meant strong structure, and the thoughtful process of adding features.
From there, I started learning Ember.js, while implementing the first version of asknative.
Landing page
When people go to asknative.com, we wanted a page that would answer “what askative is”, and allow them to log in.
With that, I focused on giving our tagline “Your travel questions, meet their local answers” more precedence than our logo, then tried to answer “What will asknative help me do?” in the byline.
As for login, I tried to make it easy for people to login with their social accounts, without cramming a lot of buttons. Based on the data from the iOS app, when offering login with Facebook, Twitter, or Email, the majority used Facebook.
So, I started with Facebook login, then added Twitter too, while hiding email login under a link below them.
Going through different iterations, the general structure was good, but it felt empty. So to give it life, I tried adding a background, and tested it, which came back positive. So I improve more on it, and made the background change every couple of seconds, with a fade-in-out animation.
Generally, I’m against auto-changing backgrounds and carousels, but in this case, backgrounds didn’t have any value other than visual delight and didn’t hold information, so it was okay.
The two login buttons, seemed like they are competing for attention. So I focused instead on a single Call to Action button, and rely solely on Facebook (because it was what most people used for login and signup), while hiding extra login options under the Log In link below
Login
During the first iterations, when users clicked Log In, I used to redirect them to a login page.
There were two problems with that approach.
First, user would lose his focus. For example, if he is already looking at a post and wants to reply, he would click Reply, get redirected to a page for login, after redirecting back, he would forget what he was doing.
Second, redirection didn’t always work. Although I did handle it programmatically to redirect back to the page that user was working on, in some cases, an error would creep in, and would break the flow of users.
To solve this problem, I implemented a modal view that would allow users to login without leaving the current page.
Home
Goal for the home screen is to see user’s feed from posts from cities and people user’s following, and to be able to post questions, and tips.
The first iteration in the design, focused on a single timeline, with posting text field that would expand to write the post. On top of each cell, it was important to state “Why are you seeing this post.”
Another important part in the cell design, was showing people who liked the post. Because sometimes posts, don’t get answers, I wanted to show that there are others too who like this post, and interested in the answer (in case this is a question) to motivate people to answer this question.
Showing likes in each post caused a huge delay in receiving the JSON response from the backend, because avatars were not provided in the posts response, each batch of users in each post had to be fetched with a separate request. So I had to remove the avatars in order to improve performance.
In the next iteration, I improved the posting box, making it blend more with posts, and I tried to show the options for posting (Ask Question, Leave a Tip). Also replace the text area for answering and commenting, and leave it as a label that would expand to write the answers and comments.
Also changing the navigation, I merged home with the discover page. Showing the main timeline, and on the side, a city and users to follow suggestions, and finally created a segmented button to switch between different timelines. So users could navigate to almost anywhere in the application from the home page.
Adding suggestions on the right didn’t have much impact on users following behavior. It needed a better suggestions algorithm from the backend, in order to provide the user valuable suggestions.
Going forward, I removed the suggestions on the side, replaced the segmented button with tabs to improve the look, and finally hid the rest of the navigation from the top right under a drawer for a cleaner look.
For the cell design, we wanted to make it focus more on post text, and give more importance to questions than tips.
So first, I re-prioritized the cell design, moving the question or tip on top of the avatar, while keeping the post location on top, and finally decrease avatar size to shift more focus on the question.
Then, I tried having different text size for questions and tips. Because questions usually have less characters, and tips were the opposite, I made questions have bigger font, while tips remain the same. But it wasn’t good visually, and I ended up giving both of them the same size, which was something between the large font size of question, and small one of tip.
As for action buttons (like, reply, repost, tweet, share), they were confusing. Orange seemed like it was active. Also we wanted to simplify the cell by merging action buttons with stats on the right, instead of having to look to the right in order to answer “how many like or shares” and whether I already liked this or not.
Using gray was the best option available, as black conflicted with the rest of text. So in order to avoid feeling that it was disabled, I separated it from the upper and lower sections of the post, used colors on hover, and if user for example liked the post, the button would turn orange, so it would be obvious, that he liked the post.
To make actions feel faster, I relied on optimistic requests. So when users hit the Like button for example, they would see the button toggle instantly, and not wait for a success confirmation message from the backend. In order to do that, it was important to handle failed requests by retrying in the background first, then showing an error if there was still a problem.
Posting
Problem with the previous posting field, that it required users to scroll to the top in order to post, and in some pages it was hard to add posting cell when there is no timeline to add to the top.
To solve this, I moved the posting cell into modal view, so it doesn’t have positioning limitations. Also it focused on the posting, while dimming distractions behind.
Cities
We needed a place to let users explore, a place that would allow users to look at popular and posts from around the world, and also have a chance to follow cities, and other people.
The first attempt, focused on the timeline, while having suggestions on the side.
In the previous attempt in the Home, I tried to have cities, under a home tabs, but it was out of place. The cell design was different and it didn’t fit.
Creating new page for cities gave more room for improvement. Now I could add a quick search for finding cities, and I had more freedom to use different background color than home timeline.
City details
In the first iterations, city looked like the profile. It had it’s name, people who followed it, and the posts.
In city design, I tried giving each city a unique look, and not just another page, so around 40% of the screen was reserved for the cover image, and the posts in that city.
Profile
I started with something very minimal, something to act as a placeholder for the profile URL, to deploy that version of the application as soon as possible.
There were two problems in the previous design. First, the request time to retrieve the data from the backend was a lot. Second, was the consistency of the overall application design.
So I changed to single timeline view, with user information on top, ability to follow or edit profile top top right, and finally the main timeline below.
This also allowed adding cover image for each profile, which was planned in a later stage.
Branding
Transition from the first version of the app, to the next one. We wanted an improved logo that works better in different places. The combination of the icon and logo was hard to use with colors, especially that we changed the branding colors in the iOS version from orange and lighter orange, to orange, and yellow.
The typography wasn’t really good, and overall the logo didn’t scale well.
So the current logo wasn’t working for us, and it was a good opportunity to change.
Creating a different logo, we wanted something that can stand on it it’s own, and doesn’t require the icon beside it.
I started looking for logos that use script fonts, as it felt more friendly and smooth.
Trying different fonts, closest thing was called Tamarillo. It was thin, when I tried to make it bold it created sharp spikes, and some characters didn’t connect well together. So I started from there and improve it.
Learnings
Using new technologies can be amazing, and can accelerate the development process dramatically, but it can also be the cause of major delays. It's important to not to be overly optimistic with the estimations, and take into consideration that possibility of major bugs.
Minimalism can hurt discoverability throughout the app. In our case, hiding information behind drawer and tabs reduced interactions in those sections.
One of the reasons I had to hide information, was to improve page loading speed, by minimizing the number of requests required. Instead we should’ve focused more on improving requests from the backend.
Don’t block users with login. People usually like to see the value you offer themselves before committing to sign up. Even if they only have to click a button to enter.
Mobile first experience. Although I’m a believer of the mobile first approach to design, in this situation, I broke the rule.
I thought there is already a mobile application, and people would use it instead, of which I was wrong. There are so many reasons that people would use the web version instead of the native one.
© Seif Sallam 2021