Flightpath's User Experience Designer was published in iMedia Connection this month.  The article outlined four essential tips for creating social media that is usable and engaging including:

• Learning what your user's social media behaviors are.
• Creating a social media space that makes sense in your consumer's lives.
• Supporting ease-of-use with basic usability best practices
• Joining the conversation with your consumers in a way that is meaningful and supportive.

Read the full article here: 4 steps for creating usable social media

 

One of the pillars of our digital practice at Flightpath is to integrate the art of technology with the technology of art.  Nowhere is the fluidity of this precept more evident than in our SEO work.  The best search-engine optimization requires a mercury-quick understanding of what is happening in any given market at any given time, what words describe that market snapshot in an informative, creative way, and what technology delivers the information in compelling design (incidentally, another of our tenets).

 

A major breakthrough for us, then, is Google's increased ability to index Flash.  Flash, when it broke into mainstream consciousness, was the pretty new girl in school.  Everyone was a little bit in love and wanted to take her for a ride, but there was a rumbling contingent that warned about the correlative probability that good looks can mean less substance. 

This turned out to be true--Flash didn't offer much in the way of text that search-engine spiders could index; the crawlers couldn't link back to anything, because the browser didn't reload after interactivity.  Even pages that spiders indexed were useless in search results, because users landed on Flash home pages instead of product pages.   

Flash was . . . well, at least it was pretty. 

But, then, last year, Google dedicated the resources to figure out how to index text in Flash sites:

[We] developed an algorithm that explores Flash files in the same way that a person would, by clicking buttons, entering input, and so on. Our algorithm remembers all of the text that it encounters along the way, and that content is then available to be indexed.

The trick, then, is to put the text that you want indexed "along the way" the algorithm travels.  This might include adding text to Flash applications, including a Robots.txt file or adding alternative HTML code.  Making sure the site's organizational strategy includes lots of deep links helps with long-tail optimization, and page titles have never gone out of style.  

Essentially, as Google becomes more and more ubiquitous, making nearly everything about the digital space more inclusive and included in a more intuitive way, we can expect to allow our artistic strengths to shine in happy equilibirium with our market goals and technological requirements.  

We have a project we're wrapping soon for an amazing, artistic client with big-figure goals that will show this to great effect.   Stay tuned! 

It’s always interesting to me when I hear about people in completely foreign lines of work that share similar professional challenges to those of us in the digital marketing industry.  Over the weekend, I was confronted with two very interesting stories that seemed aligned with some of the issues we face when developing and rolling out web sites intended to achieve business goals on behalf of Flightpath clients. 

While stuck in traffic on Friday, I heard a story on NPR about the Airtrain that connects JFK airport to the NYC subway system.  As reported by WNYC’s Andrea Bernstein, five years after its inception, the AirTrain draws 5 million passengers a year despite confusing signage and insufficient passenger information.  Listening to the story, I couldn’t help but draw parallels to challenges we face in creating simple, usable, user-friendly web sites.  This is a fascinating story for anyone who creates web sites or is considering commissioning creation of one.

Next, the weekly Public Editor column in Sunday’s New York Times titled ‘How Did This Happen?’ chronicled a comedy of errors (seven, in fact) that made their way into Times reporting rushed into print around the death of Walter Cronkite.  The newspaper printed wrong dates, incorrect information about Cronkite’s work, and more. 

Apparently, many of rules and processes the Times employs to check facts and approve stories fell by the wayside as they rushed to meet deadlines.  Anyone that’s ever been involved in web site quality assurance will likely understand the cascade of events chronicled in this thought-provoking story and remember checks and balances they’ve implemented in order to circumvent similar problems.

Author Clark Hoyt explains that ‘seemingly little mistakes, when they come in such big clusters, undermine the authority of a newspaper.’  The same holds true for a web site.

 

A number of us at Flightpath recently attended the conference, The Future of Web Design. 

While there were many informative presentations, I was reminded of just how young “the Web” is as a field.  

