Washington Post Social Reader: FB Hack Preso 01-18-2012
•Download as PPT, PDF•
1 like•1,011 views
The document discusses strategies for developing mobile applications, including: 1. The company launched their mobile app in September and had 8 million installs within the 18-35 demographic. 2. They built the mobile app second after the web app to rethink boundaries and the core experience, and then rolled mobile learnings back into improving the web app. 3. Tips are provided for building HTML5 single page apps, including avoiding handwritten templates, consolidating data structures around specifications, and not waiting for the Facebook JavaScript SDK.
Recommended
More Related Content
Similar to Washington Post Social Reader: FB Hack Preso 01-18-2012
Similar to Washington Post Social Reader: FB Hack Preso 01-18-2012 (20)
Recently uploaded
Recently uploaded (20)
Washington Post Social Reader: FB Hack Preso 01-18-2012
- 1. by
- 2. september launch 8 million installs 18-35 demographic
- 3. mobile HTML5 double digit traffic native (coming soon)
- 8. mobile HTML5 double digit traffic native (coming soon)
- 9. 1. coding for the futures
- 10. 1. coding for the futures “ <coding for the futures” +
- 11. everything you write effects possible futures “ coding for the futures” +
- 12. be deliberate when you have to do it wrong “ coding for the futures” +
- 13. architect for the foreseeable futures “ coding for the futures” +
- 18. and long term futures
- 19. backbone.js and REST JSON api before we could even support single page
- 20. closed off the fewest future options
- 21. conceived, design, built, and shipped mobile in 6 weeks
- 22. coding for the futures “ coding for the futures />”
- 23. 2. building mobile second
- 24. 2. building mobile second “ <building mobile second” +
- 25. “ building mobile second” + makes us (me) feel better =)
- 26. “ building mobile second” + but we learned a lot, too
- 27. “ building mobile second” + mobile and web are facets of the same product
- 28. “ building mobile second” + it will probably be multiplatform at the end of the day no matter what
- 29. “ building mobile second” + use <platform> second as a chance to rethink the core of your experience
- 30. social reading had no conventions or boundaries
- 31. screen shot of first app implementation
- 32. used mobile to rethink boundaries
- 35. we’ll roll mobile learning back into web app
- 36. and then do the whole thing again
- 37. “ building mobile second />” building mobile second
- 38. some tips and tricks for HTML5 and single page apps
- 39. avoid these two
- 40. HTML in your views View.render = function(name){ return ‘<span>’+name+‘<span>’ }
- 41. lots of keys in localStorage window.localStorage.length > 1000
- 42. ‘ tis good stuff
- 43. black box your js templates $(‘.fp’).html(Templates.facepile(peopleJSON))
- 44. get javascript weekly javascriptweekly.com/
- 45. don’t wait for the FB js sdk fbQueue = $.Deferred(); fbAsyncInit = function(){ fbQueue.resolve() }
- 46. for native SSO around HTML5, try passing the tokens if(access_token && user_id){ _startApp() } else { Auth.getUserAuth(_startApp) }
- 47. consolidate you data structures around spec ActivityStreamsArticle = { objectType: ‘article’, id: ‘x6hf3’, url: ‘ https://myapp.com/a/x6hf3 ’ }
- 48. /* clowntown */
- 49. handwritten templates template = function(data){ return ‘<div></div>’ };
- 50. our stack
- 51. on ye old client requirejs jQuery underscore Backbone amplify.store typekit.js RESTful routes coffeescript less
- 52. on ye old backend AWS Cloud Services python pyramid groovy grails MySQL, SimpleDB, Redis, Memcache
Editor's Notes
- 1. Hey all, thanks for coming to this NYC facebook hackathon. I hope everyone's been having a good morning so far. I'm Charles Covey-Brandt. I'm the tech lead for a product called The Washington Post Social Reader, a news reading app that Washington Post Labs launched with Facebook's Custom Graph in September of last year.
- Social Reader is a big product for us and a great experiment into news distribution, personalization, and social reading. Since launch, we've totaled 8 million users. And, more importantly, a very large number of our users are 18-35 years old, which, if you're familiar with the traditional news industry is pretty unheard of.
- We are on the web in the Facebook Canvas, on mobile web, and targeting a native release in the next month. So far, we're seeing that social news can be very successful.
- The app is centered on social reading, this means that when you read an article, all your friends will be able to see that you read that article. and you will be able to see what your friends read.
- to do this we're leveraging Facebook custom open graph and read action. Whenever a user reads an article, we fire this to facebook.
- And the result is a really nice aggregation in a user's news feed of all the articles their friends recently read.
- and here's the mobile version.
- so building all of this out has been quite an interesting process, I want to share today with you two ideas we've picked up and sorta latched onto over the past year or so building the Social Reader.
- --- Also, I like to be informal with presentations, so just yell or something if you have a question before I'm done.
- Code for the future So, first thought that I'd like to share is the importance of is coding for the futures.
- 1. So what does this mean? Well, probably three things to us. First, coding for the futures means that every line of code we write will effect the possible paths we can take down the line. So we try our best to implement each template, method, or new lib we write with and understanding of how it will effect the paths we have available down the line.
- 2. coding for the future also means when we can't do it the right way, we try to be deliberate so that our less than pretty decisions (whether a function or a full on service) are properly abstracted away in their own little box. It makes cleanup much easier for us when we actually can get around to it, and it makes everyone working on the project much much happier.
- 3. thirdly, and perhaps most importantly, coding for the futures means that whenever we make a larger architectural decision, whether its a RESTful route path, or a decision to use a new library, we take the time to figure out how that decision will effect where we want our product to be in the foreseeable future. and i'm not talking about next month, but the next year. this saves us time down the line when we need to move quickly.
- so I know that these seem like basic ideas, but its amazing how often I find my own code completely tangled, or realize later on that i made an architectural decision without considering the long term effect on our product.
- a great, relevant example on the micro scale from my own code is failing to abstract away the FB SDK. Is it possible that at some point in the future we’ll not have the FB js sdk available in the DOM? If so, then this is suddenly really unmaintanable code. Better yet, what if at some point in the future we decide to serve the user object off of our own servers?
- For about 4 months, our code base has referring to the FB javascript sdk directly. Now, that really sucks when a method disappears or doesn't return the way you expect it to, or when you decide you want to fire that graph call differently. so we abstract this stuff away.
- and then, down the line, this helps us when we have to change the underlying methods. i know this is basic stuff, but it really happens all the time that we fail to do this.
- So that's just a really short term example of coding for the futures. a good example of thinking for the long term might be decisions we made when we first built to the social reader
- when we first architected the social reader about a year ago, we decided to go with a single page javascript implementation of Social Reader. so this might seem really obvious now, but a year ago we couldn't even implement the features that a single page app would offer like hash routing (have you tried hash routing in facebook's canvas? its not pretty).
- but we had a sense at the time about where we wanted to be in a year, so we went with a stack that would close off the fewest options.
- about a year later it allowed us to move really fast on mobile: conceiving, designing, coding and shipping the mobile app in about 6 weeks.
- so the first thing i want to leave you with is the idea of coding for the futures. it should be a different take on a well worn concept, the idea of trying to see the short term and long term possible implementations of your product and make sure to close off as few of those options as possible with every decisions you make.
- Mobile second The second concept that we sorta like to toss around is the idea of mobile second.
- So this one might just be a way for us to feel better after having spent months building a web app only to have everyone start talking about mobile first.
- On the other hand, I think that we learned a lot building a web app first, and I think it has helped us to think about our development cycle in different way and how our product as a whole will grow and change over time. also, i understand that we're here for a mobile hack, so bear with me here.
- 1. So what does mobile second mean to us? First off, building mobile second means understanding that mobile and web and native and desktop and whatever else we are on are all facets of the same product, and its a business decision for us to choose one or another to develop for first. We had the most potential users on the web, so we concentrated our resources there when we first built the Social Reader.
- 2. For us, mobile second also means that it is an engineering imperative that we recognize that we will eventually be developing for all platforms. its not mobile first, its really multiplatform first. at any one point we are talking about mobile, tablet, desktop, full web, set top box, game console, etc.. so when we built social reader, we started with an architecture that would serve multiplatform as best as possible from the get-go, and whenever we make an architectural decision, we try to consider how all our possible implementations will be effected. This definitely slows us down, but again, it makes it much easier to move fast when we need to.
- 2. But probably the most important part of our mobile second mantra is meant highlight the cyclical nature of our development, and how we use the development cycle to iterate and make all of our platform implementations better. This really means that we are using whatever platform we develop for next as an opportunity to rethink our core product and experience.
- So, this has actually become really important to us from a product and development standpoint, so I want to quickly share how this has effected our process building the mobile web app. When we started with our web product, we were really starting with a blank canvas because no one had really done social reading yet the way we wanted to. because of this, we didn't have UX convention to follow, or frankly any UX boundaries.
- So our initial application in some way reflects this: a lot of our navigation is pivoted around streams of articles like a newspaper. When we released in september we didn't see nearly the engagement in the personalized front page of our application that we expected. At the same time we were starting our mobile development.
- So we used working on mobile second as a chance to rethink what navigation meant in a social reading context.
- The result is that our mobile app doesn't assume that our users will go to their &quot;front page&quot; to get more articles. instead, we put more articles right below whatever they're reading.
- We also did away with article streams navigation and built our nav completely pivoted on friends. And we essentially did away with the front page as a landing place. From one perspective these are pretty drastic moves, but for us, these changes are part of the learning cycle.
- Now with our mobile implementation, we're learning a lot by seeing users interact with this new navigation, and we are rolling these learnings back into the full web
- And we're looking forward to running this cycle again by taking what we learn from the web app and rolling it into mobile and our other platforms down the line.
- So that's really the essence of what we think of with mobile second. The big takeaway here, by the way, isn't that mobile second is that way to go. that's just how we did it. the real takeaway is that there should always be a second. use multiplatform as a chance to rethink your core product and experience, and roll what you learn on one platform back into the others.