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 '10 at 21:33

6 Answers
6

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

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:

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.

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.

There are 2 things to consider before you choose one of them, which are:

Site Security.

Site SEO.

Personalized Subdomain

If you need a tight security, then you should go to personalized subdomain, there are several things that will tightened your site security when you choose personalized subdomain, which are:

No Google Indexing. You can avoid google indexing your private client site, and you can safely index all of your www site without worrying your system will be compromised.

Avoid site hacking from viewing your robots.txt. You can safely disallow google from indexing several of your pages or directory structure, but someone can easily peek into your robots.txt and find something precious there.

If you prefer security than search engine optimization, then you can choose personalized subdomain, but the implementation is a bit tricky, don't use dns to add a cname or an a record to your subdomain, simply add an a record for *.yourdomain.com, and you can safely manage your subdomain with vhost from your web server, so no one can enter the subdomain without knowing the exact name of it first.

Personalized Subfolder

If you need to optimized you site rank in search engines, you can use this method. You can prohibit some places to be indexed by search engine with robots.txt, and hopefully no one knows where it resides. Also you can have your site rank higher than the previous method, because all of your client visit your main site, rather than their own subdomain.

Summary

I personally choose the first option, since I cannot afford loosing some pages to be unintentionally indexed by search engine, or someone somehow found my robots.txt. If I need SEO more than ever, I can simply create a blog for the company and have it indexed, that would attract more people and have a higher unique visit, and increase rank, rather than risking my system easier to be compromised.

I don't understand this answer at all. Subdomains can be indexed (or not) just as easily as any top-level domain. How do you think this site is indexed in search engines?
–
Charles BoyungDec 10 '10 at 15:16

Yes, you are correct, subdomain as well as top-level domain and all of it's content can be easily index (or not). But in my opinion, I focus on preventing site abuse such as peeking at the robots.txt where you can found precious path by removing the whole web app to it's own subdomain so that non-member cannot enter the web app without knowing the right url. If you were using robots.txt to restrict search engine to crawl certain path, someone can peek into your robots.txt. Once again, it depends on what you choose, would you choose SEO over security or otherwise.
–
Hendra UziaDec 11 '10 at 7:47

Your entire statement here is flawed. In fact, what you are saying makes absolutely no sense. If the app has its own top level domain, it isn't going to get indexed either, unless you start linking to it on the web/submitting it to search engines. There is nothing in a top level domain that magically gets it put into search engines. Also, if you're trying to use obscurity as security, you've got some serious flaws in your application. If you have a web app, it should be secured with some sort of login, which would prevent indexing anyways.
–
Charles BoyungDec 13 '10 at 14:35

And also, what in the world does robots.txt have to do with anything?
–
Charles BoyungDec 13 '10 at 14:36

Sure, it has to be secured with some sort of login, but let me show you my point of view. There are many ways to compromise a site, here I simply removing 2 possibilities which are, preventing non member to enter the private login, and preventing your important not-to-be-indexed path in the robots.txt to be seen by public. Of course this problem can be resolved in many ways, and I'm not forcing anyone to do it this way, I'm just showing this is how I've done it.
–
Hendra UziaDec 14 '10 at 5:36

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:

Go to the site URL

Enter their username

Enter their password

Log in

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

Go to the site URL

Enter their company name

Enter their username

Enter their password

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?