Kyle Schaeffer - Web Design and SharePoint Branding

Design Patterns in SharePoint

Kyle — Thu, 26 Jan 2012 03:32:40 +0000

Last week, I was happy to present at SusQtech’s “30 on Thursdays” weekly webinar event. This is a great series of free webinars from some talented speakers, and the succinct format is a great opportunity to learn something new without a huge investment of your time.

My topic was Design Patterns in SharePoint, which is an introduction to the concept of design patterns, and how to apply them to your SharePoint environment. Luck you, we have been recording these webinars, and they’re freely available on our website. Feel free to view the webinar video below, and check out the webinar archive for any and all webinars that we’ve recorded in the past.

As mentioned in the video, I will be teaching a SharePoint design class in the Netherlands starting on March 22. If you are looking for design training and can make it to the class, please feel free to sign up.

Watch this video on YouTube.

HTML5, CSS3, and Mobile Strategy

Kyle — Mon, 09 Jan 2012 16:48:25 +0000

I had the pleasure of speaking at SharePoint Saturday Virginia Beach this weekend. Thanks for all who attended; I had a great time speaking on some exciting new topics, and sharing my passion for design in SharePoint. For those of you who were at the seminar, and also for those who might be interested, I wanted to share my presentations on my two sessions: HTML5 & CSS3: What About SharePoint? and SharePoint Goes Mobile. You can view or download the presentations in PDF format here:

HTML5-and-CSS3-What-About-SharePoint.pdf (968 KB)
SharePoint-Goes-Mobile.pdf (1.4 MB)

Join me for Advanced SharePoint Design

Kyle — Wed, 30 Nov 2011 14:40:23 +0000

On January 23-26, 2012, I’ll be instructing a class that focuses on the more advanced strategies behind applying style and branding to a SharePoint 2010 website. This isn’t your average SharePoint training class: we’ll cover topics like improving the SharePoint user experience, creative design for the SharePoint platform, and implementation strategy for making your creative designs come to life. Over four days, we’ll learn how to bend the rules in SharePoint to make it a truly limitless platform for customization.

I’ve been working with SharePoint for a long time now, and going beyond the basics is a challenging barrier to overcome. Many of the free online resources pertaining to SharePoint customization (and many of the paid ones) only cover the most simple of changes that you can make to your design. Learning how to implement a more comprehensive design is difficult, to say the least. In this new class, we are taking these advanced techniques head-on, and we’ll show you how to implement awesome changes like responsive layouts, comprehensive themes, and amazing enhancements using jQuery.

At least some experience with SharePoint customization, HTML, CSS, and JavaScript are highly recommended: we’ll be diving head-on into the world of SharePoint design. For more information, you can read all about the upcoming class here:

http://susqtech.com/training/classes/Pages/SharePoint-Designer-2010-Styling-and-Branding-Training.aspx

SharePoint Saturday: Virginia Beach

Can’t make it to the class in January? You’ll also see me speaking at the free SharePoint Saturday event at Virginia Beach on January 7, 2012. I’ll be doing two sessions at this event: “SharePoint Goes Mobile” and “HTML5 & CSS3: What about SharePoint?”

http://sharepointsaturday.org/virginiabeach/

v5, the Responsive HTML5 Master Page for SharePoint 2010

Kyle — Mon, 03 Oct 2011 20:25:49 +0000

“v5.master” is a simple HTML5 master page designed for SharePoint 2010. It makes good use of the amazing new features of both HTML5 and CSS3, including CSS3 media queries. The master page is extremely simplistic in nature, and is truly meant to serve as a framework for building your own SharePoint 2010 customizations.

SharePoint Gets Responsive

SharePoint has a knack for being rigid and difficult to customize. I’ve been working with responsive layouts for a while now, but the nature of SharePoint has thus far prevented me from making something that is as flexible as, say, this WordPress blog you’re reading right now. It’s easy-peasy to do this in WordPress, but SharePoint simply does too much. When you create a layout in SharePoint, you’re creating a layout that encompasses much more than just pages: you’ll have to contend with pages, web parts, lists, libraries, blogs, wikis, search, meeting workspaces, team sites, calendars, and the list goes on. With so much content to contend with, creating something that can contract to any width is a tall order to say the least.

To me, at least, the answer was simple: ignorance. I’m ignoring every part of SharePoint that I don’t care about. 90% of the sites that I create in SharePoint are publishing sites: public-facing with a focus on pages, navigation, and web parts. Now, that’s a list I can handle. The v5 master page uses a fluid layout that drops to a single column when the display size shrinks below 800 pixels in width. Check out the screens to see the flexibility in action:

Large/Desktop Displays:

Medium/Tablet Displays:

Small/Mobile Displays:

Features

New HTML5 document type declaration
Revised content to adhere to new HTML5 standards and best practices
New HTML5 semantic layout (
,
,
, etc.)
Uses html5shim for backwards-compatibility
Responsive CSS3 media queries

Download v5.master

v5-masterpage.zip (16kb)

The v5 master page is provided completely free, released under the Creative Commons Attribution license 3.0.

Update Oct 26, 2011: Dércia Silva has been kind enough to create a deployable solution package, as well as a Visual Studio template, if you’d rather automate the deployment of this master page and related files. See Dércia’s post here.

Installation

Copy the v5.master file into the /_catalogs/masterpage/ folder of your SharePoint 2010 site collection.
Copy the entire v5 folder into the /Style Library/ document library, located at the root of your site collection.
Check in, publish, and approve all copied files.
Change your site and system master page to use the new file you created.
Optionally change the site logo setting to use the new logo image located at /Style Library/v5/i/v5.png.

Requirements & Assumptions

