Joshua Tucker's avatar

Joshua Tucker

Lock Screen Features Are Treacherous Ground: Part 1

Over the last two years, as I’ve continued to grow and learn more about design, my diligence to truly evaluate the features people have suggested for iOS and my own projects has increased. I often found myself indulging in something based on the “how cool would it be factor” instead of taking the view from the sky and deciding the validity of the idea based on the important fundamentals: security, usability, functionality, etc.

Although I have much to learn and understand, I am confident in writing my point of view on the iOS lock screen and what should and should not be accessible from it. Many times has this topic come up in discussions online and offline, but I have yet to find a solid source that elaborated on the specifics. This is my goal with these “series” of posts. I am breaking up the discussion in bite-size chunks as to not overload people, including myself. I can’t discuss everything on each topic in a post either, so I’ve opened up a way to discuss more dynamically (see Branch).

The main question of this discussion will be:

"What should and should not be accessible from the lock screen and why?"

Part 1 will focus on the issue of security.

Security:

The security of the user and his or her information on device is extremely important. Regardless of whether a passcode is set, what can be viewed or done directly from the lock screen should be an issue of great concern. As a point of critique, I will use a common feature that jailbreaker’s love; quick send.

At the core of lock screen security, I believe it’s extremely vital that a user shouldn’t be able to perform any action that requires or allows someone to search Contacts. This is why quick send from the lock screen is a fundamental security flaw. Someone can start a new message and search through all your contacts, viewing data such as phone number or email address. But one might argue “Siri allows you to call, text, etc. from the lock screen, so quick send is no different.” This is not true, and here’s why. With Siri, you have to be deliberate when you perform any of those actions. Siri awaits a direct input such as “Call X” with X equaling a value which is extremely specific. You can’t search through all your contacts via Siri, whereas with quick send, I can start by typing the letter “a” and go down the alphabet, viewing every contact and their information. That’s a big problem. One might follow up with an argument “What if you prompt the user for a passcode (if set) or require the user to have a passcode on to use this feature?” If this is a question you may have, stay tuned as I will discuss why this wouldn’t work either.

To conclude this section, if any application, tweak, or concept potentially allows a user to search through Contacts, or any data that is considered private, then there’s a fundamental security issue at hand. This is why Apple will never implement a feature such as quick send unless they are able to ensure protection of a user’s private data.

I encourage you to jump in and post your thoughts. Hit up my thread on Branch to get involved.

© 2012 Joshua Tucker

Updated design for my task launcher concept.

Full details on Dribbble

How Facebook’s New Chat Drawer Increases Inconsistency

Facebook updated their iOS application today and incorporated a new chat drawer for the iPhone and iPod touch. It’s essentially the same as the left drawer but accessed from the right side. There were a lot of other features that were added as well however that’s not the focus of this rebuttal.

I am writing this because I feel that the newest drawer addition continues to make different parts of the Facebook application inconsistent and confusing for the user. I have broken each point into its own section for better understanding of why I feel this analysis matters.

News Feed:

The News Feed page is the same as before with one exception; a new chat button on the top right side. On top of adding the button, the new drawer can shown by swiping from the right to the left, which means the News Feed has dual side gestures to show different drawers. This presents a problem. Native cell swipe handling has been compromised.

Using Mail as an example, users are coached to understand that swiping a cell presents a Delete button. No matter which way you swipe, the button is presented to ensure both left and right-handed people can perform the action with ease. This pattern is engrained as default all over iOS and is a known paradigm for other applications that choose to use it correctly, whether it’s a Delete button or not. Due to how Facebook handles the drawers currently, it makes it impossible to integrate any of those features in the future:

1) Deleting my own posts from the News Feed

2) Hiding posts

3) Reporting for spam

The second and third point are not features available in the mobile application. My question is why not? They very well should be and are just as important from the mobile platform as it is from desktop. These are just a few ideas for what could be added.

You may be thinking that this isn’t such a big deal, but wait until the connection is made with the section below.

Profile Page:

If you go to your own page, nothing has changed – which is a problem. Note that the Chat button is not available on the top right side of the bar. Why? Having access to the chat feature is just as important here as it is on the News Feed. Why limit a core feature and require the user to perform extra steps to reach it? First inconsistency.

Second, the cell swipe handling becomes super sketchy here. Let me list what each swipe in this view does:

Swipe Left (Page): Shows “X” button to allow you to delete a status

Swipe Right (Page): Shows main drawer

