3

Imagine a situation where there is site with urls

somesite.com/events

which is a list of events

and

somesite.com/events/event-name

which is a detail of particular event.

Now due to some technical limitations, it would be better to have a slightly different url for the detail, particularly

somesite.com/event/event-name

notice the missing s.

Now the worry of some of our team members are, that there is actually a situation, where user sees the detail url(somesite.com/events/event-name) on the web/facebook/whatever and instead of going directly to that url, he deletes the /event-name part, hoping to get to the list of events.

Do you think is situation is worth considering? Does a considerable number of users behave this way?

  • 1
    I can't speak for anyone else but it would frustrate me to no end. – Mayo Apr 24 '15 at 20:57
  • 4
    I'm guilty of treating URLs like file system hierarchies and trying to "go up one level" by deleting part of the URL. I'm pleasantly surprised by sites that give me what I want, and a little disappointed by sites that don't, but it's never been a deal breaker as I can recognize it's a power-user quirk. It depends on your target audience and how deep and polished you want to take your UX. – Nathan Rabe Apr 24 '15 at 21:07
  • I think it would be best to look at the problem from the perspective of URL changes and URL redirects. Changing URLs happens with websites, but it is important from an SEO and user perspective (user clicks old link) to have redirects in place so that the old links take users and bots to the new URL. With proper redirects in place, the question of user behavior is a non-issue. – Benjamin S Apr 24 '15 at 21:34
  • +1 I never really thought about this until this question was asked. I wished I had done this in a few apps i worked on in the past I think its a great idea. – Frank Visaggio Apr 24 '15 at 22:00
4

Well, first of all, I'd seriously consider using another logic that implements non confusing, semantic URLs. Assuming this is not possible, I'd recommend you to track your user's behavior and see what happens.

Nevertheless, the solution for your problem is quite simple: just use htacces to redirect any user that hits somesite.com/event/ to somesite.com/events/ and you'll have all bases covered.

Then again, try working out your non-semantic URLs first, and track your user's behaviors so you can have an accurate view of what's going on with your site

  • "just use htacces to redirect", no, this wouldn't help. The whole problem is, that those two urls could be conflicting. Imagine two routes /events/:list-event-type and /events/:name-of-detail-event, when user hits /events/past-events, there's no way for the router to recognize that this is supposed to go to list of all past events, rather than detail of event called "Past events". – fxck Apr 26 '15 at 17:28
  • Then you might also need to re-think the site organization. Anyways, the idea is that you send people to a default (let's call it "hub") page, and then you "train" the user to follow your flow, not to wander freely across your site. Also, if the user is savvy enough to go to /events/ , they're savvy enough to expect an index, not a "per event" detail page – Devin Apr 27 '15 at 17:29
2

This kind of falls into the 'flexibility and efficiency of use' heuristic from Nielsen Norman Group's heuristics. Their definition for this heuristic is:

Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

If a person knows enough to navigate a site that way I think you should allow it. I personally do try to navigate sites like this when I'm unfamiliar with them and love it. I have seen other more "experienced users" do this as well. Just through personal interaction, no research on this on my end.

0

For the lack of overhead that is involved in modern web application frameworks like spring Rails or asp.net I would add another route that redirects users there to mitigate this problem. I dont see any negative effects of having both routes active and its like 5-25 minutes of work to do it. It seems like a win win unless I am missing any risks.

For example I cant think of what yourdomain.com/event would map to , i could see yourdomain.com/event/{id} mapping to something but having event and events redirecting to the same place to eliminate user issues seems like a good idea for minimal work.

If the way in which you are coding your site is different where this isnt a minimal "Do it" then put it in the same process where you identify and rank requirements to eventually place it somewhere in your backlog.

  • Two whole problem is, that currently there are two routes, list /events/:category, which can be say, /events/past, /events/music, or just /events.. then there is detail page route /event/:permalink, which can be say /event/musicfest-foo-2014, imagine if both started with /events, router would't have a way to differentiate between the two. I can think of a few ways to deal with it, and most of them results in "uglier" urls or too much overhead. – fxck Apr 26 '15 at 17:37
0

Responses i'm seeing so far are looking to only to "make it work" for now. URIs will stay - so when designing them try to make it work even after a site re-design/re-structure in the future.

I share the concerns of your team mates, We can't expect an ideal way user would interact with the site, but we can make the site function ideally for any user.

Consider the grammar like this -

somesite.com/{type}/{child-id}

The {child-id} could be referring to anything random when paired with the {type}, but {type} is pretty-much static in every cases. So it is only natural that if a user assume {child-id} as a subset of {type} and treat it as such.

The key to avoid a confusion is to define the grammar early on while designing the URIs, how you want the user to perceive the path structure of the site.

So, I would re-think using two different strings for {type}, one plural and another singular for the language's sake, while {type} is expected to be static.


Tim-Lee on Cool URIs http://www.w3.org/Provider/Style/URI.html

gov.uk on Designing URI sets for the UK public sector » https://www.gov.uk/government/publications/designing-uri-sets-for-the-uk-public-sector

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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