In This Issue...

• Introduction
• Opera Mini -- Beta 4
• JavaScript Animation Using jQuery
• What's New on SitePoint!
• Hot Forum Topics
• New Blog Entries

The Principles of Beautiful Web Design

Tired of making web sites that work absolutely perfectly but just don't, well, look very nice? This new full-color book will show you design the right way.

• Create amazing designs from scratch
• Understand why some designs "just work"
• Unleash your creative talents
• Master the design fundamentals:
  layout, color, texture, typography and imagery
• Uncover the trade secrets the great designers keep to themselves

Bonus: Get a Photoshop RGB color & font quick reference card.

Click here to download free sample chapters!

Introduction

Welcome to Design View #35.

There seem to be two opposing forces in web development at the moment.

In the blue corner, we have the new mobile web. Not long ago, the mobile web was looked upon as a gimmick -- the general consensus was: ''Who on earth will want to view a web page on such a tiny screen?"

Fast forward to mid-2007, and almost all decent new phones now come with a decent web browser built in. Additionally, phone-oriented applications like Twitter, Socialight, and Yahoo! Go are training people to regard their phone as a web device. Bear in mind, though, that even the best phone browsers have little or no JavaScript support.

Over in the red corner, we have the new generation of JavaScript and Ajax interface development. Online applications such as Flickr, NetVibes, Google Maps, and BackPack have championed the development of more JavaScript-centric applications than ever before.

While some applications degrade beautifully (you'd be forgiven for thinking that Flickr even used any JavaScript), others (I'm looking at you, Google Maps) almost purposefully disable the application for users without scripting turned on. Sure, pannable maps might be impossible without scripting, but what would be so difficult about making the four map edges clickable for JavaScript-less users?

The new version of Dreamweaver isn't helping matters -- its built-in Spry Ajax framework makes it easy to add Ajaxy flourishes to your interfaces. However, many Spry-enhanced features often seem to fail unceremoniously when there's no JavaScript to power them.

I've become particularly aware of this fact since I recently started using the No Scripts extension for Firefox. This extension allows me to set scripting privileges on a site-by-site basis.

Although I originally installed NoScripts in order to handle irritating behaviors at a few sports sites that I frequent, I recommend running it for a month, just as a simple exercise to learn what happens to many sites when JavaScript goes away. Very educational stuff.

The next few years seem likely to be a balance between locking in the obvious benefits that JavaScript enhancements can give us while avoiding the ruination of our sites for the thousands of new phone browsers (read: customers) coming online every hour.

So many phones. So much scripting.

Simply JavaScript

As we're talking about good and bad JavaScript, this is a perfect time to introduce Kevin and Cam's excellent new book -- Simply JavaScript.

If you've played around with snippets and pre-written scripts, but felt like you lacked the proper grounding to put it all together, this is the book for you.

The guys take you from a good foundation understanding through to some nifty tricks and techniques -- all using the kind of best practice code designed to keep you clear of the kind of JavaScript dependence problems I described above.

As always, there a sample PDF for you to make your own call.

Download Simply JavaScript Sample PDF

Cheers,

Alex Walker
Editor
SitePoint Design View

Opera on a Phone

So, all the chatter about the iPhone has got you thinking about the mobile web, huh? But if you won't have (or don't want) an iPhone in the foreseeable future, what are your best options for using the web-enabled phones that are already out there?

The folks at Opera have always had an excellent pedigree in delivering browsers for mobile devices, and appear to have a solid stranglehold on most of the top-end phones. Currently they make two excellent, but philosophically different, mobile browsers.

Opera Mobile is fully fledged browser, in the classic sense of the term. While it is certainly optimized for small-screen rendering and mobile-friendly layouts, in many ways it's not very different from your desktop browser. Although its 1.7MB file size makes it around one-quarter the size of its desktop equivalent, it's still a significant download for most phones.

If you own a latter model Nokia or a Motorola, there's every chance that Opera Mobile is your phone's default browser.

Opera Mini, on the other hand, has taken a completely different approach -- it employs a "middle man" server between your phone and the site you are requesting.

The application on your phone is tiny (90k) and relatively unsophisticated, automatically passing all page requests directly to Opera's servers, which is where all the real grunt work is done. The servers grab a copy of the original page, strip, simplify, and compress it, before sending the result back to the Opera Mini client on your phone.

There are some obvious advantages to this approach:

1) Page rendering: Complex rendering decisions rules can be applied quickly, because you're not reliant on the always limited processing power and RAM of your phone to make smart rendering choices. This means that even older handsets can often run Opera Mini nicely.

2) Speed: By stripping the page before sending it to your phone, you don't use precious bandwidth to download elements that you can't use. The result is that the browsing experience is sped up noticeably.

3) Ongoing development: As most of the "smarts" in delivering a fast user experience exist on the Opera server, the application can be constantly developed, improved, and upgraded without users constantly being required to upgrade the application on their handset to reap the benefits.