Already at this point, it diverts from what is being used in the News Feed. Consistency is vital to user interaction; it’s absolutely invaluable. A feature is being limited and made harder to access and the handling completely changes. Not good. Second inconsistency.

Third, I mentioned above that the chat drawer can’t be accessed from the profile page (or other pages). In fact, it can. But, it’s strange. If you swipe the navigation bar from right to left, the drawer appears. Again, why? Is the lack of a chat button a bug or deliberate? If it’s a bug, then that’s fine, but either way it still adheres to my concerns. And if it’s deliberate, why hide it? Bad news bears.

Note: The handling of the profile page is the same for all other pages.

My Solution:

In light of my points, what is my solution? I could discuss how I feel the view should be changed completely, but for the sake of my argument, let’s go with the best way to optimize with what we’ve got. Here’s my proposition.

1) Keep the default cell swiping paradigm consistent in all places. Allow the user to swipe either way on a cell to be presented with options such as delete, hide, or report for spam

2) Show both the Main and Chat button on the navigation bar everywhere. Accessibility from everywhere is extremely important

3) Still have the ability to swipe open a drawer by restricting the swiping to only the navigation bar or make the off-screen gestures more precise. Leave 98% of the page adhering to default cell swiping and make the edges a way for you to more deliberately swipe across and access the drawers.

Feel free to hit me up on Twitter to continue this discussion or with questions/concerns.

© 2012 Joshua Tucker

What Makes or Breaks an App Switcher Interface?

The topic of a “new, revitalized App Switcher” on iOS has resurfaced over the last day as The Verge posted a concept a user did recently on what he feels the iPhone 5 App Switcher should be. After reading and evaluating the concept, I really got to thinking about what I believe in when it comes to a good multitasking design. In other words, what are the make it or break it for a multitasking interface or concept? I have highlighted in the following sections different important factors I feel make or break a multitasking interface or a concept. I will be using The Verge’s concept post as the primary comparison.

Note: I will continue to add more points if time and ideas permit so view this as a “ever-changing, evolving” document. 

Three-Way Battle

The proposed Verge mockup for the actual app switching has three basic key components.

1) App preview

2) App icon

3) App name

Out of these three choices, a logical question would be “Which one is the most important?” I would argue that that the application icon is the most crucial part of a multitasking interface. A user, especially on mobile devices, associates applications or certain tasks by its icon, not by the name or action. You can evaluate this on your own by viewing the SpringBoard as an example. What’s larger? The name of the application or its icon? 

With this said, I return to the mockup and say that exemplifying the app preview and diminishing the size of the app icon is counter-productive. When I open the App Switcher, the first distinguishing factor is the icon. The icon is the most important part because, all other parts aside, it is the clearest piece of information that tells me the application I can switch to. Period. This concept loses the icons in the preview of the app and increases the time for me to cognitively understand what applications are what. 

On top of this, the app previews are so small they essentially waste space and show nothing. Think about certain stock Apple apps have similar base interfaces. Imagine trying to figure them out in such a small view where content within the application is barely visible simply by their app preview? Ouch.

So what is my opinion on what makes this “three-way battle” come out with the right winner? Two things.

1) The icon must be the centerpiece and focal point of app switcher. It needs to be the most important piece

2) If you’re going to use an app preview, find a way to display it so the content is clearly visible and useful. Otherwise scratch it completely

Penthouse or Green Acres?

I use this analogy, because heck, you can’t discount the classic TV show “Green Acres” right? I’m into the classics. But really, I think this comparison fits perfectly with the app switcher interface. The underlying question really is the following:

"Do you want a scenic or compartmentalized view?" 

The mockup brings in some new features that would be unique to that view, but I would argue that things are just too jam-packed. The more areas where touch or gestures can be accepted increases the level of error and mistakes. I understand that optimizing the space that is available is important and I’m a huge contender of that, but it must be done in the proper way. 

Using the music section of the mockup as an example, the album and music icon are so small that they are barely visible or tappable. For people with big fingers, that could be an issue. Also, in the case of the album art, it’s so small that it’s not particularly relevant to see because you can’t distinguish any parts of the artwork itself. 

The most obvious solution would be to split certain parts and put them on another page of the app switcher, but then that increases the number of views to swipe through. So to fix that problem, we have a “big lot next door” we could work on.

So what’s my opinion on this topic?

1) There is effectively 800+ pixels above the switcher that is left untouched. Utilize the surrounding real estate to cut down on things being too close together

2) Bouncing off my first point, if content is barely visible or useful, resize appropriately or cut it. 

Law-Abiding Citizen versus Rebel