This master page was designed for SharePoint 2010, Enterprise and Standard versions.
This master page was designed and tested for SharePoint publishing and wiki sites. No other site templates have been tested.
Keep in mind that some SharePoint content simply doesn’t work well at smaller screen resolutions (lists with many columns, calendars, etc.). The focus is on external-facing sites with a lot of text- and image-based content.
The SharePoint front-end server must have internet connectivity to access Google’s hosted version of html5shim. If you do not have internet connectivity in your environment, download and use a local copy of this file.

Known Issues (Updated Jan 19, 2012)

A few people have encountered some issues with the v5 master page. Although I think the master page still works great (especially as a publishing master page), you may want to consider making these changes, depending on your SharePoint environment and how you choose to utilize the interface.

Error on “Save” in SharePoint dialogs (IE9) — this is caused by an error in Microsoft’s internal JavaScript files. This easily remedied by simply not using v5 master page as your “system” master page. If use a lot of system pages in your SharePoint site, you may also try adding the following line of code to the section of your master page:
This forces newer versions of Internet Explorer to display in compatibility mode. Note that you’ll also lose CSS3 and HTML5 functionality when you add this to the master page (everything works, but the site will look a little more bland in IE).
Ribbon not appearing at the top of the browser window — I’ve had some mixed reports of this happening in Internet Explorer, but I think it’s actually an indication that the paths to the attached CSS and JavaScript files are incorrect. If you are deploying v5 master to any site other than the ROOT site collection, make sure you update all references to these files where appropriate.
Scrollbars appearing in SharePoint dialogs (Chrome, Firefox, Safari) — this is actually a side-effect of my ribbon/scrolling fix for SharePoint. SharePoint dialogs are still entirely functional, but the positioning and sizing of them just gets a little weird in any non-IE browser. Again, the idea is that the master page is optimized for publishing sites, which don’t make much use of these dialogs (if at all). If you have a lot of trouble with this, consider using a different system master page.

10 Things a Website Should Never, Ever Do

Kyle — Thu, 22 Sep 2011 21:19:15 +0000

As a designer of the world wide web, you are armed with the power to amaze, enlighten, entice, and captivate. The web is an easel for your creative aspirations, and the content you design for is the foundation of your creativity. With so much power at the tips of your fingers, you also possess the ability to deter, annoy, anger, and infuriate. Your users are yours to command, their emotions yours to pluck like the strings of a harp.

It’s the latter of these powers that we discuss today: your ability to destroy the desire for users to stay on your site. We’ll examine the causes of user strife on the web, and see clear examples of common mistakes that designers and developers all-too-often seem to make.

1. Never interfere with the ability to scroll

The browser window is a fairly simple application: an address/search bar, a few buttons, and a big window where users read, scroll, and click. Sure, most browsers have other bells and whistles, but it really boils down to these essential elements of the browsing experience. Rule number one: never, ever (ever, ever) interfere with these most basic features of the browser window.

Example: Microsoft SharePoint 2010

One of the most preposterous features of an interface that I’ve seen is SharePoint 2010′s new ribbon interface. The default SharePoint 2010 interface includes a simple CSS style that disables the scrollbar on the element. Microsoft chooses to remedy this by adding a scrollbar to other division elements in the interface instead. This results in a fairly impressive “fixed” ribbon, but it has some infuriating side-effects.

When a SharePoint 2010 page loads, users will not be able to scroll until all JavaScript has loaded. On slow servers or on large pages, this can take up to 2-3 seconds, which can be quite infuriating.
Some devices don’t execute the JavaScript in the expected fashion, resulting in the complete inability to scroll on mobile devices and tablets.

An easy solution

The truth is, creating a “fixed” element is a fairly simple CSS technique that has become extremely popular in the last few months. The complexity of Microsoft’s interface is it’s downfall. Always practice in simplicity, because fewer things can go wrong in the end. Build simple interfaces, and never disable the scroll bar. Do this, and you’ll know at least one person who doesn’t hate your guts.

2. Never allow form resubmissions

Forms are a fairly standard feature of the web. Users see them and use them all the time: to sign up, sign in, order, update, and the like. With so much familiarity, it’s a wonder that forms are one of the largest sources of frustration to users. Between data, validation, formatting, handling errors, and all the auxiliary things that seem to surround web forms, things can get pretty complex for designers and developers. All the while, you try to keep it simple for your users. It’s a tall order, to be sure, but there is at least one thing that you can do to help users stay calm.

Example: The Form Resubmission Prompt

This is Google Chrome’s form resubmission prompt. Most browsers have something very similar. This appears when users click on the “Back” and “Forward” buttons in the browser, or when they “Refresh” a page on which they have submitted a form. As web junkies, we might know what this means, but it has a more elusive meaning to your every-day internet users. Most of the time, you’ll find that users simply click the default option (in this case, “Continue”), which can lead to duplication of orders, data, requests, and all sorts of things that would be better off if avoided. Also, it’s just another annoying prompt that users encounter while they’re using your site.

A Simple Solution

The solution to form resubmissions really depends on the platform your website runs on. In most cases, a simple fix is to separate the script that submits the form data, and the script that receives and processes that data. For example, if you’re using a PHP-based platform, you might have a form that looks like this:

To avoid the resubmission prompt, your submit.php script would forward to another page, rather than displaying a page in the browser.

if(isset($_POST['user']) && isset($_POST['pass'])){
  // do something with the form data
  header('Location:/login/form.php?success=true');
}

This receiving script never actually displays anything in the browser window. Instead, it receives the form data, does something with it, and then forwards the user somewhere else. Using this technique, when users click on the “Back” or “Forward” button, the browser will skip the submit.php page completely, and never see the annoying form resubmission prompt.

