views:

120

answers:

3

I have a large, PHP-based CMS that manages web pages. All items are organized in a tree structure. When I edit an item, the "back" button usually points to its parent item. So, the usual workflow is navigating through the tree.

Now every now and then, the need arises for a workflow that "jumps" to other items without regard for the structure.

For example, when a user is editing a web page, they may want to open the template the page is attached to (another item in a completely different branch), make a change there, and when clicking "save" expect to come back to the page they were editing.

At the moment, I solve this using

domain.com/admin/template/edit?from=/frontpage/edit

where the "from" variable determines the target URLs of the "save" and "cancel" buttons.

This works up to a certain point when the path becomes too long and complex. For example, what if the user

  • edits a page
  • opens the attached template
  • previews that template in the front-end view
  • and then expects to be seamlessly taken back to the page they were editing?

Right now, the "history" ends at the last item so that when the user returns from the front-end view, the link to the original page is lost, and they have to search it by hand.

Another problem that can happen quickly is that the GET URL containing all the "from" values becomes too long, or totally chaotic:

domain.com/admin/template/edit?from=/frontpage/edit&from=/somepage/edit
&from=/template/preview&/from=template/edit&/from=template_preview ...

(you get the drift)

I have solved this elegantly by opening separate windows in the past, but I really want to implement a seamless one-window workflow that works universally, mainly because multiple windows tend to confuse users.

How do you solve this?

Have you implemented a robust "unstructured" navigation that works well with multiple windows open (=one user doing multiple different things with different navigation paths)?

How do you go about this on the user interface side?

The best approach I can think of is passing on a "from" value that points to a temporary record in a database or session. That record contains all the information about the current path, and can thus always provide the right "back to page x" value.

What I would like to hear most is experiences from people who have successfully implemented this, and how they did it.

A: 

As long as you're only needing to backstep once, why not pass in whatever linkback page IDs you want whenever you produce the page you're jumping to?

John at CashCommons
There can/will be multiple backsteps and putting the whole chain into GET variables quickly exceeds the allowed 1024 bytes.
Pekka
+2  A: 

Just a couple suggestions

Preview Problem: preview in an IFRAME, so the history doean't get lost?

Cluttered URL problem: If you have some sort of key for each page, other than the URL path

(i.e. /frontpage/edit = 952,
/frontpage/edit&from=/somepage/edit = 763,
/template/preview = 651,
template/edit = 612,
template_preview = 866 etc.)

you could string them together in the PATH_INFO like so:

domain.com/admin/template/edit/952/763/651/612/866
Fenugreek Femtosecond
The path idea is very good. I think I will go with that.
Pekka
+2  A: 

You could build a stack of visited pages for the session as the user clicks around, pushing on a new page each time the open it, popping off when they click back. Store it as a session variable.

The trick then is to always check their referrer string, since they may also use their browser's back and forward buttons. If their referrer string isn't at the top of their stack, you'll have to scan the stack for it to see if they manually backed up to a previous page.

keithjgrant