Tag: kranthi

What’s New in WordPress 3.4


  

With WordPress 3.4 set to arrive this week, it’s a great time to familiarize ourselves with the new features and additions. The new version of WordPress brings many improvements, including custom backgrounds and headers, a live theme-customizer, revamped XML-RPC, better support for internationalization, and many bug-fixes and enhancements. Let’s dive in and see what WordPress 3.4 has in store!

wp34featured-500

Custom Headers And Background

When WordPress added featured images as a core feature in 2.9, a new function was added — add_theme_support. It was (and is) obvious that this is a precursor of things to come: the standardization of theme features. Since its introduction, add_theme_support handles post-formats, automatic feed-links, and now in version 3.4, custom backgrounds and headers will be added to the list.

Adding a Custom Background

To use this feature, just call the add_theme_support() function with ‘custom-background’ as the first argument, and a list of default options as the second. Here is an example showing the basic syntax:

	$args = array(
		'default-image'          => get_template_directory_uri() . '/images/bg-default.png',
		'default-color'          => '#fafafa',
		'wp-head-callback'       => '',
		'admin-head-callback'    => '',
		'admin-preview-callback' => ''
	);
	
	add_theme_support( 'custom-background', $args )

Once the code is in place, you’ll see the changes take effect in the WordPress Admin:

The new custom background facility in WordPress 3.4
The new custom background facility in WordPress 3.4

Adding a Custom Header

Adding the custom-header options work in much the same way. In addition to the new way of defining them, you can now make them flexible in height or width, which is a great asset to theme designers.

	$args = array(
		'flex-height'            => true,
		'height'                 => 200,
		'flex-width'             => true,
		'width'                  => 950,
		'default-image'          => get_template_directory_uri() . '/images/headers/header-default.jpg',
		'random-default'         => false,
		'default-text-color'     => '',
		'header-text'            => true,
		'uploads'                => true,
		'wp-head-callback'       => '',
		'admin-head-callback'    => '',
		'admin-preview-callback' => '',
	);
	add_theme_support( 'custom-header', $args );

Once you add this code the relevant controls will show up in the Appearance tab and you will be able to set up your custom header and background-image.

The width and height is now 'suggested'
The width and height is now ‘suggested’ (displayed in bold text)

Thanks to Chip Bennett and Amy Hendrix for their excellent posts on this topic.

Live Theme Customizer

I think one of the best features in recent times is the Live Previews or “The Customizer”. As someone who sells themes on Theme Forest, I welcome this addition because the more I can use default WordPress options, the less support I need to provide. The best way to familiarize yourself with this feature is to watch the following great overview from Otto. I also recommend his article on leveraging the theme customizer in your own themes.

We’ll be taking an in-depth look at this awesome functionality here on Smashing Magazine, but for this article, the live theme-preview feature is too complex to showcase concisely. If you’d like to get started, do read Otto’s article — it has everything you need to get things set up. Here’s the nutshell version for a quick preview.

The preview facility works in an object oriented fashion. To use it you will need to cover the following steps:

  1. Add the customizer (hook it to ‘customize_register’)
  2. Add an area of customization — a section (using add_section())
  3. Add a setting you want to be able to control (using add_setting())
  4. Add the control which is used to modify your setting (using add_control())
  5. Customize the preview functionality to work in real-time

The live preview is brand-spankin’ new, but it’s already a very powerful tool. It will no doubt receive numerous updates and additions, so theme developers will finally have a common and also flexible way of letting users customize their themes.

XML-RPC Revamped

XML-RPC is a specification and a set of tools that allow software running on different platforms to make procedural calls over the Internet. In essence, it allows communication between WordPress and other software. The most apparent use of XML-RPC is the remote blogging services that are offered by apps like Windows Live Writer and mobile apps.

WordPress 3.4 comes with a number of XML-RPC bug-fixes as well as some heavily requested features like support for post thumbnails, custom post types and taxonomies.

Internationalization Changes

Back in the second half of December last year, WP Polyglots (the translation team) announced that they will be pouring a lot of work into the 3.4 release and beyond. As a result there a numerous upgrades in the internationalization functionality of WordPress:

  • Comma-localization (for languages like Chinese and Arabic which do not use the standard comma)
  • Some fields are now forced to be LTR (like password and login names)
  • Translatable spell-checker language
  • Single quotes, apostrophes and primes can be localized
  • Translatable time-zone string
  • Simplification of:
    • Feed-language specification
    • Start of the week
    • RTL language designation
    • Default secret-key text
    • Placeholder text of database constants
    • setup-config.php file translation
    • WP_I18N_* hardcoded translations
  • Translations are now split over three POT files — wordpress.pot, wordpress-admin.pot, and wordpress-admin-network.pot
  • Default WordPress links can be translated
  • Dashboard widgets can be translated

Beginnings Of A New API

While not advertised in the change-logs, Andrew Nacin has been working on a new API which will replace the get_themes() functionality.

For now you won’t notice much, with the main difference being that you can place template files in sub-directories. Under the hood, the new class will bring significant speed increases while searching for themes by reducing the filesystem operations to a bare minimum.

As you can see on the main Trac Ticket (scroll down a bit in the comments), there has been a lot of work done but the class is only scratching the surface of what we will be able to do later on. Flexible theme-management with better performance will help developers and users out a great deal — I can’t wait to see where this goes!

Bugs and Enhancements

With a total of 401 bugs fixed, 116 enhancements added, 3 requested features built and 52 tasks completed (at the time of writing) there is a lot more to this update than just the main features above. The WordPress 3.4 Track Milestone page has all the links and info you need to take a look at all that’s been done, and here’s a quick overview.

  • HTML Support in image captions #18311
  • Twenty Ten and Twenty Eleven themes updated to support new features #20448
  • Theme installer supports child themes #13774
  • WP_Query core performance upgrade #18536
  • Clicking on an empty space in the toolbar will scroll the page to the top #18758
  • Incorrectly displayed author meta fields fixed #20285
  • Failed cURL redirect fixed #20434
  • Spam comments are now excluded from the dashboard #14222
  • Theme editor support for special theme name characters #16507
  • Retina display icons added #20293
  • Already installed themes excluded from theme search #20618
  • Args added to the recent post and comments widget #16159
  • New comments can be added from the editor #15527

Updates Of External Libraries

It’s always worth checking out the external library update for a milestone. This version brings quite a lot, to name just the most important ones:

  • PHPMailer updated to 5.2.1 #19887
  • TinyMCE updated to 3.4.8 #19969
  • jQuery updated to 1.7.2 #20339
  • jQuery UI updated to 1.8.20 #20559
  • SimplePie updated to 1.2.1 #18309
  • hoverIntent updated to r6 #19311

Want To Chip In?

If you’d like to participate there are still a few days left and you can always help out after 3.4 as well. If you have the coding chops take a look at the open tickets for the next major release.

If you’re not a coder, not to worry! Just using and testing the features can be invaluable as well! You can download WordPress 3.4 RC2 or you can install the Beta Tester Plugin to grab all the latest nightlies and be on the bleeding edge!

(JS)


© Daniel Pataki for Smashing Magazine, 2012.


JavaScript Profiling With The Chrome Developer Tools


  

Your website works. Now let’s make it work faster. Website performance is about two things: how fast the page loads, and how fast the code on it runs. Plenty of services will make your website load faster, from minimizers to CDNs, but making it run faster is up to you.

Little changes in your code can have gigantic performance impacts. A few lines here or there could mean the difference between a blazingly fast website and the dreaded “Unresponsive Script� dialog. This article shows you a few ways to find those lines of code with Chrome Developer Tools.

Establish A Baseline

We’ll look at a simple application called a color sorter, which presents a grid of rainbow colors that you can drag and drop to mix up. Each dot is a div tag with a little CSS to make it look like a circle.

The Color Sorter

Generating my rainbow colors was a little tricky, so I got a little help from “Making Annoying Rainbows in JavaScript.�

The page loads pretty fast, but it still takes a moment and blinks a little before it paints. Time to profile the page and make it faster.

Always start performance-improvement projects with a baseline understanding of how fast or slow your application already is. The baseline will let you know whether you’re making improvements and help you make tradeoffs. For this article, we’ll use Chrome Developer Tools.

The profiler is part of Chrome Developer Tools, which is always available in Chrome. Click the “Tools� menu under the little wrench to open it. Firebug has some profiling tools, too, but the WebKit browsers (Chrome and Safari) are best at profiling code and showing timelines. Chrome also offers an excellent tool for event tracing, called Speed Tracer.

To establish our baseline, we’ll start recording in the “Timeline� tab, load our page and then stop the recording. (To start recording once Chrome Developer Tools is open, click the “Timeline� tab, and then the small black circle icon for “Record� at the very bottom of the window.) Chrome is smart about not starting to record until the page starts to load. I run it three times and take the average, in case my computer runs slowly during the first test.

Performance baseline 1

My average baseline — i.e. the time between the first request for the page and the final painting of the page in the browser — is 1.25 seconds. That’s not bad, but it’s not great for such a small page.

I want to make my code run faster, but I’m not sure what’s making it slow. The profiler helps me find out.

Create A Profile

The timeline tells us how long our code took to run, but that doesn’t help us know what’s going on while it’s running. We could make changes and run the timeline again and again, but that’s just shooting in the dark. The “Profiles� tab gives us a better way to see what’s going on.

Profilers show us which functions take the most time. Let’s make our baseline profile by switching to the “Profiles� tab in Chrome Developer Tools, where three types of profiling are offered:

  1. JavaScript CPU profile
    Shows how much CPU time our JavaScript is taking.
  2. CSS selector profile
    Shows how much CPU time is spent processing CSS selectors.
  3. Heap snapshot
    Shows how memory is being used by our JavaScript objects.

We want to make our JavaScript run faster, so we’ll use the CPU profiling. We start the profile, refresh the page and then stop the profiler.

The first profile

The first thing that’s clear from the profile is that a lot is going on. The color sorter uses jQuery and jQuery UI, which are doing a lot of stuff like managing plugins and parsing regular expressions. I can also see that two of my functions are at the top of the list: decimalToHex and makeColorSorter. These two functions take a total of 13.2% of my CPU time, so they’re a good place to start making improvements.

We can click the arrow next to the function calls to open the complete function-call stack. Expanding them, I see that decimalToHex is called from makeColorSorter, and makeColorSorter is called from $(document).ready.

Here’s the code:

$(document).ready(function() {
    makeColorSorter(.05, .05, .05, 0, 2, 4, 128, 127, 121);
    makeSortable();
});

Knowing where they’re called from also makes clear that making the colors sortable isn’t my biggest performance problem. Performance issues resulting from the addition of a lot of sortables is common, but my code is taking more time to add DOM elements than to make them sortable.

I want to start making those functions faster, but first I want to isolate my changes. A lot happens when the page loads, and I want to get all of that out of my profile.

Isolate The Problem

Instead of loading the color sorter when the document is ready, I’ll make a second version that waits until I press a button to load the color sorter. This isolates it from the document loading and helps me profile just the code. I can change it back once I’m done tuning performance.

Let’s call the new function testColorSorter and bind it to a clickable button:

function testColorSorter() {
    makeColorSorter(.05, .05, .05, 0, 2, 4, 128, 127, 121);
    makeSortable();
}
<button id="clickMe" onclick="testColorSorter();">Click me</button>

Changing the application before we profile could alter the performance of the application unexpectedly. This change looks pretty safe, but I still want to run the profiler again to see whether I’ve accidentally changed anything else. I’ll create this new profile by starting the profiler, pressing the button in the app and then stopping the profile.

The second profile

The first thing to notice is that the decimalToHex function is now taking up 4.23% of the time to load; it’s what the code spends the most time on. Let’s create a new baseline to see how much the code improves in this scenario.

The second baseline

A few events occur before I press the button, but I only care about how long it took between the times the mouse was clicked and the browser painted the color sorter. The mouse button was clicked at 390 milliseconds, and the paint event happened at 726 milliseconds; 726 minus 390 equals my baseline of 336 milliseconds. Just as with the first baseline, I ran it three times and took the average time.

At this point, I know where to look and how long the code takes to run. Now we’re ready to start fixing the problem.

Make It Faster

The profiler only tells us which function is causing the problem, so we need to look into it and understand what it does.

function decimalToHex(d) {
    var hex = Number(d).toString(16);
    hex = "00".substr(0, 2 - hex.length) + hex; 

    console.log('converting ' + d + ' to ' + hex);
    return hex;
}

Each dot in the color sorter takes a background color value in hex format, such as #86F01B or #2456FE. These values represent the red, green and blue values of the color. For example, Blue dot has a background color of #2456FE, which means a red value of 36, a green value of 86 and a blue value of 254. Each value must be between 0 and 255.

The decimalToHex function converts these RGB colors to hex colors that we can use on the page.

The function is pretty simple, but I’ve left a console.log message in there, which is just some debugging code we can remove.

The decimalToHex function also adds padding to the beginning of the number. This is important because some base-10 numbers result in a single hex digit; 12 in base 10 is C in hex, but CSS requires two digits. We can make the conversion faster by making it a little less generic. I know that the numbers to be padded each have one digit, so we can rewrite the function like this:

function decimalToHex(d) {
    var hex = Number(d).toString(16);
    return hex.length === 1 ? '0' + hex : hex; }

Version three of the color sorter changes the string only when it needs the padding and doesn’t have to call substr. With this new function, our runtime is 137 milliseconds. By profiling the code again, I can see that the decimalToHex function now takes only 0.04% of the total time — putting it way down the list.

The third profile

We can also see that the function using the most CPU is e.extend.merge from jQuery. I’m not sure what that function does because the code is minimized. I could add the development version of jQuery, but I can see that the function is getting called from makeColorSorter, so let’s make that one faster next.

Minimize Content Changes

The rainbow colors in the color sorter are generated from a sine wave. The code looks at a center point in the color spectrum and creates a wave through that center point over a specified width. This changes the colors into a rainbow pattern. We can also change the colors in the rainbow by changing the frequency of the red, green and blue.

function makeColorSorter(frequency1, frequency2, frequency3,
                         phase1, phase2, phase3,
                         center, width, len) {

    for (var i = 0; i < len; ++i)
    {
       var red = Math.floor(Math.sin(frequency1 * i + phase1) * width + center);
       var green = Math.floor(Math.sin(frequency2 * i + phase2) * width + center);
       var blue = Math.floor(Math.sin(frequency3 * i + phase3) * width + center);

       console.log('red: ' + decimalToHex(red));
       console.log('green: ' + decimalToHex(green));
       console.log('blue: ' + decimalToHex(blue));

       var div = $('<div class="colorBlock"></div>');
       div.css('background-color', '#' + decimalToHex(red) + decimalToHex(green) + decimalToHex(blue));
       $('#colors').append(div);
       
    }
}

We could take out more console.log functions. The calls are especially bad because each is also calling the decimalToHex function, which means that decimalToHex is effectively being called twice as often as it should.

This function changes the DOM a lot. Every time the loop runs, it adds a new div to the colors div tag. This makes me wonder whether that’s what the e.extend.merge function was doing. The profiler makes it easy to tell with a simple experiment.

Instead of adding a new div each time the loop runs, I want to add all of the div tags at once. Let’s create a variable to hold them, and then add them once at the end.

function makeColorSorter(frequency1, frequency2, frequency3,
                         phase1, phase2, phase3,
                         center, width, len) {

    var colors = "";
    for (var i = 0; i < len; ++i)
    {
       var red = Math.floor(Math.sin(frequency1 * i + phase1) * width + center);
       var green = Math.floor(Math.sin(frequency2 * i + phase2) * width + center);
       var blue = Math.floor(Math.sin(frequency3 * i + phase3) * width + center);

       colors += '<div class="colorBlock" style="background-color: #' + 
           decimalToHex(red) + decimalToHex(green) + decimalToHex(blue) + '"></div>';
    }

    $('#colors').append(colors);
}

