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!

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:

<!-- Print Stylesheet -->
  <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

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?

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.

Problem: You've been asked to create a graphic design that can be applied to a SharePoint 2007 site - but you've never seen one before. Or, you've seen one but don't have access to the CSS to see how things are set up.

Here are some basic guidelines for creating a graphic design that can easily be applied to out-of-box Microsoft SharePoint 2007 sites. The guidelines apply to designs that will be implemented using SharePoint “themes”, which means that only CSS and graphics can be altered but the HTML on pages cannot. This is by no means an exhaustive list of SharePoint elements - but if you're trying to work on a mock-up of new graphic design, hopefully this will help clarify some of the terminology and limitations you might hear about when discussing the feasibility of implementing the design with a technical team.

Disclaimer: When I say that something "cannot" be done - I don't mean it's impossible, but rather that it's not easily done by modifying a theme file alone. And I won't claim to be a CSS guru either. I have no doubt that people have figured out ways to overcome some of the points below with more crafty CSS than I am capable of.

PAGE WIDTH

• Pages have a fluid width and are designed to occupy 100% of the width and height of the browser window.
• Pages are optimized for a 1024x768 browser resolution.

Tip
If designing with a “grid layout”, commonly used in print design, percentages will have to be used to define the column and gutter widths.

NAVIGATION

Tabs

• Unselected tabs all look the same.
• The selected tab can have a distinct look from unselected tabs.
• You cannot single out a tab and change its style (e.g. adding a “New!” icon or unique colouring that draws attention to it).
• The width of each tab defaults the width of the name of each tab, plus padding of XX pixels on either side of the text.
• The widths of the tabs can be made consistent through styles, but longer tab names should be considered when defining the width.
• The small arrow icon is a graphic, and shows up when a tab has menu items underneath it.

Left Navigation

In Sharepoint terminology, the left navigation bar is referred to as the “Quick Launch” bar. The links in this area are generated dynamically as users add lists and libraries to their Sharepoint site.

• The width of the left navigation area is static and set in pixels. The width is the same on all pages.
• Headings all share the same styles.
• Links under headings all share the same styles.
• The “View All Site Content” link can have its own style.
• The Recycle Bin area can have its own style. 

Breadcrumb

The breadcrumb uses plain text, hyperlinks, and the “>” character to let users know where they are in the site hierarchy.

• Links can be styled.
• Plain text can be styled.
• The “>” character cannot be changed.

Global Links

Global links appear at the top of each page. 

TITLES

Area / Site Title

• The area/site title appears at the top of every page and is a hyperlink which can be styled.
• The height of the white background seen in the screen shots can be modified as required.
• The white background behind the area/site title, logo icon/graphic, and search bar can be styled.
• The position of the title within the white background can be controlled with styles. 

Logo / Icon

The default icon can be replaced with a JPEG, GIF, or PNG file.

• The white background around the logo will increase or decrease in height depending on the size of the replacement graphic.
• The icon can also be hidden and replaced with a background image that contains logos or graphics.

Page Title

The page title is plain text that can be styled.

Page Description

The page description is plain text that can be styled.

• Consider a link colour for the page title, because on some pages the title may be a hyperlink.

WEB PARTS

“Web part” is a SharePoint term that in other platforms means “widget”. A “web part page” could be considered as a dashboard view of various lists consolidated on a single page. The condensed view of each list is referred to as a “web part”. 

Web Part Title Bars

• Web part title bars all use the same styles.
• Sometimes the text is a hyperlink to the full view of a list; other times it’s just plain text.
• The arrow icon on the right side of the title bar cannot be changed. When hovered over a drop-down menu appears.

LIST VIEWS

Toolbar

• The toolbar options change depending on the type of list you are using, but the same styles are used everywhere.
• The “View” option on the right side of the tool bar can have its own unique style.

SEARCH RESULTS

• There may be more than one search scope available, in which case tabs are used to indicate the available options.
• The title of the result is a hyperlink.
• The URL for the result is a hyperlink.
• The paging options are hyperlinks.

CONTENT PAGES

Article Page

• The article title is a mandatory fields and shares the same style as all page titles.
• The article date is an optional field that can be styled.
• The article byline is an optional field that can be styled.
• Content is entered through a rich text editor (RTE). Default styles for RTE text can be modified, and custom styles can be added.