photo credit: victoriapeckham

We have reached the most critical point on a project I'm working on. After a few months we think we know enough about the domain and application to build a product road map that will take us to the first public release. The proof of concept is complete. The design team has created a remarkable, genera changing product. Additionally, the system is designed around real users we have been able to talk to and get feedback from. We have put together an unbelievably good development team and built a backlog of stories with estimates. We have been here before. Putting together a design and backlog of stories is something we have done countless times...

The easy part is over. Now the hard part begins.

Our research and user feedback tells us we have multiple potentialcustomer groups we can build the system for. On one hand this is great news. We have a number of potential markets to choose from. On the other, we don't have an infinite amount of time and money to build it for all of these groups. We have to commit and go all in with one group. Right now, these are just some of the questions we are asking ourselves now:

• What customer group do we value the most?
• What features do they value the most?
• How expensive is it to build the ultimate product for each group?
• What is the minimum viable product we can build for each group?
• Which group is most likely to give feedback and partner with us to help refine our product?
• How much feedback is this group likely to give you?
• Are we missing some market window by passing on one group v.s. another?

This is a critical point in the product's design. Whichever user group we choose will be our customers. Or another way of saying it: They will be our ONLY customers. Other customer groups aren't likely to be interested because we aren't building any features for them yet.

When designing a product do you consider what customer groups you are including and excluding? Are you going to be happy with that choice for the foreseeable future?

Related posts:

1. Your SDLC or Your Product – You Decide
2. User Driven Product Development
3. “Build half a product, not a half-assed product” – tips on clarity and focus from Jason Fried of 37Signals

Instead of a "loading" animation that we may bail out on, why not tell a story? I was impressed with this technique used by BMW.  They are running banner ads on NBC's site which hypes the upcoming Olympic events. You see a car in the banner ad, you expect to click and see more car. But you don't. Instead, a blank white screen with just a few short words pops up. But the words tell a quick paced story. phrase by phrase, of what joy is. Joy is Timeless. Joy is Freedom. Joy is Innovation. And below those words is the "loading" indicator. 10%, 20%, 32%, and so on. A nice example of storytelling used in design - if you are going to make someone wait (or have to, because you are loading a high-end car video), consider getting them engaged with a story.

http://www.bmw.com/com/en/insights/technology/joy/bmw_joy.html

Related posts:

1. Ajax and Design
2. Art vs. Design, the Art of Design, or the Design of Art
3. Design Doesn’t Just Mean Color

Now ask yourself, in which of those pictures would (a sealed, always on, always connected) tablet make more sense?

In all of them (although the beach one still seems like a bad idea.)

Related posts:

1. Where the iPad will take over: 15 examples
2. iPad: How big is the space between laptops and iPhones?
3. iPad: Instant Reaction to Apple’s Tablet Event

... it's hard not to think about how much easier some people's lives would be (hi Mom and Dad) if they could trade technical complexities they don't care about for vastly increased simplicity and ease of use.

- John Siracusa, ars technica

My parents were technically savvy enough (with a little help from their sons) to start using Skype video in their mid seventies, prompted by the arrival of grandkids halfway across the country. But for them, it was always a cumbersome affair:

1. Arrange a time to have the video call.
2. Move the laptop to the dining room.
3. Call on the telephone to tell me that they're using Skype on the computer.
4. Initiate the Skype phone call.

Needless to say, this did not happen all that often.

This past Christmas my brother got them a Skype Video Phone. They set it up with a little help from us, and when we told them to just treat it like the telephone, they got the idea. Now, they are making video calls much more frequently - not just to the grandkids, but to our cousins in Switzerland and South Africa.

They traded complexity for simplicity and ease of use, and though the skype video phone will not end up being a success on the level of the iPhone, it's already brought my parents a lot of joy, and is part of a trend towards more simplicity and ease of use. It's one major reason the iPhone is as successful as it is.

Now imagine that simplicity and ease of use in a multipurpose, always on device with a bigger screen. My parents wouldn't need the skype video phone, they'd just have that as an app on their tablet.

Related posts:

1. Single Purpose Devices vs. Flexible Platforms and Functional Cases
2. DUX2007 – Simplicity
3. Where the iPad will take over: 15 examples

A couple of days ago I happened upon an interesting article about the difference between art and design. The author makes a lot of interesting points, and whether you agree or not with the statements he makes, the article does make for a great conversation starter.

Art and design are two different words, and some say two different worlds as well. The use of each often comes with a distinct connotation. I could go on about how design's goal is to solve a problem, whereas art doesn't necessarily always have a problem to solve. I could talk about how art doesn't necessarily require a common user experience, whereas design more often than not does. I could expand upon that by discussing how art doesn't require that a thing be usable, whereas design is often judged in part or whole by its level of usability. I could even discuss how art can be effective whether done collaboratively or not, and contrast that with numerous examples of how here in our agile software development environment at Pathfinder we find collaboration inseparable from our design process.

But I could also talk about how much art and design overlap and blend, so much so that it becomes difficult to make concrete distinctions. And how, sure, software design is about solving a problem, but it's also about solving a problem beautifully.

Art versus design, the art of design, or the design of art...it's a never-ending debate, and the usefulness of this debate is also debatable.

The art versus design topic definitely can be a fun one to banter about. The author of the article had some very interesting points, especially regarding the purpose of design being to communicate a message and motivate the user to act. He makes an important point that, "If your design communicates a message other than the one you intended, and your viewer goes and does something based on that other message, then it has not met its requirement. With a good piece of design, the designer’s exact message is understood by the viewer." And it was nice to see too that he included his designs for the article as downloadable wallpapers.

But in the end, I think the author of this blog post said it well when he said it's not really our goals that are in conflict when we talk about art and design - just our definitions. So perhaps rather than elaborating on terminology, we should focus more on clearly expressing our goals.

Related posts:

1. Integrating Design and Agile Development
2. Week in Review
3. Developing Good Wireframes Ahead of Visual Design

I've worked on more than a few software projects over the decades and one of my favorite little misunderstandings is the Importance versus Effort disconnect. That's where non-experts assume that because a particular part of a software system is more important than another, it must also take more effort to develop. That is rarely the case and, in fact, importance -- however that is defined -- is rarely a driving factor in determining effort or cost. This sort of misconception can result in some planning and budgeting mistakes, sometimes to comic or even tragic effect.

To illustrate, I can point to a trading system that I worked on (the names have been changed to protect the innocent). The average size of a transaction in this system was over $1 billion in 1990's money. The part of the system that resolved the transactions was really really "important," but the part of the system that allowed an application helpdesk to support users by seeing what their user's saw cost 60% more to develop. That's right, an "unimportant" helpdesk module was more expensive and took more effort and cost more than the "important" backend that handled billions of dollars a day.

There are lots of reasons why one system can be more expensive to develop than another. One recurring and important reason is the amount of user interface your application has. By that I mean a user interface for a real flesh and blood user. One of the reasons that the above trading platform had this mismatch was that while the helpdesk app had lots of user interface requirements, the trading backend had almost none. It dealt almost exclusively with other systems through API's and data interchange protocols.

There's lots of empirical evidence that interfaces for humans are more difficult and expensive to develop that those for machines, but there's also a fair amount of theory on the subject under the heading of Human Computer Interaction (HCI). If you spend a little bit of time reading the referenced Wikipedia article, you'll see that there's an awful lot of cognitive psychology involved. In short, you can't just ask a human being to do those things that a software system can do -- parse 2GB of data, remember it forever and make decisions within a millisecond. No, human beings have limited memory, can't act very fast, have ambitions and emotions and all sorts of human frailties. All of these have to be accounted and designed for.

(We ourselves use an approach known as User Experience Design (UXD) to tackled this terrain. It's by no means the only approach, but it's stood us in good stead.)

So, what are the key takeaways for product managers and owners? Don't make emotional budgeting decisions. Just because your backend which is doing all of the financial transactions is important, doesn't mean that it should cost more than the nifty website that helps users buy your product or service. Listen to your developers and analysts on the subject of effort and cost, then make rational decisions based on what is essential for your business.

Related posts:

1. Software Development and the Construction Analogy
2. Software Development and Wasted Motion
3. Digging a Hole and Covering it with Leaves — The Software Development Version

photo credit: Sinaasappeljuice

