Dumb redirects interact poorly with forms

The current design for an improved role editor is still in prototype, but this is what it looks like:

Selecting a role to delete

The implementation of role removal is problematic, which I will be illustrating.

Upon pressing the Remove button, this confirmation form is unhidden using JavaScript:

Confirming delete role

After pressing OK, the form is submitted back onto the same page. The user is redirected to another page (admin?action=remove_role) if the role is still in use:

Reassign roles before removing

Otherwise the user gets a reloaded copy of the original page (admin?action=edit_roles):

Successfully deleted role

There are a number of problems with this implementation:

  • On the server, the pages for “action=edit_roles” and “action=remove_roles” are in separate files. Looking at remove_roles, it is not immediately obvious that it needs to process form data from edit_roles.
  • When the edit_roles page redirects to the remove_roles page, all the form data is lost; the browser issues a fresh request to remove_roles. The remove_roles page gets the role in question through the URL, e.g. action=remove_roles&role=viewer. This is not scalable to a large number of fields that must be preserved in a redirect.
  • If the role to be removed is still in use by some memberships, then after the user hits the confirmational OK button, he gets the reassignment page but the role is not yet removed. At the cost of extra complexity, this can be resolved by embedding the “which roles can be removed immediately?” information on the edit_roles page, so that JavaScript knows when the confirmation should be suppressed.
  • The DrProject web interface typically shows acknowledgement messages for administrative commands. So if I make the role removal subform submit to remove_roles, then it would redirect back to edit_roles if the role was immediately removable. But the page would also need to pass the name of the deleted role back to edit_roles so that it can display the acknowledgement message.

One way to eliminate the redirects is to have all the possibly displayed forms put into one page, having the server cue the appropriate form on demand. This idea suffers from excessive complexity.

Another approach is to use AJAX techniques so that the browser does not move between pages at all.

Mixing Web 1.0 techniques and Web 2.0 techniques can result in more problems than using either set of techniques exclusively.

Advertisements
Explore posts in the same categories: DrProject, Uncategorized

2 Comments on “Dumb redirects interact poorly with forms”


  1. […] Qiyu Zhu is working through the design of a new role editor, and believes that dumb redirects interact poorly with forms. Suggestions, […]

  2. Eric Says:

    A possible solution used by my current platform involves keeping an array of form data in a session variable. On each page load, that form data, if it exists, is loaded as if it were actually submitted by the browser, then the session variable is cleared. Certain pages load fake form data straight into the session before redirecting. However, its primary purpose was to preserve actual form data across a session timeout and re-login, after fielding a few complaints from, among other people, the company owner.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: