Image Height == Image Importance

Our design employed a ~3:1 hero image with three ~4:3 thumbs below it. At full width it posessed the proper hierarchy: Biggest == Most Important. However, when resized and folded into a single column, the 3:1 image appears to be about ½ the height of the 4:3 images below it.

Narrow your browser width to see the visual hierarchy breakdown:

View “BEFORE” on JSBin

Pretty unacceptable to lose hierarchy on such a major feature of the site – especially when e-commerce and products are involved. We had to come up with a solution.

Uncle Dave’s Squeeze n’ Crop Method

We wanted stop the image from scaling once it reached a certain height. Here’s what we did:

<div class="banner-item">
<!-- Using a 2:1 image because the cat picture is better :) -->
    <img src="http://placekitten.com/1200/600" />
</div>

First wrap the image in a DIV, this will act as an image-mask of sorts. Then apply some min-height + max-heightheight + overflow: hidden magic to lock the image and hide the overflow:

.banner-item {
  overflow: hidden;
  min-height: 300px; /* 300px is arbitrary. */
}
.banner-item img {
  width: 100%;
}

/* 600px is about the width "locked in" at */
@media screen and (max-width: 700px) {
  .banner-item img {
    width: auto;
    max-width: none;
    height: 300px;
  }
}

The image hugs the left of the wrapper. Auto-cropping is never perfect, but if you want to adjust the focal point of the image, you can do that with position:relative:

/* OPTIONAL: Use to shift left as necessary */
@media screen and (max-width: 480px) {
  .banner-item img {
   position: relative;
   left: -40%
  }
}

Results

View “AFTER” on JSBin

There’s a lot of playing around with what “feels good”. Adjust the breakpoint of your media query to where it feels like your image locks-in to the desired height. There might be some “Math” [/quotehands] based off of a conch shell that can help you with this, but I just go with my gut.

Good luck and let us know if you use this technique and/or can make it better.

I’d pay well for a video service that made embedding fluid/responsive videos the right way easy. It’s way more difficult that you’d think.

August 31, 2011 12:35 pm via Twitter for MacReplyRetweetFavorite

@TrentWalton

Trent Walton

Trent is right. It’s deceptively difficult to make videos fluid and responsive. I almost lost all my hair getting it to work on Do Lectures. On one hand, the HTML5 video element is super easy to make responsive: video { max-width: 100%; height: auto; }. On the other hand, if you want to do something basic like embed a video from YouTube or Vimeo (that has a flash fallback) you can set the width: 100%; but the height stays the same breaking the aspect ratio… until now.

After some interstate brainstorming and coding with Chris Coyier, we came up with a solution. Mr. Walton, we’re here for our check.

Introducing FitVids

FitVids is a lightweight, easy-to-use jQuery plugin for fluid width video embeds. It currently supports the major video vendors: YouTube, Vimeo, Blip.tv, and a couple outliers.

How it works

