Techniques for redesigning convoluted UI

Question

I'm sure you've all seen them. Line of Business UIs that have logic such as: "When ComboA is selected, query for values based on that selection, and populate Textbox B", or "When ButtonC is pressed, disable Textboxes C and D", and on and on ... it gets particularly bad when you can have multiple permutations of the logic above.

If presented with the chance to redesign one of these lovely screens, how would you approach it? would you put a wizard in front of the UI? would you keep the single screen paradigm but use some other pattern to make the logic of the UI state maintainable? what would be the process you use to determine how this would ideally be presented and implemented?

Not that I think this should matter for the responses, but I am currently presented with just this "opportunity", and it's an ASP.NET web page that uses javascript to respond to the user's choices, disable controls, and make ajax calls for additional data.

Answer 1

Start with the KISS principle, and work from there. Don't over-engineer the solution, and try to think about the problem from the user's POV. Your first impression of what would make a good layout is probably close to what you should be building, as a good UI is intuitive.

That being said, single screen versus multiple screens, JavaScript or AJAX, it doesn't really matter. If it looks good, is easy to understand, and behind the scenes, is well commented and written with clear code, it works. It should be maintainable, so aim for modular code blocks with clear functionality.

Answer 2

Something you might want to look at is whether some of those dependencies don't imply that while looking similar and serving the same functions these elements should be split out over multiple pages that are similar but actually different. Someone maybe grouped these onto on page because there were enough similarities.

If you can try looking at the problem as if it were not implemented at all, how would you structure the user interface if you had to implement it now. If it is too radically different and existing users would have major problems, you might have to compromise. But as Elie said look at it from the users view. They are the ones that have to work with your product.

Answer 3

I think what is most important is the user experience and to a lesser extent the maintainability of the code. On the web I try to minimize the roundtrips as much as possible so I'm not sure that I would take a wizard approach since that would lead the user through multiple pages or require replacing nearly the entire page via AJAX (which just seems wrong). I typically work with my customers to capture the functionality that they require, though I aim at the functionality, not the implementation. I might mock up a few examples to show them alternatives or just hand draw them on a whiteboard to give them ideas. I don't mind doing "hard" or "complex" things in the app if the result is a much improved user interface. Of course, I make it as simple as I can and definitely use good practices, even in Javascript.

Answer 4

I would model the state of the whole UI on one object. That object should keep track of the state in which each UI object should be in, including the list of options of a combo box (and which option is selected of course).

That means that having one state object you can correctly re-draw the whole screen and not end up in broken states on the UI. Of course, refreshing all the components each time anything changes is not the way to go, so I would refresh them on callbacks from each of the setters in the state object. This would also allow you to have two UIs over the same state if you ever want that.