My NYTimes Wishlist
I tweeted in May about things I would have loved to see happen if I had stayed at the Times. During my move to Seattle I wrote up these thoughts but wasn’t sure if I really wanted to post them - for many reasons.
It’s too easy to say all this in retrospect. I’m no longer there so I don’t have too worry about the complexity of some of these projects.
Lets add a bit of background - I worked at the Times for 7+ years. From Customer Service, Content Management, Client Technologies (frontend dev etc) and over briefly to the Mobile group. I began as a temp (my first job when I got my work authorization from the INS, BSCIS, USCIS) and left a Senior Product Engineer. Leaving the job was more about New York than the Times itself.
So far so good? Then let’s add a few big disclaimers.
This is NOT many things. It is not a “old media doesn’t get it and… blah de blah… dead-tree etc” rant. It’s not “you are doomed unless you x, y, z”. It is not about the endless tweaks you could make here and there. It is not a complete list.
This IS something else. This is personal opinion. It is what I would have loved to do given more time at the Times. It is high-level for the most part but i have thought out the details. Its more functional and service based. Some of these are definitely things that were proposed then shut-down or vetoed but I’m not saying which ones. This includes items I have pitched internally. This includes at least one that was gaining traction before I left.
Still with me…?
1. Ubiquity
This started off as my entry to our Innovation Challenge back in 2008(?). If you work at the Times search the Dev wiki for the horribly named ‘Fresh Lede’). The best example of this project is in regards to our Homepage. This is a heavily curated highly trafficked piece of screen real-estate. Depending on the news of the day there is a lot of content that is rotated in and out, and more that could be up there but never makes it.
I find that as an avid news reader I return to the Homepage and still see stories I have read taking up space where new content could be.
The idea is to minimize, or remove content you already ‘read’ so as to push new content into it’s place. This pool of new content could be anything and subject to debate. I would go with: A collection of editorially ranked content that is sorted based on time, rank, known user preferences (never, ever, ever, show me anything from the Sports section), trending within readers network. But thats just me.
A few considerations:
- Updated Articles are considered new again.
- It’s not enough to consider a Article in a ‘read’ state just because it is viewed. You need to factor in some interaction or time on the page - that requires more research and fine tuning. Would hate to see a button as only option to mark it as ‘read’.
- The reader has to have the ability to seamlessly return to the last Article they were reading. It must be with one single platform-sensitive action.
- This needs to be built in to every application on each platform. If I am reading an Article on the web site and I leave to take the subway I should be able to open my iPad and immediately (or one gesture later) be back at the very paragraph I was last on. Likewise if I am in the middle of a video on Boxee and I switch over to the iPad, I should have the option of continuing playback.
There are many ways to skin a cat. The big take-away for this should be the notion of adding ‘state’ to content, be it unread, read, position, dismissed, liked.
Oh, and include an API for this too.
Apologies if you have already heard me yammer on about this one over the last year…
I have an iPad, and like most users I use a single application (“Reeder”) to read all the blogs and other sources I’m interested in via Google Reader integration. It providers an experience I prefer over all others. I love this app.
When I read the WP, CNN, NYTimes etc I must exit and open their respective application, have it sync, load content, maybe crash, and then here I am with a different experience just for that one news source - different UI, layout, theme, menus, logins, oauth’d accounts, settings… I then switch back and fourth.
End result: I rarely use the Times iPad application. Or any other single source news application.
There is a very easy way to set the Times apart and ahead of the competition. Let the paying readers have the content anywhere they like, in their preferred environment. No one else does it (yet), it would be a huge carrot to get more people to subscribe, and give more still an incentive to make us their one payed subscription over other sources.
Enable application developers to register for an API Key. With this Key they can now validate a users NYT account to verify they are subscribers in good standing. Upon confirmation, they get access to full article and blog content.
This can be done in a way that addresses concerns about ads, abuse, reader feedback, behavior and pageviews.
Allow other developers, designers, and companies to build out features that make the journalism shine, to learn from that and pull it back into the Times apps when something fits. Allow readers to have a seamless experience as they move around devices and mediums with none of the over-head other than putting this service with support in place.
That’s it. I’m not the greatest at pitches but I believe I’ve at least covers the main points.
The success of this is dependent on putting the user first giving them what they want. It will be huge. I promise. And I’ll pay for it.
3. Web App VS Native
I can’t say I’m a fan of Apples 30% cut of subscriptions or the fact that they lock up the customer relationship. There is the claim that people don’t know about the NYTimes app until they magically find it in Apple’s app store, or Amazons app store for that matter.
I think that we are at a point where a web app for reading and interacting with news would equal or exceed a native app. It would also cut down on platform specific development and associated overhead by embracing the whole feature-set covered under the HTML5 umbrella. The Times certainly has the expertise and the talent to pull this off.
I, personally, would pull the iOS apps (even after this was noticed today). Just a thought.
4. Web Site VS 2005
The last redesign was in 2005 (launched in 2006) and marked the move from a table based layout (though you can still hit some of those pages that were not raptured).
Rather than propose an overdue redesign why not push to a web application. Its where it is all headed. Think Facebook.com or Twiter.com of today. Kudos to Gawker.com for being the first content site to try this.
This would be an opportunity to kill all the legacy hold-overs, remove internal politics on who has what module and where. It would address a host of problems that come with a site last rebuilt 6 years ago.
I could ramble on here for weeks. I’ll just say that I would love for the Times to be a cross of Gawker meets Twitter meets Tumblr - and a lot of what I’m proposing elsewhere can be done through a project like this.
Fin.
Side note: Hey, NYTimes developers! You can build all of this right now. You don’t get very far if you only stick to your job description - I am very serious. Build things. To quote a former colleague of mine who may or may not work at Tumblr, “no one ever got fired for launching something”.
I hope this is helpful and not just a badly written ramble as I sit in my apartment as some nice men use up all the toilet paper and take all my worldly possessions and pack it into a truck bound for Seattle.
As times goes on I’ll try and add to this list. My big concern is being mistaken for one of those blow-hards who looks in and thinks they have all the answers and believes that ones doing the actual work, in the tenches, somehow haven’t a clue. Actually, my big concern is if I eventually become that without realizing it.
