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

If you have read my most recent article, Tools for Designers: del.icio.us and Flickr', I made mention of starting a CMX Blog piece for anyone interested in sharing their design and inspiration tools,resourceful solutions for their business, and for self-organizational purposes.

Please leave a comment on this post to share your thoughts. I look forward to seeing what you're up to and if I can get new ideas and be inspired by your ideas.

Happy blogging!

Yes, it's rather embarrassing, but I admit it. I have a Facebook account. Though I resisted for a long time, I was recently convinced to join Facebook to participate in a birthday prank for a friend. Oh well, another social time sink.

On Facebook today, I was invited to join a group called "Blue Beanie Day." November 26th has been named Blue Beanie Day, in honor of Jeffrey Zeldman's photo, donned in a blue beanie, on the cover of his book, "Designing with Web Standards." It's a day to stand up and show our solidarity around accessible web development using Web Standards. And besides that, it'll just be plain fun!

Here's how it works:

1. Buy, beg, or borrow a Blue Beanie and take a photo in it. Heck, you can even take a picture with your camera phone at the mall trying one on if you don't want to buy it. Maybe you'll put a beanie on your head or change a black beanie to blue with Photoshop. Be imaginative. Take a cool group photo of you and your friends wearing Blue Beanies. The possibilities are limitless. Show your beanie creativity.
2. Post your photo, or photos to Facebook, the Flickr pool, and other social networks on November 26th, 2007. Remember to switch your profile photos that day on all your social networks, like Flickr, Twitter, Last.fm, iLike, Pownce, Dopplr... you name it.
3. Promote Blue Beanie Day in your blog or wiki starting today. Tell all your friends to get ready for Blue Beanie Day. If you have a Facebook account, join the group and invite all your Facebook friends to this event.

You can participate without a Facebook account too. Just grab a beanie, make it blue and join in! See you there.

Seems Comcast thinks that they can interfere with your web usage on their network.  Apparently, if you have Comcast, you no longer are paying to use the bandwidth as you want - Comcast has determined various applications and services just aren't allowed.  Things like peer-to-peer file sharing, other VOIP providers, Lotus email and FTP.

So, if you have Comcast and you've been noticing things not working right, it isn't your computer - nor your browser (for once!) - it is your ISP meddling in what you are allowed to do.  Most likely they have a government mandated monopoly where you're at too, so you can't move to an ISP interested in just giving you service.  If you have Comcast, make sure you let them know you do not appreciate their business practice and, if you can, leave.

Comcast violates net neutrality with this move and if those with Comcast don't make it an expensive business decision, other ISPs may feel emboldened to do the same.  If they are taking an inch and not stopped, they will eventually make sure the only Internet service we get will be through their mutual business partners... 

We get a lot of positive feedback about our JumpStarts. They are a great way to kick start the design and production process and can really speed up development time. They're so great, I use them myself!

Last month I was approached by a personal trainer who needed a web site. A friend had been promising for about 4 months to make one for her but at the time she contacted me, nothing had yet materialized. My client was serious about promoting her business and really wanted to get her name on the web. As a small business owner, her budget was not very large and while her site was going to be fairly simple, she really wanted someting clean, professional and contemporary.

Enter CMX JumpStarts. After my initial meeting with Caroline, I experimented with a few JS's, and decided that Traverse City woud be the perfect answer. Opening the PNG in Fireworks, I created my own custom banner and navigation icons. When I was happy, I exported out full size jpegs for my client to view. With some tweaking, the design got a green light and I jumped right into development.

The site took less than a month in real time before it went live (that was tonight - woo hoo) but in actual production hours, it took less than a week. Traverse City saved me a lot of time and as a result saved my client a fair chunk of change, too.

There's still work to be done - we're nailing down keywords and she has set up a photo shoot so we can get some current shots of her and what she does on the site. But that's the beauty of a web site; as long as the site appears whole and complete, you can continue to add to it as new content becomes available.

If you have a chance, check out GRIT Conditioning for some Great Results in Training! 

There's no black and white distinction between what constitutes plagiarism and what doesn't. Sometimes its obvious, but often it's not clear if a new piece has crossed over the murky line. This includes design plagiarism.

An outside organization asked my employer for permission to use one of our web site designs for their own site that they wanted to create. I'm the designer of the site in question. We've explained to the organization that they may use the HTML and CSS from our site if they put a credit to me as the original author of the CSS inside the code — after all, markup is not really something you can copyright, especially the simple, no frills stuff I used on this small site.

But we've having trouble getting them to understand that though they can be influenced by the design, as any designer can, they can't blatantly copy it. They can have a similar layout and look, but they can't use the same images or content. This organization definitely wants to work with whatever guidelines we give them — they don't want to violate our copyright or step on our toes at all — but they don't appear to understand the distinction yet. I can't blame them.

How do you distinguish between sites that just have a similar style or layout and sites that are copies? I remember my art teacher in high school always telling us that we had to make our art at least 30 percent different from whatever source file we were using as inspiration (usually a National Geographic photo, since we had a whole floor to ceiling cabinet of old issues). I have no idea where she got this 30 percent figure from, and I still don't really know how I would evaluate if something was 10 percent different versus 40 percent different.

I gave the person who requested our design this guideline to tell if his design was plagiarizing or not: Once your design is different enough that someone could conceivably believe you created it without ever having seen our design, you should be safe. If someone came across your design and accused you of copying our design, could you reasonably defend your work by saying you'd never seen our site before, that it's just a coincidence?

By this, I don't mean to imply that if someone saw both designs they would have to be able to see no similarities, but rather that there could be some possibility the two designs were created independently. They could think it's possible that one used the other as a starting point, as long as they could also accept the possibility of the opposite.

Do you think this guideline holds water? Is it too loose? Too restrictive? Do you have a more precise way you determine what is just inspiration and what is copying, in terms of web design? I'd love to hear your thoughts on this in the comments.