The plugin is based on Chris’ pre-exising work on fluid videos and the Intrinsic Ratio method suggested by Thierry Koblentz (ALA #284). With these gems of knowledge combined with my ability to only make tiny jQuery plugins, getting your videos do aspect ratio-based resizing is now as easy as targeting your .container, .post, etc. with FitVids.

$("#thing-with-videos").fitVids();

It’s that easy! Best part, there’s very little Javascript happening. After the initial setup, it’s all percentage based resizing with just CSS.

You can fork it on Github to dig in deeper into how it works. We’d love your feedback.

FitVids happily joins the Paravel family of easy-to-use tools for radical web: Lettering.js and FitText. If you use FitVids or any of these plugins on a something, let us know! We love to seeing this stuff in action.

Updates: Plugins and Modules

Absolutely amazed that people are taking this and running with it. Thanks, y’all.

• FitVids WordPress Plugin by Kevin Dees
• FitVids Drupal Module by Derek Ahmedzai

Also, we’ve made some updates to FitVids and you can add your own custom video vendors and test out other players. If this interests you, read more here.

The Buildout

The site itself is a simple 3 column responsive gallery with a few special ingredients:

• Foldy960, our homegrown not-a-framework, for the responsive base of the site. It’s lightweight and great for customization.
• FitText for some subtle title resizing.
• Blueberry, a responsive image slider. I was sad my trusty jQuery.cycle doesn’t work on fluid images, but I’m glad I found Blueberry. Highly Recommend++!!

For the homepage feature we settled on a sliding background image that correlates your browser’s window width, even though we weren’t sure it was possible. After building a quick prototype to test that interaction, it was easier than we thought. Then it was simply a matter of applying the final copy, textures, and images.

As we were wrapping up, MIX’s Nishant Kothary asked us if we’d be interested in making a sample app for launch day…

Introducing Colorrrs

Colorrrs is 7,085 bytes (zipped) of random inspiration. We decided to isolate Dribbble’s awesome Browse By Color feature, make it ajaxy, and add a “Random” button for funsies. The heart of the app is a simple YQL query to get data from Dribbble, then some jQuery to stitch it all together.

I’m finding Colorrrs to be a great way to explore Dribbble. I’ve been exposed to some sweet shots way outside the range of my daily browsing habits – and I enjoy that.

Coming up with a sample app for launch day and subjecting myself to the 10K limit was as fun as it was challenging. You have to think and choose your codes carefully. Now, knowing firsthand what goes into making such a tiny app, I’m even more excited to see what the world comes up with. Good luck, everyone!

Further Reading

• MIX Online announcing 10K Apart – Responsive Edition
• Reagan Ray on Designing the 2011 10K Apart Contest
• Trent Walton on 10K Apart: The Responsive Edition
• Nishant Kothary on Back to the Future of Wireframes

Better Browsers, Better Devices, New Interactions

Browser improvements aren’t just limited to graphics and animations. We can now tap into the hardware capabilities of various devices: geolocation, orientation¹, notifications, multitouch, etc. These capabilities create brand new avenues of physical interaction we’ve never had access to before.

How can we use these new features for more meaningful interactions? How can we use them responsibly? Here are a few rules I live by:

• Don’t repeat the sins of Flash.
• Don’t make users wait.
• Make it non-essential.
• Make it delightful.

Stick to these rules and you’ll be able to surprise users with simple, joyful interactions (and should keep the luddites at bay).

The tools for the job.

Interaction Design is still tough. Aside from sliding around paper cutouts on a flat surface, I haven’t come across a tool greater than HTML for mocking up interaction².

I’m not naive enough to say, “Thou Shalt Only Design in Browser.” Though, in the near future I’m sure we’ll all spend more and more time mocking up working interaction prototypes in browser. We’ll all need HTML/CSS labs to test clicks, fonts, swipes, flips, orientations, squeeziness™, and more on multiple devices.

We’re in hyper-futuristic times if you consider the browsers and devices we use each day. It’s a new frontier and there’s never been a bigger space for exploration. Go forth and make awesome.

If you zoom in, you’ll see the lines are actually two tone: a main color and a highlight color.

Typically, we’d use a 1x2px image based approach -either background-images on nested DIVs (CSS2) or multiple background-images (CSS3)- to accomplish this effect. Challenging ourselves to reduce HTTP Requests, we came up with a simple solution to get the job done.

<style>
    body { background: url(noise.jpg) repeat; }
    #blog {
        border-top: 1px solid #fff;
        box-shadow: 0 -1px 0 #cdd4b4;
        /* you'll need all the vendor prefixes for `box-shadow` */
    }
</style>
<body>
    <p id="blog">This is my content</p>
</body>

Bingo Bango! It works, is future proof, and degrades nicely. View the Demo

Double-Double Borders

What if you need two-tone lines on the top and the bottom of a element? That’s easy as well.

#blog {
    border-top: 1px solid #fff;
    border-bottom: 1px solid #cdd4b4;
    box-shadow: 0 -1px 0 #cdd4b4, 0 1px 0 #fff;
}

UPDATED: Divya Manian and Felix Niklas were quick to point out a better way for multiple borders using multiple box shadows. Updated code, but view the e-solution here!.

Bonus Sass Mixin

If you’re going to do this a lot, with all the vendor prefixes needed it makes sense to use Sass. Here’s a free Sass mixin to get the job done:

@mixin doubleborder($side, $innerColor, $outerColor) {
    $shadow: "0 0 0";
    border-#{$side}: 1px solid $innerColor;
    @if ($side == "top") { $shadow: 0 -1px 0; }
    @if ($side == "right") { $shadow: 1px 0 0; }
    @if ($side == "bottom") { $shadow: 0 1px 0; }
    @if ($side == "left") { $shadow: -1px 0 0; }
    -webkit-box-shadow: $shadow $outerColor;
    -moz-box-shadow: $shadow $outerColor;
    -o-box-shadow: $shadow $outerColor;
    box-shadow: $shadow $outerColor;
}

#blog {
    @include doubleborder(top, #fff, #cdd4b4);
}

Here are the slides that are available for download on Slideshare (and hopefully soon at Note & Point). Also, don’t forget to re-look at the ever growing gallery of real-world examples over at LetteringJS.com.

Bonus PowerPoint!!

Because I know you like PowerPoints, here are some slides on Webkit Transitions and the accompanying demos I did for a talk at Refresh Austin last year.

Also worth checking out: Trent Walton and I co-wrote an article for a Summer 2010 issue of NetMag (Issue 205 – Out of Print) that features similar, less-copyright-infringing, demos along with a simple walkthrough explanation of CSS transitions and animations.

In order to quantify the benefits side projects, I decided to take note of at least 40 different skills and technologies I’ve learned this year solely through side projects. The bulk of my work at Paravel is still in PHP and since clients aren’t paying me to be totally confused for hours on end, I had to hone these new skills in my spare time.

Paravel has just wrapped up an exciting secret project with three of the web’s most talented designers: Jason Santa Maria, Frank Chimero, and Naz Hamid. These designs are epic, like 18,123px epic. Working with these guys was a complete joy. There were a few fun development challenges and – as you might expect from these gentlemen – a lot of fancy typography work in the delivered PSDs.

Before Trent and I marked up the designs, we noticed that in many instances we would need to style individual letters. We decided we’d need a system to keep our markup maintainable. Something agile enough that a text change wouldn’t ruin us. Our solution was to call upon the power of Javascript to insert some easy to remember span tags.

Individual Letter Control with Lettering.js

We developed a really simple, lightweight, easy to use jQuery plugin, we’re calling it “Lettering Dot JS”, and we’re releasing it today for free over on Github. Let me demo it for you: </stevejobs>

We’ll start with some really basic markup:

<h1 class="fancy_title">Some Title</h1>

After including jQuery, download and include the minified version of Lettering.js, then a script block:

<script src="path/to/jquery-1.4.2.min.js"></script>
<script src="path/to/jquery.lettering.min.js"></script>
<script>
$(document).ready(function() {
  $(".fancy_title").lettering();
});
</script>

The resulting code will churn your .fancy_title and output the following:

<h1 class="fancy_title">
  <span class="char1">S</span>
  <span class="char2">o</span>
  <span class="char3">m</span>
  <span class="char4">e</span>
  <span class="char5"></span>
  <span class="char6">T</span>
  <span class="char7">i</span>
  <span class="char8">t</span>
  <span class="char9">l</span>
  <span class="char10">e</span>
</h1>

Magical. Now the text is easy to manipulate in your CSS using an ordinal .char# pattern. This plugin assumes basic counting skills, but it’s a pretty fast and easy way to get control over every letter.

As you can imagine, it would be a pain in the ass to have all those spans littering your markup and a nightmare to maintain. If the client came by the next day and said that the SEO Expert demands that you have to change the title to “Cool Title”, it’d just be a matter of changing the original clean markup to:

<h1 class="fancy_title">Cool Title</h1>

It also plays nicely with CMSs like WordPress or Expression Engine and art direction plugins.

Wrap Words with Lettering.js

Once we developed this e-solution and played with it, we found it useful enough to broaden the scope so that we could break apart and wrap words in a sentence in a span tag.

Here’s an example of the .lettering(‘words’) method:

<p class="word_split">Don't break my heart.</p>

