Faruk At.eş

Archive for 2011

  1. January 12
  2. February 35
  3. March 16
  4. April 29
  5. May 10
  6. June 4
  7. July 9
  8. August 6
  9. September 3
  10. October 4
  11. November 9
  12. December 11

Showing 16 posts from

A Very Big Bang

Wilson da Silva:

A searing blastwave of wildfire raced through the air for thousands of kilometres, burning any living thing in its path. The shockwave shook the planet like a bell, triggering tsunamis, landslides and volcanic eruptions around the world.

The sky fell dark, temperatures dropped. In the dark and desperate years that followed, around 80% of all the species on Earth became extinct. Among them, the dinosaurs, magnificent creatures that had ruled the planet for 160 million years.

This would make a killer CG video.

Chrome’s Future Plans on Animation & Javascript

The new requestAnimationFrame proposal is going to be a big thing for animation on the web going forward. Read up on it now if you’re a web developer. And if you are, also heed the unwritten warning at the end of the post:

In the forthcoming Chrome 11 release, we plan to reduce CPU consumption even for pages that are using setTimeout and setInterval. For background tabs, we intend to run each independent timer no more than once per second.

In other words: check to make sure your timers won’t break any site functionality if they get executed at a browser-enforced one-per-second interval.

Web Standards Sherpa

In case you missed the somewhat quiet launch, Web Standards Sherpa is a new effort from the Web Standards Project’s Outreach team, featuring articles on best practices in web design & development and site reviews by some of the best our industry has to offer. Or as Aaron Gustafson put it:

We see Web Standards Sherpa as a way to let you glean advice from some of the smartest folks in the industry and provide you with the opportunity to learn from real world examples of what people are doing right and where there is room for improvement.

Google delays Honeycomb tablet OS

Jim Dalrymple:

Can you imagine if it were Apple delaying a software release. What would the press say if Apple admitted it took shortcuts with its OS to keep up with Google and now they couldn’t release it? The press would have a field day with that story.

See also: Adobe and Flash on mobile.

100 Little Robots

My friend Anton draws some of the most inspiring art I know. This is a great opportunity for you to own some of it, at a mere $25 for a unique 4x6" card.

The Great In-Between

Few people have been privy to what has truly been going on in my life the past year and a half. Before June 2009 I was perhaps even more quiet about things, but it was widely known I was working at Apple as a Front-end dev/UI Engineer—first at the Online Store, then MobileMe—and as is par for the course with Apple employees, not much about their work & lives is discussed in public.

But when I left Apple in mid-2009, I had no clear direction for myself. I had three promising directions I wanted to pursue, but none of them were one-man ventures. I set out to find co-founders and took the opportunity of my new-found free time to do an open-ended road trip across the entire United States. It lasted for 7 weeks, 11,500 miles and included the complete Route 66 experience. It was amazing, and at the end of the road trip I was positively bursting with enthusiasm and ideas for products to build. I’d also found two interested parties to co-found a company with me.

And I was also very much without a U.S. work visa.

The majority of you reading this have probably never looked into starting a company in the U.S. as a non-citizen (and non-Greencard holder), and may well not be aware that such an undertaking is dramatically different than it is as a citizen. The latter pays a simple registration fee of somewhere between $20 and $100, on average, and that’s it. In my case as a foreign individual, it involved raising $500,000 in funding and have the added requirement that I’d need to employ ten Americans in my company by the end of the first two years. It put a bit of a damper on things, as I was (and still am) not sure I wanted to go the VC-funding route with my company and product ideas.

Adding to all of that was an ongoing personal and medical condition (fortunately now completely resolved) that made my life progressively more difficult and complicated and, paired with very frequent travel across both the U.S. and Europe, extremely tiring.

A lot of time went by wherein I continued to do freelancing on the side whilst trying to figure out what I wanted to do next, which product I wanted to build next. All this time, however, I was without a U.S. work visa so I lived back in The Netherlands and only visited the U.S. for conferences. It taught me one thing very clearly: I love the Pacific West coast. And so my new, higher priority became getting back to San Francisco.

This weekend, after many, many months of preparing a new visa application and collaborating with my sponsoring (new) employers, I have finally returned. With a shiny new O-1 visa in hand, I started my new position this past Monday at Apture, Inc. What I will be doing exactly I can’t say, but I can say that it involves design, front-end development, and bringing a decade of experience and expertise to this company.

