Summary: This first UX Think-Aloud article focuses on my first week with iOS 7 on my iPhone 4S, noting my impressions and reactions during actual usage after updating my iPhone 4S on September 20, 2013 (two days after it’s official release). I note UX flaws, design choices I would have made differently myself, places where the drive towards “flat design” degrades the iOS UX from its more “skeuomorphic” predecessors (e.g., unmarked text, tappable or not? Sometimes!), bugs, and more. Observations include how to get to the weather app and the new calendar widget in the Notification Center, pros and cons in the changes to the the presentation of launcher folders (one step forward and three steps back) and the most recently used app list (webOS-like, but not enough), and changes in Messages (timestamps! finally!). Certainly, iOS 7 has UX flaws and other bugs, but all OSes do. It may not be revolutionary, but I doubt iOS 7 is a death knell for its users’ ability to use their iPhones.

UX Think-Aloud: Notes While Experiencing Design

A classic tool in the usability toolkit is the think-aloud protocol. When used during a usability test, test participants are asked to think out loud as they go about the tasks of the test. It has always had its theoretical problems, some of which center around the degree to which researchers can take the participants' vocalizations as an accurate transcript of their cognitive processing and some of which have to do with the degree to which the vocalizations are edited or somehow influenced by participants, knowingly or not, for any number of reasons.

Those concerns aside, the think-aloud protocol is one of the few ways to "get into participants' heads" and get a sense of users' experience of a design.

UX Think-Aloud articles are a way to "get into my head" as a UX designer; I'll basically be "thinking aloud" as I explore new designs, taking notes on my experience and my reflections of that experience as I explore whatever design that is the focus of that particular article.

Format

I will be experimenting with the format of my UX Think-Aloud articles. This first one is a little more structured; I've grouped my observations and reflections into topic sections. This format should make the observations easier to digest as a reader, but it does mean that readers lose most of the sense of the order, causation, and stream-of-consciousness that a less processed "transcript" would provide.

Like so many other things in UX design, designing this "report" format is an exercise in navigating trade-offs.

Today's UX: iOS 7

On September 18, 2013, Apple's iPhones 5S and 5C were released to general purchase, and iOS 7 was made available as a software update. In the interest of keeping my first impressions as unbiased by others' reviews as much as possible, I updated to iOS 7 on my iPhone 4S as soon as I could—Friday, September 20.

What follows is a listing of my first impressions and a few later reactions from my first week of using iOS 7.

iOS 7 UX Issues

General

• The font in the launcher is no longer bold. That makes it a bit harder to read.
  • I tried to changing text to bold in Accessibility settings changes too much, including the text in text messages.
• The animations launching an app from the launcher and returning to the launcher take too much time.
• Opening apps seems to take longer. I get the app's full-screen image, and it sits there for longer than in iOS 6 before I can interact with the app.

Notification Center

• The widgets have disappeared from the Notification Center: Weather, Facebook status, and Twitter. How do we find them? Has Apple chosen to withdraw support for those companies by choosing to remove those activities into the Notification Center?

I discovered how to get to the weather app from the Notification Center: you have to tap on the completely unmarked and normal-looking text reporting the weather:

• I discovered how to get to the weather app from the Notification Center: you have to tap on the completely unmarked and normal-looking text reporting the weather.
  • Just to be perfectly clear about the UX problem here, the problem is that there is no way for users to tell that that weather text is any different from the text reminding them about their friend's birthday or from the text noting that their calendar is double-booked. Tapping either of the latter two blocks of text does nothing; their presentation does not suggest that they can be tapped, and so, appropriately, tapping on them does not do anything. How is anyone supposed to tell that the weather text is tappable? This is like pushing a blind man into a room and asking him to flip a light switch; he can't see it.
    • Is this an example of a "flat" design aesthetic  driving the removal of affordances from designs in an effort to avoid being skeuomorphic? If that's the case, this is a prime example of having an aesthetic override a good design guideline (making it obvious what users can interact with).

• Single day calendar in the Notification Center: Jury's still out.
  • It tells me that I have a conflict at 7pm, but 7pm is not visible in the little calendar snippet, nor can I scroll the calendar snippet.

Folders: One Step Forward and Three Steps Back

