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.

Short and Sweet

imageAs I indicated earlier in the year, I am doing less of the heavy lifting around our SharePoint space lately. I think I mentioned that this would have an impact on this blog, and well, I think that starts today. I’m not planning to stop or to go to a less frequent editorial schedule but I do have less to say.

I’ll wait for the applause to stop.

Seriously, I can wait.

OK, here’s the first short and sweet SharePoint Story.

One of the things I’ve been doing lately is helping a young woman build a site to store, track and display the results of our upcoming Wellness Contest. I say helping her build, because she is doing all the work. I’m looking over her virtual shoulder (via Lync) but she is navigating the browser, creating the lists and libraries and she is constructing the SharePoint Designer workflows. My contribution is a lot of:

oh, I see why that didn’t work” and “ok, now go back into the browser and try that workflow again…

So far, the most memorable moment for me is when she was terminating a workflow gone haywire and, looking at the workflow results page, said:

These error messages don’t really tell you much do they?

No, no they don’t – Welcome to SharePoint.

This post is about two bits of my personal style that I felt were important enough to pass onto her, and I’m going to refer to one that I’ve already mentioned. Let’s get the reuse out of the way first.

As I said a few weeks ago, I like building multiple small workflows instead of single large ugly workflows. Yes, adding the word “ugly” is a literary technique to skew your opinion toward agreement with mine. I don’t want you to think I’m trying to subtly manipulate you – the manipulation attempt is blatant.

I had a new reason for sharing this technique today though. Having short, single-purpose workflows helps a person build their reference library. Everybody forgets how to do some of the wonderful things they did in an earlier moment of greatness. It’s nice to be able to say “oh, I remember doing that when we did the Wellness contest back in 2014” and to be able to open that workflow and study it. If you open a workflow that scrolls on for several pages, you’ll likely be too confused to gain much benefit.

By the way, in addition to reusing the old thing, that counts as one of my two new things, so I’m almost done.

The second new thing has to do with clarity. Simply put, use more variables. For instance, in the workflow we were working with today, we are processing a step count that arrives by email. If there is an error, we are going to send an email back to the person who sent in the steps. That bit of information is in the Current Item From field, and we could reference it from there. However, I’d rather store it to a variable called “vFrom” and then send the error message to ‘vFrom’ if / when we have to. When we look at that workflow, the variables are visible, readable and the workflow makes a certain amount of sense.

When she finishes this project, I’ll provide a full description here; maybe I’ll even be able to coax her into writing that post. Until then, maybe I’ll actually do some work of my own, or I’ll offer up another short and sweet observation.