There is a lot more that I will be sharing with you over the coming weeks, including more about what Apture is and does, but right now it’s time for me to go celebrate my return. It was 21 months to the date between my departure and my return—a long wait to be sure—but however long it was, it was worth the wait.

It’s good to be back.

First Compelling Argument For Android Over iOS

JR Raphael for Computerworld:

Traditionally, Apple has been viewed as the top dog when it comes to pure app dollars; love it or hate it, the company's App Store generates plenty of dough and thus plenty of income for third-party programmers. Even so, Android is increasingly becoming a prominent part of the equation for many well-known developers — and for some, it's actually starting to surpass Apple by a significant margin.

It's Apple's “Post-PC” World — We're All Just Living In It

A great editorial by Joshua Topolsky on Apple’s greater consumer electronics strategy, as revealed through its iPad 2 event the other day. About this bit, though:

But right now -- in the tablet space at least -- the problem for Motorola, Samsung, HP, RIM, and anyone else who is challenging Apple becomes infinitely more difficult. Almost any company could put together a more powerful or spec-heavy tablet, but all the horsepower in the world can't help you if you don't find a way to delight the average consumer.

I think Topolsky understates the scope of what makes Apple’s products and strategy so successful. It’s not merely a matter of delighting the average consumer; Apple’s retail stores are a huge part of bringing these new technologies and devices to the average consumer, allowing them to try them out, learn more about them from a friendly, helpful employee, and get help with the product should they ever need to (and people often do). That is something no other competitor is able to offer, because they don’t have their own retail chain. And those who tried (or are still trying) are failing with them for any number of reasons.

For all of the complaining some people do about the iOS’s lack of “true multi-tasking,” it’s perhaps ironic that Apple has been the only company this past decade that successfully multi-tasked a complete consumer electronics strategy.

Two More Notes on Native vs. Web Applications

Regarding this week’s post about Native vs. Web Applications, there are two additional notes I’d like to share.

First, the topic of graphics rendering performance and the people who point to WebGL. This is not a good answer, because neither Canvas nor WebGL offer us many of the things that make websites so flexible and powerful (in essence, having a DOM we can style via CSS and interact with via JavaScript). Whilst it’s great that these powerful concepts are no longer relegated to plugin (read: Flash) territory, they still effectively run inside their own closed-off sandbox. That’s why I’m much more excited about hardware acceleration for all page content, coming up in IE9, Firefox 4 and Opera (some future version). Already we have hardware acceleration in Safari, but only for CSS Transforms (2D and 3D) and opacity, which provides somewhat limited utility.

Of course, my argument will still stand: even when all browsers offer hardware accelerated graphics, it’s only their latest versions that do so, not any of the ones in use today. Mobile native apps enjoy hardware accelerated graphics almost everywhere, today, right now.

The second note is Phonegap. For those unfamiliar with it, here’s the tagline explanation of Phonegap:

PhoneGap is an HTML5 app platform that allows you to author native applications with web technologies and get access to APIs and app stores.

I haven’t played with it yet myself, but am planning on doing so next I get a chance. It’s been in very active development for some time now, and allows you to at least use your expertise with web technologies to build apps for native platforms, also taking advantage of some of the main native APIs. Definitely worth checking out if you haven’t already.

Native vs. Web Apps

Debates over Android-vs-iPhone are so regular in the tech industry these days that I found it refreshing to have a discussion on Twitter with Remy Sharp and John Allsopp about native versus web apps (again). The argument by Remy and John was that most apps can be made using web technologies and would benefit from platform agnosticism and far greater reach than those sold on an AppStore (on only one platform per development effort). My argument is that this is simply not yet the case. I’m going to explain why, but first, a little dispelling on definitions.

In a Web Directions blog post from last October, John seems very much dismayed at the notion that native apps are “inherently better” than web apps, simply because they’re native. I think John is looking at it all wrong, and is letting himself get frustrated by claims in this realm for the wrong reasons.

I posit that the quality of an application is determined by three factors, in order of significance:

  1. The quality of the work done by the developer;
  2. The quality of the environment in which the application is used;
  3. The quality of the tools at their disposal