At Pathfinder, we do our best to help our clients experience the software through the eyes of the user. Defining a feature includes explaining who will be using it, what they need to accomplish, why they need to accomplish it and how they’ll actually do it.

We start with personas (who) — they define the user base and let us identify the primary users whose needs we should focus on, which in turn drives the feature list. Personas also bring the human element into software development. Rather than using a vague term such as actor or user, terms that can easily be dismissed, we now have Myrna from Accounting, a numbers guru who is the primary user of the new software. Myrna is not so easily dismissed, especially once her needs and goals are identified.

We move onto user stories, all of which are written from the point of view of the personas:

As Accounting, Myrna needs to quickly extract time expended per project so she can calculate the actual costs.

Our user stories state both the user’s need (what) and business benefit (why) from meeting that need. The story is no longer some randomly floating idea; it’s now anchored to an identified user and given context within the scope of the business by specifically stating how the user and/or company can benefit from this feature.

From here we move onto acceptance criteria (how), i.e., defining how the user expects the feature to work. Since they’re written from the point of view of the user, they’re easy to understand and aid in experiencing the feature before it’s built:

Given that Myrna has clicked on Reports > Costing Report
   And that the costing report page has successfully displayed
When Myrna selects one or more projects
   And she specifies a date range
   And submits the request
Then the costing report will show the hours by project for each resource for the specified date range

Even without delving into the details (e.g., how does the user select one or more projects), you still have a pretty good idea of how someone will interact with this feature; i.e., you’ve established a foundation that interaction designers and information architects can now build on. Acceptance criteria, btw, are also great at uncovering any user story you might have missed, such as: does Myrna need to save this report after it’s generated?

Designing software with a user centric point of view begins with defining the Who (Personas), What (User Stories : User Needs), Why (User Stories : Business Benefits) and How (Acceptance Criteria) of feature stories. With this knowledge, we can then create a well-designed feature that we’re confident will meet the users’ needs.

Related posts:

1. It Starts with the User Story
2. Definition of a Feature (Given … When … Then)
3. The User Interface is the Root of All Evil

The task of wireframing in application development, as I've come to know it, should begin after user research has been performed, and a complete set of requirements gathered.  But what happens when, for whatever reason, you just don't have access to user research, or a full set of requirements?  What if all you have are some rather unspecific, vague notions of what the user should and should not be able to do?  Is wireframing at this juncture useful?  I say yes.  With incomplete or even almost non existent information about target users and or requirements, wireframes can still be a valuable tool in the interface designers toolkit.

The key to a wireframe's usefulness is that it is a visual document.  Presumably it will be presented to one or more product stakeholders, and they will have the opportunity to review it and comment.  Having something visual to respond to is one of the easiest ways to generate ideas, and identify incomplete specifications.  A good assumption is that if a product's requirements are incomplete, someone at the wireframe review will notice the gap by responding in the context of the visual presentation.  "Where is the Cancel button?  Oh...not in the requirements?  Well it's obvious that on this screen the user will need to be able to cancel, so we have to add that as a requirement."

In this way, a wireframe can be an ever evolving document, which begins by starting the requirements conversation.  Of course ultimately, just prior to feature development, the wireframe should have all of the necessary specifics so that the developers can use it as a guide (along with the relevant user stories).

Related posts:

1. Exactly What are Wireframes?
2. Writing Agile Requirements
3. Developing Good Wireframes Ahead of Visual Design

Ack! On the one hand, good for them for alerting me that an error had occurred. On the other hand, what's up with that message? I had no idea what I could do beyond clicking ok (and after reading the message I wasn't sure all was ok). A bit unnerving, but it did get me thinking about how applications deal with error messages.

The idea that non-technical users will be viewing error messages is one of those things that tends to be overlooked. You’re so focused on getting all the features up and working that dealing with errors on the presentation layer are often left out of both design and implementation.

Even if time is crunched on a project, however, here are three scenarios you should always cover in a user-friendly fashion:

Validation Errors

At a minimum, submitted forms should validate that all required fields have data and that certain data (such as email addresses) are properly formatted. My personal preference is to catch the obvious errors (e.g., empty fields) using client-side validation which gives the user instant feedback and allows them to correct their errors before actually submitting the form. Regardless of whether you’re using client or server side validation, however, you should still alert the user as to what went wrong — without using technical lingo — and highlight the fields containing the errors.

