All Posts in iphone
October 2, 2012 - Comments Off on Directions to Crazytown: How Crowdsourcing Should Have Saved Apple Maps
Unless you've been living under a clump of moss, you are undoubtedly aware that Apple supremely failed with their iOS Maps application. Judging from the all-out thermonuclear war that followed from the press, Droid devotees and occasional smartphone Luddites who clench their Blackberry like grim death – this was a long time coming. Like slobbering hyenas waiting for a magnificent antelope to stop one too many times to defecate in the jungle, everyone seems to be relishing this opportunity to eviscerate the tech giant for releasing and (some say) arrogantly replacing a vital part of any smartphone’s delicate ecosystem – the almighty mapping system. In fact, the reason this is so troubling, is that Apple, in releasing poorly rationalized software, has betrayed their brand's essence.
It makes “antenna gate” look like a rampant case of hiccups at a leper colony.
Apple brought this vitriol on themselves, by almost single-handedly ushering in the pathetic age of the “legal patent screw-fest” – where every entreprenneur who thinks they might have a brilliant idea will immediately discard it (opting rather to take a nap in their parents basement), in order to avoid the unholy wrath of lawsuit-hungry corporations.
The snark was particularly squalid in both the press and the endless comment trails from the merry tribe of Internet baboons who deem it necessary to flip every opinion piece into their own bully pulpit for personal political or technical vomit. On the corporate side, Motorola instantly added fuel to the fire by commandeering the #iLost hashtag quicker than a beard grows in Williamsburg. Samsung has commercials poking fun at people waiting in endless iPhone lines as a response to Apple reportedly penning an internal ad poking fun at an apology requested in a UK court over a Samsung verdict. Screw all of these corporate knuckleheads – it reeks like a public tiff over Bieber tickets between the rich high school cheerleaders that everyone hates yet desperately wants to date. The intended audience this bile is aimed towards will soon move past all of the silliness. To teach the corporate executives approving this creative pap a lesson, shareholders should be cashing in their stock. In the end, innovation is the new loser, not a person buying a gadget.
While I’m not forgiving Apple for their transgressions, if a particular CEO was still alive, one could postulate that the Maps disaster might not have even happened. This major mistake occurred under the watch of a supply watchdog, not a creative visionary. Mr. Cook and many others who didn't program the application would have likely been burned at the stake on YouTube live in Cupertino if this had transpired under the watch of that turtlenecked angel in black, Steve Jobs.
TomTom (one of the companies that Apple uses for the maps portion of the Maps app) had already been publicly humiliated (Google search “blame TomTom” and see what comes up). Everyone from the CEO of Waze to the entire country of China is having a field day with this company right now. TomTom has fired back, understanding that their 20 years of respect in the business will likely be questioned because of the Maps fiasco, noted the fact that Apple is using data from at least 2 dozen other partners.
They should have released this new piece of software alongside Google Maps and challenged their devotees to make it better than Google.
Aside from arrogantly pushing a fully unfinished and untested product to the masses, Apple made a seriously shortsighted and future backwards error. They should have released this new piece of software alongside Google Maps and challenged their devotees to make it better than Google. We've all heard the spin: There was a month left on some corporate contracts between them, and yes, the word on the street is that everything fell apart because of Google's refusal to integrate turn-by-turn directions, but in the end the Maps application should have focused heavily on crowdsourcing out of the gate. The interface of the application should have made it overwhelmingly simple for the audience to correct mistakes in maps. Apple could have spent some of the zillions that Jobs said he would use to destroy Google and really buried them by empowering their users to make the Maps application a truly socially aware product (or at least feel part of the experience by building reputation capital through linking the geo-coding aspect of their photo libraries, commenting or at least connecting with other map users like Waze does). And please don’t tell me that crowdsourcing Maps was always the plan, because the suggestion box is currently buried in dark gray on the interior screen of the Maps application. My guess is, if Apple doesn’t just eventually shelf the entire app (like Ping, a coincidentally excessive and uninformed social media failure from Apple), and it's shareholders don't force Cook himself to crawl on his hands and knees to Google’s office begging them to build an Apple Maps app (spoiler: Google says they refuse), the next release's interface should focus heavily on a crowdsourcing component.
The only trouble is crowdsourcing takes time and interest from the audience to reach an increasing level of perfection - both which were lost on this highly touted app's speed to market. Launching a lousy app was stupid. Replacing Google Maps with this "not-ready-for-prime-time app" is reprehensible.
Unfortunately, it’s likely too late. In fact, people may look back at Apple in a couple years and point to this moment (much like a certain presidential candidate), as the time when due to arrogance or sheer stupidity - shit went south. I don’t doubt that Apple might be able to recover, but I don’t think that they have a big and vicious enough honey badger running the company anymore to savagely beat the entire planet into willing submission. The bad vibes, not the press, are enough to begin pushing a small percentage of Apple’s globally small, but passionate mobile user base toward what is finally becoming an excellent alternative OS by virtue of customization alone. And since Apple has staked it’s entire future on the inevitable mobility of computers, and not the desktop computing machines that drove a stake into Microsoft’s dominance, this is a very, very... very catastrophic event.
The problem with Android phones is that the OS resides on inferior components. Apple’s advantage remains that the device’s quality is married to the OS. Apple used to preach this in their branding - the sexy machine married to the equally sexy interface. Now they supremely screwed that pooch, and I fear that they will not fully recover.
Word to the wise: Never, ever, ever betray your beloved brand essence. Especially when the road back to the top has a stream of venom waiting for you - flowing right down the center.
We recently underwent the process of making our site mobile and tablet friendly. The results look fantastic but our implementation has, in places, been a bit cumbersome since the original site was not laid out with such an adaptation in mind. Now that we're more or less done I felt it would be pertinent to create a list or useful resources found and lessons learned along the way. Since this entire branch of web development is still so young and liquid I don't know how long the following will be useful but I hope it helps those as lost as I was when we began this trek.
Adapt or Leave?
One of the biggest questions when faced with the prospect of creating a mobile site is "Should my site adapt or redirect?" Unfortunately I don't believe there is one right answer to such a question since, like so much in life, it depends!
Some key factors that might affect our decision include the functionality we want, type of content we mean to serve and look/feel of our design. Is it important that our mobile version have stunningly different design and/or app-like animation effects? Then a redirect is probably in order. Are we mainly trying to provide a mobile version of a news, blog or other site where content is the focus? Then a media query adaptation would be beneficial as we make it easier for users to share content between devices (and keep all that traffic in one place to boot). However both options can be adapted either way if we put in enough work.
Let's not forget the last option: making a web app. Using services like PhoneGap we can take a our HTML and make it into a bonafide app on the user's device...well it's really just a virtualized webpage with greater device integration (accelerometer, media, camera, etc.) and a dedicated icon on the device but sometimes that can be a great branding edge. And there's the added bonus that users can then use our "site" even when not connected to the internet though the line between website and app begins to blur at this point. A direct migration of your website to an app will probably never clear the iTunes store's strict approval process so we need to add something unique which may be more trouble than its worth.
Let Me Pose You a Query Sir
Media Queries: confusing, under-documented, cutting-edge, useful as all hell and bloody confusing! It took me awhile to get my head around these little statements of goodness. Once I did I came to understand their power and structure. We have two main options when dealing with media queries; we can use them to specify certain CSS links or alternatively we can write them into an existing CSS file. Personally I used a mix. It made sense to use the internal CSS version when altering this blog's WordPress theme while on the other hand the link option made sense for most other pages. In general I'd recommend the linking option since it keeps each CSS shorter, allows for easier document navigation and generally keeps our process cleaner.
It's easiest to think of media queries as giant "If" statements that inject our extra CSS when our given properties are met. As such, we must remember to override existing styles in order to apply our new device-friendly ones. It can be tedious searching through our original CSS file to see which specific properties need to be overwritten. I found it easiest to simply copy the entire original CSS, do all changes as required and then go through and delete any definitions or properties that remained constant (I sniff an extremely useful code highlighting/SVN tool that could do this comparison automatically along the liens of CSSlint).
Another nice benefit of media queries is the ease of testing and updating them. During the development process, make sure to specify "max/min-width/height" AND "max/min-device-width/height." This will ensure that our queries appear not only devices with the specified resolution but also any similar window viewport allowing us to use Firebug/Chrome Inspector as we normally do for a familiar debug cycle as well as useful previewing tools like Protofluid. Just remember that once the site is live, we should only target devices if we don't want adaptive versions appearing on desktop browser windows of the required size as was our case since the mobile versions or so device specific.
Don't forget this is a completely new ballgame. Using media queries, especially with mobile devices, we can add all sorts of fun and/or hidden functionality into a site. How about a site that literally changes personality the smaller the window? Maybe you have a logo or character that actually reacts to the changing amount of space they're given as elements shift about them? And don't be afraid to think even more radically. The very function of a page could alter depending on a devices orientation. We could have our copy appear in portrait and then an image gallery appear in landscape (as is the case for our iPad site). Such novel use of media queries can completely redefine how people interact with a site and help redraw the front lines of the ongoing war between app and webpage.
Of course not all the changes that come out of these new device are solely good. In fact the biggest one requires a fundamental change in how we think about design and interaction: touch. No cursor means no hover. Truly though, hover is simply an artifact of the invention of the mouse, itself not very old and clearly diminishing in importance. There's now a new frontier of interaction and design patterns to be explored.
Here though, the waters are still quite murky. Some plugins, like this jQTouch one, allow a webpage to respond to touch-specific events that most browsers and libraries don't yet natively handle. Of course this comes with the down side that we also lose our native touch-to-scroll ability (though theoretically we could reconstitute this functionality by hand or via work-arounds). For sites designed specifically for small screen devices this opens up many new possibilities that before only existed natively in apps and not on the browser.
One clear limitation we have on mobile devices is the lack of real estate. Design is all about creating something to fit within certain restrictions which are quite tight in this case. However good design often comes out of such challenges so the news isn't all bad. Sadly problems arise since lack of space also reduces our margin of error. When designing a website for the browser, we can safely assume that most screens will fit a design of a specific minimum height and width with room to spare or allow the user to easily scroll about the page to see everything.
Alas the fragmented nature of the mobile market, even if we disregard tablets, poses greater challenges since different devices not only have a wide range of sizes and screen ratios but also numerous different abilities and native elements. As such we must be dead certain that our site is adaptive to many heights, widths and especially devices. Yet by in large the best mobile sites are designed to fill the screen perfectly so making adaptive designs can be difficult to impossible. Perhaps this is where "good enough" is fine since the prospect of specifying designs for each resolution is daunting to say the least. Furthermore, we can try and maximize our real estate by hiding browser elements when possible. For instance many mobile sites "hide" the address bar on mobile Safari by programmatically scrolling the page down by the bar's height giving us more space above the fold.
If It Ain't Fixed
We've grown used to a lot of functionality on the web but many of these norms may not have been carried over to the mobile world, at least not yet. Some APIs may not yet have native support for our platform of choice but we can, on occasion, find workarounds like this one for the Google plusone button. However, sooner or later we have to simply cut functionality from our mobile site and sometimes this may be for the best considering the restrictions and problems discussed so far. So if you're wasting time trying to get a certain resource to function on your mobile site when you could be perfecting the design itself or, better yet, device testing, consider simply hiding that element or simplifying the functionality. After all, even if you get it to work it's only a matter of time until official support rolls out and your work's left out in the cold.
- Smashing Magazine Intro Tutorial
- Less useful Adobe Tutorial but with great list of possible properties
- ProtoFluid is a great way to test out your Media Queries. It essentially creates a iFrame of a given URL with dimensions specified by the chosen device. I found it to be a bit unstable and often designs look different on the actual device. There is also the lack of scroll/touch, the persistence of hover states and other Desktop-Device hybrid funniness but its great for checking your initial layout. BE SURE TO TEST ON DEVICES AS WELL!!! (Note: since Protofluid works via Desktop browser, make sure all your queries specify "width" and "device-width" as outlined above)
- Hide address bar in iOS mobile Safari
- Google+ plusone mobile button fix
I know Apple is quite restrictive about information, but I was a bit surprised to see how far the non-disclosure agreement (NDA) for the iPhone SDK goes: iPhone developers are legally banned from sharing programming tips, discussing code or asking questions of one another in forums or over e-mail!
"F**KING NDA" has become a mantra on Twitter. Every time a developer posts about his or her latest run-in with the metaphorical brick wall that is Apple's NDA, the capitalized expletive is sounded off. "F**KING NDA" has become such a phenomenon, a website has sprung up at F**kingNDA.com to track the twisted tweets.
Apple's software development kit (SDK) for the iPhone is the primary set of tools for building apps for the iPhone, especially if the creations are to be included for sale in the device's App Store. The NDA, which must be agreed to before the SDK can be downloaded, prevents programmers from discussing the finer points of their code.
"There is no legal way for developers to talk about they are developing," Williams laments. "No way to post tutorials. No way to give code away. It's hard to interact with other developers and to write code without reinventing the wheel. Normally, you could post [a coding question] on Twitter and get an answer within minutes."
More info on why the iPhone NDA is no good:
From Ask E.T.:
The iPhone platform elegantly solves the design problem of small screens by greatly intensifying the information resolution of each displayed page. Small screens, as on traditional cell phones, show very little information per screen, which in turn leads to deep hierarchies of stacked-up thin information—too often leaving users with "Where am I?" puzzles. Better to have users looking over material adjacent in space rather than stacked in time.
To do so requires increasing the information resolution of the screen by the hardware (higher resolution screens) and by screen design (eliminating screen-hogging computer administrative debris, and distributing information adjacent in space).
This video shows some of the resolution-enhancing methods of the iPhone, along with a few places for improvements in resolution.
Read the rest of Tufte's thought's and view the video here.
Thanks for sending this to us, Aline!