• A Step Forward: You can finally put more than 12 apps in a folder!
• A Step Backward: Icons are reduced to three in a row from four in a row! Granted, it matches the zoomed out view, but, in this case, I would prefer for functionality to win over visual consistency. Later reflection: This could definitely be a personal bias. User testing could solve the question of which would be more useful for more users..
• A Step Backward: We are limited to 9 apps in one view within a folder, and are forced to scroll to a new page to see the rest of the 12 that we'd previously had in the folder, even if we don't want to add any new ones! So, existing users are penalized with having to scroll to see their potentially painstakingly organized icons.

• A Step Backward: The three in a row in folder view means that Apple has now moved users' icons, and they are no longer where users put them and expect them to be. Whatever Apple's designers may think about its users being ready for a "flat" world, users are people--evolved for spatial memories, spatial recognition, spatial reasoning, and the manipulation of things in space. Move things, and we get confused.
• A Step Backward: Opening a folder is now its own view level. Using the home button from within an app that was opened from a folder view now serves as a "back" button, bringing users to the folder view. This is horrible for two reasons:
  • First, it further overloads the home button. What will tapping the home button do? In iOS 6, it used to: 1) take you to the launcher page from which you came (even if it was with a folder open, it was embedded in the launcher page...and you could actually see the larger context of the other icons on the page outside of the folder), 2) if you were on a launcher page that wasn't the first launcher page, the home button would take you to the first launcher page, 3) if you were on the first launcher page, it would take you to Spotlight search, and 4) if you double tapped the home button, of course, you would bring up the most recently used app (MRUA) list.  Now, in iOS 7, they've removed its use to get to Spotlight search, but they've added in this "Back" function (that goes from app to folder view).
  • Second, it introduces a new level of navigation, and, with it, a new level of overloading. Now, where you'll go when hitting the Home button is unpredictable from within an app. Will it take you to a launcher page directly or to a folder view? It depends on how you got to the app. That's a user-uncertainty/surprise moment that I'm betting will be well over 20% of the time. That's the kind of uncertainty that disrupts the ability of users to develop solid, cogent system models and expectations of the interactive system with which they are engaged. Users will have to remember not only what app they're in, but how they got there. E.g., Will it be faster (i.e., how many taps will it to take) to get to the next app that you're looking for by going to the most recently used app list, or by tapping the home button to get out to the level of launcher that you need to get to your next app? For the MRUA path, users would double-tap the home button, swipe until they see the app they had in mind, then tap to go into the app. Users risk the possibility that the app that they want is not in the MRUA list, and this time spent is wasted. For the launcher path, users might only have to tap the home button just once if they came directly from a launcher page, or they might have to tap twice, once to get to the folder view and again to get to the launcher page (depending on how they got into the app), then swipe to get to the right launcher page, maybe tap into the right folder, then tap the app that you want.
  • The important point is to offer users a navigational invariant--something they can count on. Most importantly, that it be invariant with respect to whatever matters most to them--in this case, most likely, it is to get back to a familiar starting place that provides a broad enough overview for them to do what they want to do next. In this context, I suspect that that should be the launcher.
    • Related UX Considerations: The question of what it means to go "back" is also faced in the use of "breadcrumb" trails for web sites, the question being whether to offer breadcrumbs that showed the structure of the website/content or to offer breadcrumbs that literally showed your path to getting to the current content (replicating web browsers'  "back" path).
    • Jakob Nielsen recommended structural rather than history-dependent breadcrumbs all the way back in 2007 (Breadcrumb Navigation Increasingly Useful). While he does have an additional consideration in recommening structural breadcrumbs^[1], the core issue is the same as the issue I bring up here: should back mean back the way you got here or just "up" to the launcher? The good thing about previous iOS versions' folder-embedded-in-launcher-page view with respect to this question is that it avoids the structural vs historical question entirely, whereas the new iOS 7 implementation reveals the problem.

Most-Recently Used App (MRUA) List

• Why don't the icons stay aligned with their cards?! The icons' slightly independent movement from their cards undermines the assumption/perception of the pair as being single entities, because the movement mismatch disrupts the application of the gestalt principles of perceptual organization (see Gestalt Psychology, especially the principle reification). Maybe the icons were given the ability to creep in towards the middle relative to their related cards to give users the ability to see apps that are further off to the left and right. But this is a case in which the potential additional functionality is not worth how it undermines the perception of the card and its icon as a single object.
• Argh! We knew this going in, but those cards are not active cards; they're just big thumbnails. This means that, when users tap into the cards, we get not an active app, but, rather, an image of an active app. But the image stays around too long; It should ideally swap out to an active app as soon as it gets to be full-screen sized. Otherwise, we have what we have now: tapping on what looks like a fully active app does nothing. It seems to take an additional up to 3 seconds (on my iPhone) for an app to actually come active, and it is only then that the image of the app is swapped out for the actual now-working app. This is an example of a UI sleight of hand that is bad; it tricks users into thinking they can interact with an app, but they'll then have to re-do any work that they've tried to do with the non-functional image.
• Why is the launcher in the MRUA list?! It's not an app! And you can't "close" it?! Why up it there amongst an array of pictures whose functionality includes the ability to be thrown away to close them when 1) users can't, in fact, throw it away, and 2) it actually allows users to move it a little ways as *if* it could be thrown it away?! Taken together, those two points are a recipe for confusing users into thinking that they *can* throw it away, misleading them further, and then, ultimately, thwarting them. It's a trick! It shows up in the MRUA list, it looks like an app, it behaves mostly like an app, but refuses to actually be thrown away.
  • Even worse, the launcher thumbnail seems to have inherited the most egregious of the thumbnail behaviors, the up to 3 second delay between looking like you can interact with it, and when you actually *can* interact with it.
    • There seems to be some of this even when going from an app to the launcher via the Home button, but that could simply be the duration of the zoom-out-to-the-launcher animation.

