Joshua Tucker

Calendar and Reminders Alerts vs. Do Not Disturb (iOS & OS X)

Fri, 22 Feb 2013 00:13:40 -0500

I noticed what I’m about to tell you long before tonight, but I just got to writing it down.

The purpose of Do Not Disturb on iOS is to ensure you’re not being alerted during times you don’t wish to (like when you’re sleeping – or even during a calendar event (something I plan to create)). However, there is always those exceptions to the rule. Currently, you can set a privileged group that can override your Do Not Disturb (something I think OS X could have as well in the future). Plus an alarm that you set in Clock will always circumvent when it’s enabled.

I found that Calendar and Reminders don’t have that authority when it comes to alerts. Do Not Disturb (and Show Banners and Alerts on OS X) lacks a fundamental exception for those. If I set a calendar or reminder event to alert (or remind) me at a certain time, location, etc., it will not override Do Not Disturb when it goes off.

My methodology can be summed up in the words of a great friend of mine:

“When I think of Do Not Disturb, I think of a hanger I put on my hotel door. The hanger is meant to keep me disturbed from the outside world, not myself. I could be having a party in the room but people or things outside of my room shouldn’t bother me.”

Key point: Features like Do Not Disturb and Show Banners and Alerts aren’t supposed to keep you disturbed from yourself.

If I take the time to set an alert on a calendar event or reminder because it’s that important for me to remember, it should override anything no matter what. It warrants authority.

Why isn’t it doing this?

Analysis: Notification Priority on iOS The expansion of...

Wed, 13 Feb 2013 02:14:00 -0500

Analysis: Notification Priority on iOS

The expansion of technology has enabled us to converse with one another in a variety of ways such as Twitter, Facebook, iMessage, SMS, email…the list can go on for infinity. There are many pros to this from a mobile perspective but there’s also a major problem that we all face: notification priority.

There’s a lack of an intuitive, intelligent way of filtering content when it comes to notifications. Every application has an excuse to send you a notification. At the number of applications people run on their iOS device(s), the list can extent to a great length. How can this be handled? There are currently three ways of dealing with this issue, but are they really the most optimal option?

Sorting Apps Manually -

This requires you to go into Notification settings and move cells around in the order you wish to receive them. But is that really worth your while? It can be tedious, especially when you have a lot of applications. If you install a new application that’d you like to be prioritized, you go in again and move things around. After a while, you just let it go and the order runs rampant.

Sorting Apps By Time -

Although a logical ordering parameter, does it really reflect what’s most important? If I receive a very important message from my mom but then I receive a ton of Facebook notifications, what’s being prioritized? Facebook, even though what I really care about is my mom’s message.

Disabling Push Notifications Per App -

At the point of installing the application, you make the choice. But most of the time, I’d argue we reluctantly choose to send push and then really don’t care to change it afterwards.

The key point in all these current cases is that it’s difficult to truly order notifications in a way that matters most to you as the user. And the two ways that allow the user to manually order it can’t reflect your changing habits and use of applications effectively. Our devices, or are iPhones, iPads, and iPod touches more specifically, are more sophisticated and powerful then any other time in history. How can we make them the workhorse in understanding us better in regards to communication priority? What can be done to remove the necessity to manage notification priority ourselves? Sorting notifications by usage.

Sort By Usage

I can argue confidently that the applications a user uses or responds to the most (notifications) are the most important. Choosing to open an application or directly responding to a notification is a choice. And when you are presented with numerous choices and you choose one over the others, it’s clear which is more important to you. Therefore, if you (as the user) make choices all the time about the applications you open and the notifications you respond to, wouldn’t this be great measure for determining what notifications are important to you? I think so.

I propose that iOS could improve this issue of communication or notification priority by doing the work for us – presenting us the notifications that matter most based on data. How can this data be collected? Here are some different ways it could be done effectively:

Usage Collection:

- # times an app is opened

- # times a notification from a particular app is opened from the lock screen (omitting the slide to view or read cases as no choice is presented to opt out and just unlock)

- # times a notification from a particular app is opened from the Notification Center

- the amount of time spent in an app

Based on this data, you can rank applications by most important (priority) and display their notifications as such. The device could also cross-reference other data to ensure that notifications from applications such as Phone, Mail, and Messages aren’t buried (if they aren’t necessarily the most used application)

Phone -

