Do you constantly have topics you need to teach your employees? How do you do it? With Powerpoint presentations, long printouts, or activities? Or do you send them to classes or conferences to let others teach them?

Do you know what type of learning styles they prefer? Sensory, visual, active, sequential, intuitive, verbal, reflective, or global?

To keep people’s attention—you have to be interesting and innovative!

Teens and adults can only concentrate on one thing for 20 minutes. Thinking outside the box can really make a difference when you are trying to teach.

What can you do about it?

Try different ways of teaching and even offer prizes:

• Set up teams to get a little competition going
• Create activities that allow everyone to participate and have fun
• Offer gifts to those who score high on a knowledge quiz at the end

Quizzes at the end of sessions will ensure that they are hearing and learning what you are saying.

What am I going to try next?

For my next QA and QC lesson, I’m going to:

1. Teach about the topic for 20 minutes
2. Make a team activity for 20 minutes with something like legos or k’nex where teams can compete
3. Wrap up: Quiz with a surprise gift

What works for you?

Engaging work, fun teammates, unique benefits, nap-time pods, free child care, free lunch, or fooze ball and Xboxes for playtime?

From Google to smaller companies like Flightpath it is extremely important to make employees want to stay. Companies need to be creative and unique with programs and benefits—stand out! Losing a valuable employee can be very damaging to a company.  

Google has done an amazing job at standing out against the crowd! It offers free food, nap time, employee fun rooms, gyms, and more!

But…….most companies aren’t Google…so what can you do if you are a small company?

Ideas for standing out against the crowd!

Do you create other interesting programs to participate in? We have our very own book club! Every so often we purchase books for employees who want to participate, we read it separately and then gather to voice our opinions and share it. It helps keep your employees minds active on something positive and lets you see how creative they are.

Do you have regular presentations from different employees or experts on relevant topics to the company? It’ll help show you what your employees are thinking about and learning or help inspire them to learn about new content and the latest trends.

Do you have employee of the month programs? Or rewards for those who go above and beyond on a regular basis?

Do your employees participate in a small non-profit? Can you offer up the conference room after hours for them to meet? Can you support them occasionally? You’ll be giving back and creating employee loyalty.

What’s most important though?

What do your employees really care about? Money? or Spouses, children, and pets!?  According to me, people care about their loved ones whether it’s their wife/husband, children, or furkids. Benefits catering to family and pets can be truly rewarding and make you stand out.

Consider offering maternity/paternity leave for your employees. Make insurance policies affordable for spouses. Try something unique like offering pet insurance.

A few other unique ideas could be creating a benefit that allows a few days off when purchasing a home or buying  plane tickets in the event of true family emergencies.

Consider the alternative, would you rather keep an employee long term or spend the same funds into knowledge transfers, training new people, and calming angry clients.

One of the SXSW 2010 panels I attended was "Web Accessibility Gone Wild (Now Even MORE Wilder!)" by Jared Smith (@jared_w_smith) of WebAIM, a non-profit organization focused on web accessibility.

Jared says the mythical web site, accessible to all users, does not exist; accessibility is a continuum. Your website may always be inaccessible to someone. Sure, we can have the website follow compliance standards specified by the World Wide Web, but that does not make the web site accessible. Accessibility implemented partially or incorrectly can be worse than no accessibility at all. Here are some tips to follow when building an accessible web site.

Oh, and an accessible web site does not have to be ugly.  

Tips/Best Practices

• Alternative text (alt text) for images should present content and function. Alt text may vary on the context. Have your copywriter provide alt text for images to developers.
• Use skip navigation to allow screen reader users and persons who can't use a mouse to skip long lists of links, such as the primary navigation.
• When using CAPTCHA, use reCaptcha, since it uses both audio and visual cues for spam protection.
• Build one version of a web site that is fully accessible. Provide an accessible alternative if you cannot make it accessible
• Test your web site in a screen reader. NVDA is open-source and free!
• Provide accurate, descriptive page titles
• Enhance focus indicators on links - non-underlined links should be underlined on rollover and focus.
• Visually hiding content - if you want content that is hidden visually but available to screen readers - use CSS and position off-screen left
• Use the ARIA (accessible rich internet applications) framework, as it helps make web site content and applications more accessible. It helps with dynamic content and advanced UI controls developed with AJAX, Javascript, and other web technologies.
• Wave (not the Google Wave) is a free web accessibility evaluation tool

