Interaction for each row in a long list or table

11 May 2010 - 3:48am
4 years ago
4 replies
867 reads
dahiya.manisha
2010

Hello...

I have a confusion here...

Scenario: there is an intranet application; for its admin interface where the admin will view the user list which can be long enough. Each row displays the details for a user.

There will be actions like "Add new user", "Edit user" and "Delete user"; as the last two action can be performed on any of the rows.
Instead of giving links for Edit and Delete along with each row, action buttons are given at the top and bottom of the list.

Wanted suggestion on the point that is there any guideline of usability which says that when you give global action buttons, the height of the list/table should be fixed; so that the buttons are displayed always?
And to view more in the list either there is a scroll within the list or pagination.

Also, if the list is long you can do pagination for e.g.; 20 user rows on each page and the action buttons can be given both at the top and the bottom of the list to reduce the motor load.

Please suggest.
__________________________________________________________


Another point here is regarding freezing the header in long lists:
That incase if the list has data like pure numbers; then freezing the header part should be done so that one can makes sense of the numbers as in they belong to which category by seeing the heading.

But if the data is like name, email id, role, contact number; then it does not require the header to be displayed always while you are scrolling as the data itself is explicit enough.

Does this make sense? If not, please suggest...

Comments

11 May 2010 - 5:50am
adityadipankar
2010

I faced a similar problem a few months ago while designing this: http://www.pagalguy.com/rankings/2010/national.php#overall

Freezing the header in a long list seems to be a more viable solution here as the list seems to be ever expanding and though you can give the user the freedom of choice on the number of entries to be displayed, there's only so much he can scroll. Furthermore, scrolling to the end and then clicking on 'Next n' repeatedly is another undesirable action.

What do you think?

11 May 2010 - 7:50am
puja rastogi
2007

Dear Manisha,   Global action bar should be there in such kind of applications, as this the most common and acceptable pattern for these widgets is to have Fixed rows and pagination in the bottom. Header could have search box and even pagination pattern can also have search box which can help admin to reach any of the user on any of the page,   specifically you can chunk your datas into different pattern dependent high usage, alphabetically, postion wise ( hierachy)  with the respect of nature of your application.   Not neccessarly Header would have details of name / email id/ contact number, However global controls on the top and bottom of table can be one possibility or once the user hovers to any of the row and edit/delete control appears....   Hopefully this would give you some clearlity,     Puja   Interaction D

From: dahiya.manisha <dahiya.manisha@gmail.com>
To: puja9980@yahoo.com
Sent: Tue, 11 May, 2010 4:15:31 PM
Subject: [IxDA] Interaction for each row in a long list or table

Hello...

I have a confusion here...

Scenario: there is
an intranet application; for its admin interface where the admin will
view the user list which can be long enough. Each row displays the
details for a user.

There will be actions like "Add new user",
"Edit user" and "Delete user"; as the last two action can be performed
on any of the rows.
Instead of giving links for Edit and Delete along with each row, action buttons are given at the top and bottom of the list.

Wanted
suggestion on the point that is there any guideline of usability which
says that when you give global action buttons, the height of the
list/table should be fixed; so that the buttons are displayed always?
And to view more in the list either there is a scroll within the list or pagination.

Also,
if the list is long you can do pagination for e.g.; 20 user rows on
each page and the action buttons can be given both at the top and the
bottom of the list to reduce the motor load.

Please suggest.
__________________________________________________________

Another point here is regarding freezing the header in long lists:
That
incase if the list has data like pure numbers; then freezing the header
part should be done so that one can makes sense of the numbers as in
they belong to which category by seeing the heading.

But if the
data is like name, email id, role, contact number; then it does not
require the header to be displayed always while you are scrolling as
the data itself is explicit enough.

Does this make sense? If not, please suggest...

11 May 2010 - 11:52am
nixkuroi
2010

Have you thought of having a floating header that slides down the page as you scroll?  Also, you can have a mechanism that automatically gets more data when the bottom of the page is scrolled to.

This eliminates the need for adding pagination controls except, perhaps for a page number indicator in the header that can tell what page a user has scrolled to, and perhaps can be changed to load more data.  

The header, after it has started to scroll, could fade a bit to allow for viewing of all data, and then fade in when clicked or moused over.

 

11 May 2010 - 10:50pm
C K Vijay Bhaskar
2009

There are patterns available that describe the various representations of data table. Do note any activity like modifying the credentials of a user will invoke an action that is based on the primary key tied to the user. This will be a unique entity and the possibility of modifying/editing multiple users usually happens in rare cases. The interface design should mimic the process that the admin department has to follow in order to add, delete or modify the users. The interaction of the screen should also mimic the process as the department follows so as to make the interface more usable.

In my view, providing a floating header, etc are 'nice' to have functionality, but may not be compatable for all browsers and personas (assuming that there is a possibility of technology limitation and a possibility of people with different physical disabilities to access this application).

From the scenario that you have mentioned, there could be a possible situation that multiple users can be deleted at one go, but the adding of new users have to happen one at a time. Also the editing of the user credentials will have to happen one at a time - unless there is a need to change many users from one group to another based on their access rights etc.

So, as mentioned, the interaction on the screen will have to be specific to mimic the process that is in place in the organization. In many cases, the change in the user name, adding, deleting etc is usually triggered by another department and the admin is involved in only getting the job done - unless the application that you are designing is specific to the access to various internal admin systems - even here, they have to follow a specific process to add, delete, edit & update the user details.

Unless these aspects of the flow of the actual process are clear, it would be difficult to provide an optimum solution.

You can still google for UI design patterns and I am sure you will be able to find a solution that fits into your scenario.

Syndicate content Get the feed