I will expand on this more when I have time, but if I could describe this section in one brief sentence, it would be the following:

"In the name of keeping our interfaces intuitive with Apple, we must somewhat play by their rules, but that doesn’t mean we have to think in the sandbox of what exists."

The linen app switcher interface has been a part of iOS since the beginning. I would argue that to include a lot more of the features that people would want in a multitasking interface, that we need to start thinking outside of the linen box. Go beyond what exists and create something that still fits the iOS native profile but utilizes something new and unique. 

I’ll be back with more! Stay tuned: feel free to tweet me on Twitter — @joshmtucker.

© 2012 Joshua Tucker

Inconsistency with Power Button While in a Phone Call (iOS)

For all my Twitter followers who replied or saw my post, I polled all you guys on the following question:

#Poll How do you most often end a phone call?

A) Use the “End button”

B) Use the Power button

The reason why I asked this is because I wanted to point out an interesting inconsistency with the Power button while in a phone call and discuss my solution for this issue. You can test this out for yourself and see exactly what I’m about to tell you.

If you’re in the Phone application and currently in a call, there are two ways to end a phone: using the “End” button or pressing the Power button. However, if you exit the Phone.app and come back, the Power button locks the screen instead of ending the call.

I’m someone who accidentally hangs up a call by putting my phone to my face and it hitting the “End” button (I’m sure many of you have experienced the same thing). The way that I keep myself from doing that is to lock the screen. But, it’s not an action that can easily be done. I have to multitask and do something else in order for the Power button to “switch” over to locking the screen instead of ending a call. The inconsistency of the Power button makes it difficult to remember what action will be done.

Since the Power button’s main use is for locking the screen, no matter where you are or what you’re doing, I think that it should be reserved for locking the screen only and not ending the call. For those users who use their Power button to end a call, I would say that there could be a short hold in order to end a call with the button so it’s not confused with simply locking the screen.

© 2012 Joshua Tucker

Now that iOS 6 has pull to refresh in Mail, the refresh button has been removed from the bottom bar. Being someone who always tries to find ways to utilize “dead space,” I thought about something that I would like to have easier access to from that view. 

One area that’s difficult to get to in Mail is the folder hierarchy for each account. In other words, you can’t easily navigate to another folder within your account (inbox) very easily. The process to do that now is to go to the main page of Mail and go into one of the Accounts at the bottom of the list. That’s displacing if you’re already in the inbox view. 

To make the process easier, I brought a folder button to replace the refresh button inside the inbox view. If you tap that folder icon, it will bring up the hierarchy view and allow you to switch to another folder right from the inbox view. If you have more than one inbox and are in the “All Inboxes” view, all the folders for all accounts will show. But if you’re just in an individual inbox, it will only show folders from that inbox. 

You can always quit out of the view and return to the inbox you’re in. Easy peasy.

P.S. If you want an invite to Branch, click this link and “Ask to join.” Come discuss this concept with me there!  

© 2012 Joshua Tucker

Yesterday, I got in an interesting conversation about Settings toggles. The other person and I both agreed that having the actual on/off switch in the root of Settings was the most traditional way to display it, but we wanted to find a solution to following:

"How can the user toggle certain settings that have the toggle one cell deeper in Settings from the first page?"

The reason why this topic was important is because “in the name of keeping specific settings organized,” it’s better to keep the toggle and its respective settings all together. But on the other hand, it adds one extra step and makes it less convenient to switch certain toggles easily. The release of iOS 6 would make the solution we were seeking much more significant. 

To keep all the settings of one specific setting in a unified view and allow the user to easily toggle just the switch from the first page, I formulated the following solution: swipe cell toggling. In the most basic of terms, the user would be able to switch a setting on or off by simple swiping over the first cell in Settings. Naturally, the text would change depending on which one you’re on i.e. “Swipe to enable, Off.” One view deeper in that setting’s panel, the on and off toggle would still be available and would dynamically change via swiping or simply tapping the switch. 

——————————————————————————————————————

Here are answers to a few questions that could be posed.

"Why keep the actual on/off switch in the setting’s panel? Isn’t it redundant to have a swipe and an on/off switch?"

It isn’t and here’s why. It’s displacing for someone to have to leave a view in order to toggle something. For example, if I was in the Location Services panel and wanted to turn it off from there, it would just be easier to go to the top and disable it versus having to leave the view to do it. I base my judgement on an example like the volume slider in the App Switcher. The volume buttons perform the same function, but having the slider is an easy alternative and is located right in within grasp of what view you’re in. My implementation of the swipe in conjunction with the on/off switch is on incorporated on the same premise. The swipe is added as a convenience, not a replacement.

