Josef Albers's Interaction of Color is a masterwork in twentieth-century art education. Conceived as a handbook and teaching aid for artists, instructors, and students, this timeless book presents Albers's unique ideas of color experimentation in a way that is valuable to specialists as well as to a larger audience. Originally published by Yale University Press in 1963 as a limited silkscreen edition with 150 color plates, Interaction of Color first appeared in paperback in 1971, featuring ten representative color studies chosen by Albers. The paperback has remained in print ever since and remains one of the most influential resources on color for countless readers. It has now become available as a fantastic iPad app.
All Posts in ipad
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
Apple unveiled the mighty iPad last week after a targeted carpet bombing of pre-event hoopla, far too many misfired “leaks” and eventual lukewarm excitement. Of course, the people who were unable to devise the device immediately went to work, spending unnecessary time and brain cells shouting from their favorite mountaintop called Twitter, making fun of the name and comparing it to lady stuff...
Geeks are funny creatures. If this device was called an "iTab" they probably would have made soft drink jokes - All that talent and occasional genius is sadly wasted on a single, albeit funny observation instead of trying to figure out some undocumented and innovative uses for the thing. Trust me, as soon as someone starts waving real development cash at the naysayers, they'll be singing the praises of the “innovative” and even “magical” iPad; salivating to build apps quicker than you can bark the word “Pavlov”...
For those who are interested in actually using the device, it really doesn't matter what the thing is called - as much as what it can and cannot do.
The iPad has a couple well-documented drawbacks:
- iPad doesn’t do Flash (more about that later). This means no Hulu, YouTube or other currently Flash-enabled video sites for you on the iPad Safari Web browser...
- iPad doesn't multitask, so you can't listen to music while penning your brilliant blog post, notes or novel. This is a “deal breaker” for the countless hordes who apparently planned to brutally smash their trusty old iPod on the way out of the Apple store with their iPad. The truth is, people have grown accustomed to hoofing around several devices in their backpacks, shoulder bags and/or pockets. Despite our Utopian dream of "one device to do it all," as technology changes and new things are devised to keep us from having actual conversations with other live humans, there will always be another “thing” to stuff into our ever expanding satchels o’ plenty.
The iPad's strength isn't that it plays music, movies, games or that it surfs the Flash-less Web. The iPad gets it's real mojo as a comfortably-sized, compact and usable device that doesn't require an attached keyboard, a mouse or a constant power source to input notes, data or, more importantly, read published materials. Everything else it comes loaded with, simply helps to justify the price point. The iPad could really show true muscle for students, teachers and classrooms and by eventually saving and/or enhancing the suffering magazine publishing business. But to do this effectively, Apple needs to cozy up to college kids to make the iPad truly a thing of “magic”.
So, while we're waiting for the iPad to do a keg stand at a college dorm near you, here are some things that Apple and it's partners should concentrate on to help the iPad live up to it's promise:
- Create an exclusive network for students. College textbooks should be available via a subscription service on the iTunes store so you can burn those oversized, overweight, overpriced books like Guy Montag and plant some trees. As a specific textbook’s information is enhanced or corrected, it should automatically be updated, just like your iPhone/iPod currently informs you when a purchased application has been updated. Software developers for the iPad should focus on applications that will make lecture note taking and sharing, as well as commenting on digital textbooks simpler. Imagine downloading a textbook for your class and having the benefit of seeing the best notes from a global network of past students. To avoid reading irrelevant notes, a system could be put into place allowing students to rate other students notes, making only the useful stuff rise to the top.
- Expand the iTunes store to include magazine and newspaper subscriptions asap. Save that dying, ink-laden, forest-chomping horse as fast as you can. Obviously publications will need to embrace HTML 5 for any video content, so start brushing up, if you're planning on developing for a future publishing industry.
- Allow musicians to plug in. With GarageBand already part of iLife, in the future I hope to see musicians with guitars, iPads and a dream sprawling out in Prospect Park writing tons of crap they can sell to their relatives on iTunes with the help of TuneCore.
- Advancement and advocation of the HTML 5 specification. Apple has been very clear: they refuse to get into bed with Flash. They view Flash as an uncontrollable source of application crashes - not to mention a bandwidth and processing hog - and as a designer and developer who has worked with Flash, they are partially correct. Many of Flash's novice developers know only a little about the scripts and techniques required to deliver the most processor-efficient experiences. ActionScript, the scripting language behind Flash has been massively changed and enhanced over the years, leaving the true Flash programming to true programming wizards who have worked with it since the introduction of ActionScript 1.0 with Flash 5 in 2000. The future promise of HTML 5 has begun to make the use of Flash increasingly irrelevant and unnecessary for simple video and audio players. Even Hulu will come around as well if first the audience - and eventually their advertisers request it. This prospect of course, sours the folks at Adobe. They will run myriad ads over the next couple months attempting to convince the masses of the perceived inferiority of the iPad because it doesn't have Flash. But it's really just fear.
- Shhh...the word on the street is that the iPad may have a camera. In fact, the Software Developer Kit (SDK) for the iPad currently has "Take a Photo" as a programmable menu item, so maybe the dream of video conferencing or even augmented reality with the iPad will come true (or not)...or some Mountain Dew-gorged developer at Apple has just gotten a “mouthful of fist” from Steve Jobs because they forgot to remove the "take a picture" menu item from the iPad SDK...
Apple has a history of using current devices to test out and eventually surpass the last one. Look at the history of advances that have been made to the iPod since it came out in 2001. I’ve got 4 of them, each with enhanced features.
Just like the iPhone was a jacked up phone with a serious music player and a savvy integration into a robust online store, the iPad jacks things up further, but in a slightly different direction. Who wants to seriously read books or watch movies on your iPod or iPhone? You can right now, you know. They've been testing out the iPod and iPhone as an eBook reader and video player to lead us like slobbering zombies to the iPad. Whether the vast Apple audience realize it or not, we support their innovations by historically testing them and upgrading our devices to the next big thing.
Regardless, is the amount of chattering, twittering and blogging out there an indication of how quickly the masses will line up for a shiny new iPad?...