404 Errors

Design a useful “page not found” page. Make it as clever or funny as you like, but make sure you give the user alternative ways to find the page they were looking for so they don’t feel so helpless. This can be done by providing a site map, a search box or a list of top-level categories.

500 Errors

When a page blows up, unless you’re in a development environment you never want the user to see the stack trace. So, make sure that (a) there is a page in place to display when a 500 error occurs, (b) the app knows to display that page and (c) it gives useful feedback to the user.

In an ideal world, of course, errors never occur (ha!) but should they happen, your job is to let the user know what went wrong and provide guidance on the next steps. Time spent up front designing good error handling will alleviate user frustration down the line.

Related Services: User Experience Design, Custom Software Development

Related posts:

1. Oops! Our Bad.
2. Usability review: Amtrak.com checkout process
3. Stop, Reload, Error Loading Page 404: Converting Web 1.0 to 2.0

So, the question is: How to determine if your project/organization has that collective code ownership culture. And what team members (including managers ) can do to create/encourage it.

Does your project have collective code ownership?
Here are few things you may want to ask yourself to determine if your organization/project has collective ownership culture.

• Are tools like continuous integration and testing, code coverage and code metrics considered nice to have but not necessary?
• Is the project release schedule determined and then enforced with little or no involvement from developers?
• Is failure to slip on iteration stories viewed as failure on developer's part?
• Does your velocity seem to decrease with time?
• Do developers talk about my module, your module instead of our module?
• Do members aspire to leave your project and join other project?

If answers to these questions are mostly in the "yes" range, you may have a code ownership problem.

What's a developer to do?
Be a good citizen, strive to write good code. Leave any codebase cleaner than how you found it. Developer need to tame their tendency to guard their masterpiece code from other people's changes, infact welcome those. If you really really hate some design, try to pair with the person who concieved it and influence his thought process. This might be slow and furstrating but it will be better in the long term. If you rip out everything you don't like, you will end up owning everything. Remembership, it is a collective ownership. Code is very fluid, which means when coding, you can always take short-cuts to get stuff you are responsible for, done. Or you can take ownership and fix the general code quality (even if it take a little longer). These are all things that a developer is in control.

However, there are stuff that are beyond developer's control. It is hard to continue to be a good citzen when other members don't feel the same way and when your boss is holding your neck against a timeline. This is where managers can play a role.

Why do manager care about code ownership?
A manager cares about the quality of deliverable, team morale, attrition and deadline. An agile project manager can remote obstacles that prevent such culture from growing. Managers need to cultivate a culture where developers are not hard pressed to deliver on timeline at the cost of quality, atleast not often. Managers need to develop a culture of trust where developers are free to over-estimate stuff (atleast from their point of view). Hire team players overs smart but solo players.

What's a Architect to do?
Managers can't judge the quality of code and hence success of code ownership culture. Yes, there are code metrics like code coverage that attempt to quantify the code quality but those are not precise measures. Here is where architects can make a different. By architect, I mean anybody how has the direct or indirect authority to influence other developers and modify their behavior. Install tools like continuous integration, testing, code coverage and various other metrics. Encourage pair programming to reduce bus number and prevent knowledge silos (the bad side of code-ownership).

In summary, it could be a good thing when a team feels responsible when the project when in it and proud that they were part of a project that completed successfully. They owned the outcome of it, good or bad.

Related Services: Agile Development, Custom Software Development

Related posts:

1. What makes a good requirement document for an agile project
2. Data Driven Design and the Culture at Google
3. Code Coverage – Why?

To make a cheap joke and paraphrase a common quote, web developers and web designers are two groups separated by common languages. In our case, the languages are HTML and CSS, which are the output of both the web design process and the web development process. Developers and designers produce their HTML/CSS in different ways and with different goals. Here are some ideas for bridging the gap so that the developers and designers on your team can work together smoothly.

Designers and developers obviously have different goals for their HTML -- developers have issues of reducing duplication, organization, and performance that are largely not the designer's concerns. The designer is primarily concerned with how the HTML looks and behaves to the user.