Is the notification from someone in your Favorites? Your Do Not Disturb group? Someone you frequently call or receive (pick-up) calls from? Take this data and rank it based on most important (priority) and override the overall usage ranking if it meets certain criteria (i.e. duration of calls, # of calls)

Mail -

Is the notification from someone in your VIP list? Someone you frequently respond to? How quickly does the user read the email from that address? Take this data and rank it based on most important (priority) and override the overall usage ranking if it meets certain criteria (i.e. response time in relation to receiving the email, # of times you send messages to this contact)

Messages –

Is this notification from someone in your Favorites? Is it someone you frequently respond to? Take this data and rank it based on most important (priority) and override the overall usage ranking if it meets the certain criteria (i.e. response time)

Let’s let our devices be the smartypants.

P.S. Stay tuned for another analysis and my idea of notification “re-posting.”

Do Not Disturb for iOS - Application Integration Preface To make...

Sun, 10 Feb 2013 17:54:00 -0500

Do Not Disturb for iOS - Application Integration

Preface

To make this short, I attended a conference called Apps World this past week at the Moscone Center in San Francisco. I met a woman for the first time there and we totally hit it off. She’s a designer too and we spent much of our time talking design and interaction. Her insight truly opened my mind to thinking in different and new ways.

Originally posted on Dribbble.

Introduction

Do Not Disturb was a prominent feature in iOS 6. Beyond setting a schedule, Do Not Disturb is a simple toggle on and off action. Our iOS devices are extremely powerful and are designed by incredibly intelligent people. How could Do Not Disturb move forward in a way that makes it more intelligent too without you needing to attend to it?

One way is to integrate it with Calendar (see here). It would helpful so you don’t have to remember to set Do Not Disturb if you’re in a class, in a meeting, or somewhere that your calendar has down. This works primarily for occasions in which you’re not using your device. But what about when you are? How could this work?

Grab your hardhats.

Do Not Disturb for Applications

One for All or All for One?

Apple designed the banners in such a way to make them as unobtrusive as possible but to remain visible enough to catch your eye. You can still navigate places when banners are showing and they aren’t generally aggravating when you’re moving from task to task, app to app. However, this is not the case for certain scenarios such as reading a book or document, watching a movie, or playing a game. Essentially places where you’re in presentation or fullscreen mode.

Adding the ability for Do Not Disturb to manage when you’re using your device is a solution, but it’s cloaking it all when it isn’t necessary. When specificity can be achieved, I feel it’s always the best solution. Much easier and more efficient. When the sun is facing my window, I close the shades. But do I want to close all my shades, even the ones on the other side of the house when I just want to close this one for a specific period of time? No. So how can I close only one shade so to speak on my iOS device?

Intelligent Integration

Do Not Disturb could work in a “one shade” fashion too. For applications such as games, video players, or in stock applications like iBooks, an alert could show offering you the option to set Do Not Disturb specifically for that application only. If you don’t mess with the banner at all, Do Not Disturb remains off and will hide automatically. However if you enable it, Do Not Disturb will turn on and the banner will hide.

While in the application, you won’t be disturbed. If you choose to leave the application, it won’t be set everywhere else. The integration would be intelligently designed to not prompt you each time. If you only exit for X amount of time or the application is still “running” and hasn’t been killed in the App Switcher, the setting you have remains intact. If you wish to change the setting, you could do a gesture from the top of the screen (possibly two on the iPhone, four on the iPad) to show the option again and allow you to change your choice. Over time, the device could catalog your patterns of enabling Do Not Disturb and make the decision for you (but prompt you of the choice you set and allow you to change it if you wish to).

Let’s let our device be the smartypants.

Bonus Feature

Here’s how I got the necessary colors for the banner and its elements:

I analyzed the color table of the image in question and checked two things: which color was the most used and which color was the brightest color (128 block color grid). The most used color was taken to make the banner and the button. The brightest color was used to color the text and moon icon. In the event that the most popular color and brightest color were the same, it went down the grid to the next color in which it was visible (could be determined by a brightness parameter). The colors for drop shadows, gradients, and the like were done in a similar fashion (with exceptions to the rule of course too). The background underneath the content is also blurred. All of this computation could be done in code and on-device dynamically.

Noticed something interesting with phone handling on the iPhone...

Fri, 01 Feb 2013 22:50:00 -0500

Noticed something interesting with phone handling on the iPhone that I’ve never seen before. The following occurs only in this order to my knowledge.

After answering a phone call, here’s what’s standard in regards to the Power and Home button:

Power Button: Locks screen (speaker) and hangs up when not on speaker (I wrote a personal rebuttal on this handling in a prior post)

Home Button: Multitasks to SpringBoard

I discovered that the Home Button in the sequence below locks the screen instead of multitasking to the SpringBoard. It’s puzzling and I’m not sure why it would do it in this case.

Step 1: Answer phone call

Step 2: Turn on Speaker

Step 3: Lock screen

Step 4: Unlock screen (note Camera grabber is gone and no passcode is required)

Step 5: Disable Speaker

Step 6: Press Home Button

After pressing the Home Button, the screen locks. And not only does it lock and remove the Camera grabber, but it prompts you for a password. In every other case but this one, the Home button multitasks you to the SpringBoard.

I wonder why it is like this. What is its intended purpose? It seems odd to me to change the handling of a button for one user case but keep the same for all the rest. In a similar response as my other post regarding the power button while in a call, I would argue keeping it consistent in all cases would be important.

I would love to learn what the purpose of it might be. It could very possibly be a bug too, but I always give the benefit of the doubt. Feel free to post a comment about your thought on it below.

Full screen images for my third revision of Lock Screen...

Sat, 26 Jan 2013 17:12:12 -0500

Full screen images for my third revision of Lock Screen Actions.

Original Dribbble post

Unsolicited Redesigns by Lukas Mathis

Fri, 25 Jan 2013 00:45:00 -0500

Unsolicited Redesigns by Lukas Mathis:

A present I got for my birthday many months ago was Mathis’ book Designed for Use: Create Usable Interfaces for Applications and the Web. I started reading it recently and can’t believe I didn’t start earlier. It’s a great resource and has taught me immensely.

This is another great piece from him called Unsolicited Redesigns. Of all the excellent points made, here’s my takeaway:

1) Walk in humility

Humility is an act of respect. Instead of seeking to be right, strive for what IS right. Pose your critique more along the lines of a question, not a statement.

“Being brilliant is not a great feat if you respect nothing.” – Johann Wolfgang von Goethe

2) Seek to learn

