This is version 2 of the Better Defaults library, expanded to sixty five (or so) interactive and cleanly styled widgets. Use it in place of the standard widget set.

Reasons to use these widgets include:

• Consistent and improved styling.
• Polished interactivity.
• Standardized labeling.
• Expanded set of shapes & controls.
• Rollover, MouseDown, Selected, and Disabled styles for most controls.
• Includes all defaults.

This is for version 5.5 and above. Put the extracted .rplib file in your “My Documents\My Axure RP Libraries\” folder (Windows) or your “Documents\Axure\Libraries” folder (Mac).

Preview |  Download

1. Plan
   • Choose a central theme.
   • Make a list of widgets that will be included.
   • Determine a common style to use throughout the library. This may include color, grid, typography, interactivity, and copy.
2. Create
   • Open Axure RP.
   • In the widgets pane on the left, click the “Wireframe” dropdown and choose “Create library…”
   • Save the new document with a short, clear name—this will be the name that shows up in the library droplist for everyone.
   • Create each widget just like you would create new pages in a normal prototype.
3. Polish
   • Name everything that may be interactive. A dynamic panel for showing a calendar should be named something like “panel – calendar”. A submit button should be something like “button – submit”. This will help your users during annotation and spec generation.
   • Add Rollover, MouseDown, Selected, and Disabled states to interactive shapes like buttons. Right click the object > Edit Button Shape > Edit Rollover Style (etc).
   • Many widgets may contain more than one element. Group them together (ctrl + G) to ensure they don’t get separated when your users move them around.
   • Sort the widgets. This is difficult because you have to do it manually and there is no best sort order. Play around with sorting options, such as alphabetical vs. order or importance, to find what’s right for you. It’s worth the effort.
   • Add custom thumbnails. Another pain-in-the-butt task that will improve the professionalism of your library tenfold. Take your inner icon designer out for a spin and start producing 32 x 32 px thumbnails in .png format. Apply them to widgets by right clicking the Widget > “Widget Properties” > “Import Icon”. Make liberal use of screen grabs. Even your lamest effort at producing an icon will look better than the grainy compressed default that Axure spits out.
   • Add descriptions. I don’t always do this, but for complex widgets, it can be good to explain them a bit. Right click the Widget > “Widget Properties”. Put your description in the text area.
4. Distribute
   • Hosting .rp / .rplib files is fraught with issues due to their resemblance to .zip files. There is one true method for hosting these things successfully (take my word for it): Put the .rp / .rplib file(s) in a folder, and zip the folder. This is the file you distribute.
5. Announce
   • The best places to announce Axure libraries are:
   • Twitter (plug: I’ll probably RT you if you direct a message to @lorenbaxter).
   • On the Axure Forum.
   • Submit to Axure’s official list of resources.

Happy prototyping!

Kevin Wick has posted a very nice sketchy-styled Axure library.  I highly recommend it.

Prototyping in a very low-fidelity visual style generally helps your stakeholders provide feedback at the right level, as discussed in this article, and has been adopted by many other design tools, notably Balsamiq.

I recently joined a wave of about seven user experience professionals, with all of us participating and discussing, in real-time, the merits of Wave. In fairness, if you send seven UX snobs to review almost any interface, you can expect some berating. And this is a closed “preview” (read: beta) version. But what occurred was an absolute evisceration. In this post I attempt to distill the feedback by providing three criticisms and three suggestions about how Google Wave can be improved.

Criticism 1: An Identity Crisis – What is Google Wave?

“Google Wave is all this interesting stuff on the screen, all around me. A wave is a shared space, where you can discuss, and work, and communicate, with friends and colleagues, using text, and videos, and photos, and maps, and all sorts of interesting stuff.” - Doctor Wave

Holy crap! It’s everything! In the instructional video that Google expects the user to discover floating in their inbox, the Google-PM-turned-mad-scientist “Doctor Wave” point out that, really, they aren’t too clear on what it’s for either. Herein lies the first problem with using Wave: it has no idea what need to fulfill.

Criticism 2: Out of Context – Why am I here?

Upon receiving the invite to use Wave and signing in, I found myself staring at a bunch of functionality. The internal conversation went something like this:

“Why am I here?”
“To check out Google Wave”
“Yeah. It’s pretty crazy.”
“… What now?”

