W00t! Happy to say I've been accepted as a speaker at the upcoming D2W Conference in Kansas City. I'll be talking about using Adobe Fireworks to wireframe and prototype mobile applications and web sites. It will be my first conference of the year, and I'm very excited to hook up with friends and make new ones. D2W is a designer/developer mobile workflow conference, it's goal being to improve communication and share workflow ideas between designers and application developers. 

Now in it’s second year, it’s definitely gaining in popularity and has attracted a great range of presenters, including yours truly.

Early Bird Pricing in Effect

If you book the conference before April 1, 2011, you’ll receive a $95 Early Bird discount on conference registration.That’s right, until April 1, the conference fee is only $200! After April 1, the registration fee increases to $295 (still a great deal), so you’re saving practically 30% by confirming by the end of March.

And if you’re looking for more in-depth sessions, D2W has them as well:

• Introduction to Adobe Fireworks CS5 with Dave Hogue
• InDesign to iPad Workshop with Pariah Burke
• Creating a Portfolio With WordPress with Justin Seeley
• COOP Hands On with John Farrar

These hands-on sessions will run on Thursday July 14 as a pre-cursor to the conference, which begins on Friday. What a great way to whet the digital appetite!

So if you’re a digital professional and you’re hankering for a fantastic way to network and learn at the same time, reserve yourself a spot at D2W this July.

I attended an excellent web cast last night, held by Dave Hogue. Dave is a user experience and interaction designer and uses Fireworks for building wireframes and prototypes every day in his position as Director of Information Design at Fluid Inc. in San Francisco.

In the web cast, Dave demonstrated several of the techniques he uses to keep his Fireworks files trim and organized, and shared many tips with us on how to streamline our own workflow process. This 30 minute web cast was recorded and is time well spent if you are learning about or working in the interactive design field. Be sure to check it out.

I'm very happy to announce that my latest book, Fireworks CS5 Classroom in a Book is now available!

This revised edition builds on my first Classroom in a Book (CiaB), and covers new topics such as wireframing, working with Device Central, and exporting to Flash Catalyst.

Based on user feedback, I've also included more information on the relationship between Fireworks and Photoshop. The CiaB's are not intended to dig deep into other software. The focus needs to remain on the main product, but I did find more information about integration between the two programs. There are even a few improvements to integration since CS4.

I had an excellent Tech Editor; our very own Sheri German made sure this was the best book it could be and was an invaluable resource and friendly ear for me.

And as in the last book, I wrote too much, so there are two bonus chapters included on the disc that comes with the book, along with all the exercise files, so you can work right along with me in each lesson.

If you're new to Fireworks, I don't think you can go wrong by picking up a copy. And what do you know? Here's a handy link: Amazon.com

If you do pick it up, please let me know what you think of the book. I'm always looking for suggestions on how to improve it.

If you were able to watch the CS5 Launch event today, you might have wondered what happened to Fireworks.

You weren't alone.

I'm very happy to say though, that Fireworks CS5 is alive and well - and AWESOME! Fast, stable and easier to use than ever, the Fireworks team did an amazing job fixing bugs (900+) and addressing legacy issues.

Over the next couple weeks, I'll be releasing a series of videos showing you some of the new features and enhancements, starting with a summary of my top features, which will be out early this week.

I'm also relieved I can finally say, I've been writing the new Fireworks CS5 Classroom in a Book. It's been fun - and challenging - and I think this version is even better than my first go-round for the CS4 Classroom in a Book.

So even though Adobe didn't say anything in the launch, I can safely say that you will be very happy with the CS5 version of Fireworks.

For a quick heads up, check out Bruce Bowman's article on the Fireworks Developers Center.

Well, it' been a long time coming, but I'm very happy to hear that the Adobe  Fireworks team is working on a Fireworks CS4 patch to fix the Snow Leopard crash on quit bug, as well as other high priority crash and data loss bugs that they're aware of.

Adobe is expecting to release the update in the second quarter of 2010.

