Personalized to the Point of Failure

imageIn 1997 I wrote a bit of code that has finally come back to haunt me. The idea was sound, the implementation was flawed but I didn’t know it at the time. I wanted a way to include some rudimentary (by today’s standards) personalization into our desktop systems. I crafted a Parent Class that contained a System Setup utility and a startup routine to access and apply preferences. I stored things like the fonts and font sizes, the position and size of the main window and certain basic application parameters. This was at a time when most Windows applications contained UI elements that didn’t even scale when you stretched the window, so I was quite happy with the outcome. My mistake? – following Microsoft’s advice to abandon the trusted .ini file in favor of storing this stuff in the Registry. I wrote a Registry interface before a good commercial class library was available for Smalltalk, and that bit of code has reached its breaking point.

It seems that errors with personalization are moving like ripples on a lake, because while I am rewriting a 15-yr old process, we are facing the other side of the personalization dilemma, when to say “no.” We’ve been asked to reduce the detail in a dashboard view in SharePoint. Saying “no” isn’t something I enjoy, but we do have to know where to draw the line between a personal view and the minimal amount of information a user should receive. This is a tricky endeavor. I used to work for a man who viewed the world as a series of binary equations. Status to him was “done or not done?” He would prefer a dashboard with a simple red/green indicator (no yellow required), but that isn’t always what people need to see. “Not done” inevitably leads to questions, and good dashboards should answer the most common questions as well as report the status. This is especially true in SharePoint, where finding those answers may not be easy. Our dashboard highlights reports that are nearly overdue as well as reports that are actually overdue. Seeing that 7 reports are approaching their delivery deadline will absolutely cause you to ask “which reports?” but finding them takes a bit of sleuth work. So, if someone asks me to remove the actionable list of those reports from the dashboard, I hesitate; I want to talk to them and walk them through the scenario(s) that might unfold and test their resolve on that request.

Another oddball request we received this week was actually a multi-part mind numbing exercise. We have a list of contacts, which are organized into three categories. To avoid adding enough detail to identify the suspects, I’ll just call them Type A, B and C contacts. We had to produce a series of reports that include A’s and occasionally B’s but never C’s. That was pretty easy. Now we have a request to include a single B-type contact on a report that doesn’t contain B’s. In addition, we need to include a contact that is neither an A, nor a B nor a C on a report that only includes A’s.

These are the kind of problems that make you question your design effort, not to mention your chosen profession, but a bad design wasn’t the cause of our problem. The root cause in this case is the nature of this list – contacts are people and people aren’t as easy to manage and categorize as things. Rather than try to manage our way through this issue, we opted for a few technical tweaks that provide the necessary capabilities while stopping short of hard-coding individual reports.

I hope that you can see from my opening story that I am a fan of personalization; however, I do think there are practical limits that should be considered:

1 – There should not be an ability to eliminate information that is widely considered to be essential to the understanding of the content.

2 – Personalization should not require arduous coding. This is another way of saying that personalization should be intuitive and available to all visitors to a site. When we start trying to make micro-adjustments to accommodate specific individuals, it’s time to push back.

3 – Personalization should not interfere with knowledge transfer. This might be a special case of the first item in the list, but it’s worth considering separately. When we look at what information is essential to the viewer, we have to consider what an experienced user does with that information as opposed to what the new guy might do with it. It’s fair to say that not all people know what information they might need under certain situations.

According to Plan

I had the perfect idea for this week’s blog. I was going to segue from my comments about SPTechCon into a discussion of the other places at which I will be speaking about SharePoint, as well as the reasons that people using SharePoint need to help sell SharePoint. Well, it turns out, one of those speaking engagements needed to be cancelled. My message, about how much you can do with SharePoint out-of-the-box, didn’t mesh with the event sponsor’s product line. I wasn’t bothered by this, my job does not depend on my selling SharePoint or selling my SharePoint expertise or experience – my job depends on making SharePoint work. That brings me to my second idea for this blog entry.

Over the course of the last three weeks, I talked about a solution I “developed” for our internal SharePoint server’s main page. The collection of calculated columns, instructions and workflows places our Recurring Calendar Entries at the ragged edge of acceptable solutions. One of my problems with the “answer” we came up with is the difficulty in replicating and documenting SharePoint Designer workflows. Once again, I thought that I would build on that concept and talk about the way SharePoint Designer 2010 solves some of those problems. That did not go according to plan either, but it is still an important topic.

