Tag : apple

When one talks about Apple's design, one immediately thinks of Jony Ive's modernist, rational industrial designs for computers, peripherals, and of course the iPad and iPhone.

I usually send a bunch of links around the office every week. Perhaps some of you may be interested by them too:

The conventional wisdom is that Google will be or is the big challenger to Apple in the mobile computing market, but it turns out that we've been digging in the wrong place all this time. The way I see it, the real competition is going to come from Amazon.

Recent announcements from Amazon make me more certain than ever that they will shortly be launching a Kindle-branded phone and tablet based on Android.

Following up on Cath’s recent post about what Conor calls ‘application obligation’, I thought it would be interesting to see what apps people in the office feel obliged to use, and why. More interesting than the apps themselves (Twitter as a service took centre stage, as I expected), was the reasoning behind why people altered their behaviour to fit these apps or services into their lives, instead of the other way around. I’m presenting them below so you can read them for yourselves (in most cases I’m simply putting their words into the third person so as not to take too much away from the content – they make really valid points):

Hidden among the details of Apple’s announcement of the next version of the iPhone operating system last week was a nasty, snide little addition to the terms and conditions that iPhone app developers must agree to in order to get their apps into the App Store.

In effect, it says that you must use Apple’s developer tools and preferred programming language to develop iPhone apps. Which, on the face of it, is uncontroversial. It’s Apple’s platform, so you use Apple tools and languages. The problem is that there are significant efforts from other companies and projects to make it easier to transition to iPhone app development from other platforms, such as Microsoft’s .NET and Adobe’s Flash, as well as to make it easier to write apps that run on multiple mobile platforms. Apple’s devotees have had problems with these alternative platforms before, as I wrote a few months ago, but now Apple have taken the extraordinary step of embedding their own language preference in the terms and conditions of even being an iPhone developer at all.

Or so I tweeted whilst watching the recent Apple keynote. A month later and I don’t think I could have been more wrong.

Immediately after the iPad’s reveal, the interweb rippled with an argument between two tribes, those that want a computer that allows them to tinker under the hood, and those that don’t care about getting their hands dirty – they just want to email, surf, watch and listen. For me, this isn’t the interesting debate. It’s how the speed, screen size and controlled environment of the iPad now means that content design on screen can finally come of age and grow some balls. Big ones.

A great blog post by Lukas Mathis has been floating around Twitter for a few days now. In it he talks about the removal of features in software development. Specifically:

If you don’t pay attention, what started out as an elegant, simple application that perfectly solves a single problem, can quickly turn into a huge behemoth of an application that solves a ton of problems, but solves all of them poorly.

This, and some other tweet comments, got me thinking about the iPad (who isn’t?) and how I believe it’s a glimpse of the future for how we interact with personal computers.

In the 35 years since the arrival of the personal computer we’ve been on a continuous upward trajectory of feature enhancement and specification bloat. It’s not just the software, it’s infecting the very machines that we run the bloated software on.

Now that the dust has settled from the latest application of the Reality Distortion Field and we are all salivating at the chance to get our hands on the iPad, it’s time to think about how all of these devices will work in our day to day lives.

I’m a fully paid up member of the Apple devices fanboy club. I carry an iPhone and a 5th generation iPod with me wherever I go (even the largest capacity iPhone is nowhere near enough to store even a third of my music collection), I have a MacBook Air for holidays and overseas trips, a 17″ MacBook Pro for work and a huge cheese grater Mac Pro at home for media storage and its raw computing horsepower.

I love all of these devices for different reasons, but one thing I don’t love is the difficulty of keeping them all up to date with the latest versions of my data.

One response among designers and UX folk to Apple’s new iPad has been to criticise the effort required of users to command the haptic interface. Microsoft’s Surface had the same response, as did the interface that Tom Cruise used in Mission Impossible.

‘Ergonomically speaking, it’s just too much hard work’ is the usual response. There’s a lot of supposition and conjecture there though, mostly based on the received wisdom that less work is better. It seems obvious that they require more work to control, but I’m not aware of any long-term study into the ergonomic effects of haptic interfaces in everyday use or indeed that they are even hard work to use on a daily basis. I’m certainly one of those people that look at this kind of interface and thinks “It just looks like a lot of hard work”.

RRW have been trading on a rumour that Apple’s new iPhone is going to have NFC functionality in the coming Spring. About bloody time if you ask me. NFC (Near-Field Communication) will technically allow you to use your phone as not only an Oyster card, a passport or a debit card but will also allow you to read RFID chips so you can see how much is on your Oyster card, check the microchip of a lost pet against the Pet ID database or even take payment from other people. There’s a wealth of possibilities. Nokia already has devices on the market with NFC built in but has never managed to make it appeal to the public.