In the meantime, on the Fireworks Team blog, Bruce Bowman is asking all Fireworks users to submit bugs they want addressed, via the Feature Request and Bug Form. The FW team is paying close attention to the bugs filed here. It's very important though, to be as detailed as possible when reporting a bug, so the team can track it down. If you think you've hit on a bug, try to reproduce it and record the steps you took in order to do so. It's also helpful to know what other software was running at the time, and what your hardware configuration is.

I hope this comes as good news for many.

I'm very excited to announce that my latest video training title is now available on lynda.com!

Recorded earlier this summer, the 4.5 hour course discusses and walks you through wireframing, storyboarding, interactive HTML prototyping, in a far more in-depth manner than my Essential Training title is able to. I also introduce you to creating Flex skins, exporting MXML and exporting FXG.

I had a lot of fun putting this course together and I think it will be a great resource for anyone wanting to learn more about using Fireworks for prototyping web and other interactive projects such as AIR applications.

Here's a quick run down of the main lesson topics:

• Rapid Prototyping Options in Fireworks
• Wireframing
• Storyboarding
• Multi-page Mockups
• Adding Interactivity
• Creating AIR Prototypes
• Creating Flex Mockups
• Going Further with HTML Prototyping

Hey Everybody!

I'm picking through my idea file for new tutorial concepts for Fireworks and I thought I'd put the request out to you, our faithful CMX subscribers. Is there something you've been dying to know about Fireworks? (or Photoshop or Dreamweaver or ~insert favorite app here~ . . .)

And what about the types of articles? Creative? Technical? Workflow? Business oriented?

Drop by the Community Clubhouse forum and share your thoughts and ideas.

W00t!

A very exciting day, yesterday; I received my shipment of books and I must say, I'm very happy with the overall production quality of the book. It's pretty cool to see all the illustrations in full color!

Sporting a bright banana-yellow cover (you almost need sunglasses!) the book definitely stands out. Kinda like some of my shirts . . .

In the next few weeks, I hope to release a few excerpts of the book here on CMX, so stay tuned.

It should be in bookstores soon, so if you're interested in learning FW from the ground up, make sure to check it out.

Have you ever wondered if (or how) you can add an iframe to a Fireworks prototype? What about inserting a SWF? Or adding some jQuery functionality?

Well, I just finished reading a truly excellent article at the Adobe Developer Center, written by David Hogue and Mariano Ferrario that takes protyping with Fireworks to the next level.

The article shows you how to leverage CSS, JavaScript and HTML using Fireworks and Dreamweaver to create a highly interactive HTML prototype. There's a great synergistic result when you combine the design capabilities of Fireworks with the coding strength of Dreamweaver. 

If you're interested in prototyping, head on over to the Adobe Developer Center and check out this article.

Ahhhhhh! A huge sigh of relief and great sense of accomplishment are the two things I am feeling most at the moment. As the headline states, the very first Classroom in a Book for Fireworks is off to the presses.

I'm so freakin' excited!

The book has a total of 11 lessons, plus two supplemental lessons on the CD which accompanies the book. Just like other CiaB's, the artwork is included so people can work along with the same assets I used in the book. Some of the assets are supplied by - or inspired by  - Adobe, and some are my own, including several photos.

I think this will be it for me on the book scene for a while, but I have some other projects in the works, including some new video titles with Lynda.com . . . and of course, I'll keep writing here at my home away from home, Community MX.

I'll keep you posted on the release date.

When I write and speak, I often talk about using em units to size layouts giving the user the ability to resize the entire layout if they change their font size. In fact, chapter 5 of the book I co-authored with Greg Rewis is an entire project based on em units. Until all browsers zoom, this is my personal preferred method. My personal site is built using this method.

Last year, I wrote a blog post about Scaling fonts using em units and how I saw that affecting different types of users. A comment was made recently, and I wanted to address it in a new post while sharing a couple charts I made for myself. The comment said:

"A simple calculation as 1pt equals 1px at 72dpi (MAC) so:
1pt equals 1.33px at 96dpi (PC}
12px (pt) font in MAC is therefore 16px in a 96dpi PC.
If you have a parent element with a 11 pt font then to convert px dimensions to em you divide them by 14.63 (11pt x1.33) Dont interchange pt and px on a PC."

First I'd like to address using points for the screen on either a Mac or a PC. Simply don't do it. Ever. Points are for print. I regularly use points (as well as inches and serif fonts) when I create a print style sheet. I updated an article recently called From screen to print: Creating a print CSS in Dreamweaver published both at Community MX and Adobe's Devnet Center. One thing it addresses is how to use pts for print style sheets.

Until 2000, Macs used a 12px browser default and PCs used a 16px default. We got used to seeing different things (and due to the 72dpi vs 96dpi difference, it was further compounded if points were defined). I'm under the impression (but can't find anything quickly to back it up) that the 72/96dpi issue is no longer a problem. If anyone can point me to a recent reference confirming or denying that, I'd love it. Either way, all current browsers on both platforms now use 16px as their font-size default.

A while back, I was messing around for my own entertainment (you know, partying on a Saturday night or something) and created a couple of charts that might be helpful. The first is font size equivalencies. This chart shows that setting the font to 100%, 1em, 16px, 12pt and medium are equivalent in the same font. It also shows how font sizes can vary greatly from font to font.

The second chart was an exercise showing divs sized using em-units with a variety of font sizing. The red line down the right side is a graphic at 800px. The body's font size is set to 100% (16px). The first three divs show the default font sizing with the divs set to three different widths. The second section shows all divs set to 50em with the font-sizing (placed on the div) set to different units. It's an interesting exercise if you'd like to more clearly understand the effect of font sizes on the size of an em unit.

The interesting thing to me in the second chart, based on the gentleman's comment in my blog, was that viewing this chart on both a mac and a pc the lengths of the divs are the same. Yes, there's a very slight difference in actual font size on the PC - two of the lines of text slightly wrap to the next line - but the 50em width of the div is still exact on both platforms. Are we really that different anymore?

Well, MAX San Francisco has come and gone. What an experience; 5000+ geeks attending a single event!

Seriously, it was a great event and I had the opportunity to meet and mingle with many new people. There were also a few networking opportunities as well. Both my Fireworks Mock Up labs were full, and I saw several other very interesting sessions and labs. I for one, was very impressed by the number of Fireworks sessions that were available.

Yep, the secret is out! :-)

On my return, I was informed by a very happy publisher that 28 copies of my book sold in the MAX Store during the event, which made me very happy as well.

I know I promised pics much earlier, but I've just gotten around to getting them online. So if you want to see a few shots from the event and a few from the aquariums at the California Academy of Sciences, head on over to my flickr site.

Enjoy!

I'm very proud to announce that Adobe Fireworks CS4 How-Tos: 100 Essential Techniques will be available October 20, 2008. It was a heck of an experience and I owe a big thanks to Kim Cavanaugh who was my tech editor.

You can learn more about the book here: http://www.peachpit.com/store/product.aspx?isbn=0321562879

I'm very excited about the book. I think it's a great introduction to Fireworks.

So there's been a pretty decent sized debate going on through the webosphere. Designers should know how to code. Developers should know how to design (or shouldn't need to design). I considered weighing in on the 37 Signals blog -- but the comments were already closed. Call me slow (yes, I've been on the road, had a birthday, and had my mom visiting with her birthday. ;). You'd be right. Oh well.

I do have one thing to say. Well, I probably have more than one, but I'll start with that. I recently did a couple sessions at the HOW design conference. One was on "Mistakes Print Designers Make on the Web." Yes, I definitely agree there are common mistakes from the print paradigm. Many times I can tell how people's brains work when they ask for help on lists. I can tell they don't understand the web or come from a print background. However, that does NOT mean I think they are useless. Do I think they should know how the web works? That the web is a fluid, not static medium? Am I willing to help them learn (if they're going to be in my "designer stable")? He77s yea. I am willing. Because I think they are very important to our industry.

