Branding SharePoint
By Ryan Keller
Your organization has successfully deployed SharePoint, and you and your colleagues have learned all about its document-management, collaboration and content-management features. But somehow you just can't shake the feeling that the look of such a powerful product leaves a little to be desired. Apparently management feels the same way, because now it's time to apply a little bit of style to SharePoint to spice it up a little, and maybe give it a look that's a little more in line with your organization's branding. So how do you go about this?There are a few options for branding a SharePoint site, ranging from the simple to the complex. In the simplest terms, you can apply a company logo to the SharePoint portal and call it a day. For some organizations, this may be enough to keep management happy, but what are the other options available?There is the theme engine, which essentially applies a color skin to the out-of-the-box SharePoint site. If none of the themes that ship with SharePoint work for you (and there's a good chance they won't), you can always create a custom theme using Office 2007 or 2010 and upload it, but even that might not get you the end results you want.Finally, you can dive in and do some custom branding yourself. This in itself is a bigger topic than a single article can cover, but the theory behind this point is the main focus of this article.Generally speaking, when you start branding SharePoint, you want to have an end goal in mind; that is, you should have an idea of what your branded site will look like. The best way to start thinking about this is to look at your organization's branding and think about how it can be applied to SharePoint. Think about the colors you generally see on company letterhead, the company's public website, the company logo, and other branded applications you may use on a day-to-day basis.Once you have a good idea about the color scheme, spend a little time surfing the Web for some additional inspiration, and if your boss catches you doing this, at least you can honestly say you're working! Maybe there are a few sites that have a certain look that you want to replicate. If this is your first time branding SharePoint, it's best to not get too crazy with your design, but whatever strikes your fancy can generally be replicated one way or another.#!Now that you have your inspiration, the next step generally is to create a mockup of what the end site will be. This will be helpful later for saving off any custom image files you want to use in the design. Think about the major components of SharePoint: You'll need to account for the ribbon interface; a header area, the top navigation and the left navigation; a place for the search box; and finally the main body area for content. You can use whatever image software you feel most comfortable with.This article assumes you have done your design and have enough CSS and HTML knowledge to get going. If you have experience with Web design in the past, some of what you know will come in handy, but SharePoint can sometimes be a tricky beast to style. This is because there is a lot going on behind the scenes to render the final HTML output you see in your browser window. Tracking down each little piece to which you’ll apply your custom styling can sometimes take a little extra work, but the end result will be well worth it.Most of the look of SharePoint is driven by three things: the master page, a page layout, and cascading style sheets. The master page acts as the skeleton of the page, and holds the position of the major components, such as the navigation areas, search, and the ribbon, and controls where the main content of the page will go. The page layout fits within a master page and controls how the main content of the page will look. Finally, CSS is used to add images, colors, text styles, and some positioning to the elements in the master page and page layout.When you are ready to start your custom branding, you will generally be using SharePoint Designer 2010 to create your custom master page, page layout and CSS. But where should all these components live? Master pages and page layouts live in the Master Page Gallery, which is accessed from the Site Settings Screen (Site Actions > Site Settings > Master Page and Page Layouts). CSS files, along with any custom images that accompany it, go in the Style Library (Site Actions > View All Site Content > Style Library), generally within a folder within the library to keep everything nice and tidy. If possible, you should try to do your branding in a development environment and deploy everything to the production server later.In SharePoint Designer, you'll start by creating a new master page. You can either start by copying one of the out-of-the-box master pages—v4.master or nightandday.master as a starting point for your new design—or you can create one from scratch. SharePoint requires several placeholders and controls to be present on a master page in order to render properly, so if you are starting from scratch, it is generally recommended to use a starter master page developed by members of the SharePoint community.For example, SharePoint MVP Randy Drisgill has an excellent starter master page with all the necessary placeholders already on the page. You can wrap these placeholders in your custom HTML and styles.#!As you build out the custom HTML in the master page, you will generally simultaneously build out the custom CSS that will determine the look and feel of the site once it renders in the browser. Once this is all finished, you can start building out any custom page layouts that you need, such as creating pages with different column layouts for various types of content. With a handful of images and some CSS knowhow you can really change the look of SharePoint pretty quickly.Two valuable tools you may end up using extensively are the IE Developer Tools (built into Internet Explorer), and Firebug, an add-on for Firefox. These tools can be very helpful to use when trying to track down a specific style to override within your custom CSS.Once you dive deeper into branding, you might start to work with content types and site columns, which allow you to add various fields to your pages. You can also add Web zones and Web Parts directly to your page layouts for even more customizations. The possibilities are nearly endless.When your design is done, the master page and page layouts work together, and you are happy with the final result, the next step would be to get the design applied to your production site. There are a few ways to do this: You could manually upload the master page, page layouts, CSS and image files, or the other (and more preferred) option is to have a developer package the files up into a solution file (a WSP file) and deploy it to the server. This topic is also out of scope for this article, but there is plenty of information out there on the Web.Hopefully this gives you a good start to planning out and implementing your custom SharePoint design when the boss comes around and asks you to give the SharePoint site more pizazz. Until next time, happy branding! Ryan Keller is a consultant with SharePoint911.
|
More on the Content Organizer in SharePoint (Second of three parts)
By Chris Geier
In my previous article, I talked about the affects of the “Redirect Users to the Drop off Library” setting. This time I’ll dig into some more things you should know about the Content Organizer, including folder partitioning, managing duplicates and setting up rule managers.The Content Organizer is not just about moving content from library A to library B, or even between folder A and folder B. It can also help you partition those libraries and folders based on their sizes.How do you divide up containers, and how do you set thresholds as to how many items should be in each? The Content Organizer can help with this partitioning. As you can see from the Content Organizer settings image below, you can set thresholds to prevent destinations from getting too large in any one container:This setting allows you to specify your individual site threshold for each library or folder before it creates a new container (folder). You can also specify how you want the folder named. This does not have to be a permanent condition; rather, it can be a way of alerting you that you may need to do some reorganization of different folders or libraries manually.Managing duplicatesYou may be wondering what happens if in all this routing there are duplicate file names. Well, not only can you control the number of files going into your libraries or folders, but you can also control file duplicates. There is a provision for this: The Content Organizer will simply append a unique character to the end of each duplicate file as it writes the file to the destination folder or library.#!Rule managersBy now, you are blown away by the Content Organizer and can’t wait to get out there and start experimenting with it in your environment. But don’t forget about your rule managers. See the figure below for how this may look in the Content Organizer settings screen:These are the people who can be designated managers, and can come in and modify the rules you have set up so you don’t have to do it all yourself. These are also the people who can be notified via e-mail when files are being uploaded and are not matching rules, and thus placed in the drop-off library. Not only that, but if the file is placed in the drop-off library and you are expecting someone else to take care of it, you can also have it e-mail the rule managers if the file has been left there for a specified number of days, kind of like a reminder: “Hey this file is still over here waiting.”This is important because when a file does not match rules and is placed in the drop-off library, it is assigned unique permissions. Only the person who uploaded it and the rule managers will be able to go into the drop-off library and edit the metadata on that document, thus allowing it to be resubmitted to the Content Organizer—hopefully, this time, with enough information to match a rule.In part 3, I will look at Content Organizer and permissions, and sending to connections.Chris Geier is the community manager for K2, and is a participant in, and advocate for, the SharePoint community. He is a 15-year veteran of the technology industry and specializes in all things Microsoft. He was introduced to SharePoint in 2001 while working for Microsoft services.
|
Keeping things simple to ensure SharePoint success
By John Ross
People often ask about tips for getting started with their SharePoint project, and usually my advice is to keep things simple and focus on what SharePoint does best (and avoid what it doesn’t do as well). Normally whenever these words come out of my mouth, I’m very aware of how silly it must sound to someone because it sounds rhetorical. But the fact of the matter is that failure to follow these two little tips is the reason why most SharePoint projects jump the tracks.The K.I.S.S. principleIf you aren’t familiar with the acronym K.I.S.S., it stands for Keep It Simple Stupid/Silly/SharePoint. The solution to any problem should be reasonably simple, but just for clarification that doesn’t mean that I’m advocating a specific way of solving the problem. For example, we’ve all talked to stakeholders who have some problem to solve, and we’ve probably all heard (or proposed) solutions that are the technical equivalent of a Rube Goldberg machine (i.e. www.rubegoldberg.com). In these cases, you might address the original problem but would likely end up with long-term supportability issues.If you happen to find yourself in a position where a complex solution has been proposed by someone (or maybe you’ve been the one who proposed it), the best thing is often to step back and look at the original goal. Many times the answer is to improve and streamline the process (executives love stuff like that!), or maybe it would be possible to just make the technical solution less elaborate so that you’d still get business value but not the perceived “perfect world” solution. In my experience, it is okay. Remember that you can always enhance functionality in the future, but it is far more difficult to dial back complexity once it has been implemented.If you ignore the K.I.S.S. principle, you run the risk of delivering an overly complex solution that might be difficult to support and use. This can lead to loss of trust by your stakeholders. Start simple and create things that create real value for your stakeholders. If you do it right, they’ll ask you to do more, which is a very good problem to have! Focus on what SharePoint does best (and avoid what it doesn’t do as well)It seems like obvious advice to focus on what SharePoint does best and avoid what it doesn’t do so well. But when you are starting a SharePoint project, this could mean the difference between success and failure. You should be honest and ask yourself if you (or your team) really understand SharePoint well enough that you could be confident to propose a solution. And if it turns out that there’s a gap in your understanding, that’s okay too. We’ve all be there. SharePoint is a big product. But there are plenty of ways to close that gap, through books, training, online resources, or even getting some good help from an experienced external resource.One last thingThe other piece of advice that I normally tell people is to “avoid doing things that are hard.” Let me give you an example: We’ve all been in meetings where a business user asks for something, and the technical team looks at each other with pure horror, but then for some strange reason someone says to the user, “Yeah, we can do that.”This advice isn’t intended to mean that you should never implement anything difficult on a SharePoint project; the real moral is to pick your battles. Depending on your experience level of you or your team, what you consider difficult is going to vary. The most common issue I see is that a team that is experienced with other technologies, usually .NET, takes on a SharePoint project and then quickly realizes that things are more complex and nuanced than they expect. Usually one of two things happens: They either try to simplify functionality, or they forge ahead and implement something that many times that wouldn’t be considered a “best practice.”The reality is that every project is going to require that we tackle some difficult requirements. The analogy that I usually use to describe this is that back when I was in college, I’d try to be mindful of the courses that I was registering for. I knew that as I got closer to graduating, some of the courses I needed to take were going to be very difficult. I tried to spread these difficult classes out so that I never took more than one or two at a time and balanced them out with much easier classes. You can do the same thing with your SharePoint project: Split it up into several phases and try to spread out the more complex functionality so that it doesn’t become too overwhelming. Another thing to consider is that the complex functionality often takes more time to implement. Spreading that functionality into phases allows stakeholders to see things sooner. It normally makes a project go smoother when functionality can be rolled out for people to start using sooner as opposed to later. This approach also makes it easier to make small course corrections along the way as people start to use the functionality, which tends to lead to a better product in the long run.It seems like it wasn’t that long ago that I did my first SharePoint project. I’ll never forget when my boss walked past my cube, clapping his hands and shouting, “Who wants to do SharePoint?” That person ended up being me. Things have turned out pretty well, but I learned a lot of hard lessons during that first project—many of which I’ve shared in this short article.I’d be interested to hear from readers about these tips or others that they give. You can find me on Twitter: twitter.com/johnrossjr.John Ross is a SharePoint MVP and Senior Consultant with SharePoint911. He has over eight years of experience implementing solutions for clients ranging from small businesses to Fortune 500 companies, as well as government organizations. John is coauthor of the books “Professional SharePoint 2010 Branding and User Interface Design” and “Real World SharePoint 2010: Indispensable Experiences from 23 SharePoint MVPs.” Visit his blog at johnrossjr.wordpress.com.
|
Writing the right requirements — Part III
By Eric Riz
This is the third and final article in my series on “Writing the Right Requirements.” (Read Part I and Part II if you haven't done so already.) If you have been reading this series, you have learned about engaging the business unit, defining a user community, and creating a phased approach to your SharePoint project requirements. Thank you to those who have reached out and provided feedback on their thoughts and successes; I look forward to receiving more notes and meeting some of you at SPTechCon.This article focuses on strategies toward effectively creating and documenting your requirements into meaningful, tangible, actionable statements. Note that I have written this from the perspective of deploying portal functionality to the business first.A common practice in requirements sessions is to get the team together and to simply talk through how your existing portal or intranet operates, while an analyst sits in the corner and furiously attempts to capture the information. Though this approach is unstructured and takes a strong project manager to control the session, it can uncover some valuable information on the high-level needs you’ll want to build into SharePoint. The difficult part will be documenting the information in a format to appropriately leverage the information and have it be useful in the overall process.In order to have meaningful and result-driven requirements sessions, follow these steps to success:Plan: The adage “measure twice, cut once” is relevant when planning and executing requirements sessions. Spend time measuring the needs of business users and the strategic objectives the business wants SharePoint to provide. Create a schedule that shows when and where participants should meet, the details of the meeting, and the anticipated outcome for each session; also, be sure to invite participants well in advance to ensure their availability.Finally, when planning your meeting, set each session up for no more than two hours. Enforcing the two-hour rule ensures that participants are fresh and remain interested in the conversation.Discuss: Start the session by outlining your objectives and expectations to the group. Show some sample portals that have been developed in SharePoint (e-mail me for screenshots) to build excitement for what you’re about to undertake. Discuss the importance of having transparency in your communication, and that each point is a steppingstone toward a formidable SharePoint solution. Then begin by asking some high-level questions to generate thought and feedback. How will the portal change the day-to-day work completed by staff? How can you best leverage portal functionality to empower users?#!Environment: In order to create practical requirements statements, create the right environment for creative thought. As the PM or team lead, hold your session in a boardroom or conference room with ample wall space; have lots of sharpies and Post-it Notes on hand. Next, divide the room into sections identified as Business Requirements, Stakeholder Requirements, Functional Requirements and Non-Functional Requirements. By preparing the room as such, you’ll have created a structured approach to the creation of each requirement. Participants now must qualify each of their needs into a specific category where it is most relevant. Structure: Invite participants to use one Post-it per requirement, and ask them to use as many words as possible to describe their need. This eliminates non-descriptive answers like “effective” and “user-friendly,” both of which have multiple uses and meanings depending on the author and the person responsible for interpreting the requirement.Interact and Share: When you feel you have an appropriate number of Post-its on the walls (there is no maximum), begin reading through the requirements aloud. By reading them, you are building buy-in and adoption as your participants hear each requirement. After reading 10 aloud, ask if anyone in the room has a comment about what they have heard. Focus on eliminating a minimum of 20% of the requirements due to overlap or lack of necessity; remember that not all requirements are going to be aligned to the project’s focus.Document: With the walls full of Post-its, being documenting the requirements in your tool of choice, such as Excel (though my personal recommendation is to create lists in SharePoint with the appropriate Content Types; use the Business, Stakeholder, Functional and Non-Functional headings described above). Then perform and complete your analysis on the ideas shared and requirements gathered. Remember that not each requirement is going to be possible for implementation. Some may be unnecessary while others may be best suited for another phase or project entirely.Regardless of the documentation format you choose, circulate the information and ensure that stakeholders and end users alike have had an opportunity to review. In the past, I have seen surveys created to measure stakeholder feedback, which was a well-received method of feedback. Once you have feedback and you have categorized your requirements into the appropriate categories, you are ready to begin finalizing your list and moving forward to begin scoping the development effort. Eric is the EVP of Systems Integration for Concatenate, a software firm focused on maximizing SharePoint through product innovation and systems integration based in Toronto. You can reach Eric by e-mail at ericr@concatenateinc.com or on Twitter at @rizinsights. Read his other SharePoint thoughts on his blog at www.ericriz.com.
|
A lesser-known Web Part connection option
By Chris Caravajal
Web Part connections are a popular out-of-the-box feature that enable users to connect Web Parts in such a way that selecting data from one Web Part can automatically perform an action on the data in a connected Web Part.To set one up via the browser, users can simply manipulate the Web Part properties options and connect Web Parts that are on the same Web page. By now, most users are familiar with this feature and incorporate it into their organization’s SharePoint sites. What most users don’t know is that this is not the only option that is available to them. It is the only option via the browser, but if a user opens a SharePoint 2010 Web page in SharePoint Designer 2010, another Web Part connection option is available to them, connecting to a Web Part that is on a different Web page. Once done, users can filter and update data based on the connection.What this looks like in the browser is that when two Web Parts, each on a separate page, are connected, the user clicks on the icon in the “Select” column of one Web Part and is automatically forwarded to the page for the other Web Part. When this redirect takes place, the data in the Web Part is updated based on the item that was originally selected. The behavior is similar to the way wikis are built out, but rather than text being organized this way, we can now do the same with list data. This ability allows for the creation of more complex dashboard and Web Part page solutions. This feature is just one of many additional options available in SharePoint Designer 2010. When working with SharePoint sites, be sure to remember that the browser options aren’t always the only ones that are available to you.For some more information regarding the creation of connections for Web Parts on separate pages, check out this video.Chris Caravajal is a consultant with SharePoint911.
|