I've found the latest beta 4 to be a particularly impressive release. It integrates a number of new features, including a slick thumbnail-to-zoom browsing mode.

This mode allows you to navigate quickly around sites you are visually familiar with. Once you've located what you need, you can zoom in to reading level with a click.

It's not always plain sailing, of course. Although the new Mini beta does a great job with the majority of sites, some Ajax-heavy sites perform more reliably on a full mobile browser, so I wouldn't advocate deleting Opera Mobile if you have it installed. Having Opera Mobile as a backup browsers has gotten me out of trouble a couple of times.

Nevertheless, with its speed and smarts, Opera Mini is now the first browser I launch on my phone.

If you're intrigued as to how your sites might perform in Mini, Opera have made a really nice simulator available.

Take it for a spin.

Meanwhile, Matt has a rundown on a new iPhone simulator -- iPhoney. Looks like lots of fun and mobile times ahead...

Read the blog entry:

SitePoint Blogs: Web Tech by Matt Magain iPhoney: Test Your Site for iPhone Compatibility (5 comments)

ProWorkflow - The Business/Project Dashboard for Web Design Firms and Freelancers!

ProWorkFlow is a web-based application that allows you to manage your projects, tasks, time, contacts, notes and more.

• Keep accurate time usage records
• Deliver projects on time, and on budget
• Organize, plan and delete jobs and tasks
• Get a global overview of company activity

ProWorkflow is customisable and expandable to suit your business and is available in two flavours: subscription account or permanent license to run on your own server.

Click here to try a Free Trial Account.

JavaScript Animation Using jQuery

One of the nicest things about going to a real bricks 'n' mortar bookstore is the effortless pleasure of thumbing mindlessly through any book that takes your fancy -- not to actually read anything in particular, but just to get a general sense of its layout, style, and quality.

While it's difficult to convey information about the paper and binding quality via a screen (compared to fingertips), our marketing manager Shayne and I started wondering whether it might be possible to reproduce some of that effortless "page flicking" feel, using a touch of JavaScript. The result of our first test is here -- promoting Kevin and Cam's new JavaScript book, fittingly enough.

Although you're more than welcome to pick through the live version on our site to see how it's done, I'll walk you through a standalone, simplified version in this newsletter.

I give you fair warning: the following will be a little more technical than usual, but with any luck you'll agree that the end result is worth it.

Part I: The Starting Point

There were a few decisions I made early on in the project:

a) I wanted the final product to be as flexible as possible, so that I could add or subtract pages and alter the page sizes without having to make major changes to the code.

b) I needed all of the individual book pages (between eight and 16 pages) to be contained in a single, large, flat rendered image (like this one). This meant that I could guarantee that all my page images were downloaded and "ready to rock" at the first sign of a click.

It also meant that I could overlay the rendered 3D elements of a turning page on a separate, reusable PNG layer (like the one shown below). This one is obviously setup for our blue and orange page head and footer, so you might need to generate a plain white version for use on other books.

Displaying just the central third of the page gives us only the shaded curves of the inner spine -- great for adding some depth to the book sitting open. When our user attempts to "turn" a page forwards or backwards, we can then align this background image to either the right- or left-hand side of our book respectively. These three simple frames go a long way toward creating the illusion of a turning page.

c) I wanted to base my solution on jQuery, because of its easy-to-learn syntax, small size (20k), and speed. If you're a long-time DV reader, you might remember reading my jQuery primer about a year ago.

True, using a library like jQuery has its disadvantages. If you're a JavaScript guru (like our resident front-end expert, brothercake) you'll always prefer to write a smaller, more efficient script from scratch -- you'll also never have to worry about library upgrades or backwards-compatibility.

Nevertheless, the benefits of using an efficient library (whether that be jQuery, Prototype, Animator, MooFX, or a raft of other libraries) easily outweigh the costs for many of us.

Part II: The Structure

The markup structure we're going to use is a construction of four divs.

1. div#leftpage: the left-hand page
2. div#rightpage: the right-hand page
3. div#flip: the midway point between the pages
4. div#turner: a wrapper to hold the whole thing together

div#flip is set as position:absolute, so we can float it over our spine region.

The other three divs are all set to position:relative, and floated to the left so that they stack together nicely. I've set my page dimensions to be 189px x 146px. There's nothing special about these dimensions -- they just happened to be about the right size for the page area I had available.

Once our page inserts our images into their div backgrounds, our static book is ready, waiting for jQuery to make it dance.

Part III: The JavaScript

1) The setup

Time to get our hands dirty. The first thing we need to do is attach jQuery to our document and add a new script tag to contain our custom script:

<script type="text/javascript" src="jquery.js"></script>

<script type="text/javascript>

/* our script goes in here */

</script>

2) Setting up some useful variables

We have a handful of numbers that we'll need to use several times, so it makes sense to store them in variables. That means we'll only need to update our script in two places if we decide to change our page size later. The variable names do a fairly good job of describing what they are:

/* Page sizes*/