Do I think that coders should not use a graphic medium. Lord no. "Designing" (or so they call it) using the constraints of "what's easy to do with code" is really a sad, and less attractive, way to work. I say bring on the tough comps -- we'll work it out, or we'll ask for a small revision. We'll come up with a way to make it work accessibly. A way you might not have thought of before -- but a way that is equally lovely. But lord knows I think you design types are valuable. I quit designing years ago. Why? I'm a tweakaholic. I make more money hiring people that are more creative, better trained and faster. My clients save money with those same people. The designers are freed to be their creative selves -- but yes, it's nice for me if they understand the web. It's nice if I don't have to lead, guide, explain. That said, because I know my craft, I'm willing to help them at the beginning. And no, I don't expect them to know how to code. Just to have an overall understanding that the web is not print. Everything will not have line breaks where they want it to. It won't be glued down. But I, with my experience, will guide them through what can and can't be done. In time, they will be one of my favorite designers. They will understand, but they will send it to me to code. Because that's what I do best.

Do you create the site with HTML? Do you create it without a graphic program? Well, gawd bless you. But I'd venture to say your designs are likely boring. I think 37 signals rawks in usability. I have no bad words to say about them. But what I'm seeing from their recent blog posts in this area is just silly. And no, I've never seen a super creative design come out of that group (at least that I KNEW was from them. I'm certainly not barring it).

Personally, I welcome the challenge of the design minds. I find that if I create the site IN HTML, I do what's easiest to do with HTML/CSS. I don't challenge my abilities. I don't push the envelope.

Yes, the site is about the content -- the message. People are generally looking for information on the web. I teach that all the time all over the world. But there's another side of it. There's the package that same content comes in. Is it readable and usable? Good. That's important. Does it work when the text size is large. Does it work with assistive technology. Excellent. Accessibility is even more important. But goodness knows that a majority of your readers are going to be influenced by what it looks like. Yes, even the colors. Study color psychology. Look at eye patterns. Immerse yourself in usability and interaction. Heck, watch your mom try to navigate things -- I just did. It's eye opening. How it looks is important. Sorry, that's just the facts. Why do you think company's spend so much on their Superbowl commercials?

And let's not leave out how you interact with the database -- how well that content dynamically appears. How much sense it makes. How usable the interface is. There are many things to think about. The root of my story and my point is -- it's the rare individual that has all the strengths needed for one web site. It's the team that matters. Should everyone have a basic understanding of the other member's jobs? How they work? What they can accomplish. Oh yes. Absolutely. Should they be able to do them? That's just ludicrous. Absolutely not. Surround yourself with people more brilliant than yourself. Always learn. Work hard. You, and those around you, will be enormously successful.

Ciao.

TODCon will be here very soon. Yep, I'm counting the days. OK that's not the secret.

It'll be great to hook up with some CMX friends and regular TODCon attendees and speakers. Well, that's no secret either.

I've written the last three CMXtraneous blog posts! That's more of a shock than a surprise, though. 

I'm pretty stoked about the Fireworks public beta. The Fireworks engineering team has done a phenominal job. It's to the point now where I don't like going back to CS3. Yeah, not really a secret there either, the way I've been blabbing all week long about it.

The secret is my second TODCon session. It will be a live demo of the new features in the Fireworks Public beta! We'll look at some of the cool features you've read about in my recent articles as well as Kim Cavanaugh's piece on the Path panel. Based on what you've read and heard this week, I hope you pull up a chair for my session.

Alan Musselman from Adobe will also be presenting a session on Fireworks. He'll no doubt have some very awesome and cool stuff to share as well.

I'm looking forward to seeing everyone. I'll be the guy with the loud shirt and - new this year - a limp (sprained my ankle and pulled a tendon a couple weeks ago YEOUCH). Feel free to have pity on me and buy me a martini or at least help me to the gift shop for a new fashion statement. ;-)