It’s illogical to suggest that #2 and #3 are irrelevant, but I’ll address all of them, in reverse order.

The quality of the tools

Better tools are no guarantee for better results, but worse tools objectively limit you in what you can feasibly accomplish with them. Don’t forget that in the case of application development, one aspect remains constant: the time and money investment you can make to build it. This means that worse tools, which require more effort, thus more time, thus more money, will negatively affect the overall quality of the end result compared to something made with better tools.

This is an objective truth that has nothing to do with however talented the development team is. But more on that later.

The quality of the environment

This factor matters quite a lot. For native apps, the environment equation is something like this:

Hardware + Operating System + OS version + API level

For web apps, it’s slightly compounded but otherwise very similar:

Hardware + Operating System + OS version + Browser + Browser version + Web API level

I initially omitted OS and OS version from the web app equation, but that would have been a mistake because, especially on mobile, some browsers rely on a web framework that is installed on the OS level, and only gets updated when the OS gets updated.

The first lesson here is obvious: web apps have a more extensive equation, meaning there are more possible permutations to deal with—especially since good web developers eschew dropping support altogether for users of older browsers and favor using practices such as Progressive Enhancement. This in contrast to native platforms (especially on mobile), where it’s quite common to simply require the end user be on at least OS version n or later, and anyone who isn’t simply won’t get the app. For web apps, that means the development effort is already spread thinner across a larger number of environments to support, and since we have a constant of X time and Y money to spend on this, this factor is detrimental to the quality of web apps.

But if you think these equations are statistically equal, you’d be wrong. Web APIs are inferior to native OS APIs because there are far fewer of them so far, and many of the ones that bring web APIs up to the level of native APIs are so brand new that they are 1) comparatively poorly implemented, poorly supported and poorly documented, and 2) only available in the latest, often unstable development versions of browsers. If you look very simply at market shares, an apples-to-apples comparison between web browsers and Android OS version (chosen because Apple doesn’t make iOS version breakdown statistics available) tells us that Android 2.1 is roughly equivalent to IE8.0. Internet Explorer 8.0.

I could compile a list of all the cool new things we’re seeing in HTML5 and CSS3, and then cross out every single one of them because IE8 supports exactly zero of these latest-and-greatest cutting edge features. To suggest that IE8 can match up against Android 2.1 in terms of features and device capabilities is absolutely ridiculous. Especially if you consider performance.

Android 2.3, the latest version for smartphones, has an internal share of 0.8% (of all Android users), which is roughly akin to Chrome 10. But Chrome 10 doesn’t have all of the same device and API capabilities as Android 2.3, and even that’s for Chrome 10 on the desktop. The Android version of Chrome lags behind in quite a few things, making this comparison reveal the same disparity between native APIs and Web APIs.

For another example, read what Aditya Bansod of Sencha wrote, on the Motorola Xoom/Android 3.0 Honeycomb’s browser:

We were excited about the first true Android operating system for tablets and had high hopes for a mobile browser that was as powerful as the platform. Sadly, the Xoom and Honeycomb are a real disappointment. We found consistent and reproducible issues in CSS3 Animations and CSS3 Transitions among other things. We had issues where the browser either hung or crashed. Regular scrolling was slow or below full framerate. We had issues where media playback failed or performed incorrectly. At times it felt like we were using a preproduction device, but we bought our test device from a Verizon Wireless store.

And beyond the HTML5 features, there were many more mundane web rendering issues: form element borders disappearing unpredictably at various zoom resolutions, CSS border radii with flattened edges, the accelerometer object being upside-down, the virtual keyboard causing layout bugs etc.

Whilst no platform or environment is ever bug free of course, we don’t see iOS or Android app developers suffer from such problems with the very latest public releases of their respective target OS. This makes the Android 3.0 browser feel very immature as an environment, whereas Android 3.0 itself, like iOS 4, feels robust, mature and reliable.

Bringing this all together, what it means is that for a developer, the API level equation skews heavily in favor of native apps. Native APIs are more mature, more stable, more powerful, more plentiful, and more widely available compared to their apples-to-apples-compared web equivalents. There’s a huge gap between the two right now; this gap is being closed by the browser vendors, but to suggest it is negligible or not even there is simply wrong.

The quality of the developer

