Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I have a website where users can search for resources, whether they're other users, or accounts, etc. and when they get a list of results back they can click on that resource and go to a page with information about it. If possible I'd like to think about this without the use of JavaScript.

On the page with information there's a delete button. My question is similar to this one, but the second part wasn't answered. My question is: when delete is clicked what page should the user be navigated to?

Should they go back to the search results? If they go back, the deleted resource will still be in the list because the browser has cached the GET request. What if they navigated to the resource via URL directly and didn't search for it? Is this a problem?

Alternatively should they be redirected to a page with a message saying that the user has been deleted? If so and they click back in the browser, they'll go to the page with the deleted resource.

I realise this question is influenced by browser implementation and web semantics, but I get the feeling there's a simple solution to do with deletion that we're missing. Maybe the delete button shouldn't be on the page for the resource at all...

share|improve this question
    
So if I understand your question, they can delete a resource ? –  Mervin Johnsingh Dec 12 '13 at 11:06
    
Yes, at which point it is effectively removed from the system. They can't see a page with the resource information saying that it's deleted. –  NickL Dec 12 '13 at 11:17
    
So any random user can delete the page ? –  Mervin Johnsingh Dec 12 '13 at 11:23
    
Not exactly, but it doesn't really matter. If they can see it they can delete it. –  NickL Dec 12 '13 at 11:29

3 Answers 3

up vote 0 down vote accepted

The question you cited discusses confirmations and undo, so I hope you have either one for deleting something that is going to be completely deleted, as you say.

Other than that, you've stumbled across an issue everyone faces when creating transactional applications (changing state/data, I mean) on the web, which was invented to be a hyperlinked network (without actions to change, which is usually not stated explicitly). So any solution you create (and we can recommend) is a workaround due to the fact that transactions do not work well in the web.

I guess my recommendation would be to change the resource page to indicate it's now a deleted resource (inactive, uneditable, together with an undo button?!), and the leave the choice of navigation to the user: Whether BACK is used or some other navigation link on the page, the user will know which task is next. After triggering the deletion, the resource will not be reachable from elsewhere, but the user triggering the deletion can still undo. Once this page is left without undoing the deletion, the resource can be deleted finally.

The issue here is that the "deleted" state of the page should not have a BACK button which leads to the "regular" state. Ajax should allow building this behavior.

share|improve this answer
    
I appreciate your detailed answer. I would have preferred there to be a way to do it without using JavaScript, but that's the route that I've had to go down. –  NickL Dec 13 '13 at 10:38

Once a task is completed, user should be taken back to the place from where he had triggered the task. Navigation should be the result of the user's selection, rather than a system choice. This is also done to allow the user to continue using other options on the page, from where he started.

I see you have a technical problem, generally when you are referred back to a page, the page refreshes. There might be some setting that allows you get over the caching issue.

share|improve this answer

Look up the Post-Redirect-Get pattern.

After the resource is deleted, you should redirect to the URL from where they were, as stated already. This would cause a new GET request for that URL, which in this case would be the search results page. The search results page should not be cached, as its a new request, and isn't done via pressing the back button in the browser.

If they enter the URL manually of the deleted resource, then that should be handled to provide a resource not found page or similar.

share|improve this answer
    
The issue is that they haven't clicked delete on the search-results page, they've clicked it on the resource's page. If I redirect back to that URL it will show something like a 404 for instance, which looks like an error has occurred. Unless you're suggesting I provide a return-URL when getting the resource's page? This seems to be leaking information about the page... –  NickL Dec 12 '13 at 14:36
    
I believe you've misunderstood me. On the resource page, e.g. site/user/1, you click delete. The server deletes the resource. Since you always navigate to the resource's page from a search results page, or a user listing page, you then redirect to site/user, which is the listing of users, or the search results (if search results, then yes you would need to keep track of that somehow, return-URL or other method). If the user closed the browser, and now entered site/user/1, they should get a 404 resource not found page. –  jamiebarrow Dec 13 '13 at 15:40

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.