Category Archives: Ricardo Wilkins

Use of a Touch Tablet for SharePoint Planning

You may also be interested in:


Editor’s note: Contributor Ricardo Wilkins is a Solution Architect for Blue Chip Consulting Group. Follow him @ricardo303

As a SharePoint consultant, I’m often involved in whiteboard sessions where some aspect of SharePoint planning is being discussed and documented. This process can be facilitated in many ways, and with many tools, some of which may be more effective than others. As a happy owner of a Surface Pro Windows 8 tablet PC, I’m starting to explore new ways of using it to enhance the value of the consulting that I provide to my clients.

Ruven Gotz (SharePoint MVP and author) has talked and written in detail about how he uses mind mapping tools in SharePoint planning. But with the emergence of more Windows 8 tablets, I thought it would be useful to discuss it as it relates to creating these diagrams on a touch device. Traditionally, OneNote has been my tool of choice for free-hand drawing with my tablet PC pen, but I’m beginning to explore finger-friendly mind-map diagramming software similar to the tools Ruven recommends.

There is certainly a different experience when no mouse is present, and objects are dragged onto a canvas with fingers rather than pointers. It can also be useful to pinch for zooming in and out of the diagram, giving more close-up detail, or getting a birds-eye view. And with the inclusion of a pen, it could be argued that you get the warm-fuzzy feel of writing on a traditional whiteboard with dry-erase markers. The question is, could this new touch-enabled way of diagramming make the planning process a little more dynamic and fluid than traditional whiteboard or keyboard/mouse methods have in the past? And if so, would more of our customers be interested in planning this way?

The following video shows an example of using the Surface Pro tablet PC with Mind Map software to diagram a Content Type planning process. Lemme know what you think, or join the discussion of this topic over at SharePoint Community. Enjoy:

Useful phrases for fighting SharePoint-Sucks-Syndrome

You may also be interested in: O’Reilly - SharePoint 2010 at Work


Editor’s note: Contributor Ricardo Wilkins is a Principal Consultant and SharePoint Practice Lead for Improving Enterprises. Follow him @ricardo303

Many organizations face the challenge of good SharePoint adoption due to the battle of fighting the SharePoint-Sucks-Syndrome (not to be confused with Paul Culmsee’s SharePoint Fatigue Syndrome). SharePoint-Sucks-Syndrome is a debilitating illness that includes the lingering misconception that current-day SharePoint is no good, simply because of bad experiences with previous versions (read SharePoint 2003). Most of us know that SharePoint has improved with leaps & bounds over the past few years. But if you have to work among, or consult for, those who are still suffering from the destructive symptoms of this disease, : ) here are some great affirmations and other useful phrases to help people feel better about their SharePoint experience:

“Put some MOSS on it…”
This phrase was thrown around a lot in one of the offices I used to work in – whenever there was some business process that needed to be improved, or some application that wasn’t quite doing what it needed to do, or if in general something just wasn’t going well, we’d say “Put some MOSS on it!” We were of course talking about Microsoft Office SharePoint Server 2007, and that was our way of saying that using SharePoint could make any situation better. That’s right – to us, SharePoint was a hammer, and everything else was a nail. : )

“…the intranet site…”
I long for the day when SharePoint is such a pervasive platform that we actually stop using the word “SharePoint” to describe our use of it. This phrase helps bring that day closer. When you’ve placed the latest information about the upcoming office event on the homepage of the intranet portal, don’t say “the latest info has now been posted to SharePoint…” Unless you have to make the distinction between the SharePoint intranet and some other intranet available in the office, try to just focus on the great content you’ve just provided, and the convenient and universal access that an intranet provides, without mentioning the irrelevant details of the platform hosting the content. This is even more important if your colleagues have had bad experiences with older versions of the SharePoint portal – now suddenly the value of your content is not quite as enticing because a user is suffering from the thought that they’ll have to battle the platform to get to your content.

“…the application…”
This phrase also helps get us closer to the day when SharePoint is just an assumed platform. It also helps get us closer to the Age of the Devs when there’s more focus on the effective applications built on SharePoint than there is on the infrastructure concerns surrounding SharePoint. If I build, for example, a .NET desktop application for managing customer accounts, I usually give it a cool name, deploy it to the users, and from that point on everyone uses my cool name when they refer to it. No one ever says “be sure to add that new customer to our .NET 3.5 Smart Client app”. So if I build the same application using a custom web part, or an InfoPath form, or some custom SharePoint Lists, what’s the value of mentioning that the application is hosted by or delivered using SharePoint? Particularly in an age where more of our everyday applications are simply Software-as-a-Service, the details of what’s powering that Service should become less and less important.