3. Never disable keyboard support

While we’re on the topic of forms, let’s look at another deviation from web standards you’ll want to avoid. To the right, you’ll see a screenshot of the login form at mysprint.sprint.com. I have a Sprint mobile phone, and I occasionally use this login form to sign in and review my account, see my bill, or (more commonly) daydream about all the fancy new mobile phones that I don’t have.

What went wrong

The font sizes are a little small for my taste, but the appearance of this form is not the worst I’ve seen (yes, that was a compliment). Design and aesthetics aside, there’s one feature of this form that drives me absolutely crazy. It’s an extremely simple form, one that I’ve encountered on countless other websites before. As usual, I would expect to enter my username and password to sign in without a fuss.

Unfortunately, this is not the case. While focusing in either the username or password textbox, pressing the ENTER key does absolutely nothing. I’m not the type of user that wastes time after filling out a form by lifting my hand from the keyboard and finding the submit button with my mouse cursor. I’m all about speed: on most websites, it’s type, type, ENTER, and the form has been submitted. On Sprint’s website, however, they’ve removed this behavior, and thus they’ve earned a place on my list of don’t-do’s.

4. Never fail to give feedback

Feedback is important, especially if you’re working with the awesomeness of AJAX. Traditionally, you knew what was going on in a web page, because any time you clicked on something, you had to wait while the next page loaded. There was a very apparent interaction period, and very obvious feedback from that interaction. With the introduction of new technology like AJAX, however, that feedback is not always so obvious. Today’s websites are much more interactive, and the result of those interactions (whether successful or not) needs to be communicated to the user.

Example: Facebook

There’s an easy way to test this: visit a web page, turn off your wireless adapter, and then click on things and see what happens. Obviously, because you’re not online, anything you do should be very obviously followed by a “no connection” message or some sort of indication that you’ve failed to do something. Facebook, a website that makes gratuitous use of AJAX for interaction, is not so good about warning users when things have failed.

Editor’s note: yes, I am using pirate Facebook.

One particular example is the new “lists” feature that allows you to mark a list as “favorite.” Even when you’re offline, Facebook gives you no indication that the action has failed. Never assume that users will have a fast connection, or that AJAX requests will complete. You should always provide feedback if something fails, especially when no page loads are involved.

5. Never disable keyboard navigation

Different strokes for different folks. That’s a saying that I like to spew off at random times, usually in a failed attempt at humor, but the lesson of this silly quip is tried and true: everyone has their own way of doing things. This can also be applied to navigation on the internet. Some people prefer to use their cursor for absolutely everything, and only resort to keyboard use when absolutely necessary. Others use the keyboard almost entirely, tabbing, backspacing, and scrolling their way through the world of the world wide web. Others, still, use gestures and touch screens to flick and fly their way through the internet. As a crafter of the interactive, you must adhere to all of these people. Never detract from your users’ ability to navigate in whatever way they damn well please.

Example: No, I don’t want to search

I’m going to use eBay as an example, just because they’re so big, but many websites out there are guilty of this annoyance. Upon arriving at eBay’s website, they use JavaScript to auto-focus on the search bar. I guess they’ve already decided, before you even visit, that you want to search their website. For some users, however, this can be incredibly annoying. A common and simple way to scroll down the page, in all browsers, is to press the space key. Pressing this key will advance the screen about one page, so you can continue reading without having to worry about scroll bars and the like. If you’re auto-focused on a search box, however, it disables your ability to do this. Even if it’s only a minor annoyance, it can be incredibly frustrating to users who like to navigate in this fashion. Likewise, I often use the backspace key instead of the back button to go back when I didn’t find what I was looking for. With the focus on a search field, backspace navigation simply doesn’t work.

The fix for this one is easy: don’t do it. It’s annoying.

6. Never move content without user interaction

Websites can be so damn sneaky. I guess they need to make a buck, but who doesn’t? One thing that will drive your users bonkers is anything that moves without a prompt from the user. Yes, I’m talking about you, “auto-expanding-advertisement-that-plays-a-stupid-video-of-a-guy-who-walks-across-my-screen-when-I-just-want-to-read-the-damn-article” guy. I also dislike anything that happens on hover (including drop-down menus). Hover is so 2000′s, get with the times, people. The only time your website should “move” or “do something” is when users tell it to. Most simply, any time they click, drag, or scroll. That sounds simple and obvious, but not everyone adheres to this most basic of principles.

Example: Digg.com

While the quality of Digg’s content is another concern, one thing that does drive me crazy is the sponsored links that appear in the rollup. Notice the promotion from NewEgg.com. This link does not actually appear on page load, but rather when users hover their mouse cursor into the rollup of popular stories. This means that if you’re a fast clicker (aren’t we all?), you will often accidentally click on the advertisement instead of the story you’re interested in. Good for Digg, bad for users. Stop being so shifty, internet.

7. Never use fixed position without a fallback

A “fixed” element in the browser window is one that stays on the screen, even as you scroll down the page. It’s a simple CSS technique, but it’s been amazingly popular in recent months. One thing I’ve noticed in all these fixed designs is the failure to provide a fallback for users who are on smaller screens. The truth of the matter is that the web isn’t just for desktops any more. Internet connectivity is coming in all sorts of shapes and sizes: desktops, laptops, mobiles, tablets, e-readers, gaming consoles, and even refrigerators (yes, even refrigerators). The future promises only more diversity in internet-connected devices, and that means you can’t assume users will have a large viewing area on which to see your website.

Example: Pandora.com