"Why do you keep the swipe cells the same size? The cells in Settings > Notifications display a second line of text but are bigger."

In comparison to the cells for Notifications in Settings > Notifications, the swipe cells are not displaying anything that is potentially significant. With the notification profile cells, the user is looking at it to see whether things like Badges, Banners, or Alerts are enabled. Viewing and knowing what each notification has set is important from that view. But when it comes to swipe cells, the second line is a reminder; a simple guide. It’s not meant to alert you of something that’s set. As the user becomes more familiar with how swipe cells work and where they are used (where info like “On/Off/Connected” is displayed on a cell), then it won’t be necessary to prompt them anymore about how to perform the action. 

"Why even notify the user at all with the "Swipe to disable/enable?" 

Prompting the user is important if there’s no clear indication of how to handle something. Swipe gestures are difficult because there’s no great way of alerting the user that swiping it will perform something with a symbol. Especially when it comes to de-cluttering the view. And in any situation, the user needs to know exactly what he or she is doing and what will happen when any actions is performed. At this current time, using a text string prompt is the best solution. 

"The swipe cell functionality applies to other settings, not just Location Services?"

Absolutely. The implementation of swipe cells would be incorporated in every applicable area. Consistency is important so bringing all scenarios to the same level would be the only way to go. It would work on cells like Wi-Fi (although not shown), Bluetooth, and others that will be available in iOS 6. 

"How does this work within the scrollview?"

The swiping is down horizontally and would not conflict with the vertical scroll that’s already native. 

——————————————————————————————————————

Note: I always value suggestions, opinions, and even opportunities to engage in a conversation. Discussions are for seeking knowledge and improving upon ideas. Feel free to comment below or contact me on Twitter

© 2012 Joshua Tucker

With cell providers continuing to cut back on data and increasing the prices of the plans, it’s crucial to be aware of how to limit your data usage. Push for Mail is a core component of iOS and is extremely useful, except when it eats into your data. You want the capability to have push, but many of us have to disable it due to our data usage habits. However, many of us are in areas where Wi-Fi is available often therefore we aren’t concerned. But at this point push for mail is either an on or off option. And when it comes to Fetch, same deal - possibility of increased data usage.

I propose that an easy solution for this issue would be to allow the user to specify whether push or fetch uses cellular network. In the first picture, note that a new toggle would be added allowing you to decide whether push (if enabled) and fetch uses cellular data. The next following pictures show the options you would have if you go into the Advanced section and select a specific account. If you select either Push or Fetch, it will offer you the option use cellular data for that specific account only. 

Hit me up on Twitter with any questions or comments. Or feel free to post below. 

© 2012 Joshua Tucker

Usability is a 360 Degree Spectrum

The heart of usability goes after the user. From a user interaction standpoint, the purpose of such design is to enhance the environment allowing each and every user to experience it in a simple, native, and unique way. To accomplish this, problems must be solved. Just a like a developer solves a problem through code, a usability designer solves a problem through design and interaction. 

I’m writing this post as I feel its important to stress that to accomplish excellent usability, you have to approach the environment taking in a 360 degree view. What I mean by this is, many times developers and (or) designers bring out this great awesome new feature or interface but don’t account for the other existing factors that are inadvertently “removed” or “hindered from use” due to how the implementation is done. Also, solving one problem doesn’t mean you solve them all. Introducing something new is great but can cause problems in the interaction itself by offering a limited field of usability. 

I’m going to use the following example to illustrate my thoughts and conclude with how I feel this scenario applies. 

——————————————————————

Search Engines in Safari for iOS versus Search Engines in Safari for OS X

Safari on OS X has had a slick feature for a while that allows the user to change the default search engine right from the search field. Now that Safari has a unibar designed (part of Mountain Lion), it’s now done through the address bar. When the URL field is empty, a magnifying glass will appear on the far left. Clicking it will drop down a small window and give you an option to switch to another search engine in the list. Clicking a new search engine will change the default search engine. The default search engine can also be set in Safari’s preferences.

With the way OS X has it set up, it would be easy to gradually add new search engines to choose from because they are easily accessible from anywhere. Even though a user may switch often, it’s excellent usability to allow the user to switch at anytime without going through dialog windows, settings, or by doing numerous steps. Convenience is key.

