3

And when is it better to structure your website's content one way or the other?

Note that I have seen there's already a related question, Domain Strategy From a UX Perspective, which has some great info ... but I don't see that really addressing the difference or applicability between subdomains and subdirectories.

Bonus question: How would we visualize domain.website.com in a sitemap in relation to website.com/directory? The subdomain is considered an entirely separate website, right? So would domain.website.com and website.com be at the same level of hierarchy?

Improve this question
6
  • Traditionally domain.website.com and website.com can be two different computers sometimes even at other sides of the world. It's just that the computer at website.com has the adressbook for all subdomains.
    – Pieter B
    Commented Jan 16, 2014 at 9:03
  • Can you elaborate on what you mean by this?
    – in_flight
    Commented Jan 16, 2014 at 13:51
  • A subdomain is not part of the site, but can and should be considered a different computer/location/server, a subdirectory should be considered part of a site on the same server as other subdirectories on that site.
    – Pieter B
    Commented Jan 16, 2014 at 14:07
  • 1
    @PieterB What sense does it actually make with cloud and cluster servers? I mean if we both type google.com there is a very low probability that we are on the same server, and the same goes with maps.google.com, translate.google.com, mail.google.com…
    – Pierre Arlaud
    Commented Jan 16, 2014 at 14:38
  • @ArlaudPierre Mostly a way of how you view things. Apple.com and Google.com are subdomains of the .com domain. Apple.example.com and Google.example.com are in the same way subdomains of .example.com domain.
    – Pieter B
    Commented Jan 16, 2014 at 15:12

6 Answers 6

Reset to default
11

I'm not so sure there's a huge difference from a UX stand-point. If anything, it makes it more difficult. Let's say a user is on your site and is at www.sub.example.com/articles/article-title.php, and he wants to go to your homepage. Users often clear the address bar, so he would click in the address bar, clear the end of the URL, and be left at www.sub.example.com, which may not be where he wants to be.

Take the alternative you have www.example.com/sub/articles/article-title.php, the user can quickly get to the homepage by clearing the end of the address, and if they wish to remain is /sub/, they can keep that part there.

Using sub-directories though written like that has more to do with programming rather than UX, take a look at this similar question on StackExchange - https://stackoverflow.com/questions/1965609/subdomain-vs-subdirectory-in-web-programming.

Besides the fact that from a security standpoint it is a bit easier to isolate an app within a subdomain, I will just comment on what I think is the biggest difference between the two.

Pro's for subdomains:

  • You can isolate configuration (for for example apache) per-domain.
  • It will be easier to migrate parts of your application to other machines. Sub-directories won't really give you this flexibility.
  • Instead of having to use a $baseUri variable in every html template, you can just assume the root of the app is always /.

Cons:

  • It will be much more annoying to quickly setup staging or temporary development environments. For every 'app' you will now need DNS of hosts-file entries and webserver configuration. With subdirectories you could drop the app in a directory, and go!
  • If you do ever have the requirement to deploy your application on a different system where using / is because of some odd policy not possible, some rewriting might be in order.

My advice:

Make sure you can always do both, which will give you the best of both worlds. Every part of your app should have a configurable base uri that is always respected. As long as you make sure you can always go both ways, then who cares what you do? it's just a url and it can always be changed.

Although it can look nicer, it can be worse for the user in terms of UX.

Improve this answer
3
  • The Opera browser has a gesture to make it easy to go "up one level" without having to fiddle with editing the URL: drag up then left. It is very frustrating when content is not structured in a way that makes it easy to access similar/related content if I end up on an orphan page (such as when someone sends me a link to an image).
    – cimmanon
    Commented Jan 15, 2014 at 15:35
  • @cimmanon - I never knew about that, sounds like a handy feature. Unfortunately not all of the browsers have that though, so we can't rely on it when developing websites.
    – Mike
    Commented Jan 15, 2014 at 15:45
  • One point against separate sub-domains is that you will have problems with CORS when doing AJAX calls between sub-domains. For example, jQuery can call website.com/domain from anywhere in website.com, but browser security will block calls from website.com to domain.website.com, unless the application/server is configured properly and the user is using a modern browser. Even http: vs https: differences are enough to trigger CORS issues!
    – David Keaveny
    Commented Jan 16, 2014 at 4:29
