When I threw my father a surprise 50th birthday party a number of years ago, we had to scour our family to find decent pictures of his childhood, teenage, and early adult years. In the age of cheap storage and phones that double as many people’s only camera, today we have the opposite challenge of past generations: we have way too many photos.
My wife’s MacBook Air is a testament to that. Her iPhoto Library has grown to over 125 GB, causing her machine to be resource-constrained while iPhoto is open. Between the birth of our son at the start of 2012 and the advancements of the iPhone, she went from snapping around 1,000 or so photos back in all of 2010 to nearly 7,000 just through October 2013 alone.
While a second stage will be to move significantly older photos off of her hard drive, step one was to make iPhoto more manageable by reducing the overall size of her iPhoto Library. My approach was to group photos by year into multiple iPhoto libraries. Beyond speeding up iPhoto usage, this felt like a nice way to browse photos and just as importantly ensure there was no longer a single point of failure by having a single, massive iPhoto Library.
iPhoto does natively support the ability to have multiple iPhoto libraries but as usual, the simple solution is not as simple as it sounds. The main issue is that the easiest way to get photos from one library to another will cause the important metadata associated with the photos to not be maintained. That’s where Fat Cat Software’s iPhoto Library Manager comes into play. While iPhoto Library Manager does much more, what I mainly used it for was to copy photos from the default iPhoto Library into ones associated with each year.
The best part about this app, is that it actually uses iPhoto itself to do the work. After you create the library and choose the photos (and videos) to copy, iPhoto will systematically open and close in the background. Unlike the “easy way” of moving photos mentioned above, iPhoto Library Manager automagically employs the importing functions multiple times to maintain event info and other metadata of the photos. Doing this manually would take a considerable amount of time and could also introduce copying errors.
iPhoto Library Manager also has a nifty find duplicate photo feature—even across libraries—that I’m sure will be helpful at some point. And if I ever want to eliminate certain libraries, there’s also a merge function. For now, problem solved…no more fans kicking off when iPhoto is open. iPhoto Library Manager is well worth the $29.95 price tag.
Since the GoDaddy acquisition, I’ve been contemplating migrating away from MediaTemple by the end of 2013. Back at the dawn of the Internet, I used GoDaddy exclusively for domain registration. Over time, I came to dislike how much they’d try to upsell you during the checkout process. Additionally, I have not appreciated how they advertise themselves, especially during the Super Bowl. I ended business with them a number of years ago and now do all domain registration through Hover.
After some deliberation, I’ve decided to continue with MediaTemple because they will operate as independent entities. I’m also taking into consideration that MediaTemple did some due diligence on the supposed new direction of GoDaddy. If GoDaddy does clean up their act, having their resources behind MediaTemple actually does provide additional confidence in their long-term viability as a business. I realize that’s a big “if” and plan to see if this new GoDaddy is real or just marketing speak. Only time will tell.
Although I think we should try to give our apps a unique look through subtle twists on the iOS 7 design language, I’m excited to focus more on making our apps unique by experimenting with novel interaction models, transitions, and physicality, making our apps a lot more visceral.
With Apple focusing on clarity, deference, and depth for iOS 7, the new user experience and interactions models of iOS 7 apps are just as important as the new design language.
A point made by Harold Emsheimer on the companion Branch discussion highlights this further, “For now we are just focusing on the new APIs and less on the UI.” It’s an interesting approach that would likely start with incorporating elements such as UI Dynamics and then attack an iOS 7 re-design later, so as he puts, “we aren’t developing new patterns from our gut reactions.”
Unfortunately, Macworld seems to have changed some of their tests, so it’s not a full one-to-one comparison. Overall, the new fully maxed out MBA doesn’t appear to fall too far behind but I just can’t bring myself back to a non-Retina display. And that’s even considering I mostly use my rMBP docked.
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.
Unlike in 2012, this year’s Google I/O was not a distinctively Android-focused event and that’s telling: Google has realized that the key to mobile does not rest with Android itself. Google does not win mobile by competing against Apple and iOS. It wins by being Google, focusing on servicing its customers across platforms.
While there were some significant product announcements such as Google+ Hangouts—which launched on Chrome, Android, and iOS simultaneously—I’m going to highlight the interesting Android developments that caught my eye. For further details, check out Google’s wrap-up of the Android announcements on their blog.
Google Play Services
The big three here were new location services, Google+ sign-in across devices, and improvements to Google Cloud Messaging. Having worked on applications that heavily rely on location, I’m pretty excited about the low battery consumption aspect, along with the new activity monitoring that can detect movement type (e.g., walking versus running).
Making Google+ immediately more relevant as an identity provider, is the automatic sign-in to an app that’s been downloaded across your Android devices. This update is something that is extremely difficult to execute if you’re Facebook or Apple, without having to rely on one another.
On the Google Cloud Messaging side, there are some goodies for developers like upstream messaging and persistent connections. As a consumer, however, I’m looking forward to the fact that notifications are now synced across devices. Dismiss a notification on one device and that’s respected across your Android devices.
Google Play Developer Console
Thankfully, we’ve found a great localization partner in Applingua and they’ve helped us localize about a half-dozen iOS and Android apps. I believe that has definitely increased our success, which is why it’s surprising that more developers don’t take the time to localize their apps. That’s likely going to change with how easy Google’s making it to localize apps by submitting the strings file through their developer console to approved localization vendors.
I am initially concerned with this approach providing the right context to the translators, as a strings file alone won’t do that. We always give a build to Applingua and even when doing that, we sometimes have to tweak strings after a release. Provided that there is some level of interaction or quality checks involved, it’s a great addition.
Another welcomed update is the ability to do alpha and beta distribution via the console. I don’t love, however, that this seems wrapped up in Google+ itself by sharing with specific people or Circles. Hopefully it won’t be. In any case, we’ll still be using Hockey for the foreseeable future since it’s a one-stop shop for doing distribution across platforms.
One strategy mobile game developers have done for the last few years, is to initially launch an app in Canada to see how it performs, make revisions, and then tackle the U.S. market. With Google’s new “staged” rollouts, that might be a thing of the past on Android. Along with referral tracking, optimization to do’s, and the new revenue reports coming to the console, Google is finally bringing its algorithmic DNA to mobile app developers.
If you have spent any time around developers, you know they regularly complain about all and any IDEs. Thus it wasn’t surprising that my Android team members were immediately skeptical at this announcement. But within 10 seconds (literally) of Android Studio being demoed, they became very interested in it.
The verdict is still out obviously but Android Studio appears promising. Having an IDE specifically focused on Android is going to reinforce Android as a platform and at least in theory, reduce the learning curve and speed the development of Android apps. It’s a smart move by Google and the Android team.
While I have a to do app on my iPhone, I usually also have an app that lets me quickly jot down ideas, points I need to discuss with my team, and similar items that really aren’t task-driven. Historically, I’ve been using Drafts for this purpose but I’ve wanted something that was more structured yet still lightweight. Listacular may be that app.
What I like about Listacular thus far, aside from its clean design, is that it’s not overly focused on being a task manager. In particular, each entry on a list can actually just be a note or a bullet—instead of a to do—without the need to “complete” it. To accomplish that, there’s a very clever formatting toolbar to define item types, create headers to separate items, and control indentation.
I’m giving Listacular a chance in my dock. If it sounds interesting to you, check out Christine Chan’s full review on AppAdvice.