Of course, it was not the first touch "device" with a finger oriented UI. There had been plenty of those in other fields.
I think what you meant was first smartphone with a UI designed for touch.
However, even that honor must go to what was also the first smartphone in the world, the 1994 IBM Simon.
View attachment 452615
View attachment 452616
Of course, it was ahead of its time. After that, there were other all-touch smartphones, both concept and commercial. Big buttons, slide to unlock, orientation sensors, all black front, you name it, it was done.
Hmm. I think that what the iPhone did most differently (besides being from a well liked and known company), was that it included a fun factor that more function oriented phone designers had eschewed. I don't know how else to put it. For example, flick scrolling was well known, but other designers still used scrollbars, because they made more sense for long documents... and still do. It defied common sense to get rid of them as a primary list navigation method. Yet Apple did.
Thoughts?
Sorta. Most certainly, many of the individual fun things existed well before the iPhone.
But the "fun factor," as you call it, was not the reason for the iPhone's success.
What makes Apple different from all the other companies that tried before is that Apple's engineering and design teams actually understand how people interact with technology. They take the time to understand that in order for people to learn technology, they require a tight feedback loop to learn from. And therefore the experience of interacting with an unfamiliar device determines how likely the adoption of the new technology would succeed.
To get this feedback loop:
1) you need to first make it easy for the user to target interactive widgets. (touchscreen sensitivity, spacing, and widget size matter)
2) You then need these widgets to respond instantly to the user's interaction. (such as button press highlights)
3) Finally, you need the results of your interaction to show whatever state change occurred. (list scrolling, fading in/out selection, animated transitions)
4) And to extend that, widgets that visually hint at how they'll react help the user see what's coming. (that date picker thing, named back/forward arrow buttons in the navigation stack, toggle switch, etc.)
All of these things have been done before on some small scale just because they were cute and flashy on their own.
Apple was different by promoted these concepts from easter egg-class demos of programming prowess into a consistent mandate across the entire UI. By doing so, it wasn't just a cute gimmick anymore, it became a teaching tool. And by providing a less frustrating experience, a competitive advantage.
Just the simple matter of deciding how to lay out widgets demonstrates when a designer understands. Try Google Play Music on Android 4. Note how often you'll hit the wrong widget when trying to pause/play and jump to a particular section of music. Note how much easier it is to use iOS6's iPod app. (iOS7's iPod app is worse than iOS6, and marginally better than Play Music on Android 4.)
Flick scrolling with acceleration versus scrollbars with regards to long documents are an example that doesn't make sense.
If a UI designer and an engineer thought it through far enough, they'd realize that document length shouldn't be part of the question. There just wasn't any data transfer method available back then to provide a long enough document to a wireless device to matter. Nor is there any reason that a user would know beforehand how far to scroll.
Scrollbars provide great feedback in that when you interact with the handle, it moves both the handle and text, thereby tying the two actions together. It's nice that it even tells you where in the document you've scrolled to. The downside is that handles are small, and therefore not suitable for finger interaction. (Great for stylus!)
Flick scrolling provides a larger interaction target by allowing the entire scrolled document to function as a relative handle. The downside is that quality of experience and feedback depends on fast low-latency rendering. (if you go back to older OSs and play with scrolling, you'll find that in most cases, the scrolling is done by line heights of 10s of pixels rather than per pixel. This makes it a coarser scroll, but easier to render)
Most engineers and companies, when faced with the decision to use an existing GUI rendering engine or rewrite to make a high performance one, will use the existing engine. Despite all the smart people at Google and Microsoft, this didn't happen until Windows Phone 7 and later, Android 4.
If a team at IBM were assembled in 2006 to build the Simon with 2006 technologies, I have little doubt that they would ship something akin to the LG Prada instead of the iPhone.
