Back to description
When many people attempt to take up Microsoft Office SharePoint 2007 (MOSS 2007) as a profession, or even as a hobby, they... more
When many people attempt to take up Microsoft Office SharePoint 2007 (MOSS 2007) as a profession, or even as a hobby, they immediately begin 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 compare 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 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.
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 look 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 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.
... less
Any chapter titled “Web Design 101” is bound to be passed over for more exciting topics. A broad introduction to Web site... more
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 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 five 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 the all of 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.
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.
Now that you have gotten through the first two chapters and explored the importance of design and what types of considerations... more
Now that you have gotten through the first two chapters and explored the importance of design and what types of considerations any SharePoint designer should take into account before actually designing their projects, it’s time to start laying down code. Sort of.
In this chapter, you will get a crash course in general concept design techniques and tips. While you won’t be writing any actual code per se, you will be generating the files needed for the remaining chapters of this book and will see how to take graphic design concepts and put them into practice. Specifically, you will see how to take an abstract idea and begin making it more tangible through your graphics program of choice. In this chapter, you will see these concepts materialized through Adobe Photoshop CS3. While there are certainly many other programs ranging in price (some even free through open source code philosophies), Photoshop is generally considered the standard for graphic design among many Web developers. And, as that product has matured over the years, it has become possible to create almost identical projects on a Windows-based PC as with any Macintosh counterpart. With that in mind, any keyboard shortcut in this chapter will be given both the Windows and Mac versions.
The scope of this chapter is to get familiar with a standard graphic design application and, with that, learn some tricks that can be reused in other projects. You will also get an understanding of some of the SharePoint specific issues that a designer must contend with (such as the placement of certain required SharePoint objects). At the end of this chapter, you may not feel comfortable enough to quit your day job and start earning your living as a professional graphic designer. However, you will have enough knowledge to poke around in Photoshop and be familiar enough with it to make designs that people will take note of. And, more relevant to the scope of this book, you will be able to create SharePoint designs that are above the curve in today’s market.
Most organizations today use their SharePoint portals with one of two main focuses: either to communicate with their employees... more
Most organizations today use their SharePoint portals with one of two main focuses: either to communicate with their employees, partners, clients, or the general public or to collaborate with them. To this end, MOSS 2007 provides different site templates for each focus, each with its own unique characteristics. Today’s designers must have a solid understanding of what site types are available with SharePoint, as well as the design considerations that need to be made for each, before attempting to customize the look and feel of a SharePoint site.
This chapter will focus on the differences between MOSS 2007 publishing sites, which are primarily used to communicate to others, and collaboration sites, which are intended more to facilitate working in a joint intellectual effort.
This chapter will also touch on the various design considerations that must be taken into account when designing for these different types of sites, including what designers must know about master pages and page layouts at a basic level. At the end of this chapter, you will have enough knowledge to determine if your site should be a publishing site or a collaboration site and then make recommendations for the correct technology that should be used in that environment.
Now that you are getting excited about working with a real Microsoft Office SharePoint Server (MOSS) site, you may be asking... more
Now that you are getting excited about working with a real Microsoft Office SharePoint Server (MOSS) site, you may be asking yourself, “How do I actually edit code?” In the good old days of SharePoint 2003, you were pretty much limited to working with FrontPage to edit your sites, which often proved to be challenging as FrontPage hadn’t evolved much over the years. Luckily, Microsoft has effectively ended FrontPage’s lifecycle and in its place, two tools named Microsoft Expression Web and Microsoft Office SharePoint Designer 2007 (SharePoint Designer) have been created. SharePoint Designer is equivalent to Expression Web plus special tools that work specifically with MOSS servers and code. While you can edit your MOSS design code in any text editor, you will find no better way of working rapidly with MOSS than with SharePoint Designer. This chapter will discuss why SharePoint Designer is the tool of choice, as well as covering the ins and outs of using it to work effectively with MOSS.
SharePoint themes are a great way to brand a site as they help you instantly change the look and feel based on your corporate... more
SharePoint themes are a great way to brand a site as they help you instantly change the look and feel based on your corporate identity requirements. Themes are a key tool in the customization of SharePoint sites. This is particularly true for Windows SharePoint Services V3 (WSS) sites, which, unlike Microsoft Office SharePoint Server 2007 (MOSS) sites, are not as easily customized via master pages. Despite their usefulness, themes can be challenging to work with in a consistent manner across SharePoint sites.
This chapter will explain what themes are and how they help you “skin” SharePoint sites. Then it will cover why themes should be used over other approaches. After discussing the “what” and the “why,” this chapter will discuss how to create a theme using the design that was created in previous chapters. It will walk through the steps in how designers can create themes for their organizations with Photoshop CS3 and SharePoint Designer.
When it comes to styling Microsoft Office SharePoint Server 2007 (MOSS), few topics are as important as Cascading Style Sheets... more
When it comes to styling Microsoft Office SharePoint Server 2007 (MOSS), few topics are as important as Cascading Style Sheets (CSS). This is due to the fact that Microsoft relies heavily on CSS’s cascade to allow you to override any out of the box style that they have applied to MOSS. Much of this out of the box style comes from core.css, which is included by default in MOSS. You will learn how to position your own CSS properly to override these MOSS styles. This chapter will also provide a brief overview of CSS, focusing on the areas of CSS that are useful in MOSS. For a more thorough understanding of CSS, check out Professional CSS: Cascading Style Sheets for Web Design (Schmitt, Wiley, 2008).
In the previous chapter, you learned about how Cascading Style Sheets (CSS) work in Microsoft Office SharePoint Server 2007... more
In the previous chapter, you learned about how Cascading Style Sheets (CSS) work in Microsoft Office SharePoint Server 2007 (MOSS). Even though CSS is an important concept in styling MOSS sites, it can only affect the overall look of a site so much. This is equally true for MOSS themes, which was the topic of Chapter 6. Both of these technologies can only affect hiding and showing areas of a design, as well as changing colors and images.
To truly make wide sweeping changes to the user interface of a MOSS site, master pages are the only way to go. This is because master pages can control almost all of the aspects of the HTML that glues all of MOSS together. The difference between using just CSS or themes and making a custom master page is often compared to the difference between just hiring a painter to change the colors of walls in a house and having an architect change the location of walls or even the configuration of the whole house.
In this chapter you will learn how master pages work in traditional ASP.NET applications and more importantly how they work in MOSS. You will also learn how master pages and page layouts differ, as well as how the various parts of master pages are handled in a MOSS site. The chapter will conclude with a tutorial on converting standard HTML and CSS design into a corresponding master page and CSS.
With the release of Microsoft Office SharePoint Server 2007 (MOSS), Microsoft has introduced the Publishing Feature to the... more
With the release of Microsoft Office SharePoint Server 2007 (MOSS), Microsoft has introduced the Publishing Feature to the already impressive array of functionality available to SharePoint sites. Publishing empowers content authors to create their own HTML based Web sites in MOSS using only their Web browsers. Page layouts are not only the mechanism that provides this ability, but they also work together with master pages to create the user interface for all publishing pages. To fully customize a MOSS Web site, designers must have a strong understanding of master pages, which were covered in the previous chapter, and a good working knowledge of how page layouts are created and ultimately utilized in MOSS. By the end of this chapter, you should have a good understanding of what page layouts are and how they are created in MOSS. The chapter concludes with a walk through of creating a welcome page layout that can be utilized to create a home page suitable for the Internet master page design that was created in the previous chapter.
Okay, you have the basic shell set up. You have designed your template and your master pages and styled with CSS now it’s... more
Okay, you have the basic shell set up. You have designed your template and your master pages and styled with CSS now it’s time to get to your content. But a Web site, any Web site, is more than just the shell. Most developers should recognize that, as much work as they put into the architectural design of the site, visitors typically care a lot more about the content. So, as a designer/developer, you must give due consideration to the content that will, in all honesty, be the biggest measure of the popularity of the site you develop. Don’t misunderstand; having a site that looks good and functions appropriately for all visitors is monumentally important. But that is what gets people in to your site. The content is what keeps them coming back.
In the world of SharePoint, Web Parts play an important role as a secondary means of delivering content that is not handled by the typical WSS or MOSS Publishing content. This can, generally speaking, consist of custom made Web Parts or the ones that come as standard components of SharePoint. While there is certainly merit in creating your own custom Web Parts, there is a wealth of power and flexibility available through the out-of-the-box Web Parts that come with SharePoint.
While at a high level, Web Parts may not seem like they fall into the scope of a design book. In a sense, most of this chapter won’t be talking about aesthetics. But understand, good design isn’t all about aesthetics. You have to know what your users want to see and provide them an appropriate way to get it and, ideally, an appropriate and easy way to update it. And, in this regard, there are probably no better tools at manipulating, displaying, and retrieving the content your users want to see than with Web Parts.
So, in this chapter, you get at least a cursory exposure so some of the Web Parts that can really help in the design and layout of the content areas of your Web site. These will include:
Content Query Web Part
Data View Web Part
Content Editor Web Part
Image Web Part
XML Web Part
Page Viewer Web Part
While this is only a small sampling if the out-of-the-box Web Parts available to you, these will hopefully show you how powerful and flexible the Web Parts can be and how much a crucial role they will play in the designs you create.
The two different versions of SharePoint give designers different navigation controls. With WSS 3.0 (aka the free version... more
The two different versions of SharePoint give designers different navigation controls. With WSS 3.0 (aka the free version) you get simple navigation controls where as with MOSS 2007 you get the extended versions of the navigation controls.
Organizations that have seen the advantages of MOSS 2007 will get major benefits when using MOSS 2007 navigation controls on their sites. With MOSS 2007 designers and developers can build upon the navigation controls much faster and get better results. For those of you using WSS 3.0 no need to worry, this chapter details what you can accomplish with the simple WSS 3.0 navigation controls.
This chapter first details the WSS 3.0 basic navigation controls by explaining how to use the Top link bar, Quick Launch, and the Tree view menus and also by covering how each of them can be customized. Most common tasks, such as enabling SharePoint menus to have sub-menus, adjusting fly-out menu settings, orientation, style and hiding certain links from non-administrators are also covered in this chapter.
The second half of this chapter focuses on the MOSS 2007 navigation controls by first detailing how to enable MOSS 2007 navigation for your non-publishing sites and then how you can setup your sites.
Google has ruined search.
Not just Google search, Yahoo! search and any other Web-based search engine that you’ve ever used... more
Not just Google search, Yahoo! search and any other Web-based search engine that you’ve ever used. Ruined it for business users, for SharePoint administrators, and for portal and Web designers.
Let’s say, for instance, that your significant other really likes fondue. So, on a little weekend jaunt to Des Moines, you’re trying to surprise them with some melted cheese and a nice bottle of wine. You go to your favorite search page and type in “Best Fondue Des Moines” and you get back a list of 18 restaurants. Odds are, you’ll end up going to the restaurant, have some darn fine cheese and chocolate-covered strawberries, and thank the fine people of Google/Yahoo!/Microsoft Live for pointing you in that direction and getting you a few points with your boyfriend/girlfriend/spouse.
An unmitigated success for Web-based search, right? The search engine found exactly what you were looking for, right? Not necessarily. There’s a dirty little secret in the whole multi-billion-dollar-a-year search process. How can you be sure that you really found the best fondue restaurant in all of Des Moines? What makes it the best? Does Google factor in meat quality or the quality of the service? Of course not. Do they rank the wine lists and the wait times? No. Do they have an index of all your likes and dislikes? Well, knowing Google, they probably do. But as of today, most search engines simply catalog the number of times that Web pages list that restaurant with the words Best, Fondue and Des Moines, run it through a fancy algorithm, and then return the list of links. You’re relying on the wisdom of the all the people who make Web pages about fondue to tell you which restaurant should be classified as the “best.”
In the vast majority of cases, you’re going to be more than happy with the result. The search engine you used may or may not have pointed you at the best fondue in Des Moines, but you still had a really good meal and impressed your date, so you can go on thinking that Yahoo! magically read your mind, calculated all the factors, and delivered exactly what you asked for. As with horse shoes and hand grenades, sometimes close is good enough.
Business search requirements are different. In some ways, enterprise search would seem much easier to calculate. Your company doesn’t need to index the entire Internet. After all, wouldn’t it be easier to run the numbers on a 30 Gigabyte pile of documents rather than hundreds of Terabytes? That, unfortunately, is not necessarily the case.
The problem lies in two areas: accuracy and the availability of resources. Let’s do the same thought experiment again, but instead of Best Fondue Des Moines, say you want to find your 2006 Q4 Southeast Sales Forecast. Replace that “boyfriend/girlfriend/spouse” with “really demanding boss.” You go to your SharePoint portal, crack open your Search Center page, and type 2006 Q4 Southeast Sales Forecast, which returns back a list of 30 documents.
The first question that you have to ask yourself is this: How accurate was my search? Odds are that your boss knows exactly which document that they’re looking for. If all goes well, you may have a pretty good idea yourself. Hopefully, you can spot the document in the first few entries, send it to your boss, and avoid their wrath for another day. In this case, you don’t need a hand grenade, you need a sniper rifle.
Another issue with SharePoint search is that you don’t have the resources that Google/Microsoft/Yahoo! have. No, this isn’t about the billions of dollars or the squadrons of Ivy League math geeks. The resources in this case are countless millions of people that make Web pages every day, cross linking between corporate sites, private sites, blogs, and photo collections of people’s cats. Each search engine bets on the fact that high-quality information gets more attention than low quality information does, and assigns a ‘page rank’ accordingly. The pages that are unlinked (the ‘dark Web’) are left out on any search results.
Most SharePoint sites have at most, a few thousand users. There may not be the critical mass of links needed to build significantly affect between the documents on a SharePoint portal. And unfortunately, there is no room for a ‘dark Web’ on a SharePoint portal. Every document may be the single most important bit of information for the company at a given point in time.
That being said, let’s go back to our thought experiment, the one with the demanding boss. How can you be sure that you pick the right document? How can you make it easier for the people who use your portal find the information that they’re looking for?
In Chapter 1 you had a brief introduction to accessibility as it relates to Web design. You saw a little bit of the reasons... more
In Chapter 1 you had a brief introduction to accessibility as it relates to Web design. You saw a little bit of the reasons why accessibility should matter and some of the potential consequences of not taking it seriously. But this exposure to accessibility was meant to be merely a cursory overview of this critical element of Web design. It wasn’t meant to be a truly deep-dive approach; that is what this chapter is for.
In this chapter, you should hopefully come away with a much more solid understanding of what accessibility means, how it affects today’s Web design, how SharePoint measures up, and what you can do as a SharePoint developer to make things better.
As part of this last point, you will be introduced to some free tools that are available that, if used properly and for what they were intended, can really move your SharePoint installations much closer to accessibility compliance. Will you be Priority 3 compliant (don’t worry; you’ll get to know what that means a bit later in this chapter)? Probably not. But at least you will know where the shortcomings are and be able to talk intelligently about them. And maybe work toward new solutions that can help figure some of these problems out. After all, 100-percent accessible design is good for everyone.
One of the selling points of any portal system, SharePoint included, is that it can create a full Web application for you... more
One of the selling points of any portal system, SharePoint included, is that it can create a full Web application for you out of the box. Sure, you have to install it and configure it but, once you have done that, you have a full system up and running, complete with things such as blogs, wikis, and message boards. And this is definitely true with SharePoint. But what can be forgotten or overlooked is that SharePoint can be, and probably should be, a starting point for your Web application. This book’s intent is to start with a preconfigured installation of SharePoint and show you how to customize the look and feel to meet business requirements (branding) and accessibility compliance. As a SharePoint developer, you need to understand what SharePoint is really good at and where it needs your help. This book aims at highlighting these things with regard to the interface design of your portal.
Out of the box, SharePoint does an okay job of providing an interface for your site. It is, after all, a portal package and, as such, should provide at least a skeleton for the sites you create. But accepting that is like accepting a new car without a radio. Or air conditioning. Or power steering. Or cruise control. And maybe that is okay for some people. After all, that car will get you from point A to point B, which is the basic requirement of a car. And, like the car, the initial shell will serve the underlying purpose of SharePoint as a Web portal. However, like the car comparison, you’ll probably feel better about the ride if you upgrade. And, fortunately, SharePoint was built so that it can be fairly easily “upgraded” if you have the desire and knowledge. Buying this book is a pretty good indicator that you have the desire. After reading it, you will have the knowledge as well.
So what might be helpful now, possibly as a future reference in going forward in your own projects, is to have a summarized list of the ideas presented in this point so that you can make sure they get due consideration in the design aspect of the SharePoint sites you create. To this end, they will be organized as checkpoints (but will not necessarily follow the chapter order of this book) so that you can think through them in a linear fashion and maybe quantify the design aspects of your own projects.
by John Ross
A number of very important topics have been covered in this book relating to professional SharePoint design... more
A number of very important topics have been covered in this book relating to professional SharePoint design. Your head is probably filed with ideas that you are ready to implement as soon as you finish this book. You have probably come up with an idea for a design and even have an idea about how to make it. Before you run off, there is still one big question remaining: How do you implement your design/brand into production? Better yet, how should you implement your design/brand into a production environment?
This appendix will discuss the final piece of the design process called deployment. You might be thinking “Isn’t this a topic for developers?” The answer to that question is yes; traditionally the topic of SharePoint deployment is covered in texts for developers and administrators. But this is exactly why the topic of deployment is important to designers; the way that the design elements for a SharePoint site are created will directly impact both developers and administrators.
Specifically, this appendix will explore the various options available for deployment of design elements and the pros and cons of each option and how it can affect your SharePoint implementation now and in the future. And no discussion on deployment would be complete without mentioning file customization, including what it is and why it matters to you as a designer. Best of all, this appendix will give you some perspective into how the other members of your team might be thinking and help to shed some light on their world.
Purchase Before purchasing this product, please be sure you have met all software and system requirements, and that you understand any limits placed upon its use.
Return Policy Wrox Chapters on Demand are non-returnable and non-refundable.
Reader Software Wrox Chapters on Demand are offered as PDFs, and they must be viewed using the Adobe Reader. If you do not have the Reader installed, it can be downloaded for free at Adobe.com.
Test Download As Wrox Chapters on Demand purchases are non-returnable, it is advisable that you test your system and software configurations with a free sample download before you place an order.
Usage Rights for a Wrox Chapter on Demand File Any Wrox Chapter on Demand product you purchase from this site will come with certain restrictions that allow Wiley to protect the copyrights of its products. After you purchase and download this title, you:
If you have any questions about these restrictions, you may contact Customer Care at (877) 762-2974 (8 a.m. - 5 p.m. EST, Monday - Friday). If you have any issues related to Technical Support, please contact us at 800-762-2974 (United States only) or 317-572-3994 (International) 8 a.m. - 8 p.m. EST, Monday - Friday).
Related Books