Don’t let your arrogance get in the way of learning the what, where, when, why how. Take pride in your work, but be open and receptive to the feedback. The more you listen and the less you talk, the more you will gain. Communication has a purpose – use it for what’s meaningful.

“Being ignorant is not so much a shame, as being unwilling to learn.” – Benjamin Franklin

Many people have addressed Do Not Disturb and questioned why...

Sat, 12 Jan 2013 16:26:00 -0500

Many people have addressed Do Not Disturb and questioned why there isn’t a toggle for it in the iOS Notification Center. Often, the justification is that OS X has a Show Banners and Alerts feature in its Notification Center therefore it could be a viable to add Do Not Disturb in a similar fashion. The conversation arose again a few days ago, so I decided to sit down and think about my own personal thoughts on the matter.

What is written below, along with the images submitted, is a collection of my analysis on Do Not Disturb as well as my solutions to the inquiring minds. They are strictly my opinion based on my own personal experience, but I hope to shed some light on a topic I feel hasn’t been focused on as in-depth as I attend to with this post.

Do Not Disturb vs. Show Banners and Alerts

First, I will begin by explaining the difference between these two. Sometimes their differences can be overlooked and I want to put their “definitions” on the table so to speak so I can move forward with a solid foundation.

Do Not Disturb - A feature on iOS which allows the user to silence any calls and alerts from the lock screen when enabled.

Show Banners and Alerts - A feature on OS X which allows the user to show or hide banners and alerts from the desktop when enabled.

From the core, these two features are starkly different – Do Not Disturb functions only when the device is locked and Show Banners and Alerts only works when computer is in use (by nature of the OS). With that said, the implication of these features is the following:

Do Not Disturb is designed to keep you uninterrupted when you’re not using your device while Show Banners and Alerts keeps you uninterrupted when you’re using your computer.

In simple terms, one serves for when a device is not in use while the other serves while it is in use. That’s a significant difference. When Do Not Disturb is enabled and you’re using your device, it is not in effect. You still receive notifications (banners and alerts) without interruption. Therefore, placing a switch for Do Not Disturb in the Notification Center doesn’t make sense.