5

Thematically, a subdirectory is clearly part of the main site. A subdomain is an area that may be related to the main site, but doesn't really fit as part of the main site. There's no hard rules for what goes where, it is dependant on how content/functionality is being organized and who is doing it.

The benefit of the subdomain approach is that it can be managed as a separate site, using a different technology, front/back end, or configuration. The subdirectory approach is more sensible when the content or functionality is part of a cohesive whole.

Improve this answer
2
  • That's much clearer to me, the way you distilled it, so thank you for that. And as @Mike brought up in his answer, which approach you choose seems to be a question of managing the site, more than anything else. I do think subdomains can be the more usable option over subdirectories, in a certain context ... but that's an exploration for another day. Anyway, so in a sitemap or visualization then, would a subdomain (by nature of the prefix "sub") be below the main domain, or on the same level, as it's managed separately?
    – in_flight
    Commented Jan 15, 2014 at 18:29
  • Just a note (not specific to your answer, but I think it's more like a comment than an answer), www.google.com and say maps.google.com are two sites. Therefore, except you explicitly allows it, you cannot make Ajax calls from one to another - they will be blocked for xss reasons. On the other hand, www.google.com and www.google.com/something are the same site.
    – danqing
    Commented Jan 15, 2014 at 22:25
2

Each website should get its own host.

Website? A collection of webpages that share a design (e.g., header and footer) and main navigation.

Host? A registered name, e.g.: example.com, www.example.com, sub.example.com, sub.sub.example.com.

This is not a technical requirement (!), but I think it’s an assumption that many users have (at least those with a basic understanding of URIs). And not only users, but also tools. And breaking with this advice would break those tools for their users. For example:

  • Password managers (as implemented by browsers) typically work on host level, not path level. Different websites may require different kinds of accounts. If you’d had several websites on the same host, password managers may try to fill in login data for the wrong website.
  • JavaScript blockers (like NoScript) typically work on host level, not on path level. Different websites may require different kinds of scripts. If you’d had several websites on the same host, a user could not allow scripts for only one of those sites.
  • Same goes for many other tools like cookie blockers (e.g., Cookie Monster), Referer controllers (e.g., RefControl), etc.
  • One might like to block a specific website with a hosts file (which works on host level, not path level) or similar mechanisms. If you’d had several websites on the same host, all of them would be blocked.

Your "bonus question" about sitemaps: Typically, a sitemap contains all URLs of a (= a single) website. So each website should get its own sitemap. Of course you could create a sitemap listing all websites (and their pages) of your company/etc., for example:

Our sites

  • www.example.com
    • www.example.com/about
    • …
  • shop.example.com
    • …
  • blog.example.com
    • …
Improve this answer
1
  • I highly appreciate you answering the "bonus question"!
    – in_flight
    Commented Jan 16, 2014 at 16:48
1

As per my experience and understanding, the decision of structuring content on a website depends on the nature of it. For example, if I were to start a website on the product called "Faadu", my approach would be:

  • For the product homepage, I would try to own the domain www.faadu.com.
  • For the blog page, I would pick a subdomain like blog.faadu.com since a blog is a separate entity than the product page.
  • To put content on the a special feature, for instance, the AI feature that my product offers, I would choose www.faadu.com/AI. Alternatively, if I would like to blog about it, I would use blog.faadu.com/AI. I would not use, AI.faadu.com since, it's a part of the product and not a separate entity.

In terms of UX, I agree with @Mike that it wouldn't differ or matter much, unless the user tries to predict the parent URI. Hope this helps.

Improve this answer
1

From a UX perspective www.domain.com/cats is preferable to cats.domain.com .

It is worth noting that 'www.domain.com' is a subdomain(primary) of 'domain.com'. It is an indicator to the user that what follows is a domain name.

I doubt many users understand the difference between URLs, TLDs, subdomains and directories but they will place a greater level of subconscious trust it the pattern off 'www' . 'domain' . 'com' . This is a pattern they will recognise. (I do not have any data for this!)

Many big companies do many different things and should not be heralded as examples of best(or worst) practice. A whole heap of companies entirely ignore the UX aspect of their URL and look at the issue from a Search Engine Optimisation point of view.

The primary reason for the choosing between directory and subdomain will be technical/structural depending on how you want you network to run and operated.

There is also the issue of email and the sender/originator but I do not think the original question is questioning this.

Improve this answer
4
  • A project I worked on a couple years ago gave clients a subdomain to access their content and theme it. We setup clientname.example.com for them, and they told all of their users that their website was www.clientname.example.com. So yeah, users don't get subdomains (or that www is a subdomain).
    – cimmanon
    Commented Jan 15, 2014 at 21:11
  • @cimmanon lol! I had the same thing happen. I told them www.theirname.myportfolio.com was the site they could use until theirs was up (DNS had to propagate, and theirs was an add-on to mine). They advertised it on Facebook as www.theirname.myportfolio.com.
    – Mike
    Commented Jan 15, 2014 at 22:50
  • @Mike you mean you said theirname.myportfolio.com and they understood it with www :P Interesting typo, are you a normal user too?
    – Pierre Arlaud
    Commented Jan 16, 2014 at 14:42
  • @ArlaudPierre Nope, they advertised it as the right URL, but it looked so unprofessional because of the www.theirname.myname.com.
    – Mike
    Commented Jan 16, 2014 at 15:42
1

In all honesty, from a front-end UX perspective - I think it's a marketing thing. Here's what I mean.

gmail.com redirects to mail.google.com - but, Gmail is easier to market and remember for a user.

Both googlemaps.com and maps.google.com redirect to www.google.com/maps

googleplus.com redirects to plus.google.com

From a server perspective, subdomains are a good way to isolate various configurations easily (and can actually aid in the user experience):

apple.com

developer.apple.com

itunesconnect.apple.com

iadworkbench.apple.com

Apple markets the "Developer" program, which is connected to "iTunes Connect". And developers can create marketing for the iAd network using the "iAd Workdbench". And, last but not least on the list, if a user types in apple.com/developer - (s)he will be redirected to the subdomain.

And, there is always: ux.stackexchange.com, pm.stackexchange.com, etc. - basically every exchange in the stack exchange network except stack overflow, which has its own domain.

There is also the argument that it might be easier for a user to hit the period (ring finger and used more often - muscle-memory) versus the forward-slash (pinky and used less often). Also, visually, subdomains are better from a designer perspective than the slash.

And, there is the argument against having www. as part of the root domain.

To sum up. The end domain name is pretty irrelevant from a user's perspective, in my experience. Instead, the entry domain is the part you want to care about. gmail.com is a great entry domain - short, sweet, and marketable - but that's now where you go as a user. stackexchange.com as an entry will be a good one when the marketing picks up - then using the exchange listing - then bookmarking that specific exchange (at which point the domain becomes URL structure becomes moot). Domains aren't necessarily created to house the website - they may just be to help a user get to the right place (iPhone.com, iPod.com, for example).

Improve this answer
1
  • I agree there's a marketing/branding element to it, but it'd be interesting to do some quantitative research into how users think about/perceive these domain differences ... and see whether it really is irrelevant. I know in higher education, for an example, many universities will have their main school.edu domain, and then break out entities like library.school.edu or biology.school.edu with subdomains. I wonder if this makes for a better user experience by fostering a sense of digital place and modularizing what would otherwise be a massive information architecture.
    – in_flight
    Commented Jan 16, 2014 at 13:58

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