This is a screenshot of Pandora’s fancy new HTML5/CSS3 design. First of all, I’ll say that I love Pandora. Maybe too much. It’s pretty awesome, and it even lets me give all of my radio stations quirky little names like “Harmonizatorasaurous” (eat that, spell-check).

Pandora’s new design includes a fixed header, like many new designs, but it seems the header does not provide a fallback for users on a smaller screen. When reducing the window width, it clips the player controls off the edge of the screen. If a fixed element is clipped, users can’t see it, even if they try to scroll to see more, which can be a huge problem.

A simple solution

An easy solution to this problem is to make the default behavior of your site’s header to maintain a static position, but when users have a large enough screen, you can make things fixed for a more impressive presentation. The following jQuery snippet does the trick quite nicely:

$(window).resize(function(){
  resizeUI();
}); 
$(document).ready(function(){
  resizeUI();
});

// resize on page load AND window resize
function resizeUI(){
 if($(window).width() > 500){
 $('#header').css('position', 'fixed');
 }
 else{
 $('#header').css('position', 'static');
 }
}

This script runs both on page load AND as users resize the window, so no matter what happens, you can decide whether or not to use fixed elements. You’ll have to mess with the values that the script looks at (width and height) to determine what works best for your site’s design, but it’s a useful technique to use.

8. Never use pop-up windows

Do I really even have to mention this one? I thought that pop-ups were notorious for the infuriating behavior that have on users, but I still see them “pop up” from time to time (pun intended).

Example: TinyMCE

I never use pop-ups. I always recommend against them. A common excuse is that your site should stay open, in it’s own tab, even if users click a link that takes them away from your site. I’ve got a simple response to that: wrong! Don’t let your head grow so big that you think your website is god’s gift to the internet. Users have gotten pretty comfortable with the idea of tabbed browsing, and they know how to manage their windows. Unless you’re Google, you’re not allowed to use pop-ups. It’s that simple.

Imagine my surprise when I attempted to implement the TinyMCE JavaScript editor into a web application I was building, and realized it still used pop-up windows for things like links and images. I am building a PHP application, and I have had stars in my eyes for WordPress the entire time, so TinyMCE was the obvious choice. I was so taken aback by this behavior that I ended up switching to CKEditor, another popular editor that has recognized the need to rid the world of these annoying little boxes, and I’m all the happier for it.

9. Never get quirky (well, not too quirky)

I love websites that are different, but not too different. There’s a fine balance to be made between adhering to expectations, and getting so weird that users have no idea what’s going on. As with most users, if I visit a website and am prompted to “explore this insanely huge image of nonsense to learn how to navigate our site,” I’m going to leave and never return. I’ve never been a proponent of Flash, for this very reason, but I also recognize that it has it’s place. Flash can enhance a website’s content with some awesome features, but it should never be used to present content in its entirety.

Example: Sony.com

Check out Sony.com, and you’ll realize that a full 5-8 seconds will go by before you actually see anything on the screen that you can click on. Almost the entire site is in Flash, and it breaks about five of the ten “don’t do’s” that I’ve described in this article. All that aside, Sony has provided a non-Flash version of their site, which also subsequently presents a loading spinner for about 2-3 seconds that covers all of the content on the page. I’m not entirely sure why the designer who created the Sony website was so fond of things that come between users and consuming the content they came to read, but I do know this: it’s annoying. Don’t do it.

10. Never do THIS…

Okay, this last one is really just for fun, but never do THIS…

body * {
  -webkit-transition: all 0.5s ease;
  -moz-transition: all 0.5s ease;
  -o-transition: all 0.5s ease;
  transition: all 0.5s ease;
}
body *:hover {
  -webkit-transform: rotate(180deg);
  -moz-transform: rotate(180deg);
  -o-transform: rotate(180deg);
  transform: rotate(180deg);
}

Try it out by clicking on this button (you’ve been warned):

From “Developer” to “Designer”

Kyle — Thu, 25 Aug 2011 16:34:16 +0000

It’s easy to forget how a website really works. I mean really works. I’ve had the pleasure of working with many brilliant and talented developers (programmers) who could bend the functionality of any application or server-side platform at the drop of a hat. They are problem-solvers, as is everyone in this industry of the online.

With most developers, I’ve found that there can be a disconnect between how I understand websites, and how they’ve come to understand them. Not just a disconnect: The Disconnect. If you work in a team environment, you know the feeling. I say “element,” and you say “control.” I say “script,” and you say “method.” Most developers are ultimately, completely, and entirely focused on the server-side application.

That’s okay. I need my developers, and they need me. It’s a good relationship for all of us, with our complimentary skills, tools, and techniques. They make it work, and I make it look good.

How to Connect

Overcoming the Disconnect is all about education, on both sides of the fence. Developers and designers alike would benefit from understanding how the technology that they use comes together. The grand finale of everything that we do online ends up in a single place, where it can be seen, read, clicked, and tested: the browser window.

As a designer, that’s where my beautiful designs will end up, and they somehow need to be translated from Photoshop into HTML and CSS that works well with the server-side application. Good designers understand the technology before they create the designs. Likewise, as developers, the controls and methods that you create are all somehow translated into HTML, whether you’ve recognized that or not. Understanding the output of what you do in the application is just as important as making the application work.

Don’t Forget the Browser

This is where it all ends up. Everything that we do as designers, developers, project managers, or architects: it all comes together in the browser window. The browser is the tool that is used to present all of your hard work, everything that you’ve done throughout an entire project. With so much responsibility resting upon the shoulders of the browser, why is it that so many people ignore it completely?