Do Not Disturb doesn’t mandate SpringBoard notifications (banners and alerts). Even with it enabled, the device still shows banners and alerts like normal. By placing a toggle in the Notification Center, it makes a false impression on the nature of Do Not Disturb and just adds clutter – it doesn’t make sense.

A logical response to this could be:

“Then why not make Do Not Disturb hide banners and alerts too which would make this feature work in the Notification Center?”

There are many issues with why that wouldn’t be a good solution, especially for users who have it scheduled. Another tack-on suggestion could be:

“Add a Show Banners and Alerts option within Do Not Disturb.”

Although it is an option, it adds more complexity than the user needs to handle. If the user has to think whether that option is enabled before enabling Do Not Disturb then it removes the ease of knowing exactly what you’re doing when you toggle the switch.

Hopefully, you see why I feel that a feature like Do Not Disturb and Show Banners and Alerts are two separate entities and would wreak havoc if placed together.

So, what if I want best of both worlds?

Like the title says, what if you want both features? A way to keep you uninterrupted when you’re not using your device as well as when you are? My concept photos show what I feel could be a good way to integrate them both.

In the images I submitted, you’ll notice that it has the following disclaimer:

“Do Not Disturb is enabled. Calls and alerts that arrive while locked will be silenced.”

This only shows when Do Not Disturb is enabled. Why did I add this after digressing into why Do Not Disturb doesn’t belong in the Notification Center? Because it is applicable to let the user know of its current state. Although Do Not Disturb doesn’t mandate banners and alerts on the SpringBoard, iOS still stores all the notifications you receive even with it enabled. And despite being an “advanced user” so to speak, and having a status bar icon, I forget it’s left on sometimes.

This isn’t a problem I face alone. I have had three friends in the last two months make a comment that they couldn’t figure out why their device wouldn’t buzz or ring. They mentioned they finally discovered that it was this feature called “Do Not Disturb” that was on. Two of them said it took them over a week to figure it out (the last said over a month). The prompt in the Notification Center, I feel, should help in reminding even the most “advanced” of us that Do Not Disturb is actively running. In my mind, this would always be in view in the Notification Center until it’s turned off. On top of this, having some type of alert after a significant amount of time that Do Not Disturb is turned on would be great integration as well.

But this message won’t be displayed in full view all the time. Pulling down the shade will reveal a Show Banners and Alerts toggle along with the text. Toggling it, similar to OS X, will turn off all banners and alerts from showing on the SpringBoard. When turned off, a status bar icon will show to notify the user of its state (next to the battery percentage). Since the scrollview in the Notification Center is very fluid, it won’t be hard for the user to discover the Show Banners and Alerts toggle as well as check its state in the even they forget (or don’t look at the status bar icon). You can hide the toggle and the text by pushing the view back up again.

As mentioned in the field, it will toggle itself back on again tomorrow. One might ask “Why not have a similar un-toggle feature for Do Not Disturb?” It would conflict with Schedule and wouldn’t help in users figuring out how to use all of its features.

I would love to hear your thoughts, concerns, and insight on this topic. Feel free to comment below or hit me up on Twitter.

UPDATE: I have started a project with a developer to bring this to life. Coming to Cydia in the near future.

UPDATE 2: It just dawned on me. Think about Power Nap as being the OS X equivalent to Do Not Disturb. The implication is that your device is not in use and doesn’t interrupt you (you don’t have to leave the lid open or disable your computer from sleeping).

Original Dribbble Post

As promised, here are fullscreen shots of my Reminders for...

Thu, 03 Jan 2013 12:47:14 -0500

As promised, here are fullscreen shots of my Reminders for Messages on iOS concept. Check out the original Dribbble post for full details.

Reminders for Messages on iOS

Here are the fullscreen images for my Actions Widget concept...

Tue, 01 Jan 2013 21:20:56 -0500

Here are the fullscreen images for my Actions Widget concept plus an example Calendar view on Dribbble.

Original posts:

Actions Widget - Notification Center

Actions Widget - Calendar View

Full screen images for the second revision of my Safari for iOS...

Thu, 27 Dec 2012 13:19:06 -0500

Full screen images for the second revision of my Safari for iOS New Tab View concept.

Original post on Dribbble.

Full screen images for my Safari for iOS New Tab View concept....

Fri, 21 Dec 2012 14:21:00 -0500

Full screen images for my Safari for iOS New Tab View concept. This first part highlights the Top Sites tab. Original post on Dribbble.

