User Experience Group

Don’t make a mega mess of your new Mega Menu

2011-02-11T18:09:00Z

Mega Menus are quickly becoming ubiquitous. So I thought I would share some design considerations as people build these into their website designs, but first I want to distinguish between Mega Menus and traditional dropdown menus. The main difference between the two type of menus is that Mega Menus allow you to surface up sub content and provide the user with structured choices by grouping the content. Mega Menus also give you the opportunity to illustrate choices by including images within the menu itself. Here are some examples of both types of menus:

Traditional Drop Down Menu Example:
www.imdb.com

Mega Menus Examples
www.nike.com

www.goodmans.ca

Mega Menu Benefits

Helpful to quickly scan through the sub sections of an area
Visually compare all choices and if content is grouped together meaningfully
Easier to locate desired content quickly.

Caveats

Like most interesting things on the web, Mega Menus can be easy to abuse, making them less meaningful and confusing for visitors. Here are some of the things to consider:

Avoid complex interaction by the user. E.g. search boxes or input fields. Mega Menus are meant to have a quick screen presence, not replace complex pages.
Aim for medium level of granularity with depth of the Mega Menu. It is a fine line: large or long groups require too much time to scan the options; multiple, small groups forces users to try and understand the differences between the various groupings
Avoid putting additional text in the Mega Menu (see Goodman example above). Rarely does this type of content offer value to your visitor, and may distract more than help.
For grouped content, make sure the labels are descriptive and concise.
- Links below headers should be alphabetically ordered by columns, not rows, for easy scanning.
- Make use of colour and typography to distinguish your headings from content
Timing/speed is important to consider. Mega Menus that flash in and out too quickly can annoy, but users may think there’s a freeze if menus remain open too long after the mouse has left the menu area. The menu must be smart enough to know that the visitor is scanning the content based on the mouse position and should not close too soon.
Duplicating links or labels should also be avoided in Mega Menus. It creates a guessing game causing users to wonder if the two options link to the same content or if it is different content.

Styling SharePoint 2010 - Refrencing Your Custom CSS

2010-04-15T20:36:00Z

As I delve deeper into styling a SharePoint 2010 site, I am discovering a few quirks here and there. Normally as each new challenge arises and I find a fix for it I just move on, rarely documenting what I did to fix the problem. This made it a bit of a challenge for me when on the next project, the same quirk arises and I'm left pouring through MasterPages and CSS files trying to remember how I fixed it last time. So, I have decided to start documenting these little things as they happen as a reference for both myself and other developers out there.

Now what prompted this particular post was something tha thad a very simple solution. You see when I started this particular project I decided to use Randy Drisgill's 2010 Starter MasterPages. I thought this would be an easy way to strip out all of the the extra coding that came with Microsofts v4.master. Everything worked great, until I tried to apply the MasterPage on another team site and for some reason I was getting a 404 error when it referenced my custom stylesheet. I had uploaded my custom css and images to the appropriate folder in the team site but the MasterPage was looking for the files in the root site and not the current site collection.

After a bit of research I discovered that I needed to update how I referenced my custom css. In Randy's Masterpage he references his Custom CSS like so:

<SharePoint:CssRegistration name="custom.css" After="corev4.css" runat="server"/>

Using the format above it will always look for custom.css in the root directory, not the current site collection. By updating it to the following it will reference the current site collection:

<SharePoint:CssRegistration name="<% $SPUrl:~SiteCollection/custom.css %>" After="corev4.css" runat="server"/>

Hopefully this will help someone else out there.

Cheers!

Print Stylesheets affecting the Rich Text Editor

2010-04-07T19:04:00Z

Every now and then a client will have some very specific requirements when it comes to the print view of their website. For those clients we will create a custom print only stylesheet that is referenced when the page is printed. I will not go into detail here about what you should include in your print stylesheet but if you are interested in learning some best practices I would highly recommend Eric Meyer's article on A List Apart titled Going to Print.

What I do want to talk about is the fact that this week I came across a strange bug with SharePoint Moss 2007 and how it referenced my print stylesheet. Specifically it was affecting the Rich Text Editor dialog that opens when the user edits a Content Editor Web Part. For some reason, the print stylesheet was overiding the default stylesheet but only within the Rich Text Editor dialog box. Once you clicked OK and the content appeared within the site, the styling was fine.

I admit I was stumped for a while and could not find anything online that talked about this specific issue. Everything looked OK from my end, the media for the stylesheet was set to print and by all accounts it should not be referenced at all but of course there it was every time I opened up the Rich Text Editor. After hours of searching for a solution, I decided to open up my print stylesheet and wrapped all of my print styles within the @media rule. I figured it was worth a shot and 'lo and behold it worked! The print styles now behave as expected and they no longer affect the Content Editor Web Part's Rich Text Editor dialog box. Instead my beautifully crafted print styles only appear when the page is printed. At that moment I did a little chair dance and decided I had to share this little fix with other developers out there.

So, to help someone else that may come across this issue, below is how I implemented my print stylesheet in a SharePoint Moss 2007 project. The important elements are in red.

