Posts Tagged apple

The Apple iPad: Thoughts

Posted by jasonwong in bad design, good design, marketing, thoughts on January 28th, 2010

Disclaimer, in case you didn’t know for some reason: I have a MacBook and an iPhone and I enjoy them very much.

The iPad is intriguing. I have seen many people ask why they would want one. I think Apple essentially presented several use cases (eReading, couch surfing, airplane video watching), but it boils down to this: if you’re in the market for something that’s cheaper and less useful than a laptop but is more expensive and useful than an iPhone, the iPad is your device.

I am just curious as to how big that market is.

A friend of mine has an iPhone and Apple desktop. He doesn’t do work when he’s mobile, so he is interested in this device. For me, I can’t justify one right away. I would not get the more expensive 3G model, so I’d be stuck with just a WiFi connection, which means mostly home use. Since I already have a laptop as my main computer that I can bring with me, I don’t see the iPad use case working for me.

In terms of striking the balance between a cheaper laptop and a more useful iPhone, they leaned more towards the iPhone. However, they brought along many iPhone shortcomings – namely, multitasking and Flash in the browser. Therefore, you cannot have Pandora streaming, have your IM client going, and also work on something in Pages at the same time. With a $500 iPad (which Josh Gruber says is fast, fast, fast), you can only do one thing at a time. This just kills it for me.

I don’t think a big enough deal is being made about the fact that Apple is using its own Apple A4 chip in the device that makes it “fast, fast, fast.” Apple bought P.A. Semi and is now designing their own ARM-based chips in house. So, from this, the iPad is faster. I would like to think the processor can handle more than one application at a time, though. Yes, you could say that the iPad would bog down running too many apps, but so too can the MacBook. People expect multitasking and, if Apple could design an elegant system to do so, they should. Essentially, my argument boils down to this: Apple can’t possibly have unitasking as a written-in-stone design goal; at some point, they are going to have to introduce multitasking. It seemed like the introduction of the iPad, with its wickedly-fast processor, was as good of a time as any.

John Timmer, Science Editor of Ars Technica, nails it for me (scroll to the bottom of the page to read his thoughts directly):

Steve Jobs very explicitly placed the iPad in the category class between the phone and notebook, and it very nicely splits the difference between the two. And that’s precisely why I’m a bit disappointed by it—it doesn’t share enough of the features of either one of those two devices to actually make it useful to me.

When I leave the apartment for anything beyond local errands, I’m almost invariably carrying both a cell phone for communicating and a laptop for getting work done. A truly useful device would be one that could let me leave one of those devices and its added bulk, cables, and worries about charge status at home. The iPhone went a little way towards that dream—it was a phone, but its ability to handle a bit of web browsing and some light e-mail meant that leaving the laptop at home was possible in a few additional circumstances—but, for the most part, I’m still stuck lugging two devices.

The iPad doesn’t fix that. It’s clearly not a phone, so my phone would still have to come with me. It would do a better job of e-mail and web browsing than the iPhone but, if I’m carrying one of those anyway, that’s not a huge help. On the other side of its category divide, the iPad might add a few more cases where a laptop is unnecessary, but very few. I’m a touch typist; I take notes on presentations while watching the speaker, and I am often writing in one application while looking over a document in a second. With no physical keyboard and no multitasking, the iPad simply wouldn’t work for me. It’s just too limited to mean I could leave my laptop home any more often than I already do.

Apple looks like it nailed its target of creating a truly distinct device that’s somewhere in between the phone and the laptop. And, for precisely that reason, it doesn’t seem like it would be all that useful to me.

No Comments

New Apple iPod shuffle: New commands in morse code!

Posted by jasonwong in bad design, memory on March 11th, 2009

Apple released the newest iPod shuffle today. It’s very small. The old version had a few buttons for navigation.

oldshuffle

Now, the new iPod shuffle has no buttons. Instead, the headphones have the controls – Volume Up, Down, and a center button.

newshuffle

