You were likely following the news, so I’ll cut things short - today was the WWDC, and together with a bunch of other cool news, Apple launched a
new website.
“Great!”, I hear you say correctly. The new website is beautiful. Except for where it isn’t - content organization.
The screenshot above portrays the new navigation scheme on Apple.com (specifically, the new
iPod+iTunes page). I have to wonder what crossed their minds that made them mix products (like the iPod models) with accessories and user actions (”Download iTunes”) in the same navigation bar. I mean, that’s mixing apples (pun intended) and oranges.
I know once you do something cool - like that awesome new navigation - you want to use it everywhere, but this is Apple - come on guys, you sure as hell can do better than that in terms of information architecture.
One thing I’ve explored often is how many web-based applications fail because of a lack of proper planning. One thing that I haven’t stressed enough though, is that proper planning doesn’t always mean spending months on end thinking about every single detail, but actually thinking about things in the right order.
Traditional feature-centric design
Usually developers start planning applications by thinking of everything they want it to do - and let’s face it, it’s pretty easy to get excited: since you’re getting some functionality in, you might as well do all the other hundred cool things too, right? Well, wrong.
Getting excited is great, but it may just as well hinder the application development process. Focus slips, pretty soon you’re trying to solve all the world’s problems. You may have heard of scope creep - this is just the same, but it’s your fault, and is definitely avoidable.
Top-down product design
The solution is actually quite easy although it may seem odd if you haven’t done it before: design interface first, then underlying code. Result: no functional slippery slope - you know exactly what you need to build to accommodate the UI functionality. As a side benefit, you get to have something you can experiment with as a prototype sooner, which means you can get more input sooner and iterate over it.
Give it a try on your next project - your developers will love knowing exactly what they need to build, and your designers will love not having to design
that new page for the brand new functionality that just crossed your mind.
In case you missed
Google Developer Day 2007 last month (
our coverage here) it’s not too late to see and learn about all the interesting Google APIs, tools and other news covered that day. Why? Because Google’s used their YouTube property to publish
these 128 videos from the event. Lots of good stuff covering everything from
Google GData programming to
Google Gadgets programming to
Testing Distributed Systems, and
a Google Gears introduction. Or, 124 others. And since it was a distributed event across 10 cities around the world, you can get videos in languages from
Japanese to
German.
On the Google front, our listings for Google mashups keep growing. For example you can check-out:
What’s hot online these days? Video. What’s hot in web mashups? Video. We continue to see a steady stream of mashups built with the
YouTube API. We now have
123 YouTube mashups listed here. But this is an API that’s due for a change.
At last week’s
Google Developer Day the folks from this team outlined how they soon be transitioning this API to use the Google
GData formats and protocol. See this YouTube API blog post
The Future where you can read more about it, including why:
- Better scalability/stability/flexibility
- Standardizing on an existing framework - easier to mash up with other GData APIs
- Setting us up for write feeds later in the year by using the authentication models
- Developers can leverage GData resources, such as client libraries and developer guides
And what would a piece about YouTube be without a video. Below links you to
a video from Developer Day to get the story straight from the YouTube engineers.
Got ideas on what they should do with it you can let them know in the
YouTube API Feature Requests wiki.
Amid all of the API and mashup news last week between the
Where 2.0 Conference and
Google Developer Day there was another interesting tidbit of mashup news: the Google Earth team bought the Spanish geo-centric photo sharing service
Panoramio. The service, started in fall of 2005, lets users upload photos and geolocate them on Google Maps and Google Earth. This application was one of our earliest ProgrammableWeb mashup listings back in 2005 and you can see our
Panoramio Profile here. Below is a screenshot from the service back when they started:
Of course it’s much more than just a mashup and Panoramio has lots of useful features and a large, quickly growing community (over 1 million photos, 4 million monthly uniques, and 30 million page views — see
this Alexa chart on their blog to view how fast they’ve grown). For some time now, Panoramio has been the default photo layer for Google Earth which in turn had a lot to do with this acquisition. A big congratulations to co-founder Eduardo Manchón and the Panoramio team. You can read more at
Panoramio’s Q & A page and the
Official Google Blog.
