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.

As Easy as 1-2-3

clip_image002Last week, I talked about how we built a prototype site in order to demonstrate some of the features we were thinking about using in a project for our legal department. The prototype site was well received, and even though we’re going to delete it pretty soon, it was worth building. In addition, it didn’t take that much effort to build. Part of the reason we were able to build the site so fast is because SharePoint is designed to be built fast; let’s face it, that’s one of the reasons we bought it. The second reason we were able to work fast is because we used a few of the tools we have bolted onto SharePoint. I’ve talked about each of these before, but it’s summer so I think we can stand a few reruns. Here are three of the things we have added to SharePoint that I am happy to have:

Muhimbi PDF Converter – This product not only lets our users convert Office and a wide variety of other documents to PDF from the library drop-down menu, we can call on these services from a SharePoint Designer workflow. The best part is that last little bit about workflows. We can save our coworkers the time it takes to create the PDF, but we can also manage the process. That means that we can put the PDF in the library it belongs in, and because we can kick the workflow off when an item is uploaded or changed, we don’t have to worry about people forgetting this important step.

SharePoint Classifier – We added this product from Boost Solutions last year. Working from an intuitive interface, this lets us bulk edit metadata for a large number of selected or uploaded files quickly. We can set metadata to a specific value across the entire group or we can skip through the list of documents, setting some bits of metadata to a single value but setting others to unique values. We used this to quickly populate the demonstration libraries on our prototype site. Classifier can also copy or move the selected items from one library to another, set tags and check the documents in if necessary.

Lightning Conductor – This is our most recent add-on, but it’s one that I am really going to enjoy using. One of the features we wanted to demonstrate was the ability to pull items together from the various libraries based on certain metadata. The example we used was to show all the documents that had been tagged as the “Current Version” in a single web part on the main page. This illustrated a critical capability that our users wanted, the ability to store documents where they belong, but present them as if they are in the same place. What I like so much is the fact that we configured the web part in a matter of minutes.

These tools make SharePoint easier to use and much more powerful by augmenting the inherent strength of SharePoint’s out-of-the-box power. Whether our users are working directly with these tools or asking us to configure a solution for them, these (and other) tools are saving us precious time.

Lightning Conductor Web Part

New Haven RailroadA while back, I suggested that I wasn’t worried about the changes that Microsoft was making / has made to SharePoint because the market would come to our rescue. The pronoun here is referring to those of us who had gotten used to wiring up Data View Web Parts and customizing pages in SharePoint Designer. The collective changes in SharePoint 2013 will make building those solutions a different exercise and one that brings us closer to programming than my staff wants to be. I’ll save until later the philosophical debate(s) around whether script-coding is programming; whether programming is evil and to be avoided or a necessary skill that should be required, and whether JavaScript is the official language of the new world order and we should all just suck-it-up. Today, I want to point out one vendor that has stepped into the role I outlined last October.

We have been previewing the Lightning Conductor Web Part from Lightning Tools and I am happy to report that it looks like it can easily help us provide one of the solutions that we used to turn to XSL to provide – the custom view of data from places our users don’t want to go. OK, it’s not that they don’t want to go there; they just don’t want to be on the road forever. The people using SharePoint in our company don’t really want to use SharePoint to conduct business; they want SharePoint to work for them. We made a promise to those people years ago when we (Information Services) chose SharePoint; we said that we would invest time and budget into making SharePoint easy to use. I take that promise very seriously. If I start telling people “you have to learn a lot more about SharePoint in order to have it help you with that task…” I’m practicing bait and switch. This new tool is pretty cool, and it appears to be a really good use of my budget. So, what does this tool actually do? Well, I can’t describe this any better than the Lightning Tools website, but here’s what we like about it:

Using the tool, we can quickly put a web part on a page that aggregates content from multiple libraries on the site, from within the site collection, from within multiple site collections or from across our entire farm. We can filter this content, we can sort this content and we can decide what columns to include. We can do all of this from within the browser, without opening SharePoint Designer and without even leaving the page that we want to put the web part on. Configuration is fast, and the results are immediate. And, if we screw it up, we can simply delete the part without having messed up the entire page.

For example, we will be able to gather policies, underwriting correspondence, inspection reports, engineering metrics, previous claims and presentations given to any one of our customers, on any page on our farm. These documents (someday will) all reside in the sites where they belong, but I (will be able to) pull them together – without waiting for a search to complete – wherever they might be useful. Parenthetical expressions aside, we already have content in multiple locations that needs to be aggregated to be more useful.

Of course there are a lot of other ways to accomplish these tasks. I have watched lots of people demonstrate various techniques at seminars and, inspired by those demos, I urged my team to learn these techniques. These days, I want my team building solutions. I want them to show off their content and information management prowess, not their syntax skills. The people on my team can imagine great solutions by merging their understanding of SharePoint, content management and the unique attributes of our crazy little business. If I can buy tools like this to let them quickly build what they can imagine, it seems like a good move.

I think we are moving forward with this purchase We just purchased this product! We had a few questions during our evaluation, and they were quickly answered by the responsive service group at Lightning Tools.

Let me dwell on that last thought for a second. I love it when a vendor lets you work with the actual technical support group during a sales evaluation. Not only did we get our answers, we were able to evaluate the support as well. BTW, the support is as good as the product.

The Lightning Conductor looks like a nice fit for us, but I’ll fill you in on our actual experience after we put it to use. Maybe I’ll get one of my team members to write about and I’ll get a week off – this is sounding better and better.

SharePoint FM

clip_image002I spent my freshman year at the University of Georgia (go Bulldogs) and thanks to some friends on my dorm floor, I was able to visit some beautiful parts of that state. Once while driving around some desolate south-Georgia back roads, we stumbled across a Pirate game on the radio. I recognized KDKA AM 1020 Pittsburgh immediately by the announcer’s voice. We could hear that game in Georgia due to the ability for AM radio waves to skip across the planet, bouncing off the Ionosphere. FM radio waves, due to the different way they propagate, are limited to line-of-site reception. Hmm, if this is an analogy to SharePoint, wouldn’t I want to be AM? No; we chose an FM model because it’s more narrowly focused, but capable of delivering a higher quality signal (think classical music vs. political talking heads). If we extend this analogy just a little closer to the breaking point, we like operating in a narrow band of the “development spectrum” within SharePoint so we can:

Focus on Quality – This is very important to my team. We don’t want to simply be a company that uses SharePoint; we want to implement Content Management in SharePoint. That requires adherence to the standards and best practices associated with ECM, not just the creation of a bunch of libraries. In addition, we want to improve the business process associated with the creation, use and distribution of the information that we store in SharePoint. In the current project that I’m working on, I have worked with the owner of the process to build a better way of entering data, segregating data and presenting data for review. In the course of defining the requirements, we are expanding the use case from one where we keep track of stuff to one where we keep track, manage, analyze and share this stuff with our coworkers and our customers.

Stay close to home – We keep our solutions close to “out-of-the-box”, because we want our users to be able to understand, combine, extend and reuse the work we’ve done. We also don’t want to invest too heavily in development because we have better things to be developing. No offense to ECM, but out-of-the-box SharePoint can look pretty good, and if it’s easy to use and satisfies the customers, we don’t need to make it overly snazzy. Plus, I keep coming back to the notion that, in using SharePoint, people learn how to use SharePoint, and that knowledge is cumulative. I have also found that my coworkers are more interested in how the solution works, than appearance. I think there’s a fine line between adding functionality to have the page look tricked out and modern, and adding functionality that improves the user experience – we’re working hard to find, but not cross that line.

Be a wee bit anal – I know that some of you might be asking “why not just let your users develop their own solutions from the ground up?” The answer is simple and a bit selfish; I don’t want to join some friends of mine who have been left with half-finished or half-baked SharePoint solutions when some department level guru decides to leave. I want our solutions to be documented. I want to know what needs to change if we move the solution to a new server, or to our Internet-facing farm, and I want to be able to maintain the “systems” that our employees have come to rely upon. I also want our solutions to follow some standards. For example, where we have managed metadata in use, I don’t want to see a solution that is using a Choice column that has (at the moment) the same information as what is in the term store.

The system that I mentioned above organizes data from a series of inspection reports and follow-up meetings in three related lists. In order to review that data, we built a Web Part Page that contains about 5 Data View Web Parts to pull the related bits from those lists and present them in a useful format. To setup the page, we pass a bunch of parameters in with the URL. For example, based on source parameters, the page can be grouped by Facility, or by Engineer, or by Category. We construct those URLs in a workflow and store them with each item in the master list so they can be exposed as links in a wide variety of views. The Facility link, for example will configure the page to be grouped by Facility. We could have just built a second DVWP page to drive the sort and filter process and then build the URL on-the-fly, but that would put us in maintenance mode. SharePoint Views look pretty good, and many of our users can build them. Letting them add the URLs to their own views, lets them extend our solution. It’s still a line-of-sight system, but it has a little better reach.

FDMI

clip_image002I began driving in the era when Interstate highways were beginning to replace the convoluted network of US and State highways interconnected by local roads. One of the first major bits of Interstate to open up in western PA was I-79 between Bridgeville and Washington, PA a.k.a. “little Washington” so you didn’t confuse it with Washington, D.C. I-79 was an alternative to, but did not replace US Rt-19. Unfortunately for me, my father stood by Rt-19 as his first choice for any destination between our house and little Washington. I can remember his arguments, which varied between: “Rt-19 is actually shorter” to “by the time you deal with getting to and from the ramps, the highway isn’t that much faster” – I call results like that a Failure Due to Marginal Improvement (FDMI).

I have recently been reminded of those conversations with my dad, as I try to replace an Excel spreadsheet with a series of SharePoint lists. The issue is that we aren’t talking about replicating data; we are talking about changing, and hopefully improving the process that the data is associated with. The question is, are we doing enough.

The spreadsheet works – The current “system” in Excel doesn’t work well, but has the advantage that people know how it works. This is often the reason why people want to just move what they have into SharePoint, the thought is that they will still understand it. When we are replacing a list, we are often changing the way items are created, maintained and viewed. The result should be a better overall experience, but will it be good enough to offset the change?

Several weeks ago, Marc Anderson raised the question of whether form or function was more important. I suggested that the form-function ratio should never be less than 4:3, and this little project is an example why I think that is true. SharePoint lists are about as close to a database solution as you can get without invoking SQL, but we’re still talking rows and columns, and rows and columns are Excel’s forte. When you start moving Excel data into SharePoint, you create one or two (in this case three) Custom Lists. If you show the user an All Items view of their data in SharePoint, it’s going to look worse than it did in Excel. SharePoint doesn’t use its screen real estate as efficiently as Excel, and people who like Excel will pick up on that immediately.

The Excel-based solution I am replacing is a collection of observations and recommendations. Each row has details about the observations on the left, a huge column of text containing the observations in the center, and a series of recommendations on the right side of an A-X layout. The text is nearly unreadable and it is hard to stay on the same row as you scroll right to left, but the process is easy to understand. Read the details, read the text, write the recommendation.

clip_image004
Moving to a data view web part of items, with options to expose the details in a second DVWP, the observations in another and the previous recommendations in a third, give us a composite view of each item in an easy to read format.

clip_image006
I am planning to add an entry part to write the new recommendations, but that can wait. What we have so far is based on the initial discussion, and it’s time to check-in and show the results.

I’ve got one more concern as I get ready to touch base with the future owner of this solution. Since the stuff isn’t in the same “row” (it’s not even in the same list) he needs to have an increased level of trust in the underlying process. Sometimes it’s hard for people to accept that everything on that page is everything there is. Again, you gain that confidence in the spreadsheet visually; it’s not a pretty sight, but you can see it. I plan to walk the new owner through the process of building an entry from the ground up. By the time we come back to the composite page, he will know exactly what he should see. I’ve made that trip eight times, so I know it’s going to be a sweet ride. In addition to making it work, the user experience needs to be clearly superior to Excel if we’re going to avoid FDMI.

Doing Battle Again

clip_image002Every time someone comes to me with a system that they have built in Excel and asks me for help making it better, I feel like Steve McGarrett in his perennial battle with Wo Fat. Inevitably, that “system” is a list of stuff loosely arranged in row-column order. Also inevitably, when I suggest moving the system into SharePoint, I get major push-back. I have written about this before, in fact, Excel vs. Custom Lists is one of the top-5 most popular SharePoint Stories of all time. This time, I thought that I would share some of the questions and comments I normally receive, along with my answers:

So, you really push SharePoint don’t you? – No, I don’t “push” SharePoint, I recommend the best technology we have available to meet the business requirements. When those requirements include tracking a list of items that are characterized by custom but common attributes, I am prone to recommend building a Custom List – I’m just funny that way.

“I think these things should be stored in a database.” – I usually avoid saying “then why did you put them in Excel?” I also try to avoid going into the weeds to explain SharePoint from the ground up, and how it really is a fancy way of sticking stuff in SQL Server. I’ve learned that the way to win this battle is to ask “why?” Sometimes, people don’t know why they think stuff should be in a database. These are the same people who buy all sorts of storage systems for their garage because the garage in the picture looks so good. The people who do have a reason for wanting their list of items to be in a database usually want one of the following three things:

  • Relationships – whether it’s one to many, or many to one, they want to relate a few things to one or more other things. This is a great reason to put stuff in a database. It’s also a great reason to put stuff in a series of connected SharePoint Custom Lists. Why do I often choose SharePoint instead of SQL Server?…I mean we have both. Well, SharePoint offers all the features we normally need to meet these requirements, programmers are usually not required and it’s easy to share the lists on a web page and out to a mobile device.

  • Ease of use – When people say that they want their storage mechanism to be easy to use, they are almost always still talking about relationships. They want people to be able to pick from a list of standard terms, or they want to select a facility name and automatically find the policy in force and the underwriter for that policy. Perhaps you can appreciate how hard it is for me to not say “seriously, why did you put this in Excel?” I am a huge fan of vLookup(), but I’ll buy a beer for every Excel user at the bar who can tell me how it works. SharePoint, by contrast gives us multiple ways of adding Pick-lists and lookup columns and they are all pretty easy to build and dirt simple to maintain.

  • Sorting and Filtering – I understand that Excel has the ability to sort and filter, but these functions in Excel involve hiding what you don’t want to see, particularly if you don’t want to see the same columns for every sorted and filtered set. Views in SharePoint are real views. Sorting and filtering in Excel is like putting virtual duct tape over certain rows and columns. But, if you want to make the point to an Excel fan-boy, build a view. Sit them down, and build a view right in front of them and dare them to do the same thing in Excel. Better yet, build three views in less than 5 minutes and sit there switching between them. Even better, put two Data View Web Parts on a page and use one to drive the sort and filter parameters of the other. Granted, that last one takes a bit of what some would call programming, but still…

It’s easier to print from Excel” – OK, you may have me on this one, but that’s OK, I have a secret weapon – SQL Server Reporting Services. I know, there are ways to print from a Custom List, and there are List Print utilities. In fact, I think we own one of those utilities, but I like SSRS because my coworker can slap Excel upside the head with a report from that service.

When people push against moving to SharePoint from Excel, don’t argue the details, don’t try to convince them with logic and don’t make fun of them – bury them. Find every single thing they like about Excel and show them the superior thing in SharePoint. Trust me; it won’t be hard to do.

The Market Will Save Us

clip_image002I just finished reading a blog post by Sahil Malik which refers to a blog post by Marc Anderson and other posts and comments on the subject of the soon-to-be-gone-but-not-forgotten design view in SharePoint 2013. I have followed this story from the beginning when Marc was hinting that the design view was missing, up to and now well beyond, the seemingly official death sentence that was published by the Microsoft SharePoint Team on their blog. That the design view is going, going, gone seems certain at this point, but whether that will result in a wave of power users learning the art and craft of development or just skyrocketing demand for existing developers is not so clear. I can only say with clarity what will happen in my little world – nothing.

I should rephrase that “nothing will happen right away” and by “nothing” I mean SharePoint 2013. It won’t land here at least until this time next year because activity is underway that relies on the work that members of my team are performing in SharePoint Designer, using design view. Those projects will be completed and an annual event that depends on some custom Data View Web Parts that we assemble will be supported on SharePoint 2010 as it has for the previous two years. Switching canoes in the middle of this stream isn’t appealing and it won’t happen. This isn’t going to hurt Microsoft, (unless SharePoint 2013 marketing success depends on posts in this blog) because we have SharePoint under Software Assurance.

While people are lining up to prognosticate as to which way companies will go (developer of just plain SharePoint) I have faith that good old marketplace economics will save the day. Somebody will build a tool or an add-on tool for something like Dreamweaver, to once again empower the end-users and designers to push SharePoint beyond the limits of its dumpy box. If that doesn’t happen, then other market forces will bear down on the situation and other platforms may benefit from this decision. Again, I can’t speak for the market, or the broad content management / collaboration community, but if I have to turn developers loose on an ECM solution, I’m going to take a hard look at Nuxeo before I start buying more copies of Visual Studio.

Of course, I probably don’t even have to go that far. Before watching Marc Anderson deftly build a Data View Web Part using j-this, j-that and SPServices, I was using Ruby and Dreamweaver to put the information I wanted in a Web Part. I certainly prefer the approach Marc taught my crew, but I can always revert to other options. In fact, I may not have to revert to Ruby; much of what we display in Data View Web Parts can be rendered by SQL Server Reporting Services, another technology my crew is adept at using. Then again, the market may save the day in other ways. When I was using Ruby, I coupled it with Dreamweaver because someone had written a Dreamweaver extension for working with RHTML. I’m willing to bet that there are way more SharePoint power users than there are Ruby developers so I wouldn’t be surprised to see a solution become available for building the kind of solutions that we continue to need in SharePoint from a different development starting point.

Microsoft may want SharePoint to look like SharePoint, and as I have said before on this blog, I support that to a degree. The more SharePoint solutions share a common look and feel, the easier it is for people using SharePoint to move from one solution to another. Still, sometimes what you need isn’t in the box. When intelligent and enterprising people are confronted by the absence of the things they need, they find them elsewhere or they figure out how to build them. When enough people start building things, vendors bring tools to the market. Maybe Stanley will come out with the Fat Max Editor for SharePoint – I would buy that in a heartbeat.