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.
|
What you need to know about Content Organizer (First of three parts)
By Chris Geier
The Content Organizer is one of the most interesting and yet least-known features in SharePoint 2010. Content Organizer is a new document-routing feature that is an evolution of the routing engine that (believe it or not) did exist in SharePoint 2007 for use in the Record Center. SharePoint 2010 extends, enhances and makes this functionality more broadly available. But before you jump into using it, here are some things you need to know.Perhaps the most important choice you can make when setting up the Content Organizer is in the settings page. This is the “Redirect Users to the Drop-Off Library" setting.On the surface, the idea is simple. When you have the box selected, all uploads are going to be automatically temporarily placed in the newly created drop-off library, at least behind the scenes. This means that when one of your users is uploading a document, the dialog/property window they are presented with is the one from the drop-off library. This dialog is where the user will enter in all the metadata associated with the document he or she is looking to upload. After all information is added, the information is analyzed to make routing decisions, rules are applied, and the document is routed. The user is then presented with a dialog box that gives the URL of the document’s final location.This may sound pretty straightforward, but there are a few things to keep in mind about the little gotchas that may be waiting just underneath the surface. First, the Content Organizer only works with content types that are document content types or are derived from them. So, if you have created custom content types or wish to use this with list items, you are out of luck.Next, if you have used custom local columns in your document library, these will not be displayed in the dialogue box users are presented with. Let’s take a look at an example.I have a PO document library on which I want to enable some content organizing. Within this document library, I have the PO content type and associated site columns, but I have also defined some additional columns in that library (not site columns associated to the content type). When a user is uploading a new document to the PO library, these custom columns will not be displayed in the upload dialog box because the dialog box is actually pulling the data from the drop-off library. If I need those columns to be displayed, I must make them site columns and bind them to the PO content type.Even though the local columns are not displayed, the routing of the document will not be affected, because you cannot make routing decisions on local document library columns. However, if I am still expecting that information to be collected, I will be disappointed and will have to make other plans to collect the information. This can be especially problematic if those new columns of mine are marked as required.At this point you may be asking yourself, “Self, can I just uncheck that box and get around this?” If the box is not checked, we can still take advantage of routing. However, to do so, all items you want to route must be uploaded only to the drop-off library. When I upload documents normally to my PO library, no routing will take place. In some organizations, this may be a great solution; in places that take advantage of content types and the Content Organizer, though, the situation may get unwieldy.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.
|