Messages

• Each individual message now has an independent ineria when scrolling the conversation history. Why?! Isn't it better to consider that history a single, atomic page of history to scroll through rather than a list of individual messages? What benefit does the latter model offer? Maybe the suggestion that you can interact with it individually… I'll grant that it did lead me to explore whether I can do anything with it individually, and that that's how I just now discovered that a long press on the message brings up a context menu that allows you to copy, select it and delete it or forward it, etc. The inertia is still aggravating and not worth it. To compare this with what seems to be a parallel domain and to consider whether that should be treated the same way, why not have paragraphs in a document or Facebook news feed stories show the same inertial effects? Because its not very useful and thus, not worth the distraction.
• Messages uses conversational partners' nicknames, rather than their first and last names. In the conversation list, conversations are labelled with nicknames, and search does not seem to find conversations via the contacts' first or last name. There is no setting to go back to old behavior. Grrrr.
• Finally! My first delightful, begrudging, positive! Dragging to the left when viewing the message history reveals actual timestamps for each individual message! Granted, the showing of individual timestamps has been available in all my previous smartphones (Handspring Treo 600, Palm Treo 650, Palm Treo 700p, Palm Treo 755p, Palm Pre, Palm Pre 2, Palm Pre 3). It's just that Apple had decided on behalf of its users that they didn't need that information in iOS 1-6. And, when, finally—after withholding timestamps for 7 generations of iOS software—Apple relents, it feels like a (theatrically manufactured) revelation. It still seems implemented as a begrudging offering, though, since it requires that users drag the screen to the left and hold it there to see them. This is the UX equivalent of requiring users to actually ask for the information and keep asking for it if they want a sustained look at it.

Safari

• Ah ha ha ha ha ha ha! They went with cards a la webOS for their multi-tasking, but ditched it in Safari's multiple card view for a less functional (seeing less of each card as compared to iOS 6) and less consistent (say, with their new multi-tasking card use and launcher pages and folder paging) Rolodex-like view!
  • Probably a scalability thing: Safari finally allows more than 8 simultaneous pages open. I currently have 17.
    • Later reflection: This Rolodex-like view could possibly be superior in at least one way to the stacks seen in webOS 3.x (HP Touchpad) and webOS 2.x (HP Pre 2 and Pre 3). The ability to see the full breadth of each open web page might give users a more complete view of the pages, allowing them to more easily identify each page when looking at the array of pages. Compare the views above, though; there is no obvious winner.
  • Swipe from left edge --> Back
  • Swipe from right edge --> Forward
  • In Rolodex view:
    • Tap-hold on a card allows you to pick it up and move the card within the "stack", just like in webOS' stacks.
    • Swiping a card to the left --> dismisses/throws away/closes card
    • Those two gestures noted in the Rolodex view are just like those in webOS 3.x' card stacks. Rotating the presentation of the cards and the gesturesby 90° does not count as "innovative" or prevent us from seeing the reuse of webOS ideas. Android's MRU Apps list, I'm looking at you; though, since Matthias Duarte (from Palm/webOS) is Android's UX leader, I don't suppose that counts as copying--but re-use, yes.

Lock Screen

