Posts tagged "apple"
To write that the 2013 WWDC keynote was monumental would be an understatement. From the changing of the OS X big cat naming convention to the complete redesign of iOS with iOS 7, it was a significant day for Cupertino.
What surprised me most compared to last year, is that while OS X Mountain Lion was all about unifying Apple’s desktop and mobile platforms (e.g., bringing Reminders and Notes to the Mac), iOS 7 widens the gap considerably. iOS 7 is indeed the “fertile ground” as Marco Arment writes. It’s again a brave new world for designers and developers.
Meanwhile, from a design standpoint, OS X Mavericks will seem out of place and maybe even old or outdated relative to its iOS 7 counterpart. Arguably, it could have been better for Apple to introduce its new design language across iOS and OS X at the same time. OS X Mavericks is an extremely solid update but from tabs on the Finder to tags, it’s an iterative update and not the paradigm shift iOS 7 is. Looking at the developer preview of Xcode 5, however, it’s clear OS X will see a similar overhaul in the not so distant future.
It’s hard to not compare iOS 7’s buttonless, typography-driven interface to what Microsoft introduced with Metro two years ago (see Chris Millr’s observations). Similarly, Google’s iOS apps in particular have been much flatter over the last year. Apple often is a tastemaker and leader in driving design trends but iOS 7 seems more like the first iPod than the first iPhone: it’s an Apple-take on an existing trend, not an Apple innovation. That’s not a dig on Apple, it’s more a compliment to Microsoft and Google.
I’d like to believe that what we’ve seen and experienced in iOS 7 will be different than what consumers install on their iOS devices later this year. That’s not because of the bugs expected in beta software but rather that iOS 7 does not look or feel worthy of Apple quite yet. To that end, I found Frank Chimero’s words comforting when he wrote that iOS, “lacks nuance, but has courage” and that he’s hopeful for its future. I’m not confident that iOS 7 itself will have that nuance because once Apple unveils something, they usually only iterate on it after it goes to the market. That could mean the nuance returns in iOS 8 and I’m certain that Apple would be fine with that.
The analysts have stated that Apple has lost its ability to innovate. Anecdotally, I hear comments from friends and family that the iPhone is no longer new or cool, with regular questions about whether to buy an iPhone or a Samsung device. So, whether your initial reactions to iOS 7 are of love, hate, or indifference, iOS 7 is exactly what Apple needs right now. It’s exactly what iOS designers and developers need right now. And it’s exactly the kind of change only Apple is insightful and bold enough to both recognize and make. It’s time for a change.
A sensational title on BGR that is a testament to a single reality: games are the most popular apps on mobile platforms. More specifically, games continue to thrive under the freemium model. So, it’s no wonder that the highest grossing charts are filled with free game apps.
The good news is that to survive on the App Store (or in app stores in general), it’s not necessary to be on the overall top grossing chart. And at least to this point, the freemium model is largely unproven in the non-game market. Thus, a better title would have been,
Paid Game Apps Are History
SNL writers have cracked the inner geek circles with this one.
One of my biggest gripes with Mac OS X Lion was the elimination of Spaces. Specifically, I wrote about how I was a big fan of using a 3×3 Spaces layout because it allowed me to use keyboard shortcuts to quickly switch between each Space. For example, I would place my browser in Space 1, mail client in Space 4, and common work-related tasks in Space 2, which let me switch up, down, and right between my most used apps. When in Space 1, that would allow me to switch between two workspaces easily (compared to one in Lion). If I was on Space 2, however, I could switch between three workspaces just as quickly (compared to two in Lion).
With Lion, Apple moved into the Desktop era powered by Mission Control, where each Desktop is aligned horizontally next to the previous one (see above). This required a pretty fundamental shift in how I organized my workspaces but more so, in terms of how I’d navigate between them. Where Spaces allowed me to be keyboard-driven, with Lion I’ve become almost exclusively reliant on my Magic Mouse or Trackpad. Primarily, I now click the application I want to go to via my Dock, which brings me to the corresponding Desktop where it resides (all my applications are assigned to a Desktop). The second means is Mission Control, where I use Hot Corners via a drag to the bottom left Screen Corner and then click on the desired Desktop. Even with Mission Control keyboard shortcuts, I’ve found these two means to be the fastest way to get from Desktops that are multiple workspaces away from each other.
Thankfully, I’m welcoming Spaces to Lion starting today due to a great new app called ReSpaceApp (thanks, Lifehacker). Currently in beta, ReSpaceApp brings Spaces back to Lion, mapping Desktops to the grid layout allowed in Spaces. In my case, I had six Desktops, so ReSpaceApp allowed me to create my 3×3 grid Space configuration again. ReSpaceApp also has a handful of preferences beyond layout, including keyboard shortcuts, transition type (if you’re daring, try something other than the traditional “Slide”), and transition speed.
To no fault of ReSpaceApp I did have to reassign all of my applications to different Desktops because of the fundamental differences between Desktops and Spaces. So, for example, my Desktop 2 mapped to Space 4, Desktop 3 mapped to Space 2, etc. There’s still some muscle memory leftover from the Spaces days but the most difficult part of using ReSpaceApp right now is that remapping and seeing a different Desktop ordering in Mission Control than I’ve been used to the last eight months or so (again, not its fault). Perhaps, in a couple of weeks, I’ll once again forget about Mission Control for switching Desktops and be back to zipping through Deskto…Spaces with my keyboard shortcuts. For that, ReSpaceApp is a welcome addition to my app arsenal.
Back when Facebook first hit the iPhone in August 2007, it introduced the “dashboard” layout pattern to iOS. Many applauded the dashboard as a fresh take against the standard tab bar and a number of apps began following this pattern. Over time though, it proved to be a frustrating way of navigating because it requires the user to leave their current state to get to another part of the application. Additionally, it required paging the navigation as it grew, meaning additional gestures were needed before an item could be selected. The dashboard is largely extinct for iOS now but unfortunately, this pattern has become entrenched in Android.
With the launch of Facebook for iPad, Facebook has again introduced a new mobile pattern for navigation and this time they’ve created something simpler and more elegant: slide-out navigation. More significantly, this pattern has quickly gained traction and is now being used by more than several notable iOS apps.
On its blog, Facebook described its new navigation pattern—available on Facebook for iPad, as well as Facebook for iPhone 4.x—as “left-hand navigation.” I’ve chosen “slide-out” navigation because it is more descriptive and universal (e.g., Path includes it on the left and right side). I’m defining slide-out navigation as follows:
Slide-out navigation consists of a panel that “slides out” from underneath the left or the right of the main content area, revealing a vertically independent scroll view that serves as the primary navigation for the application.
Up to this point, the slide-out navigations available in the App Store have typically consisted of a panel (menu) that groups related views together, breaking them apart through headers. The default views provided by the application have been placed at the top of the panel. Facebook’s headers include Favorites, Apps, Pages, Lists, and a non-labeled help area.
Facebook implemented its slide-out nav via a list button, with the left panel always snapping out to a single, fully extended position. Once the left panel is visible, it can be closed by either tapping the list button, by touching the mostly hidden main content area, or by swiping that area left. For that final closing action, any swipe left—even if it’s very minor (i.e., a flick)—will close the panel. These nuances are important, as the other implementations are observed.
Gmail for iOS was the next app to implement a slide-out navigation. Considering it launched several weeks after Facebook for iPad came out, it’s not clear how much Facebook actually influenced it. Its main functionality is the same but it does have several distinctions. The first is that instead of a list button, it uses a back button labeled with “Menu.” In my opinion, that is the biggest eyesore with Gmail for iOS. Secondly, it’s possible to swipe or drag right on the main content area to open the left panel. And finally, the left panel can expand or contract to a minimum and maximum size respectively.
Path 2.0 is one of the most innovative iPhone apps to hit the App Store in some time. With all it’s flourishes, transition animations, and polish, it clearly received a lot of love and attention on even the smallest details. It’s slide-out navigation closely resembles Facebook’s, with a list button being used. But unlike Facebook, they include a swipe right gesture to see the left panel, similar to Gmail for iOS. They don’t, however, allow left panel resizing.
One minor annoyance regarding their slide-out nav is that the main content area and the list button actually don’t provide the minimum tappable target sizes suggested by Apple when in its expanded position. As far as I can tell, they’re roughly 40 pixels instead of the suggested 44 pixels. Beyond being slightly less gesture-friendly, the byproduct is that the list button is also partially cutoff.
My final comment regarding Path is that it’s arguable whether it really requires a slide-out navigation at all. Generally, it’s more useful when there are many content views, especially ones that can grow dynamically, as is in the case with Facebook and Gmail (e.g., Gmail labels).
The Authentic Jobs app was featured by Apple back in early December 2011 and its version of a slide-out navigation is probably one reason why. Technically, it doesn’t fit the definition above, but it’s effectively providing the same user experience.
Authentic Jobs uses an item button in place of the list but more significantly, does not slide the view when that item button is tapped. Instead, it provides a popover-like view with a vertically scrollable list.
Astrid is another iPhone app that opts for using an item over the list button but it then follows Facebook’s slide-out interaction pattern exactly.
These patterns help formulate how to properly implement a slide-out navigation. Should it be a navigation scheme implemented in your iOS app, there is some leeway and flexibility available, as shown with these examples. But, there are at least four best practices that should be followed:
Slide-out navigation is best served in content-related apps, especially when there are many views that can grow dynamically.
Use a list or item button to trigger the panel or popover (i.e., not a back button like in Gmail for iOS).
When the navigation panel is in the expanded state, ensure the minimum width of the mostly hidden main content area consists of at least a 44 pixel wide tap target size (i.e., not like Path).
Keep the opening and closing gestures for the slide-out navigation consistent with these observed patterns; snapping the panel closed versus making the panel resizable is winning the day, at least for now.