In my MasterPage I have added the following link after my main CSS has already been referenced. Please note that the media must be set to print for it to work properly:

<link rel="stylesheet" type="text/css" href="/Style%20Library/project/css/print.css" media="print" />

In my print.css file I have surrounded all of my styles within the @media print rule:

@media print {
/* ----- Add Your Print Styles Here ---- */
BODY, form {text-align: left;}
}

If you found this helpful, please let me know! I would love to hear from you.

Cheers from your helpful Interaction Designer

Building a User Experience Team

2010-03-29T21:34:00Z

A while back I was asked to answer some questions on how to build a User Experience team. I'm always interested how other teams work, so I'm sharing this in hopes that people will share their experiences with what works and what doesn't. This is how we're working now...

What is the typical workflow for interactive design? Who provides the project requirements and how are those requirements typically communicated? Wireframes? Functional requirement document? Back of a napkin?

Our workflow has evolved over the years to best meet the needs of the client, designers and developers. What's been working well for us for quite a while now is:

Business Analyst meets with client stakeholders to understand the short-term goals (1-3 years) of the business, and how they map to the goals of various groups in the business. Then we discuss how the proposed solution is expected to help achieve the primary goals. Having all of this context helps us guide the client towards making informed decisions and trade-offs throughout the rest of the project.
Business Analyst works with Interaction Designer to create annotated wireframes, which serve as the detailed requirements. We've gotten away from using use case documentation on many projects. Clients and developers continue to positively respond to the more visual representation of requirements that the wireframes provide.
Wireframes are used to achieve consensus on the features, information architecture, and screen layouts. Once an agreement is reached, developers can use the wireframes to start coding.

How to coordinate workflow between designers and developers? Currently the architect provides wireframes to designers, designers provide comps to developers, developers create websites. This breaks a lot.

Our Interaction Designers are graphic designers who can code great HTML/CSS. So after they work out the comps and get approval from the client, they're also the ones who do the front-end coding which gets handed off to the developers. This is our ideal mode of working and the developers respond well to it. However, the ratio of Interaction Designer ("ID") to Developers on a project is usually 1:many, so the ID doesn't always get to do everything at the start of the project. But they're usually assigned to the project at approximately half-time during the Implementation period so that they can continue to help with the HTML/CSS coding and tweaks that need to be made again once the developers are done with their portion. The collaboration between the two groups continues to go very well — there's a mutual respect for each other's roles on the project.

What types of hires should I be looking for? How should I configure my team and what roles should be in place? Currently I have graphic designers, developers, and an information architect. Am I missing anything? Should I replace graphic design with "interactive designers"?

Tough question. The title "Information Architect" tends to mean different things at different places. Most commonly, I find that this person is a jack-of-all-trades (usability, interaction design, information architecture, front-end coding – maybe even copywriter). It sounds like you've been using them in the role of what we call Interaction Designer to create wireframes based on the requirements. I find that by having the person who does the graphic design also do the front-end coding we're always producing designs that can be implemented.

How to manage creatives? General management philosophy about how to manage and inspire designers.

I think the most important thing is to foster respect between your creative team and development teams. This takes a lot of teaching and the job is never really complete. Create dialogues that help both sides understand each other's perspectives and frustrations. Let them figure out how they can best work together. What's worked for us is to encourage everyone to look beyond the design of our web applications to the design of everyday things. We have an email alias, comprised of creative people and developers who often discuss the user experience of many aspects of the world and it's a great alias that exposes people to new ideas (good and bad). Your designers probably all have their favourite places/things (websites, books, blogs, art) for gathering inspiration but they'll also gain inspiration from the ideas of others. So making your design process more collaborative and iterative, when possible, will only benefit the final product. This blog post I wrote was inspired by working with developers for years, and hints at how we try to work together at imason.

So how do you work?

Don’t Tell Me You’re Not a Designer

2009-08-06T15:03:00Z

Often, when I’m working on a project with someone who isn’t an Interaction Designer I’ll inevitably hear the phrase, “I’m not a designer, but...” followed by an idea or suggestion for changing the user experience. This is frustrating to hear.

Designers are facilitators of ideas. We assemble requirements, best practices and ideas into visual representations for consideration. But we’re not omniscient divas who will storm off at the first hint of a non-designer’s opinion.

Good designers analyze the big picture and the minute details of a design problem. We should be able to tell you why our concepts work well, and where there’s room for flexibility. Rather than telling you that our design is perfect, we need to hear your feedback. We want to collaborate with you to improve our design – it will probably never be perfect, but it can always get better.

So if you’ve got an idea for changing a design or interaction, throw it out there. Sure, designers may have more experience and knowledge about the rules of engagement for design and usability principles – but a good designer won’t shoot you down. Just like we hope that you won’t immediately dismiss our first take on a design solution. Let’s work together here – no ideas are bad, they just might not be the best ones. But we can filter out the good ones together.

Think of a designer’s concepts as sparks for a fire of ideas. I don’t care that you’re not a designer. I do care about your sparks.