By the way, I'm absolutely not trying to make this some kind of left brain/right brain thing. It's more of a software needs vs. domain expertise thing. Once upon a time, I was writing scripts that outputted router configuration files, and I had exactly the same issues with the router domain experts -- my software engineering desire to structure the code without duplication conflicted with the way the router experts liked to structure their hand-written configuration instructions.

Our teams have had success with getting everybody on the team using common tools as much as possible. This means putting designs and code in the same code repository, and it means the development team supports the designers in creating a set up to run the current development version of the app locally. (By the way, this article by Mindy Wagner might be helpful if you are trying to convert everybody to Git.)

From the developer perspective, if you are working with HTML provided by designers, it's important to keep the view layer of your code accessible to the HTML providers. Exactly what this means is subject to negotiation. Left to my own devices, I'd be putting all kinds of HTML generation in Ruby via helpers or something more esoteric. That didn't work out well when the designer needed to go mucking about in metaprogrammed Ruby code to start changing CSS classes. We do better with putting pure logical stuff in helpers and using partials to split view logic. I'm pretty sure that if I were to suggest Haml for a project, the designers would veto it -- Haml barely meshes with the way I think of HTML, the designers I've shown it to have basically recoiled in horror.

That said, everybody likes Less CSS, which seems to augment CSS in ways that seem very intuitive to CSS designers, and which are very satisfying to coders. It does all the things that you would expect CSS to do if it was a real language, but vanilla CSS works just fine. It really caught on quickly here.

From the designer perspective, get everything out of photoshop and into HTML/CSS as early as possible. It's just too easy to put stuff into a photoshop image that represents hours of development work, leaving the developers in the position of trying to determine which parts of the impossible image are vital, and which are just chrome. Doing the wireframes in HTML/CSS keeps the design honest.

We use this little hack to integrate wireframes into the development app, which is really nice for developers when working with in-progress designs.

Ultimately what it comes down to is for everybody in the team to take some responsibility for making the team work together. The developers need to make the code base accessible to designers and to be alert to basic design issues and flexible in adapting wireframes into the site. Designers need to help place their deliverables in a format that keeps the developer from having to guess how things are supposed to work -- nobody wants that.

Related Services: Ruby on Rails Development, User Experience Design, Ajax Rich Internet Applications

Related posts:

1. A New Workflow for Web Designers
2. Down with HTML + Code Markup!
3. Designers on Joel

Design encompasses both of these, and both are equally important. But by first addressing the software's information design & interaction needs, wireframes help you make sure the user experience makes sense, including that the workflows are natural and intuitive for users, and that the interactions are easy and clear. Without these, a site may not be very usable. Developing good skeletal wireframes before fleshing out the visual design is important for several reasons.

Focuses the Conversation
Visual designs tend to elicit more of an emotional response than wireframes. Hence, putting a fleshed out visual design in front of a client can divert attention from the structure and interaction of the page, and tilt the conversation more towards the color and graphic choices. Skeletal wireframes help you and your client focus the conversation on the business goals and the needs of the user.

Creates a Path toward Better Design
Wireframing and information design is really an evolutionary process. Design reviews, customer feedback, and user testing all help the information and interaction design evolve for the better as the project moves forward. Being open and flexible, without having invested deeply into a visual design, allows for the freedom to continuously create and recreate to meet the users' and clients' needs better. Good user experience comes from creating an environment and process that allows for more evolution in design.

Allows for Choices to be Driven by Users' Needs
A great deal of creativity, time and effort goes into mocking up a visual design, so it's natural to feel attached to it. The last thing you want is to feel locked into a certain user experience because you've invested in the visual design too much too early. Because your information design choices should be driven by users' needs and business goals first, it's important to develop good wireframes before investing heavily in visual design.

Saves Time
You don't always hit a great information design on the first try. When you work iteratively, your information design gets refactored and improved. Spending days creating visuals, only to find that you have to redo it because the underlying structure or interaction pattern needs to change, is frustrating and hurts your efficiency and overall progress.

Saves Money
In a world where time is money, having to redo work can cost you a lot. It is inevitable that your design will change. But redoing wireframes costs less in terms of time and money than redoing a visual design.

