Thread tracking page behavior (for lack of a better way to describe it, sorry)

Mar 06, 2010 11:41


Title
Thread tracking page behavior (for lack of a better way to describe it, sorry)

Short, concise description of the idea
After selecting and saving the options to track a specific thread, I would like the page to redirect to either the original page (as was the original behavior) or an intermediate one, instead of the current behavior to redirect to the entire Manage Notifications page after saving the thread tracking options.

Full description of the idea
Before the Notifications system was overhauled a few weeks ago, when someone tracked a specific thread, they were returned to the original page (the one containing the thread in question) they came from after saving the options. However, the behavior now is for the page to redirect to the entire Manage Notifications page (http://www.livejournal.com/manage/settings/?cat=notifications) after the user has saved their options to track the thread in question. There are at least two problems with the current behavior: 1. The user may want to return to the page they were previously viewing and may have no need nor desire to manage any of their other notifications, and 2. The Manage Notifications page, which can contain up to 1000 individual events for those with Paid/Permanent accounts, can get large and unwieldy to load, needlessly wasting a great deal of bandwidth in the process.

I (and, from what it looks like, a lot of other users) preferred the original behavior of redirecting to the original page on which the tracked thread was found. Thus, I would like to have the behavior reverted to what it was previously.

Alternatively, since there may be users who prefer the current behavior, perhaps implement a simple "intermediate" page that contains two links: one to return to the original page, and one to go to the Manage Notifications page. That way, it lets the user decide which page they want to visit after tracking the thread, while making it convenient for them to do so.
An ordered list of benefits
  • More convenience for the user
  • Much less wasted bandwidth for users who don't wish to load unwanted script-intensive pages
  • If the developers choose to create the "intermediate" page, more freedom for the user to decide which page they want to visit after tracking a thread
  • And others I'm not thinking of
An ordered list of problems/issues involved
  • As always, the time and trouble for the developers to code and implement this
  • If the developers choose to revert to the original behavior, this might be less convenient for users who prefer the current behavior
  • If the developers choose to create the "intermediate" page instead, there would be one extra (albeit relatively small and non-script-intensive) page to load
  • And others I'm not thinking of

user interface, usability, message center inbox, § no status

Previous post Next post
Up