Two things wrong with this. One is not human factors, but nonetheless: you can’t use your own headphones with the iPod shuffle without buying some kind of adapter. Because the controls are on the headphones, you need to use those headphones.

Next, and more important to human factors, is how you control the thing. To play or pause, click the center button once. That’s not bad. But then… well, Apple has a whole table. Just read how complicated it is to perform some buttons. (Click the image to go to the source of the instructions)

shuffleinst

To rewind, you TRIPLE-CLICK the center button? Supposedly, Macs only had one mouse button cause Steve Jobs thought people couldn’t tell right and left buttons apart. Now it’s triple-click. The sheer number of steps you need to memorize to operate this thing is nuts. Sure, you may say “I need to press three buttons to do the same thing on my regular iPod!” The regular iPod, however, has menus to serve as visual cues to tell you what you are doing. Here, you get a green or orange flashing light.

This is a bad idea. If nothing else, Apple should at least have redundant controls on the device itself – the same control scheme from the shuffle. Buttons for all the major functions. No double- or triple-clicking to be found. This is almost as bad as the MacBook Wheel.

,

No Comments

Safari 4: Top Sites vs. History CoverFlow view

Posted by jasonwong in data visualization, visual search on February 28th, 2009

Safari is a web browser developed by Apple and is primarily used on Macintosh systems, though there is a Windows version available. They just released Safari 4 Beta, so it’s not quite ready for primetime, but it’s close.

There are several great new features. One of which is called Top Sites. In place of a home page (though you can still set a home page), you get a panoramic display of 9, 16, or 25 of the sites that you visit the most. It’s displayed dramatically, arranged so you can see all your sites at a single glance. You can move sites, get rid of them, and pin them to a certain location if you want. The thumbnails are updated periodically and starred if they’re changed. Handy.

safari_topsites

Another feature is a visual browsing history. This is typically shown as a list of sites you’ve visited, going backwards in time. The list isn’t especially helpful, since all you have to go on are the URLs (because http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&ssPageName=STRK:MESELX:IT&item=320344855221 is not helpful) and the page titles, which are sometimes helpful. Having a visual for each page in your history, though, is great – it’s way easier to recognize visual things visually. Apple implements this feature using CoverFlow, which looks like this.

safari_coverflow

Now, it’s visual – the item you’re focused on is presented fully, and the items before and after are pretty visible. Trying to look at sites three or four items away, however, is unhelpful – you can’t see much detail in the site. All you can see if the left or right margin of the page, which tells you very little. Instead, if history was implemented like Top Sites was, where you could see all (or at least more) of each site, the feature would be more useful because you could more easily identify the site you wanted to go back to.

It turns out that this issue has already been discussed here before. Window switching in OS X using Expose (where you can see all the windows) was compared to doing it in Windows (where you can only see part of the window), and it was the same argument. Interfaces where you can see more of each window allows you to pick out the object you want more quickly because you can search in parallel instead of in serial. I think Apple should take this advice and apply it to more of its interfaces.

,

No Comments

Inconsistencies in Deleting Objects on the iPhone/iPod Touch

Posted by jasonwong in bad design, training, user testing on June 29th, 2008

Transfer of training is the concept that if you learn how to perform a function in one context, learning is much faster to perform the same function in a different context if the actions are the same. For example, copying and pasting is the same between Microsoft Word, Notepad, Adobe Photoshop, and others – Control-C and Control-V. These conventions are created through traditions and user interface guidelines, such as Apple’s Human Interface Guidelines for OS X and the iPhone. Consistency is good: users learn an action once, and it can be applied everywhere. Transfer of training.

However, the iPhone/iPod Touch interface has several glaring inconsistencies. One is how to delete objects. What’s been touted in Steve Jobs’ presentations has been swiping your finger across an object to delete it. For example, in Mail, the user swipes their finger across a message, and they get:

Then, they press delete, and it’s done. Simple enough, once users learn the finger swipe action.

