Proximity Revisited

imageEarly in the life of this blog, I wrote several posts about ‘proximity’ and how important that attribute is to the user experience. I was recently reminded of that fact, and I realized that I my previous examples were too limited.

I was talking about designing a home page or a site page with all the appropriate web parts and without any of the inappropriate web parts. So, if you need to see a task list and a calendar, both of those should be represented on the page, not just sitting over in the quick launch area. Conversely, if you don’t want to have a picture on your site, then you should delete the one of those pretty people.

I also mentioned proximity in association with building dashboards. Having everything that you need being available at a single glance is the key benefit of a dashboard, so I guess my emphasizing proximity wasn’t much of a revelation. I also talked about proximity in terms of business process automation. As our engineers work though the recommendations resulting from their inspections, we tried to give them a view of each recommendation’s life-cycle that was meaningful.

It sounds like I covered all the bases. But, you know that I’ve never written a blog post with less than 250 words, so I must have missed something.

Earlier this year we built a payables process in SharePoint. People can select a vendor, enter a payment request (invoice) and spread that invoice around (allocate) to all the various GL accounts that are affected by it. For example, when we buy a new laptop for someone, we might buy them a case. Those are different types of expenditures.

I have always looked at accounting from a “money in” or “money out” perspective but our accountants seem to be in agreement with my Management Accounting professor – you have to pay attention to stuff like this.

Anyway, the system does all of that stuff reasonably well but there are a few things that the accountants wanted it to do better. Fortunately, one of the women in accounting is also working part-time with my team. One of the things she told me that they want isbetter views of the transactions at all of the various points. They have a view that shows payment requests that are pending, requests that still need someone’s approval, payment requests that are approved but not processes, as well as requests that have been paid and requests that were voided. Seriously, money in / money out works a lot better.

When I sat with her to find out what they wanted, Iimage experienced that old familiar feeling. The presence of that gap – the gap between what people can imagine and what they can’t. In this case, that gap separated the end users from what we SharePoint folks know as Data View Web Parts. As we work together, we are bridging that gap.

She said that they need more detail in the view(s). When I asked “why?” she said “sometimes, we need to know things about the vendor, or we need to know what GL accounts had been affected by this payment.” That made sense, except for the “sometimes” part. I don’t like views that show things that are only needed sometimes. I prefer views that show what you need ‘all the time’ but can be made to show what you need ‘sometimes’ on demand.

I wired up a imagelittle example of one view with the addition of two Data View Web Parts. One web part contained more detail about the payment request and one contained more detail about all of the allocations. I connected those web parts – OK – I really want web part to be one word…webpart, why can’t we just call them webparts – Sorry, I just had to say that. I connected those web parts to columns in the view. SharePoint easily let me show those columns as links, and now when they want the additional detail, they can click on the link and populate the web parts. If they click on the payment request ID, they get its details and its allocations. If they click on the amount, they just get the allocations. Easy-peasy.

To keep all this stuff proximate, we also have to constrict the original view by limiting the number of rows it contains. Most people hate paging, so I gave her an array of options to consider. All Payments, All Payments This Month, All Payments this Quarter, and then of course, this year, last year, etc. I showed her how we can set the page limit and how we can dynamically filter the list to render things like All Payments for a specific vendor. Then, I gave her a homework assignment – go back and sketch out the perfect view. Next week, I’m going to help her build that perfect view. Maybe then I’ll have a better illustration.

Is This Right

clip_image002Last week, I was talking about accuracy. This week, I learned that there is something more important than accuracy – confidence. We have been working on the design of a SharePoint solution that is both simple and complicated at the same time. Of course, we are concerned about accuracy, but the people using our system will have to feel confident that they have selected the information that they need. This isn’t a challenging SharePoint problem; this is a design issue, a usability issue and ultimately an adoption issue.