One of my favorite features in SharePoint 2010 is the addition of Visio Services. The ability to display Visio diagrams, especially diagrams linked to live data for people to view in a browser is awesome. The ability to combine the power of well designed diagrams with the data they represent can lead to some powerfully informative pages. Separating the Model from the View not only reduces the number of Visio licenses required, it is the right approach to development. The thing I like most about Visio services in SharePoint 2010 is the ability to design workflows in Visio and the ability for SharePoint Designer 2010 to import/export workflows to Visio. This solves one of the problems I have with workflows – documentation. Not only does exporting a workflow to Visio create instant documentation, it allows you to maintain the workflow. Well, it would, if it worked. I have to look up and remind myself that this blog includes things we “attempt” and things we “find frustrating”, this is one of those things. I am not sure if the problem is with the Release Candidate version of SharePoint Designer 2010 I downloaded, or my laptop, but when I export a workflow to Visio, Visio cannot open the file.

SharePoint Designer 2010 exports a *.vwi file (essentially a Zip file), or a Visio interchange file containing yourWorkflow.vdx and a few xml files describing the guts of the workflow. Unfortunately, when I export a workflow, the resulting *.vwi file does not include the *.vdx file. As a result, the diagram of the workflow I developed for replicating Calendar entries is not available to show in this blog 😦 .

While this glitch may have helped derail that perfect blog entry, I’m not worried. Either my tech guy or Microsoft will figure out the problem I am having with SharePoint Designer, and this feature will be ready for prime-time when we go live with SharePoint 2010. We will be able to document, maintain and replicate our workflows. Also, since SharePoint 2010 supports Reusable Workflows, I may be compelled to expand greatly the places where we use workflows instead of turning to a developed solution – that is good news!

While I am sharing good news, I’ll briefly mention two things I like that I discovered about SharePoint Designer 2010 while recreating the workflow I spoke about in the previous series. Workflow variables are now explicitly typed. Being a Smalltalk developer, you would think I would argue against explicit typing, but if your development environment doesn’t really deal with dynamically typed variables, you should have the opportunity to specify that ‘NewDays’ is a Date/Time variable. The other thing I noticed is that you now have the ability to control your selection of list items. If you read my earlier series, you may recall that I found it easier to continue working with the Current Entry than to try to find the entries that my replication workflow was creating. SharePoint Designer 2010 gives you several ways to select the entry from the list you are working in during the course of the workflow.

Back to the original idea for this blog, later this week, I will be speaking at an event called WorkSmart 2010, a day of educational sessions and technology demonstrations presented by ADNET Technologies. ADNET is our VAR and I have spoken about them before in this blog. If you are in the New York – New England area, they are a vendor you definitely should check into.

Fat-Client – Meet SharePoint

Two weeks ago, I started out with a quote from a fellow systems developer that included the question: “I was wondering what the fascination with SharePoint is ‘out there’?” I have to admit, I found myself asking the same question about two years into our SharePoint deployment. Not that everyone was fascinated mind you; if you follow this blog you know I spend a lot of time marketing SharePoint to our small group of users. But what I did find surprising were the times people would ask me “why can’t I do [some fat-client system task] in SharePoint?” Why would they want to? If I follow this blog, I know the answer to that question – proximity. People don’t like bouncing from one thing to another during the course of the same task.

In an attempt to please some of the people some of the time, I now find it necessary to connect our fat-client systems to SharePoint. Readers of this series may have picked up on the fact that those fat-client systems are written in Smalltalk. I won’t debate the merits of Smalltalk over dot-net here, I’ll simply say: “if you’ve used both, you understand why I want to keep using Smalltalk.” Microsoft doesn’t make that an easy task, but to their credit, they do make it possible. SharePoint is accessible via Web Services and Smalltalk can take advantage of that mechanism. Right now, we have the talented people at TotallyObjects (Ipswich England) developing a Smalltalk to SharePoint connection framework. I’ve worked with these guys for many years and we tend to hand them, as their lead developer likes to say, our “tricky bits” of coding. If it were up to me, I’d hack my way through SharePoint’s Web Service interface and get one system working, and then repeat about 60% of that work in the second system. After TotallyObjects is done, I’ll have a reliable interface to SharePoint for all my systems.

Beyond the proximity effect for our users, is there any real benefit to linking front-office systems to SharePoint, or SharePoint to back-office data? Of course the answer is yes. Microsoft knows that, and that is why SharePoint 2010 will support better and easier connections to back-end data. Presenting back-office details in charts and dashboards has always been a cherished goal of SharePoint architects and, like so many other features, it was possible in 2007 and it gets easier and more powerful in 2010. Our users want this to be bi-directional; they say: “if the best place to keep track of contacts is SharePoint, why can’t that contact list generate a pick-list in those fat-client applications?

