Cringe Factor: When Designing You Need To Use Real Content

I got a design packet the other day that made me cringe.  It was full of that “LatinCryptic” placeholder text, you know the one I mean that starts of with “Lorem Ipsum” that Apple’s PageMaker has made so famous in today’s digital world.

It’s meant to be a placeholder that shows a general look and feel of the page without actually focusing on content.  When this used, it means the designers are focusing on only one possible use case.  It’s tough to break out of the box with these designs and often enough a design needs to be reworked either before or after the implementation.  When I see this sort of thing in my head I translate it as:

“Lorem Ipsum” == “I am too lazy to think up some real content that is relevant to this application”

Volume Should Match Design

Using this sort of placeholder doesn’t help communicate what sort of content we’re actually dealing with.  Is it a company article? A procedural manual? An event alert? Who knows?  Worse, what if the real content doesn’t fit within the actual design?  They’ve designed for 200 words of content and in reality there are 2000 words of content – now what?  Or what if the opposite is true? A design built for paragraphs of content when in reality only a sentence or two is needed.  What if the person writing the content starts trying to write according to how many paragraphs were in the original design?  Lengthy, wordy  and confusing content may end up in your final product simply because there was space for it.

Understanding the Context

Writing sample headlines, menus and micro copy that is specific to the application or business helps you nail the design and allows you to catch any misunderstandings with the design prototypes early in the process. Better to clear the air and catch miscommunication early in the project rather than after the design has been built out and you’re populating the website with content.

Support Real World Scenarios

One of my favorite parts of the design process is the pen and paper walk through.  Designers can create their own pictures and pixel perfect mockups, but there is just something magical about sitting down with a user and putting a pencil in their hands.  It’s awesome to see how empowered they become when they realize they’re allowed to mark up these beautiful pictures however they want.  If they don’t understand the context of what their looking at they can’t give you the feedback you need to give them the awesome user experience they want.

Don’t Become Another Visual Element

To use the often overused adage, “Content Is King.” When you use Lorem, you diminish the importance of the content to the same level as any other visual element – it ends up becoming a supporting role to your design.  Effectively, your content is enhancing your design rather than your design enhancing the meaning of your content.  Lorem is a work around that largely ignores the most important part of your site.

Ultimately your design is supposed to enhance your content and usability.  IF you have the most uber awesome site with all sorts of wiz-bang widgets and animations but your content is junk then nobody will use it.  If you build it does not mean they will come.

 

 

 

Sign In As A Different User In SharePoint

I’ve seen or searched for this about a million times so far, so why not write up a quick post about it…

With SharePoint 2013, a decision was made to remove the “Sign in as different user” option.  It was a weird decision to take that out and yet leave in the “Sign Out” option considering most people using SharePoint are in a corporate environment with access to Active Directory.

This creates a rather confusing situation for the user where they click the “Sign Out” button, close the browser and when they reopen the browser they are signed in again.  To the average end user it looks like they were never actually signed out and that the sign out button is useless.

For me as a developer, I absolutely loved the ability to sign out and sign back in as a different user because it allowed me to quickly switch between users as I was testing my site.  Luckily, while the option is now hidden from users, the functionality remains.

In order to sign out and sign in as a different user, all you need to do is use the close connection URL:

_layouts/closeConnection.aspx?loginasanotheruser=true

So if you want to quickly logout and log in as someone else, all you need to do is go to:

http://<sharepoint_site>/_layouts/closeConnection.aspx?loginasanotheruser=true

Since this link is so incredibly useful to me, I generally end up putting a link to it in my favorites bar when I’m working on testing the site, or even a temporary link in the masterpage for other testers to click on as the site is developed.

 

 

SharePoint Branding, Don’t Remove the Quick Launch

Last month I wrote about SharePoint Branding and made this point:

Maintain Functionality

This is especially important, and one of the reasons that creating a customized masterpage can be a little intimidating.  SharePoint is both and application and a platform and has a lot of baked in functionality and content that will need to be available for the site to function and grow properly.  And yes, the site will grow.  Remember that you are building out a framework for content.  While you may be able to create specific prototypes for specific use cases by hacking up a default masterpage, don’t forget that there are a number of sections that need to be included in order to have the entire SharePoint experience available once the site is live.