<script>
$(document).ready(function() {
  $(".word_split").lettering('words');
});
</script>

Which will generate:

<p class="word_split">
  <span class="word1">Don't</span>
  <span class="word2">break</span>
  <span class="word3">my</span>
  <span class="word4">heart.</span>
</p>

You can then style each word using the .word# class.

Wrap Lines with Lettering.js

Once word wrapping was complete, noticed the need for yet another method, one that would break lines up mid-sentence. We struggled for a semantic way to do this, but then remembered <br> tag which a semantic way to say “break this line”. Similar to the above examples where lines of text are broken up by either non-breaking spaces or individual letters, the lettering('lines') method will create breakpoints at <br> tags:

<p class="line_split">Are you<br/> ready to<br/> RUMmMmMMBBLE!</p>

<script>
$(document).ready(function() {
  $(".line_split").lettering('lines');
});
</script>

Resulting code:

<p class="line_split">
  <span class="line1">Are you</span>
  <span class="line2">ready to</span>
  <span class="line3">RUMmMmMMBBLE!</span>
</p>

Kern Well

If you’re going through the trouble to load a fancy font and that word or phrase is the largest on the site, then it’s important for it to be kerned well. With Lettering.js, kerning is a breeze. You can simply use $("#id-of-what-i-want-to-kern").lettering(); and then on each .char#, you can set relative position or left/right margin. Works like a charm.

Best Practices

We’ve found this to be a pretty quick and elegant solution to create typographical CSS3 posters. It’s also a great solution for really custom type headings, while keeping the text selectable.

Be smart and use sparingly. You’ll probably break your browser if you try to tried to do wrap every letter on your page in a span tag, so don’t do that. Look to use this in your Headings, Blockquotes, Asides, etc.

Non-Javascript Fallback

As with any kind of Javascript, have a fall back plan in case the user doesn’t have javascript enabled. The bottom line is up to you, my bottom line would be “legible and on the screen”. Also, use lettering.min.js: Download the minified version of Lettering.js here.

Performance Anti-Pattern

Web performance patterns advise that you put Javascripts at the bottom of your page before your </body> tag. There is an unfortunate side effect where you may experience a FOUT (Flash of Unstyled Text) when you’re manipulating your text after the DOM has loaded. Unfortunately, we found the best solution to avoid/minimize the FOUT caused by this plugin is to put your scripts (jQuery, Lettering.js) in the document <head>. On the one hand, your page will load slower. On the other hand, a flash/restyling makes your site feel slow. Users might ultimately feel the site is faster if they don’t see the FOUT.

Download, Fork, Commit, Please.

We really want Lettering.js to be a quality helper for web typography. If you have any feedback or suggestions, please leave those over on the Github. We’re excited about typography on the web and want to help make it print quality.

Download the Plugin here.

Thanks to Paul Irish for code review!

In January, I interviewed Kyle Simpson on Episode 4 the ATX Web Show. We discussed Web Performance and Google’s plan to “Make the Web Faster”. Since then, Google has announced they will start rewarding your site’s page speed. And in their Webmaster Tools they hint that the bar is set at ~1.4 seconds.

80% of the time users wait for a web page is because of the frontend.

I was sort of thunderstruck with fear. Although we always strive for better, I typically found a 3-5 second page load great and up to 7 seconds acceptable. After recording the show, I stayed up a few hours that night fiddling with The ATX Web Show and increased site performance by ~500%¹.

Since seeing those results, I only think about Web Optimization. I see the web in milliseconds now. If you’re like me and never considered optimization a necessity maybe now is the time to re-evaluate that. And don’t act like this isn’t your problem because 80% of the time users wait for a webpage is because of the frontend². The goal isn’t to fit under some imaginary kilobyte threshold, the goal is to make sure that everything is as small as possible. Reduce Filesizes, Reduce Requests, and Enable Caching.

5 Steps to a Faster Website

I documented the steps I took to increase my YSlow and Page Speed grades without getting into costly CDNs and such. A lot of sites will tell you to just install a cache plugin. And while you should do that (see Step 5), it’s important to do that after you’ve optimized or else you’re just polishing a turd, curing a symptom not the disease, putting lipstick on a pig or whatever analogy you want to use. Very little of this is WordPress specific so even you dweebs on Expression Engine can optimize your sites.

