Your company actually lets you develop applications for your internal employees. Awesome! You have a web server and you’re about ready to publish it. But what should you name your site? If you’re publishing to an existing portal that already has a name such as apps.mybusiness.com, what should you name your application’s relative location?
If you’ve tried searching online for a domain naming conventions or application naming conventions for internal applications, you probably came up pretty empty. Since there doesn’t appear to be much on this subject, I’ve decided to come up with a few suggested guidelines you may choose to follow when naming and publishing your internal web applications. In no particular order, here they are.
Select an appropriate home for your application.
In business, we end up having a lot of applications that we need to get to. There are customer management systems, HR systems, technology support management systems, time sheet systems, document management systems, and so forth. Ideally, your organization should have one portal that houses links to all internal applications. One portal to bind them all, so to speak. You can hide or show links based on access rights if you want, but have one place that tells everyone where to go for anything.Think of applications like families. Your applications don’t have to be physically hosted near each other, but they should appear related in the eyes of your users. The HR links should all be presented from the same user interface. The same goes for all of the operations support systems.
Select user-friendly URLs relative to your portals and applications.
If your organization is known as ABC Widgets and you have an internal application named Time Tracker, an example of a friendly URL is apps.abcwidgets.com/timetracker. The idea is that all of your internal applications would be accessed from apps.abcwidets.com. If possible, you would select a relative URL of timetracker for this application. Most of the time, it’s impossible to control URLs like this because of varying application platforms and legacy issues. Aim for creating one portal with all the links available in a way that makes sense to your users. Then, when you can control it, name your URLs according to something that describes what the purpose of the link is. Don’t use server names, state names, president names, Sesame street characters, or whatnot.
Don’t reengineer internet conventions.
Don’t institute your own domain suffixes. This means no abcwidgets.apps. Only use fully qualified domain names and don’t override existing URLs. That means, don’t institute your very own answers.com. Using a fully qualified domain names means you use something that could only be resolved to your resource according to the tree like hierachry of the web. Across the world, this is how people are interacting with the internet.
Lastly, please don’t drop the suffix from your URL. Most web browsers will try to resolve the entry even without a domain suffix, so if you name your application simply timetracker and your user isn’t connected to your network or can’t resolve the entry they are going to be really confused by what they see.
Spend some time thinking about your domain naming scheme. Make it logical to a normal person (not the developer). Changing internet conventions is just confusing to users and silly. You can probably train your employees to remember what you’re doing, but why waste the effort? There are much more important things for them to remember and you’ll just create stress when they incorrectly enter your domain name. Keep it simple and conventional, please.
These are just suggestions. You may have a legitimate reason to do something different from this list. If you do, please share your experience with me. And, if you know of a good resource for best practices, conventions, or standards on domain names for internal applications, please share them.