And this is especially important when working with designers who are more client focused than they are administrator focused.  When designers are working on use cases, they almost always focus on the client presentation layer and sometimes forget that there are several types of users for the system (Hence why I love personas and use cases that include ALL users).  One fairly common scenario I’ve seen is the following:

  • UI Designer delivers the design comps focusing on the “front door” – i.e. home page.
  • Home page comps don’t have the left navigation.
  • Left navigation is removed because it is not needed
  • Admin goes to add content to the site and…???
  • Left Navigation now becomes an important design element

SharePoint Quick Launch may be ugly, but it’s an integral part of how SharePoint functionality works.  If you remove it you end up affecting many of the components of the site like calendars, managed metadata navigation, blogs, etc.

When a design comp is created, often times there are elements of SharePoint functionality missing because it’s not needed for that page.  But that doesn’t mean the site overall won’t need access to that functional area in the future or in some other use case.  One of the biggest mistakes I’ve seen is to remove elements from the master page (or create a bunch of master pages for each use case) instead of just hiding these elements.

The best solution for this situation is to just add the Quick nav back to the masterpage and then hide it when you don’t need it or enable it when you do.

How To Hide Left Display Panel in SharePoint 2010 and 2007

SharePoint – How To Hide Recycle Bin & View All Site Content links in SharePoint 2010 and 2007

SharePoint Branding – What Is It?

One of the main challenges I’ve had as a “SharePoint Guy” is trying to explain to UI developers I’ve had to work with that SharePoint is a little different in terms of how to control and brand a site and the features we can offer users of the site.

While there are many reasons for wanting to brand a site. If you’re using SharePoint as an Intranet, it helps build company identity if you match the company’s design patterns.  You might want to increase adoption by improving the overall user experience. If company colleagues can have input into how their sites will look and feel they will be more willing to adopt the product.  Custom branding often means the difference between an apathetic user and one who identifies SharePoint as a useful collaboration tool.

In a nutshell, SharePoint branding is a way to change the basic look and feel of OOTB SharePoint in order to give it a more customized or personal appearance.

If we decompose the tasks for branding SharePoint, we can usually define a specific set of features that are important to every use case for branding.

  • Site Master Pages
  • Site Customized CSS
  • Page Layouts/Templates

Now, there are some people who will also add the site behavior (i.e. JavaScript) to the branding deliverables.   Hover effects and animations are as much a part of branding as the site logo.  Branding your site isn’t just about how it looks on paper, it’s how it feels to the user – the “User Experience” as I’ve often seen the term phrased, And of course, the branding of a site is as much a process as it is a finished deliverable. I always cringe when I see a packet of hi-definition mockups tossed over the wall with a note attached, “How long will this take?”

When taking on a branding project for SharePoint, there are a couple of elements to keep in mind as you work through the process:

Maintain Functionality

This is especially important, and one of the reasons that creating a customized masterpage can be a little intimidating.  SharePoint is both and application and a platform and has a lot of baked in functionality and content that will need to be available for the site to function and grow properly.  And yes, the site will grow.  Remember that you are building out a framework for content.  While you may be able to create specific prototypes for specific use cases by hacking up a default masterpage, don’t forget that there are a number of sections that need to be included in order to have the entire SharePoint experience available once the site is live.

CSS classes are another boogieman in the SharePoint world.  There are a lot of CSS classes in SharePoint, not all of them are obvious in their downstream affects. I honestly can’t recall how many times I’ve seen core hacked up to get a functional version of a prototype out the door, only to see that same CSS screw up the formatting or functionality of other webparts that were added at a later date that were not included in the original use cases.  Take the time to research SharePoint CSS and understand what it does before overriding it.

Look For Quick Wins

Sometimes, it really is the little things that matter most. Adding a few navigation icons, drop down megamenus or live-tiles to your site will make it look and feel more customized and improve the navigation experience.  Personalization is key when branding SharePoint, if only to give the user a quick little “Hello <username>” and maybe display their profile picture.  Sometimes even replacing some of the default site icons with a company icon can make a big difference.

