Absorbing Frustration

clip_image002The tag line includes “…we find frustrating” for a reason. Every now and then, SharePoint presents you with a situation that just makes you scratch your head. Here’s the most recent one for me: There is a setting on the People and Groups column where you can specify that multiple people or groups are allowed. However, if you are filtering on a people and groups column, you can’t use the “contains” operator. I can imagine that since “contains” invokes a string function, it would be more work to implement it on people, and I can further imagine a developer saying: “if they want to filter on multiple people, they can use a group.” However, a group doesn’t work for us.

We have an Internet-facing site for our business partners, and we also include a section for employees who may need to access company content when they are away from a machine that can establish a VPN connection. This site is on a separate farm, and a separate domain. Our internal domain users can authenticate via an Active Directory Trust, so, in theory they only have to remember one set of credentials. The problem is, they have to include the domain name, so they log in like “co-domain\jsmith” which is a little annoying, particularly if you’re using an iPad. If they don’t mind maintaining two UserIDs, they can use credentials from the outside domain, in which case they could log in as “jsmith”. As you can imagine, this is easier sometimes, but not always. If I am on my domain laptop, it’s easier to be “inside me.” Normally, it doesn’t matter who you are, because we establish permissions for both. Of course, since I said this was frustrating, you realize I’m not talking about a normal situation.

In trying to support a company Wellness Program, we are building a site where employees get points for doing healthy things. They can redeem these points for awards. In addition, the program administrator can redeem their points for them. This combination of activity means that the Points and Redemptions list has items “Created by” an internal domain user, an external domain user and the administrator. OK, we aren’t filtering on that when we want to show the employee their own point balance. Our first attempt at setting up a filter mechanism was to put both userIDs in a People column of an Employee list and filter on “Domain Names contains [Me]” – no can do. To get around this, we created two columns in the Employee list in addition to a name column (“John Smith”), we have a trusted ID “co-domain\jsmith” and an outside domain column “jsmith”. We pick using the name, and a workflow populates the domain versions wherever they might be needed later. When we want to filter, we select: outside domain user = [Me] OR inside user = [Me].

I would be willing to bet that some of you have already thought of a better way to solve my problem than the brute force approach I took. If you have, please add a comment. However, if you follow this blog, you know that I don’t try to teach people how to do things here; this blog is more about why we do things. Why did I (have the person actually building the site) go to all this trouble? So we could absorb the frustration at this level.

We could have simply said “when you visit the Wellness site to enter points, you must use your co-domain credentials;” in fact, I’ve done things like that before – I know better now. We have to build this site once; people have to use it every day. I can’t begin to count the times I’ve have had to remind myself, and other programmers of that (1:n) ratio over the course of my career. No system, platform, device or language is perfect; automated systems will always include pain points and frustration. Good architects, designers and developers remove these before deploying a solution; they absorb the pain and frustration into the solution. When we deploy the Wellness site, it won’t be pretty under the hood, it will include this somewhat hard-coded kludge of name variants, but it will work like the employees expect. No matter how they login, they will see their points.

2 thoughts on “Absorbing Frustration

  1. Dan:I really like the "1:n" thing, which I don't think I've heard before. I wish more programmers (we're showing our age by using that word!) realized that ratio matters. I think it's a big part of the whole UX "movement" – if it in fact ranks as a movement. It's not good enough to make something work well or look good. It's got to be a combination of the two, as you and I have discussed many times. (I'm not giving up on you.)As for the filtering thing, it may make sense to use a DVWP because you can do far more sophisticated filtering in one. Person or Group columns are represented with a mess of HTML which you can parse apart to get at the UserID (a number representing their item in the User Information List), their name (as in Fliggenbottom, Lester), or their account (domain\lfliggenbottom). It's also possible to get at more details about the person by using SPServices functions like SPGetCurrent user or by calling the User Profile Web Service.M.

  2. Thanks Marc.I did think about using a DVWP, assuming that the filtering options would be more robust. Part of the reason I decided against that was to leave this in a state where the actual end-user can build additional views. We are pretty far behind the curve in terms of end-user development, but this time the person does want to help, so I tried to make it a bit more straight forward.That said, I do have to get some practical experience with SPServices.

Comments are closed.