Step 1: Minify & Optimize Your CSS

This is just a 3 step process and it’s here that I saw the majority of the site’s weight drop off. There’s about a 10% chance you’ll break something here. If you’re uncomfortable take it slow, line by line, and refresh a lot.

Minify CSS

Open up Page Speed and click “Analyze Performance”. Find the section titled “Minify CSS”. You will see download links for optimized versions of every CSS file your page calls. Replace your bloated CSS with this.

For WordPress, you’ll have to keep the theme declaration block at the top.

Unfortunately in the case of WordPress, most blogs rely on plugins which load their own assets that are rarely optimized. You may have to overwrite the CSS in some plugins. In a perfect world, WordPress plugins would come with pre-optimized assets.

This is maybe not advisable, but I hack into plugins and comment out the CSS and Javascripts they load. I’d rather write my own CSS. Be prepared to do this after every plugin update.

Learning Point: Don’t Over Qualify. Use Efficient CSS Selectors.

I always assumed it was best practice to be explicit when writing CSS, but I was wrong. It’s called “Over Qualifying” and it’s more work for your browser to sort out. Unique classes and unique elements will win in the speed game.

  #header nav ul li a { ... }
  /* bad. 5 selectors is way too many. */

  ul.commentlist { ... }
  /* bad. too conjoined. */

 
  #header a { ... }
  /* better. more direct. really nice. */

  .commentlist { ... }
  /* better. just the class selector should be specific enough. more agile too.*/

I covered this briefly, but Chris Coyier of CSS-Tricks has a great write up on Efficiently Rendering CSS.

Step 2: Smush & Optimize Images

Your images are too fat. Photoshop’s “Save for Web” is actually pretty good at optimizing, but there’s room for more. Your images have huge amounts of useless metadata that can be stripped out. This couldn’t be easier to fix. Here are some tools to smush your images.

1. Page Speed gives you a lossless smushed version of each image that can be optimized! Save As… and upload.
2. YSlow > Tools > All Smush.it – this will batch shrink the images on the page and maintain folder structure. It’s unbelievably convenient.
3. ImageOptim is a great offline tool (for Mac) that you can batch run whole directories with. Any image you upload to the internet should go through this before you upload from now on.

Sometimes you’ll see that you’re only saving 400B and you may think “What’s the point?” Pay attention to percentages. If an image can be 9% smaller, that means your users will get that image ~9% faster! Math.

Be sure you make backups before you replace images or smush whole directories, just in case.

If you use Adobe RGB color profiles for your images, some optimizers strip out the profile leaving you with a desaturated image. The Adobe RGB profile adds ~50KB+ and is intended for print. Use sRGB instead.

Serve Properly Scaled Images

This is pretty elementary. Where you can, serve a 200x200px wide image instead of scaling down a 400x400px wide image to 200x200px. Larger images take longer to download and resizing takes longer to render in browser.

Specify Image Dimensions

I had grown accustom being non-committal about image dimensions, but Page Speed recommends that you specify image height and width because it’s less for the browser to sort out. It gives you the rendered dimensions and you add that to your <img> tags. Total time spent completing task: 2 minutes.

SpriteMe

Use sprites. Spend some time and figure it out. It can reduce tons on HTTP Requests and make your site even faster. Google performance guru, Steve Souders, created a tool called SpriteMe that does this for you. Install the bookmarklet, and click it on your homepage, then it’ll do the rest of the work. It will pack up your sprited images, and give you some CSS to replace in your stylesheet. Skills Required: Math.

Step 3: Minify & Optimize JS

Just like CSS, Page Speed gives download links for minified versions of your javascript right there in the window. Grab the minified versions and drop them in your site. There’s, again, a 10% chance you’ll break something, but just take it slow and refresh often. And again, you might have break into plugins and comment out their swill.

One JS Library to Rule Them All.