Back in The Day, the browser is all there was. In 1989, Tim Berners-Lee created the world’s first web server. When requested, it served up documents to be viewed inside the very first web browser. These documents were pure HTML, and the browser interpreted that language in order to create Hyper-Text documents that could be linked together. As you probably know, this simple concept caught on, and by the mid 1990′s, the Internet had become arguably the most influential product of Man in the 20th century.

Everyone that works in the industry of the world wide web should pay their respects to the oft-neglected browser. It has so much power, and it is the tool that allows us to do what we do. The browser is everything. The W3C and WHATWG can make all the recommendations they want: nothing really happens until browsers support it. In the mid 2000′s, the W3C started working on a recommendation called XHTML 2.0. It failed. The browser manufacturers didn’t like it, and that’s why we’re now working with HTML5 instead of XHTML2. Similarly, Microsoft created something called the XMLHTTPRequest in the early- to mid-2000′s, and everyone loved it. The major browsers quickly adopted this technology, and AJAX was born.

The point is, the browser truly has the power in web application development. It doesn’t matter if you’re a programmer or a designer: you need to understand how technology works inside the confines of this little window. In all the amazing technology that surrounds the Internet, it’s really based on a few simple languages: HTML, CSS, and JavaScript.

Making Requests

Web browsers are fairly simple applications. In essence, they do two things: make requests, and handle responses. A request might be something like “show me the document at KyleSchaeffer.com,” or “give me the image at /images/kittens.jpg.” The server that you’re requesting from then responds and the browser does something with the response. It all sounds very simple, but it’s so easy to forget this fundamental layer of web technology. I’ve helped troubleshoot dozens of web applications, and my first question is always “What request is the browser making?”

This entire process is called an HTTP request. HTTP requests are sent by your browser every time you type something into the address bar. The first requests is almost always an HTML document, and then the browser subsequently makes additional requests for things like CSS files, JavaScript, and images. Even if your web application is running on PHP or ASP.NET or SharePoint, the server is returning an HTML document, which subsequently loads additional resources. Simple, right?

1. The Request

