Simplicity comes in many forms.

Reducing distractions, including providing too much content or too many calls to action, helps people focus on the task at hand.

And allowing the content that is there to be seen, especially on mobile, is an important balancing act between copy, images, and screen height.

But let’s look at how Apple has taken the wrong approach to these tenets with their new mobile menu at Apple.com.

Reducing distractions

Yes, removing content from an interface simplifies it, allowing the user to focus. But if that content is vital, the choice to omit the content, even temporarily, can be more detrimental than having it on screen at all times.

Where to next?

This is especially vital on Apple’s homepage, because there are really only three links on it:

1. The menu reveal button, which is a nonsensical equals sign.
2. The apple logo, which just refreshes the page.
3. One product hero image which links through to a product you may not be interested in.

Saving space on mobile

Sure, mobile menus are often a distraction on an already too small screen, but when the header to toggle your menu is the same size as the menu itself, you’re just adding needless clicks.

Apple did make a unique choice here in opting for a horizontal, scrollable menu over a stacked menu which would have taken up the full screen. And, hey, it works, so embrace it. More on that below.

Charming interactions

You can argue that the reveal of a hidden mobile menu can benefit from a nice animation, rather than unceremoniously snapping into place. But when that animation makes your site seem unresponsive due to a long delay between the time you press the open button to the time the menu slides down, you’re just increasing the frustration level for folks who are trying to get to the information that matters to them.

Combine these things together and now you’ve created tedious work for the end user, with no benefit whatsoever.

So how can Apple address these issues?

Given Apple’s choice to go with a long horizontal menu, the simple option  would be to just always show it. This saves time, effort, and provides valuable information on a homepage which has almost no information on it, all within the same space that the current header takes up.

Here’s how this can be done quite easily:

1. Remove the equals sign.
2. Begin the menu with the Apple logo (still doubling as the Home button).
3. Make sure the menu’s spaced in a way that you hint at additional content to the right, so people understand there’s more content they can access.

Like this:

Presto: a simplified menu, half the height of the current one, with all the same content the current full-height menu sports, always showing and ready for action.

And the added benefit: now the mobile menu on Apple.com subtly reflects the menu bar on OSX.

It’s a minor change, that would make a whole world of difference, as this comparison highlights:

The post How to fix Apple’s poorly designed mobile web menu. appeared first on Say Yeah!.

While I appreciate that iOS 7.1’s update saw the shift key match the colour of the rest of the keyboard when it’s turned on (everything goes white), rather than changing to another shade of grey as in iOS 7.0, Geoff’s absolutely right that this is not clear enough for users to understand when the shift key is active.

Let’s explore this in more detail.

Android 4.4’s Current Keyboard

As Geoff pointed out, Android solves this by actually changing the keys on the keyboard. Personally, I find this practice of changing all the keys on the keyboard quite jarring. Particularly because this change happens so frequently (including every time you start a new sentence) in order to highlight the capitalized first letter of the first word before shifting to lower case for the rest of the sentence. Here’s how that shift looks every time you start a new sentence:

iOS 7’s Current Keyboard

However, it’s clear that iOS 7’s more subtle approach is not enough. Here are the current states in iOS 7.1 for lower case, shifted, and caps lock.

The iOS 7.0 keyboard, by comparison:

Neither of these is clear, and both suffer from odd choices, including the removal of the outlined arrow from iOS 7.1, and the lack of clarity between shift and caps lock in iOS 7.0. More importantly, in both cases, there’s a lot of effort required to understand whether or not that shift key is on or off.

Geoff’s Proposed Keyboard

In Geoff’s article, he worked through to this proposal, which maintains Android’s shifting keys and reverses the shading of the shift key to imply it’s a button being pressed to activate it, but still leaving out the hollow arrow for the unpressed key:

Lee’s Proposed Keyboard

I think it would be enough to retain iOS7’s three states: grey, white, and underlined white (for caps lock) along with two visual adjustments. First, some reverse shading to imply the key is pressed down (as Geoff introduced). Second, returning to the use of an outlined arrow to imply off and a filled in arrow to imply on (which is how the shift key looked on previous versions of iOS, as noted by Sean O’Sullivan).

These two visual additions would eliminate the jarring adjustment of all the keys jumping from lower case to uppercase found on Android, while keeping the more easily read all caps letter keys we know and love from our physical keyboards.

Here’s a look at the minimalist approach I’d prefer: inactive grey, with an outlined arrow vs a depressed active white shift key with a filled in black arrow.

But Matt here at Say Yeah is still not comfortable with this, instead preferring more distinction between the white active shift key and the white default keys, which are white and all caps at all times. Matt’s thoughts:

Consistency is fine (white to match the other keys), but not at the expense of clarity. By making the shift key distinctly different from the rest of the keyboard, it becomes obvious what’s happening so you don’t have to think about it.

Previous to iOS 7.1, the shift key lit up in bright blue. Something along those lines is Matt’s preference. Filip Truta agrees, stating in his article The iOS 7.1 Shift Key Is a Disaster:

iOS 6 was spot on, change wasn’t necessary

From Jason D O’Grady:

Above: In iOS 6, the Shift key is gray when disabled and blue when enabled, which is much easier to discern than with the iOS 7 keyboard.

What’s your take on how Apple should solve this notable issue?

The post iOS 7’s woefully unclear shift key and what can be done about it. appeared first on Say Yeah!.

iOS 7.1 (released today) includes a number of seemingly minor adjustments to the latest version of iOS but, overall, they mark a vastly improved iOS 7 experience.

If you’re running an older iPhone, you’ll want to download this release straightaway for the performance improvements. (Just open the Settings app, select “General”, and then “Software Update”.)

And if you have yet to upgrade from iOS 6, this release may be what you’ve been waiting for.

More Responsive

Across the board, animations are snappier. Moving from home screen to folders to launching an app now feels twice as responsive, as if the folders and apps are jumping to attention.

Improved Accessibility

And for those who were getting a little seasick with the animations the Reduce Motion accessibility now includes Weather, Messages, and more.

Complete Details

Lots more to see from Apple on the new iOS 7.1 update page, as well as the full release notes, as follows.

User Interface Refinements

A couple of examples:

1. Refined home screen spacing, with icon labels moving farther away from the icons, along with adjustments to the dots representing the number of pages and the green used for the Messages and Phone app icons. I’m including this more out of curiosity for the nearly unnoticeable subtle refinement (perhaps implemented to accommodate the Accessibility settings for increased text sizes and bold type). And please excuse me for my lack of Inbox 0, nerds.

2. Phone app updates, prioritizing the key actions with larger visual elements for Decline and Accept and better identifying each of the actions with icons and increased contrast:

CarPlay

• iOS experience designed for the car
• Simply connect your iPhone to a CarPlay enabled vehicle
• Supports Phone, Music, Maps, Messages, and 3rd-party audio apps
• Control with Siri and the car’s touchscreen, knobs, and buttons

Siri

• Manually control when Siri listens by holding down the home button while you speak and releasing it when you’re done as an alternative to letting Siri automatically notice when you stop talking
• New, more natural sounding male and female voices for Mandarin Chinese, UK English, Australian English, and Japanese

iTunes Radio

• Search field above Featured Stations to easily create stations based on your favorite artist or song
• Buy albums with the tap of a button from Now Playing
• Subscribe to iTunes Match on your iPhone, iPad, or iPod touch to enjoy iTunes Radio ad-free

Calendar

• Option to display events in month view (pictured above right)
• Country specific holidays automatically added for many countries

Accessibility

• Bold font option now includes the keyboard, calculator, and many icon glyphs
• Reduce Motion option now includes Weather, Messages, and multitasking UI animations
• New options to display button shapes, darken app colors, and reduce white point

Other

• New Camera setting to automatically enable HDR for iPhone 5s
• iCloud Keychain support in additional countries
• FaceTime call notifications are automatically cleared when you answer a call on another device
• Fixes a bug that could occasionally cause a home screen crash
• Improves Touch ID fingerprint recognition
• Improved performance for iPhone 4
• Fixes display of Mail unread badge for numbers greater than 10,000

The post iOS 7.1 is now available for iPhone, marking a significant improvement in usability. appeared first on Say Yeah!.

Mobile UI Patterns

With topics such as Check-in Screens, Empty Data Sets, Maps, and many more, Mobile UI Patterns, gives you a single row of screens to scroll through. Dig in!

Pttrns

Meanwhile, Pttrns joins the fray with a two column approach highlighting such app categories as Calendars, Friends, Messaging, and more. Take a look!

These are great quick reference tools. And I wish there was a crowd-sourced site like this. I don’t think Pinterest really supports this kind of easy sorting, but that would perhaps be the best option. Can you recommend any other sites like these?

The post Patterns in mobile app design, a series of screen comparisons. appeared first on Say Yeah!.

A couple of weeks ago, my excitement was ratcheted up a notch or two with the prospect os OSX Lion presenting us with a new unified skin for “the world’s most advanced operating system.”

For years we’ve had inconsistencies between the design and icons of the various native OSX apps, even being left with version 1.0 scrollbars in most apps, long after Apple’s aqua interface was otherwise replaced.

While OSX Lion’s introduction was relatively brief, and the screen shots on the teaser page don’t offer much (going so far as not even showing any non-fullscreen scroll bars at all), a little digging and we can find the following:

Toolbars
Mobile Me’s blue background and white icons will not be replacing the current metalic theme.

Mobile Me:

OSX Lion:

Mail
It does look like Mail will be getting a much improved, simplified icon set:

OSX Snow Leopard:

OSX Lion, from AppleInsider:

(Sorry for the blurriness, but I believe that was captured and enlarged from Apple’s keynote video.)

Scrollbars
Finally, we the keynote video also shows that scrollbars will be taking their lead from iOS. Aqua will be replaced with wispy wee scrollbars.

Interestingly, MacRumors is reporting that, “Like iOS, the scroll bars disappear when not in use, but reappear during scrolling or with mouse movement.” In other words, like iOS, if it’s not visually obvious you get to guess whether or not the page continues downward (or across) before you bother attempting to scroll. This would be a very odd decisions as it’s a bit of a nightmare for users and, at best, made sense on the iPhone due to limited screen real estate.

Of course, I’m sure we’ll see more in the months leading up to OSX Lion’s summer ‘11 release.

The post A look at the subtle UI changes that are bringing consistency to Mac OSX Lion appeared first on Say Yeah!.

When we originally built the commenting system on the old PTE (pre-Tumblr era) Say Yeah website, we required users to create an account and sign in before they could comment. This created an unnecessary barrier to entry that reduced the likelihood that a user would comment. It just took too long.

At the same time, we wanted to ensure that we weren’t dealing with moderating spam comments all the time and the account creation process pretty much eliminated this. Additionally, the same user account for commenting allowed a user to post or like an event on the TO Events Calendar, so the barrier to commenting for calendar users wasn’t as high.

With all that in mind, and to encourage the conversation by making the process less painful for users, we took a fresh look at the relationship between commenting and user accounts on the Say Yeah site. For users who weren’t using the TO Events Calendar, it was clear they had no reason to make an account unless they wanted to comment, so we worked to combine these actions.

In short, we encouraged people to create accounts by attaching the creation process to a rewarding action.

Here’s how it worked.

The initial form is just two fields, asking only for an email address and comment.

Once the user enters their email address, and progresses to start writing their comment, we do a quick look up using AJAX to see if their address is in the database.

If we find it, we welcome them back and present a password field to confirm they are in fact the user we think they are.

If the email address isn’t recognized, we note that it’s their first time commenting and ask them to select a username and password.

We also suggest a username using the first part of their email address as the name. This is probably not what people will use as their name, but it gives them an idea of what we’re looking for in a username.

The button language also changes from ‘Post’ to ‘Register & Post’ to indicate that the user is indeed creating an account with us that can be used for other purposes, such as creating events on the TO Events Calendar.

The result of the change to the commenting system was an increase in comments to articles, and subsequently an increase in user accounts.

We’ve since moved away from commenting in favour of Tumblr’s system of Likes & Reblogs, but we know this process of creating accounts during the commenting process was a valuable addition to our site, as it allowed users to sign up at a time when they’re most engaged with content on the site and made an otherwise cumbersome process as simple as possible.

Would we have had more comments if we allowed users to post a comment using just their email address? Sure. But you can be sure it would have all been spam.

The post Towards better commenting on the Web. appeared first on Say Yeah!.

After struggling mightily with a Blackberry 8900 over the weekend (seriously, almost every aspect of the OS on that thing is broken – from email to Wifi to Web browsing. What a nightmare!), it’s nice to see that Blackberry is actually attempting to improve their user experience with Blackberry 6.

While I haven’t used one yet, the videos and articles I’ve seen highlight some key improvements to how the touch interface is handled, while the larger touch screen makes viewing and interacting with the device a lot easier.

They’ve also built their browser on WebKit, the same engine that drives Apple and Android browsers and simply an indescribably better engine than whatever beastly thing they had been using previously. Granted, their new Blackberry Torch has a low resolution screen, but with Wi-Fi media synching, that’s a fair tradeoff. This is the one area where Apple needs to make some vast improvements, and I’m expecting just that with the next release of iOS.

The post Blackberry 6, better for users. appeared first on Say Yeah!.