If you’re loading in jQuery, Mootools, and Prototype, you’re doing something wrong. These libraries have a lot of functional overlap so you’re basically repeating yourself over and over and wasting tons of bandwidth. Have a good hard look at your plugin stack. Find out which plugins are loading what library (use paper if you have to) and try to target a single library (*ahem* jQuery *ahem*). Search for alternative plugins that use the your library of choice.

Step 4: Enable Browser Cache & GZIP in Apache with .htaccess

This took me a long time to master. I was ignorant to its proper implementation, I googled around and found a few good resources.³ If you’re on Apache (you probably are), add the following to your .htaccess file after your WordPress rules. If it’s all gibberish to you, that’s fine. Basically it does the following:

1. Detects mod_deflate and GZIPs various mime types.
2. Detects mod_expires and sets an expiration date for each type of asset.
3. Detects mod_headers and sets Browser Cache age limits for your assets.

I’ve used this on about a dozen sites on a handful of hosts and had no problem. It will simply ignore what it can’t support. If you see improvements, please comment over at GitHub.

Step 5: WordPress Plugins for Performance

Here are some plugins to install on our final step on the way to Web Performant WordPress. Like I said at the top of the article, don’t rely on plugins to fix your sloppy code and your poor craftsmanship. Your site needs good bones. And your client deserves at least that.

WP Minify

WP Minify is a great plugin that will combine and minify all your javascript files or all your CSS files. Basically, everything I told you to do in Steps 1 and 3. If you’re lazy and skipped that section and just came here, I’m sad for your clients.

I’ve found this great for serving minified CSS that I had to keep human readable in the theme. As far as Javascript goes, it could be my problem but, I’ve never had a plugin successfully combine scripts and have them all still working in the end. Try it! If you’re able to squeeze all your javascript into one file successfully, I applaud you.

WP Super Cache

Now that your site is optimized, you’ll notice on your page load waterfall one of the longest part of your load is probably the first blue line, your HTML. This is because your site is taking a huge roundtrip:

Client Request → WordPress Server → Database → WordPress Server → Client

Turning on caching will take out that trip to the database.

Client Request → WordPress Server → Client

FASTER! It actually does quite a bit more but this is the simplified explanation.

I’ve found WP Super Cache to be wonderful for this and I highly recommend it. It’s a bit of a pain to install as you have to grant temporary permission to some directories to write, add a line to your wp-config.php, and then add some more to your .htaccess. There’s a 30% chance you’ll whitescreen your WordPress install, but just follow the directions and the end result is once you turn it on your visitors will be served HTML in milliseconds.

Disclaimer: Most of these stats are from Luke Wroblewski http://www.lukew.com/ff/entry.asp?933

Design & Development on the Mobile Web

I usually don’t usually sit around and ponder “The Mobile Web”, but about two weeks ago I accidentally inundated myself with multiple talks about it from two separate podcasts. Because of that, the Mobile Web has a growing market share in my brain space.

First was John Resig on yayQuery and second was Luke Wroblewski on The Big Web Show. I encourage you to tune in and listen to each of these episodes, although each episode leans towards a different end of the Design/Development spectrum they combine to help paint a larger picture of the challenges and limitations of the mobile web.

I should state upfront that I’m not going to propose any solutions or announce a new biz-dev-mobile-social-strategy on behalf of Paravel. If we had it my way, the whole world would convert to Webkit and we’d be mostly done with all the cross browser crap, but that’s not reality. I just want to share a mini-roundup of what my mindgrapes are soaking in.

The Design Point of View

Episode 6 of The Big Web Show is a must listen. Luke Wroblewski shares his “Mobile First” mantra, which is the idea that if you design for the mobile platform first, you can end up with a superior product.

In terms of design, the mobile web presents us with some challenging limitations:

Size Matters

Designing a website on 1024×768 is completely different than designing on 320×480. And now with the iPhone 4 in the mix, there’s a rogue 960×640 resolution floating around… and that’s just iPhones. Devices vary in dimensions and although devices are squeezing more and more pixels in the screen there’s still limited real estate.

Touch

Touch brings about a few design challenges. Most importantly is the lack of :hover. Avoid relying heavily on :hover. Fat fingers are less accurate than 1px mouse pointers so things that are clickable need to be big, occupying more precious real estate. While touch-interfaces are gaining popularity, the majority of smartphones are non-touch.

