Posts Tagged "developers"
Grassroots UI Innovation
When Apple introduced the iPhone and later the iPhone SDK, they established a series of UI metaphors, interaction models and conventions, that have served as a template for nearly all third party apps. Gestures such as swipe to delete, or UI elements such as springy lists are simply expected.
Apple has done such a great job of establishing best practices for nearly all types of UI interactions that it’s not often you see news kinds of UI interaction introduced by third party developers.
But when Atebits introduced Tweetie 2, it also introduced so-called “spring reloading”. Basically if you pull down past the end of a list, causing it to spring back, you can refresh the current list of tweets.
Many reviewers noted the ingenuity of this design, as it effectively turned a habit of many users (namely playing with the springy lists) into a useful feature. This design has since been adopted by several other applications and seems as though it may become a de facto UI convention on the iPhone OS.
Here is the original Tweetie 2 design:
Foursquare is basically a straight up copy:
This is Gowalla’s take on it – the logo appears to let you know you’ve pulled down far enough:
And the Wikipedia app Articles uses the design to lock or unlock your screen orientation:
It’ll be interesting to see if this convention is adopted by more applications going forward – or if Apple will even perhaps add it to their own apps. But at any rate, it’s nice to see good UI innovations from a third party developer being adopted by others. I can’t wait to see what Atebits and others come up with for the iPad.
Read MoreJetlinked: Goodbye Macworld
From my day job: equinux has written about some of our Macworld experiences over the years and how we made the decision not to go back this year. It’s a good look behind-the-scenes at Macworld and worth reading if you’ve been or plan on going.
equinux blog: Goodbye Macworld
Read MoreThoughts on the Safari 4 release timing
Apple announced and shipped the official Safari 4 release on the first day of WWDC. This was preceded by an extensive beta period, where Mac and Windows users could download the new version and test their websites and web applications with the new Webkit engine included with Safari 4.
Apple received a lot of useful feedback in terms of bugreports and also regarding the user interface changes the beta included ((Customer uproar notably lead to a reversal of the decision to place Safari’s tabs at the top of the browser window.)).
However Apple and website developers aren’t the only stakeholders with an interest in any new version of Safari: Many OS X and iPhone applications rely on Safari’s Webkit underpinnings, e.g. to display web content or generate HTML previews directly within an app. Safari provides the default system-wide Webkit framework, so any update to the browser will also affect those applications reliant on Webkit.
As expected with any major update, many 3rd party apps and plugins required updates to deal with the changes introduced by the Safari 4 beta. This is par for the course and most users expected a few glitches – it was a beta, after all.
But when the final Safari 4 release was announced at the WWDC keynote, it was quite different than the beta versions that preceded it. Cosmetic changes aside, a number of changes had also been made under the hood: The final release (which was automatically distributed to all OS X 10.4 and 10.5 users via Software Update) used Webkit version 530.17 – a notable jump compared to the Safari 4 beta releases, which used Webkit versions 528.16 & 528.17.
However, it would be wrong to try to blame the Webkit project in any way: Whilst a large part of the team does consist of Apple employees, it is a separate entity that isn’t directly tied to Apple itself. The Webkit and Safari release schedules also do not seemed to be directly related ((For example: The Squirrelfish JavaScript engine that Apple is touting in Safari 4 (under the “Nitro” marketing name) was announced by the Webkit team well before the Safari 4 beta was released.)).
It’s understandable that Apple would want to include all the bugfixes and improvements the Webkit team added as a result of the beta, but it is a bit disappointing that 3rd party developers weren’t given a chance to test those changes in the shape of a release candidate. As a result, a number of applications, websites and web applications needed to be re-tested with the final Safari 4 release and as usual, some of these required minor updates to restore compatibility with Safari 4 ((Apparently, even the iPhoto team hadn’t been able to thoroughly test 4.0: Safari 4.0.1 was released to specifically address compatibility issues with iPhoto’s Facebook integration & Places feature.)).
Webkit has become such a crucial OS X framework that releasing an update without extensive testing seems careless. To release such a large update on the first day of your own development conference, which developers spend a lot of money to attend, seems downright callous ((And releasing a browser that crashes when customers visit your online store, on the day you release a bunch of new products seems – well, just plain stupid.)). It effectively means that any testing and possible bugfix releases are delayed by at least a week, after developers have returned home from WWDC (and sobered up).
Is this a big of a deal as I’m making it out to be? Probably not: In the grand scheme of things, I’m guessing most developers and users couldn’t care less. But Apple does a much better job in this respect with other products, giving developers ample time and opportunity to thoroughly test their apps against most major iPhone and OS X updates before they’re released. Let’s hope a similar strategy can be adopted for Safari in future as well.
Update:
Adrian Kingsley-Hughes at ZDNet has also written a post outlining a number of Safari 4 issues. More indication that the final release was slightly rushed?
Read More