Emergency Call List Concept v2. Refer to Dribbble for...

Wed, 05 Dec 2012 22:03:00 -0500

Emergency Call List Concept v2. Refer to Dribbble for explanation.

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

Original Dribbble Post

Original Tumblr Post

Disclaimer: Due to being unable to test the Emergency Call...

Wed, 05 Dec 2012 12:41:00 -0500

Disclaimer: Due to being unable to test the Emergency Call system without dialing real emergency numbers, I may be incorrect on certain points. Feel free to correct me if I am and you know from experience.

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

This concept showcases an addition to the Emergency Call interface. On top of being able to dial a number, you can swipe over to view a list of numbers to call. The user of the device can set four emergency numbers in Phone settings to display in this view (or possibly more – potential scrollview however I don’t see it as being that useful). Tapping any of the cells will automatically dial the number. Security/privacy is retained since no one’s number is displayed ever during the call.

In light of potential exploitation or accidental dialing, an additional add-on would be a notification that remains on the lock screen to alert you that an emergency call was dialed.

Here’s another idea I have but I’m posing it as question in case this is already built-in.

1) The dialer recognizes if the number is not an emergency number and won’t dial if you type any number in. But, does that mean you have to dial an emergency number to call or can you press the Phone dial button on the bottom right immediately for it to automatically dial the appropriate number? If it doesn’t do this already, it would be an excellent addition

Originally posted on Dribbble.

Full screen photos for my Do Not Disturb Calendar Integration...

Tue, 04 Dec 2012 19:39:00 -0500

Full screen photos for my Do Not Disturb Calendar Integration Concept on Dribbble.

Lock Screen Features Are Treacherous Ground: Part 1

Mon, 03 Dec 2012 14:39:00 -0500

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.

Updated design for my task launcher concept. Full details on...

Wed, 28 Nov 2012 20:05:00 -0500

Updated design for my task launcher concept.

Full details on Dribbble.

How Facebook’s New Chat Drawer Increases Inconsistency Facebook...

Mon, 05 Nov 2012 20:20:57 -0500

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.

I recently added my AIM account back to Messages for Mac for the...

Tue, 23 Oct 2012 20:39:00 -0400

I recently added my AIM account back to Messages for Mac for the first time in a while. After signing in and everything was squared away, I realized two things:

1) The buddies list and other controls are still its own window (a “problem” I noticed since beta)

2) At the bottom of the main window in Messages for Mac, your AIM status is shown

As mentioned in number one, I noticed that the window was separated in beta and was puzzled because I felt that there could be a great way to integrate it into one view without having two open windows. At the time, I didn’t really think of a solution but it’s been jostling in my head. After reviewing this again and getting my thoughts together, I came up with a solution: a Show/Hide view.

A Show/Hide button would be added to the current view along with your AIM online status. Clicking the icon would expand the view showing all the same info that the regular list has but in that view. It’s scrollable just like normal, and even the buttons at the bottom are visible. To hide it, simply click the Show/Hide button again. The amount of content in your list will determine the height of the view (unless otherwise specified — read further). Even when this view is open, you can still scroll through your iMessages just fine. You can even change the height of the view at anytime when it’s open by simply dragging the border (just like any other similar view).

Since I don’t have any other social networks to add, I can’t test this, but, if there were multiple status cells at the bottom of the window, each and everyone one of them would have a Show/Hide button.

In light of this implementation, I don’t see any reason to still have the option show a separate window. If you wish to have it in a separate window, you could click and drag the view off the window.

Feel free to comment! Look forward to hearing from you.

What Makes or Breaks an App Switcher Interface?

Wed, 10 Oct 2012 12:45:21 -0400

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.

JailbreakCon Presentation

Tue, 02 Oct 2012 00:25:42 -0400

Evening everyone!

Wanted to post my Keynote slides from my talk at JailbreakCon so you can see what I was showing on screen during the presentation.

Beyond a doubt, these last couple of days have been some of the best in my life. The people I met, the relationships formed, and the opportunities I had to do fun and amazing things kept piling on and I will never regret making the decision to attend and speak this year. I thoroughly look forward to the next JailbreakCon in New York next year. Cheers to all the speakers, presenters, and the team that put it on who worked so hard to make this convention great!

Here are my slides from the presentation if you want to give them a look!

JailbreakCon Presentation