Friday, February 8, 2019

usability - Percentage of users who edit the URL of the site they're on?


The company I work for rents out vacation properties, with an alphanumeric ID for each property. Such as http://www.example-domain.tld/abc123456


There are SEO recommendations for using a slug / permalink with 3-5 keywords in them instead. Such as http://www.example-domain.tld/vacation-property-in-italy/


The internal (company) reason cited to keep the ID as-is, is for better user experience, with the explanation that if users edit the URL, they will encounter an error page. However, this got me thinking as to what percentage of users actually do (and know how to) change the URL of a specific page. I was unable to find an answer, searching online, and figured that this would be an excellent forum for it.


Is there any statistical information on whether users manually change the url in the browser? Are there any user tests that have been published, with information about whether people even know how to change the URL?



EDIT: A number of comments relate to people's own practice in modifying URLs - I appreciate the feedback on that, however I am looking for information (statistics, studies or similar) that support either the claim that users do or do not (or don't know how to) modify the URL of the page they're on. With the stats in hand, improving the user experience with regards to the URLs is easier.



Answer



I don’t know any general studies about it, and I guess it would be very hard to come up with a sensible one. I think it’s safe to assume that this very, very much depends on a) target group and b) URL design.


So even if users regularly manipulate URLs, this doesn’t mean that they do it on every site, because often the URL design is not good, i.e., the URLs are not browsable at all.


Why? (Motivations)


I think there are three main motivations for manipulating the URL:



  • Navigation: Users know (or assume) how the URL design works and want to reach a specific resource.

  • Error correction: Users try to fix a URL that leads to a 404 error page, because they think the page should exist and they assume that the URL might contain an error (e.g., missing a part, mistyped something, etc.)

  • Curiosity: Users try to find (possibly "hidden") content, but they don’t know if it exists at all.



Other motivations might be: trying to make the URL shorter (removing unnecessary parts); removing referrer parts (e.g., from affiliate links); removing identifying parts (e.g., session or tracking IDs); ….


How? (URI parts)


Host / domain


Users might try to remove or add subdomains, second-level, and top-level domains.


Examples:



  • Switch from the English to the German Wikipedia by replacing the subdomain en. with de.

    1. http://en.wikipedia.org/


    2. http://de.wikipedia.org/



  • Switch from Amazon France to Amazon Germany by replacing the top-level domain .fr with .de

    1. http://www.amazon.fr/

    2. http://www.amazon.de/





Path


The slash / is probably the most used delimiter for path segments.


As the URI standard says (emphasis mine):



The path component contains data, usually organized in hierarchical form, […]



So for navigational purposes, it can expected that users



  • remove path segments (delimited by /) from right to left

  • add path segments from left to right, delimited by /


  • replace strings between /


Examples



  • Switch from the "php" to the "python" tag by replacing the corresponding strings:

    1. https://stackoverflow.com/questions/tagged/php

    2. https://stackoverflow.com/questions/tagged/python




  • Remove the whole path to reach the home page:

    1. http://en.wikipedia.org/wiki/Stack_Overflow_%28website%29

    2. http://en.wikipedia.org/



  • Append a segment to reach the Edit page:

    1. http://any-wikkawiki.example.com/FAQ

    2. http://any-wikkawiki.example.com/FAQ/edit





Query


Typically more complex than the path.


It’s likely that only users that know the typical format (each key-value of the formkey=value, the first one introduced by prefixing ?, additional ones by adding & as a delimiter) add/remove whole key-value pairs.


Others would probably only replace existing values.


Examples



  • Go from page 2 to 5 by replacing the value of the page key:


    1. http://example.com/products?page=1

    2. http://example.com/products?page=5



  • Switch to French translation by adding the whole query component:

    1. https://support.google.com/webmasters/answer/47334

    2. https://support.google.com/webmasters/answer/47334?hl=fr





Fragment


Unless the site uses JavaScript to show different pages when changing the fragment, users can manipulate it typically without "breaking" something. They might try to add the whole fragment component (prefixed by #), replace the value of an existing fragment, or remove the whole fragment.


Examples:



  • Reach the top of the page by removing the whole fragment:

    1. http://tools.ietf.org/html/std66#section-3.5

    2. http://tools.ietf.org/html/std66




  • Replace a value to jump to a specific section:

    1. http://tools.ietf.org/html/std66#section-3.5

    2. http://tools.ietf.org/html/std66#section-4



  • Guess that a page allows to jump to a specific section by adding a fragment:


    1. http://de.wikipedia.org/wiki/GeSHi

    2. http://de.wikipedia.org/wiki/GeSHi#Weblinks






Your example


For your example case, only the URI path matters, so it’s /abc123456 vs /vacation-property-in-italy/.


If the motivation is Navigation:




  • The cryptic path doesn’t allow anything except removing it completly to reach the home page.

  • The readable path additionally might allow users to switch to similar pages, if they assume/know that they exist (!), by replacing values, e.g., by replacing italy with france.

    • I don’t think that users would assume to find something when removing only parts of the dash-delimited path segment (e.g., from /vacation-property-in-italy/ to /vacation-property-in/ to /vacation-property). This would be very uncommon as almost no site allows this (as this is typically only possible with /)




If the motivation is Error correction:



  • The cryptic path doesn’t allow anything except "obvious" cases like removing whitespace or trailing punctuation.


  • The readable path allows various kinds of corrections, e.g., when users see /vacation-property-in-italyy/ they might try to fix it by replacing italyy with italy.


If the motivation is Curiosity:



  • The cryptic path invites users to try to find other pages by changing the ID, maybe with the hope to find hidden/private content, especially when it looks like the number is incremental.

  • The readable path doesn’t convey that there would be something users wouldn’t be "allowed" fiddle with (like it’s the case when cryptic IDs are used), so there is probably no motivation to find private content. So the only thing users might try would probably be replacing some words (similar to the Navigation case).




Conclusion:




  • In the Curiosity case, anything goes, no matter how the path looks like. Users probably never expect that their manipulation works at all.

  • In the Navigation case, the readable path wins if there are such related pages. If not, it doesn’t matter (then it would fall into the domain of the Curiosity case anyway).

  • In the Error correction case, the readable path wins.


So the company is right, the readable path probably leads to more users trying to manipulate it. But the company is wrong in assuming that this leads to a worse user experience. If the URL/link contains an error (for example, because some characters were stripped in a mail client, or because it was dictated via phone, or because someone mistyped it), then users have a chance to correct it. In all other manipulation cases, users know that they might and expect they will stumble upon error pages.


(Apart from SEO and manipulation, readable/descriptive URLs offer, of course, various other benefits.)


No comments:

Post a Comment

technique - How credible is wikipedia?

I understand that this question relates more to wikipedia than it does writing but... If I was going to use wikipedia for a source for a res...