Creating a Facebook Clone - Part I - Transcript.pdf

Creating a Facebook Clone - Part I
I almost always start apps by building a mockup of the frontend first. We are driven by visual feedback. The ability to see and interact with the app clarifies the problem
space and motivates you to move forward. Backend and business logic become easier as you can associate them with requirements from the GUI.

One of the benefits of having mockup code is that it's easy to experiment with the mockup. For example we can comment code in/out and see how it impacts everything,
move UI elements around to judge impact etc.

Deconstruction
✦Deep vs. Flat
✦Forms With no functionality
✦Plain Text Password
✦Delayed Verification
✦Device Orientation Behavior
✦Phone vs. Tablet UI
✦Adherence to platform conventions
© Codename One 2017 all rights reserved
Before we jump into the implementation of the mockup we first need to understand what we are building and study the refrence. In this case the reference is the
Facebook app so we'll start by deconstructing it. I'll begin with the login process which is the first thing you see when you install the Facebook app.

There are a few things I'd like to discuss about the login process. Deep vs. Flat (also known as Shallow) UI structures.

Forms With no functionality

Plain Text Password used in the UI

Delayed verification process

Device orientation support in facebook

Phone & tablet UI

And finally the adherence to platform conventions in iOS vs. Android. I’ll go over all of these one by one but first lets take a brief birds eye view of the sign in UI.

Sign In UI
This is the signup UI in the native Facebook app on Android. Don’t panic, I’ll go over all the steps. I will also simplify it a lot because this is a mess as you can tell…

Sign In UI - My Version
This is what I came up with, as you can see it’s much simpler but includes a lot of the features we saw before. I’ll go over all of this soon but first lets get back to our
agenda.

Deep vs. Flat
✦Deep
✦Flat
✦Facebook chose both
✦Intuitive
✦Portable
✦Process
There are two approaches we can take for user input. With deep we ask simple questions in each form & dig deep through forms until we have all the information.

With flat we show one form with all the information we need. The previous graphic showed a deep approach whereas the edit details form on the right takes the flat
approach.

Facebook clearly picked deep for the signup process and did so for various other concepts but within the app it often picked up the flat approach e.g. for editing user
preferences. Why was Facebook inconsistent & why pick one approach or the next? 
 
There are several reasons to pick a deep UI. It’s Intuitive. Even those who have aversion to technology can understand the flow of the UI.

It’s Portable. More whitespace on the screen allows the UI to resize and adapt a wide range of display sizes

It goes through a Process. As humans we are used to this approach

Deep vs. Flat
So if deep is so great why doesn't Facebook use it everywhere? Because it has some limits. The biggest is expressiveness. It's very hard to communicate complex data
and ideas like we see above where gender has complex options or a person might not want to advertise their birthday…

Annoyance is also an important limit. Going through a 7 step wizard to change a single detail is annoying to most users. 
Picking deep/shallow approache is a matter for a UX expert. As developers our concern is code reuse. How do we express two distinct UI paradigms & map to the same
data model?

Since the Facebook UI is so darn simple I'd like to automate a lot of it and one of the core goals is automating this logic.

Sign In UI
Lets go back to the flow graphic we looked at before

Sign In UI
The splash screen is shown when we start, this makes sense for platforms like iOS but it’s there on Android too. The logo blinks a bit

Sign In UI
Then we move to the login form. It lets you input the email or phone. Notice a few interesting things about this form. It doesn’t use the material design style of labels on
top of the text field when elements gain focus but it does try to comply with some Android paradigms. For instance the buttons use uppercase text which is the
convention on Android

Forms With no Functionality
The Create Account UI is one form that literally has no purpose… When I looked over the UI I was perplexed by this.

I'm guessing there is some UX reason for this form but I have no idea. I didn't include anything like that in the clone and there is no equivalent of that in the iOS version of
the native Facebook app.

Sign In UI
Before I discuss the name form notice a few interesting things about this wizard. The word Next is spelled in the style of iOS with case sensitive text instead of
uppercase. Also notice that here the first & last name fields use material design convention for placement and when you select them the hint animates above the field
unlike the first form of the application.

I think this inconsistency is due to diﬀerent teams building diﬀerent parts, it contributes to an app that feels unrefined in some regards.

Sign In UI
This is a long wizard with quite a few stages and notes. There are small inconsistencies with the UI for birthday and the gender prompt doesn’t look great. During
verification we can enter either a phone number of an email in the case of the latter we can click the signup with email address link at the bottom or the form which sends
us to the email entry form

Sign In UI
The email entry form is practically identical to the phone number form and you can toggle back

