UX Lab: Changing the way you handle CRUD workflow
I often see a lot of consistent patterns in the way applications are being built when it comes to generic create, read, update and delete (CRUD) workflows .
The usual pattern is that a screen starts off with a add/remove action followed by a very large datagrid and probably some paging. A user would then refine the datagrid’s result set, make a selection either inline on the datagrid or opens a modal via an action like double click which then presents the end user with a more detailed view of that record. This is probably so generic in the way it’s being approached that I’d probably dare say nobody’s really sat down and thought about its actual practicality — as it seems to be the unofficial standard for screen design (well the bloody apps I see day in day out anyway).
This pattern for me isn’t something I’m a fan of, maybe because it’s so common now that I simply crave for an alternative approach? I crave this alternative because I feel at times the workflow in itself seems oddly backwards?
The part that catches me out, is the overall approach taken. For instance, the end user has come to the said screen to get a detailed view of a record — maybe a summary, but doubtful. They wade around in the various amounts of turn-keys (filter settings) until they settle on a pattern of data that they can then scan (hunt/browse) for and proceed to get the modal open for a detailed view. It appears that majority of the practical usage is saved towards the end of the process pipeline? in that getting a detailed snapshot of the record seems to be an extension to the UI instead of probably being the focal point of the UI?
Armed with this style of thinking, today, I set out to try an alternative approach to the way this workflow could work. I decided to simply inverse the workflow, in that take a typical Security (add/remove users etc) workflow and try a different approach (see below).
The idea is that when you click on “Find Users” the screen opens up to your summary view, in that since I’m logged in it reflects back my entire account profile found within the system. There are then a number of actions one can take in and around deciding on what to do next but the main key piece here for me, is well I’ve shown you the end point up front — I’ve seeded a contract with the end user around what screens will look like once they’ve found a user of their choosing.
How do I change the user from me to someone else?
The change button in this screen kicks off what is traditionally the first screen, in that if the end user clicks on [Change..] a modal will open over the top, presenting the end user with search criteria. The user then fires up some search results and can specify filters for their search. Once the end user has found the right user of their choosing, the modal closes and the original security profile (you) switches to the person in question.
Ok, I’m kind of with you, but what benefits does this give then?
I personally think it shifts the user into a more focused approach to how they handle the workflow. It’s quite easy to snap in a datagrid + tree control and hit F5/Ship. This approach in my opinion approaches the workflow differently, in that it asks the user to be specific in what they are really after. If you’re in the User Administration area of this application, then what is it you want to do? Manage users is probably the typical response here. So, let’s let them manage a User in a more focused fashion by exposing other areas of interest in a screen that’s more content specific and less cramped / buried in a floating modal.
The typical “list all users” with paging approach is quite unnecessary real estate to reserve for prime time, as well it’s merely a stepping stone to the end point. It’s almost throw away in the task process should the user want to change “John Doe” password or check when that user last logged in etc.
You could even approach the way I’ve done it differently, by simply providing a search box at the top with a label “Find User..”. Once the user types in “Scott Bar..” (auto complete) like experience fires, but instead of a pulldown it could then go off and grab all twitter feeds, flickr photos, facebook profiles, linked profiles etc and just start showing them on screen. This kind of approach is more helpful when you’re trying to figure out who that “Scott” fellow was last night, as now you’re meet with multiple forms of media to help guide your search detective skills down to a more informed end point.
The point is, it’s taking the equation of CRUD and flipping it into a more interactive experience. Why invest all this time and energy into some of the new UX platform’s out there only to use generic patterns like the original one mentioned in this post? How can you evolve this pattern further and where can the users gain in terms of data + contextual view beyond what they’ve typically been given.
It’s a new world people, try and break a few things as when you break something you in turn are rewarded with knowledge on where risk/failure can occur. Much more informative approach than “well everyone else is doing so i assume it works” policies :0
To be tested..