Define A Deployment Strategy

This one gets overlooked a lot during the design and build phase. Think about the life cycle of your site and how often the branding elements are going to be updated.  Is your branding related to a sub-site or are you going to have alternate brandings with sub-sites? Does the site apply to all web applications in a farm or the farm itself?  Will users be able to update the Style Library to add their own customizations for their specific sites?  These decisions will all play into how best to deploy the branding solutions to your sites. This makes a difference on where your branding elements will ultimately reside when the sites go live and can be a nightmare to maintain if not thought about upfront.

In summary, when you embark upon a SharePoint branding project you need to consider the following:

  • How customized styles will be achieved
  • How these styles will be applied to the farm, web app, or site
  • Maintaining SharePoint functionality in all use cases
  • The best strategies for deploying and maintaining these design assets

And ultimately, whatever process you choose, realize that it is a process and while at the end of the day you may have some pretty pictures and mock-ups – they mean little unless everyone has collaborated throughout the process and understood what the user experience is.

Hiding HTML elements from the SharePoint Dialog Box

Having worked with SharePoint branding for a while, one of the interesting items is how content pages will appear in the web interface for desktop interfaces vs how they appear in the pop-up dialog boxes. Ideally we want to be able to separate the presentation from the content, but also be able to reuse the same page whether it’s showing up as a full page or as a dialog box.

Anything you add to a custom SharePoint Master page will in general show up on the desktop view as well as the pop-up dialog boxes. The standard SharePoint 2010 method of hiding branding like logos and navigation from the SharePoint Dialog windows is to to tag your customized HTML elements with the “s4-notdlg” class. As an example, if you’re building out using BootStrap HTML and don’t want your headers and footers to appear in the dialog box, we can simply add s4-notdlg to the elements, so this:

<header>
<footer>
would become
<header class=”s4-notdlg”>
<footer class=”s4-notdlg”>

And that works fairly well in hiding your headers and footers. However, if you’re a big fan of keeping your presentation pages as clean as possible, you may not want to inject SharePoint specific classes into your pages, especially if these classes may change from version to version. For example, in SharePoint 2013 Microsoft has changed over to recommend that “ms-dialogHidden” is now their preferred method of hiding certain elements from the dialog box, so the above example, to be 2010 and 2013 compatible would now look like this:

<header class=”s4-notdlg ms-dialogHidden” >

<footer class=”s4-notdlg ms-dialogHidden” >

So now we’re stuck adding additional classes to our pages or webparts if we want them to not display in 2010 and 2013 dialog boxes. We may even need to go in and update them again when 2016 rolls around. And we’re stuck adding this class to every HTML element we don’t want to display in a dialog box. Surely there must be a better way?  When we look at the sourcecode of a page where you’ve passed in the “?IsDlg=1” querystring, you may notice an interesting thing, it adds the class “ms-dialog” to the HTML element of the page:

<html class=”ms-dialog” >

So SharePoint is very helpfully tagging the HTML element of the page with the ms-dialog class, telling us this content page is meant to be displayed as a dialog box.

Knowing this, we can create a CSS style that uses a descendent selector where the ms-dialog class is the parent and the HTML element (or class, identifier, etc.) is the child. Then all we have to do is set the display to none, like so:

.ms-dialog header,

.ms-dialog footer,

.ms-dialog .classToHide,

.ms-dialog #idenitifierToHide {

display:none;

}

This allows you to create a somewhat future-proof and somewhat platform independent (granted, this is SharePoint so we can only do so much) style. As you flesh out your pages and need to create a new element that needs to be hidden during the dialog box, you can just update the CSS statement without having to update your master page/page layouts/content pages.

Since we also know that the .ms-dialog is created using the QueryString “?IsDlg=1” this also allows us some additional creative branding ideas where we can further brand any child elements under the ms-dialog class as well, and hopefully future proof our work against additional class changes in the SharePoint ecosystem.