After a year of no news, Apple as re-announced it’s in-car iOS integration system CarPlay
I have to be honest, as a full on diehard raging Apple fanboy, the availability of such features will greatly influence my next car buying decision. However…
In what seems like a huge marketing oversight, neither Apple nor any of the car manufacturers have mentioned any of the primary use case(s) of what iOS integration could potentially offer:
- Real-time push notifications for traffic alerts
- Real-time alerts for family members. The car sends an alert to your loved ones letting them know that you’re on your way and how long ’til you get there
- iOS integration with on-board sensors (Low gas, low tire-pressure, check engine, etc.)
Maps, Messages, and Music? I can already do that…except for the texting part of course. I’ve NEVER texted while driving *looks down and to the left*
All CarPlay is doing (so far) is to give me an easier way to access that information through the car’s dashboard. That’s really cool and all, but it doesn’t address any problems in the context of my everyday driving experience. Here’s hoping there’s more to come.
Purchasing Haibits of late iOS adopters
Some interesting data from David Smith
The recent hype surrounding the re-design of iOS has gotten me thinking a lot about the current state of UI/UX/HIC (give it a name) and its direction in the future.
For starters, let me quickly remind all the trolls out there that when Mac OS X was released, many (if not most) of the designers hated it. The iPad, when it was initially released, was resolutely bashed by most as “an oversized iPod”. Time and and ultimately, the market, will determine whether iOS7 was a success. Let’s just leave it at that.
Back To The Future
Looking at the progression from iOS6 to iOS7 I can’t help but think back to a great presentation given by Josh Clark two years ago:
Buttons are a Hack: The New Rules of Designing for Touch
It’s a fairly lengthy presentation but the two key points that stuck out in my mind were:
Touch interactions will help us sweep away buttons and a lot of existing interface chrome by moving us closer to the content and away from GUI abstractions.
User interfaces are an illusion. But with touch interfaces we can cut through the illusion and let people interact directly with content.
If you agree with these points, and Clark’s motif in general, then you would have to agree that iOS7 is a step forward and not a step backwards. There are certainly a number of things that could have been done better, but in my opinion I think Jonny Ive is moving us in the right direction.
Please don’t misunderstand me, there are problems with the new design of iOS. For example, the new concept of a “borderless” button and using color to indicate action is somewhat ambiguous – in my opinion. In a world where buttons have no borders, the cognitive load is increased by virtue of the fact that a user cannot reasonably determine all the touch targets on a screen simply by looking at them. For example
Take this QUIZ
If you had to think about your answer, there’s already a problem. So there are issues, but isn’t that the gap designers and developers are supposed to fill for our end users? Cheers!
A good starter’s guide to designing for iOS.
I must have missed the memo, but if you’ve registered your iOS device for development (in XCode), you have the ability to simulate network conditions right on your device.
In case you’re not subscribed to the Apple iOS developer RSS feed you may not have heard – or were never aware – that 1) Apple allows you to provide “short links” to your apps in the App Store and 2) the base URL for short links is now AppStore.com
To create an App Store Short Link, apply the following rules to your company or app name:
- Remove all whitespace
- Convert all characters to lower-case
- Remove all copyright (©), trademark (™) and registered mark (®) symbols
- Replace ampersands (“&”) with “and”
- Remove punctuation
- Replace accented and other “decorated” characters (ü, å, etc.) with their elemental character (u, a, etc.)
Like young children — developers seldom remember to pick up after themselves when finishing a project. And while you might think that it’s not a big deal, you’d be wrong. As a developer leaving calls to NSLog() in your ‘Release’ code can significantly affect the performance of your iOS app.
Suppose that you’re developing an iOS app with a UIScrollView or UITableView. And within the scrollview’s delegate you place an NSLog() statement in the ‘scrollViewDidScroll’ method. This means that for every frame you have additional and unnecessary function calls which in turn consume CPU cycles.
Of course, no one likes cleaning up after themselves. So a quick and easy way to disable the NSLog calls in the ‘Release’ code is to define a wrapper macro for logging. What I do is define the following in my project’s .pch file
#define DebugLog(…) NSLog(@“%s (%d) %@”, __PRETTY_FUNCTION__, __LINE__, [NSString stringWithFormat:__VA_ARGS__])