Of course, we can do that; we have already made enough progress that I know I can read a SharePoint contact list, generate a pick-list and link, for example, one of our policies to a risk manager identified in SharePoint. But, what if that risk manager retires? How do we make sure SharePoint data that is in use by our applications, doesn’t get destroyed? Two things are going to make that possible. One is workflow; when a SharePoint user wants to alter something, we can determine in a workflow if that action is going to cause a problem. If there is a problem, we can point the user in the right direction to solve that problem. The second tool available to us is permissions. SharePoint’s granular permission structure makes it easy to let people do what they need to do without being able to do what they should not do.

But wait, this sounds complicated; are we sure there is real benefit here? Yes! It may be complicated but it’s less complicated than writing and maintaining custom applications – trust me, I do both of these things for a living. It may be easier for a developer to build and maintain a custom application, but developers are expensive. Likewise, it may be difficult to train end-users to design and maintain SharePoint, but it’s at least an order of magnitude harder to train them to write code! If we can get end-users comfortable performing in SharePoint, what was once the possession of tenured applications, we not only make the users happier and more productive, we lower our total cost.

We are about 75% of the way through our first migration of a fat-client system into SharePoint. The data is being entered and maintained in SharePoint today. Reporting will be the first application we wire-up using our Web Service interface. For now, we’re using an export to Excel. This has been a simple exercise and I don’t believe we have solved or even seen all the problems that are out there. Still, I know what it took to develop the system we eliminated and I know what it took to eliminate it – we are way ahead!

"Funny how that works, eh?”

Back in November, I gave a presentation to the New York Smalltalk User Group at which I explained why our need to connect our business applications to SharePoint almost drove us away from Smalltalk. The presentation generated a number of comments and one that I liked was from Richard Sargent:

I have to admit, I was wondering what the fascination with SharePoint is ‘out there’. The examples I have seen in the last few years are rubbish, nothing but repositories for randomly disorganised junk…if there is anyone using it for anything different than a document dump and a web-based spread sheet, I’d like to know!

Of course, I pointed out we are using SharePoint for more than that, and that our site isn’t rubbish. A few emails later he selected one of my earlier comments and sent it back to me. I said: “We work hard to define the requirements” and I could almost sense a little smugness when he replied: “I think that is what sets your SharePoint sites apart from the garbage I have encountered… It’s funny how that works, eh?

Systems developers know how important requirements are and we all tend to feel a chill when we hear the words “end-user development.” SharePoint isn’t the first end-user development environment I’ve encountered, I think that was dBase III, and what always scares me is the implication that ‘anybody can do this’. I want to add a disclaimer like Adam and Jamie on MythBusters – “Don’t try this at home”. If you are going to avoid rubbish, you have two choices: 1) Train your end-users, or 2) Don’t give them anything more than Contribute permission.

Train Your End-Users – That sounds simple enough, but it’s more than teaching them where to find the Create menu. You have to make sure your users understand the various platform components: Sites, Libraries, Lists, etc. and their various incarnations. They need to know the difference between a Document Library, a Document Center and a Publishing Site. They need to know how to add Custom Columns to a library or a list and they need to know when and why they need to add them. They need to know what the company vision is for ECM and SharePoint and how to map their requirements into that vision. It follows that you need to have a company plan for SharePoint in which you establish that vision.

Lock Them at Contribute – This approach may make you feel better but it isn’t going to work unless you are prepared to build everything your users need. People know what SharePoint can do and they want those options to be made available. If you don’t let them build their own sites, and you don’t build those sites for them, you are going to watch SharePoint fail, or worse, spawn home grown solutions either on workgroup servers or in the cloud, or much worse, more rubbish in file shares.

We have opted to chart a course in between these two extremes, albeit we are closer to the “contribute” shoreline. We respond quickly to user requests for SharePoint resources, either on our internal or our Internet facing farm. But, as I mentioned in a series called Timeless Lessons, responding quickly doesn’t mean building sites quickly. We take the time to understand the users’ requirements and to satisfy those requirements. At the same time, we invest heavily in training. We have an in-house training program featuring a new topic every month. Some of those topics are SharePoint specific but all of them address any SharePoint implications. For example, if we are teaching a class on PowerPoint, we include a few minutes on our SharePoint Slide Library. Since we use SharePoint for ECM, we conduct ECM training too. We have examples of end-users who design their own sites, customize their sites and we’ve had a few successful end-user constructed sites. But, in each case we have been close by, like the Fire Department during a taping of Myth Busters.