At the end of the day, if your software is usable and providing users with value, but has less than ideal visual design, people will still use it. However, if your software is confusing and hard to use, but has great visual design, people won't use it. So concentrating on the layout and interaction first will pay off in the end.

Related Services: User Experience Design, Custom Software Development

Related posts:

1. Exactly What are Wireframes?
2. The Hand-Off Between Information Architecture and Visual Design
3. Fresh paint or new drywall? The cost of changing IA or design mid-project

[...] this is completely at odds with how homes are normally built.  People typically choose a previously-implemented design, and only customize superficial features like countertops, cabinets, floors, and railings.  Houses from this plan have been built before, and the labor and materials cost are known from previous experience.

Building software is usually more like constructing something that’s never been built before: the first sky scraper, the Golden Gate Bridge, or the Hoover Dam.  The requirements are unique, the pieces have never been assembled in such a way before, and there’s an inherent level of risk in creating something new.  When this is the case, the Customer needs the services of an Architect, not just a Builder who stamps out deliverables in a cookie-cutter style.

I would add two points to his post:

• One additional reason that building construction is not a good metaphor for software construction is that it breaks down along scale. You can construct a scale model of a house to validate the concept, but a scale model of the software is the same as the software itself. An application's size is measured in features, not feet. That's why agile development seeks to deliver a minimal set of features as quickly as possible.
• We've folded User Experience Design (UXD) into our agile process as a way of getting to value more quickly. Feedback in agile is important, but if you can improve the quality of that feedback, you converge on good features more quickly.

Related Services: Custom Software Development, Agile Development

Related posts:

1. Software Development and Wasted Motion
2. Ten Keys to Successful Software Development: #9: Respect the Process
3. Agile Software Development and the Lazy Client Trap

The market says that about 15% of people today are using IE6 which is 8 years old now.

Nothing to be surprised about.

Recently, we at Pathfinder were presented with statistics of usage for a desktop software created in-house showing the biggest drop in workflow at software installation reinforcing the point that people have a hard time installing software, so why would they go around installing a new browser when they already have one? Most people are under the impression that "the site" or "the internet" doesn't work and not the browser they are using and there's nobody there to tell most people what the problem really is.

Microsoft is not going anywhere and it didn't listen to it's own developers and users pleading for mercy and help. So why would anybody go through the horror of using or developing for IE6 when there a great browser options today that implement HTML and CSS standards comprehensively (including IE8 which is not bad)? Because they don't know any better.

That's where people who do know better should step up and offer insight. "Oh, but that's too much work and I don't care about educating people about browsers". Fellow internet dweller, next time you are writing a hack for IE6 and wasting your creative energy, write an email to your mother, friend or cousin and inform them about other browsing options and tell them to pass the word. That small ripple will have a bigger effect than all your hacks and related whining put together.

Or - to make it the least effort possible (because we don't want anybody to strain a typin' finger ) , you can use this code to inform people about their choices, that they are possibly even not aware of.  Maybe even, and I'm just talking crazy here, offer a suggestion.

JavaScript is adopted from Microsoft's article "Detecting Internet Explorer More Effectively" which is exactly what we want to do.

What to pass in the message is a thing of your personal flavor and a good place to really get creative.

Here is my lite take on it.

Thanks to my colleagues from Pathfinder on inspiration who have put together a similar but way more creative informing system on one of our internal applications, not to mention the the development cost reduction it resulted in.

Related Services: Ajax Rich Internet Applications, Custom Software Development

Related posts:

1. .NET Web Browser Control Gotchas
2. IE6: The zombie browser
3. Hacking the :first-child pseudo-class into IE6 with jQuery and CSS

Why use them?

Wireframes are a great communication tool for all members of a project team. Instead of an abstract list of requirements or a verbal description of a concept, the visual nature of a wireframe allows everyone to see exactly what it is they’re discussing. They are usually black and white (sometimes with shades of gray) schematics because we want to get feedback on the page structure and behavior, not the visual design. However, wireframes created for mature applications can readily incorporate existing visual design since that language is already defined and shouldn’t divert focus from the reason we’re looking at wireframes.

Annotated Wireframe

Although a picture is worth a thousand words, adding annotations to a wireframe lets the viewer immediately know the expected user behavior of various elements on the page. While a more detailed explanation of the behavior is generally contained in the design specs, adding a shorter version here is extremely helpful.

