Technology is cyclical. Good ideas are often “borrowed” and make their way to products from multiple vendors. http://engadget.com/photos/hp-envy-15-vs-the-macbook-pro
The one thing all these phones have in common (besides Angry Birds) is they all have decent web browsers. http://paulirish.com/2010/high-res-browser-icons
The term “Responsive Web Design” was coined by Ethan Marcotte, in an an article published by A List Apart. Loosely defined, it means adapting to various screen sizes, using a fluid grid and @media queries in CSS.
Disney.com — Entire site is responsive There is one Flash ad, which disappears if the browser is at “mobile” width. Note: Most mobile devices have little/no support for Flash, Silverlight, etc.
When should you use RWD™? Responsive web design using @media queries (with one codebase for all devices) typically works best for web “sites” (not apps). Apps work best when tailored to one particular interaction paradigm. For instance, mobile Gmail is a different experience than on the desktop. As a general rule of thumb, if your content can be read via RSS (such as Google Reader) and still make sense, it might be worth considering a responsive approach.
Mobile web trivia time… — PhoneGap on Windows Phone uses the IE10 engine (it is pretty good) — WebKit is the dominant rendering engine across most mobile devices — iOS, Android, Blackberry, webOS — Blackberry has one of the best WebKit-based browsers available
Benefits of native development — Default OS look & feel (UI conventions) — Performance (“closer to the metal”) — Access to device hardware (GPS, etc) — App store/marketplace distribution — Benefit from latest OS enhancements
Drawbacks of native development — Tied to the particular OS you built for — Maintaining a multi OS team/skill-set — Dealing with app store approval process — Keeping app in sync with OS updates
LinkedIn’s iPad app is 95% HTML5 We did users studies in-house, and I don’t think people noticed a big difference. Nobody said, “Oh that’s native,” or “Oh, that’s web.” As long as we can make the experience fast enough, nobody can tell the difference. It still feels right. — Kiran Prasad http://venturebeat.com/2012/05/02/linkedin-ipad-app-engineering
Benefits of hybrid development — Common codebase for multiple OS’s — Access to device hardware (GPS, etc) — App store/marketplace distribution — Skills you already have (HTML, CSS, JS) — Potential code reuse in web site/app
Drawbacks of hybrid development — Build for lowest common denominator — 3rd party SDK’s might lag behind OS — Want to use feature X? Wait for an implementation in abstraction layer. — An abstraction layer can have bugs of its own. Have to determine if a bug is in your code, the abstraction layer, or OS.
Note: Essentially, Facebook was just “doing it wrong” when it came to HTML5 — Sending down HTML, CSS, JS to the app, rather than building the app with that embedded, and consuming lightweight JSON sent from the server. “A craftsman doesn’t blame his tools”
Areas where Titanium shines — Native UI — Great for iOS, crapshoot on Android — Build for iOS, Android, and Blackberry — Some code reuse across platforms — Entirely JavaScript based — Uses CommonJS’s AMD approach — Except for WebView (HTML/CSS too)
Abstraction layers tend to be harder to debug than “native” languages — Objective-C, C#, or Java — whilst using an IDE such as Visual Studio, Xcode, or Eclipse. With “the web,” you have familiar browser-based desktop tools in Chrome, Firebug, or Opera Dragonfly.
— It embeds a WebView in a native app — Native app gives access to OS API’s — All the UI is built via HTML/CSS — JavaScript handles everything else — The app wrapper compiles via… Xcode, Eclipse, Visual Studio, or “the cloud” → build.phonegap.com How PhoneGap works
Areas where PhoneGap shines — It is “the web you already know” — Debugging via desktop browser — Access to device API’s (GPS, etc) — Strives to implement W3C specs — Camera API, etc. — Supports Windows Phone, too
@font-face { font-family: 'Open Sans'; // For all good browsers, including IE9. src: url('../fonts/OpenSans-Regular-webfont.woff') format('woff'), // For older IE, and Android default browser. url('../fonts/OpenSans-Regular-webfont.ttf') format('truetype'); } @font-face { font-family: 'Open Sans'; font-weight: bold; // For all good browsers, including IE9. src: url('../fonts/OpenSans-Bold-webfont.woff') format('woff'), // For older IE, and Android default browser. url('../fonts/OpenSans-Bold-webfont.ttf') format('truetype'); } All modern browsers support *.woff or *.ttf
markup = $('#_template-list-item') .html() .replace(/\s\s+/g, ''); template = Handlebars.compile(markup); Where the magic of Handlebars happens Yes, this looks underwhelming. That’s the point. It’s code you don’t have to write yourself! :) http://host.sonspring.com/handlebbbars/assets/js/application.js
Underscore.js is a power tool for working with collections of objects and arrays… — Collections — sortBy — pluck — uniq — extend — flatten — each — filter — find — Utility functions — throttle — chain — times
nathansmith
hjmkth
joelgoodman
ikuhotamura
bermonpainter
kaminashi
uxaustralia
thebloggart
uxevents
sakito
kawaiirailroads
akwkm
48yukyia
thekraken
lara
ddemaree
tanoku
danielanewman
orderedlist
samlambert
chriscoyier
sonatard
geeforr
keathley