This is almost the same with deleting a video. The finger swipes across a video and the red Delete button appears, but there’s a second confirmation:

This is not too drastic of a change, and adding a confirmation is not necessarily a bad idea, especially when it’s so obvious as to which buttons do what.

However, trying to delete a bookmark in Safari requires not only confirmation, but trying to guess at the meaning of buttons. The user brings up the bookmarks list, and a finger swipe does nothing. Instead, there is a button on the lower left labeled “Edit,” which does not evoke the “Delete” action at all. Once the user finally presses “Edit”, they are presented with little red circles to the left of the bookmark. It is important to note that this iconography is not used anywhere else in the interface. Finally, once the user clicks on the red circle next to the bookmark, they see the familiar red “Delete” button. Whew, that was different.

Moving on to the Notes application, however, shows a major breakdown. This, in my opinion, is the worst offender of implementing the delete feature. Deleting a note does not involve a finger swipe or an “Edit” button. Instead, to delete each individual note, they must be opened one-by-one. Of course, there is no indication of this. Once the note is opened, the user is presented with:

Suddenly, there is a Trash Can that is assigned the Delete command. More iconography that is never used in the iPod Touch interface, despite its familiarity to the user.

Yes, the iPod Touch interface is very new, but Apple is known for its consistent and intuitive user interface. This is an example of a total disregard for consistency in Apple’s shiniest new product, and it detracts greatly from the usability of the iPod Touch. Every computer user knows how to Copy and Paste, because the keystrokes are the same across applications. But when something as simple as a Delete command takes on four different implementation in four applications on a system, there is a problem. Apple desperately needs to standardize their interface to make transfer of training much easier from one iPod Touch application to the next.

,

No Comments

Animations and the iPhone

Posted by jasonwong in data visualization, good design, perception on June 24th, 2008

Animation in computer interface has been used for as long as the technology has been able to support it. The infamous “Clippy” in Microsoft 1997-2003 is an example of that. However, Clippy was almost universally despised because the animations tended to slow down completing a task. Even worse, when the user is idle (possibly thinking about something), the on-screen character would do a little dance, providing a distraction. No wonder why Clippy was even hated by Microsoft.

Animations can be useful, though, in the right context. On the iPhone/iPod Touch user interface, there are several examples of animations providing information about the state of the interface. This video below (created by me, which explains the awful production values), shows two instances of this. One is zooming and scrolling during navigation in Maps, and the other is scrolling in Safari, the web browser.

These animations naturally fit in the interface; they are not superfluous like Clippy. The zooming and scrolling in maps provides information about location and space. As users progress through the fake turn-by-turn directions, Maps could simply display the next turn. Instead, Maps zooms out from the old location and zooms in to the new location. This provides the user with a sense of where they are in the global sense, but also where they’ve come from in the relative sense (“We’ve driven very far southeast.”) This is useful in giving users a sense of situational awareness about the state of their trip.

The Safari animation is much more subtle – you scroll a page by tapping on the screen with your finger and dragging. When you reach the top or bottom of a page, trying to scroll more gives the user the sense of dragging the whole window, which visually implies to the user that there is no more to see. This is incredibly smart for this interface. In a regular computer interface, scroll bars are used to give the user a sense of position in the document. Scroll bars would not fit well in the iPod Touch interface, however, because many users would feel they had to use this bar to scroll, and the finger is not precise enough to grab a narrow area like that. Instead, the iPod Touch uses the entire screen as an effective scroll bar.

The downside to this is that there is no indication of document position, which is especially crucial at the top or bottom of the document. If the user is at the bottom but thinks there is more to see, the user may try to scroll. If the animation was not present and the interface did nothing, it would look like the scroll command performed by the finger did not register. This would prompt repeated actions by the user, all met by silence from the interface. Instead, this natural “rubbery” action by the interface signals that there is no more document to see. It’s natural, informative, and unobtrusive, which makes for an excellent use of animation.

,

No Comments