Product Pattern — Social Sharing
A product pattern is a general, reusable solution to a commonly occurring problem. The goal is to encourage thinking around a particular problem and different approaches to solving.
(another in this series)
Everyone wants to tell the world what they’re doing and every app wants to be recognized for they inspired. Sharing out to social networks is a common pattern, but there are complexities to consider.
Sharing via Facebook:
Gone are the days where you just shared some pre-populated text. On FB, a share is broken into parts of grammar syntax you probably left behind in high school. These are called “stories”. A share can be about an Object, or an Action on an Object. Facebook wants to know the ID of the Object, as well as the verb tenses for what you did to that object (“Visiting”,”Visited”, “Want to visit”). All of these need to be configured inside Facebook before you can share. “Nic is <drinking> <Taft Street 2014 Pinot Noir>”
Why this level of detail? You’re leveraging the power of what Facebook calls the “Open Graph”. Using explicit nouns and verbs means Facebook can style or display your data in a unique way that stands out in the feed. Read more about common actions.
Because of this built-in attention, I recommend you stick to the default actions. If you want to try custom stories, read more here: Custom OpenGraph Stories
To think about first:
- What is it that the user is sharing? Is it an Object? An Action? An accomplishment? Make that the focus.
- To whom is this providing value — the user or their audience? Are they looking for a response? Write your copy to appeal to them, including a call to action if necessary.
- What context is the user in? If they’ve just created something then the action of sharing is enough. If it’s an upcoming event, they’re encouraging people to join them and they are likely to spend more time crafting their message. For the latter, your design should accomodate the need for more space, or a Draft feature.
- Facebook requires additional permission for first-time posting. You cannot ship without handling for when users deny this permission.
- You’ll need to create a Facebook “app”, and all actions/verbs/objects will need to be approved by Facebook. This can take time.
If you answered “virality!” to any of the above, STOP. Rethink in terms of the value to your USER.
What your user is thinking:
- “I‘m afraid this will spam all my friends”
- “Look how cool I am, doing <x>!”
- Can I see what the post will look like before it sends?
- Can I change what the post will say before it sends?
User Scenarios:
Happy path:
Scenario One: User just created an object and as they are about to post it inside your app, they also want their social creatures to know how cool they are.
- User has finished uploading their photo and ready to share
- In app, they see a thumbnail of their photo
- They enter a comment they want their friends to see
- They choose who will see it
- They tap ‘Post’
- A permissions screen appears. They click ‘Approve’
- Object (photo) is created, shared to Facebook and they are returned to originating screen (usually a Feed)
Scenario Two: User found a cool Thing and they want the world know about this cool Thing.
- While looking at an object, they tap a Share button.
- They see pre-populated text of what your app will post
- They add a caption of their own for context
- Taps “Share”
- Confirms permission request
- Sees confirmation that their post was successfully shared
Sad path:
- User doesn’t give permission upon initial request. How will you message this?
- User confirms permission, but later goes into FB and revokes permission. Your app assumes the permission still exists, and crashes.
- No internet connection. Are you going to cache this share and try again later, or just tell the user to try again?
Recommendations:
Object targets: Do you want FB users to be able to click on your Object? Should they go to your web page? Or a FB page? What’s your goal?
Ex: For Foursquare, their value lies in the user tips for a venue. Therefore, they don’t link to the venue’s web page, but they link back to their own venue page, and jump you to the tips. This way they create a uniform, controlled experience (most venue web pages are clunky and not mobile friendly)
Facebook requires additional permission for Posting. Bind this request along with the users share action so they understand the request.
Think about the dimensions of your photos. If you are posting photos of objects, you want that object to be the focus so it grabs attention in the user feed. Instagram takes only square photos, but they have a preview mode that lets the user rearrange the object focus. If you are going to automatically crop, grab from the center, that’s generally the focus.
What happens if your app fails to create the original object? What does that flow look like and how would you message the user? If they Retry the original object, do you still couple the share action alongside?
If your app supports commenting, do you include the comments from Facebook as well? Generally a bad idea, and confusing. Look at Techcrunch’s comment system and how many people mistakenly post a comment when they think they’re sharing an article to their friends.)
Power-move: If users have Denied posting permission in the past but try to share again, message them with instructions on how to re-enable sharing. (Technologically, your app makes a request to see if it has this permission).
Analytics to Track:
- # of shares
- Ratio of shares/user
- # of shares over a period of time
Further reading:
Facebook Sharing
Do you see a commonly occurring product pattern that I should write about? Drop me a line in the comments area, or tweet to @nic
Next up: Product Pattern: Social Login