This small change in the code means that the DOM changes once, when it adds all of the div tags. Testing that with the timeline, we see that the runtime between the click and the paint events is now 31 milliseconds. This one DOM change has brought the time for version four down by about 87%. We can also run the profiler again and see that the e.extend.merge function now takes up such a small percentage of the time that it doesn’t show up on the list.

We could make the code one notch faster by removing the decimalToHex function entirely. CSS supports RGB colors, so we don’t need to convert them to hex. Now we can write our makeColorSorter function like this:

function makeColorSorter(frequency1, frequency2, frequency3,
                         phase1, phase2, phase3,
                         center, width, len) {

    var colors = "";
    for (var i = 0; i < len; ++i)
    {
       var red = Math.floor(Math.sin(frequency1 * i + phase1) * width + center);
       var green = Math.floor(Math.sin(frequency2 * i + phase2) * width + center);
       var blue = Math.floor(Math.sin(frequency3 * i + phase3) * width + center);

       colors += '<div class="colorBlock" style="background-color: rgb(' + 
           red + ',' + green + ',' + blue + ')"></div>';
    }

    $('#colors').append(colors);
}

Version five runs in only 26 milliseconds and uses 18 lines of code for what used to take 28 lines.

JavaScript Profiling In Your Application

Real-world applications are much more complex than this color sorter, but profiling them follows the same basic steps:

  1. Establish a baseline so that you know where you’re starting from.
  2. Isolate the problem from any other code running in the application.
  3. Make it faster in a controlled environment, with frequent timelines and profiles.

There are a few other rules to follow when tuning performance:

  1. Start with the slowest parts first so that you get the most improvement for the time spent tuning.
  2. Control the environment. If you switch computers or make any other major changes, always run a new baseline.
  3. Repeat the analysis to prevent anomalies on your computer from skewing the results.

Everyone wants their website to run faster. You have to develop new features, but new features usually make a website run slower. So, investing time in tuning the performance does pay off.

Profiling and tuning cut the final color sorter’s runtime by over 92%. How much faster could your website be?

(al) (km)


© Zack Grossbart for Smashing Magazine, 2012.


Building Books with CSS3

Building Books with CSS3

While historically, it’s been difficult at best to create print-quality PDF books from markup alone, CSS3 now brings the Paged Media Module, which targets print book formatting. “Paged” media exists as finite pages, like books and magazines, rather than as long scrolling stretches of text, like most websites. CSS3 allows us to style text, divide it into book pages, and set the page structure as a whole. You can dictate the size of the book, header and footer content, how to display cross references and tables of contents, whether to add guides and bleeds for commercial printing companies, and more. With a single CSS stylesheet, publishers can take XHTML source content and turn it into a laid-out, print-ready PDF. You can take your XHTML source, bypass desktop page layout software like Adobe InDesign, and package it as an ePub file. It’s a lightweight and adaptable workflow, which gets you beautiful books faster.

XML, XSL, XHTML, and PDF processors

As the publishing industry moves toward digital-centric workflows, there’s a need for scalability—repeatable processes and workflows that work at small and large scales. Creating a well-formatted printed book is no longer enough; publishers often need to release several different formats for every book: print, ePub for the iPad, Nook, etc., .mobi for the Kindle, and so on. The hardest jump is the one from print to ePub—you need to put plain text, often from multiple documents or text flows, and non-linear elements such as images, into a cleanly-tagged linear flow, and package it with a table of contents and instructions on how to tie together the various files that make up the book (see the ePub Wikipedia page to learn more about the extra special sauce that’s part of the ePub format). Even InDesign’s ePub output still needs a lot of extra cleanup after the fact, because of the non-linear nature of print page design.

For many years, XML has been one way to achieve a scalable multi-destination publishing model. XML offers a structured and standardized way to tag book content. It converts easily to XHTML, which is the foundation for digital books. It also comes with XSL-FO, which is markup that converts to print-quality PDF layout. XSL-FO has been both the gateway to XML-source publishing, and a major roadblock: it’s a powerful language for structuring pages and formatting XML files, but it’s also intricate, unapproachable, and not very well known. However, by using XSL-FO and a PDF processor like Antenna House or Prince to read the markup, publishers can use a single XML source to flow neatly into XHTML and ePub and also to produce fully laid-out, print-quality PDFs.

With the combination of major PDF processors and paged media features in CSS3, XML- and XHTML-based publishing can move away from XSL-FO to tap the vast and talented web design community. PDF processors Antenna House 6.0 and Prince 8.0 come with built-in CSS support, along with a slew of their own CSS extensions. These processors read tagged files and convert them to PDF using user-supplied stylesheets. The paginated PDF you get uses the same extensive CSS available for web design, in addition to the specialized CSS3 features added just for paged media, like text strings, cross references, and printer marks. [1]

Cost is a factor in adopting this kind of workflow. The PDF processor is the biggest upfront cost beside the initial stylesheet development. As of this writing, Antenna House costs $1,700 for a single user license, or $7,000 for a server license. Prince’s licenses are substantially less: $495 for a single user, or $3,800 for a server license. But compared to the ongoing cost of desktop page layout, a single upfront payment to install a PDF processor becomes a viable option. (Prince offers a demo version that watermarks the first page of each PDF but is otherwise fully functional. It’s a good way to experiment and evaluate the workflow.)

The open source command-line tool xhtml2pdf is built on python and can convert html to PDF for free, however the CSS support is much less robust than the for-pay tools, especially for CSS3 paged media features. Download the source code from GitHub. Here are some notes I whipped up after playing with xhtml2pdf for an hour.

Building a book

The new CSS3 features come from the Paged Media Module and the Generated Content for Paged Media Module (GCPM). I used the latest working draft and the latest editor’s draft of the Paged Media Module to develop my stylesheets. The spec is fairly stable and has entered the last call period (meaning the working group feels pretty good about it and is looking for final review before they recommend advancement). They’re still editing and it’s likely that they’ll release another Last Call Working Draft to finalize changes made during this review period.

The first step when working with print documents is to set up your page structure using the @page element. This is akin to master pages in print layout, through which you can set the trim size (i.e., page dimensions), borders, running headers and footers, fonts, and so on—basically anything that you want to appear on every page. And of course, you can still use cascades. For example:


@page {
  size: 5.5in 8.5in;
}

This code sets the trim size of every page in the book, which you can then build on to style different sections of your book. The following page definitions add margins and padding for left and right hand pages only in parts of the file that use the “chapters” page rule:


@page chapters:left { /* left page setup */
  margin: 0.75in 0.75in 1.125in 0.62in;
  padding-left: 0.5in;
}
@page chapters:right { /* right page setup */
  margin: 0.75in 0.62in 1.125in 0.75in;
  padding-right: 0.5in;
}

The page names are yours to create, and each named page can be further broken up into :first (which styles the first page within an element that uses that page rule), :left, and :right. Invoke page rules like this:


section.chapter {
page: chapters;
}

The Paged Media spec also has 17 predefined page areas that you can customize within your page rules. There’s the main page area, and then 16 other areas run along the edges, as follows:

top-left-corner top-left top-center top-right top-right-corner
left-top main page area right-top
left-middle right-middle
left-bottom right-bottom
bottom-left-corner bottom-left bottom-center bottom-right bottom-right-corner

You can style each of these page areas individually, if for example you want to add navigation tabs or running headers or footers (see below for more on those). The Paged Media Editor’s Draft has a great description of sizing and positioning of margin boxes. All but the corner margin boxes have variable widths (for boxes on the horizontal edges) or heights (for boxes along the vertical edges), and will stretch the full width or height available until they run into an obstacle (for example, neighboring content defined in one of the adjacent margin boxes). The example below adds a gray bleed to the outside edge of all index pages by adding a background color to just three of the vertical margin boxes. Because there’s no other content defined in the remaining boxes, the bleed will fill the full height of the page. You might accomplish a similar effect with a fixed position background image or by using page borders, but this method is simple, clean, and gives true bleeds (see Bleeds below).