Tomorrow, I get on a plane to Web Design World Chicago. It looks like it's going to be a great conference. If you're in the area, come on over and join in the geek fun. Jeff Veen, Jared Spool, Dan Rubin, Joe Marini, Greg Rewis and more!

Then it's on to HOW Design in Boston followed by Multi-Mania in Brussels, Belgium, TODCon in Orlando and finally Web Down Under in Sydney. The organizers have worked hard, and done a great job on all these conferences so be sure to come to the one closest to you. You will not regret it. Promise! Grab me in the hall if you're there. I love to meet people. :)

As the title indicates, my Fireworks article is now live on Adobe Edge. Feel free to check it out. I'm quite happy with the end result and I hope you gain some insights on the Fireworks work flow as well.

I have covered this topic in both written and video form here on CMX, but in this article, I atcually take someone else's single page design and build it out into a series of interconnected pages.

Enjoy! 

Keep your eyes peeled for the April issue of Adobe Edge because yours truly is making a guest appearance.

Here at CMX as well as in my teaching, I've been focusing recently on using Fireworks to create click-through prototypes, and establishing best practices for one's FW workflow. With the evolution of Fireworks, it's much easier to create these interactive mock ups quickly, allowing more immediate client feedback/approval of a site's design and flow. The beauty of this process is many changes are made early in the design stage, rather than during the coding process.

As designs get more complex, it becomes even more important to set up some best practices for workflow. This helps in case you have to revisit the design weeks or months down the road. It is also very helpful if you have to pass on the design to someone else.

My article on Adobe Edge will focus on the creation of a click-through mock up from a finalized multi-page Fireworks PNG file.

If you've not heard of Adobe Edge before, here's the low-down:

Adobe Edge is a free electronic newsletter that comes out every couple months. It features content for web designers and developers, covering stuff going on at Adobe and the web in general. While the focus is about Adobe and what it's doing to make web-life easier, the magazine also covers things happening outside "the mothership."

For example,  February 2008's issues has this list of contents:

• Adobe Media Player: Understanding the structure of the RSS feed
• BlazeDS and what it means for the developer community
• The edge of Flash
• Comparing Adobe Flex and Ajax development models
• Project profile: Virtual life on the International Space Station
• Quick tips for integrating Adobe Creative Suite 3 products
• Open source at Adobe

You can either check out the Edge every couple months, or subscribe to it online. I hope you get a chance to read the article and find it useful.

OK, so I'm reading ALA (A list apart) on the latest new thing to come out of the web standards group, something Microsoft intends to implement in IEv8. One of the biggest issues we web developers face in developing web pages is the varied version of browsers and code compatibility. If you look at the offerings here at CMX, you will find, from time to time, articles that address this in some manner (as in, for IEv6, you need to include; for Firefox, include; for IEv7 do this and for IEv5.x, try this - oh and Safari v1, just give it up). The proposed idea is to implement a meta tag which allows you to specify the browser engine to render the page with - for example, if you specify IEv8, when IEv9+ comes out, it is rendered with the same, prior, version of IE, v8. The goal of the standard would also to be allow multiple browsers to utilize this same functionality so that Firefox, Safari and the rest could also use this to render pages in prior engines for their product line (so I could specify IEv8, FFv2 and Safari v3, for example). The implementation will look like:

<meta http-equiv="X-UA-Compatible" content="IE=8" />

The articles went on to talk about the prior attempt to have web pages rendered differently using the doctype declarations. Both articles are a good read (not so much on the comments to the articles). It is my opinion that this is a good thing. I believe it will allow us to create a work on the web and not have to freak out when the next version of whatever comes out, worried our sites will break. I also believe it will aid us in transition from one browser to the next. Likewise, I have a couple concerns as well - how well will the future browsers render prior versions? and if I have a site created for IEv9 and you have IEv8, what happens? The articles from ALA are:

Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8
From Switches to Targets: A Standardista's Journey