Rethinking design when migrating applications
As part of helping customers move from the Clarify Classic Client to Dovetail Agent, we often assist in porting their customization from Clarify forms and ClearBasic code into Dovetail Agent code (HTML, C#, CSS, JavaScript).
It’s easy to fall into the thinking that we want our customizations within Dovetail Agent to look and behave the same exactly as how they are within the Clarify Client. While there are advantages to this (familiar app, less training, etc.), I think it’s worthwhile to revisit your customizations and take the opportunity to improve them where it makes sense.
Within Clarify, there are some constraints that often cause customizations to have to be done a certain way. Within a web application like Dovetail Agent, we also have some constraints, but they’re not typically the same constraints that we had with the old Clarify Client.
Tabs
A good example of this is tabs. It’s real easy to add tabs to forms within Clarify, and it’s easy to end up with tab explosion. In addition, tabs aren’t dynamic – meaning that a tab would always be present, even if it’s not needed in a certain context. Here’s a more specific example that I’ve seen a lot over the years – a case form with 10 tabs, lets say 4 baseline tabs and 6 custom tabs. But for those 6 custom tabs, only 1 is applicable for a case – often based on the case type. So if the case type = “Benefits”, then the user would fill out data on the Benefits tab. If the case type = “New Account”, then the user would fill out data on the Account tab. But, since tabs aren’t dynamic in Clarify, the user always sees all of the tabs. It may not sound like a big deal, but it is. It confuses users, increases training time, and the visual weight affects how users feel about using the application.
Tab Explosion
Not a case form, but still an example of tab explosion:
Dynamic Tabs
We don’t have this same constraint within Dovetail Agent – tabs can be dynamic. So we can change what tabs are displayed based on what the Case Type is. Here’s a simple example:
From the user’s standpoint, we’ve re-thought the design and simplified the user interface while still providing the needed functionality. And we can re-use this same pattern on other pages within the application.
Edit a Closed Case
Another example I’ve seen recently is a completely custom, very complex form built within Clarify for updating values on a case after the case has been closed. So we have the normal way of editing case values, and then an entirely different mechanism for editing a case after its been closed. Part of the reason for this is that it can be difficult to work around the constraints within the Clarify Client to do what you want. So we end up with complex workarounds that are difficult to use, and add more code that needs to be maintained.
Instead, we can use the same edit case page that we already have, and have it function how we want. For example, we could allow a case to be edited after it’s closed without re-opening it. This could be privilege-class controlled. And we could add additional activity logs to indicate exactly what happened and when and by whom. This would make things much simpler for the users, while still maintaining the desired functionality.
Edit a Case You Don’t Own
Another example that I discussed a few years ago is how we can re-think the design of modifying a case you don’t own, which we used to use the custom Temporary Yank functionality for.
Story: As a supervisor, I need to be able to modify a case I do not own so that I can assist the case owner as needed.
Notice that there’s nothing in my story about Temporary Yank. It’s a story. Not a solution. Temporary Yank was a fine solution to the story on the Clarify Classic Client, because of the limitations we had with the Clarify Client, specifically, the ownership paradigm was baked into the C code of the product, and extremely difficult to change. However, we don’t have those same limitations with fcClient.
Summary
Those are just a few examples – there are many more.
One of the many things I like about helping companies move to Dovetail Agent is the opportunity to improve the design and greatly improve the user experience. And most of the time, the cost to do so is negligible, as many of the old constraints we had to deal with are now gone. It just requires some desire and some design thinking.
