Saturday 11 August 2012

Modals, Edits and oOjects

Have been looking into standard objects (contacts mainly) and editing lately and have been wondering when it is best to use Modals, or Windows vs actually pushing content into a new viewport in page. Most of these approaches tie into the development widgets at Kendo UI for Web and are quite different in their approach.

Take this instance of editing a contact, a user would obviously want to search for the contact first most interfaces handle this the same way, but after they select the contact they wish to view or edit the attributes of said contact. This is where the similarities end and different interface designs take place.

Some allow you to edit directly from where you searched inline. 


Inline Edit is great for data sets where the user only really needs access to a few fields to edit the table directly and this increases speed of users edit. However, this also means the user hasn't really established a direct view connection with the object (row) in question and may feel like they are simply editing an excel table. Also if you start having more then 5-6 fields the user can get lost quite quickly editing from left to right to complete the row. I think users would prefer a long page with a lot of elements then a wide page where the fields are listed left to right, harder to read. All in all good for maybe product price adjustment lists which don't have many fields and allow you to edit but for a contact which has lots of data not really user friendly.


Others may use a Popup Edit Modal.


Popup Edit allows the user to actually enter a view for the object in question where they can edit the data. This edit view can be presented differently from the standard search view and will make the user feel as if they have 'opened up' the object in question. This means that your search view can be really simple and can avoid having lots of text as the editing is not done inline. 

This however, can fall apart, if you have a variety of object links in context to the current object. For example "I have a contact which has actions linked to it, in the edit modal, I would like the user to be able to view the actions in the same modal" having this in a window could create confusion with the user as they could open the modal at the contact search screen, but lose context as they navigate across to the action object. If you are going to use a modal for editing an object it cannot be too complicated, should be a single screen should avoid cross object issues. If you want to create a view where a user can view a contact and all the actions they have linked then it should probably be part of your contact view, not the edit screen.

Custom Edit Screen


A Custom Edit screen can be created and is probably the approach of choice in most situations and is the most popular. These usually mix in read only structure with editable fields, this allows the user to have a nice view of summary information about the object and also a separate area for editing of details, all of this is contained in the same view of the object, just containing specific areas for edit.

The approach also allows for cross object linking so a user could navigate from a contact to a linked action and change object views without being confused as to where they are in relation to the objects they are working on.

Overall

These approaches are definitely not the only ones available as a developer but I think it is worth having a look at each, it all relates back to your audience and what the users are looking for in the app. Custom Edit is obviously the most used, but in some cases an inline or window might be best for the user.

No comments:

Post a Comment