Kranthi | BlogmyQuery - BMQ

26

Jun/12

Using media queries to hide CSS3 from older browsers

by Roger Johansson under CSS, Feeds, Web Design

When working around bugs and different levels of support in various browsers, a common approach is using conditional comments to target certain versions of Internet Explorer. Come to think of it, itâ€™s pretty rare to need to fix something for an older version of any other browser. People who do not use IE tend to upgrade quicker and CSS-related bugs in other browsers tend to be less severe than in IE, especially compared to IE7 and older.

Anyway, while working on a lot of responsive layouts lately Iâ€™ve started using an approach that Iâ€™ve found reduces the risk of more advanced CSS, especially CSS3, tripping up older browsers. I simply wrap any CSS that I know won't work at all or may only half-work in a very basic media query, like this:

@media only screen {
    /* "Advanced" CSS2 and CSS3 goes here */
}

Read full post

Posted in CSS.

Copyright Â© Roger Johansson

kranthi Leave a Comment more...

26

Jun/12

Facilitating Great Design

by Kevin M. Hoffman under Feeds, Web Design

Whether you build websites as part of a design agency, as a freelancer, or with an internal team, you don’t design in a vacuum; you work with people. To collaborate and develop a shared understanding of goals and assignments, you have meetings. It doesn’t matter what kind of process you haveâ€”waterfall, agile, or “jazz improv”â€”you cannot get to site launch without having had at least a few meetings. In any design process, coming together insures your project against breakdown due to unrealistic expectations, limited resources, and differing definitions of the problem or the solution.

Today’s web design professionals practice any mix of graphic design, information architecture, user interface design, usability testing, user research, and front-end or back-end development skills. The value of the modern web design professional is not those disciplines, however, but the ability to combine them to solve real problems, especially as a group. Effective group work requires structured, strategic meetings, and good facilitation provides that structure.

What does good facilitation look like?

Imagine the most fulfilling, collaborative design meeting you’ve ever had. Hours seemed to fly by, and those hours were productive. Political and mental barriers melted away and in their place were innovative ideas, or realistic solutions for complex problems. For several shining moments the team worked as one; the conversation or the activity was equally fun and productive, and you left the room feeling smart and empowered. It’s highly likely that someone in that meeting was a facilitator, either by design or by accident. If you can’t identify the facilitator, chances are it was you.

To the untrained observer, a great facilitator seems to perform Jedi mind tricks: a skill that we’ve all wished for during a troublesome meeting. Imagine if you could simply wave your hand to reach consensus with a disagreeing counterpart. Projects (and life) would be so much easier. Most of us have seen this happen in meetings. Without aggression or argument, and with seemingly little effort, a meeting Jedi guides the discussion into a productive and beneficial space. Some person in the room manages the process to explore and evolve contentions to reframe understanding around a shared goal. For example:

At a kickoff meeting for a web redesign project, a member of the team is fixated on putting dozens of Facebook Like buttons on each page, so that users can “like all the things.” The content strategist leads a team-based competitive game where working groups create and ship imaginary digital products that align social interaction to content that users care about. In subsequent discussion, social media becomes content strategy rather than a feature. Attack of the Like buttons averted.
During the prototype phase of building an iPhone app, a team member becomes obsessed with the typography, (lack of) color, and other graphic design elements. The information architect demonstrates a sequence of transitions from prototype to final design for a number of tangentially similar projects. Obsession dissolves.
While selecting from graphic design direction options, a client is convinced that the website must “look like my iPad.” The creative director leads the group through a freelisting activity, where the team lists every design problem the iPad solves, then explores the alignment between those problems and the project’s problems. The client associates specific techniques with overlapping problems. Conviction evolves into insight.

These examples share a similar pattern: they begin with dissonance, usually rooted in differing perceptions of a technology or design technique. Then, through a planned activity specifically designed to expose and explore that dissonance, the group develops a more sophisticated, shared vocabulary around the problem. Finally, the group reaches an understanding through persuasion, collaboration, or both. Good facilitation is the tactical skill that empowers you to orchestrate this process, and it’s a skill that anyone can learn.

Facilitation basics for any meeting

First published in 1976, How to Make Meetings Work introduced a role-based process, dubbed “the new interaction method” for improving any kind of meeting. For a successful meeting, someone in the room must assume one of the following roles:

a group member (most of the folks involved),
an organizational leader,
a recorder, and
a facilitator.

A facilitator has the right combination of knowledge about the problem, a playbook of meeting protocols to open, explore, and narrow focus on the problem, and prior experience running a group through those protocols. The facilitator plays an entirely neutral role. By adopting neutrality, and not contributing or evaluating ideas, the facilitator creates a locus of trust.

Inspired by How to Make Meetings Work, Sam Kaner and Jenny Lind set out to document the core values, organizational strategies, and a diverse set of solid facilitation methodologies in their 2007 book, The Facilitator’s Guide to Participatory Decision Making. The book argues that for organizations to be effective, they need to involve all members of the organization in the decision making process.

However, the natural dynamic of larger or multi-group discussions often leads to awkward disagreements and dead ends. Solid facilitation methods help you move around, over, or through these situations. A good facilitator “support(s) everyone in doing their best thinking” during a meeting—they build and execute participatory processes. To do so successfully, they serve four functions during a collaboration:

Encourage participation. This one’s a no brainer, but it’s harder than it sounds. There are bulls and daffodils in every meeting and it’s the facilitator’s job to elicit and balance everyone’s contributions. One approach is to have participants write down their ideas before speaking them out loud. This technique prevents bigger personalities from dominating by simply being louder, and it forces participants to write approximately the same amount of content. Another technique is to change the order of people called upon for ideas, ensuring that you have a clearly non-biased pattern: go around the table clockwise, then go counterclockwise, then choose randomly. Mix it up.
Build a “shared framework,” or understanding of the problem. To build shared understanding, you must define what different concepts mean for different people, and make sure everyone agrees on a single meaning for key concepts. Building shared understanding is one of the toughest things facilitators have to do. One approach is to manage the scope of the discussion by establishing what you are and are not going to talk about in the meeting invitation, and reiterate the discussion’s scope at the beginning of the meeting.
Seek inclusive solutions that “work for everyone with a stake in the outcome.” This requires the group to explore the design challenge more than some may be used to, especially senior leadership. (“Can’t we just build a website?”) Touch on the ways in which the website affects every person in the room, and the departments the project represents. It will take more time now, but will save time and headaches later. Early in the process, ensure everyone has voiced their ideas/feedback/concerns and make sure those concerns are clearly documented for everyone to see. Then, when someone hammers the same point repeatedly, it’s easy to point to the documentation and say This has been documented, and will be addressed.
Finally, design solutions based upon shared responsibilities. If you’ve designed an amazing collaborative session and assigned all the work to a single party, you’ve wasted your time and your participants’ time. Good strategies depend on everyone involved participating. For web design, this translates into some simple best practices. Involve the developers in the early meetings. Make sure the information architects are part of the quality assurance scrums. Generally, be less siloed about the design approach based on discipline, and offer the option to participate whenever someone MAY have something to add.

Facilitation basics for design collaborations

Being neutral and designing solid participatory processes will help you facilitate effective discussions. These four additional concepts have been invaluable in helping me connect with clients in meeting scenarios unique to the web and application design process.

Provide clear guidance through a series of steps intended to reach an agreed-upon end result.
Select the best activity for the problem at hand. The good news is there’s been a renaissance of fantastic resources that will help you build that playbook. Books like Gamestorming, Visual Meetings, Back of the Napkin, and Business Model Generation provide pre-built, engaging collaborative activities for design and beyond, built upon ideas found in game theory and sketch facilitation. These resources will help you align activities to the specific parts of your web design process, whether you are at the beginning, middle, or end. They also organize activities based on additional constraints such as time, materials, environment, and the number of people involved in the process. With a few sticky notes and a whiteboard, you can accomplish just about anything.
Always follow this pattern: allow for divergence of opinion, permit participants to explore those opinions within constraints, and then force ideas to converge.
Divergence — Exploration — Convergence is a simple but powerful pattern, prominent throughout meeting and facilitation literature. For more productive meetings, workshops, and conversations, always follow that sequence.

Ever been in a kickoff meeting where someone says “That’s a terrible idea!” in the first five minutes? It felt awkward and perhaps even hostile, because someone has jumped right to the end of the pattern (convergence) before you've had a chance to diverge and explore. By designing your kickoff interaction to embrace diversity in the beginning of the meeting, it establishes trust. That trust makes it safe for people to want to participate. As long as the subsequent prioritization process is transparent, people will feel like they were heard AND they participated in the outcome.

On the surface, the kickoff meeting’s goal seems straightforward—we need to agree on what we will—and will not—be doing for a particular project or sprint. But for even the simplest website redesign with a small client team, there could be half a dozen versions of that “what” in the room. Therefore you must elicit each version of what’s expected right at the beginning of the meeting. Establish the level of diversity in expectations—remember, as a facilitator, you’re not judging those expectations at this point. Once expectations are out on the table, explore the relative merits of each one. Then provide some methodology to prioritize, and if appropriate, eliminate options.

“The bookend” is a great technique I use to elicit expectations. At the beginning of a meeting, ask the group a grounding question about their expectations for the meeting. “Write this down: What do you want get out of the next two hours?” Have them put it aside for later. Before you leave, give anyone whose expectations have not been addressed during the meeting a chance to express their concerns. Collect those expectations, document them in a shared location, and address them in future collaborations or subsequent project work.
Provide a real-time representation of what’s going on during the meeting where people can see it.
One person—not a facilitator—must take notes during the meeting. Fail to assign a note taker and you flush any detailed insights gained during the meeting down the toilet. In addition, a facilitator should provide a visual representation of the discussion in a format that everyone in the room can quickly and easily reference.

There are lots of ways to do this. Use an easel with large, adhesive-backed paper. When you start a topic, label the top of the paper with that topic and number it (starting with number one) with a nice big Sharpie. Once the team fills the sheet with ideas, pull it off, stick it on the wall, and start a new piece, labelled number two. At the end of the meeting, pull all the sheets off the wall, roll them up, and transcribe them as an outline of the key issues raised. The note taker has the transcript, but this is the discussion’s larger narrative and a great way to remind folks of the key insights gained during a discussion.

As a facilitator, be effective at paraphrasing the essence of the ideas raised. When someone makes an important point (important either to the project, or simply important to them), take the time to verbally echo their point back to them with greatly reduced wording. Ask “Is this what you mean?” If you get a yes, Sharpie that idea large on one of those big sheets of easel paper. Keep capturing those mini-ideas, and display them where everyone can see them. Soon people will cut down on repeating themselves, be more to the point, and hit the discussion with new ideas faster.

This is also a powerful way to course-correct a meeting that has gotten out of hand. If a discussion lacks direction, discreetly get up, go to an easel (or whiteboard), and start capturing the essence of what people are saying. When folks ask “What the hell are you doing?!,” just say “This helps me follow the discussion.” I’ve introduced this ambush note-taking technique to people in both agencies and in-house teams. I’ve heard stories where people stand up and applaud when someone starts capturing the conversation in a visible way. People are much more careful about what they say when it’s being written down, and it’s a great way to focus people’s attention.
Keep in mind that everyone in the room, no matter what they say, believes that their recommended action equates to doing the right thing.
I can’t count the times I’ve been facilitating meetings where someone, out of the blue, has said the most ridiculous thing you could possibly imagine. “You know, I love that black and white image. Let’s make everything black and white. Everything, everywhere.”

After suppressing anger, or laughter, I always keep this in mind: we all have different perspectives on the process we’re involved in. But anyone who takes the time contribute truly believes that their idea is going to make things better. It may be off the mark, misinformed, or even crazy, but it’s more important for you as a facilitator to understand why that idea surfaced in their brain, and how it relates back to the value they hope to add to the project. The more you understand those values as the individual contributors perceive them, the easier it will be to design a project strategy that will not just be adopted, but embraced.

Use the force, Luke

Great web design is perceived as appropriate and enjoyable by users and clients alike. To get there, you have to have a process. To build consensus about where that process should go, you have to facilitate understanding of the myriad overlaps between business and user needs, art direction and brand, and innovation and ease-of-use. Great design is facilitating these forces.

May the forces be with you.

Translations:
Italian

Illustration by Kevin Cornell

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

kranthi Leave a Comment more...

26

Jun/12

Agreements = Expectations

by Greg Hoy under Feeds, Web Design

Every client/vendor relationship is based on a set of expectations, whether they’re stated or not. When you hire a painter, the act of applying paint is only part of the gig. All the steps that lead to the finished job are where the details lie.

I expect the painter to:

Get to my house on time.
Move any furniture that’s in the way.
Put down drop cloths.
Refrain from smoking in my house.
Refrain from rinsing brushes in my kitchen sink.
Be respectful and professional.
Finish the job on time.
Leave the house in the shape it was in before the job started.

I don’t expect the painter to:

Feed my dog while I’m at work.
Set my alarm system.
Paint areas I didn’t specify.
Apply three coats of paint.

A lot can go unsaid or unspecified for any project, large and small. Not being specific can lead to disagreements, quarrels, and high blood pressure.

For my day job, I’m on the other side of the fence. At Happy Cog, we work with dozens of clients each year. Over the years, you learn a thing or two about a thing or two, usually as a result of the mistakes you’ve made along the way. A business relationship is governed by what you mutually agree to. A Statement of Work (SOW) or Statement of Services (SOS) is one tool used to align expectations. We used to use SOW and SOS synonymously with the words “contract” or “proposal,” but they’re actually a little different. Whatever you call them, they will save your bacon.

SOWs and MSAs

A Statement of Work (SOW) is usually a document that accompanies yet another document, often referred to as a Master Services Agreement (MSA). They’re the Lenny and Squiggy of legal agreements. The MSA is usually the governing document for the entire relationship, while the SOW usually deals with the specifics of a single project or scope of work. Our larger scale clients usually prefer to lead with an MSA, even though we’d rather lead with our own agreement, which we call a Project Service Agreement (PSA). The acronyms are already making me loopy.

An MSA will typically address relationship-governing topics such as:

General Services—In general terms, what you’ll provide the client (web design services, content strategy, etc.).
Project Management—What the roles for project managers on both sides will be.
Deliverables—How deliverables will be provided to and accepted by the client.
Support/Deployment—What assistance you’ll provide the client with implementation, and what additional support you’ll provide moving forward.
Payment/Expenses—How you’ll get paid, which expenses are covered and which aren’t.
Audits—How the client can ask you to prove you’re doing your job.
Confidentiality—What you can’t say about the work, and what your client can do if you blab.
License Grants—What client-owned information you’re allowed to use, and for how long.
Proprietary Rights—Who owns the work (even the individual elements of it) when the job’s done.
Term and Termination—How long the agreement lasts, who can end the agreement, and for what reason.
Representations and Warranties—Ensures you can do the work, you’re not in conflict with other agreements, and that you’ll fix what’s broken if it’s your fault.
Indemnification—To guarantee against any loss which another might suffer.
Insurance—The types and amounts of insurance coverage you’re required to carry to perform the work.

A SOW, on the other hand, typically addresses such things as:

Requested Services—Describing what the project actually is.
Project Phase Descriptions—Detailing how many phases, and what goes into them.
Project Duration and Milestones—Estimating how long the project will take and what milestones occur along the way.
Resource Hours—How many hours are allocated to each phase.
Billing Rates—What you’re charging for each practitioner in your company.
Proposed Tasks & Deliverables—What you’ll do and deliver, and when.
Commencement and Completion Dates—When you’ll start, and if all goes well, when you’ll finish.
Service Fees—How much you’re charging for the entire engagement.
Payment Schedule and Terms—How much you’ll get paid, and when.
Listing of Representatives—Who the primary players are on each side, or at least what their roles are.

As you can see, it’s all quite invigorating.

If the MSA and the SOW have similar or conflicting language, the MSA is usually the agreement that takes precedence. Some lawyers will tell you it should be the other way around, and will fight for that stipulation. After all, the details the SOW captures are more project focused and granular, and therefore may provide more context. An SOW is created for each specific project, and is highly specific to the current work at hand.

Be careful: don’t lock in to a long-term MSA

We usually don’t sign MSAs that carry a term longer than a year. Why? Well, say you sign an MSA with a two-year term that states that the client can terminate the relationship whenever they want, but you can’t. You sign the MSA anyway, because you were too lazy to consult a lawyer to slap some sense into you. Then, you execute a SOW for a big project that takes a year to finish, and everything goes smoothly. Based upon that positive experience, you agree to sign another SOW for an even bigger project. Remember, you’re still governed by the MSA you originally signed a year ago. Say that during the second project, the person you loved working with on the client side leaves, and is replaced with someone who is impossible to work with. After trying everything you can to make the project work, you decide you want to get out. Well, too bad. The MSA says you can’t. Have fun with that!

The bottom line is this: you're always learning, and your needs change. Don’t lock yourself into things. It’s the same reason you don't want to sign a three-year contract when you sign up with a mobile carrier.

I’m not the first to say this, as it applies to both MSAs and SOWs: everything is negotiable. Don’t simply take an MSA from a company, and because you might need the dough, sign it without scrutinizing it. Get yourself a lawyer and go through it. Track changes. Your client will expect that, and you won’t be a jerk for putting it under a microscope. We once had a prospective client try to slip a non-compete clause in the MSA that stated we couldn't consider any opportunities in their industry for a period of five years. Um, no. Be sure to look closely.

PSAs

At Happy Cog, our preferred starting point when defining a business relationship isn’t the MSA/SOW combo many of our potential clients enjoy so much. As I mentioned above, we lead with our own Project Service Agreement (PSA). It’s specific to the project at hand like a SOW, but it also contains all of the relationship-governing legal stuff like an MSA. It’s an MSA, SOW, proposal, and agency rÃ©sumÃ© in a neat, elegantly designed package (MSAs and SOWs are usually ugly legal documents, so we like to construct/design our own that better communicates our brand).

Our PSA starts with the information our prospective clients want to see the most: the cost. We save them from the page flipping/PDF scrolling. There it is, our price tag, right on page two in big, bold numbers. On the same page, we detail our proposed payment schedule, and how we prefer to be paid. On the surface, it sounds like the wrong thing to do, but after considerable testing, our prospects appreciate it.

Next, the PSA provides an overview of the history of our company, talks about our differentiators, and includes bios of our people. Next, there are several paragraphs that introduce the problems we’re trying to solve. At a very high level, we describe how we propose to solve them. We then detail the phases involved with our effort, including the number of hours we expect to expend on each phase.

After all of the prose comes the legalese. It is a bit jargony, but it has to be. Every time we tried to convey legal language in an easy-to-understand way, we were doing ourselves more harm than good. Know your audience. Lawyers expect to read things a certain way.

Be vague (you heard me)

This is subtle, but important: don’t try to solve what you don’t understand yet.

Reflecting on many years, even before my role at Happy Cog, I think we tended to consider projects a bit too “one-size-fits-all-ish.” Up front, we would establish which tasks we were going to perform, which artifacts we were going to produce, how many comps we were going to design, and how many revisions we would offer. It usually consisted of a site map with three rounds of revisions, 10-12 wireframes with three rounds of revisions, three different design comps created by three different designers revised three times, and HTML/CSS templates for 10-12 pages. For just about every project. This created a bunch of issues.

First, we were prescribing solutions before really understanding the problems. And the only way you can be 100% confident about what you should be delivering is to do your research and to have in-depth conversations. But how do you articulate how you’ll solve problems you don’t fully understand yet? You’re still trying to be asked to the dance. There are no signatures on contracts yet. And we didn’t want to do a bunch of unpaid fact-finding to achieve clarity for the sake of a contract.

We needed to solve that issue. Two ideas came to mind. We could choose to:

Change our approach to simply pitch a project research/definition phase for a fraction of the total project cost, and allow the findings from that effort to provide the ammo we needed to put together a detailed contract for the rest of the work.
Be a bit more vague with what we say we’ll do.

That second bullet point looks ridiculous when you read it. Shouldn’t you be getting more specific, not less? I’d argue no. Instead of prematurely committing to a course of action that may or may not be appropriate for the project, we identify all of the possible artifacts we could produce in each phase. Then we commit to zero of them.

The specific deliverables Happy Cog will provide will consist of one or more (in any combination) of the following, to be selected based upon their appropriateness for the project...

Then, we list them. For example, the types of deliverables we could provide for information architecture work includes:

Taxonomy creation
Persona development
Content outline
Content genre classifications
Site outline
Site map
Wireframes
Page description diagrams
User/process flow diagrams
Comprehensive experience document

Your client’s role in selecting a vendor includes performing the necessary due diligence to feel confident with your work, your people, and your process. This includes checking references. If your client has faith in your abilities, you’ll have no problems being less prescriptive with your PSA or SOW. In fact, you’re actually being responsible. You don’t know what you don’t know, right? Don’t suggest the wrong stuff just to tie your agreement up with a pretty bow. Be honest, and say that you’ll do what is the most appropriate. Most of our prospective clients, when reading our PSA, don’t bat an eye over our purposeful lack of specificity.

Bucket those hours

Back when we’d prescribe exactly what we would deliver ahead of time, we’d run into another conundrum. Clients wanting more.

We once had a client that wasn’t happy with the designs we created for them. We promised them three variations, with the winning idea revised twice more until we had the perfect design. We felt strongly about the work, but it wasn’t resonating with the client. Shortly thereafter, we exhausted our specified number of comps and revisions. We let the client know that. And to that, they responded, “That’s too bad. But we still don’t have our design, and that’s not our fault.”

That’s a fun spot to be in.

You could issue a change request/order, sure. But that will make your client breathe fire. So in addition to abandoning prescribing specific tasks and deliverables up front, we switched our model to use “buckets of hours.” We price our jobs at a fixed fee, but we also know how many hours we’ve allocated for each phase of the project. Upon exhausting 75% of a phase’s hours, we’ll fire a shot across the bow to let the client know that. Then, if they hit 100% and use all the hours, we stop work and they need to buy more. We won’t steal hours from another phase to fund the shortfall. This way, if a client wants five designs iterated five times, that’s cool with us. The hours are used how the hours are best used. Freedom.

Documenting requirements

Whether you’re hiring a painter, a builder, or a creative company, you need to think about requirements, which also set expectations. In our world, there are business requirements, content requirements, and technical requirements, to name a few. And you might think that a contract is the right place to document those requirements. I know I’ve tried to identify as many of those details as early on as possible to minimize risk and ambiguity. It’s tough to do. I’d argue that the contract is not the appropriate vehicle for articulating requirements. However, the contract should specify a process by which requirements will be gathered, evaluated, and prioritized. What you can ultimately execute upon will be dictated by your project budget and timeline.

Translations:
Italian

Illustration by Kevin Cornell

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

kranthi Leave a Comment more...

25

Jun/12

Create Interactive Prototypes With Adobe Fireworks

by AndrÃ© Reinegger under Feeds, Web Design

Whilst designing for screens—including Web, mobile and rich interaction applications (RIAs)—you often need to create a prototype to see whether the application works properly before moving onto the development stage.

Prototypes are also essential in Web projects. For example, when you plan an online ordering process, you have to be sure that every step is correct and that no critical elements are missing. Usually, you would create different screens for all pages of a website, ordering process or application workflow, and then describe the connection between them. This way you can see whether the interactions work as expected, you can test the product with different users, and your client can review it.

However, a static prototype is much harder to review and test—usually it is just a bunch of images (with some explanatory notes here and there), and grasping the connection between them may be hard. Why not make things more dynamic, and easier for the client, with the help of Adobe Fireworks?

What Is A Prototype, And Why Should I Use One?

“A prototype is an early sample or model built to test a concept or process or to act as a thing to be replicated or learned from.” — Wikipedia

Using an interactive prototype brings a lot of benefits. The main benefit is that you are able to easily find errors in the interaction flow or the user interface (UI) at a very early stage, before development has even started. Your client can also provide detailed feedback early in the design process. The client will get a functioning demo with many interactions displayed right on the screen, instead of a collection of images with no interaction.

To learn more about the advantages of prototyping, have a look at â€œDesign Better and Faster With Rapid Prototypingâ€� on Smashing Magazine. A couple of interesting articles have also been published on Boxes and Arrows: â€œIntegrating Prototyping Into Your Design Process,â€� and â€œDefining Feature Sets Through Prototyping.â€�

What Is A Click-Through Prototype?

A click-through prototype is an interactive mockup of a website or application that allows you to click through different pages and states and is packed with key interactions.

HTML Prototypes

Creating such a prototype in Adobe Fireworks is very easy. All you have to do is prepare the design for exporting as an interactive prototype: create slices for all interactive areas on the screen, and make pages for all of the different states of the application. Slices can also have hover states and be linked to the various pages. At the end you will create a click-through prototype (also known as an interactive prototype or click-through dummy) by selecting â€œExport as HTML & Imagesâ€� in Fireworks. The exported HTML files can be viewed locally in the browser or uploaded to a Web server for reviewing and testing.

Web prototype exported from Adobe Fireworks.

(Interactive) PDF Files

Another option is â€œExport as Adobe PDF.â€� The difference here is that interactive PDFs have a somewhat reduced feature set: rollovers wonâ€™t work, and only rectangular hotspots will export with their links. The advantage is that you can email the PDF to the client, who can then easily give feedback using the comment tools in Acrobat or Adobe Reader. Keep in mind, though, that Fireworks does not generate a comment-enabled PDF file; you must open the PDF in Acrobat Pro, enable commenting, and then save the PDF before sending it to the client. (Enabling commenting in Acrobat Pro makes it possible for anyone with the free Acrobat Reader to add comments.) Of course, if Acrobat Pro is not an option, then feedback can be provided in any of the usual ways, such as email.

In my opinion, HTML prototypes are a better option. In this article we will show how effective this kind of workflow is in Fireworks. But before diving in, letâ€™s quickly review the main benefits that the â€œliveâ€� prototyping phase brings to a project.

Advantages Of Prototyping

Get feedback at a very early stage.
Increase the effectiveness of your communication. Get more detailed client feedback.
The prototype can be used for usability and A/B testing.
Find errors early on. Fewer mistakes are made later in the development process.
Find errors in the interaction flow or UI before development has begun.
The exported graphics from the prototype can be used for development.
The developer or team will understand what needs to be done without needing detailed explanation.
Overall development time will be decreased.
Minimize the need for development changes
Your client will be impressed.

How To Impress Your Client

If your client is working with a Web designer or team for the first time, he might not be so impressed by having access to a click-through prototype early in the design process, because he wouldnâ€™t know any different. But if they have gone through the process in the past, then they will probably be very impressed by seeing a live preview of the website right on the screen, with a lot of interaction, instead of a simple static preview or collection of image files.

Personally, I have used click-through prototypes from Adobe Fireworks for over 10 years, with much success and enthusiasm from my clients.

Every client who had experience with Web design was impressed with seeing a working prototype of the website right in the browser. My clients always appreciate this, and once your clients have used one, they will prefer to work that way, too.

A word of warning, though. Be clear that this is just a prototype and that it has yet to be developed into a real application, which will happen once the prototype is approved. Otherwise, the client might expect a functioning website to appear simply by you copying the prototype to the root folder of their domain.

How To Create Click-Through Prototypes In Fireworks

The click-through prototype that Fireworks creates consists of simple HTML files (i.e. HTML with tables and images). But this is not important because the prototype is used only in the early stages of the design process. Once the prototype has been approved and tested by the client, you can continue to the development phase of the website, with semantic HTML and CSS. Fireworks is helpful only for transferring the design to the development stage.

What are the key elements of an interactive prototype? Basically, a prototype consists of pages (and, optionally, a master page), states, slices and hotspots. Letâ€™s review each in more detail.

Pages and Master Pages

To create a click-through prototype, you first need to set up multiple pages in your document. Every state of an application or every page of a website will need a separate page in Fireworks. To create an individual page, you can use the Pages panel. When all pages in a design share common elements—such as a header, logo and main navigation—you can use a master page.

In our example website, we will need six pages (home, products, shop, shop detail, support and contact). They will all have the same header area, with a logo, image and navigation, so creating a master page makes sense. To do so, create a page with only those elements on it, and then (just as in InDesign), right-click on the page in the Pages panel, and select â€œSet as Master Page,â€� Alternatively, you can use the options menu on the right side of the Pages panel. Now, every element that is placed on the master page will automatically appear on all pages, which will save us a lot of development time.

Set a master page in Fireworks.

Based on the master page, we can now build all of the pages. Go to the Pages panel and click on the new page icon several times until you have six pages (plus the master page). Then give each a meaningful name. The home page should be named index in the Pages panel, and â€œShop Detailâ€� can be shop_detail.

The Pages panel in Fireworks.

When it comes to exporting, Fireworks will automatically name these two pages index.html and shop_detail.html. Now, we can fill each of the six pages with its unique design elements (i.e. not the common elements, which will go in the master page).

All pages created in the Pages panel can later be linked to each other via hotspots and slices (more on that later).

Please note: All elements on the master page will appear in the same locations across all of the individual pages and cannot be moved on a page-by-page basis. So, if one page needs to be different than the master page, you will have to overlay the new elements on the master pageâ€™s elements, or use another Fireworks file.

States

To give the client more interactive feedback, you might also want to create hover states for the navigation elements. To do so, open up the States panel, and add a new state by clicking â€œNew/Duplicate State.â€� If you are using a master page, you can create the second state right on the master page (thus saving a few clicks), and then it will be used on the individual pages. Now in the new state, you only need to place the elements that should change on hover, such as the navigation, links, drop-down menus, tooltips and so on.

The States panel in Fireworks

To show a hover effect for a navigation element, you simply need to place the graphic for the hover effect in this second state. You can change the color of the navigation background or a drop-shadow applied to a text object. All of these would change on hover in the second state (the hover state) in the States panel.

Please note: Fireworks does not use CSS :hover pseudo-classes. Instead, it uses JavaScript to swap the images in the prototype (a traditional JavaScript-based rollover or mouseover). This JavaScript behavior is rather old and should be used only during the rapid prototyping phase. During the development stage, it should be done with CSS pseudo-classes.

The â€œAdd Statesâ€� option in the States panel

After all hover states have been created, you can reuse them for all pages. If you have a master page, you only have to create a second state for all pages by right-clicking on the States panel, or by clicking â€œAdd Statesâ€� in the options menu to the right of the panel.

The new state will automatically include all hover elements from the second state of the master page. If you donâ€™t have a master page, youâ€™ll have to copy and paste all hover elements to the second state on all individual pages.

With slices, you are able to define the regions that should change on hover.

Please note: When multiple states are used on the master page for rollovers and image swaps, you need to manually add additional states to all of the other pages.

Slices and Hotspots

Slices in Adobe Fireworks

Slices can be used to define regions that are interactive and that will be linked to different pages on the same website or that even point to external URLs. Hotspots can only be used to generate areas for hyperlinks (internal or external).

Create Slices in Fireworks

To make a hover state, select the Slice tool (step 1 in the image above), and then outline the whole area of the hover element (step 2).

You can also create a slice by selecting an object on the canvas, right-clicking and choosing â€œInsert Rectangular Slice.â€� This is often easier, faster and more accurate than using the Slice tool. If you select multiple objects, right-click and then insert a slice, Fireworks will show a dialog box with the option to insert multiple slices (one for each object) or one big slice that covers all of the selected objects.

After you have defined all of the areas, you can use the target in the middle of each slice to create the hover effect (step 3). To do so, click and drag out the target in the middle of the slice back into the same slice. In most cases, it will be the same location, so it has to be pointed to the same slice (step 4). If you want to show another image on hover, then the target must point to the slice with the image; but in the most cases it will be pointed to itself. Then Fireworks will ask you which state to choose for the image swap (step 5). Here is where you would pick the state with the hover image (for example, â€œState2â€�).

Preview the design in Adobe Fireworks

After repeating this step for all hover areas, you can look at the result by clicking the â€œPreviewâ€� button in the top-left of the Fireworks PNG document.

For hover elements that appear on every single page, such as the main navigation, you can save time by creating the slices in the master page.

To help you, Fireworks provides some visual associations for slices (green) and hotspots (blue); and the Property Inspector panel (or Properties panel) will also show the slice or hotspot type. Standard slices and hotspots are semi-transparent, but HTML slices are opaque. You can also assign custom colors to slices and hotspots—useful if you want to differentiate the types of code that have been placed in them (HTML, JavaScript, embedded Flash objects and so on).

Please note: When using states for rollovers, copying or sharing background elements to the other states is sometimes necessary, otherwise blank areas might appear on rollover. For example, if a slice is larger than the object that will change on rollover, then the background behind the object will also need to appear in the rollover state (state 2). I recommend using â€œShare to statesâ€� for elements that will be the same in all states to maintain a consistent appearance during rollovers (or on hover). â€œShare to statesâ€� is accessible in the Layers panel (right-click on the layer that needs to be shared to the mouseover state).

Linking Pages

Now that all interactive elements have slices, the pages can be linked to each other. To generate hyperlinks, you would typically click on a slice (or on a hotspot, if no hover effect is needed) and enter a URL in the â€œLinkâ€� field in the Properties panel. For an external URL, you would enter, for example, http://www.google.com; for an internal link, you have to enter the name of the page from the Pages panel. All page names from the Pages panel are also available in the drop-down menu there, which prevents typos.

Linking pages in Fireworks

The names of the pages in the Pages panel should be Web-friendly (i.e. no spaces or special characters). You can check out the demo prototype you have just created, with all of the hyperlinks and interactive areas, by clicking on File → Preview in Browser → Preview All Pages.

Add Real Interactivity To Your Prototype

Many Fireworks users do not know about HTML slices. For every slice, there are three different options in the Properties panel (foreground image, background image and HTML). With foreground and background image, you can specify the exporting mode for images if you are exporting HTML and CSS out of Fireworks.

Slice types in Fireworks

For click-through prototypes, which are based on HTML and images, the default â€œForeground imageâ€� option works best. If you want to place different types of interaction in your prototype, the HTML slice is a good choice. You can place any HTML code in an HTML slice, which is very efficient if some elements already exist, such as interactions. Thanks to HTML slices, you can easily insert Google Maps, videos, animations and so on right in the prototype to show the client how the elements will function.

Embed Google Maps

What if we wanted the â€œContactâ€� page to have an embedded Google Map? You donâ€™t need to take a screenshot of a map area to indicate the presence of Google Maps. In Fireworks, you can place the actual map itself right in the prototype.

Using HTML slices in Fireworks

To do so, select the Slice tool (step 1 above), and draw a slice over the area where you want to show the map (step 2). Next, change the type to â€œHTMLâ€� in the Properties panel (step 3). Now an â€œEditâ€� button will be available (step 4) that opens up a dialog box where you can paste the HTML code into the slice (step 5).

Next, go to Google Maps, locate the clientâ€™s office on the map, copy the iframe HTML code for embedding, and then paste it into the HTML slice.

The HTML slice in Fireworks

The width and height of the iframe should have the same pixel dimensions as the slice. Review the embedded map in the prototype by going to File → Preview in Browser → Preview inâ€¦

Embedded Google Map in the Fireworks prototype

See an example of Google Maps embedded in a prototype of a website made with Fireworks.

Embed Video

Video can be easily embedded in the prototype, similar to maps. Go to the video that you want to embed (whether on YouTube, Vimeo, etc), and copy the embed code of the video. To see a live preview of the video, go again to File → Preview in Browser → Preview inâ€¦

Please note: The embed code will set the width and height of the video. The HTML slice in Fireworks should have the exact same dimensions in order to keep the proportions correct.

Embed Flash Animation And More

With an iframe, you can embed everything in a live prototype. Just place the element you want to embed in an iframe, and paste the code in the HTML slice. So even Flash animation, video and other elements stored on your own Web server can be easily embedded.

Of course, HTML slices are not limited to Google Maps and Flash video. Anything that can be wrapped in an iframe can be put in an HTML slice, including JavaScript and AJAX elements, JavaScript animation, HTML5 and CSS3 animations and much more. For example, with Adobe Edge, you can create animation and interactivity based on HTML5, CSS3 and JavaScript. Even Adobe Edge animations and interactions can be included in a Fireworks prototype. Alternatively, you could make your own HTML5 and CSS3 animation, and paste the code directly in the HTML slice. So many possibilities!

Export The Click-Through HTML Prototype For Review

The final step of the process is to export the prototype for review. Before doing this, you can do a quick preview in the browser to make sure everything works as expected; go to File → Preview in Browser → Preview all Pages in Browser. Remember to select â€œPreview all Pagesâ€¦â€�; if you select â€œPreview inâ€¦,â€� you will only see a preview of the actual page, and the links to other pages will not work. If you choose â€œPreview all Pagesâ€¦,â€� you will be able to see all pages, with all interactions and internal links working.

Fireworks preview in the browser

Try everything out before exporting the live prototype. If everything is functioning properly, you can then export the click-through prototype by going to File → Exportâ€¦. In the dialogue box, select â€œHTML & Images,â€� â€œExport Slices,â€� â€œAll Pages,â€� â€œInclude Areas Without Slicesâ€� and â€œImages in Subfolder.â€œ

Options for exporting your prototype in Fireworks

A Couple Of Live Demos

See an example of a prototype with very basic interactions—such as mouseover states, linked pages and an embedded Google Map—exported right away from a Fireworks PNG file. (Feel free to explore the pages and available interactivity.)

Another method is to export an interactive PDF by going to File → Exportâ€¦ and selecting â€œAdobe PDFâ€� as the exporting format. The PDF can then be sent to the client, who will be able to review the website and interactions offline and then provide you with feedback. See also an example of an interactive PDF (an HTML live prototype is a more elegant solution, but itâ€™s good to know that there are other options).

A Word On The New Mobile Web And Fireworks

While preparing interactive prototypes with Adobe Fireworks can be fast and easy, they are not responsive or adapted specifically to the modern mobile environment. Luckily, the Export Responsive Prototypes with Adobe Fireworks extension by Matt Stow and Touch Application Prototypes (TAP) for Adobe Fireworks, are here to help! Both extensions are free and will help you build responsive Web prototypes or iOS prototypes in Fireworks with greater ease.

Acting On Client Feedback

Finally, what do you do when the client provides feedback on the prototype and the interactions?

In Fireworks, acting on the clientâ€™s feedback is very easy. All you have to do is to make some adjustments to the design (based on the clientâ€™s notes and comments), re-export a new version of the prototype for review, and upload it to a test server. The whole process can be done in minutes, and you can make as many design changes and iterations as needed.

Fireworks fits perfectly in the workflow of a Web or mobile app designer. You can do the whole design in Fireworks, or you can import artwork from Photoshop or Illustrator and continue in Fireworks. The layout for all of the pages of the website can be easily created with the Pages panel, in combination with the master page feature. To add interactivity, you can set all of the different states of the website, with the help of the States panel. This whole process is fast because Fireworks is optimized for this type of workflow. Slices and hotspots enable you to link all pages to each other with ease.

Both the designer and client benefit from an interactive prototype. While preparing an interactive prototype certainly takes some time, it will more than pay off during the development process.

Create Interactive Prototypes With Adobe Fireworks

by AndrÃ© Reinegger under Feeds, Web Design

Whilst designing for screens—including Web, mobile and rich interaction applications (RIAs)—you often need to create a prototype to see whether the application works properly before moving onto the development stage.

Prototypes are also essential in Web projects. For example, when you plan an online ordering process, you have to be sure that every step is correct and that no critical elements are missing. Usually, you would create different screens for all pages of a website, ordering process or application workflow, and then describe the connection between them. This way you can see whether the interactions work as expected, you can test the product with different users, and your client can review it.

However, a static prototype is much harder to review and test—usually it is just a bunch of images (with some explanatory notes here and there), and grasping the connection between them may be hard. Why not make things more dynamic, and easier for the client, with the help of Adobe Fireworks?

What Is A Prototype, And Why Should I Use One?

“A prototype is an early sample or model built to test a concept or process or to act as a thing to be replicated or learned from.” — Wikipedia

Using an interactive prototype brings a lot of benefits. The main benefit is that you are able to easily find errors in the interaction flow or the user interface (UI) at a very early stage, before development has even started. Your client can also provide detailed feedback early in the design process. The client will get a functioning demo with many interactions displayed right on the screen, instead of a collection of images with no interaction.

To learn more about the advantages of prototyping, have a look at â€œDesign Better and Faster With Rapid Prototypingâ€� on Smashing Magazine. A couple of interesting articles have also been published on Boxes and Arrows: â€œIntegrating Prototyping Into Your Design Process,â€� and â€œDefining Feature Sets Through Prototyping.â€