Here's an example of what an annotated wireframe can look like:

Who uses them?

All team members. Because they are a visual artifact of what is proposed to be built, they are an easy and cost-effective way to get the stakeholders to sign-off on how their business requirements will be translated to software, before any code is written. They also give development a heads up on what the page will look like and how it’s expected to behave; which means they also let QA know what to expect once the feature is ready for testing.

While I sometimes have to educate clients new to software development on the benefits of wireframes, once they see them within the context of a project, they're sold on the benefits and understand their usefulness.

Related Services: User Experience Design, Custom Software Development

Related posts:

1. Wireframes: Much More Effective than Interpretive Dance
2. Developing Good Wireframes Ahead of Visual Design
3. Wireframes in Omnigraffle 5

The benefits of Facebook connect Facebook is obvious. It'll gather more information about its users, and become more ubiquitous within the wider web, as users remain connected to its platform even while not actually on the facebook.com.

And the (potential) advantage of the relationship to third party sites, such as Yahoo are that those sites can become more engaged with their users by providing them with more relevant content as a result of having access to their facebook information. It'll also potentially be used as a tool for enhanced direct marketing, although Facebook will have to be careful to to repeat it's Beacon mistake.

The potential benefits to users of third party sites are that they'll be able to tap into their network (or social graph, as Facebook calls it) as a source of information on those third party sites, and not just facebook.com. As a hypothetical example, if I'm looking for a movie to add to my Netflix queue, and I, and my friends were sharing our facebook information with Netflix, then the site could theoretically inform me of my friends picks--provided they granted Netflix access to share that information--and that would be more helpful to me than anonymous recommendations.

I like the idea, in theory, and it's seems like an exciting new direction in the evolution of the way we use the web, if implemented properly. However there are some privacy concerns I have. In order to allow Yahoo to access my Facebook account, I had to give it the Ok on a couple of different requests relating to access to my information. The initial confirmation dialog:
Connect Yahoo! with Facebook to interact with your friends on this site and to share on Facebook through your Wall and friends' News Feeds. This site will also be able to automatically post recent activity back to Facebook.

Related Services: User Experience Design, <Facebook and Open Social Applications

Another dialog asked me to confirm this:
Allow Yahoo! to publish posts or comments without prompting me.
Posts will appear on your Wall, in your friends' News Feeds and in applications like Photos, Videos and Notes.

Now what exactly is Yahoo going to be posting on my Facebook wall? I don't want all my activity, once I am logged into the Yahoo network, to be potential fodder for conversation among my friends. This to me seems a little scary. Yet I went ahead and gave it access. I do know that it's possible to edit my privacy settings as it related to individual third party applications, including Yahoo. But I'm curious what kinds of Facebook wall posts Yahoo will make on my behalf so I haven't changed the settings.

Related posts:

1. Facebook apps: Not too late to compete on the user experience front
2. Mashups versus Facebook
3. 20 useful Facebook/FBJS developer resources

Related Services: User Experience Design, Flex, Flash and Air, Custom Software Development

Related posts:

1. Data visualization and the art of conveying information
2. 3D Data Visualization in Adobe Air
3. Flex Widget for Graphing Elections and Debt

photo credit: theD40kid

A few years ago, I worked on a team that was trying to move the business side away from the waterfall method into more of an agile approach so there wouldn’t be such a disconnect between design and development. Since there was no blueprint on how design could be done in an agile fashion, resistance was very high. One of the major sticking points, however, was in documenting requirements. The business side controlled the process which meant no one could see or review the requirements until they were released by the analyst. In a world view of us vs. them, collaboration was not very high on their list.

Collaboration, however, is high on the list for agile development. So, how to resolve this conundrum and begin to merge the two teams. The eventual solution was to use a wiki for documentation and to note when requirements were still in draft form. This process raised the comfort level of the analysts that they wouldn’t be unduly criticized before they’d finished writing, but still allowed for review and questions by others. It took a number of cycles before the analysts were comfortable with having their drafts visible by all, but eventually it happened.