• When users unlock the lock screen, the whole lock screen slides to the right to bring users to the PIN pad.
  • When users want to react to and go to an individual notification (e.g., a text message), this behavior does not provide any differentiation to users that they are headed for that notification vs. just unlocking the phone. This lack of feedback leaves users wondering what's going to happen.
    • More "flat design" throwing the baby out with the bathwater in the name of escaping the presumed badness of skeuomorphism?

Closing Reflection: My initial impression about the lack of feedback when sliding an individual notification was incorrect. There are a couple of changes to the screen as users swipe on an individual notification to provide feedback that users will be going to that particular notification's app post-unlocking: that particular notification slides about a quarter of the way across the screen before the screen itself moves along with it, and, if there are other notifications on the lock screen, the other notifications fade a bit as users swipe the one in which they're interested. All the same, I believe that the feedback is too understated. When there are multiple notifications on the lock screen, the swiped notification moves with respect to the other notifications, and is emphasized as the others fade away around it. This is subtle feedback, but noticeable. When there is only one notification present on the lock screen, I believe that the quarter-screen shift and lack of fading for the only visible notification is too subtle, as the quarter-screen shift goes by very quickly given normal swiping speeds and is visually camouflaged by the movement of the whole lock screen as soon as that quarter-screen swipe continues into a whole-screen-width swipe.

New Gestures: Inconsistent meaning and availability

• There are gestures in Safari! See Safari section above.
• Messages also has gestures! Or at least the back gesture from conversation to conversation list.
• Mail has the back gesture, too.
• Calendar does not.
• App Store, back gesture
• Reminders does not have the back gesture from the reminder detail screen.
• Photos has the back but not forward gesture, too, but only between album view and Album list view. In picture mode, the back gesture is interpreted as a swipe to switch to the next picture "back".
• Clock does not: I tried going from editing an alarm to the alarm list.
• Passbook does not appear to have them…weird navigational swapping instead
• Game Center does not have them, as far as I can tell.
• Notes has the back gesture.

Thoughts on The New Gestures

• This is one challenge of having navigational gestures like these happen in the same space as the content vs having a dedicated gesture area like webOS' phones.
• Hypothesis: Here in iOS 7, everywhere but in Safari, the "back" gesture is more appropriately understood as an "up the hierarchy" gesture, not a back gesture.
• Hypothesis: or maybe it's a one-step structurally back (is that distinguishable from "up"?) or one step historically back?

Change in Existing Gesture

• Swipe to delete in lists only seems to work right to left. Seen in voice memos, Messages conversation list, Mail's mail list view, ...

Miscellaneous

• I can finally put Newsstand in a folder! Let's hear it for consistency--let icons behave like the other icons.

Bugs!

• Messages sent from within Safari or even from within Messages to a new phone number (say, by tap-holding a number and choosing to Send Message, then typing out the message and hitting Send) result in a new conversation in the conversation list, but it's empty--i.e., your message is not in the history, possibly lost and never sent.
• I can no longer set the cursor on a new blank line (created with a "return" press) in Messages, at least, to paste anything. I get the magnifying glass, but no context menu. To make things worse, the cursor actually does not appear afterwards.

• Search within Messages does not find everything that it should. It's supposed to search both in the To line and in the conversation, I believe…(I wonder if it is supposed to search the whole conversation, or only the most recent page of conversation…).
  • I searched for "Marvin", and Messages found a conversation between Marvin and I, as expected.
  • It failed to find a conversation labeled "Corwin & Marvin", however.
• Continuing bug: Screencaps do not get a proper "Date Taken" timestamp...Or Windows somehow isn't reading them correctly.

Interesting iOS 7 Articles From Around the Web

• 21 brilliant iOS 7 tips and tricks [Techradar.com]
• Links 28 Sept, Apple's iOS 7 Causing Motion Sickness And Even Vomiting In Users [Forbes.com]

Updates

1. 10/2/2013
   • There is a way to get Messages to use normal names instead of nicknames! The answer is on the Short Names page in Settings > Mail, Contacts, Calendars [look in the Contacts section] > Short Names. Flip the "Prefer Nicknames" toggle. For pictures, see my follow-up article, iOS 7: Make Messages Stop Using Nicknames
2. test

[1]While Nielsen’s recommendation for structural breadcrumbs comes in the context of web browsers and potentially longer chains of pages and “locations”, the idea of offering a reliable navigational invariant is applicable in both the context of breadcrumbs and here.