In his lecture on “The Future of Web App Interface Design,” Ryan Singer of 37 signals made numerous points as to how to use text sizing and interface around the screen to enhance a user’s understanding of their applications. 

I appreciated that he is bringing such knowledge to light, but I couldn’t help but shake my head, “We knew this stuff decades ago for server-side application design!” 

The web is very young, indeed.  On the one hand, it is an exciting, unbounded space where we can explore movement and art and interface; but at the same time, this idea of “novelty and freshness” often blinds designers and developers to what we have learned from years of software development and interface design.  The computer and IT industry has been available for the masses since the 1970s--we’ve certainly learned a lot in that time. 

I have to wonder, are we designers so arrogant because of our relatively new sandbox (i.e.,“the web”) that we cannot look to the lengthy history of Human Factors (or Ergonomics) and Software Design and use it to our advantage?  Does our pride condemn us to reinventing the wheel? 

Do we really think that text sizing and placement as usability enhancements is a new revelation?

OK, I’m mounting my high horse a little bit and need to take a step down.  Yes,  the web is a new, wonderful playground that offers many options that your regular old server-side apps do not.  

The possibilities of social interaction + application are so exciting.  They’re something we’ve never seen or done before (in the long history of development I mean).

Let’s be clear--I love designing for this playground; that’s why I do it.  I do think it would behoove us, though, to give some props to the history of development and our design forefathers, a nod to the psychologists who originally opened our eyes to Learning Theory, Cognition and Perception. 

So, thank you, B.F. Skinner, for teaching us how to learn and about human behavior. 

Thank you, World War II fighter plane designers, for keeping your pilots in mind and for teaching us the psychology and production of the man-machine organism.  Your work led us to the Ergonomics and Human-Computer Interaction field. 

Thank you, Douglas Engelbart, for imagining how information can be displayed on all kinds of screens and contexts. 

Thank you, researchers at MIT and Xerox.  Thank you, IBM, Apple, and Microsoft for pushing technology to what we know it to be today. ...and a multitude of others not contained in this blog post.

The web has reached its adolescence because of your efforts. 

We are still child-like with wonderment, but we are also growing up and becoming self-aware.  

We can do so much, and the possibilities are limited only to what we can imagine.  We should be looking ahead, using what we know from our history, cognition, perception and design to make the web come alive.  

We now realize that people actually have to use this stuff. 

 

P.S  -- If you want some serious schooling, check out some eye-movement heat maps -- but that's a whole other post.

 

Nobody likes bugs. They're annoying, messy, unprofessional and embarrassing. Although, when it's someone else's bugs, I do find it amusing. I admit I love it when I see Google or Yahoo throw an error, and the best one yet was a 10ft high by 20ft wide video display in a New York City Sprint store that had a big empty black screen and this lovely message facing Broadway for everyone to see:
 
"Windows could not start because the following file is missing..."
 
So, what's the best way to catch these bugs (or defects) and eliminate them, before they become those irritating problems that frustrate end users? The general strategy needs to be test early and test often. But 'test' doesn't just mean the programmer completes development of the new feature, moves it to a testing site and then the QA team jumps on it and runs their tests. The idea is illustrated beautifully here, with a chart that I've become very fond of and used in an earlier post:
 