This highlights the second problem with Wave: many people arrive in the software with no context. Because it’s not marketed or designed as an application to solve a specific need, it’s up to the community to discover what problems can be solved in a better way by using a wave. You have to come at it with a goal: to plan a trip, to organize a project. If your goal reads vaguely, like “figure out how Wave can be useful to me”, you will probably walk away frustrated. Unfortunately, you can’t help but enter the application with this goal at the moment.

Criticism 3: Do I make you nervous?

As you type in a wave, other participants can see you typing in real time. (There is a feature to disable this, but it’s not implemented yet). Imagine yourself sweating, nervous, your hands shaking as you mash out typo after typo in front of a conference chat. You type something which you decide you don’t want to say, but by the time you erase it, everyone has read it anyway.

Furthermore, when a few people are typing and clicking around at once all the “blips” (messages) in the wave start jumping all over the place. Text appears and disappears everywhere, things move around, the other parts of Wave ping you with chat messages and unread inbox items, and you can’t see the screen because it’s covered in the remnants of your brain, which has just exploded in protest. Imagine everyone in a big room, standing in their own spots and just yelling in all directions at the same time.

Finally, and this just confounds me, anyone can edit anyone else’s messages, even while they’re typing them. Imagine the disaster that happens when four people start editing the same content at once.

So what should Google do?

Suggestion 1: They should start small.

Instead of telling people that Wave will solve all their problems, if only they could figure out how, Wave should introduce itself to solve a single problem. This could be something like.. Plan a party. Google Wave is your new party-planning software. Give people a reason to be there, and a goal to work towards as they navigate and discover Wave’s features. People will naturally discover new and interesting applications of their software, and the use will broaden over time. But people have to use it first, and right now they have no clear reason to do that.

Suggestion 2: They should end the closed beta.

I cannot imagine what made Google think that it was a good idea to give out limited invitations to a closed space that is fundamentally social. Many of us arrived in Wave staring at an empty contacts list and no idea who else was using it. Furthermore, the invites tend to spread to the ultra-connected early adopters. But most of my real friends aren’t that person. How do I plan a camping trip on Wave when none of my friends use it? It will open up someday soon, but the taste is already bitter. Google should open things up now, so that we can begin to contact the people we actually need to communicate with.

Suggestion 3: The real-timeyness needs changing.

But I don’t know what. Moderation? Guidelines? Established etiquette? Outright deletion? Currently, any lively real-time conversation between more than two people evolves into mayhem. Either some sort of social rules that keep things in order will arise from the user base, or Google needs to change how this feature works. They can start by turning the real-time typing off by default.

Google Wave may turn out to change how we communicate after all, but they need to build a lot of bridges. The large gap between novice and effective use of the system, in its current form, will stifle its success.

Web applications and sites these days are using many social features. This library, compatible with Axure versions 5.5 and up, contains many of the standard widgets you will need to prototype basic social functionality.

You’ll find a lot more than nice looking stencils – these widgets have polished interactivity, for your prototyping and usability testing needs. And always feel free to contact me if you have any requests or additions!

Preview | Download the Widget Library

(place the .rplib file in \My Documents\My Axure RP Libraries\ for it to load automatically when you start Axure)

Widgets in this library

• Add Friend
• Email This
• Favorite
• Flag
• Follow
• Leave a Comment (single and multi)
• Loading GIF (big and small)
• Post Status
• Rating (plus/minus)
• Rating (thumbs up/down)
• Rating (stars, with and without label)
• RSS
• Save
• Share This

Screenshots

Add to Friends Widget

Rating Widget

Email This Widget

Notes

Although they were developed separately, there’s a bit of an overlap with another neat widget library by Roslyn Zolandor.

Most of the icons in this library are from the awesome Silk Icons pack.

Axure Social Widgets Library by Loren Baxter is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Engagebig.com v2 Prototype

This redesign was not too complicated – we wanted to present a more professional, modern site, focused on delivering a single point at a time, while keeping it all relatively simple. The small video clips of us were inspired by (and use an API to) robo.to. They are a fun way to get a better idea of who we are.

The main Axure lesson I’ve taken from this prototype is that we can use opacity gradients to “fade” scrolling elements in and out of the screen. Note the left and right sides of the carousel animation in the prototype. This effect didn’t go into the final design, but it was fun to develop.

Also note the nice browser chrome. Unfortunately I can’t redistribute the .rp file itself because it uses the very-awesome but for-pay Konigi icons.

