Joshua Tucker

Month

February 2013

4 posts

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

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?

© 2013 Joshua Tucker

Feb 22, 2013
Feb 13, 20132 notes
Feb 10, 20136 notes
Feb 1, 20131 note

January 2013

5 posts

Jan 26, 20137 notes
#iOS #iOS 6 #iPhone #Apple #iPod #iPod touch #Lock Screen #Actions #Do Not Disturb #Camera #Bluetooth
Unsolicited Redesigns by Lukas Mathis → ignorethecode.net

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

© 2013 Joshua Tucker

Jan 25, 20132 notes
#Unsolicited Redesigns #Article #Link #Ignore the Code #Mathis #Lukas Mathis #Takeaway #Quotes #Communication #Humility #Design #Designs #Redesign #Redesigns #Concept #Concepts
Jan 12, 20133 notes
#iOS #iOS 6 #Apple #iPhone #iPad #iPod #iPod touch #Notification Center #OS X #SpringBoard #Do Not Disturb #DND #Show Banners and Alerts #Banners #Alerts #Show #Hide #Feature #Concept #Images #Image #Analysis #Enable #Disable #Enabled #Disabled
Jan 3, 20133 notes
#iOS #iOS 6 #Apple #iPhone #iPad #iPod #iPod touch #Reminders #Fullscreen #Messages #Message #Text #Text Message #SMS #iMessage #Remind #Remind Me #Concept #Hour #Minutes #Cancel #View #Bubble #Sheet #Alert #Notification Center #NC
Jan 1, 201310 notes
#iOS #iPad #iPod #iPod touch #Apple #Notification Center #NC #View #Calendar #Reminders #Messages #Twitter #Facebook #Post #Tweet #Add #Event #Add Event #Reminder #Add Reminder #Action #Actions #Widget #Dribbble #Message #Send #iOS 6

December 2012

6 posts

Dec 27, 20127 notes
#iOS #iPhone #iPod #iPad #iPod touch #iOS 6 #Apple #Safari #Browser #Tab #New Tab #Concept #Dribbble #Images #Full screen #Bookmark #Bookmarks #Reading List #History #iCloud #iCloud Tabs #Top Sites #Sites #Site
Dec 21, 2012
#Apple #Bookmark #Bookmarks #Browser #New Tab #Reading #Reading List #Safari #Sites #Tab #Top #Top Sites #iCloud #iOS #iPad #iPhone #iPod #iPod touch #Concept
Dec 5, 20121 note
#iOS #iOS 6 #iPhone #Emergency #Call #Emergency Call #Apple #Concept
Dec 5, 20121 note
#iOS #iPhone #Apple #Phone #Emergency #Call #Emergency Call #Notification #Alert
Dec 4, 20123 notes
#iOS #iOS 6 #iPhone #iPad #iPod #iPod touch #Apple #Do Not Disturb #Calendar #iCloud
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

Dec 3, 20121 note
#iOS #iPhone #iPad #iPod #iPod touch #Apple #Security #Lock Screen #Siri

November 2012

2 posts

Nov 28, 20123 notes
#iOS #iPhone #iPod touch #iPad #Apple #Lock Screen #Actions #Dribbble
Nov 5, 20123 notes
#iOS #Facebook #iPhone #iPod touch #App #Application

October 2012

3 posts

Oct 23, 20123 notes
#AIM #Apple #IM #Instant Messenger #Mac #Macintosh #Messages #Messages for Mac #OS X #OSX #iMessage #Instant Message
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

Oct 10, 20122 notes
#App Switcher #iOS #iPad #iPhone #iPod #iPod touch #Interface #Apple #Concept
JailbreakCon Presentation

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

Oct 2, 2012
Next page →
2012 2013
  • January 5
  • February 4
  • March
  • April
  • May
  • June
  • July
  • August
  • September
  • October
  • November
  • December
2011 2012 2013
  • January 12
  • February 8
  • March 6
  • April 1
  • May
  • June 4
  • July 6
  • August 5
  • September
  • October 3
  • November 2
  • December 6
2011 2012
  • January
  • February
  • March
  • April
  • May
  • June
  • July
  • August
  • September
  • October
  • November
  • December 38