Our project involves a contact list. That’s simple, but it’s really about 10 contact lists, and since they need to be exposed on both an internal and an Internet-facing server, it’s really 20 contact lists. The “master” list is a group of people who serve on a variety of committees, and that’s the only list we want to maintain. The people come and go and the committee membership changes from year-to-year. We need to know who is on each committee today, we need to know who was on each committee 2, 3, 5 and perhaps 10 years ago, and we need to know this from multiple angles. For example, I might simply want to be able to contact the members of Committee A. On the other hand, if I’m about to meet one of the people on the list, I might want to know every committee he or she serves on. In yet another scenario, if a person is retiring, I might want to know every committee the person ever served on. We’ve cracked the list design issues, and with the help of HarePoint Workflow Extensions, we’ve cracked how to keep the lists in sync on the Internet-facing server. OK, so what is this confidence issue?

Let’s think about those scenarios again. In the first one, I want to see the names of the people who are currently serving on Committee A. Obviously, I could simply filter the list on a few columns to distill the contents down to right group. That would work, but while most people know how to do this, they don’t want to have to do it every time; that’s what views are for. Views, now this is where we start to get into trouble with usability.

Views are a fantastic feature within SharePoint, but neither lists nor views scale very well. That’s not to say that you can’t put a ton of items in a list, or create a bunch of views, but sooner than later the results are untrustworthy. Once you get a couple of pages of items in a list, you have to resort to sorting or filtering to make it useful. Similarly, once you have 15 or 20 views on a list, the selection is equally unmanageable; in fact, a large selection of views might even be worse than a large collection of items. When I am setting sort and filter parameters, I know what I am doing; the trouble is that I have to be able to imagine the results as I proceed. When I choose a view, I am relying on someone’s ability to name a list intelligently. If I make the user figure out how to get the information they want, I put the burden of accuracy on them and it becomes a confidence issue.

There’s a very fine line between wanting my users to understand SharePoint and forcing them into a situation where they are uncomfortable. When they get to that point, they are going to ask someone else (maybe me) to get them the information they need, and at that point SharePoint and I have failed.

We have to find a way to tame a large list that can be rendered in a large number of ways. I can’t just substitute a bunch of input fields for a search or data view web part, that’s really no different than asking them to configure the raw list. I need to give them links and simple binary selections, coupled with a standard output format so they remain confident that they are getting what they want. Links like “Committee A Members” with a choice for “Current members only” or “Most recent five years” or “2000 – Present”. The output should be simple: Contact name (with a link to details), his or her role on the committee and the company they work for. I would argue that this kind of solution is the poster child for “perfect is the enemy of good enough” – making this process more elaborate, or the making the results fancier will only erode the confidence of the average user.

The simplest contact list that we have ever prepared, is rendered from our annual Policyholder Meeting survey, it’s a dirt-simple list: “Who’s Golfing on Thursday”, and it’s an absolute favorite among my coworkers.

Saying No

clip_image002What do your users have in common with your children and your pets? Sometimes, they have to be told “no” in an effort to help them learn to be more self-sufficient. OK, if your pets include cats, telling them “no” and expecting them to learn is a fool’s errand, but I think you understand my point. In addition to the need to be told no, users, children and (some) pets have ways of making it difficult for us to say that word. There are lots of reasons we don’t want to say no, but the big three are:

  1. We want to be liked.
  2. We genuinely want to do what they ask, or let them do what makes them happy.
  3. It’s often easier to do something for them than it is to teach them how to do that thing for themselves.

If you were to ask the users in our company, they would probably tell you that my approach to technical support would indicate that I don’t care about being liked. That’s not entirely true, being liked is nice, but I get paid for being effective. In order for IT to be effective, we have to strike a balance between providing technical support and helping people grow in their understanding, adoption and their own effective use of the technology we provide. This has always been the case; there has always been a fine line between support and coddling on the one hand and encouragement and indifference on the other; walking those lines has never been easy. SharePoint, at least our SharePoint installation makes walking those lines even harder, because the lines are moving. Maybe that’s the whole point of the SharePoint Maturity Model, but I’ll leave that discussion for others. The simple observation is that the further we extend SharePoint beyond the ability of our users to understand it, the more it becomes an IT product.