“It’s not DESIGNED to do that …”
Sometimes folks suffer from acute Attitude issues when SharePoint doesn’t do something that they think it should. Let’s take the out-of-box Blog feature, for instance. Some users can’t understand why SharePoint blogs don’t do every cute little feature that they’ve seen done on their favorite blogging platform (a platform which, by the way, probably ONLY does blogging). Sometimes you’ve got to explain to them that SharePoint isn’t designed to do all the things you’re expecting in this case – SharePoint’s goal was to give you a basic blog to get you up and running, not to compete with every other blogging platform in the world. And there are certainly plenty of other examples of this across SharePoint’s functionality. With that being said, can you buy a 3rd-party add-on to get the functionality you need? - Probably. Can you custom-code the functionality you need using SharePoint as a development platform? - Absolutely. Can you realize that apparently having a blogging platform with all the bells and whistles is important for you and your organization, and probably means you should go invest in a best-of-breed blogging platform, while at the same time admitting that SharePoint is still useful for all the 900 other things you do in your organization? – I hope so.

“I gotta have More SharePoint!…”
In other words, tell them the Cowbell sent you… : )

So, what phrases do YOU use to fight SharePoint-Sucks-Syndrome?


Deploying a Visual Web Part to your Remote-Hosted SharePoint Site using Visual Studio 11 (Dev Preview)

You may also be interested in: CloudShare


Editor’s note: Contributor Ricardo Wilkins is a Principal Consultant and SharePoint Practice Lead for Improving Enterprises. Follow him @ricardo303

The Developer Preview of Visual Studio 11 is now available, and I’ve been exploring its new capabilities, especially as it relates to SharePoint development. Two of the great new features in Visual Studio 11 that I’ll discuss are

  • the ability to deploy visual web parts as sandboxed solutions
  • the ability to automatically deploy sandboxed solutions to remote SharePoint sites

At the end of this article, I’ll explain why I think this is such a big deal. But for now, I’ll walk thru the 3 easy steps necessary to take advantage of these features. In my case, the remote SharePoint site I’ll use is my Hosted SharePoint account.

1) Create your visual web part

Although this article is not an attempt to show how to create a visual web part, I do want to point out what’s different when creating a new Visual Web Part project. First, you select your New Project as you normally would:

After naming your project and hitting OK, you’re presented with another familiar screen, but this time with a new twist:

If you look carefully you’ll notice that, unlike Visual Studio 2010, we now have the option of creating our Visual Web Part as a sandboxed solution. Awesome! I then proceed to create my web part. In my case, I’ll be making a web part version of my Dog Lover’s Application that I had created in a previous post using InfoPath:

As you know, one of the key advantages of the visual web part is that I no longer have to hand-code a lot of HTML in order to create the visual aspects of my web part – I can take advantage of the ability to drag-n-drop controls onto the canvas, which greatly speeds up development time.

2) Deploy & Activate

Once I’ve coded everything and tested locally, I’m now ready to deploy to my hosted SharePoint site. It couldn’t be easier. I begin by using the Publish option in the Build menu:

In order to publish, I need to tell Visual Studio 11 where my site is located:

After providing the URL and necessary credentials, Visual Studio 11 proceeds to conveniently upload my WSP to the solution gallery of my site, as can be seen in the Output window for my Build:

It then takes me directly to the solution gallery, because I now need to manually Activate the new solution that has been deployed:

3) Insert your web part

Now that my web part is deployed and activated, I’m ready to add it to my site:

After finding it in the web parts gallery, I can add it to the front page of my SharePoint site:

Interested in seeing the web part in action? Here’s a short 30-second video clip showing the web part behavior in all its glorious simplicity. : )

So what’s the big deal?

Today, we can add sandboxed solutions to remote sites only by manually uploading our WSP’s to the site’s solution gallery. And if we want to deploy a visual web part to a remote site, we’d need to install SharePoint Power Tools in order to do it – Visual Studio 2010 does not allow it out-of-the-box. So, the addition of these two features together in Visual Studio 11 adds a great bit of flexibility and convenience to our SharePoint development experience. And because of this, we remove yet another layer of complexity to using SharePoint as a development platform, thus increasing the adoption speed for new developers. I can also see a lot of value for small businesses using hosted SharePoint sites like or Office365 – now they can quickly and easily add powerful web part solutions to their site without needing complex on-premise installations.