@page indexmaster:right {
	@top-right-corner {
	background-color: #777777;
	background-color: device-cmyk(0.0, 0.0, 0.0, 0.5);
	padding-left: .8in;
	margin: -6pt -6pt -6pt 0;
	}
	@right-top {
	background-color: #777777;
	background-color: device-cmyk(0.0, 0.0, 0.0, 0.5);
	padding-left: .8in;
	margin: -6pt -6pt -6pt 0;
	}
	@bottom-right-corner {
	background-color: #777777;
	background-color: device-cmyk(0.0, 0.0, 0.0, 0.5);
	padding-left: .8in;
	margin: -6pt -6pt -6pt 0;
	}
}

To keep the bleed on the outside edge, the left and right pages need to be defined separately. The margins, padding, and margin boxes will all need slight adjustments for the corresponding left page bleed. (You may also have noticed that there are two color definitions in the above code; see CMYK Colors below for more about that.)

Counters

Counters aren’t new, but really come in handy for paged media, allowing you to add automatic numbering to chapters, figures, examples, and so on with just a few lines of CSS, like this:


section.chapter > div.titlepage > div > div > h2.title:before {
counter-increment: ChapterNo;
content: "Chapter " counter(ChapterNo);
}
div.figure-title:before {
counter-increment: FigureNo;
content: "Figure " counter(ChapterNo)"-" counter(FigureNo)": ";
}
section.chapter {
counter-reset: ChapterNo FigureNo;
}

In the above code, we created two counters, one for chapter numbering and one for figure numbering, and then reset them both starting at every new chapter. (Bear in mind counter-reset cascades, which means that if you want to reset a few counters on the same element but you define them separately, only the last definition will be honored. To get all the counters to reset, you need to run them together, as shown above.) Additionally, we used the ChapterNo counter within the figure title, to do things like this: “Figure 5-11:.” In this case, the ChapterNo counter is actually applied to the figure title’s parent element—section.chapter. The PDF processor will look progressively further and further up until it finds an instance of the specified counter that applies to the element in question.

Strings

You can turn almost any element into a string that you can then invoke in your CSS to appear in other places throughout your document. Headers and footers, where you have the page number and some text appear on each page, make good use of strings—for example, the book title on the left-hand page, and the chapter title on the right (CSS3 also includes some built-in handling for running elements; see below for why I chose to use strings instead).

Use string-set on any element to make the contents of the element reusable. Make up a name for it, and name the content you want to include:


div.book > div.titlepage > div > div > h1.title {
  string-set: Booktitle self;
}
section.chapter > div.titlepage > div > div > h2.title {
  string-set: Chapter self before;
}

In the top example, the name of the string is “Booktitle,” and I use the very simple “self” to say that I want the string to include whatever the content of that element is. In the second block, I tell the string to include both the content of the element, as well as any content I added using the :before selector (as I did to add with the chapter numbers in the Counters section, above).

To invoke the strings, reference them in the content property:


@page :left { /* left page setup */
  @bottom-left { /* verso running footer */
    content: counter(page)" "string(Booktitle);
  }
}
@page :right { /* right page setup */
  @bottom-right { /* recto running footer */
    content: string(Chapter)" "counter(page);
  }
}

Strings can be quite powerful and can include various types of content within the string-set property, including counters (I use the page counter in the above examples to display the current page number on each page as well), before/after text, and static text. You can also define multiple strings within one string-set property.

CSS3-GCPM actually includes special properties just for running elements: running() and element(). Used together, these properties convert any element into a running header or footer. However, the danger here is that when you convert an element to a running element in this way, it no longer appears in its original place: running() acts more like a float that also repeats on subsequent pages. Since I want my headers to appear both in their places inline and as running elements, I used strings instead.

Cross references

Most long documents (like books) include cross references, which usually look something like this: “See page 127.” Within an XML or HTML workflow, cross references can be set up as live links that jump to another section. Although live cross reference links are a basic feature for all digital books, including web-optimized PDFs, they naturally won’t be useful for the print book. However, since the source content is unpaginated, it’s hard to know what location the text should refer to. You won’t know the print page number until you send the text through the PDF processor, and in any case that page number is inaccurate when it comes to reflowable eBooks. The answer is to use generated text, which relies on target-counter(), and target-text().

For example, say you have this cross reference in your HTML:

<p>See <a class="xref" href="#section25" title="Working with Cross 
References">Chapter 5, <em>Working with Cross References</em></a>.</p>

By adding this style to your CSS:


a.xref:after {
  content: " (page " target-counter(attr(href, url), page) ")";
}

You’ll end up with:

See Chapter 5, Working with Cross References (page 127)