Every HTTP request has a URI, or Uniform Resource Identifier. That’s a fancy way of saying the address of the resource you’re requesting. The address can be both absolute (http://kyleschaeffer.com/images/kittens.jpg) or relative (/images/kittens.jpg). The browser sends this request to the “Internet,” which routes the request to the appropriate server, somewhere out there. The browser then waits for a response.

2. The Response

After sending a request, the server that you requested the document from will send back a response. Again, the browser handles the responses, and each resource that is requested is handled differently. First of all, the browser reads the HTTP response code, which is an indication of the status of your request. The most common HTTP response codes are:

200 OK - The most common response; the resource you requested was found
301 Moved Permanently - The resources has moved, and the browser will redirect the request to the new location
304 Not Modified - The resource was found, and your browser already has the most recent version in the browser cache (yay!)
401 Unauthorized - You need to sign in to see this resource
403 Forbidden - You’re not allowed to see this
404 Not Found - The resource you requested does not exist
408 Request Time-Out - That took too long, sorry
500 Internal Server Error - Something went wrong!

My descriptions of each response are less than technical, but you get the idea. If you’ve ever wondered what the “404″ in “404 Not Found” meant, it’s the HTTP response code for “not found.” For a more comprehensive list of HTTP response codes, visit the W3C’s documentation.

Another important element of the HTTP response is the Content Type. This tells your browser how to handle the requested resource when it’s downloaded. Unlike on your computer, your browser does not decide how to use a resource based on it’s file extension! It’s all about the content type. Some of the more clever server-side programmers can actually utilize this element of the HTTP response to create server-side scripts that actually disguise themselves as other types of content (like a PHP script pretending to be JSON or XML).

3. Execution

At this point, the browser now knows the HTTP response code, and the resource content type. Using this information, it’s time to make something happen. The browser downloads the resource, and presents it inside the browser window. Browsers can sometimes handle resource requests differently, so this is where you get into the nuances of browser testing. One browser might handle HTML and CSS requests slightly different from another, so testing your applications is merely a practice of testing how these HTTP responses are handled.

From “Developer” to “Designer”

Bridging the divide between developers and designers is all about understanding how the different technologies of the web come together. The browser window is the one place where the user experience, the architecture, the design, the program, the database, and everything else that goes on behind the scenes comes to fruition and is finally presented. Clients pay for you to meet needs and requirements, but what they ultimately expect is something that appears inside the little box that they call the Internet. Embrace it, learn it, love it, know it inside and out, and you’ll find that disconnecting from The Disconnect is not so difficult after all.

SharePoint Design in Five Minutes

Kyle — Fri, 10 Jun 2011 13:57:03 +0000

You can now download my free SharePoint theme, Medazio, on SharePointDesigNerds.com. We’re still working on cleaning up the site while it’s in “draft” version, but feel free to sign up, browse a couple of the themes that we’ve uploaded, post your amazing SharePoint spotlights, and give us feedback on the design, navigation, and functionality in the site.

Update 8/17/2011: The “Medazio” theme can now be downloaded directly from SusQtech.com/medazio.

The Video

While building the Medazio theme, I recorded over 11 hours of video in order to document the entire SharePoint design and customization process. From creative sketching to design in Photoshop to actual coding of CSS and HTML in SharePoint Designer 2010, you can see the entire project from start to finish, compressed into about five minutes of rapid SharePoint Design fury. Check out the video, download the theme, and see first-hand how SharePoint is truly a viable and impressive publishing platform for your design-savvy projects.

Watch SharePoint Design in Five Minutes on Vimeo.

Responsive Design Testing with Screenfly

Kyle — Tue, 07 Jun 2011 17:04:28 +0000

Responsive design is all the rage. Ethan Marcotte, just today, released a new book on the subject, of which I’m quite excited. My last post was all about responsive web design, and after writing the article, I couldn’t help but ask myself: what now? Designing and implementing experiences for an unknown number of devices can be an intimidating task, especially when you don’t have the opportunity to test your designs on many (or any) of them. The answer, for me, was to create a new web app that aids in this testing process. It’s called Screenfly, and it’s the first of many apps that will be available on QuirkTools.com.

As you can see, it’s an incredibly simple application. Simply type in a web address and you’re off and running. The entire thing, from concept to complete, took less than eight hours of work to complete – don’t expect all the wiz-bang bells and whistles for that type of investment, but I do have to say that I’m quite proud of what this little thing can do.

How it Works

When you type in a web address and hit “Go,” Screenfly builds an and displays it on the screen. The frame contains the web document you specified, and once it has loaded, testing can ensue. While viewing your web document, you will see buttons near the top left corner of the browser window, allowing you to select different devices from which to view your web document. Most of the application is just a few lines of jQuery that affect the frame as it appears in the middle of the page.

Why it’s Useful

What’s really cool about the application is that I use a proxy to request your web document. Basically, I send a request from my server, which allows me to “pretend” like I’m an iPhone, an iPad, or an Android tablet when I make the request. What comes back is the actual content that would display if you were really browsing on that device. This works great on most websites, but you’ll find that some don’t play well with the proxy (things like JavaScript, Flash, Silverlight, and server configuration can break the proxy), so I also give you the option of disabling the proxy altogether. Unfortunately, this also disables the ability to “mimic” the devices you’ve selected, but it still gives you the opportunity to see your web layouts in different screen sizes.

What it’s Not

Keep in mind that Screenfly does not emulate the behavior or capabilities of the device it’s trying to mimic. That means that if you are running Screenfly on Internet Explorer 6, you’re only going to see the web document as if it were requested from the selected device, running on Internet Explorer 6.

Also, it’s important to note that I make no attempt to maintain a comprehensive list of devices for testing. The list of devices is intended to be representational of the actual devices available on today’s device market. For instance, I made sure to include both Android and Apple tablets, as well as Android and Apple mobile devices. The list will continue to evolve as the device landscape changes (as it always does), and any suggestions or additions are welcome.

Try it Out

Without further adieu, try Screenfly for yourself by clicking on the following link. This is a “beta” version of the web app, so please let me know if you encounter any errors or issues while testing your own designs.

http://quirktools.com/screenfly/

Responsive Layouts Using CSS Media Queries

Kyle — Tue, 03 May 2011 02:23:03 +0000

The days of the desktop are numbered. In the past, designing a web interface involved targeting a screen resolution in the vicinity of 960 pixels wide. For many years, this worked, and it worked well, because 99% of online users could easily read and scroll at that resolution, regardless of the browser, operating system, or machine they were using. Times have changed.

The supreme rule of desktop design began to wane in the past couple of years. With the explosion of the mobile browser phenomenon (largely due to devices like the iPhone, Blackberry, and the Android operating system), online traffic began to show the first signs of diversification. With increasing numbers of users on these mobile devices, the distinction between mobile and desktop content was born. As you most likely have noticed, many online publishers have chosen to neatly dissect their content into two distinct applications that serve two distinct types of devices. You have “mobile” versions of many websites available today, which often offer similar or identical content to what can be found on the desktop version of that same website. Very simply, the web server detects the device that’s requesting the content, and serves up a different document (or redirects to a different location) depending on the device being used.

Today, this dichotomy between mobile and desktop content persists as the most popular strategy for serving up web content to a multitude of devices. The technical implementation of this strategy differs from site to site, but the end result is the same: a design and layout that targets a single device or resolution. This has been a great approach for many online publishers because it offers so much flexibility in the appearance of mobile content. By segregating a design into two entirely different implementations, the limits to what can be done on a mobile site are nearly limitless. As with every design, however, there are disadvantages to this approach that cannot be overlooked:

Increased effort – it is more difficult to create and maintain two separate design layouts simultaneously.
Publishing concerns – creating a division between mobile and desktop content begs the question: where does the content come from? Should all desktop content be available on the mobile site? Do you publish everything twice (once for desktop, once for mobile users), or do you dual-publish to both mediums simultaneously?
Planning for diversification – is “mobile vs. desktop” really good enough?

The last disadvantage listed here is perhaps the most important point to consider. Recent history has shown that targeting a single device (i.e. the desktop) did not withstand the test of time. Is the simple distinction between “mobile” and “desktop” content really good enough?

Mobile is important, but not end-all.

The truth of the matter is that mobile devices are taking off. According to Mary Meeker of Morgan Stanley, the sale of “smartphones” is expected to overtake PC sales (both desktops and notebooks) by next year. Browsing statistics are showing this trend as well. StatCounter shows that about 6.5% of all users in North America are browsing on mobile devices. You can count on about one in twenty users experiencing your online content on a three inch screen – how does your content stack up in this scenario? If you haven’t thought about it yet, it’s time to start.

The growth of the smartphone landscape and the diversification of browsing statistics are the driving factor behind the explosion of mobile-friendly site design. Today, this practice is entirely acceptable, but don’t count on anything in this industry to stick for more than a few years. Mobile devices aren’t the only new kids on the block.

Enter the tablet.

Tablet devices like the iPad and similar devices that utilize the Android operating system have been somewhat of a curveball in the industry of web design. They’re not quite mobile devices, and they’re not quite desktops, but rather somewhere in between. In the current design landscape, where everything has been neatly divided between mobile and desktop content, many designers are choosing to place tablets into the “mobile” category, serving up tablet content in like kind. This does not always go over well with tablet users, who justifiably feel that the tablet offers unique advantages of a desktop computer, namely a better browsing experience than what can be had on a smaller mobile device.

What, then, do we do with these users?

Responsive Web Design

The ongoing problem is that as designers, we’ve set our minds on this idea that a web interface is going to be displayed on a screen that is 1024 pixels wide (or larger). It’s a desktop mindset; anything smaller than 1024 is a “mobile” device and generally gets a pixel value of about 320 pixels. All devices that access our online content must adhere to one of these two layouts – there are two numbers, and nothing in between.

The trouble for web designers is that internet connectivity is rapidly spreading to a vast array of devices and products that people use every day. Someone might access your online portal from a desktop, phone, notebook, netbook, tablet, or even some consumer appliances. The Nintendo Wii, for instance, comes loaded with an Opera browser that’s quite good, and is hindered only by the fact that many televisions only have a resolution that is 480 to 720 pixels wide. At this resolution, many website layouts simply don’t provide an enjoyable user experience due to poor formatting and display on smaller screens. Furthermore, there is no end in sight. Expect this diversification of internet-ready devices to increase in the coming years, and plan to change the way you design and create layouts for the web.

The great thing is, whether you recognize it or not, this is actually a very good thing. Web layouts have been too rigid and design-centric for a long time now, and forcing designers to apply layouts to a multitude of devices will encourage them to create content that can be consumed in a variety of mediums. In the end, this translates into a better experience for the user, who doesn’t have to worry about what device they are on, what resolution they’ve chosen, or what issues they may encounter. Ethan Marcotte sums it up best in his article, “Responsive Web Design” from A List Apart:

Rather than tailoring disconnected designs to each of an ever-increasing number of web devices, we can treat them as facets of the same experience. We can design for an optimal viewing experience, but embed standards-based technologies into our designs to make them not only more flexible, but more adaptive to the media that renders them. In short, we need to practice responsive web design.

Responsive web design is creating web layouts that can adapt to a multitude of displays and devices. Using this technique, you can eliminate the need to create device-centric designs (like a “mobile” site), and allow your content to be displayed from a single source, on an unlimited number of mediums.

Techniques for Responsive Web Design

Responsive web design is not “one big thing.” It’s a collection of disciplines and techniques that you employ to ensure that your designs can appear fluidly on a multitude of display sizes. The fundamental change that you have to make to start creating responsive designs is to ask yourself with everything that you do: what happens with this content when the display shrinks? Plan for a multitude of resolutions from the very beginning. By mere acknowledgement and foresight, you’ll find that the challenge of creating a responsive layout is not so difficult to overcome.

1. Layout Width

The most important element of flexibility that must be employed in your responsive design is a fluid layout width. This is the condemning factor that breaks many designs when they are viewed on smaller display screens. Create wrapper, content, and column widths that can stretch display ideally in different resolutions. There is no “trick” to this technique, it’s merely a change in the way you create columns in your style sheets. Here’s an example:

#wrapper {
  width: 80%;
  margin: auto;
  max-width: 1200px;
}