This chart, produced by Construx Software, shows the stages in the project where defects are introduced, and the cost of repairing defects at each stage of the project. The color scheme and curves remind me of flames, and if you think about it that way then the later you get in your project the bigger your fires get and the harder (and more expensive) they are to put out. The chart shows that most projects devote their resources to repairing defects at the very late stages of the project, in system test. Repairing defects at the system test stage, or the post launch stage is considerably more difficult and time consuming then if the defect were caught earlier in the project and repaired at that point. Part of the challenge of raising the level of quality and finding and reparing defects early is realizing the potential for defects to be introduced early. It's too easy to blame a bug on a programmer's bad code or missing code (not that the Flightpath programmers ever produce any bad code, that's a hypothetical software firm I am referring to), but what Quality Assurance engineers need to realize is that many defects can be created in the earliest stages of a project, before a programmer even gets involved. Designers and Technical Architects can make mistakes too (but of course Project Managers never make mistakes), and the more of those mistakes that can be caught, the healthier the project will be. Having grown up playing goalkeeper on my soccer team, I like to use an analogy from the game - everyone likes to blame the goalie when the team gets scored on, but people easily forget that there were 10 other people on the field that could have made mistakes before the ball got back to the net. Similar to many software project defects, they can be created anywhere along the process.

 
So, test early and test often:
 

• Review the requirements document with the customer, to confirm that all are on exactly the same page with the goals of the project
  
• Involve the QA engineers early on in the development of the specifications document and testing scripts, to verify that the requirements are met, and as many issues as possible are considered and properly handled
  

 
Frederick Brooks, in The Mythical Man Month, writes:
 
"Long before any code exists, the specification must be handed to an outside testing group to be scrutinized for completeness and clarity. As [V.A.] Vyssotsky [of Bell Telephone Laboratories' Safeguard Project] says, the developers themselves cannot do this: 'They won't tell you they don't understand it; they will happily invent their way through the gaps and obscurities.' "
 
When the project is in the development stages, continue to test early and often:
 

• Incorporate regular programmer peer reviews of code and functionality
  
• Schedule feature reviews & tests whenever possible, for both programming team and QA engineers
  

Ideally if all of these steps are taken (and I'm sure there's much more that can be done that I haven't mentioned), then when the project is ready for system test many of the issues have already been identified and resolved. This is not to say that no defects will be found in system test, but hopefully many less than if these steps weren't taken.
 
A couple of things to keep in mind while in full system test:

• Test the pieces isolated and then test them together. If a piece passed an earlier feature review, test it again and don't just assume that it will work fine with the other pieces
  
• Test thoroughly within the mainline scenarios and don't forget to hit the edges and the outside, as Frederick Brooks writes in his book when discussing test cases for software:
  
  1. Mainline cases that test the program's chief functions for commonly encountered data (the most time will be spent here).
     
  2. Barely legitimate cases that probe the edge of the input data domain, ensuring that largest possible values, smallest possible values, and all kinds of valid exceptions work.
     
  3. Barely legitimate cases that probe the domain boundary from the other side, ensuring that invalid inputs raise proper diagnostic messages.


• Once a defect has been fixed and verified in the test system, review all other areas tested and confirm they still work properly. This can be the most time consuming task, but critical. When this task can be automated, even better.

I'd be lying if I said that all of my projects launch bug free, but I am trying to incorporate more and more of these processes into my projects and will continue to strive to keep the bug count down.

Happy Bug Hunting!

 

On this Independence Day weekend we remember the struggles of our forefathers (and mothers), the separation from Britain and the Declaration of Independence that brought it.

Ok, let's be honest...we really spend the days thinking about grilling, fireworks, getting in on the big sales or getting away somewhere interesting. Me, I'll be spending the time off trying out my new inflatable kiddie pool with canopy and sprinkler (I won't actually be in the pool, the kids will of course).

But, on the topic of independence, liberty and justice, I’ve recently been reading about the Customer and Project Team’s Bill of Rights in the book ‘Software Project Survival Guide’, by Steve McConnell. He introduces this idea by comparing a poorly run software project to 17th century life under mob rule. This experience can be “solitary, poor, nasty, brutish, and hardly ever short enough.” In order for a software project to survive, all parties need to agree to treat each other in a civilized way. These rules of civilization he summarizes first in the Customer’s Bill of Rights:

CUSTOMER'S BILL OF RIGHTS
I have the right:
1. To set objectives for the project and have them followed
2. To know how long the software project will take and how much it will cost
3. To decide which features are in and which are out of the software
4. To make reasonable changes to requirements throughout the course of the project and to know the costs of making those changes
5. To know the project's status clearly and confidently
6. To be apprised regularly of risks that could affect cost, schedule, or quality, and to be provided with options for addressing potential problems
7. To have ready access to project deliverables throughout the project

But, this is a two-way street. On a software project, customers must pay for their rights by respecting the project team's rights, which he lists below:

PROJECT TEAM’S BILL OF RIGHTS
I have the right:
1. To know the project objectives and to clarify priorities.
2. To know in detail what product I'm supposed to build and to clarify the product definition if it is unclear.
3. To have ready access to the customer, manager, marketer, or other person responsible for making decisions about the software's functionality.
4. To work each phase of the project in a technically responsible way, especially to not be forced to start coding too early in the project.
5. To approve effort and schedule estimates for any work that I will be asked to perform, This includes the right to provide only the kinds of cost and schedule estimates that are theoretically possible at each stage of the project; to take the time needed to create meaningful estimates; and to revise estimates whenever the project's requirements change.
6. To have my project's status reported accurately to customers and upper management.
7. To work in a productive environment free from frequent interruptions and distractions, especially during critical parts of the project.

I would love to see a project kickoff meeting where all parties gather around a large table to read through the Bill of Rights document together and clients, managers, senior management, project team all take their turn to sign the document. This will affirm their commitment to upholding their responsibilities (although it seems to be mainly the responsibility of the project manager to make sure all of these rights are upheld). Who knows, maybe some project teams out there go through that exact process, or maybe this could be included as a part of the project charter. It’s an interesting idea, but at the very basic level I agree with the author that everything listed here is extremely important for the happiness of the client and project team, and the health and success of the project. I hope to find a way to incorporate this into my projects going forward, so if you’re my client or on my team, better keep a quill handy!

We just recently completed the launch of a feature rich and highly complex calendar system for our largest client, United Jewish Communities. The project accomplished a number of technical and functional goals, and was also our largest of the year (well, it was the largest project for my client and since I only pay attention to what my client does, it might have actually been the largest of the year).  But, this post is not specifically about the project, but the new processes we introduced into this project lifecycle that I think have proven extremely beneficial to project team, client and end users.

Functionality Review Sessions – In an effort to improve our quality assurance and involve more of our QA team before the development completes and moves onto the testing site, we held functionality review meetings that involved the Project Manager (me), the Director of Technology, the programming team and a member of the QA team. This was in addition to the regular status meetings, and the goal of these meetings was to review the functionality developed to date and confirm that it met the requirements and worked properly with the other parts of the system. Each programmer would demonstrate what he/she had worked on and issues would be detected early at a stage when they would be more easily corrected.

This idea of the cost of early vs. late detection is demonstrated very well by this graph created by Contrux software.

(More on this concept in another post).

BETA Sites & Launch – About a month before the launch to the live websites, we went into BETA mode (not new to many in the software world, but something our group has wanted to do for a while). We created mirror versions of the 160+ websites that are using our CMS and calendar, and gave them a place where they could try out the new functionality and view their events in the new calendar system. This accomplished two goals:

• It gave the users time to become comfortable with the new system before it was ‘thrown’ upon them. One of the most challenging things about the tool that we develop for United Jewish Communities is that it needs to be user friendly to both the tech savvy and the tech un-savvy at the same time. In our last large release, there was criticism from the field that we did not give the users an opportunity to try out the new system before it was thrust upon them. We took that criticism seriously and wanted to make some changes.
  
  
• It opened up the new work to several hundred more pairs of eyes, giving us and them more of an ability to catch defects that could be specific to one website or one specific arrangement, system, etc.

Training – we also conducted web & phone training sessions for over one hundred users, spread out over 8 sessions. The users were able to train on their own BETA sites and could ask questions early and address any concerns before the launch to the live sites took place. This was also a great forum to share ideas about how to make best use of the new calendar functionality.

All of this did a great deal to improve our quality assurance and control processes and the client and end-user acceptance of the product.

Did the project launch 100% bug-free?

Not exactly. I mean, let’s be realistic here. This is the world of software after all.

Did we have any real show-stopping issues when we launched, either delaying the launch or making for rough sailing for the post launch days and weeks?

Not really. There have been bugs that both our team and the end users have found since launch that were not detected before, but we have been handling them carefully and efficiently and the system has remained stable throughout this process.

Do we have happy customers?

I think so, there seems to be a good feeling in general and we're starting to see some nice creative use of the new system and good ideas going around for how to make the best of the new tool.

I’m happy and relieved that the project has launched and completed smoothly, and excited about the progress that was made both technologically and in various project management process areas. I look forward to continuing to incorporate these processes and finding new ones that will make future projects even more successful.

I don't exactly have a corner office. We just recently moved to a new space and I sit at a window along a row of desks at the western side of the room. Our arrangement along the western side is nice and intimate, and I have the pleasure of being just a couple feet away from a very nice woman who is also our most senior salesperson. Because we sit so close to each other, I've also had the opportunity of listening in on some of her sales calls. This has been both entertaining, exciting, and sometimes totally frightening. Just last week I overheard a call with a potential new client and was not only glad I was sitting down, but happy my lunch had already digested. Here's why:

She said (not exact quotes, but hopefully enough to get the idea), "Yes, we can definitely set you up with a new website, we just completed a project for another client in the same field as yours, took about 8 weeks to turn around so will probably be the same for you."

I cringed, and I thought "What??! How can we make any estimate of schedule when we have absolutely no idea what the project will entail or what technologies we will be using, what specific needs they will have, etc. We aren't even approaching the beginning of the Cone of Uncertainty, so to make any kind of estimate at this stage is complete project suicide!"

Then she said, "We used a new Content Management System (CMS) to integrate the content of our other client's old site to new, and I'm sure we'll be able to help you in the same way."

I glared at her and almost grabbed the phone out of her hand, and thought "Wait!! We don't know enough to make a commitment to this person about using a new CMS for their site! There are still too many unknowns and a good deal of risk associated with using this technology. The best we can do is offer to research the idea and go back to them with an analysis of the benefits and risks of venturing into the project with this new CMS, and make sure it's clear with the impact on schedule and budget would be if we hit any complications."

Then she said "I understand that you're on a tight schedule, we'll corral our people and make sure we can get this out the door by August 1"

My heart skipped a beat as I thought, "How can you make any promises of schedule when you don't know what the availability of our resources are, people's vacation schedules, our key production person is out this week, etc."

Then I realized why I'm not a salesperson. A salesperson has to be a "can do" person all of the time, because she is going to bring in our next deal and she's going to make sure there's plenty of dollars around for my next bonus (that's just a hint there for someone, you know who you are). So, it's her job to raise the energy level and get this potential new client excited about the prospect of working with us, whatever that might mean. And, she's good at it, too. She's brought in a lot of new projects in her time here.

As a project manager, it's my job to make sure the new work that's brought in is done well, on schedule, within budget, and meets the client's needs. Is it possible to reach all of those goals in every project? That's the subject of many other posts, but it's definitely the goal we strive for at Flightpath. But, a project manager also sometimes needs to be a "can't do" person. A PM needs to be a leader and keep the team energized, organized and informed, but also attuned to the reality of the tasks we are undertaking and the risks involved, the uncertainties at each stage of the project and it's affect on schedule, etc. When a project is done well and the client is happy, the saleswoman's job is easier because the client will ask us to do more work.

So, for a minute I imagine what the sales call might go like if I was doing the pitch:

"Well, we did do a somewhat similar project in the past with another client, but without taking a closer look at your site and the technologies that run it, I couldn't even make a ballpark estimate of time that it would take to complete the project. Let me call a meeting with our programmers and look through your site and we'll get back to you in a few days."

"click!"

Ok, so I don't think we're going to get that deal.

The reality is that many times we are challenged with urgent scheduling demands, new technologies that we might not be familiar with or uncertainties of scope, details, etc. The advantage of being at smaller company is that it's possible to shift resources around to get the work done, even when some of the details don't get ironed out until later on. Working with a new technology can be a daunting task sometimes, but can also be very exciting and challenging, and bring us higher up on the escalator of risk.

So, I'm going to continue to do my job and she will continue to do hers. I'll continue to be entertained by her sales calls and know that together we'll keep things busy at Flightpath.