Until Visual Studio 11 is released, I guess we’ll all have to do it the hard way for now. : ) But based on what I’ve seen so far, I think it’ll be worth the wait.

SharePoint Professionals: Who Do You Serve?


One of my good friends from college recently started an organization that provides a mobile produce store for communities in Chicago’s West Side who don’t have access to fresh produce. They’re meeting a huge need in those communities, and they’re serving the People in a great way.

As SharePoint professionals, who do we serve? SharePoint isn’t exactly available on the corner of every urban neighborhood in America. [yet?] : ) So, who is it that benefits from the skills, experience, and assistance of a great SharePoint’er?

One might say we serve ‘Big Business’. SharePoint is certainly an enterprise server product, and the main consumer of that type of product is the large corporation. If this is who we serve, we certainly serve them well, as SharePoint has been proven to be a strategic advantage, cost-saver, and effective collaboration platform for many large companies.

Or, maybe we serve the corporate Developer? Have you ever seen the smile on the face of a .NET developer after you teach them about the benefits of developing on the SharePoint 2010 platform? : ) When leveraged properly, SharePoint certainly opens up a world of advantages for the .NET dev team trying to create collaboration solutions for their company.

Ultimately, tho, I’d like to think we serve the millions of Information Workers out there who use SharePoint on a daily basis. At the end of the day, that’s who our SharePoint solutions are for, and if I can make just one Information Worker come to work with a smile and expectation that they’ll have a productive day because of SharePoint, then it’s all worth it. : )

As we look toward the future, I would like to think we’ll also be serving the entrepreneur who has a small shop using SharePoint Online. As the cloud continues to provide scalable and cost-effective options for small & medium business, perhaps the dream of SharePoint on every neighborhood corner could be closer than we think.

I’d be interested in your thoughts – as a SharePoint professional, who do you serve?

Document Management & SharePoint - Forms vs Documents


I spent several months last year developing a customized document management system in SharePoint 2007 for a client.  Many interesting challenges have surfaced as a result of working thru the different requirements for this solution, and I thought it might be useful to write about them.  Although there are several aspects to a document management system, this article addresses the importance of agreeing on terminology at the beginning of your document management project.

One of the key areas of terminology as it relates to document management is the use of the terms documents and forms in a document control solution.  Out of the box, SharePoint has preconfigured Document and Forms libraries to help you get started using both.  But as you audit your own existing files in preparation for a migration into SharePoint, it can sometimes be unclear which of your files are forms, and which of them are simply documents.

For example, when identifying Forms, it can be very easy to simply say that all existing InfoPath documents are forms.  InfoPath forms have fields that need to be filled in, and usually have a Submit button of some kind.  But many organizations also use Microsoft Word or even Excel to create and use as Forms.  These Word or Excel documents also have open fields that expect data, and many times are filled out by first being printed to paper.  But it gets even better!  These Word documents could very closely resemble Word templates – files meant to be used as starting points for other Word documents, which also could have data-ready areas within them.  Now the distinction between forms & documents starts to blur a bit.

How, then, do we decide whether a particular Word document in this scenario should be a form or a document in our new SharePoint document management system?  This is a crucial piece of information in the design of our solution, as we consider which library to place the document in, whether the document should be converted from Word to InfoPath, etc.

If you were to ask me to give you an elevator pitch version of an answer, I would say this:  a form is a file whose primary intent is to ask a question, and a document is a file whose primary intent is to answer a question.

I know this won’t satisfy my more cerebral readers, so I scoured a bunch of word definitions and came up with a slightly more specific answer:

Document – A physical or digital representation of a body of information designed with the primary intent to communicate/provide said body of information.


Form – a physical or digital file containing spaces (fields) in which to write/type/select, and whose primary intent is to capture/consume/store information.


Template – a physical or digital file containing information that is meant to be replaced/extended , and whose primary intent is to be used to begin or guide the creation of another file.

  • A form without data is a template.
  • A document with areas intended to be filled-in is a template.

In future posts, I’ll dive a little deeper into what these definitions mean to us as we design & develop our SharePoint-based document management system, including records management.