This is a simple example of a fluid design width. Setting a max-width on your design is a good idea to salvage any formatting issues for users on very large resolution monitors.

2. Responsive Design and Column Widths

In most designs, you might be working with multiple column widths to display content in a number of different ways. In your style sheet, you could simply apply a percentage width to each column, but this technique is generally not ideal. In many cases, a sidebar column may include fixed-width elements like advertisements, menus, or text that does not necessarily adapt in any beneficial way as the width of your layout grows. Instead, you may choose to adapt only a single column as the layout width changes. This is a common layout structure that can easily be created within your existing style sheet. Consider the following example:

#wrapper {
  width: 80%;
  margin: auto;
  max-width: 1200px;
}
#column-main {
  margin-left: 200px;
}
#column-sidebar {
  width: 200px;
  float: left;
}

In this example, the “main” column will always fill the width of the layout area, and the sidebar column (in this example, on the left) will always remain exactly 200 pixels wide.

3. What about images?

A common concern when moving from a fixed-width to a fluid layout is HTML images (the element). An image file, for the most part, is a fixed-size file that does not scale as your design width decreases. This results in some rather unsavory presentation bugs, like large images being drawn beyond the edge of the browser window. The solution is a simple addition to your design’s style sheet:

img {
  max-width: 100%;
}

This simple addition causes any images in your design to display at full size by default. As the width of the design layout shrinks so that the image is too wide to display in the confines of it’s parent element, the image too, begins to shrink.

It’s worth noting that the image scaling ability of Internet Explorer is admittedly poor at best. Ethan Marcotte shares his very handy Fluid Images script to help alleviate your scalable image woes.

4. No More Zoom

Many mobile devices and tablets utilize a “zoom” feature to display content that is too large to fit on smaller display screens. This is an important utility for mobile and tablet users, but it creates a detrimental experience for users, as they have to constantly zoom in, pan, and zoom out in order to browse your web document’s content. You can disable this zooming behavior by way of a simple element in your design’s header.

This meta element is only interpreted by a number of browsing devices (namely smartphones and tablets). You should only disable the zoom feature if it enhances users’ ability to consume content on your site. If you’ve formatted your design layout so that users don’t need to pan or zoom, the zoom feature actually impairs the user from navigating your content (which only needs to scroll vertically). If you’ve incorrectly formatted your layout, however, disabling the zoom feature will only further infuriate your users, as you are removing a very important navigation capability of the browser.

5. CSS Media Queries

The final and most powerful technique that you can employ for responsive web design is a fairly new feature of CSS technology called the media query. Very simply, CSS media queries allow you to apply changes to your site’s design based on the viewing size and capability of the device on which your content is displayed. This is an extremely powerful tool for creating responsive designs, and it has garnered support across all major mobile browsers (including Safari, Chromium, Opera, and even the forthcoming Internet Explorer Mobile [Windows Phone 7]). Here’s a simple example of using a media query in your design’s style sheet:

#wrapper {
  width: 80%;
  margin: auto;
  max-width: 1200px;
  min-width: 800px;
}
@media screen and (max-width: 800px) {
  #wrapper {
    width: 90%;
    min-width: 0;
  }
}

In this example, we use the same fluid layout as before, but we’ve added a new minimum width (800 pixels) to the style sheet. If the width of the screen drops below 800 pixels, all of the styles defined in our media query will take effect, and the wrapper will be resized to 90% of the design width (with no minimum width).

The power of media queries becomes more apparent in a layout with columns. Consider the following example:

#wrapper {
  width: 80%;
  margin: auto;
  max-width: 1200px;
  min-width: 800px;
}
#column-main {
  margin-left: 200px;
}
#column-sidebar {
  width: 200px;
  float: left;
}
@media screen and (max-width: 800px) {
  #wrapper {
    width: 90%;
    min-width: 0;
  }
  #column-main {
    margin-left: 0;
  }
  #column-sidebar {
    width: auto;
    float: none;
  }
}

In this example, when the width of the device screen drops below 800 pixels, we completely reformat the appearance of the columns in our design. Rather than displaying a fixed-width sidebar column, at 800 pixels or less, this design switches to a stacked column layout (with the sidebar displaying on top or below the main column). This preserves space on smaller screens, and provides an easy way to display multiple columns on devices that aren’t suited for column-based layouts.

The great part about media queries is that you can define multiple queries in your style sheet. You can have a design layout for desktop machines, a new layout for tablets, and yet another new layout for smaller devices like mobile phones. The number of variations is limited only by what you can do within your style sheet. Furthermore, the latest versions of desktop browsers like Firefox, Safari, Chromium, and even Internet Explorer will recognize media queries as you resize the browser window, allowing you to test your variations on the fly. If you’re using said modern browser, simply resize this window to see how my design responds to new device sizes.

Looking Forward

Responsive web design is an important next step in presentation on the web. Expect the device landscape to broaden and diversify, and expect your job as a designer to increasingly become the curator of a flexible and fluid online experience that is more focused on content and less on pixels or devices. The idea of “mobile vs. desktop” is fairly new and very strong, but the mobile distinction will likely become an element of features and convenience, rather than an element of presentation, as it is so largely viewed today.

SharePoint 2010 Item Styles and DDWRT

Kyle — Tue, 12 Apr 2011 19:49:53 +0000

I’ve done some crazy things to make SharePoint work like I want it to. One of the things that I’ve done in the past is write some insanely complex XSLT functions to format dates in SharePoint 2007 item styles. SharePoint 2007 offered a very useful FormatDate feature of the DDWRT XSL library, but the formatting customization was limited to picking a prefab format, which didn’t always gel with what you or your client wanted to see. To get some custom date formats, I wrote crazy XSLT functions that literally had statements that checked a substring of the SharePoint date for every month of the year (seriously). Not the ideal solution, but it worked; sometimes, SharePoint gives you lemons and you have to make…well, you know.

2010, How Refreshing!

I didn’t realize it at first (mostly because Microsoft documentation on this stuff can be very hard to find), but SharePoint 2010 seems to support a new DDWRT function that I’ve found to be very useful. You can still use FormatDate, but you now have a new function called FormatDateTime at your designer’s disposal. Here’s how it works.

Open the file that contains all the item styles for your SharePoint 2010 site (/Style Library/XSL Style Sheets/ItemStyle.xsl).
Near the top of this file, you should see an element called . Add a new attribute to this element (if it’s not already there) like so:
```
xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime"
```
Now, in an item style, you can use the new function like so:

Simply substitute @Created for the date/time column of your choice. You can use a lot of different values for the date (in our example above, the date is output in MMMM d, yyyy format, which appears like April 12, 2011 within an item style. Refer to Microsoft’s MSDN article for a list of all the date variations that you can use – it’s highly flexible, and allows you to output things like 12-hour time formats or even time zone information (something that was lacking in the old FormatDate function).

More Item Style Resources

While we’re on the topic of SharePoint 2010 item styles, I’ve run into a few snags in this new product, and you might just benefit from my experience while you’re rolling your own custom item styles. Most importantly, you might notice that after creating a new custom item style and applying it to a page, it works splendidly until you open that page up and view it as an anonymous user. Everything is checked in, published, and soon you’ll be pulling your hair out trying to figure out why anonymous users are getting a mysterious error message on your fancy new item styles.

You can fix this strange anonymous-users-only error in one of two ways:

Some item styles start out with XSL variables that have names like SafeImageUrl or DisplayTitle. If you aren’t using these variables in your item style, simply delete these variables altogether! The presence of these variables can sometimes cause the anonymous error message to appear, and removing them is often all that is needed to resolve your issues.
Waldek Mastykarz found that adding DocumentIconImageUrl and OnClickForWebRendering to the CommonViewFields property of the web part also clears up any issues you might have with this error appearing for anonymous users. You can read Waldek’s post here for more information. Basically, you need to export the web part, open it up in a text editor, and find the line that says CommonViewFields, and change this line to what you see in Waldek’s post. Once that’s done, simply import the web part back into the page (delete the old one), and you should be all set.

As always, if you’re looking to get started creating item styles in SharePoint 2010, Heather Solomon’s custom item styles blog post is still relevant to everything you’ll need to do in SharePoint 2010.