There are a few things going on in that CSS. First, we supplied a static text string that will add a space, an opening parenthesis, the word “page ”, and another space before any generated content. The next bit, target-counter, tells the renderer to pull in a specific counter related to the element. Then, within the parentheses, we tell the renderer that we need the “page” counter that applies to the href attribute of the element in question i.e., the renderer should follow the link to its source (#section25), figure out what page it’s on, and display that page number. To wrap it up, we have one last text string to add a closing parenthesis. If the pagination changes the next time we run the document through the PDF processor, the page number will update automatically.

The target-text() property takes things a step further by pulling in all the text from another element somewhere else in the document. For a simple example, let’s say we need to do something about a hard-coded cross reference to a print page number, like this one:

<p>See <a class="xref" href="#section25" title="Working with Cross 
References">page 110</a></p>
…
<h2 class="title" id="section25">Working with Cross References</h2>

Again, we want to make sure that the cross reference always displays an accurate page number, but we also want to include the name of the section being referenced to match the formatting of our previous example. And so, the following:


a.xref {
  content: target-text(attr(href, url), content())" (page " target-counter
  (attr(href, url), page) ")";
} 

will give us this:

See Working with Cross References (page 127)

The target-text property works much like target-counter—it follows the url to its source, and when we supply it with a value of content(), it pulls in the content of the element we’re linking to. The last piece of our cross reference is to add the referenced chapter number within the cross reference text. If we’ve already set up automatic chapter numbering using counters, as we did above in Strings, then we can pull that in as well:


a.xref {
  content: target-counter(attr(href, url), ChapterNo)", "target-text
  (attr(href, url), content())" (page " target-counter(attr(href, url), 
  page) ")";
}

For our desired end result:

See Chapter 5, Working with Cross References (page 127)

And now for an important warning: Antenna House won’t break generated text across lines. If the imported text is too long to fit in the page area, it’ll just stretch off past the page edge. Antenna House will, however, break static text strings that you include in the content property. For example, in the above, it will break anywhere in “Chapter “, “ (page “, and “)â€�, but it won’t break within the actual chapter title, or in the page or chapter numbers (though those latter two are so small, that it probably wouldn’t break inside them anyway). This makes generated text somewhat risky and only appropriate for short lines; more about this in the Footnotes section below.

Table of contents

A table of contents can be set up in the XHTML as a series of nested unordered lists, with each list item linked to the section in question. This works great for ebooks, but print books need to display the page number for the section as well. Just like cross references, you can use target-counter to set that up:


div.toc ul li.preface a:after { 
 content: leader(dotted) " " target-counter(attr(href, url), page);
}

The leader(dotted) function adds a leader tab between the text of the table of contents entry and the generated page number, like so:

Working with Cross References…………………………………….. 127

There are three predefined leader styles: dotted, solid, and space—or you can create your own string. For example, leader(“~â€�) will create a line of tildes.

Multi-column layouts

Multi-column layouts are another new feature of CSS3. They allow you to split any div into multiple columns using column-count. For example, to set only the index of a book in two columns, while leaving the majority of the text in a single column, add column-count: 2 to the index div:


div.titlepage+div.indexnote+div.index {
column-count: 2;
column-gap: 12pt;
}

The column-count property sets the number of columns, and the column-gap property sets the space between the columns. You can also add column-width to specify the width of two (or more) columns. The columns will span the entire available page area by default.

Breaks

If you’ve done digital book production, then you’re most likely familiar with CSS’ page break properties: page-break-before, page-break-after, and page-break-inside.

As defined in CSS2.1, page-break-before and -after accept the following values: auto, always, avoid, left, right, and inherit. You can use them to force breaks around elements, or use page-break-inside to prevent breaks from occurring inside elements. (This is useful for keeping all paragraphs of a sidebar on the same page, for example). Assigning a value of left or right will force a break until you end up with a blank left or right page, respectively. This is useful for book chapters, where you want every chapter to start on a right-hand page. You’d define the chapter div as follows:


section.chapter {
  page-break-before: right;
}

CSS3 adds a few extra properties for multi-column layouts: break-before, break-after, and break-inside. These function the same as the page-break rules, but at the column level, and add a few extra possible values: page (force a page break), column (force a column break), avoid-page (avoid a page break), and avoid-column (avoid a column break).

Footnotes

CSS3-GCPM adds special handling just for footnotes. First you’ve got the @footnote selector, which defines the part of the page reserved just for footnotes (if you’ve got any). We also have a new kind of float: float: footnote;, which is where the real magic happens. When you apply a float of footnote to an element, the entire contents of the element get floated down to the bottom of the page, into the @footnote page area. They lose the normal inherited formatting, and instead get styled with any formatting you’ve defined for the @footnote area. Additionally, at the point of reference, a marker is added (in superscript by default) that corresponds to the number (or symbol) next to your newly floated content. You can style the in-text marker, called the footnote-call, and the floated footnote number, called the footnote-marker with two new pseudo-elements: ::footnote-call and ::footnote-marker.

Now here’s the disconnect: my XHTML source files included all footnotes as endnotes, where the footnote text sat at the end of each section. My print design called for the footnotes to appear on the page on which they were referenced. In spite of this, I almost got footnotes working without any XHTML changes by just using generated text and the CSS3 footnote tools. Ultimately this plan failed because, as noted above, generated text in some PDF processors doesn’t like to break across lines but will instead just run off the margin if it gets too long. For books with footnotes just a couple of words long, there’s no problem, but that’s rarely the case. [2]

I ended up editing the XHTML to move the footnotes to the exact position where they’re referenced and wrap them in a span with class="footnote". I chose spans mainly because that would leave the footnotes inline, without adding an extra paragraph break (as a div or p would).

Here’s the new html:

<p>As you saw in the earlier section,<span class="footnote"><p>If you 
were paying attention, of course.</p></span> generated text doesn't break 
across lines.</p>

Yep, you’re seeing that right: we’ve got a p within a span within a p. It’s not exactly perfectly formed XHTML, but it does the trick. And with this simple CSS:


span.footnote {
  float: footnote;
}

We get this:

As you saw in the earlier section,1 generated text doesn’t break across lines.

1 If you were paying attention, of course.

Another part of the CSS3 footnote arsenal is a predefined counter—footnote—that applies to all elements with float: footnote. The footnote counter resets the same as any other counter (see Counters above), allowing you to restart footnote numbering as needed (for example, you might set the numbering to restart at the beginning of each new chapter).

You can customize the way footnotes are marked—with numbers, letters, symbols, or any other value supported in list-style-type. There’s also a predefined “footnotes” style that rotates through and then multiplies four different glyphs: asterisk, double asterisk, cross, and double cross. Footnotes will be numbered with decimal numbers like 1, 2, 3, etc., by default. To change to lowercase letters, you’d do the following:


::footnote-call { 
  content: counter(footnote, lower-alpha); 
} 
::footnote-marker { 
  content: counter(footnote, lower-alpha); 
}

Make sure to set the list type for both the footnote call and footnote marker, unless you want to seriously confuse your readers.

PDF bookmarks

Bookmarking is irrelevant when you’re dealing with print media, but is a handy (and I would argue, essential) component for web-optimized PDFs. Bookmarking adds a linked table of contents to the navigation panel of a PDF reader, allowing users to jump to specific sections. You can create bookmarks to almost any element, and you can tell the PDF how to nest and display the bookmarks all in your CSS.

Here we’ve got two levels of bookmarks, nesting level-one headings inside chapter titles. Instead of having all the levels expanded and displayed when the PDF is opened, we’ve set them to a state of “closed.” Users will only see the chapter titles, and can click to expand the tree and see the nested section headings if they wish:


section.chapter > div.titlepage > div > div > h2.title { 
  bookmark-level: 1; 
  bookmark-state: closed;
}
div.sect1 > div.titlepage > div > div > h2.title { 
  bookmark-level: 2; 
  bookmark-state: closed;
}

Bookmarks will automatically include the entirety of an element’s content, including any text you added with :before and :after selectors. However, you can restrict the bookmark to display only a subset of the element’s information by using the bookmark-label property. For example:

 
section.chapter > div.titlepage > div > div > h2.title { 
  bookmark-level: 1; 
  bookmark-state: closed;
  bookmark-label: content();
}

The example above will display only the actual text of the element, and ignore any before/after content. Note that all text is imported without any formatting, and you can’t specify combinations of content values within a single bookmark-label declaration.

You can also choose to display a specific text string that will overwrite the contents of the HTML element. For example, if you want to add a bookmark to the copyright page, but the words “Copyright Page” don’t actually appear anywhere in the text:


div.copyrightpage { 
  bookmark-level: 1; 
  bookmark-state: closed;
  bookmark-label: "Copyright Page"
}

Fonts

When it comes to adding custom fonts to your CSS, you may be relieved to know that it’s the same old CSS you’re used to: use @font-face to declare the font, and use font-family to invoke it. Remember to include fallback fonts, especially for body text where you may need to use symbols that aren’t included in your main body font set. Again, this is the same CSS that people have been using for ages:


font-family: "Gotham", "Arial Unicode", sans-serif; 

Arial Unicode includes a huge number of glyphs, and so is usually a pretty safe sans-serif fallback.

Most commercial printers require fonts to be embedded in every PDF file. The methods for this vary depending on the PDF processor, so you’ll need to read the documentation carefully if you want to build embedded fonts into your workflow. You could also embed fonts after conversion with PitStop or another PDF post-processing tool.

There are a lot of nice features for fonts coming with CSS3, but they’re still unstable and neither Antenna House nor Prince has added support yet (though Antenna House—and Prince to a more limited extent—has some nice extensions for working with fonts). Check out the Fonts module to get a sense of what’s coming. Development that improves text formatting on a larger scale, including specifying word- and line-breaks, spacing, and so on is underway. Prince and Antenna House have implemented some of the features to varying degrees, as they had been defined at the time of release. You can check out the spec, though I encourage you to check with your PDF processor’s CSS reference before you experiment, as there may be variations.

Final touches for printing

There are a few final steps to take if you’re planning to print your document commercially.

Image resolution

Image resolution is crucial for printed media. A general guideline is to set each image’s resolution somewhere in the 200 to 300dpi range (specific requirements depend on each book’s needs). Most PDF processors will impose their own default resolutions on images during conversion, but you can choose to preserve the resolution of the source files instead:


img {
image-resolution: from-image;
}

You can also set the value to normal, to let the processor choose the resolution, or you can provide a specific numerical dpi value. (Messing around with image resolution is tricky, though, so do your homework first!)

CMYK colors

You should be thinking about CMYK colors throughout building your stylesheet. You specify CMYK colors similarly to how you specify RGB colors:


hr {
color: device-cmyk(0.0, 0.0, 0.0, 0.3);
}

Each value should be a number between 0 and 1 (percentage values actually also work, though only the decimal values are endorsed by the W3C spec right now). Specify the percentage of Cyan, Magenta, Yellow, and Black ink to be used, in that order. You can also build that in with fallbacks by stacking color definitions, for cases where you need to repurpose your stylesheets for multiple presentations (web, print, etc):


hr {
color: #B3B3B3;
color: device-cmyk(0.0, 0.0, 0.0, 0.3);
}

If the device reading the code doesn’t understand CMYK, it’ll use the web-friendly version.

Printer marks and bleed

During commercial printing, books are actually printed on a larger page size than the final version, and are cut down. The cutting is usually pretty exact, but can vary up to a few sixteenths of an inch. So, to ensure that any images or colors that you have at the edges of the page will actual lie on the edge of the page without strips of white being left during the cropping process, you need to set them to run off the page edge a bit, just in case, and then you’ll need to tell the processor to render that little bit of extra stuff beyond the edge, and to add crop marks to guide the printer:


@page {
  bleed: 6pt;
  marks: crop;
}

It’s that easy. Of course, you’ll need to be creative with bleeding elements, using negative margins and positioning to get them to actually bleed—the processor won’t automatically add extra color or content beyond the limits of the element, it’ll only show content that already exists.

Final notes and further reading

You can read through the full list of CSS that Antenna House supports, but I warn you that the documentation is limited at best and not always clearly worded. Prince’s documentation is slightly better.

Both Antenna House and Prince have their own extensions built on top of the standard CSS3, which are worth checking out. Here are Antenna House’s extensions. Prince’s extensions are listed inline with regular CSS support, and are less robust. Additionally, if the CSS documentation isn’t helping, it may be useful to read the documentation for the related XSL-FO property. They've been in use longer and are more fleshed out, and the functionality is usually the same or very similar. I wasn’t able to find documentation on Prince for this, but here is Antenna House’s documentation.

Remember that CSS3 is still a developing spec; CSS3.info keeps a fairly up-to-date list of the status of the various CSS3 modules. Don’t let that stop you from dipping a toe/foot/leg/neck in the water, though! Here, I limited myself to some book-building basics—page dimensions and margins, cross references, strings, headers and footers, and printer-friendly colors, images, and bleeds—but CSS3 has a lot more to offer when it comes to paged media, and I encourage you to see how much you can do (and remember, CSS2.1 still works, too).

References

[1] If you’re starting with XML source files, you’ll find it much easier to convert to XHTML first before styling with CSS. Luckily Bob Stayton already built the XSL to help you do that: http://sourceforge.net/projects/docbook/files/epub3/.

[2] Because where’s the fun in footnotes if you can’t wax poetic a little bit?

Translations:
Italian


RSS readers: Don't forget to join the discussion!


A Case for Responsive Résumés

A Case for Responsive Résumés

Finding a job is easy. As a job seeker, having your résumé in .pdf format is all you’ll ever need. Creating a clean résumé in HTML5/CSS3 which scales well to different viewport sizes is a futile exercise.

All lies! Here are four reasons why it’s a great idea to author your résumé in HTML:

  1. Static résumés become quickly outdated. A single, unified URL assures a recruiter or agency that your résumé is always up to date.
  2. A potential employer may view your résumé on a smartphone. Tethering our résumés to .pdf format is outmoded. Do you really want to trust a stiff, unresponsive .pdf to represent you?
  3. Editing .pdf files can be a painful experience.
  4. A DIY HTML résumé shows potential employers how much you love what you do, which can never hurt your chances.

Let’s look at the requirements for our responsive résumé.

  • It must be easy to maintain.
  • It must look spiffy.
  • It must scale well to smaller devices.

It must be easy to maintain

Evaluating document maintainability comes down to this: how efficiently can we locate and update various parts of the document? The easiest way to achieve maintainability is to create minimal, clear markup. So that’s exactly what we're going to do.

Examining the source, you’ll notice nothing shocking. After a simple header, we’ve established two columns, and each column houses various article elements. In just a few lines of HTML, our markup is complete.

It must look spiffy

Your résumé needs to look as awesome as you are, so we’ll call the CSS cavalry for assistance. Using the mobile-first approach, we define responsive rules for smaller viewports (less than 520px wide). Why did I choose 520 pixels as the media query breaking point? This particular design looks a bit too condensed at sizes smaller than 520px. The number is completely arbitrary and specific to your own design.

A little flair isn’t a bad thing, so I added a simple CSS transition toward the bottom of our media query which adds a nice touch in supporting browsers. Browsers that don’t support transitions will ignore it. Enlarge your webkit browser from small (less than 520px) to large to view the transition.

.date-ranges {
    width: 15.4639%;
    transition:all .3s ease;
    -o-transition:all .3s ease; 
    -moz-transition:all .3s ease;
    -webkit-transition:all .3s ease;    
}

It must scale well to smaller devices

Resize the demo and test liberally. Our design is mobile-friendly and still retains its good looks.

Where can I use this?

If you have space on a server, you can store your résumé there, so that you can point a recruiter or agency to your always-current URL. LinkedIn users know that, at the time of this writing, no field exists in a user profile to add a résumé or CV URL. For now, we’re stuck with the old meat and potatoes document upload. Sadly, this is the case on many other popular job-hunting sites as well. And that's exactly why I’ve written this article, to freshen the stale air we’re breathing.

As many grizzled job veterans know, a sharp résumé and near-flawless interview may still leave you short of your dream job. Competition is fierce and never wanes. But finding new ways to distinguish ourselves in today’s unforgiving economy is vital to a developer’s survival.

Translations:
Italian


RSS readers: Don't forget to join the discussion!


Developing A Design Workflow In Adobe Fireworks


  

Every designer has their own workflow when starting a new project, even if it’s only loosely defined in their head. A typical Web project goes through a variety of steps from inception to launch, with a lot of moving parts throughout the cycle. Photoshop, Illustrator, Fireworks and even Web browsers themselves are available to aid us in our work. But with so many choices, how do we determine the right tool to move from concept to functional design?

Developing A Design Workflow In Adobe Fireworks

Over the years, I have come to rely on Adobe Fireworks as the main workhorse among my design applications. It’s built from the ground up to create screen-ready graphics; it’s object-oriented by design; and it’s lightning fast for creating UI elements. While Photoshop has made great strides lately by adding some vector support, it simply has not been able to match the speed and reusability of Fireworks for production work. Read on to get a glimpse of my project workflow (sketches → wireframes → graphic comps → export) and to see how Fireworks fits into these different stages.

Sketches

Sketching is arguably the most valuable part of my design process. In terms of workflow, this step isn’t specific to Fireworks, but it’s still a crucial part of getting my ideas flowing.

Dribbble shot by Joshua Bullock
Sketched icons

Dribbble shot by Joshua Bullock
“Quest� (another sketch on paper)

Sketched designs can be done simply with paper and pen or created directly in Fireworks, and they can end up being works of art in and of themselves. I start most projects with sketching in some shape or form, and I use a few different techniques depending on the time and materials available.

High-Fidelity Sketching

Hi-fi sketching is a great option. It allows the designer to forgo the digital tools and break out the pencil, pens and paper. Peter Buick’s recent post “The Messy Art of UX Sketching� outlines this in far greater detail than we can here, so check it out. Because high-fidelity sketches exist on paper, they have permanence; and collaborating on sketches is easy by passing them around, drawing on them and making notes about necessary changes. But by all means, make copies of your work; I wouldn’t want to get angry emails saying that I told you to let others draw all over your beautiful illustrations!

High-fi sketches can provide good guidance for development
Hi-fi sketches of mobile screens and interactions

“But why should we start with sketching?� you might ask. The reason is because getting caught up in pixel-precision this early on in a project by going straight to digital is just too easy, and it’ll cost a bit of time in the long run. Remember, Fireworks is all about speed and production, and dropping back to pencil and paper is both a fast and easy way to get your ideas out so that you can start iterating. For those of you who truly enjoy the old-school ways of pencil and paper, here’s a selection of templates built specifically for that purpose. I’ve used these for both mobile and desktop website designs, and they can really help keep your UI consistent and speed your sketching along.

Do not be afraid to explore lots of concepts
Don’t be afraid to explore many concepts and iterations.

Sharpie and a Big Pad of Paper

Using a simple Sharpie or other marker and a big pad of paper is quick, inexpensive and fairly low-fi (meaning there doesn’t need to be as much detail). This lets you capture big ideas and quickly define broad concepts in the design. You can pick up a Sharpie and a huge pad of paper at a local office-supply shop. Throwing away or recycling these drawings is not a problem either — they’re not exactly pages in a sketchbook.

Quick aside: When David Gray interviewed Jason Fried of 37signals, they spoke about exactly this type of low-fi sketching. Gray drew the notes of their conversation, and this fascinating sketched conversation can be seen on Gray’s website. The “big pads of paper� mentioned by Fried in the video can be found on Edward Tufte’s website.

Jason Fried on Design
Jason Fried on design

Pro tip: Sketches can help define site maps and user flows in the absence of a project brief. Are you making a brochure website, a CMS, or a single-page design with tiered layers driven by JavaScript scrolling? Sketching your designs can help cultivate your ideas and reduce design time.

Whiteboard and a Camera

This is the option I usually default to, because a whiteboard offers the same speed as a Sharpie and paper but making changes is easier, and you’re not wedded to particular ideas. A whiteboard is impermanent, and it makes for a great projection surface, with collaborators being able to suggest changes in a meeting room. Large whiteboards can be expensive, but you should be able to find smaller whiteboards at your local office-supply retailer for prices that won’t break the bank. I keep a poster-sized whiteboard (24 × 36 inches) at home for just such occasions.

Different logo concepts - do not be afraid of revisions
Your concepts don’t have to carry heavy detail — just capture the big ideas.

Sketch in Adobe Fireworks

One of the most beautiful features of Fireworks is that it allows you to create vector objects but also offers full-featured bitmap editing. Fireworks supports Wacom tablets and pressure sensitivity to a degree, but it’s not nearly as fluid as what’s available in Photoshop. That being said, Fireworks does allow you to “paint� vector strokes, and I’ve done this with varying degrees of success. The advantage here is that, while it may not be quite as free-form as traditional media, you don’t have to jump through additional hoops, and your sketches will already be on a digital canvas.

Pro tip: When using a Wacom tablet for sketching, use a large canvas size, such as 2500 × 2500 pixels. Because tablets are sensitive, drawing on a small canvas accurately can be difficult. With a large canvas, you get better control and can zoom in to add fine detail.

In my typical workflow, I toss my initial ideas onto a whiteboard, snap a photo of the board with my iPhone, and email it to myself (or save it to Dropbox). At that point, it’s easy to pull the sketch into Fireworks to start building a wireframe in layers on top of the photo.

Snapping a quick picture with a mobile phone or point-and-shoot of a whiteboard sketch
Snap a quick picture of your sketch with your mobile phone, and email it to yourself.

Photos of sketched materials can work well too
Photos of sketches work well if you don’t have a scanner.

Wireframing

Thinking in Patterns

When building a wireframe in Fireworks, one of the most important things is to think in patterns. This doesn’t mean using the design patterns or common interface conventions that users often look for in a design, such a text box for site-wide search. Rather, it means thinking about whether certain elements should share similar formatting throughout the design? Items in a sidebar, content lists, user profiles and photos are all good candidates. Fireworks can already help by creating these content blocks as reusable UI elements in your document library. You can select a group of objects and convert them into a single symbol (we’ll talk about creating symbols soon), and then simply drag it from the document library onto the design as needed. If changes are needed, simply update the library symbol, which will update all other instances throughout the document.

Pro tip: 960.gs is a popular CSS framework for creating fixed-width designs. A Fireworks extension for 960.gs is available that automatically creates guides spaced out for the framework. If you’ve already made the jump to responsive design, check out Matt Stow’s Export Responsive Prototype, which exports your Fireworks slices to simulate a responsive layout when you create reflowed designs as separate pages. And if you have no idea what the difference is between fixed-width and responsive design, we’ve got that covered, too.

Creating Pages

I’ll typically start with the header, along with other UI elements that repeat through the website, such as the search box and sidebars. I can then take these elements and define them in my “masterâ€� page in the Pages panel. By doing this, any new pages I create will share these elements. They remain locked and on their own layer, so I can design more freely and save time by not having to reconstruct them for each new section that I add to the website. To create a master page, right-click on an existing page in the Pages panel and choose “Set as Master Page” in the pop-up menu.

Creating your first Master page (Master page drop down menu)
Creating a master page

This is really where pattern-based thinking helps. Will your sidebar have its own background colors and texture? If so, you might want to define this on the master page. However, if some pages will expand to the full width of the design, then defining a sidebar here might not be the best solution. Pages have their own unique properties, including canvas width and height, resolution and exporting options, which we’ll discuss later. Hopefully, these ideas will help you identify good candidates for master pages. Webdesign Tuts+ offers a great video tutorial by Connor Turnbull titled “Getting Started With Fireworks: Using Master Pages, Pages and Web Layers.� Remember that pages can have unique dimensions, which is a huge advantage in Fireworks. Adding your header to the master page is fine, because it is anchored at the top of the browser window, but the page’s length can vary. The footer is probably not something to include on the master page, but it can be used very powerfully as a library symbol, so let’s look at symbols next.

Pages in Fireworks help define repeatable sections throughout your site, defined on the master page
All new pages now include repeatable elements defined on the master page — headers, footers and sidebars that are easy to update.

Creating and Using Symbols

Returning to the concept of reusability, the document library in Fireworks can be an indispensable tool for items you intend to reuse. Library symbols can contain groups of objects, enabling you to quickly replicate blocks for a CMS. Need a log-in form in the form of a modal dialog to appear on multiple pages? Create that as a library symbol, complete with the background overlay in the size of your canvas, and drag it from the library to your canvas to illustrate the effect. If you need to make changes to the log-in modal dialog at that point, those changes will be reflected in every instance of the symbol, on every page, on every layer!

To create a symbol, select the objects that you’d like to include (for example, in the footer), and choose “Convert to Symbolâ€� (Modify → Symbols → Convert to Symbol, or press F8 on your keyboard). The text, shapes and anything else you had selected are now available from the Document Library panel, and you can drag the symbol onto the pages as needed. Later, if you decide to make changes to the footer symbol, just make the changes once and they will propagate to every page on which the symbol appears!

The Document Library is where all of your symbols are stored
You’ll find any symbols that you have created in the Document Library panel.

Noupe has a great collection of reusable Fireworks library objects that can be used for prototyping and design. Also worth mentioning is the fantastic Fireworks Wireframing Kit website by Hannah Milan, another great place for UI components.

Graphic Comps

Once the client has approved the wireframes, we can jump into enhancing the website’s underlying skeleton with high-fidelity design. Fireworks allows us to make this transition without ever leaving the application — we enjoy the same functionality of multiple pages and library objects, but now we can add gorgeous photography, beautiful typography and striking color enhancements, all in this one program.

Vectors and Bitmaps

Now that we’ve created the wireframes, we’re ready to get the color and typography flowing. As mentioned, Fireworks combines both bitmap editing and vector object creation in a single powerful package. I usually create as much as possible in vector format because the files are scalable and can be reused for Web and print. The vector editing tools in Fireworks are easy to use, and many of the features you’ll find in Illustrator for manipulating vector objects are available here, too. Editing tools for bitmap and vector can be found in the Tools toolbar, and there is a separate panel for combining and editing vectors (the Path panel).

Fireworks offers bitmap and vector editing tools all without having to leave a single application
Fireworks offers both bitmap and vector editing tools.

Vector drawing created in Fireworks (original art by Erin Potter)
A vector drawing created in Fireworks

Layers, Sub-layers, Groups

In Fireworks, layers work more like they do in Illustrator than in Photoshop, so keep this in mind. Both layers and individual objects can be named, which helps dramatically with exporting if you need to send the graphic files to another designer or developer. I usually name my main layers according to the overall sections of the comp, and then place objects into sublayers to keep them organized. Layer names such as “header� and “twitter block� clearly communicate to other designers which elements of the UI are where in the layout. In addition to layers, Fireworks also supports the grouping of objects and arranging of individual objects and symbols from front to back. This provides an additional level of control when you’re overlapping objects and effects.

Property Inspector Panel

Arguably the single-most powerful UI component in Fireworks is the Property Inspector (PI) panel. The PI panel can be normally found at the bottom of the screen when you first open a new document in Fireworks. Fills, strokes, gradients, patterns, object position, scale and opacity, blending modes, live filters, text properties and much more can all be defined quickly and easily from the PI panel. It’s a convenient place to quickly inspect and change the properties of all kinds of objects! And let’s not forget about Live Filters, which are the secret sauce for making Fireworks a fast tool for production.

Many people ask where the true power of Fireworks lies relative to Photoshop. The answer is the features and behavior of the PI panel. It is your one-stop shop for a vast amount of tweaking. If you’ve ever used Dreamweaver, you’ll be familiar with the panel floating at the bottom of the screen and the myriad of controls it offers.

Object, text and canvas controls are all conveniently laid out in the Property Inspector panel
The PI panel provides controls for text, bitmap and vector objects, live filters, compound shapes, the document canvas and more.

Applying (Live) Filters

Just as we apply adjustment layers and effects in Photoshop, we can apply live filters to objects in Fireworks, and these are all assigned in the PI panel. When you use filters in library symbols, such as glows and drop shadows, they are considered a part of the object and can cause the x and y positions of that element to fluctuate. Live filters can also be applied to symbol instances so that their positions better line up with your grid. It really depends on whether you need the filter to appear in every instance of the symbol or not.

Live filters can also be combined and stacked on top of one another, and they’re multiplicative, which means you can apply more than one instance of the same filter to an object. For example, you can create a very thin, heavy glow around an object, and then apply a secondary glow of another color that’s lighter and more diffused, making for an entirely new treatment. Live filters can be edited at any time simply by double-clicking the filter that you’ve applied and changing its settings. Additionally, live filters can be rearranged by dragging them into a new order, giving you substantial control over applied effects.

Fireworks live filters are placed on any object through the Properties panel (PI panel)
The live filters magic happens in the PI panel.

Keep in mind that using live filters is different than applying filters via Fireworks’ top menu. Live filters remain editable, whereas “regular� filters do not, so I’d recommend using live filters by default. That being said, live filters can affect how much memory Fireworks uses. If your design becomes too complex, you can branch a single UI component or section of the page into its own file to maintain editability, then flatten the layers and bring that object back into your primary comp as a bitmap.

Fireworks vectors and effects scale well for creating icons
Iconography created in Fireworks

Exporting

Now that we’ve converted the wireframe into a high-fidelity full-color design, it’s time for the transition to a fully functional website using HTML and CSS. We’ll use Fireworks’ superior compression and exporting abilities to pick apart different parts of the design to be used as background images for headings, buttons and even tiled backgrounds.

Defining Slices

When the design comp is completed, it’s time to export the image files for use in the browser. Slices work similar to those in Photoshop; they allow you to define a section of the graphic comp as a flat bitmap image to use on the website or in the CSS. But Fireworks has the additional benefit of allowing us to define specific optimizations and file formats in different slices of the same document. GIF, JPG and PNG images can all exist in the same Fireworks document, and you don’t have to leave the app or go through multiple passes of file exporting, as you might in Photoshop or Illustrator.

Slices exist on their own Web layer above the rest of the design, so they’re easily toggled on and off with the number 2 on your keyboard (or using the eye icon next to the Web layer).

Slices can quickly be toggled on and off
Slices can quickly be toggled on and off in their own layer.

You could manually draw slices with the Slice tool from the default toolbar, but because Fireworks is object-oriented, you can simply select your object or group and choose “Create sliceâ€� (Edit → Insert → Rectangular Slice). The slice will be created automatically and set to the size of your object, including any live filters that you’ve applied.

Pro tip: Use the Slice tool to quickly determine the size of an object or icon to ensure that live filters such as glows and drop-shadow filters are not inadvertently cropped out of the final image.

Fireworks slices also enable us to define different parts of the overall comp using unique optimization, naming and file formats, and it gives us one-click exporting options, saving all of these parts in a single location on our computer. No need to get creative with cropping or creating separate files — it’s all done within Fireworks. Simply select your objects and choose Edit → Insert → Rectangular Slice (Alt/Option + Shift + U), then go to the Optimize panel and either select from the presets provided by Fireworks or define your own settings for each slice.

Slices are the secret power of Adobe Fireworks
Slices are the secret power of Fireworks, enabling you to quickly define elements in the design for exporting.

Keep in mind that backgrounds are part of the slice, but these items can easily be placed on their own background layer with the visibility toggled off, giving your buttons and other UI elements full alpha transparency, thus maximizing their versatility.

Pro tip: You can quickly export slice objects after having made minor adjustments. Simply right-click the slice and choose “Export selected slice� to send the image out with your pre-defined settings. This also works when selecting multiple slices, each with their own optimization options. Keep in mind when using this technique that if you’ve changed the image “scale� in the exporting options (say, to create a thumbnail or a website preview for a WordPress theme), then you’ll need to go back into the export preview and reset the size to 100%, or else your sliced exports might look squished.

Exporting Defaults

Slices can either inherit the default exporting option for the file format (set in the Optimize panel) or be unique; meaning you can set a single slice to export as a JPG, while the rest of the image exports as PNG or GIF. This affords tremendous control for different parts of your graphic comp. Many times I’ve also created a separate page in my file titled “Exportsâ€� for background sprites and toolbars, which keeps my original image intact — very helpful in the event that the client wants to see the proposed changes. Simply select the relevant UI elements from the design, create a new page, and paste your objects into this new canvas. Once you have the UI elements for the sprite, you will easily have the exact pixel locations to plug into the CSS.

Pro tip: Fireworks saves natively in PNG format (with added meta data), which is easily viewable in a browser. I’ve used this feature in a pinch to quickly show graphic comps to clients and coworkers. But beware: multi-page layouts can get pretty big, which affects downloading time. Also note that the first page in a Fireworks document is what’s shown as the default view of the Fireworks PNG.

Exporting Options

Once you’ve created your slices, or if you’re simply exporting the entire comp to show a client, you’ll be taken to the exporting window in Fireworks. This works similar to the “Save for Web and Devices…� preview in Photoshop and Illustrator. Here you can once again change the level of compression, as well as see a live preview of the image in different file formats.

Export Preview gives us a quick look at sizes and quality of exported image
Export Preview gives us a quick look at the size and quality of the exported image.

You can also control the scale of the graphic — very helpful when you’re designing an icon for multiple devices and platforms (the standard and Retina-sized images for the iPhone display come to mind). You can also export HTML along with the images; export with or without slices; and save the file for use in other applications such as Photoshop or Illustrator.

Pro tip: Use the “Constrain proportion� options and scaling in the “File� tab to quickly export snippets of the design for posting to websites such as Dribbble or for promotional images for a feature area.

Try It Out

There you have it: a super-short synopsis of how to take your sketched ideas to wireframes and all the way to full-color graphic comps using Adobe Fireworks. The power of vector and bitmap editing, the easy and fast control over reusable objects, the excellent live filters and the very good compression and exporting options all make Fireworks a powerful tool for any (screen) designer.

Many of you already own a copy of Fireworks, having bought Adobe Creative Suite, but have simply never opened it up. It doesn’t cost anything to fire up this dormant app and see whether it provides some enhancements to your workflow. Why not give it a try? A streamlined workflow awaits!

Further Reading And Resources

(al) (mb)


© Joshua Bullock for Smashing Magazine, 2012.


  •   
  • Copyright © 1996-2010 BlogmyQuery - BMQ. All rights reserved.
    iDream theme by Templates Next | Powered by WordPress