A recent post by my colleague Jamie Skella “What UX Isn’t” started me thinking about how UX applies to FIM. Throughout my career as an Identity Management Consultant, I’ve seen projects reach a point in maturity where stakeholders are walked through the tasks an admin or user will perform in the portal, and the average eyebrow height in the room rises exponentially.
Those of us working with Microsoft’s identity products for a while, are used to seeing the glitz and glamour of the Sync Engine console, previously the only interface available with the product, so when the FIM Portal was introduced with FIM 2010, it gave a “user friendly” interface to work with. Sure, it was a bit clunky here and there, but hey, we’ve got a nice user interface now! The problem is however, we’re not the users. The users are a completely separate group of people, who are not Identity Management Consultants and who do not find this a refreshing change.
In this post, I will cover some of the user experience pain points in the FIM Portal which I believe should be called out early in the consulting piece. The fact of the matter is, what may seem like a trivial user experience change to the casual observer, may be a significant piece of development work for you, your UX guys, and your developers. Calling these things out early will give you the opportunity to talk about scope, budgets, or simply get an agreement up-front about how it is.
The Lack of Formatting Flexibility in RCDC’s
An RCDC is essentially a bunch of XML which tells the FIM Portal what items, representing what attributes to present. The FIM Portal takes all that information and presents it to the user in the only way it knows how. What this means, is that each item laid out in the XML, renders itself as a single item in the UI.
The problem here is that there is not much flexibility in how the portal will render this item. For each control on the page, it will appear on its own line, and each control will appear one after the other in a stack, in the order you define them in the XML. In demoing the portal in the past and showing off these screens, I’ve had project stakeholders say things like “That’s fine, but just put those options in two columns” or “Great, you just need to indent the options below that first one to show they are related” or “Group all those options tightly together across the page”. Queue the shocked look when the answer is “Easier said than done”.
Nothing Happens Until You Hit Finish
Typically in FIM, we have forms (RCDC’s) which we use to enter a bunch of information, then do something with. We flow that information somewhere, we kick off a workflow based on the data and we add or remove sync rules. If we didn’t want to do something useful with the data, it’s fair to say we don’t want it. The issue is that nothing happens with this data until we hit that finish button. The forms are essentially static. Yes of course we can use auto-post-back to make the forms more dynamic, but how useful would it be, if when we are creating a user account, the form could query Active Directory and let us know that there happens to already be a Gordon Shumway in the directory that is going to result in that users account name being gshumway1? Perhaps someone has already created that exact account in AD directly, and we’re actually busy creating a duplicate? This is just one example where real dynamic forms would be advantageous, I’m sure based on your experience and your customer’s needs, you could think of dozens more.
Adding and Removing Users from Groups and Sets is Clunky
When adding and removing users from a set or a group, we have a whole stack of page real estate dedicated to this one task. Why? Because you need the box showing the current group membership, you need the box and corresponding buttons for adding users, and you need a box and corresponding buttons for removing users. If we forget for a minute that this is what we have become used to in FIM, we quickly realise that this is not pretty. Considering that adding and removing users is a task which would typically be assigned to IT Admins who are probably most familiar with performing this task in Active Directory Users and Computers, you can see how the new interface we are presenting may seem like a step backwards.
The Date Picker is not a Date Picker
For the longest time on the internet, we’ve known that if we need to enter a date into a website, we click on the date field, and a date picker pops up. We can quickly select an appropriate date quickly by evaluating what day of the week the 20th of March happens to be in 2015. Default FIM behaviour does not afford us this opportunity, and instead we need to enter in a date in a specified format. Once again, if we consider our audience here is likely to be either IT Admins, or even end users, this is going to seem like a backwards step.
So What Can We Do?
There are many options for customising the portal to increase usability and to tighten up the interface. We can plug in community provided features which replace the calendar picker, we can play with the CSS behind the pages and change the feel of the portal with our own custom themes, and we can strip down or beef up the RCDC’s to include or exclude the parts we require. Ultimately, we should take a step back at the top of the engagement and ask the basic question: “Who is going to use this portal and what are they going to use it for?” and take a realistic approach by thinking like the end user.
If the requirement is for an admin to be able to manage user accounts and nothing more, is the FIM Portal really the best solution? How much effort would be required for a Developer and a UX guy to spin up a tailored solution to perform this task? How different might that time be, compared to the time taken for an Identity Management Consultant to hammer the FIM Portal into the required shape? We can still use the functionality of both the FIM Syncronisation Engine and the FIM Service to handle the workflows and data flow, so all we have to gain is a better user experience, and a happier customer, right?
Conversing with my colleagues on this topic, it seems one of the reasons why clients shy away from complete customisation in this area is the perception that a custom solution will be less supported, or supported only by the vendor who installed it. How could this be true? If we are writing a custom front end to known Web Services end-points, and supplying the source code and appropriate documentation to the client as part of the engagement, where are the concerns? Code is code is code.
My TL;DR (Too Long; Didn’t Read) line is this: Start thinking about the FIM User Experience now and keep your clients eyebrow height at an appropriate level.