Looking at Applications Differently
Looking at Applications Differently
Zone Leader, John Vester, talks about the benefits of implementing a queue-based approach over the standard view approach to enhance end-user productivity.
Join the DZone community and get the full member experience.Join For Free
Spending time with a user experience (UX) designer earlier this year, our discussion focused on a different way of looking at applications. My goal with this article is to share these thoughts in order to provide an alternative view for your new application design or conversion.
The Traditional Application
In the past, one of the initial design tactics for a new or converted application is to gain an understanding of the data model that will be utilized. There is always an understanding of what the application will be required to do, but understanding what needs to be ultimately persisted, and the underlying structure, are typical early design topics.
With the data design in place, the approach that has been popular is to provide a view into that data from an application perspective. Take the following example that provides a summary of customer renewals for a fictional business:
The common pattern is to provide this list to users so that they can easily find customers as part of their daily tasks. Depending on the design of the application, in order to see additional details (or update the record), I would single/double click the row I wish to work on. In the example above, it might be the GHI, LLC customer - since their contract is in a Past Due state.
As developers, additional views, filters, or even a search form could be added to provide faster access to the data in our example. Some teams may request a daily report, driving the work and task load of teams using the application.
The New Approach
While the traditional approach is powerful and provides access to the data, it always isn't the best approach for end-users of the application. In the example above, the users could need to select a dedicated view, apply a filter, perform a manual search, or wait for a report to drive their workload. Especially when the application contains a significant amount of data.
The new approach that I discussed with the UX designer is to provide the users with a work queue when they log in to the application. Instead of seeing the view above, perhaps they see something similar to the example below:
As a user of the application in this simple example, I would automatically have a list of tasks prepared for me when I log into the application. Using business rules defined in the application, tasks would be prioritized automatically allowing me to focus on the items with the largest impact first. In the fictional example above, getting into contact with the GHI, LLC customer is a primary focus. The queue-based approach would allow me to see the name of the company and the phone number - which in this case is enough information to get the task started.
Not shown in the example above, would be buttons on the queue item to obtain ownership of the task. This way, other team members immediately understand the task has been assigned and can focus on the next most important task at hand.
The new approach noted above is not much different than the Agile world developers have worked in for years, especially Kanban adaptations. In a Kanban world, the backlog of pending work is prioritized, so that team members understand what task they need to work on when ready for another task. In the majority of applications, the prioritization aspect can be determined programmatically, using the underlying data within the application to make decisions.
I believe the traditional approach of providing table views still has a need in modern application design. However, when it comes to use-cases that have a workload which can be programmatically determined, implementing a work queue into the application should provide significant gains over the process to filter, search, or process work from a manually-driven queue.
Have a really great day!
Opinions expressed by DZone contributors are their own.