The next hurdle to overcome was the format for the wiki pages. Luckily, the analysts were accustomed to using a Word template and, therefore, were in agreement that a standard template needed to be used. However, a one-to-one translation of the Word template to the wiki just did not work. For example, was a title page really necessary (yes, they actually reproduced this as a wiki page). No? gone. What about a notation of who revised the document when? The wiki tracked changes so explicitly stating this was nothing more than busy work. Table of contents? No longer needed as the content could quickly be scanned since requirements were now for an iteration and not a release. And so on and so forth.

What works in a paper world may not translate well into a collaborative, digital world. However, changing a process doesn’t happen overnight. Your best approach is to take an iterative approach: ask the developers what they read and what they ignore on the current format — then ask the same of the business stakeholders and anyone else on the requirements reading list. Ask your team members what their workflow is through the parts they actually read, i.e., what they focus on first and so on. Once you get a better understanding of the essential components, take the original template, pare back to the necessities and organize in a manner that best suits your users. After all, just enough documentation works for design as well as development.

Related Services: User Experience Design, Custom Software Development

Related posts:

1. Integrating Design and Agile Development
2. Design Thinking
3. Agile Development, Documentation and Bringing Projects back from the Dead

I'm skeptical that the tools assume a rigid and defined workflow between design and development, which would make them useless for building applications in an agile iterative manner. Perhaps the format necessitated it, but each of the online tutorials I went through assumed that the front end interface would be completely finished graphically before any coding started. This is just not the case in any projects I have worked on. In reality, design iterates along with development. It evolves as new requirements are uncovered. Catalyst does maintain a dynamic link to its source PSD or IA files, and therefore conceivably designers could iterate on those files as developers are working on application logic. But I get the sense that Catalyst wasn't created with that workflow in mind, and using it for iterative design/development would lead to major inefficiencies.

I hope to use it more as I have time, and hopefully get it involved soon as a prototyping tool on an upcoming project. Then I'll learn some more about its strengths and weaknesses. I've only spent about an hour total on it as of this writing, so I'm not expert, but these were just my first impressions. Feel free to let me know what you think.

Related Services: Flex, Flash and Air, Custom Software Development

Related posts:

1. Performance Optimization for Flash Player
2. Pathfinder releases version 1 of its Flash Platform microsite (codename Mica)
3. A case study in Flash UI annoyances: style-card.com

Google recently announced a new netbook operating system to great fanfare: Chrome OS. It's named after Google's browser for a very good reason - all applications run within the browser framework, rather than being downloaded, installed and run atop the user's desktop operating system. Much of the subsequent analysis has revolved around the battle of the titans that is expected to occur now that Google has moved directly onto Microsoft's turf.

Here's my take: Google's approach is gonna win.

Why? Developers, developers, developers, developers. And installers, installers, installers, installers. Developers because people don't buy computers to run operating systems - they buy them to run applications. And developers write those apps. Installers because having a seamless installation experience doubles or triples a software developer's customer base. And nothing is more seamless than clicking on a link.

At least, that's Pathfinder's experience. We've build hundreds of software applications in the past 10 years. Most web-based. But some were native desktop apps that users would download and install locally. And for a huge portion of the population, the everyday process of downloading and installing desktop applications is completely broken. Here are some numbers, based on our experience:

• 50% to 75% of users who visit a software download web page abandon the page without starting the download.
• Roughly 30%-60% of users who download the application never install it.

These two numbers are why companies pay Dell and HP to pre-install crapware on every PC they sell. It's why Google pays to have the Google toolbar piggyback on the installations of Adobe Reader. It's why AOL carpet-bombed North America with installer CDs in the 90s. And it's why the Chrome OS - or something like the Chrome OS - is the future for netbooks. Sure, Windows XP has a head start of 15 million or so netbook installations. But if you believe the numbers above, a cloud-based, browser-based OS like Chrome only needs 25% of that number to be a more valuable platform for software vendors. That's a pretty powerful advantage for a company looking to break Microsoft's stranglehold on some part of the netbook operating system market.

Related Services: Custom Software Development, User Experience Design

Related posts:

1. What does Google Chrome do for Mac based Flex Developers?
2. IE8, HTML5 and Ajax Navigation: The future of Really Simple History
3. Upcoming Talk – Back to the Future: Component GUI’s and Ajax