Professional SharePoint 2007 Design (Wrox Professional Guides)

Sanford ffirs.tex V3 - 08/14/2008

Professional

Microsoft® SharePoint® 2007 Design Jacob Sanford Randy Drisgill David Drinkwine Coskun Cavusoglu

Wiley Publishing, Inc.

1:45pm

Page iii

Sanford ffirs.tex V3 - 08/14/2008

1:45pm

Professional Microsoft® SharePoint® 2007 Design Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii Chapter 1: Why Design? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Chapter 2: Web Design 101 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Chapter 3: General Concept Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Chapter 4: Communicating or Collaborating? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Chapter 5: Introduction to SharePoint Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Chapter 6: Themes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Chapter 7: Cascading Style Sheets with MOSS 2007 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Chapter 8: Master Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 Chapter 9: Page Layouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Chapter 10: Working with Out-of-the-Box Web Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 Chapter 11: Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 Chapter 12: Customizing Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 Chapter 13: Accessibility in SharePoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535 Chapter 14: Wrapping It All Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577 Appendix A: Introduction to Deploying SharePoint Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599

Page i

Sanford ffirs.tex

V3 - 08/14/2008

1:45pm

Page ii

Sanford ffirs.tex V3 - 08/14/2008

Professional

Microsoft® SharePoint® 2007 Design Jacob Sanford Randy Drisgill David Drinkwine Coskun Cavusoglu

Wiley Publishing, Inc.

1:45pm

Page iii

Sanford ffirs.tex

V3 - 08/14/2008

Professional Microsoft® SharePoint® 2007 Design Published by Wiley Publishing, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256

www.wiley.com Copyright © 2008 by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada ISBN: 978-0-470-28580-0 Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1 Library of Congress Cataloging-in-Publication Data is available from the publisher. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or online at http://www.wiley.com/go/permissions. Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Website is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Website may provide or recommendations it may make. Further, readers should be aware that Internet Websites listed in this work may have changed or disappeared between when this work was written and when it is read. For general information on our other products and services please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002. Trademarks: Wiley, the Wiley logo, Wrox, the Wrox logo, Wrox Programmer to Programmer, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. Microsoft and SharePoint are registered trademarks of Microsoft Corporation in the United States and/or other countries. All other trademarks are the property of their respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book. Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.

1:45pm

Page iv

Sanford ffirs.tex V3 - 08/14/2008

1:45pm

To my boys, Hayden and Matthew, who help turn a dingy ‘ol basement into the magical world of mantown. You guys are my inspiration and the reason behind everything. — Jacob J. Sanford Dedicated to waffles (thank you for being delicious) and to Jackie (the love of my life) for always being there to eat them with me. — Randy Drisgill I dedicate this book to Alexandra, Grace, and Charlotte, who never let me forget who I work for. — David Drinkwine I dedicate this book to my wonderful wife, Kader, and our daughter, Tuana. — Coskun Cavusoglu, MCTS

Page v

Sanford ffirs.tex

V3 - 08/14/2008

1:45pm

Page vi

Sanford fauth.tex V2 - 08/14/2008

1:46pm

