In 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.