11

I'm writing a web application, the application is for small companies where each company will have multiple users.

What is better:

  1. giving each company a sub domain (so you access the app at my-company.example.com)

  2. everyone access the service at www.example.com (in this case you have to enter the company name in the login page).

I'm asking what is better from a usability perspective, both will have the same complete separation between companies and both require the exact same amount of work to implement.

Update: most (if not all) of the company's employees will use the app.

1
  • 4
    Whatever you do, avoid the problem 37signals had with Basecamp, where visiting Basecamphq.com didn't show a log in field for the first 5 years of the product's life cycle (they only just added a log in form in 2009). This was because users were expected to log in at the subdomain xxx.basecamphq.com.
    – Rahul
    Aug 22, 2010 at 21:33

5 Answers 5

4

I think it depends who is supposed to use the app. If the customers or employees of my company are supposed to use the app, it would be easier and more comfortable to use a sub-domain (also this could allow personalization of the page with a logo etc...).

If the app is meant to be accessed by only a few admin level type people than it is probably easier to just login to the main app and set things up there.

For example it is simpler for a single user to use gmail but for an organization it is simpler to use Google apps. Although it takes a bit more work to set up it is then specialized for my company

8

Definitely use a per-company subdomain.

There are 2 different ways you can do this:

  1. company.yourcoolapp.com
  2. yourcoolapp.company.com 1

The difference between the two options is slight, but to me, it seems like with option number one, the software user sees that their company is being allowed to use your software on your domain (which is probably the case). They may or may not feel like they have ownership of the data they're entering (depending on what your app actually does).

With option number 2, the software user sees that your app is a part of their domain, almost like the data/application is hosted by their company. In this case, I think the user would feel more like the app is a part of their company, rather than an outside product they just happen to use.

You can even have both URLs set up, having one of the domains point to the the other. This is how Blackboard (an education software package) does it at my University:

  1. http://unco.blackboard.com
  2. http://blackboard.unco.edu

1 This may be an ugly-looking URL if your are writing an application that the well-known law firm Dewey, Cheatem and Howe might use: http://mycoolapp.DeweyCheatemAndHoweAttorneysAtLaw.com

2
  • I never considered the spelling of Dewey, Cheatem and Howe. Now I know.
    – JeromeR
    Dec 11, 2010 at 18:56
  • 1
    There is a huge difference between 1 and 2, in that 2 is many many orders of magnitude more complex. What if a team at Google wanted to use your application? You're going to ask them to add a "yourcoolapp" subdomain to the google.com DNS? What about certs etc? Seems extremely impractical.
    – robomc
    Nov 21, 2016 at 0:15
5

Having a sub domain gives a stronger sense of ownership (and perhaps privacy).
You can make the landing page of the sub domain customized, with the company's logo, news, etc.

On the other hand, if you use one central page, the only branding of your organization (the service provider) can be there.

If you do have just one page, make sure you support URLs that automatically fills the organization field, so your users can send direct links.

Come to think of it, maybe you can skip the organization altogether:
Might you have cross organization users?
This means that Beth works in Org A, which provides services for Org B, so Beth has to log into both organizations.

If that's NOT the case, then users can log in from one central page, and not have to fill any organization field since she'll be automatically associated to the right one.

Having said that, then it can make more sense to log in from a different sub-domain.

2

For our app, we decided to combine them, and we think it works pretty well:

  • Users can visit ourapp.com and click on "Sign in" to be redirected to the sign in screen
  • Users can visit the sign in screen directly
  • Once logging in, all users are placed within the "Logged in" environment at xxx.ourapp.com
  • When users create an entity in our app, they can give it a subdomain name at yyy.ourapp.com
  • yyy.ourapp.com is "client facing" and therefore shows no branding of ourapp, including any sign in links.

We decided not to do the "enter the company name at the homepage" part, as we realised that it would be better from a database and domain model point of view to just let everyone have their own "account" and sign in with that, and then write business logic to associate users with each other. Technical stuff, but sometimes you have to consider that when designing the user experience.

0

With the caveat that with your second solution the user would have to enter their company name, the only good solution is the company subdomains. Think of it this way - with solution 1, here's what the user has to do:

  1. Go to the site URL
  2. Enter their username
  3. Enter their password
  4. Log in

With solution 2, here's what they have to do:

  1. Go to the site URL
  2. Enter their company name
  3. Enter their username
  4. Enter their password
  5. Log in

Why add the extra step if you don't need to? Also, making the user type in their company name is extra cognitive load because now they need to remember how to enter their company name correctly. What happens if they typically refer to the company via an acronym or a short name? What gets used for your login page? Why make the users remember that extra detail when they don't need to?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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