Gestures and Multitouch

In terms of interface design, there’s the added issue of multitouch versus non-multitouch. Gestures for each touch-enabled platform are different. On iPhone you tap and squeeze and swipe, on WebOS you fling, on Android you have some menu buttons in the mix. For more information, read Luke Wroblewski’s report on Multitouch Gestures.

Limited Bandwidth

If a mobile user waits too long, they will hit the BACK button and you lose them forever. Limited mobile bandwidth sends us back to the days where every kilobyte counts. Any website, especially a mobile version, needs to be lightweight and heavily optimized. Be fast by default.

Limited Battery Life

Almost a development concern, but it should be noted HTTP Requests are the biggest cause for battery drain. And since caching on mobile is minimal at best, you will likely load assets each page load. Designs should bear this in mind and be lightweight.

When you design for mobile, you are immediately faced with the challenges of ripping out all the stuff that doesn’t matter and forced to provide the most basic actions. Although a daunting task, there’s an optimistic side. As mentioned in the podcast, the mobile versions of some big websites (Facebook for iPhone, Flickr, GoDaddy) are actually better than their giant counterparts because they offer a simplified user experience. So in someways, it’s a designer’s dream to be able to put their foot down and say “No, I will not make the logo bigger” because it can’t possibly be done.

There’s a financial incentive, too. As shown by the facts at the top of this article, there’s an ever increasing demand for mobile-compatible interfaces. This means that you have legitimate reasons to charge for such services. Mobile sites and native mobile apps are fast becoming a separate portal to businesses worldwide.

I am of the optimistic mindset that any good designer likes to design. And good designers can design well even if given limitations like that of the mobile web. The mobile web gives designers an exciting new horizon and potentially lucrative field to begin targeting their pixels with.

The Developer Point of View

When John Resig, creator of jQuery, stopped by the yayQuery podcast I thought it was going to be better than freebasing crushed Fruit Loops. Although it was a great show, my delight was turned into a the world’s saddest sadface as Resig shared the ruthless, cold-hard facts about mobile development. You need to watch and listen yourself, and have your own private FML moment.

The Mobile Web IS NOT just the iPhone. Depending on who you talk to, there are around 15-21 browsers that are in need of active support. In its simplified form there are 8 major browser platforms with each of them having multiple browser versions with differing capabilities, differing Javascript support, and different caching methods or no caching at all. This is so much worse than the IE6 problem, it’s like having 15 IEs.

Information about these browsers is difficult to gather. Peter-Paul Koch ran some comprehensive tests on CSS and Javascript support. Resig wrote a nice summary of PPK’s behavior research over at his blog, this is the best place on the internet to start learning about the various mobile browsers.

It’s sobering to know your future enemy: twice as many major browsers, fractured browser share, unknown/poorly documented support, and the list goes on. Not to mention, the most important part of developing for a mobile device is actually holding it in your hands and seeing how it feels, interacts and responds.

There is some hope. There are native application compilers like PhoneGap and Appcelerator Titanium which will take your HTML/CSS/JS and build native apps for most of the major platforms. I’ve heard nothing but good things and much excitement from developers using those platforms. Also, the yet-to-be-released jQuery Mobile will help solve some of the browser inconsistencies. So although there’s a light at the end of the tunnel, it’s a hard uphill road up ahead.

Facepalm, Mobile Web.

Like I said at the top of the article, I wish the whole world was Webkit, it would solve a lot of problems. I’d even suggest setting a new standard for the word “smartphone” using the 2G iPhone as the base standard since it was the original game changer. All other phones would be “dumbphones”. But I dream a dream.

As far as the mobile web is concerned here in the now, I unbiasedly do believe that developing towards the Webkit (iOS, Android, and future Blackberry) platform is the safest bet as it’s one of the fastest growing markets and possesses the least amount of HTML/CSS support headaches. It’s important to note, however, that webkit browsers are not the dominant browser so be prepared for your mobile site to degrade and still have to function on your boss’ old Blackberry.