<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (rahuldave)</title>
    <link>https://pinboard.in/u:rahuldave/public/</link>
    <description>recent bookmarks from rahuldave</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="http://mattgemmell.com/2012/05/02/ipad-productivity-apps/"/>
	<rdf:li rdf:resource="http://www.readwriteweb.com/archives/other-apps-could-learn-from-newsmes-location-features.php"/>
	<rdf:li rdf:resource="http://radar.oreilly.com/2012/02/apple-itv-television.html"/>
	<rdf:li rdf:resource="http://feedproxy.google.com/~r/readwriteweb/~3/WcyHIHUjP-0/how-facebook-mobile-was-design.php"/>
	<rdf:li rdf:resource="http://feeds.gawker.com/~r/lifehacker/excerpts/~3/_vufr9iCL4U/let-your-smartphone-write-bibliographies-for-you"/>
	<rdf:li rdf:resource="http://www.zeldman.com/2010/12/16/flipboard-update-preview/"/>
	<rdf:li rdf:resource="http://www.zeldman.com/2010/04/14/designing-for-ipad/"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="http://mattgemmell.com/2012/05/02/ipad-productivity-apps/">
    <title>iPad productivity apps - Matt Gemmell</title>
    <dc:date>2012-05-03T20:41:21+00:00</dc:date>
    <link>http://mattgemmell.com/2012/05/02/ipad-productivity-apps/</link>
    <dc:creator>rahuldave</dc:creator><description><![CDATA[The apps he uses.



 ★ 
]]></description>
<dc:subject>apps ios ipad</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rahuldave/b:f340994bf8b3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:apps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:ios"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:ipad"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.readwriteweb.com/archives/other-apps-could-learn-from-newsmes-location-features.php">
    <title>Other Apps Could Learn from News.me's Location Features</title>
    <dc:date>2012-05-01T14:01:00+00:00</dc:date>
    <link>http://www.readwriteweb.com/archives/other-apps-could-learn-from-newsmes-location-features.php</link>
    <dc:creator>rahuldave</dc:creator><description><![CDATA[
 
      


 
                   
A new feature of News.me for iPhone delivers your news to your device whenever you leave the house. It’s called Paperboy, and it uses iOS 5’s built-in geofencing to wake up the app and download fresh news in the background. How cool would it be if your grocery list or your podcasts worked the same way?

 

Delivery at Your Doorstep

Front-end developer (and Chief Marketing Officer) Jon Ferrer came up with the name Paperboy, and it’s a perfect description. News.me gathers all the news articles shared by your friends on social networks and streams them to you in a clean interface, which you can read on- or offline. Paperboy refreshes the app automatically as you walk out the door, so you’ve got today’s news to read when you pull out your phone.

The background geofencing in iOS is triggered by cell tower changes rather than GPS, so while it’s less precise, it doesn’t consume much additional battery life. With some apps, you'll notice the slight drop in accuracy: For example, Apple’s built-in Reminders app uses geofencing for location-based reminders, and those can be hit-or-miss. You might want to set a location reminder for a specific store, but it might go off as soon as you enter the neighborhood.

But News.me doesn’t need the precise location of the user, just the signal that he or she is leaving home, so geofencing works brilliantly. “What we’ve learned is that people love the app because they can read it on the subway,” says Jake Levine, general manager of News.me. Thanks to Paperboy, they don’t even have to remember to refresh before they go underground.


 
      


 
                   


Built in a Weekend

“I’ve been trying to figure out some way to implement this idea of having different functionality based on [the user’s location] for a while,” News.me developer Rob Haining says. “I built the original Epicurious iPhone app at Condé Nast, and back then I was thinking about how you’d use the app differently at home cooking versus out shopping.”

Though Haining never got to implement geofencing in Epicurious, the idea had been kicking around for a while by the time he got to News.me: “The idea that you can mark something as your home and provide functionality around it is really interesting. And now, with geofencing, it’s easy to implement something with pretty low cost to battery life, CPU and the user.”

“This is not a feature that was on any roadmap anywhere,” Levine explains. “We were walking home one Friday night. We walked out of the building together, and Rob said, ‘Hey, what do you guys think about updating the news in the background when you leave home?’ ”

“It was nowhere near any of the features we were building,” Levine says, but they all loved the idea. So Haining went home that weekend and built it on his own time. “On Sunday night, we got a build from Rob that said, ‘First version of automatic downloading by location,’ and it worked when I left home on Monday morning.”

Implementing Geofencing


 
      


 
                   


Since geofencing is built into iOS, Haining says implementing it is “pretty straightforward.” Paperboy has two components. The first uses the native map view to drop a pin designating the “home” location. By way of contrast, OmniFocus for iPhone offers a different example of how to set up a geofence; it asks the user to choose an address from his or her contacts.

The other component is the actual geofence trigger when the user leaves that place. In News.me’s case, it detects when the user leaves the “home” area, wakes the app up in the background and downloads the latest news for online or offline reading. Haining says “it’s not too bad” to implement.

For developers, make sure you peruse your App Store review guidelines if you’re building in geofencing. “There’s language in the guidelines about proper use of geofencing, and it’s incredibly vague,” Levine says. The team wasn’t sure Apple would even approve it, but they did: “Whatever the decision process was inside Apple to let this feature through, I think this is a thumbs-up for those guys.”

For detailed instructions on how to turn on Paperboy, check out the News.me blog.

Lead image via Shutterstock.


       
]]></description>
<dc:subject>Apps</dc:subject>
<dc:identifier>https://pinboard.in/u:rahuldave/b:683e437dcf55/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:Apps"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://radar.oreilly.com/2012/02/apple-itv-television.html">
    <title>Apple's iTV and the implications of what Steve said</title>
    <dc:date>2012-02-13T15:00:00+00:00</dc:date>
    <link>http://radar.oreilly.com/2012/02/apple-itv-television.html</link>
    <dc:creator>rahuldave</dc:creator><description><![CDATA[If I accept conventional wisdom, Apple is getting into the TV-making business because:



 The living room is the last consumer segment that Apple has yet to completely remake in its image.
 Apple creates new markets where none exist, and it isn't satisfied with merely improving upon existing ones.
 Steve Jobs allegedly said that he'd cracked the code for creating an integrated TV set.
 If the iPad is really "just" a big iPod Touch, and has already sold 55 million units, then a TV that is "just" a big iPad could do gonzo business.
 The business of making TVs is broken, and Apple has to fix it.
 Cable and satellite providers are evil, and Apple has to liberate consumers.
 Tim Cook "needs" a hit.


As I stated in my last post following Apple's gaudy earnings numbers, I don't accept conventional wisdom because conventional wisdom is dead! Apple killed it.


Most fundamentally, all assumptions about Apple seem to stem from a misunderstanding of how differently Apple thinks and operates from everyone else.


For starters, Apple doesn't chase markets just because they're there. Nor do they get sucked into market share battles just so they can say they sold the most units (see: iOS vs. Android).


Further, neither the aggrandizement of the CEO's ego nor the altruistic care-taking of the consumer drive Apple's product strategy.


Rather, Apple pursues markets purely and vigorously based upon a simple logic. Do they believe that their integrated hardware + software + service approach can be applied in a leveraged fashion to create a differentiated offering that delights consumers, appeals to the masses, and can be sold at high margins at a predictable run rate?


If the answer is "yes," then game on. If the answer is "no," then leave it as a hobby (such as the current Apple TV), or avoid the market altogether.


This is the backdrop for understanding the rumors about Apple building a new-fangled television set. Rumors and whispers notwithstanding, in the words of Dr. Hannibal Lecter, the obvious question is:


"Of each particular thing, ask: What is it in itself? What is its nature?"

Top layer = iOS devices; Middle layer = Core device functions; Bottom layer = Noteworthy hardware subsystems.


In the case of a serious living room play, if you check out the above graphic, what stands out most about the Apple TV in its current incarnation is its lack of apps, web, and communications support. These elements are the three biggest game changers that propelled the iPhone, iPod Touch and iPad beyond the impressive media foundation that marked the pre-iOS iPod.


What is also lacking is the mainstream television programming (HBO, ESPN, ABC) that the typical consumer demands. A 'purdy' new TV doesn't remedy that problem, now does it?


But, remember, Apple is long removed from their anti-establishment days, whereby for the company to succeed the incumbent had to fail. Hence, the rebirth of the Mac was predicated on getting into bed with Microsoft; the rise of the iPod was predicated on getting into bed with the music industry; and the rise of the iPhone was predicated on getting into bed with mobile carriers.


When framed that way, who hasn't Apple gotten into bed with yet that they need to get in bed with to succeed in a mainstream way?


You guessed it; the cable and satellite providers. Why? Because as noted venture capitalist Bill Gurley sagely pointed out, "When it Comes to Television Content, Affiliate Fees Make the World Go 'Round."


In other words, for an Apple TV to be free-flowing with first-tier TV content in the same way that an iPod flows with first-tier music, Apple will need DIRECTV and/or Comcast to bless it.


ESPN, after all, earns $4.69 per subscriber household in affiliate fees on each and every cable subscriber. Apple's good friend, Disney, owns ESPN, ABC, Disney Channel and a slew of other channels. Disney simply isn't going to throw billions of dollars away in affiliate fees just so they can help Apple. All of the major TV content players view the world similarly.


So where does that get you when you connect the dots? I'll tell you where it doesn't get you ... to a television-like device that:



 Is priced 2-4X the cost of an iPad.
 Has sales cycles of one device every 5-10 years.
 Has bad margins.
 Has a serviceable form factor that for many people is good enough. (Apple challenges industries where the baseline experience is terrible. Television hardware wouldn't seem to qualify.)


Conversely, what if you could buy a set-top box that plugged into your modern, big-screen TV, and: 



 It just worked.
 Had every channel you currently get on cable.
 You could run those same channels as apps on your other iOS devices. 
 Your TV could be controlled by any of those same iOS devices.
 You could upgrade to the newest version of the set-top box every 2-3 years (on a carrier-subsidized basis).


Who wouldn't buy this device? And why wouldn't the cable and satellite providers be all over this? After all, does anyone seriously like their set-top box?


As a sanity check, a carrier subsidy on a sub-$500 device is meaningful, whereas a carrier subsidy on a $1,500+ device like a TV set is nothing.


Wait! But, didn't Steve Jobs say that he'd like to make an integrated TV set?


Even if he did say that, do you really think that in his final official act as Apple spokesman, Jobs would telegraph to the world his company's grand intentions in the living room?


Related:



 The magic adapter: Apple TV and the battle for the living room
 It’s Time to ‘Think Different’ because Conventional Wisdom is Dead: Thoughts on Apple’s Q1 Earnings Call
 Apple's Segmentation Strategy (and the Folly of Conventional Wisdom) 
 Apple, TV and the Smart, Connected Living Room



    
]]></description>
<dc:subject>Web_2.0 appleios apps cablecompanies disney hardware media satellitecompanies stevejobs television tv</dc:subject>
<dc:identifier>https://pinboard.in/u:rahuldave/b:fb4fbe5d5cb8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:Web_2.0"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:appleios"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:apps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:cablecompanies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:disney"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:media"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:satellitecompanies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:stevejobs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:television"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:tv"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://feedproxy.google.com/~r/readwriteweb/~3/WcyHIHUjP-0/how-facebook-mobile-was-design.php">
    <title>How Facebook Mobile Was Designed to Write Once, Run Everywhere</title>
    <dc:date>2011-09-30T00:00:00+00:00</dc:date>
    <link>http://feedproxy.google.com/~r/readwriteweb/~3/WcyHIHUjP-0/how-facebook-mobile-was-design.php</link>
    <dc:creator>rahuldave</dc:creator><description><![CDATA[Facebook has the most downloaded native application of all time. It also has perhaps the most visited mobile website of all time with nearly 350 million users and growing from feature phones to the smartest smartphones. It is available everywhere. The company started working on mobile solutions in 2006 and since then have grown with the times, using the tools available to them as they went along, from m.sites and WebKit touch interfaces to now the precipice of HTML5. Facebook's creed, or really just a way to make their developers' lives easier, is to write once and run everywhere. This has been next to impossible. 


Facebook mobile is predicated on browser technology. As Facebook's engineering manager Dave Fetterman says in the transcript below, the browser is what Facebook is good at, how it got to the point it is at now and how it is going to iterate for the future of mobile. We will touch on the future tomorrow, but be sure to read Fetterman's presentation at Facebook's f8 developer conference below because it will inform what we are going to explore tomorrow morning. Really, how did Facebook design for all those platforms and devices?

Sponsor


What is below is a direct transcript with photos from Fetterman's f8 presentation. A few things to note:


Facebook mobile has its backbone in its mobile website. Everything that is built into the native applications actually comes from the mobile Web. Think of the way PhoneGap wraps a browser-based website and that is how Facebook approached the problem. And then some.


HTML5 is the future. The fourth page gets into how all of this history is leading Facebook to a precipice of change with HTML5 and the so-called Project Spartan. 


Also note that Fetterman talks fast and occasionally swears. He is the classic Facebook engineer: kind of young, pretty brash and supremely confident. The transcript is as true to his actual words as possible.





Changing Mobile Standards Through The Past Five Years

We took an extreme HTML-based approach to this. So we will go into how we do this so you can learn how HTML5 is the way out of a lot of these problems.


Because, it wasn't really always this way for us. We have had the same mobile problems that you guys have. We are following the same mobile ecosystem that you guys are following to develop for your users. 


So, we have the same problems of cross-platform development that you have and we are hoping that you can learn a little bit from us. So, we have been learning to deal with these issues with what we call "FaceWeb" and learning a new opportunity to get out of this that is emerging as we speak called HTML5. 





So, in 2006, building a mobile presence meant that you had a WAP deck that was based on an HTML application with SMS and all of that. But, as you all know, mobile changed fundamentally in 2007. What happened then?


[Crowd] - The iPhone.


The iPhone! Great. What else happened in 2007, perhaps unveiling in the room that you are sitting in right now?


[Crowd] - The Platform.


Yes, the Facebook Platform API. So, what changed for us is that we had to develop a second user experience for the iPhone. A computer in your pocket that no longer sucked. So, it could have Javascript, a CSS and a really rich interaction model. In addition there was Facebook for BlackBerry, Facebook for Windows phone, for Nokia, for Samsung, for everyone now available through the Facebook API. 


How about 2008? What was the big thing that happened in 2008?


[Crowd] - Ummm ... Android?


I will pretend that I heard the iPhone App Store. What most developers don't realize is that the first version of the iPhone, you could build websites but the App Store was not available to later. So, in 2008, the App Store enables us to build Facebook for iPhone. The flagship, the vanguard, the best substantiation of Facebook. Based off the API, the same way that you guys are building apps off the API now. 


In 2009, what changed in 2009?


[Crowd] Ummm ... Android?





Android, yes. I will pretend that I heard Android. Android was the new player in 2009 and really started taking off. So, all of a sudden we have all of these users on all these devices using Facebook mobile in the wide rainbow of lovely different experiences across Android, iPhone, Windows, the Web. That was great from a user perspective. What sucks? The environment for my developers, essentially. You have the bad old days. You have four different platforms to build for something essentially. You want to build for all of those groups? You are going to have to build the sucker four times. Then there are all of the features - groups, deals, the new profile. All of this stuff and the matrix got really bad.  So, we have to build things four times which means that the code gets slow. The code gets old. There are different versions of parity and things just don't work together which makes it extremely difficult for a fast moving company like Facebook.


Next page: Fetterman describes how Facebook reconciled M.Sites and Touch





How To Not Write The Same Functionality Four Times

So, how do we solve this problem? If we have any shot at solving this problem of building things four times ... if you want to build it once, the Web is probably your best shot. So, back in the day we said that we have two websites, right? We have touch.facebook.com and we have m.facebook.com. Different complete docket roots and who decided what is was going to be, where you are going to go based on your phone? Well, it wasn't that complicated. If you were a Webkit phone, you basically redirected towards touch, if you didn't, you got M. If you had CSS, hey, we could throw that in there, no charge, no problem. So, have had this guess and redirect sort of approach to the Web. 


That doesn't really solve the problem of everyone having and optimized experience for their phone. Even things like inline images inside the screen, across CSS and versions, that is really problematic when you that those to my right are saved, those to my left are damned. That is the way it is going to work. So, if we had any chance of unifying these two groups and building something once for the mobile Web, we had to solve this problem.





So, what do we need to do? WebKit wasn't enough, we had to have a better level of granularity. What is the difference between a Javascript enabled mobile website from a non-Javascript enabled mobile website? Really, Javascript is there to enable certain types of display and certain type of interaction, primarily AJAX. But, when you think about the controller --- what is Groups? What is the news feed? What is Message? Those are kind of the same thing and they really don't have to be written twice. So back in the day you had to use inefficient solutions like NetBiscuits which were opaque. You could do some XSL post-processing but you can't post-process your way to good Javascript, it doesn't work. With Webkit you started to get poly-fills and modernizer and all this great stuff. But, you actually needed a way to write your code once.


Progressive Enhancement

Here is what we did. 


The cornerstone of this is detecting what your phone is going to be able to do. Capabilities, then you can start the right experience. You guys heard of WURFL at all? Wireless Universal Resource File? This is one of the projects out there that attempts to map a user to a user-agent set of capabilities. You know, what is your screen size? What is your JS? Can it do cookies? These are all pernicious, nasty problems that need to be solved. And the use-agent, as you guys can tell, doesn't do the job. So, you need an open database for manufacturers and concerned citizens to be able to tell you what is up. We sponsored this project and this project is continuing to evolve as an open source data site. 


So, once you have these capabilities you actually have to figure out what to do with these. A button on Facebook isn't just like it is HTML or this block of Javascript or something. What you want for the homepage is to have your composers render a button that does something. So, you guys say what we really want is a button. You guys figure internally what should be rendering. If it is a low-end phone maybe it is just straight up post form. It if it is a mid-range phone with CSS, maybe you could layer CSS on there. But if it is a high-end phone you really want an AJAX style experience. So, this technique was pioneered by somebody like Yahoo blueprint. So, instead of saying at the top level that this is going to be a good site and this is going to be a low-end site, each component inside that declarative markup that renders the display will decide what it is able to do. And they compose together to form the ideal experience for that phone. This technique is called progressive enhancement. 





So, this actually got us to the point where we were able to write once and run anywhere across the Web. And, you know, the Web seems doable. You can do that on your desktop browsers already. Mobile is getting to the point where you actually can do this using a system like this. But, you guys are probably bored about hearing about the Web, despite the fact that an iPhone user and Android user, whoever, can go use a mobile website competently because they all have good browsers, everyone wants an iPhone feature. 


So, we were able to eliminate on of our four stacks and get to the point where we had three and that is great. But, of course, everyone wants and iPhone feature. They want their stuff to look like and iPhone, to perform like an iPhone, to feel like an iPhone, all of that. So, we could write it in Objective-C, which we had to do, or we could think about this. Right, so, what about the Facebook news feed is really iPhone-y? You have the top, you have the fixed header, you have it to render directly from cache, all that great stuff. But really, if you look at the content of the publication, that looks a whole lot like a m.site news feed. There is not really that much that is different, there is nothing that special about any particular stack. So, that means that you have to write it three times to do exactly the same shit.


Crazier Than You Guys Can Imagine




So, what if we put the actual browser inside the app? That is the crazy idea. The way we did this was even crazier than you guys might imagine. So, there are a few phones, what browser is going to be able to work for all these phones? Well, three of them have pretty good WebKit implementations. So, we thought, what if we put a Webkit enabled site inside the app and just straight up make that thing work? Just, forget it, we will figure out how to make that thing work. 


So, this is actually pretty crazy. This isn't just building Javascript that runs on the client and uses the back end as a data portal. We are actually straight up injecting the site inside these apps. Not quite as simple as getting a UI Web view or whatever. You have to have some interactivity between that Web view and the container but what if we could just straight up use the site? It is almost the same thing, right? So, this is what we did and it is kind of insane. 





So, I want to tell you what we learned from this. Of course, unifying the site into the content containers is difficult and something that we would have to overcome but, betting on the browser is just kind of something that we do at Facebook. It is what we are good at and it is our ultimate opportunity to move fast and we are betting hard on the Web because that is what got us here (f8) today. So, we basically want to put the browser inside the Facebook for iPhone app.


Next page: How Facebook moves fast with browser tech and iterates daily





Iterate Daily

So, what doe this get us? It means that you can ship daily. You do not have to wait for an app store approval, which sucks, and you don't have to wait for every user to download this version on the binary which has to be shipped over into their phone. That sucks. You can ship every day. You can break it every day, but you can ship every day. 





You can ship it in easy language too. Your Web development team, you iPhone team and your Android team don't have to be separate. They are all the same people, they are all solving the same problem. And you can ship once instead of having to ship four times. 


So, how does this work? Project FaceWeb is an extension of this progressive enhancement idea. So, instead of the phone saying I am rendering for a WebKit browser, we send an agent that says you are going to be rendering for a WebKit UI WebKit view inside the iPhone app. So, what you have to do is detect that, style a Web code to make that work, build a bridge between the things that you want to write to interact natively with the Objective-C, say in Javascript, then build HTML pages for Facebok in the iPhone. So, you build much smaller native goop instead of having to build over and over again. 


The Answer: Wrap Facebook Mobile Inside the Native App




So, how does this technically work? Essentially the user hits the news feed icon on their iPhone. If this thing is enabled for this FaceWeb technology, it won't map to a native Web controller, it will instead map to some end point on our server that literally says serves up m.facebook.com/home.php. It can't just jam that thing in there. It can't just have the Web view. You actually have to know how it is going to be interacting with the Objective-C. So, you have to send back a JS skeleton which specifies the "platform extraction calls layer" required for that frame. Then you make another trip and load the home.php and the Javascript. 


It is a bit of extra work and that does affect some things. But, what that means is that we can write a basic m.facebook.com site and use Javascript to make it work on great phones and use this abstraction layer to interpret Javascript when applicable to do native things like say open the camera for something like the iPhone application.




So, what kinds of things have to go across this bridge? Obvious things like sensors and data. If you want to get your GPS, your accelerometer or orientation lock or some of these things, some are available in HTML5 but a lot of them aren't. So, you have to be able to make some of these sensor-esque answer queries. Depending on the display and how aggressive you want to be, you have to be able to render things look like iPhone. Look like Android. And, you can't do those things just with the browser. You could in theory do this with JS but to look exactly the same you are going to have to use a native call. And additionally, there are elements to Facebook for iPhone that we don't really want to move to HTML. For instance, the camera flow. You open up the camera, you take a picture, you put it in your album or you select something from your gallery and caption it and upload it. That is a lot to do in a browser but it is easy to do in native. So, if you want to deep dive into any existing native flows, that is a bridge we are going to have to cross as well.


Next page: The sticky points and problems with designing once and running everywhere





Sticky Points: Web v. Native Design and Design



PhoneGap has already solved this first problem actually pretty well across even more than just the iPhone. The common problems that you will run into if you do this is; one -- objection, it doesn't look native. Second one is that it is not going to feel native and third is that it isn't fast enough. Here is what we found for each of these things.


The initial mandate was, hey, you guys want to do this thing in HTML, fine, I don't want to be able to tell the difference between Objective-C rendered news feed and HTML rendered news feed. This actually didn't end up being a big problem in terms of visuals. The Web and the app actually work pretty well together. When we shipped this to users there wasn't any complaint except for one that I thought was pretty funny. 


There was an iPad "app" for Facebook that was friendly for Facebook, It just simply wrapped the m.site. Some users said, hey, Facebook is copying the app that wraps its m.site as part of its Facebook for iPhone application. Which we were because we were actually just using our m.site and that was great. So, the fact that it doesn't look native, we don't actually have a big problem with that one. 





Still, there are some things that you have to look out for. Position fix and overflow scroll were obviously a big problem. Android 2.1 and below, no chance. (Android) 2.2, it is starting to work and iOS 5, thank god, has promised to implement all this stuff. So, you guys are in a better position now to start down this road than you would have been 10 months ago. CSS regradients are a problem, images are a problem and [there are a couple of more gotchas].


Web v. Native Feel: Scrolling

Another problem is that it doesn't feel native and almost always this means scrolling. It doesn't really mean, hey, I want to swipe to delete. That is like, pfft, who cares? Almost always it is going to be something about interactivity and scrolling. Something that the native code does really well by using the GPU and like pipelining all that shit but it is something that it really hard to do in HTML. So, when people say that it doesn't feel native, they are going to be talking about scrolling. 


Sometimes you do have implement scrolling. iScroll works pretty well, Hewitts is working on a library that is pretty good. So, you kind of have to defer to a good JS scrolling library. And, make sure you do things like resize your images because was once the responsibility of the GPU is now the responsibility of the browser. And, there are all these little things that just aren't documented, like the keyboard showing up and not closing on Android and iPhone. There are just a lot of little things that are baked into the system that are getting fixed. 


The Issue Of Speed




The final one and this is the real bad one is that it just isn't fast enough. If you see a slowdown in your Facebook for iPhone application, it means that we are working through just how to make an HTML-based application work for Facebook for iPhone and it has been pretty hard.


So, tactic one is obviously pre-cache the hell out of this thing. If you render a news feed, start and going to get the content for all of those stories because when the user hits that, you want to have the content ready for them. Cache your Web views. If that doesn't work, the best thing that you can do is to just trick your users. At least have content appear to be ready. Fill out the rendered skeleton and then put in that cached content and then beneath, go get your new content. At least users will feel that there is something there because that is usually what their initial response is. A white screen is just not going to cut it. 


So, gotchas in PERF means that you are going to use a lot of JS. You are no longer just loading data, you are loading pre-rendered markup, which is a lot more expensive. And things like HTTP cache and the app cache, they say they work within UI Web views but often they don't. So, you have to be really careful about promises that are made here. 





Taking The Approach Everywhere

But, this worked well enough that we said we are going to put the Android app on this party train too. So, we were actually able to write something like the m.site news feed once. Any time you change a news feed story or add a news feed story or add commenting and Liking or whatever, that is going to show up on low-end m.site, high-end m.site, Facebook for iPhone and Facebook for Android the very next day, or whenever we push, which is actually pretty awesome. 





So, we did do this. Now we have elements of the Facebook experience, the browser running inside everything. Especially the most volatile stuff, the stuff that relies least on a certain type of display, the stuff that is going to be evolving and changing so much, like the news feed or your profile timeline, we are doing this straight in HTML. That is where the maximum benefit is. 


Next Page: How HTML5 Is Leading Facebook In A New Direction


How It Has Evolved: Heading to HTML5

So, what is the history of this? So, for iOS 3.4 and 3.5 we actually did this. Your news feed and your profile feed are actually being sourced from the m.site. So, that means if the m.site changes and adds a feature, you guys get it. If the m.site is broken, it breaks everything. There are positives and negatives there. To be launched in iOS 4.0, requests, notifications and search, this list-style content that doesn't require very specific native access, that is going to be based on FaceWeb as well. Android 1.6 and 1.7 follow the same suit. The feedback and the design have been pretty great but the bugs have been pretty crappy though. Because when you version your Javascript and things go wrong, you are tying your future to the actual Web working perfectly all the time which is something that we obviously move fast on very often. 





So, the mission is to operate from one code base and adapt to all the browsers in the world. This sounds like something that Facebook would say, this is actually part of the HTML5 battle flag. 


HTML5 is probably the way that we should have done it. This is the way we get to do it now because HTML5 has changed so much under our feet. The initial attempt at building a hybrid application, there were certain things in HTML5 that weren't ready yet and we said forget it, we are going to keep moving forward. The initial attempt to defer certain things to native rendering and native handling that really could be better handled by something like HTML5 and with in-browser technology - device access, good native frameworks and application and display code. 


What has changed between then and now that we can take advantage of and that you guys can, who are going to be starting down this hybrid path, might be able to take advantage of in the near term? 


Device Access

So, device access. Simple things like getting things that are privileged inside the device. Geo-location, network connectivity, obviously very big for caching, things like your camera and your contacts, what has changed? Well, geo-location has actually been pretty good for a while. This could certainly be HTML5 and that is what we use inside out m.facebook.com based Places and Deals stuff. Network connectivity is emerging and that is getting to the point where you can rely on newer browsers to do it via HTML5. Camera and contacts, because those are so wildly different, a lot of those things are still specified. But, if you want to look at a general list and start by asking the system for a response and getting an answer back, PhoneGap.com actually has a lot of this stuff and they have been able to this poly-fill to make a lot of this work. So, this is the easiest problem but it is the furthest along towards getting solved, especially since we have started working on this hybrid application. 


History

There are certain development frameworks that are native. Being able to manage your history, it's weird. Because your history inside a native stack is very different from a browser history. Browsers are very idiosyncratic about how they handle history and it is a very different model. History management, client-side storage is obviously the big one and threading. With threading, if you guys have developed in iOS, you know there are certain things that you have to respect. That is true in Javascript as well. So, you need a good way to figure out how to get other threads to do your work and get it in a cross-platform way.





HTML5 is emerging standards to make all of this go away as well. History management, there is some good stuff in HTML5 coming. IndexDB and client-side storage is getting much better as well. Things like WebWorkers, if we did these things again, we would be able to do it in HTML5. 


Can An App Be Built Now Using Only Web Technology?

Finally, I think the important thing is, could you build your app building straight up Web technologies? The actual Web technologies they are using, you are using. Scrolling, refresh, fast stuff, these are things that we had to defer to a native handler in an awkward way. But, scrolling, thank you to Apple and iOS 5 for promising that they are going to make scrolling, position fixed overflow scroll, this might be the problem of the past. Fixed position headers and good scrolling is a hallmark of what people have come to think of as a native application but it is a problem that can be solved by good JS now thanks to these new frameworks.


I think the most important takeaway is that the JS rendering engines have just gotten so much better in the past year and a half. V8 and Nitro have shown that you can build full-fledged, client-side JS applications instead of using Objective-C or Android Java and they will run and users will love them. Things like Netflix have done this very productively already. 


So, the emergence and the investment of big browser manufacturers that are making really, really good JS stuff, which is finally paying off. And if you guys are just starting down this path, you will be surprised at just how much success I think that you could really have. 


Move Things, Break Things, Fix Things Fast

So, we have been following what was available to us along the road for us since 2006 in Facebook mobile. If the best that we can do is XHTML, fine. If we have a really good browser that uses JS and CSS fine. If we can build and iPhone app and an Android app, that is great. But, what is changing beneath us now is actually the emergence of this HTML5 standards and browsers that implement these standards. Especially around device access and the ability to write apps entirely in Javascript. We have seen a lot of benefit to writing something in HTML. All of our developers are good at HTML. Only a few of them are really good at Objective-C and Android. We are able to make our Web developers the same as our client-side developers in some respects. 


Being able to write it once today and ship it tomorrow? That is something that Facebook is really good at and that we love doing and that is at the center of being able to move fast. Move fast has an implicit third clause - move fast, break things, and fix things fast. That is very difficult to do if you have already shipped your binary to Apple or Android and they have to download another version of it. 


Discuss

       
]]></description>
<dc:subject>Apps</dc:subject>
<dc:identifier>https://pinboard.in/u:rahuldave/b:05c96b652067/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:Apps"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://feeds.gawker.com/~r/lifehacker/excerpts/~3/_vufr9iCL4U/let-your-smartphone-write-bibliographies-for-you">
    <title>Let Your Smartphone Write Bibliographies for You [Apps]</title>
    <dc:date>2011-02-23T14:00:00+00:00</dc:date>
    <link>http://feeds.gawker.com/~r/lifehacker/excerpts/~3/_vufr9iCL4U/let-your-smartphone-write-bibliographies-for-you</link>
    <dc:creator>rahuldave</dc:creator><description><![CDATA[

If you're in college (or went to college), you know that the worst part of writing a paper is trying to crank out a bibliography/works cited page at the very end when you're brain dead and running late for class. A group of ambitious young students at the University of Waterloo want to bring an end to that with Quick Cite, which lets you use the camera on an iOS or Android smartphone to scan a barcode and have the app email you a properly-formatted entry (in MLA, APA, Chicago, or IEEE formats). [iTunes via Fast Company]More »

   
]]></description>
<dc:subject>apps Androidapps Bibliographies College IphoneApps Quick_Cite Works_cited</dc:subject>
<dc:identifier>https://pinboard.in/u:rahuldave/b:fa030308032d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:apps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:Androidapps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:Bibliographies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:College"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:IphoneApps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:Quick_Cite"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:Works_cited"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.zeldman.com/2010/12/16/flipboard-update-preview/">
    <title>Flipboard Update Preview</title>
    <dc:date>2010-12-16T16:25:03+00:00</dc:date>
    <link>http://www.zeldman.com/2010/12/16/flipboard-update-preview/</link>
    <dc:creator>rahuldave</dc:creator><description><![CDATA[

FLIPBOARD, AS YOU DOUBTLESS know, is a social media magazine for iPad. Part RSS reader, part iPad publication uniquely curated by each reader, the app brings serendipity, discovery, and typographic excellence to the experience of keeping up with one’s friends on Twitter, Facebook, and so on. This morning (last night in Japan), a new, improved version of Flipboard was launched, offering designers like us even more visual pleasure and rewarding the hours we put into our content’s semantic underpinnings.

Designer Craig Mod, in a letter, told me his “goal was to try and produce one of the best RSS experiences out there.” It’s accomplished via features like those listed below and more, as seen in these screenshots Craig sent me from his pre-launch tests:


auto-small caps
portrait and landscape optimized typography
full bleed images
flowing of text based on image size and location in the document
auto-generation of [figure] and [figcaption] objects based on alt
text on images

Adds Craig, “What’s great is that the more semantic and clean your feed, the better it will look in the app.”

Download Flipboard or update your copy in the iTunes Store and see.







]]></description>
<dc:subject>&quot;Digital_Curation&quot; Apple Applications apps architecture art_direction ipad</dc:subject>
<dc:identifier>https://pinboard.in/u:rahuldave/b:38ef23f7cfb5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:&quot;Digital_Curation&quot;"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:Apple"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:Applications"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:apps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:art_direction"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:ipad"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.zeldman.com/2010/04/14/designing-for-ipad/">
    <title>Design Lessons from iPad</title>
    <dc:date>2010-04-14T11:04:04+00:00</dc:date>
    <link>http://www.zeldman.com/2010/04/14/designing-for-ipad/</link>
    <dc:creator>rahuldave</dc:creator><description><![CDATA[






It’s only Wednesday but we already have our link of the week. Although they call it merely a “quick write-up” (and it is a fast read), iA’s mini-compendium of design insights before and after the appearance of the iPad at their office should be required reading for all web, app, and/or interaction designers.

In the equivalent of a breathlessly quick seminar presentation, iA discusses typographic resolution and feel; the effect of the device’s brilliant contrast on readability; the kitsch produced by rigorously adhering to Apple’s “make it 3D” guidelines; whether metaphors work; and more—all of it well worth far more than the little time it will take you to absorb.

In particular, I call your attention to the section entitled, “Interaction Design: So What Works?” Although intended as a guideline to producing well-tuned iPad apps, it also works splendidly as a mini-guide to creating better websites, much like Luke Wroblewski’s brilliant “Mobile First” presentation at last week’s An Event Apart, which carried a similar message:



The limited screen estate and the limited credit on the number of physical actions needed to complete one task (don’t make me swipe and touch too often), pushes the designer to create a dead simple information architecture and an elaborate an interaction design pattern with a minimal number of actions. This goes hand in hand with the economic rule of user interaction design: Minimize input, maximize output.
Since the smallest touch point for each operation is a circle of the size of a male index finger tip, we cannot cram thousands of features (or ads!) in the tight frame; we have to focus on the essential elements. Don’t waste screen estate and user attention on processing secondary functions.
We found that the iPad applications we designed, made it relatively easy to be translated back into websites. The iPad could prove to be a wonderful blue print to design web sites and applications. If it works on the iPad, with a few tweaks, it will work on a laptop.


Via iA  » Designing for iPad: Reality Check.
















]]></description>
<dc:subject>Apple Applications Design Information_architecture Platforms UX Usability User_Experience Web_Design apps architecture industry ipad estate reality interaction check resolution actions splendidly</dc:subject>
<dc:identifier>https://pinboard.in/u:rahuldave/b:f463506c9387/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:Apple"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:Applications"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:Design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:Information_architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:Platforms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:UX"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:Usability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:User_Experience"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:Web_Design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:apps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:industry"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:ipad"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:estate"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:reality"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:interaction"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:check"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:resolution"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:actions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rahuldave/t:splendidly"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>