Articles

2011 certifiably rocked for Typeoneerror in terms of laying the groundwork for the growth of our small business, so I'm happy to welcome my good friend and game designer Sean Monahan to the Typeoneerror team for 2012. Sean started last week as T1E's first Senior Product Designer. He adds to our capabilities of product design for web and mobile significant Flex/Flash, PHP, and C# experience as well as game and product design badassery (not to mention his fine hand-crafted homebrew). His talent for immersing himself in and quickly adopting emerging technologies such as Node.js, Stage3D/Starling, Unity, XNA, et al make our technology offerings, to be frank, quite staggering.

I'm personally very excited by what we are going to be able to create and learn together. We will continue to develop and incubate amazing products for our clients as well as kicking off exciting new ventures on our own products and games. As a small business, we will provide beautifully designed products for iOS, Android, and Windows Phone 7 platforms (among others) and continue to make great experiences for desktop and mobile web.

You can follow Sean on Twitter at @noobsarepeople2 and you should and feel free to stop in for a visit in our office in Ballard, Seattle any time. Here's to a new year!

Original image from dontoine, idea courtesy of @seantron

This week was an incredibly rough week for Flash and Flex Developers. Adobe announced that it would cease active development of the Mobile Flash Player, choosing instead to focus on developing tools, solutions, and browser processes targeting "universally supported" (accuracy of this statement somewhat dubious) HTML5. The Flash Platform will continue to be developed in what seems to be a more focused manner—the Flash Platform being streamlined to mobile applications packaged with Adobe AIR and more innovation with tools related to gaming and video. That's great, and it's really not news if you consider it. Adobe has regularly been mentioning this direction over the past few years and this sounds in line with its inability to attain the Flash Player's same ubiquitous installation base in the mobile space as in the desktop space.

The major pain was more sharply felt when Adobe dropped their second bombshell of the week: the announcement that Flex would be donated to an open-source foundation and that "[Adobe believes that] HTML5 will be the best technology for enterprise application development." For developers who've invested many years in Flex development, I'm sure this felt like a solid punch in the gut. This was no more apparent than in a mass-flash-developer community video chat last night where many developers cried foul on Adobe's handling of its "abandonment". Topics included...

• How are we supposed to explain to our clients that Flex is a viable technology for their Enterprise product when the makers of said technology are saying what amounts to "HTML5 is better?"
• What's the migration plan?
• Where are my HTML5 tools that allow me to start making kick-ass HTML5 apps right now?

These and other questions were posed, often in a tone of considerable vitriol. Well, I'd like to address some of the statements and questions made during this chat. Naturally, these are completely my opinion, so feel free to tell me yours at @typeoneerror on Twitter. I wrote some of these somewhat ranty sections while listening to the Flash community video chat last night so they aren't really in any meaningful order.

"How do I explain this to my clients?"

Communication is everything. Adobe certainly has made this clear with their lack thereof. With your clients, present the facts and the facts only. Your client ultimately pays you to develop their Enterprise product, so if they decide that their application should run on iPad, you need to solve that problem for them. You cannot look to solve creative problems with a technology-first mindset. It's a square peg/round hole situation; trying to apply Flash to everything is somewhat foolish. Is interactive even the best solution to your client's problem? Maybe it's a motion graphics piece instead? You cannot blame a corporation if you cannot answer that challenge, only yourself, right? Can I package it as an AIR app? Will I have to completely remake it using HTML5 technology? Which leads to...

"Flash is better than HTML5!"

Of course it is (and you know it so well, so that helps), but that's not what this is about. You need to be able to provide your clients with business solutions. That could be a Flash app, that could be an HTML5 app, hell, it could be a knitted wool cap...the point is, if it makes sense for the client, then that's the tool you should use. If you don't like the HTML5 technology stack and don't want to do web development with its technologies, you should focus your considerable skill on something else. Simple, right? Again, communication is key. Manage expectations. "You want that massive enterprise app rebuilt in HTML5? OK, not a problem, let me just be clear it's going to take twice as long and cost twice as much." That's the reality. That would be your or your client's decision to weigh whether that cost is a good business decision.

"Now I have to do browser/device testing."

No, you don't; not if you don't want to. Think how easily your Flash API knowledge could be applied to Unity 3D, or decide to pick up C# and focus on XNA gaming and push apps to Xbox, Windows and Windows Phone 7. Pick up Objective-C and make iPhone apps (check out the Sparrow Framework inspired by the Flash API!). The point is, don't be completely tied to a single technology. Performing quality assurance is just about the worst part of being a web developer, so if you don't want to do it, you may have to try a platform that is a bit more locked down.

"It costs more to develop in HTML."

A boatload more—tell me about it. Boy did I love the days back when I was the technical director at BKWLD when all we did was develop Flash sites. Save, Publish, Upload...hey QA is done! So, HTML apps take a bit more time to QA. You should factor that into your costs if an HTML app is the best solution for the project. Simple as that. BKWLD recognized the value of a non-flash product a few years ago and split the company in half to form the successful ground(ctrl). BKWLD's music sites prior to this were generally 100% Flash. ground(ctrl) has these same clients, but different technology. Expectations managed. It is not Adobe's responsibility to provide solutions for your clients, it's yours. If Adobe's corporate decisions aren't working out for you, move on to something that does.

"Javascript sucks, performance sucks[, I hate life]."

Hell yeah, it does (one could argue that the DOM sucks, not .js, but I digress), but so did ActionScript 1. Holy crap, did it suck. Look at ActionScript now; AS3 is easily my favorite language to write in to this day. Again, don't like JavaScript? Don't pursue it. Perhaps try a language that doesn't suck. Ruby. Python. C#. Objective-C. As a Flash and Flex developer, you can pick up any of these languages in a week or even a weekend. It's just syntax, right? Maybe even try Node.js!

