For sites where users' DISPLAYNAMEs are made public (via forum postings, etc) it is desirable to allow users to pick their own DISPLAYNAME values. If you have a site where DISPLAYNAMEs are NOT public, however, you may save yourself some headache by forcing DISPLAYNAME to a predetermined pattern (plus you'll simplify your site signup process to boot...)
DISPLAYNAME
The "DISPLAYNAME" field is a "User Credentials" field. This is not to be confused with "User Profile" fields. "Profile" fields are optional (subject to a portal's User Profile settings). "Credentials" fields are required and, as such, are included as part of the required fields during user account registration. DISPLAYNAME is the one "Credentials" field you can exclude from the default registration process (by specifying a pattern).
Before we get to forcing a DISPLAYNAME value via a pattern, though, we should note that in many cases it is desirable to allow users to chose their own DISPLAYNAME. This is especially true on sites that publish users' DISPLAYNAMES (as in those that elect to show DISPLAYNAME in the USERS ONLINE module or in various forums modules). In such cases, if your site forces the DISPLAYNAME to be a user's actual name (or email address), some users may elect to supply a fake name for FIRSTNAME and/or LASTNAME in order to better protect the users' privacy. We saw this very thing happen (briefly) on the DotNetNuke.com site forums in late 2007.
Forcing a Pattern - Why Bother?
Why might we want to force the DISPLAYNAME to a certain pattern? The most common pattern is to force it to is FIRSTNAME + LASTNAME (resulting in a user's FULLNAME value). But why would we want to force DISPLAYNAME to repeat information we already have?
Forcing DISPLAYNAME to an existing value may or may not be of benefit to a particular site/admin. Here are a few reasons you might choose to force such a pattern:
- Simplify user registration process (users do not have to pick a DISPLAYNAME)
- Reduce chances of user confusion with regard to difference between USERNAME and DISPLAYNAME
- Improve default EVENTS module enrollment management (list of enrolled users can be displayed by "Lastname, Firstname" or by email address instead of a user-selected DISPLAYNAME)
It was the EVENTS enrollment list (in a much older version of the current EVENTS module) that first prompted me to force a certain DISPLAYNAME for a particular portal. I had a common complaint from event administrators: many users were hard to identify on DISPLAYNAME alone (there were multiple users who picked display names of just "Bob", for example). I wanted to avoid any change to the core EVENTS module code but I also wanted a solution that did not require me to provide a custom admin interface. Forcing the DISPLAYNAME to a predetermined pattern based on the users' names was the answer. After forcing a DISPLAYNAME pattern I then realized the additional benefits of simplifying the portal's regsitration process and avoiding user confusion over the difference between a DISPLAYNAME and a USERNAME. Over the next year I began to adopt the "DISPLAYNAME pattern" as part of my default configuration for new DNN sites. I now only allow user-determined DISPLAYNAMES when it is required (primarily on sites with forums.
How to force a DISPLAYNAME pattern
The DNN setting for specifying a DISPLAYNAME pattern is found under:
ADMIN -> USER ACCOUNTS -> USER SETTINGS -> DISPLAY NAME FORMAT.
You can enter DNN tokens as well as fixed strings. I like to use a pattern that results in "Lastname, Firstname" so my pattern with DNN tokens is:
[LASTNAME], [FIRSTNAME]
Of course, you're not limited to just using DNN tokens. For example, if you ran a Monty Python fan site, you might decide to use a fixed string "Bruce" resulting in everyone having the DISPLAYNAME of...."Bruce". To distinguish between "New Bruces" you might also include the userid value, such as in "Bruce [USERID]". Inclusion of the userid value may also make sense when using actual user names so you can tell the difference, for instance, between two different "Bob Smith" members on the same portal.
Summary
Hopefully this tip was useful if:
- It helped you identify an easy way to simplify your user registration process without altering core code or buying a third party module.
- It helped you avoid confusion over DISPLAYNAMEs (admin confusion over duplicate DISPLAYNAMEs and/or user confusion between USERNAME and DISPLAYNAME).
- It helped you avoid potential user privacy concerns by knowing why you may NOT want to take away users' ability to chose their own DISPLAYNAME values.
If you've used DNN's DISPAYNAME pattern feature to help solve a particular issue, please share it in the comments, below.