Following accessibility best practices can lead to great SEO (there, you're knocking two birds with one stone). The proper use of h1, h2, meaningful title and alt tags can not only benefit your site visitor, but also your rankings. Be sure to practice better naming of links, instead of using the usual 'click here.'

Two designers from Google (@leggett and @darrend) made a fascinating presentation this morning at SXSWi around prototyping web apps (#prototypingwebapps).  Starting with the premise that your end goal is to “ship experiences people love” they laid out some guidelines and recommendations for quick, effective prototyping of web apps that:

• Help make your ideas awesome
• Get other people excited about your ideas

The opinion was shared that wireframes don’t really let you see what things look like, a mock up is better, but a prototype is ideal as it lets you see how interaction will work – this elevates the level of discourse and engagement from those who are providing feedback. Prototypes also help you see more flaws in the design.

PROTOTYPE TYPE 1 – Slideshow
A great place to start is with a straight-up slide show whereby clicking on any area on the screen brings you to the next screen.  How much code does it take to show an interaction? None!  Dump in a folder of comps and out comes a slide show.  One step further is to put it in a browser to make it reflect what your app will look like that much more.

PROTOTYPE 1A – Slideshow with Video
The straight-up slideshow  is hard to pass around so, a second approach is to make a video: A simple little 3 minute screencast of someone using the slideshow prototype with narration,  etc.  These get passed around really easily… hopefully, it leads to getting your app greenlit.   (Remember, of course, that it’s all got to be predicated on good feature design.) Adding a story, joke or some kind of surprise can make the thing that much more compelling. 

PROTOTYPE TYPE 2 – Hotspot
If you want others to actually be able to use it, construct a HotSpot Prototype.  This type of prototype lets you represent actual action and an advantage of this over a slideshow is that you can branch.

There are a couple of cheap ways to do it… Fireworks will let you export slices/click targets or you can throw it into Powerpoint, but these don’t really feel real.  (At Google, they have a script for doing some of this stuff in a prototype.)   You can add more than just click targets (like text or input fields) to ramp it up,  but at some point you eventually hit the end and it gets arduous to iterate, so be judicious with the paths/opportunities you enable.   A good rule of thumb is to think of the effect you need, think of the change of state you need and think of “how do i make it look like the effect that I need?”  The presenters like to “be as scrappy as we can be so we move on and iterate on our design.”

PROTOTYPE TYPE 3: HTML PROTOTYPE
When heading down this path, continue to keep it simple. Replace whole chunks of your app with an image whenever you can.   Determine “what do I really, really, really need to work?” Just code the pieces that you need to work.    If you’re testing a tool bar, code that, but you don’t need to make all of the menu options go anywhere.  A related trick suggested was to add things like a 2 second pause so it seems like there’s a server behind you.   This helps the ‘mental model’ for testers.  

SUMMARY NOTES
• Make a Linear Experience:  Show one awesome use case.  Just concentrate on the good stuff.
• Go high fidelity, every step of the way
• “Be Scrappy.  Iterate a lot”: Throw it into a slideshow and click, click, click.  Let you see how it feels before you send it out. 
• Make a commercial, not a spec when you’re trying to sell your ideas.
• Learn to code and be creative (you’re your own special effects dept).  Also, the best way to lose an engineer’s trust if you propose things that don’t work.  Learn/know what’s feasible in the browser.
• Let your prototype coupled with discussion be  your spec.

By following these rules, “you can do everything quickly and make everyone jealous about how fast you can make quick stuff.”  A couple of good, random final points that came up during the question and answer part of the talk:

• Avoid churn/client review cycles by showing small chunks (start with 10%)
• The speakers recommended guerilla usability testing a la the book Don’t Make Me Think, basically advocating getting anyone other than the designer to use it.  – But real testing in a lab is valuable too.
• The speakers don’t believe in rigid line between Interactive/Interaction design (aka Information Architecture), Visual Design and Usability.  All three off these things must be connected and interconnected with one another.
• The only real “wireframes” you need/want to do are sketches .  Knock these out really fast on paper.  There’s no value in high fidelity wireframes.
• Google designers use Jquery and/or write really sloppy, messy code that gets the job the done.
• Show things that have real meaning in your prototypes/comps. Don’t use Lorum Ispum in place of real text and don’t put in things like “description goes here.”  Think out the language at this stage of the game.

The speakers promised to put some resources up at SLIDEFOLDER.COM within a couple of days.  I’ll do my best to update this post at that time.

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.