A highly talented team can legitimately make a better app with worse tools and for a worse environment, than a less-talented team using better tools and for a better environment. This is why #1 is the most important factor, but as explained above, to discount the relevance of #2 and #3 is both illogical and simply incorrect.

Now, John and Remy are both incredibly talented and hard-working developers. They also work with very talented designers and know their tools of the trade better than most. But unless either of them cares to back up their claims with a factual example in the form of an Angry Birds (or whatever) done completely in the browser, all the evidence we have suggests that no matter your talents as a web development team, native apps have a leg up on whatever you create.

I’m not suggesting that people “should thus” go and abandon the web in favor of native apps. I think both platforms have their strengths and weaknesses, and among mobile native platforms there are a lot of differentiating factors as well. What I’m sayig is that the things that make native apps better now is that their tools and environments are much more capable and mature now. The CocoaTouch frameworks that Apple makes available as part of its iOS SDK are vastly superior to anything we’ve seen for the Web so far. This is not conjecture or opinion: you can do a lot of things with CocoaTouch that you cannot do, period, with web frameworks, and a good Objective-C developer can almost certainly make something perform a lot better whilst looking nicer than a comparatively good web developer.

In conclusion

What all of this speaks to is really this: because we deal with a vastly greater amount of legacy environments on the Web, whilst at the same time running as fast as we can to catch up to 25+ years of maturity on native OS platforms, web apps made within the same amount of time by an equally talented team of people will be less great than a native equivalent. That’s not an inherent truth, however, because it won’t always be true. It is merely a truth of the moment. That’s the reality of today. In a number of years, be it 2, 5 or 10, it will no longer be true.

I’m comfortable with that reality. I accept it, and still I personally choose to stick to doing things on the Web, abandoning (perchance temporarily, perchance not) my plans of getting into iOS development. But I won’t fool myself or anyone into thinking that I (or you) can do with web technologies what amazing things we see being done with native apps. Not just yet, anyway, and that’s okay with me. The Web has different strengths.

For instance, here’s one of the Web’s strengths that makes me personally love it more as a platform: I can publish content to it in ways that make the content rich and wonderful for users with modern hardware & browsers, whilst still being fully accessible to anyone using technology going back to the ’90s. They won’t get the same experience, but I’m at least not denying them access.

I love making web applications and tools for the web, and I love working with great content for the Web. But most people are nothing like me, and people who want to build a great application with a certain set of features in mind can get better results with native technologies right now than they can with web technologies. That’s a sour consolation for people who are already skilled and familiar with the tools of the web and are hoping to use those skills, instead of starting from scratch learning new tools and languages, but that’s simply a piece of the greater equation: do you want to make the best conceivable application with a fantastic user experience, or do you want to limit yourself only to the tools you already know?

Right now, my argument is that as a web developer, you cannot have both.

Dirty Percent

John Gruber with a fine piece on Apple’s Subscription policy and its 30%-cut. Regarding Price Matching, Gruber writes:

Yes, same-price rule is good for users and for Apple, but waiving this rule wouldn’t be particularly bad for users or for Apple, either — and it would give publishers some freedom to experiment.

I suspect one reason Apple won’t budge is that their competitors — like Amazon — insist on best-price matching.

One thing I would add to that, is this: Apple has no good incentive to budge on this right now. I think Apple is perfectly willing to budge, but if and only if it can drag along all their competitors. If this Price Matching aspect becomes a legal matter, it would allow Apple to point to Amazon and insist that if they have to budge, Amazon has to as well. That would work out just fine for Apple, but not so much for Amazon, who has been forcing publisher’s hands for years with their price matching policy.

Apple vs. Nintendo

A game-developer friend of mine asked me about my thoughts regarding this Wired piece by Chris Kohler on Apple’s aggressive move to present its iPad 2 event at the exact same time as, and just across the street from, Nintendo President Satoru Iwata’s Game Developer’s Conference keynote. Having once been a videogame journalist, I can somewhat relate to the “which event do I go to?” conundrum portrayed in Kohler’s piece, but given the state of things I would go to the iPad 2 event today if I had the choice.

I think this move is not at all unusual for Apple. Apple knows they’ll get all the media coverage they want, even with GDC happening at the same time, but by doing this they’ll clearly steal some attention away from Nintendo. And some of the attention Nintendo will keep will now include a play-by-play comparison to Apple’s new iPad offerings from a gaming perspective, which, no matter the outcome, is less ideal for Nintendo than simply having all coverage focused on its own new products.