Find some new stuff you like working with and offer those as solutions for your clients. For an example of this, how about following two Sean M's I know. Sean Monohan (@noobsarepeople2) is building a XNA-based game at the moment which has a Node.js backend and level editor. Guess what Sean does during the day? Flex developer. If Sean had to give up Flex completely today, I know he'd be happy to try other things. I know the guy just wants to make cool games, regardless of the technology. Having interests outside of his client work allows him that freedom. Sean McCracken (@seantron) is a Unity 3D development and also does iOS and Android development. He also works at Red Interactive (where I'd guess he does some Flash work here and there). Again, point is that you can apply all this Flash Platform knowledge to other pursuits. It's not giving up on Flash, it's just broadening your creative approach.

"Show me one good HTML5 app."

Facebook.com. Bigger than any enterprise app you've ever built, guaranteed. What is an HTML5 app anyway? Look at their doctype. <!DOCTYPE html>. Is this HTML5? Yes and no. Very little actual HTML5 markup, lots of modern web technologies used that we are now lumping under the HTML5 masthead. Point being, web technology that is not plug-in dependent. An application does not have to do what Flash can do to be successful.

"Adobe left us with no migration plan."

Learn new shit, and learn it now. Adding to your stable of product offers only increases your marketability. Adobe will eventually create some rad new tools for HTML and Javascript development (or they won't and they'll just keep adding one feature to Photoshop per year for the next decade...who knows...I know I'm planning for it) and we'll all be set for the next round of internet.

No one in their right mind will say that Adobe has a great history of PR and communication with its developer base. It's also a corporation. If you decide to put all your chips in with a single technology, you will eventually get burned. Tech moves too fast. But what have you learned in your many years of Flex and Flash dev? Personally, Flash gave me a unique way at looking at product development. Besides teaching me object oriented programming, the Flash Platform helped me learn asset management in a programming context, how to programmatically animate assets, and especially important, I feel, is a distinct separation of concerns between logic and visuals. As Joel Hooks (who happens to be one developer who makes me confident that Flash has a great future ahead of it) succinctly put it "your skill-set is not the Flash Platform"; it's creating rich interactive experiences. This overarching knowledge can easily be applied to other platforms and technologies. You should certainly continue to develop in Flash (I do, and I still love it), but diversify.

"I can't make Enterprise apps in HTML5."

This is just a cop-out to me. Unless your enterprise app is a asset-heavy game, video/streaming presentation software or something similar (the places where Flash excels according to Adobe), there's no reason you cannot build an incredibly successful HTML-based application. You can also likely charge more for it because it'll likely be inherently more difficult to produce.

"Adobe betrayed us."

Reality check: Adobe is a corporation. They will make business decisions that make sense (in theory) for them monetarily. As a developer, you've got to make tough decisions about which technologies to devote time learning. If you've been doing nothing but Flash development for the past decade, that is a huge gamble. One that probably paid off very well for you until late (I paid the bills as a Flash dev for close to 6 years). In this case, it's time to—as they say in finance—diversify your portfolio. Risk management and reduction.

New Standards

In Adobe's press release, they state that Flash "has repeatedly served as a blueprint for standardizing new technologies in HTML." This could not be more true, and will, of course, continue to be true. Flash is incredibly powerful; the majority of the cool functionality we are now seeing being recreated in modern "web" technologies all have roots in what Flash enabled us as creatives to do. Full screen, responsive, liquid layouts; effects; animation; video; et al. So what if HTML5 isn't perfect yet; the technology will move faster than any individual can learn it, so it won't take long (just compare Flash 4 to Flash 8) to catch up.

Spoon

Looks like the open-source foundation that will be taking over the Flex SDK is Spoon.as. And perhaps "taking over" is a misleading phrase; the SDK's development will still be lead by developers from the Flex SDK team; it just won't be backed by Adobe (seemingly).

Having a look at the people on the board of directors, it's clear to me that the Flex SDK will continue to be a viable platform for the foreseeable future. In fact, "removing" it from Adobe's clutches may be the best thing for it in the long run (less bureaucracy, more code, right?). Looking at something like the Robotlegs community/team, again, I'm confident that as long as the Flash Player itself continues to be developed, there'll be lots of room for Flex and AIR projects. Some clients and companies will start using more HTML5 technologies, but there'll be plenty that will settle—nay, opt—for the amazing capability of the Flash API internally and for Enterprise solutions. If you really want the Flex/Flash community to thrive, I'd imagine the best thing you can do is sign up to support Spoon.

My personal plan

1. Support Spoon.
2. Continue to let Adobe know that Flash is an important platform by using it to make kick-ass applications and games.
3. Support awesome projects like Robotlegs.
4. Use Flash where it makes sense and achieves client goals, and
5. Use HTML5 and supporting technologies with the same intent.

Thanks for reading. Hopefully you found these thoughts positive and useful. Please let me know if so.

For any developer—regardless of seniority—estimating the time you think a development task or project will take can be a daunting task. I was reminded of this again recently after I read software engineer @jaimeohm's heavily re-tweeted tweet about what makes "us coders" special: "We are expected to know how to do things we've never done before and estimate how long they will take." Where seniority becomes a factor is having more experience and being able to more accurately guess how long a thing will take. Of course, this isn't an issue unique to software engineering, but the problem is that people without this experience (CEOs, Project Managers, n00bs, et al [I'm generalizing here]) often just think that a coding task is just opening up a text editor and putting some text in there. It's never quite that simple: It's thinking about scale, maintenance, communicating with teams and clients, installing software, setting up environments, research, discussion with designers, user experience—all that comes with creating a product. In short, you need to estimate for the entire project and not just the "writing code" part of it.

With this in mind, it's important to not only pad your time estimates a bit, but also communicate immediately with your team or managers when a task is proving more difficult than estimated, i.e. you estimated incorrectly. You cannot worry about this effect; it will happen. You should plan for it to happen and managers should not get upset when an estimate falls short. Once you're actually working on the task, the absolute worst thing you can do is to sit frustrated with a bug or issue and not enlist the help of fellow team members or keep your team aware that you are stagnating. We all know the experience of spending hours on a tricky problem, only to solve it in 5 minutes with a fresh pair of eyes after a good night's sleep. Having a buddy take a look at your problem can often solve that immediately. Ask questions; lots of them. Absorb everyone around you's knowledge. If someone knows about a library you've been asked to use, ask them for tips. Typically, most developers understand the pain and will happy to help you estimate (seriously, hit me up on AIM any time if you want to chat).

Now, padding time might sound like a negative thing (especially to your clients), but, in the end, you're setting a budget expectation, so when you do end up completing that feature more quickly than expected, your producer is happy, your client is happy and you've potentially made your company some profit. Don't forget than some features will take longer than expected so now you may have time to work on another feature that you underestimated or add that really kick-ass feature to surprise and delight your team and client.

I thought I'd share a recent example of how coding projects are often less about code and more about the things you don't estimate and the things most people don't see. Below you'll find a sample from a project log I wrote during the development of a Ruby on Rails application. I had done some Rails when it was version ~0.9, but had not touched it in it's modern incarnation (which was 3.0.9 when this was written), so I was basically starting from scratch. For the budget, I estimated based on the time that something like this would have taken me to produce in PHP (the language I use the most frequently) and added a bit of extra time for the unknown. You can see in this log that 90% of the work I'm doing has absolutely nothing to do with writing the code. I of course didn't expect to run into *any* of the issues in the log since I had never done it before, but now with this experience, I know to factor in some extra time to get my environments all ready to actually get to the "writing code" stage or I can estimate lower since I know how it works now.

gem update --system

gem update

rails new app --database=mysql

bundle install

sudo gem install mysql2

gem install mysql2 -- --with-mysql-config=/Applications/MAMP/Library/bin/mysql_config

brew install mysql

/usr/local/Cellar/mysql/5.5.14

gem install mysql2 -- --with-mysql-config=/usr/local/Cellar/mysql/5.5.14/bin/mysql_config
Building native extensions.  This could take a while...
Successfully installed mysql2-0.3.6
1 gem installed

bundle install

rake db:create

socket: /Applications/MAMP/tmp/mysql/mysql.sock

brew install mongodb

gem 'bson_ext', '~> 1.3'
gem 'mongoid', '~> 2.1'

rails generate mongoid:config

require 'active_record/connection_adapters/mysql2_adapter'
require 'active_record/connection_adapters/postgresql_adapter'

ActiveRecord::ConnectionAdapters::Mysql2Adapter::NATIVE_DATABASE_TYPES[:big_primary_key] = "BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY".freeze
ActiveRecord::ConnectionAdapters::PostgreSQLAdapter::NATIVE_DATABASE_TYPES[:big_primary_key] = "bigserial primary key".freeze

# In order to properly set up single collection inheritance,
# Mongoid needs to preload all models before every request in development mode.
config.mongoid.preload_models = true if Rails.env.development?

# mongoid has overridden activerecord as the default orm so any attempts
# to generate migrations or ActiveRecord models will fail. Therefore we
# must configure our default generators so we can still use activerecord.
config.generators do |g|
  g.orm :active_record
end

namespace :db do

  desc 'Drop and recreate the database and reseed it.'
  task :reboot => [:drop, :create, :migrate, :seed] do
    puts 'Database rebooted.'
  end

  desc 'Recreate the database with a blank slate.'
  task :clean => [:drop, :create, :migrate] do
    puts 'Database cleaned.'
  end

end

How do you estimate? Let's talk about it on Twitter @typeoneerror.

I was very excited to attend the Seattle stop of the An Event Apart tour this year. Last year I was out of town when it happened and was bummed. Thankfully I got my ticket early this year and was able to schedule it in advance.

I went expecting to be excited about HTML5, Standards and CSS3...the usual. And I was; many talks were exactly what I thought they'd be; cool new technology and topics that felt somewhat familiar already. However, I came away with knowledge I wasn't privy to previously and felt this information was more important to my work and my business as a whole.

Day One

Jeffrey Zeldman

Jeffery Zeldman kicked off the conference with a humorous yet insightful coming of age story of the internet. Full of lots of little anecdotal, quotable quips; it was quite enjoyable.

Jason Santa Maria

Brooklyn's Jason Santa Maria was a great presenter. He talked about web fonts and how they are creating new opportunities for designers; he also touched on typography as a whole.

I learned that being able to discern between a typeface's characteristics will help able you to select similar fonts or choose a contrasting typeface. Santa Maria also indicated that typography was largely an art of contrast (as is much of art). Juxtapositions are what make typography interesting.

He also talked about relationships between color, weight and line length. For example, the longer the line of text, the more space should be used between lines. Stronger colors used on text should also incur more line height.

One great point I took away is that we as designers shouldn't try to always do something wildly different for each design. Find typefaces that resonate with your personal style and develop a "personal palette"; get to know those typefaces really well.

Kristina Halvorson

Kristina Halvorson also blew my mind with her talk "A Content Strategy Roadmap." The founder of Brain Traffic hammered home how content strategy is a very typically overlooked part of the average web design workflow. Sure we all do IA, Design, Development, et al, but content is always that thing that gets tacked on at the end of a project and "isn't our responsibility".

Halvorson said that the content isn't the problem, it's the process or map we standardize on to complete our projects. Her talk made it clear that a good content strategy can inform the project at all touch points and should really drive much of the deliverables for a project. Some key points:

• Determine who is responsible for the content; the "content owners."
• Don't jump to conclusions about content; dig deeper; find the good stuff.
• Define the deliverables.
• Ask how content fits the business objectives.
• Ask how the content gets updated.

In short: content is your fucking job. We all need to remind ourselves of this fact.

She also introduced a new concept to me which is that of developing "Page Tables", a guideline of sorts that tells clients/copywriters what they are creating copy around.

Every time I develop a functional spec, wireframe, etc, I start with asking "ok, what's the content? how is it displayed? how much of it is there? how is it updated?" Content touches it all and really should be in the proverbial driver's seat.

Scott Berkun

Local hero Scott Berkun gave an insightful talk on "Why Designers Fail." As an industry, our successes are determined by how we fail and how we respond to that failure. He noticed that compared to most industries, we in the design industry rarely have a failure analysis protocol; that is to say, examining our failures and learning from them.

He talked about the different kinds of failures and noted that we must experiment to create knowledge. One highlight was his discussion of designer Matt Wiley's process. The designer recorded himself designing a magazine layout. The "try this, no, try that, no, doesn't work" method of failing to succeed is immediately apparent in his decision-making process. Berkun pondered why we don't look at this type of documentation as designers more often. Pretty fantastic.

Sarah Parmenter

Sarah Parmenter's talk was quite good as well. Through examples and anecdotal evidence, it became clear how psychology can affect user experiences. Parmenter boiled down psychology in design to five points:

• Speed (KISS - Keep it Simple Stupid. People think fast.)
• Simplicity (Clear messaging)
• Surprise (Challenge conventions)
• Social Behavior (Herding behaviors and social proof)
• Stirring Emotions (Inspiration negatively or positively)

We can tailor experiences to influence users to interact and react, buy and like. She even gave some great examples of dark patterns, using design patterns to negatively influence users. Her talk was fun and her slides were really well designed (no surprise there; her style is super rad).

Luke Wroblewski

At the end of the first day, Luke Wroblewski gave an amazing talk on "new mobile moves." To get us loosened up, he had the entire crowd do some move's from MJ's Thriller. Was pretty hilarious. Wroblewski really made it clear that we should be designing for mobile before designing for desktop. Mobile internet usage is growing so fast that it's going to be overtaking desktop usage in the next few years. Luke encouraged us not to make a website and then dumb it down for mobile, but to design specifically for what mobile was fantastic at doing, and then design the website around those features. He also talked about how interaction with mobile devices differs from desktop interactions and gave tips on designing for those interfaces.

Day 2

Eric Meyer

Eric Meyer started off day two with a number of CSS demos basically for "fucking" with the user. It was a nice way to start off the second day. I felt like it was funny that he just had a bunch of CSS files, but thought maybe it could've been presented in a much quicker format (like design a website for it with a demo on each page instead of copying and pasting). Unfortunately, some technical issues kind of killed his flow a bit.

I would've liked to have seen his demos in about 10 minutes and then have him talk about the state of the CSS3 spec for 40 minutes. Who defines the spec? How do the different browser vendors contribute to it? How does a feature implementation get into multiple browsers? I hate to admit that I was thinking "it's 2011, we all know this stuff by now."

Jeremy Keith

If Jeremy Keith wasn't everyone at An Event Apart's hero already, he was after his talk. Keith eloquently described how our design principles lead to a set of design goals and design patterns form or are utilized to achieve those goals. Keith showed examples how good/bad design principles lead to patterns that can help or harm an end-user. I think Keith's talk was my favorite of the event. I wish I could write more about it but I'm still thinking about it right now.

Aarron Walter

Aarron Walter's talk was accompanied by some great illustration. Walter's was a positive, motivating talk on prototyping, testing, and generally putting your ideas out into the world. He used his own company MailChimp (which, coincidentally, is one of my favorite sites right now...beautiful) to show examples of wireframing, prototyping, sketchboards, et al. He encouraged collaboration; having a buddy to validate your ideas.

Andy Clarke

I'd heard a lot about Andy Clarke before this event, but he was even more entertaining then I expected. Clarke gave a fantastic presentation on CSS3 transforms and (mostly Webkit-based) animation. He showed a CSS3 animated version of the Mad Men intro, and then walked us through how it was done. A beautiful demo and some practical implementation knowledge; awesome

Clarke then proceeded to blow everyone's mind with a working demo of Animatable, a browser-based CSS3 animation-creating tool that generates semantic markup. It looked something like the Flash timeline, but with a more rich timeline tool and palette system. It was safe to say that I was super impressed. You should definitely follow the Animatable team on Twitter for updates about this imminent tool.

Alexa Andrzejewski

Alexa Andrzejewski, the founder of the Foodspotting application recounted her trip to Japan and explained how urban design can inform user experience. I thought this was one of the more touching, personal talks. She cracked me up when she said that "there are no stupid people, only stupid interaction designers."

Tom Coates

Tom Coates seems like an absolutely brilliant technologist. He was also hilarious. Dude had everyone in stitches. Coates gave loads of examples of emerging technologies that are or could be networked. Even though he was really silly, it really made you realize how much awesome stuff is happening right now and how much potential for growth there is. Was a great end to the conference on a fun and positive note.

Thanks, AEA!

Overall, the conference was fantastic. The food was good, venue was perfect, the music was great, and I met a bunch of new friends. Definitely made it clear to me how fantastic Twitter is as an ice breaker ;)

You've heard it before—the haters, the purists—you most likely either think Fireworks is the "free app that Adobe throws in when you buy 3 or more apps" or you're a Fireworks purist (read: snob) and feel the need to tell everyone how "Photoshop is for Photo Manipulation only." Let's be realistic, though; they are both completely adequate programs for web designers and one can happily design websites in both.

I believe, however, that many user's disdain for Fireworks is due to their unfamiliarity with the program (and possibly that it's one of Adobe's more crash-happy programs; though CS5 is certainly a huge improvement). The workflows they've spent years learning in Photoshop are "hard" to do in Fireworks (speaking from experience here). They aren't hard, just different, and I've found that now that I've gotten to know Fireworks, I actually prefer it over Photoshop for many tasks.

Let me be clear that I am not saying Fireworks > Photoshop. It's not; it's just different. I firmly believe, however, in using the right tool for the job. If you're editing photos, bitmaps, painting, drawing custom elements, etcetera, by all means, use Photoshop. If you're doing wireframes, prototyping, vector-heavy application design, layouts and web design in general, Fireworks should also be in your toolkit.

That being said, I'd like to tell you about some of its features I care about to make you think about giving it a shot on your next design project...

With many folks touting mobile-first design and mobile browsing growing by leaps and bounds, it's important to create responsive applications. Fluid layouts and scalable graphics mean thinking outside the 960x600 box we've designed ourselves into. Which brings me to items #1 and #2.

Decent Vector Editing

"Fireworks blends the use of bitmap and vector effectively, falling somewhere in between Illustrator's vector power and Photoshop's bitmap editing ability." -- Greg Lutze, Must Warn Others

Photoshop is the bee's knees when editing bitmaps, but vectors are a different story. If I want a scalable graphic I may fire up Illustrator and then create a Smart Object. In Fireworks, I can draw directly in the same app and create graphics that can scale to any size. Created a 320x480 design for an iPhone view? Scaling that up to 640x960 for retina display would pretty much be a complete redesign in Photoshop. In Fireworks, it's a quick Image Size change.

Speaking of size changes...

Pages & States

You Photoshop uses are probably saying "hey, we've got Layer Comps!" about now, right? Good, you should use them! Starting in CS4, Fireworks has Pages and States. States are similar to Layer Comps but Pages are like a whole separate design document in the same file. Each page can have its own canvas size so creating multiple layouts in the same file is a snap. Each page can have States within it. You can easily export Pages to images or to a PDF with a selection of Pages in it. I can't count how many times I've seen 3000px high Photoshop designs because the "Home Page" is only 700px high but that "News" layer is 3000px. That can be a bit confusing.

A document can also have Master Pages; pages which are used across all sub-pages. Put your navigation/header and global elements in there and make adjustments once to propagate across all pages. In Photoshop, if you make a global change, you may have to go back and update one of your layer comps to reflect the differences. This type of task is minimized with Pages and States.

There are things that both Photoshop and Fireworks do...

Grouping and Selection

Photoshop has great grouping. Select some layers, group them. However, I really like Firework's implementation of selection. When you select an object on your canvas, it shows it selected. Its not just a highlighted layer in your Layers panel. You can hover over a layer to show it's bounding box, so you know exactly what you're about to select. No toggling on/off "Auto-Select Layer", thank you.

Smart Objects vs. Symbols

Photoshop uses smart objects to make reusing assets easy. Edit your Smart Object in Illustrator or another editing program and update it throughout your file. Fireworks goes further with Symbols. They are almost like a MovieClip in Flash. You can create a reusable Symbols containing graphics and text, set properties on each, and add 9-slice scaling.

For example, you could create a Symbol that has a "label" property. Drag an instance of a custom button to your canvas and set the label property in the "Symbol Properties" panel, and the symbol will add the label and "9-slice-scale" the background to fit the text field.

Graphic Export

Both Fireworks and Photoshop have export tools for web. Fireworks gives you a bit more granular control and (I've found) better quality and superior compression on exported images overall. You can also set export settings per page if you are exporting the PNG document as images (one for each page). Fireworks also has a more sophisticated slice-creating tool, allowing you to create rollover states for buttons and export them all at once.

Trying It

I found the most difficult task when trying Fireworks for the first time was masking and gradients. They can be quite confusing compared to Photoshop. Making something like a gradient mask is quite easy though. Just like Photoshop, select the layer and click the mask icon in the layers panel. Then you just select the mask and use the gradient tool to draw the mask. The gradient tool in Fireworks is pretty cool as it has a sort of "live-preview" as you click and drag. The initial effort to learn the new methods is tough, sure, but I think you'll find that once you've established workflows for your familiar Photoshop tasks, you'll love Fireworks.

So, I've made my case for Fireworks. Obviously, these are just opinions, but give it a another shot. Perhaps you won't care for it, but I think it's responsible as a developer or designer to have both Fireworks and Photoshop available to you and to familiarize yourself with both.