Design/UX #3064
closedAdd Information on Custom Domains to Group Creation Process
0%
Description
At the end of the group creation process give the person information on:
- How to get a cuny.is/name link for the group
- The ability to map a domain name they purchase www.groupname.com to their group site on the Commons
Mostly this is figuring out the text to add and which screen to add it to.
thanks to Michael for the idea
Files
Related issues
Updated by Chris Stein almost 11 years ago
Adding before I forget, that one functional consideration is whether this should show if the person creating the group does not create a site. The domain mapping functionality is tied to a site for a group and not the group by itself.
If we show the info regardless of whether there is a group it needs to include information to make the link between group site and domain mapping clear.
Also we are planning on making some codex materials on how to promote an event with sites and domain mapping, may want to link to that as part of this.
Updated by Matt Gold almost 11 years ago
- Status changed from New to Assigned
- Target version set to 1.6
Updated by Chris Stein over 10 years ago
- File Group-Shortlink-Mapping-Explanation-16.png Group-Shortlink-Mapping-Explanation-16.png added
- File Group-Shortlink-Mapping-Explanation.html Group-Shortlink-Mapping-Explanation.html added
- Status changed from Assigned to Reporter Feedback
Looking at the process the logical place seems to be in step 4. This is when we give them the message that their group has been created and offer them the chance to create a group site. In the attached .png image, I've suggested adding two blocks of text. One before the current Group Blog text that outlines what a shortlink is and how they can get one. The other after the Group blog that tells how they can also get a shortlink for the group blog and some info about domain mapping with a link to find out more.
If we decide to implement that I've included a file with both descriptions as HTML.
I will also paste them in here for people to be able to read/edit as well.
-------------------------------
CUNY.IS shortlink
A shortlink is a short, easy to remember link you can give to people. When they visit the link they will be automatically redirected to the actual url of your group. All cuny.is shortlinks start with cuny.is. For example the shortlink for your group site might be http://cuny.is/groupname while the actual url would be something like: http://commons.gc.cuny.edu/groups/groupname¶
To get a custom shortlink send us an email at commons@gc.cuny.edu containing the actual url of your group and the proposed shortlink.
Blog URL Customization
There are two ways you can customize the URL for your Group's Blog. They can be used separately or together.¶
- Get a http://cuny.is/ shortlink
- Map a domain name to the blog
CUNY.IS shortlink
In the same way you can get a shortlink for your group's page, you can also get a shortlink for your group's blog. For example the shortlink for your group's blog might be http://cuny.is/blogname while the actual url (the Address you chose above) would be something like: http://blogname.commons.gc.cuny.edu.
To get a custom shortlink send us an email at commons@gc.cuny.edu containing the actual Address of your group's blog and the proposed shortlink.
Map a Domain Name to the Blog
To fully customize the URL for your group's blog you can go out and buy a domain name. The Commons team can then assist you with mapping that domain name to your group blog. For example The CUNY Games Network purchased http://cunygames.org and then had that domain map to their group blog which is at http://gamesfest.commons.gc.cuny.edu/. If you follow the cunygames.org link you will see you end up at the gamesfest.commons.gc.cuny.edu site.
If you're interested in this, visit the Domain Mapping Codex page where you can find out more about it and fill out a request form if you have a domain to map.
http://gamesfest.commons.gc.cuny.edu/
Updated by Chris Stein over 10 years ago
- Status changed from Reporter Feedback to Assigned
- Assignee changed from Chris Stein to Boone Gorges
Boone, since not a lot of discussion here and time is of essence, moving to you.
While I think this is worthwhile, there are some other high priority issues so I won't mind if you push this and do it in one of the 1.6 dot releases.
Flipside, if we are going to write up group related functionality for this release then this might be a good thing to include.
Updated by Boone Gorges over 10 years ago
- Assignee changed from Boone Gorges to Chris Stein
- Target version changed from 1.6 to 1.7
I'd like to recommend that we table this for now. A few concerns:
1. This is a huge wall of text. For the first-time user who wants to set up a group, I imagine that this amount of information would be off-putting. I think we should explore ways of providing the relevant information in a contextual manner, or at least more tersely.
2. Rather than asking people to request cuny.is URLs for their groups by sending an email, I'd prefer to have a tool where admins can request the URL themselves. Manual creation of these URLs is time-consuming for me and Sarah, and may be a confusing bottleneck for users. My recommended workflow here is not to mention it during group creation (it's too much information); then to auto-create a cuny.is link based on the group URL; and then provide a mechanism for changing it, akin to what we have for profiles. For the vast majority of groups, I think this'll be the ideal workflow.
3. I'm wary of widely publicizing domain redirection/mapping. We don't really have a good workflow worked out on our end for this process. Ideally, we'd hold off until we've at least got some good user-facing documentation on how the mapping works. It's also somewhat confusing that the domain refers to the groupblog and not the group itself; this interface probably needs some rethinking one way or another. As above, it may be that the group creation process - which everyone is forced to see - is not the place for this kind of advanced config option.
Tentatively placing into 1.7 for further discussion and design.
Updated by Chris Stein over 10 years ago
Those all sound like reasonable changes and reasons to push to the next release. Both the potential for confusion on the users and making things work better for the commons team are great reasons. I like the idea of making the process similar to the profile shortlink. Will take another look at this after the 1.6 release.
Updated by Boone Gorges about 10 years ago
- Assignee changed from Chris Stein to Boone Gorges
- Target version changed from 1.7 to 1.8
I've started the process of a larger guide to custom domains, but lost the thread due to other concerns. Let's pick it back up for 1.8.
Updated by Boone Gorges about 9 years ago
- Target version changed from 1.9 to 1.10
Our Hosting Partner Handbook has info on requesting custom domains. I think that this is enough as far as that's concerned. http://dev.commons.gc.cuny.edu/hosting-partner-handbook/
Adding Groups support for cuny.is sounds like a good idea. I have a slight concern that our hundreds of groups are going to pollute the cuny.is namespace. What do we think about the following default format for group shortlinks: cuny.is/group-{$group_name} So commons.gc.cuny.edu/groups/cuny-pie/ gets cuny.is/group-cuny-pie. We can allow users to request non-prefixed URLs through the manual tool. This will help ensure that all the good URLs are not taken by groups that may never use them. Note that this suggestion requires #4874.
Updated by Matt Gold about 9 years ago
I'd note only that there's a slight usability loss there, as the short link becomes a longer link with the addition of the word "group." But having a manual way for users to request the a shorter version solves that problem, so that sounds good.
Updated by Boone Gorges about 8 years ago
- Related to Feature #6241: cuny.is short URLs for groups added
Updated by Boone Gorges about 8 years ago
- Status changed from Assigned to Rejected
- Target version deleted (
1.10)
I've opened #6241 for cuny.is links.
I think there seemed to be general agreement that the other items that were originally suggested might be premature or suboptimal given the way our hosting partner arrangements currently work. As such, I'm going to close this ticket. If there are aspects I'm missing that others think ought to be kept alive, please feel free to speak up.