Additionally, there are a lot of game developers (very) curious to learn more about what Apple will offer the gaming industry with the new iPad, whereas Nintendo’s presentation is expected to be focused on the Nintendo 3DS and reiterating some of its online/social features they already discussed at their dual-events held in Amsterdam and New York, last month. In other words, (somewhat) old news.

Developers already making games for Nintendo’s platform are likely to continue doing so. They may add an iOS version, but I don’t think all that many will switch from Nintendo to iOS. The reverse, however, seems even far more unlikely to me.

But what about new game developers, i.e. people who aren’t really tied to any platform yet? They’ll go where the money is, and right now, iOS is where the money is in mobile gaming.

While the sales on that platform are spread among a much greater number of people than they are for Nintendo’s platforms (Wii and DS), the barrier to entry is inversely lower, offsetting that to a fairly large degree. While developing a great iPhone game can easily run you into six figures of costs, that’s nothing compared to the average of seven figures for console games today. And these days the high end of console games surpasses most Hollywood movie budgets. Game developers are currently succeeding well enough on both platforms, but there are some significant benefits to iOS.

First, something that matters a lot to developers: the tools (SDK). Nintendo’s Wii was seen as really easy to work with (compared to the PS3), but iOS has come in and made it look painful. The starting costs alone give you an idea: $99 for iOS (free to start, $99 to publish your game on the AppStore), $1700~ for the Wii.

Distribution is a similar deal: Apple takes care of that for you (as part of its 30% cut), whereas with Nintendo you have to do all your own licensing & distribution deals with publishers, creating a lot of overhead for you. Customer payments also fall under that, with Apple’s offerings being simpler and easier to work with.

I could go on but the point is, when starting out with game development without a huge venture capital investment backing you and a large team under your command, iOS is a much more appealing proposition for developers. Those who are shunned away by Apple’s strict policies and rules will not find anything better at Nintendo, nor at Sony or Microsoft. Those developers will go to Android (and perhaps later this year the Playbook and WebOS).

What this means is that Nintendo will have to start offering a lot more than just “3D without the glasses”. That may be a nice feature but, much like movies in 3D, it could also be as little as a gimmick. Either way it’s not the kind of proposition that will sway a lot of developers to choose its platform over Apple’s. And when it comes to online play and social aspects, neither Apple nor Nintendo are doing particularly great (Facebook is), but my gut says Apple’s got a slightly better hand at this, right now. Case in point, using Wii Numbers as a means to connect with your friends is like addressing your friends by their telephone number instead of their name; no one does that. Game Center on iOS uses your own specified nickname, easily shared among your friends.

Lastly, Kohler writes:

Earlier this month, Nintendo of America President Reggie Fils-Aime said the iPhone’s massive library of inexpensive games constitutes “one of the biggest risks today in our gaming industry.” The glut of “disposable” games on iPhone that don’t provide very much fun or entertainment to users, Nintendo asserts, could end up turning players off of games.

That’s a historically realistic fear to have; Nintendo, after all, has over 120 years of experience selling games, but in the past 5 years things have changed like never before. I don’t think any large amount of comparatively crappy games in the iOS App Stores will turn people off of games altogether, for two reasons:

  1. The cost of games is so low that expectations are also set real low. The games for which people have high expectations are the games they hear their friends and family yammer on and on about, and which will, almost certainly, live up to those expectations just fine. Peer review is a huge component of how games spread, nowadays, and peer review protects people quite well from crappy games (and apps, for that matter).
  2. People buy games a lot more from the Top 25 (or 50, or 100) lists than they do casually browsing the categories or ignoring a game’s ratings.

It’s been a long time coming, but it seems that Apple has now openly declared its war with Nintendo for mobile gaming. I think this is a great thing, because in the end consumers win. How it’ll work out for either company remains to be seen, but where Nintendo has the loyal customer base and its vast experience with making and selling games, Apple has its other businesses that help drive success to its mobile platform (and secure it against any possible failure in the mobile gaming space).

Today, however, will tell us a lot about what Nintendo plans to do in order to deal with this new competitor.

Upcoming talks

Here on My own website

Subscribe to this site