On iOS, it’s much different. The way you can switch search engines is to go into Settings > Safari > Search Engine and change it. And technically, by doing this you’re doing two different things. First, you’re changing the default browser. Second, you’re changing the search engine you wish to use in a session if you’re currently browsing. What I mean by this is, if I want to switch to searching Bing in my session from the search field, I’d have to switch my default engine in Settings so that I can. The way iOS has it setup would make it extremely difficult to continue adding more search engines because it’s difficult for the user to switch them quickly within the current view. Again, convenience is key. Having the ability to switch search engines from within Safari is key.

When it comes to searching the web, I feel that it’s extremely important to have “liquid methods;” actions and tasks that can be done dynamically right where you are without having to pull yourself away from the current view. Switching search engines I think is one of them. OS X has got this covered, so how could iOS improve? Here’s my solution. Give Safari in iOS a unibar design. Offer the magnifying glass icon on the far left and allow the user to switch simultaneously right in Safari without having to go into Settings to switch it so it can be done natively within the address bar.

——————————————————————

So the natural follow-up question would be "how does the scenario above apply to a 360 degree view of usability (or initially the point of this post)?" This scenario gives an example of offering a feature that may not necessarily be "user-friendly" in all cases. The problem being solved was the fact that users need a default search engine option. The solution was offering a way to offer a setting to set the default search engine. But, to my point about a continued 360 degree spectrum, another problem arose. The next logical step became "I’ve given them more than one option for a search engine but what about when they want to switch search engines easily?" OS X allowed the user to switch dynamically. iOS hasn’t followed in its footsteps yet.

Problem solving is a process. Solving one problem doesn’t solve them all. When thinking of usability and interaction design, remember that it is on a 360 degree spectrum. Features, actions, methods, and tasks all loop around and interconnect with one another. To be cliche, the quote the expresses it in the most down-to-earth way would be “What goes around comes around.” So when introducing something new or changing something existing, take this approach and look from a bird’s eye view of how your project, application, or tweak will offer something unique as well as how it will potentially shift how other things work. Follow the trail all the way around making sure each step of the process is simple and user intuitive. And when you reach the other side back to where you started, you know you’ve created something amazing.

© 2012 Joshua Tucker

NOTE: I thought long and hard about whether this post would break iOS 6 NDA. I concluded that it was discussed in the keynote and is viewable on Apple’s website, so I deemed it as not being an issue. However, if this is not the case, please let me know and I will gladly remove it. 

Also, I explain in the post why my implementation is different from what is currently available. 

——————————————————————————————————-

One of the new incorporations with iOS 6 is the pull to refresh feature in Mail. If you read my recent article about Pull to Refresh in Safari, you will know that my philosophy on pull to refresh is rather unorthodox. My goal in whatever I design or conceptualize is to build it in a way that makes it unobtrusive and available no matter where you are in the view. With that said, I wanted to make pull to refresh work in a way that allowed you to do that. In this case, I wanted my philosophy to hold true in the Mail application. So, I’m bringing back my handy-dandy two cell checklist of my view on what I want with pull to refresh:

- The ability to pull and refresh (obvious)

- Being able to pull and refresh and remain where I am in the scrollable view 

This piece is a rebound off of my Pull to Refresh in Safari concept except I incorporated it into the Mail application. There are some slight differences for those who read my previous article so make sure to read which section carefully which are divided for your convenience.

——————————————————————————————————-

1) Pull to Refresh View

The first section showcases how I think the pull refresh view should be. At this current time, the pull to refresh view is located within the scroll table which means you have to be at the top to refresh it. To allow the user to refresh from anywhere, I designed it so it can be pulled from the navigation/header bar. Simply drag down from the top and it refreshes no matter where you are in the view.

Although not viewable in photos at this time, I see the refresh view displaying important information like the number of new emails (if applicable) and a loading bar for new emails coming in. This would eliminate having to scroll back up to see if any new mail has come in. It will display a summary briefly at the top and then close the gap again. I will work on that implementation soon, but for the time being, note that the refresh view in my mind has a lot more purpose than what it’s currently used for. 

2) Navigation/Header Bar

Discussed briefly in the section above, this bar will be the initiation point for the pull to refresh. No matter where you are in the view, if you drag down, the view will slide down and refresh. Short and sweet.

3) Scroll View

Although shown at the top, since the header bar (All Inboxes/Specific Inbox) is always visible at the top no matter where you are on the scroll view, it’s fairly easy to initialize the pull to refresh. Again, short and sweet.

——————————————————————————————————-

This implementation would be available on all iOS devices.

 The ability to pull and refresh (obvious)

√ Being able to pull and refresh and remain where I am in the scrollable view

© 2012 Joshua Tucker