In trying halt the progression described in the last sentence, I can honestly say that I’m not prone to coddling my users. I might not actually say “no” to people asking for help, but I am becoming a fan of saying: “…here, let me show you how to do that.” The distinction is a finer line than you might imagine. Someone who simply wants a problem to be solved considers that approach to be the equivalent of my saying “no.” But even if we (IT) did everything for them, our SharePoint implementation would ultimately fail. SharePoint growth is fed by the dual inputs of response and insinuation. Most of the progress we have made to this point has been the later; people have asked for help, and we have declared that “that would be a good use of SharePoint.” Far less progress has come in response to people asking if we could change, extend or create a new SharePoint solution. That we do get some of those requests is heartening, but we have to work to keep them in the mix. As our SharePoint solutions become more complex, more aggressive, more dynamic and more useful, people have to understand more about what is going on behind the scenes.

A recent example surfaced as we were demonstrating the management dashboard that I wrote about here. The dashboard highlights individual items and aggregate results that are necessary for managing a process. Most of the results on display are linked to a detail view that better illustrates that aspect of the process – Reports by Engineer for example. As we were demonstrating some of these views, people started suggesting changes. Many of their suggestions just involved altering the sort or filter parameters of the view. We took the opportunity to remind them (demonstrate) that they can dynamically introduce those changes in ANY view, at ANY time. It is very important to remind people that even once a solution has been “developed”, that the results are still in SharePoint and all of SharePoint’s inherent functionality remains available to them. We (practitioners) know this, but people who are not as familiar with SharePoint as we are, may not recognize that a view is a view is a view. In addition, many of them are not adventurous enough to take the approach of saying “let me just try this…” Our history of building and delivering “systems” has conditioned people to thinking that what they get from IT is what they have to work with. This perception will change as we incorporate personalization features into our next generation desktop systems, but right now, SharePoint is leading the way toward the consumerization of IT at our company. I also recognize that they have their own job to do, and that I am asking them to extend their domain to include parts of ours. Like I said, it’s a fine line.

Too Many Tools?

clip_image002My first woodworking project involved cutting a beveled edge on a block of wood with a hand plane. I learned how to layout the bevels with a marking gauge, and how to cut the bevel. Later, I learned how to cut that same bevel on a jointer. Later still, I learned how to cut the bevel with a router. Today, if I have a lot of wood to bevel, I use a router. If I have a small piece to put a bevel on, I actually prefer the block plane shown at the right. It’s nice to have options, but sometimes it’s nice to have a simple solution that always works. Stepping out of the workshop and into my day job, I often find myself in the same situation.

One of the frequently asked questions we get from our end-users is whether one way of doing something in SharePoint is better than another. In fact, one of the complaints we hear from people who have to train new employees, is that “there are too many options in SharePoint.” I don’t like to limit the way people interact with SharePoint, but having more options is not always a good thing. There is a reason that my father started me out with a hand plane.

A simple area of confusion, especially to a new SharePoint user is viewing and adding content. We try to create the default view of libraries and lists with the truly useful information visible and organized in an intuitive order. Then we create the view we use if we are going to put the library / list in a web part. Then (sometimes) we build or edit the Datasheet view. Of course, all of these can be sorted and filtered and we can create custom views for specific situations. If users want to add items, they can use the link at the bottom of the view, the new item row in the datasheet, and, of course, the controls on the Ribbon. We have one application where none of the people involved ever see the list or add new items in the same way. That’s a good thing (customize, personalize, etc.), but it can become a problem when one of those people is introducing the list to a new employee. We try to remind people that they can switch views and that they (or we) can create new views as needed. However, people often forget that SharePoint is this grand mutable platform, because they are focused on a specific solution that they use every day. In other words, they begin to think of the SharePoint they see as the SharePoint that is.

Earlier this week, we had a pre-launch meeting with some of the senior members of our engineering department, and the head of administrative support for engineering. The purpose of the meeting was to show them what we were going to show the entire department during a training session later in the week. We discussed some of the optional ways of getting from A to B, trying to find the one(s) we were going to include in the demo. When I was asked: “how many different ways do we want to show?” I suggested zero, and the head of the department agreed.

We decided to train people using the most common and most reliable method for each activity. We told them that there are options, sooo many options, but we did not show them those options during the training session. I wanted to avoid people having to hold mental bookmarks in place during the session. Once the solution is running, and everyone has gone through the training, hand-holding, solo-flight and a night-landing, then we can start introducing options. For some of the experienced users, SharePoint has already started working its magic; they have transferred their experience from other sites to this site, and that is very good to see. For the users who are new to SharePoint, there is currently only one way to cut a bevel.