var $pageheight = 189; // our page height
var $pagewidth = 146; // our page width
var $pageYpos = 0; // current Y position of our bg-image

3) Setting up our ready event

One of jQuery's strengths lies in its simple document ready event, which is a souped-up replacement for the old-fashioned onLoad event that you might have used in the past.

Any code placed inside this ready event will be executed as soon as the page is ready. It looks something like this:

The nice part is that jQuery's ready event will begin working as soon as the parts it needs are downloaded -- the old-school onLoad event had to wait until your page had completely finished loading. If you begin experimenting with jQuery some more, you'll find yourself using this function quite a lot.

4) Making the #leftpage div clickable

The markup for our book image doesn't contain any links, so at the moment there are no clickable "hooks" upon which to base our page-turning animation.

That's no biggie, though -- with a few lines we can tell jQuery to watch #leftpage for clicks, and then to perform a number of tasks every time it registers a click there. The code looks like this:

 $("#leftpage").click(function(){
   /* do stuff when they click on #leftpage */

});

5) Making a click move our background image

Okay, now we're getting somewhere! For when a user clicks on #leftpage, we'll first calculate how far we need to move the background image, and then we'll move it. Our starting Y position ($pageYpos) is zero, so we need to add exactly one "page height" unit in order to move the background image to the next position. We express this as $pageYpos = $pageYpos + $pageheight. After one click, the value of $pageYpos will be 189, after two clicks it will 278, and so on.

We then use that value to reposition our background image. Here's the code to perform the repositioning:

 $("#leftpage").click(function(){

$pageYpos = $pageYpos + $pageheight;
 $("#leftpage")
   
   .css("background-position", "0px
"+$pageYpos+"px");

});

In the code above, we're selecting #leftpage and using jQuery's built-in css function to reposition its background graphic.

If we were to try that code now, we'd see that things are finally starting to happen! Clicking the left side of #leftpage should instantly snap the background-image to display the next page. The neat thing about this technique is that our background tiles automatically -- when we arrive at the last frame, the first page rolls around and the loop continues. Nice!

6) Showing the page turn

Next we need to show the page-turning part of the graphic by telling jQuery to set the background-position of our div to the top right. It's simple enough to add to our click event:

$("#flip")
.css("background-position", "top right");

7) Removing the page turn and changing the right-hand page

If we follow the same logic, it's not hard to predict what our next snippet of code will look like. First we need to return #flip to its default, central position:

$("#flip")
.css("background-position", "top center");

Next we need to display the next page on our right-hand page. We already know the new Y position ($pageYpos) because we used it to reposition the left-hand page background earlier.

$("#rightpage")
.css("background-position", "146px
"+$pageYpos+"px");

8) Delaying the page-turn effect

Okay, so now we have the correct animation sequence -- change left-hand page, show page-turn graphic, hide page-turn graphic, change right-hand page.

The problem is, these steps all happens so quickly that we never even see the page-turning animation. We need a way to delay the script momentarily, before it clears the page-turning graphic and continues. The most common way to control time in JavaScript is via the setTimeout function.

setTimeout requires two arguments: the action you want to take, and how long (in milliseconds) you want it to wait before taking that action. For instance, if you want an alert to pop up after five seconds, you might use the following code:

setTimeout ("alert('Five seconds has passed!)'", 5000);

All we need to do is place our last two CSS changes inside their own setTimeout functions. I've set the delay on both to 200 milliseconds, but you might like to adjust it to your taste. In fact, setting the right-hand page to animate a fraction later (300 milliseconds, for example) might be closer to what happens in the real world when we turn a page in a book.

setTimeout ('$("#flip").css("background-position", "top center");', 200);

setTimeout ('$("#rightpage").css("background-position", "146px "+$pageYpos+"px");', 200);

There you have it -- dropping that code into our script gives us a simple but effective animation, without having written a lot of code.

9) Making the right-hand page turn

In the interests of keeping this edition of the Design View to a semi-reasonable length, I won't step through the entire process of animating the right page here. Suffice to say it's a mirror image of our left-hand page function. Have a go at working it out for yourself, or check out the finished demo here.

Now, if you're thinking it doesn't look quite the same as the version on sitepoint.com, you're quite right. The production version:

• has an extra corner page curl part to the animation
• has an extra sliding animation effect that eases each page into place as it settles (it's subtle, but you'll notice it)
• is unobtrusive -- meaning we load a garden-variety img into the HTML, and then use jQuery to replace it on the fly with the div structure outlined above. Anyone visiting the page without JavaScript enabled will at least have access to the page images

Again, feel free to experiment with adding those parts into the demo we built here.

We've been a little more code-heavy in this Design View than usual, but if you stuck with me and made it this far, well done!

That's all for this issue -- thanks for reading! I'll see you in a few weeks.

Alex Walker
design@sitepoint.com
Editor, The SitePoint Design View

Help Your Friends Out

People you care about can benefit from the wealth of information on new and maturing technologies available on the Internet. Help them learn how to do it by forwarding them this issue of the SitePoint Design View!