This is the second part of our Essential Mobile Components series and we will be focusing on all the design patterns and user experience concepts around the Identity category.
When developing a mobile application, there are some standard elements that are expected to be in place, functioning in a way that's intuitive to the user. It becomes counterproductive to divert from some best practices because it could cause confusion, making the user experience a hard one.
After a long time processing two books that changed the way we design mobile apps (Mobile Design Pattern Gallery, 2nd Edition & Designing Social Interfaces, 2nd Edition), we created a series of articles and resources for you to learn the fastest way possible!
We're going to be releasing them every week so stay tuned to and don't miss them!
Knowing that sometimes it's impossible to keep up to date with the latest trends in mobile design, we created a list of essential mobile components that you should use in when building your app.
If you are building a social network app, then all the information in this post will be key to get the building blocks of your social network right.
Identity is the key thing that will engage users in your system, and keep them returning to experience it.
There are several key areas that form ‘identity', like profile, personal dashboard and identity cards.
The profile is one of the key pieces of a social offering. It becomes the virtual face of the user in your system.
Another key piece of the identity setup is the personal dashboard. The user wants to check in to see status updates from their friends and current activity from network e.g. comments from friends on recent posts.
The final piece of the identity puzzle we will consider is the Identity Card or Contact Card, used when a user wants to get additional information about another participant in an online community without interrupting their current task.
We all know that social apps revolve around people, what they're contributing and who they are.
All people and their representation of themselves online, and the contributions they make, is what creates a rich and intertwined community. If they don't understand who you are, they won't know you, they won't trust you or want to connect with you.
The assemblage of patterns acknowledges the different interfaces that present personal information or activities about a person to other people. These are the components that are considered as a user's brand: the profile that a person reflects to others, creating a perception of them. This encompasses the profile and the personalization of that profile, the avatar, which information needs to be private, and a personal dashboard where the person can see that's happening across their personal network.
The profile ought to be combined with attribution presentation, contact cards, and other open data to create an individual and rich people-centric driven experience.
The profile and the presentation of a user, whether robotized through activity or modified by the individual, is the way you become acquainted with somebody; it gives your users the chance to express whichever side of themselves they are open to share with the world.
Here are some points to consider across all the patterns in this section:
Give your users the ability to be expressive where it matters to them.
Contingent on the nature of your app you could include profiles that are more expressive and mirror a more personal approach, or maybe you want to constrain and make profiles not so customizable and reflect the professional nature of the interactions within your app.
Let users take control over how to present themselves.
They should own their actions and have a reputation attached to their identities, but it's good to give the option to stay anonymous in some instances.
Let your users decide who can see what parts of their profiles.
Allow enough control and permissioned access. Do my friends see my birth date, or does everyone? If it's everyone, be prepared for a lot of fake data.
Be clear on reflecting back to users what they see as editors/owners versus how others see them.
The dating sites have this idea down to a science, but on many other websites, who sees what isn't clearly articulated.
Clearly communicate the privacy policies around the information users add as part of their profile; for example, which items will be seen or not, and which will be used anonymously in aggregation as part of the business data.
How to handle Identity?
I've found that a tripartite identity model best fits most use cases, and should be forward-compatible with current identity-sharing techniques and future recommendations.
The three components of user identity are the account identifier, the login identifier, and the public identifier.
Account identifier (DB Key)
From an engineering perspective, there is always one database point—one way to access a user's record and one way to refer to them in cookies and potentially in URLs. In a genuine sense, the account identifier is the closest thing the company has to a user. It should be one of a kind and permanent.
Typically this is represented by a extensive random number and is not under the user's control in any way. Actually, from the user's point of view, this identifier ought to be invisible or at the very least inert; there should be no inherent public capabilities associated with this identifier. For instance, it shouldn't be an email address, accepted as a login name, or displayed as a public name or as a status in an instant messenger address.
Login identifier(s) (Session Authentication)
Login identifiers are necessary to create valid sessions connected with an account identifier.
Logins are the user's technique of providing access to his privileged data on the service. Normally, these are represented by unique and validated name/password pairs. Take note that the service could adopt identifiers from other providers (commonly known as "social login", typically with Facebook, Google, Twitter, etc).
For instance, lots of services accept email addresses as login identifiers, normally after making sure that the user is in control of that address. Progressively, more sophisticated capability-based identities are accepted, such as OpenID and Facebook Connect, which gives login credentials without constantly asking for a name and password.
By separating the login identifier from the account identifier, it's simpler to allow the user to personalize his login as the situation changes. Since the account identifier needs never change, data migration issues are mitigated.
Likewise, isolating the login identifier from public identifiers shields the user from those who would crack their accounts. Lastly, a service could provide the chance to attach multiple different login identifiers to a single account, thus allowing the service to aggregate information gathered from multiple identity suppliers.
Public identifier(s) (Social Identity)
Unlike the technically required account and login identifiers, the public identifier represents how the user wants to be seen by other users on the service. Imagine it like clothing or the name by which people know you.
By definition, it does not have the technical prerequisite to be 100 percent unique. There are many John Smiths in the world, thousands of them on Amazon, hundreds of them write reviews, and everything seems to work alright.
Online, a user's public identifier is normally a compound object: an avatar, a nickname, and maybe age, gender, and location. It gives sufficient data for any viewer to rapidly interpret personal context.
Public identifiers are usually linked to a detailed user profile, where more identity differentiation is available: "Is this the same John Smith from New York who also wrote the review of The Great Gatsby that I really like?" or "Is this the Mary Jones I went to college with?"
A sufficiently diverse service might want to offer lots of public identifiers when a specific context requires it. For example, when playing wild-west poker, a user would prefer to present the public identity of a rough outlaw or a saloon girl without having that imagery associated with his or her movie reviews.
Now, let's focus on the design patterns that compound the identity of the users within your app.
The Profile is one of the key pieces of a social offering. It becomes the virtual face of the user in your system.
Profiles are a place for users to express themselves and to create a "voice" or "image" of how they want to be seen in the context of your site.
Depending on how your site operates, profiles can be a hub around which relationships and activities revolve. In many services, profiles function as an aggregate representation of all the activity of a user and their friends.
Users seek a central, public location to display all the relevant content and information about themselves to others. This desire to share the "curated version of oneself" is directed on both those they know and those they don't, although the information they choose to share with each group may be very different.
The user wants to check in to see status updates from their friends and current activity from network e.g. comments from friends on recent posts.
A central profile for your service is the hub that relationships and other activities can revolve around.
The Personal Dashboard is the companion to the Profile. The dashboard should contain access to activities that the user wants to participate in on an ongoing basis and show information they wish to check regularly.
Dashboards can be thought of as the user's version of the homepage for the site and it revolves around recent activity.
When a user wants to get additional information about another participant in an online community without interrupting their current task, this is where Identity Cards come in handy. The desired information may include identity information to aid in recognition and to help the user relate to the participant; or reputation information (to help the user make decisions about trust).
Identity cards make it possible for the user to interact with another participant in an online community, in a predictable manner and in a known context. They also provide the means to reduce identity related screen clutter.
We have learned a lot in our journey to develop great mobile apps and we aim to share all that knowledge (both design and technical) with the community.
If you are planning to build a mobile app, we suggest you to consider Ionic Framework.
Check out all of our handy tutorials to learn the how to's of every major mobile capability (maps, geolocation, facebook login, form handling and validation, etc). You can also get inspired with our design inspiration section.
We also want to help you create awesome apps! You can find many high quality ready-made mobile templates covering most of the patterns mentioned above that will ease your pains and save you weeks of developing time so can you just focus on customization and the core value of your app.