Plain Text Password/Delayed Verification
The final stage is where interesting things happen. Typing a password on a mobile phone is one of my biggest pet peeves. There is literally no reason for doing that.

Facebook solved that (badly) by making the password visible by default. Their old UI would show a regular password field and oﬀer to replace it with a plain text field if
you got the password wrong. The current approach is problematic & shows the lax approach to security at Facebook.  
I will still clone that approach even though I don’t like it because it’s common practice.  
While we are on the subject of verification Facebook doesn't verify during signup. I could have given a completely fake email and the process would continue until the
end. Facebook, nags after the fact to make sure the email/phone is correct but you can complete signup with a wrong email/phone.

I'm assuming this relates to the challenge of deliverability to email/phones on a global scale. I won’t do that although you can probably adapt the code to copy that
behavior.

Device Orientation Behavior
Facebook supports device orientation changes everywhere, it often achieves this UI by removing content. Surprisingly this isn't consistent for other apps from Facebook.
E.g. Instagram is locked to portrait orientation.

At first when I looked at how Facebook implemented landscape support my first thought was: "lazy". To be fair, a lot of apps lock orientation change altogether (e.g.
Instagram, Uber etc.) so landscape support in Facebook is refreshing. It still looks bad.

It might be related to the universal nature of Facebook. The app should work everywhere and might be under constraints we can't imagine. But I find that hard to believe.
It just looks like something they didn't care enough about to invest in.

This makes some sense, I doubt most users rotate their device during the signup process.

Phone vs. Tablet UI
Signing up on an iPad is radically diﬀerent to the signup process in Android. It's clear that there are distinct groups developing the application. The entire UI is shown
within a dialog that updates with the progression of the wizard. Lets zoom in a bit on the stages

Adherence to platform conventions
Facebook clearly has two separate teams for iOS/Android. The apps are inspired by some common design language but take very diﬀerent approaches for some basic UI
features.

The Android version uses some aspects of material design and the iOS version looks somewhat like an iOS app but neither one stands out as an example of great design
in the given native platform so what's the point? 
You will notice that the flow of the stages in signup is diﬀerent between iOS & Android. Terms are in the beginning instead of in the end & there are no redundant forms.

Notice I magnified the UI so it will be more visible as the iPad resolution is so big it would make the entire text unreadable. The stages are pretty much the same
conceptual stages as we saw in the Android app but slightly diﬀerent

Again the password is plain text which shows that this is a clear policy decision.

The gender question is probably the most telling. In the iOS version it's expressed as a toggle button whereas in Android it's expressed as a radio button. The former is
clearly superior but it's available in iOS only.

iPad
The app itself doesn't use the iPad form factor eﬀectively. For the most part it feels like a blown up phone version of the app which is stunning for an app like this. It does
show a search UI on the side when running in landscape mode but that's pretty much it.

How would this UI adapt better to tablet form factor?

The feed is about posts, right now they are just blown up to a size that doesn't help. If I use an iPad it's not for seeing larger posts. We could fit 2 or 3 columns of posts in
the feed and significantly increase information density.

There are some other considerations for Facebook such as ad placement which might be impacted. This UI choice is also reflected in the web version of Facebook so
I’m guessing it’s a conscious choice.

The Main UI
There is a lot to say about the main UI of Facebook, lets start by reviewing the Android version of the UI so we are all roughly on the same page. I trimmed a lot of hidden
nuances and details from this chart!

No Hamburger
After looking at this I developed several insights into the Facebook UI. But one of those was specifically interesting: they removed the hamburger...

Back in the day Facebook was one of the first apps to feature the "Hamburger side menu". This is a UI element signified by three horizontal lines one on top of the other
(hamburger). It allows you to open (or swipe in) a "drawer" with options.

This menu is now a standard in Android. However Facebook chose to discard it in favor of swipable tabs at the top for Android and on the bottom in iOS.

On a personal level I'm conflicted about this. It's cool that Facebook goes against the trend, especially since it's a trend they helped start. Tabs have the UX advantage of
visibility which is great.

However, they have 3 major disadvantages:

First: They take up extra screen space

Second: They show only an icon, new users might be confused about what these icons mean

Third: It’s a step backwards, tab based UI's were popular in 2009

Despite these reservations I'll copy their style in the UI. We built a lot of demos with side menus so I'll use this opportunity to build something diﬀerent.

I’ll come back to this diagram later when we go over the implementation.

Creating a Facebook Clone - Part I - Transcript.pdf

More Related Content

Similar to Creating a Facebook Clone - Part I - Transcript.pdf (20)

More from ShaiAlmog1 (20)

Recently uploaded (20)

Creating a Facebook Clone - Part I - Transcript.pdf