Let me make it clear to Last.fm and every other website in existence: I haven’t the foggiest clue what your specific username requirements were when I registered, or whether I decided to use my first name, full name, moniker, or favorite Steinbeck character.  But I do remember something very well – the same email that I’ve used for the last 6 years.  Ask me for that for login credentials, and we’ll get along just fine.

Interaction Designers – I’m looking squarely at you.  This is our job.  In my opinion, a username is a completely invalid login requirement for all but the most fundamental credentials, such as your OS account, or for bank accounts (which can claim the “higher security” excuse).  What do you think?

— Update —

@salConigliaro points out, “At the very least let me use my email address as my username.”  While I agree, this also means that your publicly displayed username, assuming that’s why the user name exists in the first place, has to be your email address.  For both privacy and formatting concerns, this may be less than ideal.

About a month ago, the folks at Zurb published a nice article about sketching wireframes.  I went ahead and purchased some new sketching items including a nice thick sharpie and a cool gray “dropshadow” pen.

The difference in my sketches is incredible.  Zurb hits the nail on the head, saying, “Although we advocate keeping things as simple as possible, presentation is everything.”  I wholeheartedly agree.  While it’s important to stay in a sketchy, mostly grayscale environment while doing early prototyping, there is nothing wrong with keeping your deliverables professional looking.

In that sense, and through deep offense at the default White, Black, and Blue widgets offered with Axure, I’ve created a small library of widgets that are just a little more aesthetic.

This is for version 5.5 and above.  Put the file in your “My Documents\My Axure RP Libraries\” folder.
Download the Widget Library

In the name of transparency and providing a useful example for the design / ux / development community, I’ve posted the Axure prototype for our next version.  We’re pretty excited about the upcoming re-release, and I hope that the prototype can help show a piece of the process that our UX team goes through.

See the Axure Prototype for Do the Right Thing v2

The new design focuses on ideas – which are fundamentally more positive than complaints and compliments, because they are guaranteed to have a call to action.  The final release will have a few changes, and we had the liberty of leaving out some pieces that have already been implemented on the first site, but overall this is a fine example of what a site prototype can look like.

In other news, posts have been slow recently because I’ve made a move to South America.  There are challenges to being a global Web Worker, and I plan on writing a bit about the experience in the future.

Get enough screen real estate.  Lots of it.

Studies have shown that larger screens can make people much more productive, reaching improvements of 40 – 75%.  This is especially true with design applications like Visio, Axure, OmniGraffle, and Fireworks.

Having a second monitor can allow you to have a reference file on one side while wireframing on the other, reducing the need for window management.

Use scrolling shortcuts (and a mouse).

Scrolling around a large wireframe by clicking the scrollbars requires a lot of extra targeting with the mouse.  Avoid scrollbars completely with the following shortcuts.

Most design applications follow these conventions:

• Scroll up/down: Mouse wheel
• Scroll left/right: Shift + Mouse wheel
• Zoom in/out: CTRL + Mouse wheel
• General scrolling: Space + Mouse button 1

• Copy+paste an element: CTRL + Click an element, drag it to the target location.
• Move an element, maintain alignment: Shift + click and drag

Pimp your program.

Adjust tools to fit your style of usage.  Remove unnecessary toolbars and buttons; add useful ones.  Learn keyboard shortcuts.  Move panels around.  Keep the process of making your process faster close at hand.  Improve your own User Experience.

Watch your fidelity.

The lower your fidelity, the faster you can work.  People’s natural tendency, though, is to make their designs look good.  Be wary of any visual flourishes. It’s tempting to round the corners on that box, or put a little gradient on that button, but that’s a slippery slope.  Wireframes can be made to look very good without many visual flourishes by using minimal colors (light grays work well), pleasing alignment, and appropriate whitespace.

Use open source stencil and icon libraries.

Don’t reinvent the wheel.  There are great stencil libraries for Axure, Visio, and OmniGraffle, and hundreds of quality icons can be found at Wikimedia Commons.  Build yourself a template or folder that has all of the elements you need prepacked for every project.

Use masters / backgrounds / reusable elements wisely.

When creating a widget, layout, navigation, or any other element that will be reused across pages, always consider making it a master or background.  Consider what it will be like to change the wireframe in the future.  Is there a complex widget that has been copied and pasted across many screens?  Updates to that widget will require a lot of extra editing.  Construct elements with the future in mind.

Do you have other techniques for speeding things up?