MarkUs Blog

MarkUs Developers Blog About Their Project

Simple Grade Entry: Table view performance issues

with 4 comments

As I’ve been working on the table view for grade entry last week and this week (there are still some kinks to sort out, more on that in my next post), I’ve been noticing some performance issues that I think we might want to deal with before we let instructors use this table. One thing that I needed to decide was whether or not each table cell should be saved right as the instructor enters the mark or if the instructor should enter a bunch of marks and then hit a “Save” button. I decided to go with the “Save” button option. My initial plan was to display the entire table on a single page. However, I’m finding that:

  1. It’s difficult to navigate
  2. This page can take a long time to load or save

Severin had suggested earlier that we could implement some sort of pagination. I really like this idea. Here’s what I’m thinking:

  • Maybe we could implement pagination alphabetically, by last name (eg. At the bottom of the table, we could have links like “A-D”, “E-J”, etc.). This would help to reduce the number of rows that get displayed on the page at a time. We probably wouldn’t want to implement pagination using numbers because if an instructor wanted to enter grades for a particular student, he/she would have a hard time figuring out which page contains the desired student.

Any thoughts about this?

Written by Farah Juma

December 3rd, 2009 at 12:39 am

4 Responses to 'Simple Grade Entry: Table view performance issues'

Subscribe to comments with RSS or TrackBack to 'Simple Grade Entry: Table view performance issues'.

  1. Hey Farah,

    The kind of pagination you propose sounds like a very good idea. I’d go in this direction.

    Regarding saving of data/grades:
    Thinking of it, I believe it would be better if we did little AJAX calls for each field entered. If I were an instructor/TA and I would enter grades and press the save button after 1 hour of entering grades (I’m exaggerating, but still), and something goes wrong while saving, I wouldn’t be very happy when all the data is lost. Thus, I’d do little asynchronous requests, for each presenting the “Spinner” image when working (or some similar feedback) and reporting it in some way that the item has been saved. Not sure if we need to report the successful save, though. I see this to be a little challenge UI wise. Maybe we can work something out with icons. We should definitely indicate to the user, if something went wrong while saving a grade cell.

    Severin

    3 Dec 09 at 5:07 pm

  2. Hi Farah,

    For performances problems, I would look at the DB indexes. If you need help on it, let me know what queries you have to do and I can help you to see if all required indexes are implemented.

    melagaud

    3 Dec 09 at 9:05 pm

  3. […] Created a blog post related to some performance issues with the Table View (see http://blog.markusproject.org/?p=935) […]

  4. […] in December, I blogged about performance issues related to the first version of the grades table. Two of my concerns were that the table was […]

Leave a Reply