About the Authors Jacob J. Sanford began his career in, of all things, accounting and auditing. He graduated from Florida State University in 1997 with BS degrees in Accounting and Finance, which made him eligible to sit for the CPA exam. Although he realized in college that his interests lie more in computers and technology, he decided he would give accounting a chance. It didn’t last. He had been dabbling in HTML and VBA when he took a job at a private software company and met co-author David Drinkwine, who introduced him to the wonders of classic ASP. From there, he began learning as much as he could about all kinds of Web application development. This took him down the paths of ColdFusion, PHP, PhotoShop, CSS, XML, and finally ASP.NET (starting with the 1.0 and 1.1 releases). He has been using ASP.NET (VB and C# — but mostly C#) for the last four or five years. He has worked at several State of Florida agencies and in that capacity found a fondness for pure CSS design and accessibility considerations. Most recently, he has started focusing on new technologies and tools such as Microsoft Silverlight and Visual Studio 2008. Jacob is currently a senior consultant with Captar´e Consulting, LLC, and is the founding leader of the Tallahassee SharePoint Experts Exchange for Developers (SPEED). He is also a regular presenter at regional .NET Code Camps and at local .NET User Group meetings and is the author of Professional ASP.NET 2.0 Design (Wrox, 2007). Jacob has received his Microsoft Certified Professional Developer (MCPD) certification as a Web Developer (Visual Studio 2005). He plans to upgrade his credentials to Visual Studio 2008 and the .NET 3.6 Framework as the certification exams become available. Jacob lives in Tallahassee, Florida with his beautiful wife, Shannan. He has two amazing sons, Matthew and Hayden, and an eternal puppy, Petey. Randy Drisgill is an Internet technologist, focused on emerging Web trends such as MOSS 2007 and rich Internet applications. Currently working as a consultant for SharePoint branding and customization, Randy has been helping businesses create innovative Web applications since the late ’90s. Previously, Randy co-owned a Web development consulting company, and before that, he worked for Lockheed Martin on several enterprise-level initiatives. Along with his current interests in Microsoft technologies, Randy’s involvement in both the ColdFusion and ActionScript communities has led to his co-authoring several related books and publications. Besides blogging about everything from Adobe to LoLCats at www.Drisgill.com, Randy also uses the pseudonym ‘‘The Mossman’’ to blog specifically about MOSS 2007 at theMossman.Blogspot.com. When not thinking about technology, Randy enjoys spending time with his beautiful wife, Jackie, and his dog, Frito. David Drinkwine is currently a Senior Solutions Architect for Captar´e Consulting, LLC, a Chicago-based consulting firm specializing in advanced SharePoint implementation and custom .NET application development. He has designed and implemented WSS and MOSS based applications for a variety of clients, including global product manufacturers, state agencies, and telecommunications firms. David has a decade and a half of software development experience and has been developing Internet-based solutions since the late ’90s. He has been highly focused on designing and implementing SharePoint solutions from the early days of SharePoint Team Services. He has experience in a wide variety of technologies, including MOSS, WSS, various incarnations of C and Visual Basic, MS Office programming and integration, and far more acronym-named technologies than can be good for any one person to know.

Page vii

Sanford fauth.tex V2 - 08/14/2008

About the Authors David frequently has spoken on design and the use of third-party tools with SharePoint at regional SharePoint user group meetings. He attended Florida State University, where he studied English and Philosophy. Coskun Cavusoglu is the Director of Consulting Services and the Chief Solution Architect of Captar´e Consulting, LLC. Coskun has been architecting and implementing technology solutions for more than 10 years in both large enterprise organizations and fast-growth midmarket firms. He has extensive experience designing, implementing and supporting Internet solutions using Microsoft technologies such as SharePoint, CRM, Project Server, Solomon, BizTalk Server, Windows Server, Active Directory, Exchange, IIS, and ASP .NET 2.0. Coskun consults on a variety of business process practices. He has a broad range of expertise in areas such as knowledge management, business process analysis, collaboration, project management, office productivity, and application programming. Coskun is a Microsoft Certified Technology Specialist for SharePoint Portal Server 2003 and Microsoft Office SharePoint Server 2007.

About the Technical Editors Doug Holland is a senior software engineer at Intel Corporation in Folsom, CA, and holds a masters degree in software engineering from Oxford University. He has been designing and building software solutions for over 14 years within areas as diverse as telecommunications, homeland security, and now graphics chipset performance modeling. Doug Holland has received the Microsoft Most Valuable Professional (MVP) award for Visual C# and enjoys speaking to user groups and blogging about the latest trends in the Microsoft .NET platform and software engineering. He also loves spending time with his wife and four children at their home just outside Sacramento, CA, and enjoys flying Cessnas over the California landscape. Andrew Connell is an independent consultant, developer, instructor, and Microsoft Most Valuable Professional (MVP) for Microsoft Office SharePoint Server (MOSS) focusing on Web Content Management (WCM). He’s authored numerous books and articles on the subjects of Microsoft Content Management Server and SharePoint Products and Technologies. With a passion for SharePoint development and content management sites, Andrew has spoken on the subject of MOSS 2007 development and WCM at various events and national conferences such as TechEd, SharePoint Connections, VSLive, Office Developer Conference, and the Microsoft SharePoint Conference. You can reach Andrew or subscribe to his blog at http://www.andrewconnell.com/blog.

viii

1:46pm

Page viii

Sanford fcre.tex

V2 - 08/14/2008

Credits Contributing Writer John Ross

Production Manager Tim Tate

Acquisitions Editor Katie Mohr

Vice President and Executive Group Publisher Richard Swadley

Development Editor Kelly Talbot Technical Editors Doug Holland, Andrew Connell Production Editor William A. Barton Daniel Scribner

Vice President and Executive Publisher Joseph B. Wikert Project Coordinator, Cover Lynsey Stafford

Copy Editor C.M. Jones

Proofreaders Corina Copp David Fine Scott Klemp

Editorial Manager Mary Beth Wakefield

Indexer Robert Swanson

1:47pm

Page ix

Sanford fcre.tex V2 - 08/14/2008

1:47pm

Page x

Sanford fack.tex

V1 - 08/13/2008

8:41pm

Acknowledgments As a team, we would like to thank all of the people at Wrox for making this book a possibility. First, to Jim Minatel, our first contact into Wrox and for hearing our idea and putting us in contact with the right people. To Katie Mohr for being the right people. Besides signing off on the idea and walking it through the official approval process, she provided a wealth of understanding and guidance when we needed it. To Kelly Talbot, our development editor, for first and foremost making sure what we say makes sense (and is, in fact, what we meant to say). He also was there with us through the whole process and gave invaluable advice and was forgiving when we missed deadlines (more often than we should admit). He never gave up on us and kept us motivated (and provided the occasional shove when we needed that, too). To John Ross for stepping in at the last minute to write Appendix A for us, which really helps make this manuscript a complete work. To our technical editors, Doug Holland and Andrew Connell, for making sure what we say is factually sound and technologically correct. Without all of you guys, this book would not have happened, and we sincerely appreciate every one of your contributions. I want to start off by thanking the writing team for their dedication and hard work at getting this book finished. There were many nights I was up writing at 2 and 3 a.m. (or even 4 and 5 a.m.) and could look in my IM client and see them up doing the same. And, in that same regard, I want to personally thank their families for letting them do what it took to get through it. I know how understanding my wife was and I know you guys couldn’t have done it without the understanding and support of your families. So they deserve as much credit as anyone on this team. I also need to thank all of the employers that have let me learn as much as I could when I was with them. Most recently, Malcolm Eaton and Jamie Story of Captar´e, for throwing me into the SharePoint fire and letting me try to cook up something amazing. I have learned so much under you guys, and you will never know how much I appreciate it. Finally, to my family for being there when I needed you and leaving me alone when I needed to write. I know you went through this just as much as I did and you don’t even get your picture on the cover. I could never do the things I do in life without your support. Oh, and to all of my friends and the GSS, let’s try to eat some of the cake this time before we destroy it, okay? — Jacob J. Sanford There are so many people that I need to thank for helping me along my journey, not only through life but also along my most recent journey to the land of MOSS. The following is a list of a few people who come to mind, in no particular order: My parents (Pat and Tom Drisgill) for buying me a Commodore 64 and for encouraging me to reach for my goals. My in-laws, the Auerbachs, for helping me when I really needed it. My wife Jackie, for putting up with my Internet addiction and my new Macbook Pro. The entire team at CIBER Orlando ‘‘The Ocho,’’ in all of its iterations, for being there throughout this whole process even when I came in to work bleary eyed from writing. My co-authoring cohorts from Captar´e for helping me sound semi-intelligent. A special thanks to both Andrew Connell and Heather Solomon for everything they do for the MOSS community, for being my mentors over the past year, for patiently

Page xi

Sanford fack.tex

V1 - 08/13/2008

Acknowledgments answering my questions at all hours of the night, for all of their help on this book, and ultimately for being good friends despite hardly knowing me in person. Lastly, thanks to The Mossman for being the Incredible Hulk to my Bruce Banner. Oh, and a shout out and hearty thank you to John Ross for picking up the pieces of my shattered mind when MOSS was completely killing me; I can think of no better person to learn MOSS with. Keep on moving those chains! — Randy Drisgill I’d like to thank Jacob for getting me involved in this project; Randy and Coskun for bailing me out time and time again; Jamie, Malcolm, and everyone at Captar´e for their support; Bob Maybin from dragging me into this racket in the first place; And, last but not least, my wife, who has given me time, patience, and, at times, properly placed kicks in the pants. — David Drinkwine Nothing I have written would exist without the support of the many clients who gave me the opportunity to develop and revise SharePoint techniques and practices. My associates at Captar´e, you have allowed me to practice the ideas I have believed for so long. Jamie Story and Malcolm Eaton, in particular, have provided me with guidance and flexibility while fueling my passion for technology, clients and business. Jacob, you have not only helped make this book a reality but you have taught me wonderful lessons in the process. I’m extremely grateful to my co-authors for making this an experience that will serve me well for the rest of my life. There remains one last group of people to acknowledge, and they stand at the center of almost anything I undertake: my parents, Nezahat and Nejat, who have given me what they could and sacrificed in the process; my daughter, Tuana, who has filled the missing piece in my life with more joy than she will ever know; and my wife, Kader, who I am eternally grateful for making the countless sacrifices and providing the day-to-day support that makes writing a book possible. — Coskun Cavusoglu

xii

8:41pm

Page xii

Sanford ftoc.tex V2 - 08/14/2008

1:48pm

Contents Foreword Introduction

Chapter 1: Why Design?

xxi xxiii

1

The Million-Dollar Question: What Makes Good Design? Why Should Designers Care? Why Should Managers Care? Why Should Clients Care? So Why Use SharePoint for Design? Summary

2 7 8 9 10 11

Chapter 2: Web Design 101

13

Goal-Oriented Design Driving Adoption Storyboarding Portal Design

14 15 16 17

Things to Consider Portal Topologies

18 19

Web Page Design Planning for Change Summary

26 35 36

Chapter 3: General Concept Design

37

Getting Inspired Creating the Design

37 41

An Overview of Photoshop CS3 A Few Graphic Concepts Creating the Design from Scratch

42 54 72

The Intranet Counterpart Continuing Education Summary

128 128 129

Chapter 4: Communicating or Collaborating?

131

What Is a Communication/Publishing Site?

131

Information Flow in Communication/Publishing Sites

132

Page xiii

Sanford ftoc.tex V2 - 08/14/2008

Contents When to Use a Communication Site Using a Communication Site for Intranets Using a Communication Site for Public Web Sites

133 133 135

Effectively Using a Communication/Publishing Site

136

Keeping the Look and Feel Consistent Enforcing Corporate Identity Guidelines Enforcing Corporate Policy Managing the Publishing Process with Publishing Pages Managing Security with Publishing Pages Managing Site Hierarchy Managing Site Variations

137 138 140 142 145 146 148

Publishing Site Templates The Top-Level Publishing Site Templates The Publishing Sub-Site Templates

Communication/Publishing Site Best Practices What Is a Collaboration/Team Site? Information Flow in Collaboration/Team Sites

When to Use a Collaboration Site Using a Collaboration Site to Manage Projects

Effectively Using a Collaboration Site? Collaboration Site Templates Team/Blank Site Template Document Workspace Template Wiki Site Template Blog Site Template Site Templates with WSS 3.0

153 153 157

160 161 162

162 162

163 164 164 165 166 167 167

Collaboration/Team Site Best Practices Summary

167 168

Chapter 5: Introduction to SharePoint Designer

169

Why Use SharePoint Designer?

169

Overview of Functionality Not Using SharePoint Designer

Customizing MOSS Sites Opening a MOSS Site in SharePoint Designer The Folder List Pane File Check-In/Check-Out Adding Content to a MOSS Site Adding Other Types of Content Approval Workflow Customized Vs. Un-customized

xiv

170 170

170 171 172 173 174 178 178 179

1:48pm

Page xiv

Sanford ftoc.tex V2 - 08/14/2008

1:48pm Page xv

Contents The Design View Working with Master Pages

180 182

Working with Page Layouts Creating a Content Page Editing Pages

185 185 185

Working with CSS The Manage Styles Pane The Apply Styles Pane The CSS Properties Pane

186 187 188 188

Working with Web Parts and Web Part Zones Working with XSL Using SharePoint Designer Reports Summary

190 195 198 199

Chapter 6: Themes

201

SharePoint Themes

201

Applying a Theme to a SharePoint Site Using SharePoint Themes to Brand

How SharePoint Themes Work The Themes Folder Contents of a Themes Folder Contents of a SharePoint Site when a Theme is Applied

How to Create a Theme How to Design a Theme

203 205

208 208 208 212

214 218

Setting Up Design Environment Starting the Theme Design Finalizing the Customizations Moving the Theme to the Server

219 223 241 242

Workarounds for Theme Caveats

242

Reapplying Themes Making Your Custom Theme the Default Theme

242 242

Tools for Creating Themes Summary

243 244

Chapter 7: Cascading Style Sheets with MOSS 2007

245

Introduction to Cascading Style Sheets

245

Browsers and Support DOCTYPEs Tables vs. Pure CSS

246 246 248

xv

Sanford ftoc.tex V2 - 08/14/2008

Contents Working with CSS Ways to Apply CSS to HTML CSS Rules Types of Selectors CSS Property Values Coding CSS with Reuse in Mind How Important Is ‘‘!important’’? Inheritance Understanding the Cascade Tools for Working with CSS

249 249 250 250 254 268 269 269 270 271

How to Include CSS in Your MOSS Site

275

Setting an Alternate CSS Adding CSS to Your Own Master Pages Adding Internal Style to MOSS Pages

275 276 280

Converting Your Design to HTML and CSS Creating Sliced Background and Regular Images Creating the HTML and CSS Intranet HTML Design Differences

282 282 285 307

Summary

309

Chapter 8: Master Pages

311

What Is a Master Page?

312

Content Pages Page Layouts Master Pages in MOSS

The Master Page Structure Content Placeholders Content Page Structure ASP.NET Controls A Sample Master Page

Using Master Pages with MOSS

312 312 313

313 314 314 315 316

318

Functional Areas of a Master Page Deciding Where the Master Page Ends Required Content Placeholders Where Master Pages Live in MOSS Out-of-the-Box Master Pages Minimal Master Pages

319 320 324 325 326 327

Challenges with Master Pages in MOSS

329

The Importance of CSS System Pages

xvi

329 329

1:48pm

Page xvi

Sanford ftoc.tex V2 - 08/14/2008

1:48pm

Contents Safe Mode Web Part Zones Nesting Master Pages and MOSS Turning on Robust Errors

The Great Customization Debate Implementing a Minimal Master Page Adding Your Own HTML Double Checking Your Master Page

Converting HTML Design to Master Pages A Word about the Name ActiveX Control Message in Internet Explorer Intranet Master Page Design Differences

330 330 330 331

333 333 335 338

341 365 366

Summary

367

Chapter 9: Page Layouts

369

What Is a Page Layout?

369

Relationship to Master Pages Content Types Page Layout Structure Types of Content in Page Layouts Where Do Page Layouts Live in MOSS The Out-of-the-box Page Layouts

370 371 373 375 376 377

Implementing Your Own Page Layouts

379

The Great Customization Debate Creating a Content Type Creating Site Columns Creating a Page Layout Adding Field Controls to a Page Layout Adding Web Parts to a Page Layout Publishing a Page Layout Create Publishing Pages from a Page Layout Improving a Page Layout with HTML

379 379 380 383 384 386 388 389 390

Internet Site Welcome Page Layout Example

394

Creating the Page Layout Adding the HTML Design Adding Field Controls Adding Web Part Zones Adding Page Layout Specific CSS Switching the Welcome Page Layout Adding Content to the Welcome Page

Summary

395 395 397 397 399 399 399

402

xvii

Page xvii

Sanford ftoc.tex V2 - 08/14/2008

Contents Chapter 10: Working with Out-of-the-Box Web Parts

403

Using the Content Query Web Part

404

Real World Scenario: Adding a ‘‘Latest News’’ CQWP to an Internet Site

The Data View Web Part Adding a Data View Web Part to a SharePoint Page Selecting a Data Source for the Data View Web Part Inserting the Data Source Control to the Data View Web Part Customizing the Look and Feel of the Data View Web Part

The Content Editor Web Part The Page Viewer Web Part The XML Web Part An Example of the XML Web Part A More Dynamic XML Web Part Example

The Image Web Part An Example of the Image Web Part The Image Web Part–Connected

404

421 421 422 424 426

433 438 441 441 445

447 447 450

Summary

452

Chapter 11: Navigation

455

Determining Whether Your Site Is WSS 3.0 or MOSS 2007 WSS 3.0 Navigation

455 456

Using the Top Link Bar Quick Launch Tree View Menu Showing Only Sites on the Tree View Menu

MOSS 2007 Navigation Maintaining MOSS 2007 Navigation MOSS 2007 Navigation Customizations Creating a Two-Level Horizontal Menu Enabling MOSS 2007 Navigation for WSS 3.0 Sites

457 473 481 482

483 484 489 492 494

Summary

495

Chapter 12: Customizing Search

497

Accuracy vs. Relevancy Making Better Information

498 499

Metadata Content Types

xviii

499 500

1:48pm

Page xviii

Sanford ftoc.tex V2 - 08/14/2008

1:48pm

Contents How Search Indexing Works

501

Adding Managed Properties Content Sources Setting Gatherer Rules Crawl Settings Creating Scopes Making Scopes Available

502 504 506 508 508 510

Designing Search Interfaces

511

Using Search Web Parts The Search Core Results Web Part The Content Query Web Part, Revisited Content Query Parts vs. Fixed Keyword Core Search Results The Search Center

Hacking Search Results Search Ranking Factors Key Words and Best Bets Authoritative Pages and Demoted Sites

512 520 528 529 529

530 530 531 533

Summary

534

Chapter 13: Accessibility in SharePoint

535

Accessibility Today

535

Guidelines for Accessibility

537

Accessibility in SharePoint

538

The Checklist in the Real World

546

Customizing SharePoint for Accessibility

548

The CSS Friendly Control Adapters The Accessibility Kit for SharePoint (AKS)

548 573

Tools and Validators Summary

574 574

Chapter 14: Wrapping It All Up

577

Checkpoint 1: Basic Web Design Checkpoint 2: Accessibility Checkpoint 3: The Design Checkpoint 4: Creating the Mockup Checkpoint 5: Creating the Master Page Checkpoint 6: Using a Theme

578 579 581 582 583 584

xix

Page xix

Sanford ftoc.tex V2 - 08/14/2008

Contents Checkpoint 7: Considering Page Layouts Checkpoint 8: Intuitive Navigation Checkpoint 9: Content Considerations Checkpoint 10: Checks and Validation Summary

584 585 585 586 587

Appendix A: Introduction to Deploying SharePoint Designs

589

Customized and Uncustomized Files

589

Uncustomized Files Customized Files

Key Considerations Creating Uncustomized Files with Features and Solutions The Designer’s Role in Solutions and Features The Downside to Solutions and Features

Deployment Scenarios Small Farm and Single Server Installations Medium Farms and Multi- Level Server Environments Large Farms

590 590

591 592 595 595

596 596 596 597

Summary

597

Index

599

xx

1:48pm

Page xx

Sanford ffore.tex V3 - 08/14/2008

1:49pm

Foreword The number one question I hear from people getting involved with SharePoint is ‘‘Can I change how SharePoint looks?’’ The answer is yes! You can certainly alter the default user interface for any SharePoint product and technology. The logical next question then is ‘‘How?’’ Out-of-the-box, SharePoint provides some very limited and basic ways to alter the site interface. Most companies and site installations, however, need to go to the next level and really customize several elements of the user interface. Sites need to express ideas and emotions and quickly deliver content to their target audience. Corporate identities, complementary colors, and relevant images need to be used. Pages need to be structured, and content needs to be dynamic, eye-catching, and effective. All of these elements are necessary to create usable and functional Internet and intranet sites. This is where SharePoint Designer comes in. This product allows you to design for SharePoint. It has a direct connection to your SharePoint site and allows you to interact with your site and see results immediately. With SharePoint Designer, you can create and alter the user interface for SharePoint. Some of the buzzwords you hear most often around SharePoint branding are master pages, page layouts, and features. This book explores these items and how you can effectively use them in your site. Beyond the buzz, there are many other ways you can change the interface for SharePoint and affect both site design (logo, header, navigation, footer, and so on) and content design (text, content, data, roll up views, and so on). While themes and Web parts have been around a lot longer and do not seem as glamorous, they are both highly useful and effective for branding SharePoint. This book serves as a definitive guide and a single source for the information and expertise you need in order to make the SharePoint site your own. SharePoint Designer can help make your sites both beautiful and functional, and this book shows you how. Jacob, David, Coskun, and Randy walk you through the steps involved and help you learn the skills to change the interface successfully. They have all worked on SharePoint implementations and they understand the challenges and pain points that come with this task. This book is a must-have for designers and will bridge the gap between what you know and what you need to know to brand SharePoint successfully! Heather Solomon Owner and President, Solomon Creative, Inc. Director of Creative Services, SharePoint Experts, Inc. Senior Trainer, SharePoint Branding Bootcamp

Page xxi

Sanford ffore.tex V3 - 08/14/2008

1:49pm

Page xxii

Sanford flast.tex V3 - 08/14/2008

1:43pm

Introduction The idea of Web portals is nothing new. In fact, SharePoint is not even a totally new idea, with SharePoint Portal Server (and Windows SharePoint Services version 2) being first introduced in 2003 (or even SharePoint Team Services first released in 2001). But with the introduction of Microsoft Offices SharePoint Server 2007 (MOSS) and Windows SharePoint Services version 3 (WSS), Web portal development took a huge leap forward. Many new technologies were introduced, and since they were built on the .NET 2.0 Framework, MOSS and WSS were able to capitalize on many of the new and cool features that made that framework release so amazing. But if you look at any bookstore or online book retailer for books on SharePoint, there is a woeful lack of releases that deal specifically with design. Sure, there are several books out on MOSS and WSS, but mostly they focus on the nuts and bolts of making SharePoint work. There might be a chapter here and there that deals with things that are important to the design of your SharePoint portal, but the chapter is included in a larger scope that, frankly, doesn’t overly concern itself with the way your SharePoint site looks. The consequence to this unfortunate gap in available manuscripts is that many SharePoint sites out there look pretty much the same as any other SharePoint site. In fact, it’s not uncommon for anyone familiar with SharePoint to be able to look at a site built on SharePoint technologies and be able to immediately determine that is the case. It’s unfortunate that such a powerful set of tools often comes wrapped in such a vanilla package. This book is unique in the fact that it puts the design of a SharePoint site as its primary scope. Sure, some of the technologies covered are also covered in other books. However, this should not be seen as overlap because, in the confines of this book, the design is the point, not necessarily the technology behind it. Also, since this book is focused towards design, universal concepts such as accessibility, CSS, and even outside applications such as Photoshop are discussed as they relate to SharePoint. While not specifically a designer’s cookbook for SharePoint, this book does try to bring the most relevant topics regarding the design perspective of a SharePoint site to those developers interested in making their sites stand out. If you want to learn how SharePoint works and how to use its administrative features to make your site powerful, there are plenty of books (many from Wrox) available to help you with that. However, if your focus is making your SharePoint sites look unique, we hope that this book will help you with that endeavor.

Who This Book Is For This book is for the SharePoint professional or enthusiast who has an interest in making their sites look as powerful as they are under the hood. Some of the concepts in the book will probably come easier to you if you are already familiar with SharePoint. However, an effort was made to at least provide enough detail so that the novice can understand and have enough information to get up to speed. Even so, if you are a complete novice to SharePoint, it might be a good idea to first read up a little bit on SharePoint so

Page xxiii

Sanford flast.tex

V3 - 08/14/2008

Introduction that you have at least a beginner’s level of understanding on how SharePoint works and at least a cursory overview of its features. This book also goes over some of the .NET 2.0 Framework features that can help designers in their effort to design their SharePoint pages. Again, while being an expert C# programmer is not required, a basic exposure to the .NET 2.0 Framework features will probably help you get through some of the chapters. For example, there are topics on master pages, themes, and control adapters that would be familiar to most .NET 2.0 (or above) programmers. The focus of these chapters is to show how to integrate these concepts within the confines of a SharePoint installation. This means that going into these topics completely unaware of the 2.0 counterparts might make it more difficult to understand the concepts in these chapters. As with the SharePoint concepts, an effort was made to provide enough detail so that even the complete novice can understand what is going on. But, again, knowing the 2.0 Framework can certainly be of benefit in these chapters.

What This Book Covers This book covers the major design instruments one would need in creating the aesthetic appearance of a SharePoint site, using Microsoft Office SharePoint Server 2007 or Windows SharePoint Services version 3. The concepts presented are unique to this version because they rely on an underlying framework that was not available in previous versions of the software. Additionally, this book gets into design tools not specifically targeted to SharePoint developers. For example, Chapter 3 is solely dedicated to creating the design for your site using Photoshop CS3. Many of the concepts of this chapter would certainly be easily ported to earlier versions of Photoshop, and probably even other graphic editor programs. But nobody would argue that Photoshop, in any version, was a SharePoint tool. However, when you’re talking about the Web, and specifically Web design, Photoshop is almost always relevant. Finally, concepts on standards and guidelines are included, as they should be part of the planning for any Web site, not just SharePoint. This includes the latest versions of Web accessibility and cascading style sheet rules and definitions. While some of the rules, such as the Web Content Accessibility Guidelines, are currently under revision and will probably be updated in the future, the most current accepted versions were used for this book.

How This Book Is Structured This book is structured in what might be considered the logical approach to planning the design of your SharePoint site. In the beginning, theories on Web design and concepts are discussed in a general manner. Next, the design is architected in Photoshop CS3. The next chapters then break that design into its HTML equivalents and create the CSS and master page files used to brand the overall site. In this stage, there is also a discussion about creating page layouts and themes to further carry out your design to the controls used by your site. Finally, as the book begins to wind down, more focus is placed on the actual content that will likely make up your sites, such as search, navigation, and Web parts, and how to style them to meet the design specifications you have created in the earlier chapters. As a look back, a summarized checklist of design considerations will be provided in the final chapter to give a broad overview of the concepts provided in the book and how they should go into the planning of your next site.

xxiv

1:43pm

Page xxiv

Sanford flast.tex

V3 - 08/14/2008

1:43pm

Introduction

What You Need to Use This Book The main criterion you need to be successful using this book is the desire to design SharePoint sites that look like anything but out-of-the-box SharePoint sites. As mentioned earlier, a basic understanding of the .NET 2.0 Framework and of SharePoint concepts will be helpful as well, although not critical. As far as tools go, this book uses Photoshop CS3 and Microsoft Office SharePoint Designer 2007 as its primary development tools. Photoshop is not necessary, as any graphics editing program will likely do the job. And, honestly, most of the concepts presented in the chapters dealing with Photoshop can be fairly easily ported to any other graphics program. However, SharePoint Designer is probably a must-have, as it is the only easy way to directly interact with the virtual CSS, master page, and ASPX files that are a part of your SharePoint site. Since they are not physical files but merely files created on the fly from data in XML and database records, modifying them provides a fairly unique obstacle. SharePoint Designer is engineered to modify these files for you and, as such, it would be too much of a hardship to try to get around this requirement. To get the most out of this book, you really need SharePoint Designer. Other than that, you shouldn’t need much else. Throughout the chapters you will find references to other tools that might help you do the job, many of them free. But those are all optional. This book was not created to be a shopping list of expensive tools you need to make your sites awesome. Instead, it was aimed at making your sites awesome using tools you probably already have or can get easily. And if you work in SharePoint, you should already have SharePoint Designer. And if you don’t have and can’t afford Photoshop, there are some free alternatives available. The point is the design and the underlying concepts. And the biggest tools necessary are your brain and your vision.

Conventions To help you get the most from the text and keep track of what’s happening, we’ve used a number of conventions throughout the book. Boxes like this one hold important, not-to-be forgotten information that is directly relevant to the surrounding text. Notes, tips, hints, tricks, and asides to the current discussion are offset and placed in italics like this. As for styles in the text: ❑

We highlight new terms and important words when we introduce them.

❑

We show keyboard strokes like this: Ctrl+A.

❑

We show file names, URLs, and code within the text like so: persistence.properties.

❑

We present code in two different ways:

We use a monofont type with no highlighting for code examples. We use gray highlighting to emphasize code that’s particularly important in the present context.

xxv

Page xxv

Sanford flast.tex

V3 - 08/14/2008

Introduction

Source Code As you work through the examples in this book, you may choose either to type all the code manually or to use the source code files that accompany the book. All of the source code used in this book is available for download at http://www.wrox.com. Once at the site, simply locate the book’s title (either by using the search box or by using one of the title lists) and click the Download Code link on the book’s detail page to obtain all the source code for the book. Because many books have similar titles, you may find it easiest to search by ISBN; this book’s ISBN is 978-0-470-28580-0. Once you download the code, just decompress it with your favorite compression tool. Alternately, you can go to the main Wrox code download page at http://www.wrox.com/dynamic/books/download.aspx to see the code available for this book and all other Wrox books.

Errata We make every effort to ensure that there are no errors in the text or in the code. However, no one is perfect, and mistakes do occur. If you find an error in one of our books, like a spelling mistake or faulty piece of code, we would be very grateful for your feedback. By sending in errata, you may save another reader hours of frustration. At the same time, you will be helping us provide even higher-quality information. To find the errata page for this book, go to http://www.wrox.com and locate the title using the search box or one of the title lists. Then, on the book details page, click the Book Errata link. On this page you can view all errata that has been submitted for this book and posted by Wrox editors. A complete book list including links to each book’s errata is also available at www.wrox.com/misc-pages/booklist.shtml. If you don’t spot ‘‘your’’ error on the Book Errata page, go to www.wrox.com/contact/ techsupport.shtml and complete the form there to send us the error you have found. We’ll check the information and, if appropriate, post a message to the book’s errata page and fix the problem in subsequent editions of the book.

p2p.wrox.com For author and peer discussion, join the P2P forums at p2p.wrox.com. The forums are a Web-based system for you to post messages relating to Wrox books and related technologies and interact with other readers and technology users. The forums offer a subscription feature to e-mail you topics of interest of your choosing when new posts are made to the forums. Wrox authors, editors, other industry experts, and your fellow readers are present on these forums. At http://p2p.wrox.com you will find a number of different forums that will help you not only as you read this book but also as you develop your own applications. To join the forums, just follow these steps:

1. 2. xxvi

Go to p2p.wrox.com and click the Register link. Read the terms of use and click Agree.

1:43pm Page xxvi

Sanford flast.tex V3 - 08/14/2008

1:43pm

Introduction 3. 4.

Complete the required information to join as well as any optional information you wish to provide and click Submit. You will receive an e-mail with information describing how to verify your account and complete the joining process.

You can read messages in the forums without joining P2P but in order to post your own messages, you must join. Once you join, you can post new messages and respond to messages other users post. You can read messages at any time on the Web. If you would like to have new messages from a particular forum e-mailed to you, click the Subscribe to this Forum icon by the forum name in the forum listing. For more information about how to use the Wrox P2P, be sure to read the P2P FAQs for answers to questions about how the forum software works as well as many common questions specific to P2P and Wrox books. To read the FAQs, click the FAQ link on any P2P page.

xxvii

Page xxvii

Sanford flast.tex

V3 - 08/14/2008

1:43pm Page xxviii

Sanford c01.tex

V3 - 08/13/2008

Why Design? When people attempt to take up Microsoft Office SharePoint 2007 (MOSS 2007) as a profession, or even as a hobby, they immediately begin by trying to understand how to make the portal work. This is probably an obvious path; to make SharePoint work, you have to, well, make it work. Beginners toil with custom lists, site administration, and out-of-the-box Web parts. They may start getting into security and document libraries and slightly more advanced topics. Some more advanced (or brave) users may even get into custom development and modification in SharePoint and its integration with other technologies. But when is it time to learn about design and branding when it comes to the SharePoint portals these people are designing? Should they learn it in the beginning? Or perhaps wait until they have a solid understanding of all other principles related to MOSS 2007? And, once they learn good design concepts, when is it time to worry about the site’s look and feel? Is there a good time? If so, should it come at the beginning of the planning process? At the end? Unfortunately, too often MOSS 2007 developers put little to no emphasis on the actual look and feel of the sites they are designing. There could be any number of reasons that this happens. Maybe it’s because, from a business sense, it’s hard to quantify good design. Sure, any analyst can show that with the addition of this new feature of the Web site subscription revenue went up by x number of dollars. It’s harder to evaluate, though, if a site becomes more or less popular because of the way it looks and feels. This is especially true for a completely new site because there are no historical numbers to use to determine how much difference the site’s aesthetics make. Conversely, if a site has been online for three years and one day a total redesign is introduced and within three months sales double, it might be easier to give the credit to the design (although it might be just as easy not to). And what of the sites that generate no real revenue? Perhaps new and/or repeat visits would be able to quantify good design, but even this would be hard to measure. So maybe this is part of the reason.

2:49pm

Page 1

Sanford c01.tex

V3 - 08/13/2008

Chapter 1: Why Design? Or maybe the problem is with the mindset of the developers making the MOSS 2007 sites. Maybe they don’t have the training and exposure to make the sites visually impressive. Or maybe there is general apathy about design. Perhaps they just care a lot more about functionality than design. After all, most clients sign off on projects based on what they do, not how they look. Or maybe it’s just that these developers don’t feel they have the time to make the design look distinct, and besides, there are plenty of out-of-the-box solutions that would work just fine. Slap on the client’s logo and be done with design. This book will attempt to put new emphasis on design. Specifically, this chapter will try to point out the ‘‘why’’ of good design. Why does it matter? Why should developers care? Why should managers care? And why should clients care? The rest of the book will be more aimed at the ‘‘how’’ of good design: How to create a new design. How to create master pages and CSS files to support your new design. How to incorporate themes. How to make more accessible designs. How to make MOSS 2007 work for the design you create. With that, it’s time to get started.

The Million-Dollar Question: What Makes Good Design? This is a tough question to field. If you ask 100 different Web designers today what is critical for good design, you will not see the same answers brought up by all of them. There will be a lot of recurring themes, but varying weight or importance will be given to each one (if mentioned at all). However, even with that being true, there are definitely some things that any designer should give thought to when coming up with a design:

2

❑

Usability This should probably be at the top of every designer’s list. If the site is amazing looking and could have easily come right out of a top New York designer’s art portfolio, that is cool. But if a user has no idea they have to press the broken toothpick depicted in the bottom corner of the collage to get to the Contact Us area of the Web site, designers have missed the point. More important, if that site is commercial, the owners may miss a sale (or a lot of sales). Usability has to be taken into consideration when planning the design of a site. This will include navigation, spatial layout, information provided, and general user experience (for example, if the user is presented with a shocking strobe-light effect when they visit the site, they may never come back). A Web site is built for its user base and failing to cater to the people that use the site can have tragic consequences for the longevity of the site.

❑

Aesthetics Thought should be given to the colors that will be used, how they play into the general scheme of the site and its principles, and how they will shape the experience of the user. This is different from usability in that usability means that the site visitor can use the site effectively, whereas aesthetics is a question of how much the user enjoys the feeling of the site. To extend the preceding example, if the users are easily able to find the ‘‘Contact Us’’ button because it is logically placed and easily identified, they might just use it to tell you that they hate your site if the colors, images, and font choices are giving them headaches. (Of course,

2:49pm

Page 2

Sanford c01.tex

V3 - 08/13/2008

2:49pm

Chapter 1: Why Design? more likely you will simply lose them as future visitors and never have a clue how much your organization is suffering from these aesthetic choices.) While not as important as usability, aesthetics should never be undervalued. ❑

Accessibility This is one of those terms that people have trouble defining. Some people might refer to it as 508 design (after Section 508 of the Disabilities Act). Some might associate it with text readers and other tools to assist the visually impaired. But that isn’t really what accessibility means (although this is certainly part of it). Accessibility means, in its simplest form, making sites that everyone gets equal value from. This takes a lot of different forms. Take, for example, a site that broadcasts its daily specials using Flash software. A text reader will read the rendered code of a Web site to the user accessing the site. When it gets to the site’s daily advertised specials in Flash, the reader will likely announce something like ‘‘embedded object found’’ and then move on (if they acknowledge it at all). So these patrons will have no idea that ear muffs are buy-one-get-one-free today and may decide to brave the frozen tundra without them. And you just lost a sale. In a similar situation, imagine an e-training site that offers online training on various business topics. But what if those classes were all done in streaming media where some narrator or even instructor is recorded going over subjects like sexual harassment or civil rights issues. How effective would that be to a person who cannot hear? If there is no consideration for such people (and there are plenty of them), the site will suffer for it. These ideas should be fundamental to any designer in today’s Internet. Before you dismiss vision- and hearing-based accessibility issues, consider this: According to the U.S. Bureau of the Census statistics for 1999, there are more than 1.5 million visually impaired computer users. Also, according to a 2005 report by Ross E. Mitchell in the Journal of Deaf Studies and Deaf Education from Oxford University, nearly 10 million people in the U.S. are hard of hearing and nearly 1 million are functionally deaf. And those numbers only reflect potential U.S. visitors to your site; they don’t account for all of the other visitors from Canada, Britain, Germany, and the rest of the world.

❑

Branding This can mean different things to different people, especially on the Web. Many corporations today have specific branding requirements. This often means that Web media can only use a designated logo at specific dimensions and must be separated from all other elements by a specific number of pixels. It could mean that the entire color scheme is mandated by the branding requirements of the company or public entity. It could even mean font sizes and colors. When getting into site design, it is imperative that designers understand the branding requirements of the people paying you to make the design and then adhere to them.

With MOSS 2007 (and portals in general), there is at least one other consideration: Don’t look like every other instance of this portal. If visitors come to your site and think, ‘‘I’ve seen this look somewhere before — make that lots of places before,’’ that is not a good thing. Unfortunately, many user groups fall into this exact trap. If you go to one user group site, it will often look like every other user group site, with the exception of the content, colors, and logo. They all take the same portal and just choose one of the out-of-the-box templates and slap their logo at the top and call it a day. Here is an interesting case study: Look at Figures 1-1 and 1-2.

3

Page 3

Sanford c01.tex

V3 - 08/13/2008

Chapter 1: Why Design? If this book were in color, you might more easily distinguish the two screenshots from each other. However, in the grayscale world of the printed manuscript, this will be much harder to see. It’s almost as if one design is simply the other one with a filter on top of it that affects the hue of colors. If you are curious, Figure 1-1 is ‘‘Default Theme’’ and Figure 1-2 is ‘‘Granite.’’

Figure 1-1

Figure 1-2

4

2:49pm

Page 4

Sanford c01.tex

V3 - 08/13/2008

2:49pm

Chapter 1: Why Design? But this is the point: Do you want people to look at your site and see the business as bland, predictable, and unimaginative, or do you want them to see the business as interesting, dynamic, and unique? Now, to contrast against these designs, consider Figure 1-3, which is the Web site for The Kroger Company (www.kroger.com).

Figure 1-3 Does that look like a SharePoint site? Even in grayscale, would you think that this site is one designed in MOSS 2007? Well, it is. And take a look at Figure 1-4, the Web site for Migros (www.migros.ch). Again, even in the context of black and white images in the print of this book, this site looks distinctly different from anything out of the box with SharePoint. Finally, take a look at Figure 1-5, the Web site for SendTec. (www.sendtec.com).

5

Page 5

Sanford c01.tex

V3 - 08/13/2008

Chapter 1: Why Design?

Figure 1-4

This example may be the most unlike any SharePoint design you have seen. But it was, in fact, designed in SharePoint. If you don’t believe it, view the source of the rendered page and you will see the following:

As with many things, it may be hard to define what good design is, even though you probably know it when you see it. And these examples show what good design can look like. In addition, the examples establish that designers are not and, more important, should not be confined to the templates that come with a standard MOSS 2007 installation. Note, however, that these examples are provided to contrast the look and feel of the default templates available in MOSS 2007. Do they necessarily satisfy things such as usability and accessibility? Maybe or maybe not, but that is not the point. The point is that with some thought and planning, and maybe access to the right tools (and the right book), you can take the ordinary and make it extraordinary.

6

2:49pm

Page 6

Sanford c01.tex

V3 - 08/13/2008

2:49pm

Chapter 1: Why Design?

Figure 1-5

Why Should Designers Care? The reasons that MOSS 2007 developers make the effort to put design at the forefront of their projects probably vary from developer to developer. But one universal truth is pride. Pride in the final product and how good it looks. Pride in the fact that something they created is so well received. Pride that they did a good job. But is pride enough? Fortunately, there are other real rewards to doing good design. Maybe the biggest reason is that it often makes financial sense to do good design work. After all, when you are a consultant, you often get leads and maybe even sales based largely on your portfolio. If a potential client is looking through the sites you have developed and can see nothing inspiring or, even worse, different from the other 20 sites you have already shown them, they will not be knocking down the door to try to hire you. You may still get the sale, but the first impression may not be what you are hoping for. After all, if businesses are scouring the Web to find consultants and looking at their online

7

Page 7

Sanford c01.tex

V3 - 08/13/2008

Chapter 1: Why Design? portfolios, are they really going to know that for client ABC you created innovative event handlers to customize workflow procedures on the document library? That won’t come through in a screenshot or even in a visit to the finished site. They would have to decide that they are still interested and then come talk to you to learn about the cool technology you were capable of using. But if you lose them in the first 10 seconds of looking through your portfolio, you won’t get that chance. Beyond that, though, what about referrals? Many deals today are made based on referrals or recommendations from clients. So what happens when you turn in this powerful site but the design looks like you didn’t even try to deviate from the out-of-the-box templates? Would the client recommend you? Perhaps. But would you rather they say, ‘‘Well, these guys were pretty good. They did everything we asked them to do and were great people to work with?’’ Wouldn’t it be better if they started off by saying, ‘‘You have to get these guys. They blew us away. Sure, they did everything we required from a business-requirements perspective. But have you seen our site? These guys are great?’’ Both scenarios might get you the call, but one would get you a much better starting point with these potential clients. And, to look at the other side of the coin, there are potentially going to be more and more consequences to bad design. Sure, there are costs of users not buying what you are selling; that is the obvious consequence if your site is horrible and ineffective. What designers might not think of, though, is that there are other real costs. In February 2006, Target Corporation was probably shocked to find out that they were being sued because their Web site was not accessible. In an effort to dismiss the charges, they claimed that they met the requirements of law by making their brick-and-mortar retail stores accessible to all. However, in October 2007, the Federal court thought differently. The U.S. District Court for the Northern District of California certified the case as class action on behalf of blind Internet users throughout the country and determined that Target.com violated not only the Americans with Disabilities Act but also two California civil rights statutes. This resulted in a lot of time and money being spent by the company to deal with both the legal ramifications and customer satisfaction concerns. This is a headache that anyone doing business on the Web just doesn’t need. You can read the National Federation of the Blind’s press release on the decision here: http://www.nfb.org/nfb/NewsBot.asp?MODE=VIEW&ID=221.

It should be noted, too, that this is just one of the most recent legal battles forged publicly about Web sites and accessibility. Similar suits have come up in Europe. This is a global issue that needs to be acknowledged and addressed by designers. As the world continues to change, designers need to keep abreast of the serious design considerations that change with it.

Why Should Managers Care? Perhaps intuitively, managers should care about good design for the same reasons that developers should. After all, it is important to them as well that they have strong portfolios, extremely satisfied customers, and no negative legal consequences to the products they deliver. They are in the same boat as their developers in this regard. In fact, it could be argued that these reasons are even more important to the manager than to the developer; if any of these things bring about negative consequences to the ongoing concerns of the business, the manager would be much closer to the shouting line than the developer (for better or worse). But more important than these reasons is the consideration of the impact on the organization’s employees and their professional growth and happiness. Plenty of developers have no interest in design and see it at best as a necessary evil. However, a growing number of developers really want to create good design.

8

2:49pm

Page 8

Sanford c01.tex

V3 - 08/13/2008

2:49pm

Chapter 1: Why Design? While it is important to focus on deliverables, it is also important for managers to understand how good design reaches clients and to make sure that developers have the resources they need to make the site look good, function ethically, and provide value. While it is true that some, or maybe even many, developers don’t want to get involved in design work, it is equally true that many do. By pursuing the discipline of design, they will become better employees who add tremendous value to the overall business.

Why Should Clients Care? It is a safe bet to assume that clients have a primary reason to care about the design of their sites: the user experience. For many sites, this translates into actual dollars. For others, it might mean that they are getting their message out to the largest audience possible. However they quantify it, they should, and almost always do, care about the design of their sites. Sure, they care about the nuts and bolts that run the sites. But you can rest assured that they care about the way they look too. And clients are getting better at quantifying this experience. Web metrics are becoming increasingly popular. People can fairly easily tell how many unique visitors access their sites. They can tell if they only go to the main page and then leave (indicating a bad experience) or if they stay for a while and surf the content available. If an analysis of the log files for the site shows that 90 percent of visitors access the main page for an average of only 2.3 seconds and then leave, something in the design is just not right. Whether that means that the content is such that nobody knows what the site is for or that the navigation is so confusing and poorly planned that nobody even knows how to get to another page is not as clear. What is clear, though, is that people found their sites and found them useless. Then they left. In this example, the site is not performing whatever function it is supposed to (unless it is supposed to run people off, in which case it is working perfectly). If the client is selling something, potential buyers likely aren’t even seeing what is available for sale, much less buying anything. And if the site is a public-information Web site preaching the gospel of good Web site design, it means nobody is listening to the message. This can be frustrating and can affect revenues severely (even public-awareness sites often sell advertisement space, which is affected by no-stays). Increasingly more important will be the desire to stay out of court. For example, say the class-action plaintiffs in an accessibility lawsuit get awarded $10,000,000 (or more). Who has to pay that? The designer who designed the site? The manager who oversaw the designer’s work? Probably not. After all, any independent consultant (or firm) will require the client to sign off before completing the project. So if the client used an outside firm to design their site, they likely signed off on its final design before releasing it to the world. And, if the client didn’t even put in any business requirements to handle accessibility (or if their requirements were vague), they can’t even say that they asked for accessible design but rather that the designers failed. And if the client used in-house resources to design the site, there really is not any gray area about who is responsible for the $10,000,000 penalty. This example might be hypothetical, but it does reflect some of the very real concerns developing in the business world. Either sites will get better about accommodating all users or lawsuits will become more frequent. And going to court, win or lose, is not cheap. Even if you win the case, you are out the legal costs. It’s better to worry about paying an extra $5,000 in the design budget than to worry about dealing with an exponentially more expensive lawsuit down the road. Plus, clients care about their image. They want their sites to look better than the competition. They want to send links to their friends and colleagues and say, ‘‘Look at our new site!’’ Clients, maybe more than any other group, care about design. And, if for no other reason, so should you.

9

Page 9

Sanford c01.tex

V3 - 08/13/2008

Chapter 1: Why Design?

So Why Use SharePoint for Design? A fair question to ask, especially after reading this chapter, is, ‘‘Why should I design with SharePoint?’’ This is a remarkably simple question with a less-than-simple answer. First, SharePoint is designed to provide every functionality a portal may need out of the box: wikis, blogs, message boards, document libraries, version control, security, announcements, integration with Active Directory, and a laundry list of other features. This all comes with the initial installation and is fairly easily set up and controlled by administrators. This is a huge selling point. Add to that the flexibility and ease of customizing the default installation, and you have a much more compelling reason to consider SharePoint as your portal platform. You can integrate custom .NET code into your applications (in code blocks or in code-behind files). You can import data connections through the Business Data Catalog (BDC) that allow your SharePoint lists and controls to integrate with outside data sources. You also can completely overhaul the way the site looks and feels using familiar .NET 2.0 controls (for instance, master pages). Add to this that you can create custom Web parts to do pretty much anything else you need to do. So, while the default installation is remarkable on its own, the power of what you can do with it when you want to step outside of the boundaries of the default can be awe-inspiring. And don’t forget the level of user interaction and control of the site once it is running. Users with no Web programming experience can, with a little training and guidance, create grids that report data from the system, generate and modify custom lists, and even control who has access to what on the site. Developers no longer need to do a lot of the day-to-day maintenance of the site. The users and site administrators can do the majority of it on their own, even if they have no idea what a code block in C# looks like and have no interest in finding out. One thing that might give developers pause, though, especially in light of some of the examples in earlier sections of this chapter, is accessibility concerns. It is worth noting that, out of the box, SharePoint has some accessibility problems. This is a known issue. However, Microsoft and the community of developers are working together to try to solve this. One example is the efforts made by the development community to integrate the CSS Friendly Control Adapters into SharePoint sites to make many of the controls, such as the menu/navigation system, more accessible. (You can read more about these adapters in Chapter 13.) Maybe even more impressive is the October 2007 release of the Accessibility Kit for Microsoft Office SharePoint Server 2007 by HiSoftware (http://aks.hisoftware.com). (This, too, will be covered in greater depth in Chapter 13.) This kit was commissioned by Microsoft in an effort to better meet the accessibility needs of the Internet community regarding MOSS 2007. This is a huge step forward in the mindset of major software developers and is worth noting when getting into accessibility issues, especially when considering using MOSS 2007 as your platform. Is MOSS 2007 the perfect platform for portal development on the Web? No, not really. There are a few limitations, such as the accessibility problem that, if not handled, will be an issue with out-of-the-box installations. And this is no small matter. However, there is a concerted effort to remedy this major limitation, and as the community of developers grows, more and more solutions will present themselves. The developers already out there in the field working in MOSS 2007 are probably some of the more passionate you will run into in the Web application development arena, and most of them are happy to share their experience and suggestions. So, whatever limitations there might be could probably just as easily be called ‘‘opportunities’’ or ‘‘challenges.’’ With the power under the hood of SharePoint, figuring out how to get around these challenges is not only achievable; you might just have fun doing it (and you might even make a few friends along the way).

10

2:49pm

Page 10

Sanford c01.tex

V3 - 08/13/2008

2:49pm

Chapter 1: Why Design?

Summar y At this point, you have gained an appreciation of some of the reasons why good design should be a serious part of the planning of any Web project (SharePoint or otherwise). Maybe you have been exposed to some things you haven’t considered before. Or maybe you have just received confirmation on some of the things you already believe. Either way, you should have a new (or renewed) appreciation of the reason to follow good design principles. Now that the why is out of the way, the rest of this book will focus more on the how. You will get a better understanding of what good Web design means, how to use tools such as Photoshop and SharePoint Designer for your design needs, and how to use all of the out-of-the-box functionality of SharePoint to make it look anything but. With that, it’s time to begin. Good luck and good coding.

11

Page 11

Sanford c01.tex

V3 - 08/13/2008

2:49pm

Page 12

Sanford c02.tex

V1 - 08/13/2008

Web Design 101 Any chapter titled ‘‘Web Design 101’’ is bound to be passed over for more exciting topics. A broad introduction to Web site design isn’t nearly as interesting as customizing a search results page or creating publishing sites, is it? Bear with me, though. SharePoint has its own rules, tools, and pitfalls that can make design easy or maddening. Much of this chapter should be common sense. The key ideas covered here are pretty straightforward: Set limits, involve your users, make things easy to find, and make pages that give users what they need in as attractive a manner as possible. The problem is that common sense often gets plowed under in the name of speed and efficiency, or it gets lost in feature creep. And if you’ve ever had a Web browser open for more than 5 minutes, you can probably attest to the fact that common sense is not all that common. Development and design techniques have changed considerably from the early days of the Web. In the murky backwaters of the Internet, site design required arcane knowledge. In-depth understanding of technologies like HTML, CSS, and JavaScript were needed just to make pages function, let alone look professional. This meant that the majority of sites were created by people with a bent for the technical rather than an eye for design. Times have changed. Moreover, the technology that drives Web sites has changed. The next time you crack open the Internet Information Services console (see Figure 2-1), take a look at the files that make up your SharePoint site. The folder that would normally house all of the files that constitute your site is surprisingly sparse. There’s no ‘‘there’’ there. SharePoint sites are not hand-built .NET applications, ASP sites, or a from-scratch set of HTML pages. Everything a user sees on your SharePoint site is created ‘‘on the fly,’’ rendered in real time by the SharePoint engine from a small handful of ASPX files, XML files, configuration settings, and rows from a database. This is a source of frustration to many developers. Since this is very likely the first time you have encountered anything like this, many of the tools and techniques that you’ve honed over the years doing traditional Web page development no longer apply. In far too many cases, you’ll be limited to SharePoint Designer or a text editor to implement a new design.

4:12pm

Page 13

Sanford c02.tex

V1 - 08/13/2008

Chapter 2: Web Design 101

Figure 2-1 The payoff for these limitations is pretty significant; SharePoint provides a framework that contains most of the tools needed for the heavy lifting on a Web site: display, workflow, security, content management, and data management. These functions are already baked in. It makes it easy to rapidly develop sites with robust functionality through a simple Web interface. You don’t have to concern yourself with building document storage, complex content management tools, or implementing a page-by-page security scheme. But, that also means relearning new technologies to do things that most coders already know how to do.

Goal-Oriented Design The idea of a table or a chair is pretty easy to define, and as such is fairly easy to design. If you ask someone to jot down a plan to build those things, you have a pretty good idea what you’re going to get. A portal, on the other hand, is another matter entirely. Microsoft and others have done an excellent job marketing portals to corporate America, but there is a great debate as to how to define what ‘‘portal’’ means. The market-speak for portals sounds great. After all, who doesn’t want to connect people, processes, and information using next-generation tools while empowering users by harnessing business intelligence? The problem often lies in making this concept into any sort of reality. Is your intranet already a portal? Is it a portal in the same way Yahoo! is a portal, or is it more like a document management system that can act as a portal? Do you have an external facing Web site that clients use as a portal? Is your Internet site part of an overall portal system? There are a lot of grey areas. Before you can begin with page layouts or decide which Web Parts to use, take a step back. The goal of a portal is to help make things more organized, to make the lives of users simpler and more efficient. Many companies make the mistake of installing SharePoint and allowing it to grow rampantly, without a plan. In the end, this can make things far more complicated than they were to begin with. Let’s simplify things then. For the sake of argument, let’s make up a working definition: A portal is a Web-based application that provides users with access to the stuff they need. So, the real question is this: What is your company going to do with a portal? What stuff do they need? Is it merely a replacement for a few mapped network drives, or is it going to be used as a product development lifecycle tracking system? Is it part of a document management system, or are you just trying to

14

4:12pm

Page 14

Sanford c02.tex

V1 - 08/13/2008

4:12pm

Chapter 2: Web Design 101 give your office a way to find key performance indicators from other business systems? The most important step in any design process is to define the goals that your portal will attempt to achieve. Get your goals firmly in place and carve them in stone. This defines the scope of your project. Once you have the finish line clearly defined, they you can fill in the details.

Driving Adoption Wait. Driving adoption? Isn’t that what you do after you’ve got a portal for users to adopt? That’s what usually happens, and by then, it’s too late. In a previous life, I did a systems upgrade project for a client, installing Windows XP on all desktop computers and upgrading existing Office applications. The job was fairly easy and straightforward. The other techs and I made things faster, better, and prettier. This is the best part of the IT world. Once in a great while, IT people are regarded as conquering heroes by nearly everyone. However (and there’s always a however), everyone warned me about Marge, one of the heads of the accounting department. She had been in charge of expenses longer than anyone had been with the company. She probably came with the building. She is the most frustrating part of the IT world. Marge had no love or patience for computers or anyone in IT. She had been involved in the company’s migration from card readers to tape drives, from letters to faxes to email. I was there to change everything again, for which I was evil incarnate. She thought my job was to screw up her life. She complained about the new OS, she complained about the icons. She gave me the evil eye when I set up Outlook, and she told me that she didn’t trust email. As I put shortcuts on her desktop, she told me that the database applications used the wrong calculations. She complained that no one ever asked her before changing everything. This went on for over an hour. Every company has a ‘‘Marge in Accounting.’’ Unfortunately, your job is to make her happy (or, at the least, less unhappy). And trust me, if you can get your Marge to adopt the changes that you’re about to throw at her, the rest of the job is a walk in the park. Marge is a worst-case scenario. I can’t really blame her for being mad at the all new stuff that was thrown at her. She was just trying to do her job, and IT was methodically making things more complicated without asking if it would actually help her. And she had no say in any of the decisions that directly affected her job. You’re about to be the IT person in that scenario and you’re going to have to get Marge and the rest of your organization to adopt your new portal. What can you do to improve this process? Simple: Ask them to help. The key to driving user adoption is to get users involved in the design process from the very beginning. There are no better experts at your company that the people who actually do the work. Once you have a set of goals for your portal, the next step should be to involve these users. This process can be challenging. As with Marge, modern users are often jaded by the constant changes in IT. You’re just another snake oil salesman that promises to make the ‘‘Bad Stuff’’ go away with your really great ‘‘New Stuff.’’ At this point in the process, your job is less about interfacing with a Web site and more about fostering relationships with people. There’s a natural progression to these relationships

15

Page 15

Sanford c02.tex

V1 - 08/13/2008

Chapter 2: Web Design 101 that can benefit you and the people who’ll use your SharePoint sites. This process can be a lot like dating. In fact, the sequence of emotions is very similar: Note

New SharePoint User

New Boy/Girlfriend

Uncertain

Hey, this seems shiny and new, but it’s probably another junk piece of software that someone in IT is trying to force on me.

Hey, this person seems nice and attractive, but they’re probably just another whackjob like the last three people I dated.

Excited

HOLY COW! Did you see that? I can move stuff around on my Web page! This is the greatest thing ever!

HOLY COW! This is the person of my dreams! Perfect in every possible way!

Inspired

Wouldn’t it be great if I could get this key performance indicator to automatically tie in with these three other business systems?

Wouldn’t it great if we, you know, moved in together?

Disappointed

What do you mean I can’t have a list view that automatically reads people’s minds? I NEED THAT.

What do mean you want to get rid of my collection of bobble head dolls? I NEED THAT.

Acceptance

Well, maybe it can’t read minds, but I suppose that this is still leaps and bounds better than the old way we did things.

Well, they may have their flaws, but I suppose that this is still leaps and bounds better than those last three whackjobs I dated.

Painful as it can be, involving users early in the design process accomplishes two of the most difficult tasks in design:

1.

2.

It gives the people who know the business a chance to share their knowledge. A welldesigned, well-thought-out solution will be adopted with less resistance than one that ignores what every other user knows. It is better to get this information now than after you’re done. It is a chance to internally market the portal. When the day comes to roll out your great new portal, the users who helped will be more likely to support adoption of a new way of doing business.

Stor yboarding Okay. You’ve gotten the best and brightest of your company to sit down with you. You’ve plied them with coffee and baked goods. What’s the next step? Drawing pictures, of course. A picture, as it is said, is worth a thousand words. That goes double with SharePoint design. Odds are, the people you’re mining for information have never seen SharePoint before. Storyboarding is a process where you create a representation of what users are going to see. By working with users to create interfaces, you get more bang for your buck: Users can give immediate feedback on what they like and what they don’t like. Time spent at a whiteboard is cheap compared to time spent creating anything on a screen.

16

4:12pm

Page 16

Sanford c02.tex

V1 - 08/13/2008

4:12pm

Chapter 2: Web Design 101 But a quick word of warning: SharePoint is not all things to all people, and this may be a cause of contention. As someone who designs portals for a living, I constantly bump my head into the limitations of the SharePoint architecture. It is extremely malleable. It can be extended, stretched, and tweaked. But it is not and will not be all things to all people. The line is often the difference between design and development. SharePoint often gives the illusion that everything should be easy, that a few clicks on a Web page will accomplish something that ends up taking weeks of staring at Visual Studio to accomplish. One of the most difficult things about SharePoint design is realizing when that line is crossed. For example, assume for a moment that you need to allow users to publish documents from a team site to a document repository. Spending time with the team in question will help you design a document library that meets their needs. They want custom columns for ‘‘Client Name’’ and ‘‘Purchase Date’’? No problem. They want to be able to use a drop-down menu that allows their users to send the document to a central document repository? Piece of cake. They want a custom graphic that appears next to each document to tell them the approval status of a published document? Hold it right there. Yes, it’s possible to develop just such a display using custom coding tools such as list event handlers, but realizing that this is a non-trivial task will help keep your project on schedule. The more users, designers, and management learn to use and embrace SharePoint’s innate tools and functionality, the easier it’s going to be to build your site. And unfortunately, the further you stray from SharePoint’s standard functionality, the more work it’s going to mean for you. In terms of storyboard creation, your job is to keep user’s requests in the realm of the real.

Por tal Design One of the great strengths of SharePoint is that it’s very easy for users to create sites and customize the look and feel of content. One of the great dangers of SharePoint is that it’s very easy for users to create sites and customize the look and feel of content. SharePoint’s biggest challenge is often controlling growth. With all that ‘‘enabling’’ and ‘‘empowering’’ you’ll be doing, it’s often difficult to maintain a firm grasp on where your portal is going. An uncontrolled portal will quickly descend into a chaotic mess where no one can find anything. A well designed portal structure, on the other hand, will make your job easier. Security is easier to control. Search is easier to define. Growth is easier to manage. Users can access information easily. It’s like an IT version of nirvana. The goal of portal design is simple: Give your users a structure where they can quickly and efficiently find and use the information that they need. But what is the best way to create a framework for information and still allow for growth? Take a step back a moment and return to some of the fundamental reasons you’re implementing a portal. Most companies use SharePoint for: ❑

Giving users a framework to share and use information

❑

Making it easier to find that information

❑

Controlling access to critical information

17

Page 17

Sanford c02.tex

V1 - 08/13/2008

Chapter 2: Web Design 101 To achieve these goals and to maintain some sort of order, a SharePoint portal should have a pre-defined growth plan. This plan should define its topology, its ‘‘shape.’’ Several basic topologies are commonly used, but it’s up to you to decide which is best for your company. If you’re reading this book, you probably already have a portal in place. Things like design and branding often come in last as companies learn to embrace SharePoint. But again, bear with me. If you already have a portal, understanding portal topologies can help you plan for future growth, and perhaps allow you to reorganize your site collection so that users can get the information that they need faster and more efficiently.

Things to Consider Before you get into any examples, look at some of the things that you should consider when deciding how you will construct your portal.

Ease of Use This is, by far, the most important consideration when deciding site layout. One of the best ways to help users access the knowledge your portal contains is to organize it in a pattern that they already know. The portal should be a paradigm for how people think about information in your company. Your already have this in one form or another. It could be a set of departments or a business process. It could be the words that people in your company use to describe your business. More than likely, it will be a combination of one or more of these.

Security SharePoint allows for very complex security scenarios. Rights can be granted on a global level, a site level, a list level, or an item level. Recognize that the more granular the level of security, the more administrative overhead you or your portal management team will incur. In general, it’s best to group information with similar security rights. For instance, if your company intends to store sensitive materials such as patent information, it would be far easier to place all the lists, document libraries, and calendars surrounding patents together on a single site. External access to information can also drive topology decisions. If you plan to grant access to external users such as vendors or clients, you need to decide how they can access the information that they need without interrupting business processes or violating your company’s security policies.

Search Yet another reason people implement SharePoint is for its powerful search capabilities. There is a common misconception that search can make up for poor portal design. After all, who cares if the HR site is in a logical place for certain documents when I can just pull up a vacation request form using search results? The problem with this scenario is that search ignores the context of the information. Most data is not isolated. A document like a vacation request form may have metadata that is not returned with search results or may only be useful if I have access to the company’s vacation calendar. Giving information a clear place to reside makes it easier to find and allows users to leverage it more effectively. Information wants a good home.

18

4:12pm

Page 18

Sanford c02.tex

V1 - 08/13/2008

4:12pm

Chapter 2: Web Design 101 Another consideration with search is the proper implementation of search scopes. A scope allows users to search a specific subset of the data in your portal. This subset can be defined in two ways:

1. 2.

Defining one or more sites that compose a ‘‘branch’’ of a portal’s hierarchy. Defining a specific kind of data — a content type or property.

The goal of setting up search scopes is to segment your portal’s information into chunks for easier access. A proper portal design should allow for that by segregating data into logical chunks so that each scope can be easily defined. Have a lot of product literature? Keep it in the same section of your portal, set up a scope, and users can find the right document without muddling through all the documents from HR and Accounting. Content type and property search scopes are meant to be topology-independent. However, search results are dependent on the security of where the information lives, so a properly planned portal design can benefit these types of search scopes as well. For more on search scopes, see Chapter 12.

Growth One of the worst mistakes you can make when defining a portal topology is ignoring growth. The minute you decide that 10 sites is all your company needs, you’ll need 11. The key with planned growth is to have room to grow built in at each level of the hierarchy.

Portal Topologies Now that you’ve explored a few of the areas that will influence the shape of your portal, it’s time to consider topology. Note that in the topological descriptions shown below, several types of sites are not shown. Search Centers and Document Repositories, for instance, are meant to aggregate data from other parts of the portal, and therefore live ‘‘outside’’ of the primary portal topology.

Business-Based Model This is probably the most commonly used topology. Creating a portal to match your business’s departmental structure is a no-brainer. In Figure 2-2, you can see a top-level home site that allows access to a set of departmental sites, each of which allows access to sub-departments and committees. This plan allows for an easy implementation of security. If your company uses Active Directory, you probably already have these groups defined. Departmental separations also often mimic the security needs of a business. For instance, HR users may have privileges to view payroll information, while IT and Marketing people do not. The downside of this topology is that it often ignores how your company does business. In a businessbased topology, departments are completely segregated. The only place that companies like these exist is in business school text books. Accomplishing real work takes people from every area of your company working together. For instance, putting a new product on a shelf often involves a mish-mash of personnel from various departments: people from Research & Development, new hardware from IT, a new marketing campaign, and so on. Setting up a portal using business-based topology can involve additional administrative overhead, and information on a single project can end up scattered over the portal.

19

Page 19

Sanford c02.tex

V1 - 08/13/2008

Chapter 2: Web Design 101

Accounting

Marketing

Human Resources

IT

Accounts Receivable

Public Relations

Recruiting

Customer Support

Accounts Payable

Research

Benefits

Business Systems

Expenses

Customer Relationship Management

Asset Management

Payroll

Training

Figure 2-2 Here are the pros and cons of using the business-based topology: Pros: ❑

Users are already aware of the structure.

❑

Security and Search are easy to implement.

Cons: ❑

It may not reflect the way your company actually does business.

Process-Based Model A business-based model makes sense in several places: org charts, Active Directory, and in the heads of a corporate board. Instead of a business-based topology, you may need a topology that reflects the way your company does business. Let’s take another look at the example given in the previous section. The information that a company accrues is all about a business process — taking a product from conception to a shelf. Rather than setting up the elaborate custom code and processes needed to move a mass of documents data from a product development branch of a portal to a marketing branch each time a product is ready to be advertised, it makes much more sense to keep the data in one place — perhaps a site that can be used to house everything there is to know about that product. Each site can, in turn, have its own document libraries, workflow, and security based on the needs of the business process. In most cases, companies don’t make a single product, but a host of items across several product lines. This is not a problem for SharePoint — just add sites as needed.

20

4:12pm

Page 20

Sanford c02.tex

V1 - 08/13/2008

4:12pm

Chapter 2: Web Design 101 In the example shown in Figure 2-3, the portal topology is defined by a collection of business processes. It’s a simplified portal for a company that develops hair care products. In this case, the primary goal of the portal is not to house a disparate collection of company-wide data but to drive a business process. Each site can house the information that is needed on a specific product, including design specifications, marketing materials, sales forecasts, you name it. Every bit of information that you’d need to know on any product has a special place to call home.

Hair Care

Electrics Kidsplay Shampoo & Conditioner

Styling Brushes Hair Dryers OmniBrush HairBlaster 1400w

Bolanical

OmniBrush Mini

HairBlaster Travel

Shampoo

HairCraft Combs

Conditioner Curlers Artisanal Trieste Travel

PocketSize

Advanced Solution Stylist's Formula

Figure 2-3 The information makes more sense for a process-driven business culture. One of the shortcomings of previous versions of SharePoint was that it was difficult to share information between sites. MOSS and WSS 3.0, however, make data aggregation easier with new technologies such as the Content Query Web Part and the Data View Web Part, both of which allow data to be aggregated for display in a single location. In the example shown, these tools would allow for users to view information across a product line without the need to manually dig though various sites. This topology can also simplify administration. Security can be implemented by creating teams of users from across various departments. Search can benefit as well, as information is segregated into the same logical ‘‘chunks’’ that users are already used to. Need to set up a scope that identifies a specific product line? Not a problem. As you can see, this changes what the concept of a portal can be. With the addition of some simple workflow, the portal can go from a centralized repository of departmental information to a full-blown tracking application. Of course, this methodology could be used for nearly any business process, from product management to case management to streamlining a sales pipeline.

21

Page 21

Sanford c02.tex

V1 - 08/13/2008

Chapter 2: Web Design 101 Here are the pros and cons of using the process-based topology: Pros: ❑

Can closely match the ways your company manages processes.

❑

Gives each process a place to call home — a centralized resource location for all information pertaining to a single item.

❑

Has excellent ability for growth. When another business process starts, just add a site at the appropriate place in your site collection. Users will already know where to look for it.

Cons: ❑

Security and Search can be more complicated to administer. For instance, in the example given above, consider the headaches that could occur if users could only be granted permission to access a site on an item-by-item basis, and that some companies produce thousands of items.

Taxonomy-Based Model On its surface, this can look similar to a business-based topology. After all, businesses classify departments by what they do. But look a little deeper, and taxonomy-based topology starts to reveal itself. Taxonomy, by its definition, is all about classification. This can be a little abstract, but you will probably find that you use this technique to store information already. For instance, my desk has several piles of paper, each with its own classification. Receipts are in one pile, mail is in another, and notes are in yet another. It’s not practical for me to separate these items by who is going to use them (a business-based topology) or what I’m going to do with them (a process-based topology). But I can find what I need because I understand the classification of the item I’m looking for. Your business already has its own taxonomy, whether you realize it or not. Taxonomy is about the way people describe what they do. You’ll probably find that your company has its own language, a way of describing what it does. In the example shown below (Figure 2-4), the portal in question groups business processes and departmental needs together, because that is how the users think and talk about their business. Rather than discussing inventory, vendor supply chains, and factories as completely separate entities, the entire lot is placed together to address the manufacturing needs of the company as a whole. By properly defining how your data should be defined, you can give users an extremely intuitive way to find data. Here are the pros and cons of using the taxonomy-based topology: Pros:

22

❑

It can be used to enforce a classification of information. This can have distinct benefits. For instance, users can be certain that if a document is in a site called ‘‘Approved Vendor Contracts,’’ it is indeed an approved vendor contract.

❑

Users can intuitively find information.

❑

This topology is very easy to extend. Because the shape of the portal is based on abstract ideas, there’s no limit to how or where the portal can grow.

4:12pm

Page 22

Sanford c02.tex

V1 - 08/13/2008

4:12pm

Chapter 2: Web Design 101 Cons: ❑

It can be difficult to get everyone to agree on taxonomic terms. For instance, users could have widely divergent ideas of where a document should reside, leading to information on similar topics being scattered about the portal.

❑

It can be difficult to implement search and security. Though it may be possible to group restricted items together, this may not always be practical. For instance, suppose that your company classifies a certain set of documents as ‘‘contracts.’’ If your business rules for contracts dictate that some contracts should only be viewed by management, while others are available to the general populace, you’ll have to implement item-level procedures to ensure that only the right people have access to each document. Yes, this can be done, but no, it’s not very efficient (or fun).

❑

To maintain the proper classification, a small number of users must be in charge of the classification procedure.

Growth

Manufacturing Inventory

Communication Projects

Vendors

Clients Smith and Sons

Short Term Thermacrete

United Metals Fasten Tech

Long Term R&D/Patents

iBuildings Internal Company Newsletter

Factories Corporate Retreat Columbus Announcements Seattle

Figure 2-4

Publishing Portal This may not exactly be a topology per se, but it does deserve some attention here. More companies are embracing SharePoint as an intranet solution. It’s becoming obvious that all the tools that make SharePoint valuable internally can also be leveraged to make sure that information flows from the experts — your users — to the outside world of people who visit your Internet site. The goal of your portal may not be to function as an intranet or extranet site, but as your company’s primary presence on the Internet. Microsoft Office SharePoint Server 2007’s new publishing features make this an ideal tool to facilitate the creation, approval, and publication of outward facing information.

23

Page 23

Sanford c02.tex

V1 - 08/13/2008

Chapter 2: Web Design 101 Here are the pros and cons of using the publishing portal-based ‘‘topology’’: Pros: ❑

Allows users to publish and approve information on an external facing site.

Cons: ❑

Because the site is open to the public, security and access need to be considered very carefully.

❑

Microsoft Office SharePoint Server 2007 for Internet open licensing can be costly.

Hybrid Portals It’s unlikely that any particular topology will work best for your company. More often than not, a hybrid of one or more of these ideas will be developed. By combining strategies from multiple topologies, you can take the best from each. A business based topology can easily contain a group of sites that support a business process. For instance, a research and development site can lead to a group of sites for new product development. There are downsides to this approach. If the goal of a portal’s topology is to give users a well-defined paradigm that they intuitively understand, deviating from that plan could cause confusion. Be prepared to provide additional training to support this. If users in Accounting are expected to leave their accounting site to provide forecasting information in another branch of the portal, they’ll need to know how and where this data should live. To that end, security can be a little more complicated to configure. Again, if the security of a portal is based on the fact that users have access to a business process or a departmental site, deviating from that plan requires additional administrative overhead. In most cases, you’ll have to implement active directory or SharePoint security groups on a site-by-site basis and continue to maintain these for the life of the portal. There are real benefits to this plan, however, especially when your portal’s needs are more complex. Many companies are extending their portals to reach outside their intranets. In the past, when a user wanted to publish an article or release information to an outside client via the Web, they’d deliver the document or other information to the Web master so that the Internet site could be updated. SharePoint can streamline that process while ensuring that information is provided in a secure manner. In Figure 2-5, you can see that the company that uses this installation of SharePoint has divided their portal into two separate sections — an inward-facing intranet based on a business model and an outward facing extranet portal that is used as a corporate presence site and a portal for vendors to access key information. Information can flow between the two sections through manual or automated processes, eliminating the need for a Web master as a middleman. This can also ensure that external users are kept up-to-date with the latest information. Here are the pros and cons of using a hybrid topology: Pros: ❑

24

Can take advantage of the best of each topology.

4:12pm

Page 24

Sanford c02.tex

V1 - 08/13/2008

4:12pm

Chapter 2: Web Design 101 Cons: ❑

Because the rules that define where information lives can differ from site to site, this plan may make information more difficult to find.

❑

Security can be more difficult to configure and maintain.

❑

Search can be difficult to set up, as information can reside in more than one site collection.

Intranet

Accounting

Asset Management

Expenses

Accounts Payable

Extranet

Internet Site

Marketing Public Relations Customers Relationship Management

Vendors

Vendor A

Vendor B

Vendor C

Accounts Receivable

Figure 2-5

Mini Portals More and more companies are starting out with small implementations of SharePoint. There are numerous reasons for this. In some cases, companies are implementing dashboard sites that leverage SharePoint’s technologies to aggregate important data quickly, without a lot of development time. For instance, a portal may display data from an SQL-based inventory management system using a Business Data Connector or give users real time updates using key performance indicator Web Parts. This also allows site administrators to quickly update the display of this data using a Web-based interface rather than having to crack open Visual Studio or another development tool. The initial cost for a SharePoint license may seem steep for such things, but is still probably less than hiring a developer to create custom interfaces. Another case for mini portals is that they allow for the rapid development of Web sites for key business processes. SharePoint lists are great for quickly implementing data storage and some light reporting. Calendars and announcement lists are a great way to give visibility to key projects.

25

Page 25

Sanford c02.tex

V1 - 08/13/2008

Chapter 2: Web Design 101 Here are the pros and cons of using the mini portal-based topology: Pros: ❑

Allows for the fast delivery of key information.

❑

Is easy to maintain.

❑

Is a great way to introduce your company to SharePoint without involving the entire organization.

Cons: ❑

Can be difficult to build on if the company decides to expand the portal’s functionality.

Web Page Design Now that you have a plan for where information will live, the next step should be to get your plan off your white board and onto a Web site. If you search for ‘‘Web design’’ on the Internet, page design is what people are talking about. There are thousands of Web sites that detail good design practices for general use sites, and it is certainly worth your time to peruse as many as you can. Most of the information you’ll find refers to general-use Internet pages and the complexities of code that are required to create them. SharePoint sites, on the other hand, have a preset collection of building blocks that can be used to craft professional looking sites more quickly and efficiently. There is no need to build that style sheet from scratch or hand code navigation pieces. Out of the box, SharePoint’s got you covered. Some people might look on this as limiting, but I see it as liberating. SharePoint allows for rapid application development, letting you skip the dirty parts of page crafting and begin putting together sites immediately. More in-depth changes can take more time but still far less time than a from-scratch solution takes. That being said, there are still some basic rules to help your users get the most out of each page on your portal. The suggestions in the following sections should get you started in created a more useable, more attractive portal.

A Grain of Salt Sure, you can spend thousands on licensing and design work to create a static site that will stay exactly the way you build it, but that’s probably not why you’re using SharePoint. When you have a moment, check out the language on Microsoft’s SharePoint site (http://www.microsoft.com/sharepoint/ default.mspx). It’s all about ‘‘empowering knowledge workers’’ and ‘‘enabling communities.’’ What exactly does this mean? It means that users can control content on the Web sites: lists, documents, calendars, press releases, you name it. This can be frustrating for some designers used to maintaining tight control over the sites they’ve created. Since the early days of Web design, developers and designers have owned the look and feel of a site.

26

4:12pm

Page 26

Sanford c02.tex

V1 - 08/13/2008

4:12pm

Chapter 2: Web Design 101 For more than a decade, these people were often given the hokey title of ‘‘Web master’’ as they alone controlled what went where and why. One of SharePoint’s great strengths is its capacity for user driven design. Site owners can move items around to best meet their needs. They can add and remove lists, calendars, and other content when they feel their site needs to grow. Although MOSS and WSS allow for a fairly granular control over the rights each site user and administrator are granted, there needs to be a balance. Each right you grant to a user is one that you, as a designer, are giving away. The goal of SharePoint is to put control into the hands of the people who have end-of-line business knowledge. Moreover, they will be able to do this without bothering you to update content or make simple changes. So, what follows are a few fundamental rules for page layout. Realize that in some cases, the best you can do is to give users a solid framework and hope for the best.

Creating a Site Template Before you start slapping together your Web pages, they’ll need someplace to live. SharePoint has the ability to make exact copies of a site through the use of site templates. This is an excellent means to get the design exactly right once and then propagate the site to flesh out your portal topology. Creating a site template gives you a few other benefits as well: ❑

Site templates allow for a standardized site design. As mentioned before, keeping a uniform interface throughout your portal makes it easier for users to quickly adapt to a new SharePoint environment. Creating sites from a base template ensures that your future sites will look, feel, and act the same.

❑

They allow for fast implementation of complex items. Keep in mind that document libraries and lists maintain any customizations you make. This means that things like custom workflows or template documents are carried to the new site without any additional effort. If necessary, you can even retain fully populated lists and document libraries as part of the template, but keep in mind that there is a 10 megabyte limit on the size of a site template.

Identifying a Target Resolution Designing a Web page is much the same as painting a picture: You have to know your canvas. In Web design, this means determining an optimum resolution at which your pages will be displayed. Luckily, as screen size and video technology have progressed throughout the last few years, average screen resolution has increased greatly. For a moment, let’s assume that you’ve selected a target resolution of 1024 × 768 pixels, which is a fairly common resolution these days. With luck, your page will look something like Figure 2-6. More screen real estate makes things considerably easier for Web page designers. Unfortunately, you have less space to place information than you think. First, forget about making users scroll sideways to access key information. Most scroll mice and touch pads only allow for up and down tracking. Anything past the right side of the screen is unlikely to be seen by the majority of users. The goal of a Web page is to display unique page content. As beautiful as your navigation and title bars appear on the page, they won’t keep users coming back to your site. So, for the moment, let’s think about content.

27

Page 27

Sanford c02.tex

V1 - 08/13/2008

Chapter 2: Web Design 101

Figure 2-6 That still leaves you with 1024 pixels to play with, right? Wrong — take away 10 pixels for the browser’s scroll bar and another 10 pixels on each side of the screen for margins. Take away another 165 for the SharePoint Quick Links menu down the left side of your page, and you’re down to 829 pixels. Take away another 80–100 pixels for padding between Web Parts and any additional content, and you’re down to around 740 pixels. You’ve lost over a quarter of your horizontal canvas to SharePoint, and you don’t even have any content on your page. Vertical resolution leaves you with even less space. Over 140 pixels are non-negotiable, given up to the browser controls — the address bar and button bars. This number goes up if users have additional toolbars such as Google or Yahoo search bars. Then lose 25 pixels for a global links bar (users have to have access to their My Site and My Links, right?), another 35–50 for your company’s logo, and another 20 for SharePoint’s tab navigation feature. Add 20 for margins and another 20 for a breadcrumb Web Part. Tack on another 80 for padding, and you’ve lost almost half of your 768 pixels of vertical space.

28

Web Page Elements

Horizontal

Vertical

Starting Screen Resolution

1024

768

Web Browser

− 10

− 140

Margins

− 20

− 20

Quick Links Navigation

− 165

Site Navigation (global links and tab controls)

−0

− 45

4:12pm

Page 28

Sanford c02.tex

V1 - 08/13/2008

4:12pm

Chapter 2: Web Design 101 Web Page Elements

Horizontal

Vertical

Breadcrumbs

−0

− 20

Internal Page Padding

− 80

− 80

Corporate Logo

−0

− 50

Remaining Space

759

413

So, all told, your 1024 × 768 resolution yields 759 × 413 pixels. That means that more than 60 percent of a user’s screen is gone before you even start putting content on a page, and that’s the best-case scenario. Yes, you can remove some of these items, but that will also remove the functionality that the items provide to users, which is functionality that you will probably have to provide in some other way. Now that it’s been established that you have a postage-stamp-sized plot in which you can grow your intranet, the goal will be to make the most out of what you have. The following sections will explain how.

Keeping It Clean and Simple SharePoint makes it easy to put things on a page, regardless of whether it is the new task list, the key performance indicators, or the handy list of contacts. One of the greatest temptations that designers face is to show everything to their users at once. Needless to say, this can overwhelm even the most data-hungry user. (See Figure 2-7).

Figure 2-7 As you can see in Figure 2-7, too much information is not only unattractive but difficult to use. The page uses the same navigation and layout as Figure 2-6, but the amount of data that’s packed on the page doesn’t help users be more efficient; it just makes them more confused.

29

Page 29

Sanford c02.tex

V1 - 08/13/2008

Chapter 2: Web Design 101 Try to limit the information that you place on the page. A few tips include: ❑

It’s been established that there’s not much free space on a page, but blank space is okay. Really it is. Some designers seem to have an itch to fill every square inch of a user’s screen with data. Isn’t that what portals are for? Easy access to everything? Well, yes, but not all at once. A good rule of thumb is that every idea that you’re trying to get across deserves its own page. SharePoint makes it easy to add pages, format data, and extend navigation. Take advantage of these tools.

❑

Allow users to drill down into list items rather than displaying each item’s full text. Announcement lists are excellent candidates for this. Users often enter lengthy descriptions, but a headline will suffice to lead people to click through to a full listing.

❑

Limit list displays to key columns. List views are your friends, but don’t abuse that friendship. Avoid the temptation to cram as much data into one place as possible.

Keeping Important Information above the Fold A user’s attention is a finite resource. You have to catch his or her attention with every page click. The opposite also hold true: If you don’t make it easy for users to spot what they’re looking for, it’s likely to be missed. If you are old enough to have ever seen a newspaper, you’ll notice that all the eye-catching information is on the top half of the page. Of course, that’s what people see first. The same can be said for Web pages. If you want users to see something, place it at the top of your content area.

Give Yourself an ‘F’ The human brain is very, very good at absorbing information quickly. Recent studies (Nielsen, 2006) have shown that most users develop a visual shorthand for quickly ascertaining whether the information that they’re looking for is on the Web page they’re viewing. These studies show that most users develop a pattern for reading pages that is consistent and (if you play your cards right) exploitable. Per the study (Neilson, Jacob ‘‘F-Shaped Pattern for Reading Web Content’’ Useit.com: April 17, 2006 — see http://www.useit.com/alertbox/reading_pattern.html): When a user arrives at a page, there’s usually a fairly large amount of data to absorb. Most users read the headline first the horizontal bar across the top of the page. They then start further down the page and begin another horizontal scan, looking for additional content. Finally, users tend to scroll downward along the left side of the page, picking up the start of any data that runs the length of the page. This standard page scanning pattern (Figure 2-8) can help you position key information in a place that is most likely to be seen. Also note that there are large tracts of the page that are not scanned by most users. Remember the 50 or so percent of the page that you have where you can actually display data? Cut that in half if you actually want that information to be seen. Keep that in mind when designing SharePoint page layouts. A typical layout looks like Figure 2-9. When information gets added to this page, what will users see? Based on the rules shown above, the Main and Left Web Part zones get all the attention, followed by the Bottom (that is, if the bottom makes it above the fold). The Right zone will get the least attention of all.

30

4:12pm

Page 30

Sanford c02.tex

V1 - 08/13/2008

4:12pm

Chapter 2: Web Design 101

Figure 2-8

Figure 2-9

Keeping It Consistent It’s difficult to compare a SharePoint site to a traditional Web site. SharePoint is more interactive, more like a desktop application. Now imagine starting an application like Microsoft Word and finding that the interface changes intermittently depending on what you’re doing. The File menu changes from horizontal to vertical if you’re looking at a page with a picture on it. The Help button requires users to play hide and seek. Spell checking is enabled on some paragraphs but not others. For better or worse, SharePoint’s modular design makes it easy to create applications just like that. The last thing you want is to have users lost in your application. Try to be as consistent as possible when creating page layouts.

31

Page 31

Sanford c02.tex

V1 - 08/13/2008

Chapter 2: Web Design 101 Navigation is an excellent example. Certain screen real estate will always be allocated to getting around. There will be tab navigation, there will be Quick Link list access, and there will be links to My Site or My Links. If you want people to actually visit these pages, make sure all navigation tools are in the same place on every single Web page. There’s also something to be said for using the standard SharePoint page layout formats. They may be boring, but they’re very consistent. A few things that out-of-the-box SharePoint pages (and most modern Web pages) have in common include the following: ❑

A logo is located in the upper left-hand corner, linked to the home page.

❑

Search is available in the upper right-hand corner of the page.

❑

Navigation is available below the logo.

❑

Additional navigation features run down the right or left side of the page.

❑

Content is centrally located on the page.

Do these things sound obvious? They should. Microsoft has spent enormous amounts of time and money to train your users to navigate just such a standardized interface. Yes, you could get creative and wild with navigation and page layout. You could design a Flash or JavaScript based interface that dynamically uses the letters in your company’s logo to spell out the navigational options on your site. You can make your pages as creative and off the wall as you want. You can also pay to retrain your users on how to use the fancy new interface. In a corporate intranet, this will mean a lot of resentful users. On the commercial face of a site, it might mean a lot of frustrated users going to your competitor. Your call.

Making It Fast People hate waiting. Don’t make users wait, or they’ll hate your application. To avoid this, keep a few simple rules in mind: ❑

Keep it simple: See above. Clean, tidy pages load faster.

❑

Put limits on list views: List views are SharePoint’s bread and butter. They do all the ugly little things that I, as an old-school database application developer, got bored to tears by. Adding a column to a Web-based database application would often be a tedious process. Adding a column to a SharePoint list? Easy as pie. Maybe a little too easy. Power SharePoint users are often more than happy to pile data into lists — both more columns and more rows. Whenever a user opens a page with a List View Web Part, SharePoint has to retrieve and format list information for display. The more data that’s displayed, the longer it will take. So when possible, try to keep List View Web Parts small and manageable. There is rarely a need to display every single column in a list, nor is it always necessary to display every single item that the list contains. Luckily, List View Web Parts allow you to pick and choose columns and place limits on the number of list items displayed with each page load. Add a bit of creative grouping and sorting, and your List View Web Part will give your users the data they need without making them wait.

32

4:12pm

Page 32

Sanford c02.tex

V1 - 08/13/2008

4:12pm

Chapter 2: Web Design 101 ❑

❑

Watch your image sizes: This should be a no-brainer, but it often causes otherwise speedy page loads to be sluggish. Modern digital cameras allow for multi-megabyte files. Please remember the following: ❑

Resize images before they are uploaded to your SharePoint site, or your users will download that multi-megabyte file every time they visit your page.

❑

Resizing the display size of an image in SharePoint Designer does not change the image file size, but only the amount of space that the image takes up on the user’s screen. Browsers also do a notoriously bad job of trying to cram pixels together to fix hard-coded image sizes, making your photographic masterpiece look blocky and blurry.

❑

It’s common for both designers and users to reference pictures in a SharePoint Picture Library for image display. This is a great tool to empower users to display images on your portal, but once again, be aware of image sizes. Displaying a 5 megabyte image from a Picture Library is no faster than displaying an image that you placed on a page using SharePoint Designer.

Watch out for Web Parts that you don’t control: MOSS has several great new Web Parts that allow for the display of information from all over the Web. RSS Viewer Web Parts, for example, can display content from feeds anywhere on the Web. Realize that if the RSS feed you added is slow to respond, your Web page will be slow as well. So, though it may be great to show a weather feed on your site’s home page, users may bear the brunt of slow page loads as a result. Other Web Parts, such as Key Performance Indicators and Data View Web Parts, can suffer from the same problems. Each of these Web Parts can directly access lines of business data. With luck, you’ll have more control over the gathering of internal data. If it takes more than a few seconds to access that data through a Web service or a stored procedure, it’s going to take SharePoint the same amount of time when it pulls the data for your Web Part, plus additional time to process and format it.

❑

Keep big items out of traffic: Sometimes, loading extremely large amounts of data is unavoidable. Try as you might, you or one of your users will be asked to show a list view that returns a horrific number of rows and columns. Or it will be absolutely essential to display key business data that takes 20 seconds to retrieve. The goal in these cases should be to limit the impact on your users. Users will wait 20 seconds once for a page to load. They’ll get frustrated if they have to wait for the 20-second page load fifty times a day. So keep Web Parts, images and data-displays that are data intensive off of your home page or other commonly accessed pages.

❑

Cache when possible: Think about it — most of the files that SharePoint uses to display each page are identical. Your company logo, for instance, is often stored in an image library. When each page is loaded, the SharePoint page rendering engine makes a call to the database. In many cases, this can mean retrieving information from another server. Caching can be enabled in a few different ways. One of the easiest to implement is a minor change to the web.config file for your SharePoint application. To enable this feature, follow these steps:

1. 2.

Find and open the web.config file using notepad or another text editor. Then, find the line that starts with: