Is this even allowed for web applications that run on application
servers that aren't controlled by central? I.E. apps that run on
specialized application servers? In other words, could my J2EE
application be hosted as umn.edu/cancerstudy, rather than
As a side note, I'm for "servicename.umn.edu" rather than
Google does it, and I want to be cool like them.
Andre Leroux wrote:
> I'm **strongly** all for umn.edu/something
> otherwise known as subfolders instead of subdomains.
> 1. Eliminates the problem of setting up a redirect from
> http://www.department.umn.edu to http://department.umn.edu
> 2. I believe search engines treat subdomains as separate sites -
> anyone know?
> 3. A manual search of "h1n1 site:www.umn.edu" may not return results
> from "h1n1 site:www.research.umn.edu"
> 4. In print/verbal promotion it is easier to remember/promote
> "umn.edu/h1n1" then "www.boyton.umn.edu/h1n1"
> 5. Subfolders mimic a user's desktop organizational experience.
> Everything is contained it it's respective compartments.
> 6. People are being trained not to trust and question sub domains
> because of spam issues.
> 7. Subfolders create a stronger sense of unity and connection in the
> university environment. All housed within "umn.edu"
> 8. Personal: I think sub-domains are passee and prohibit the user from
> quickly eliminating part of the url and treating it as a bread crumb/
> university wide navigation tool.
> Peter Wiringa wrote:
>> On 1/26/10 4:26 PM, Kristofer Layon wrote:
>>> I have some clients' sites on www1, but could happily move them. I
>>> think of an argument for keeping them there; I'm sure most clients
>>> gladly go to a /name.umn.edu/ domain instead of their current
>>> (though I'm sure, now that I said this, someone would surprise me…)
>> Actually, I'd be curious to hear what others have experienced in this
>> area. We [very] rarely run into a situation with a central (TC or
>> systemwide) initiative where we can't obtain a name we're hoping for,
>> that really does seem to apply to our situation, because it's already
>> in use by a unit for what may be a very narrow purpose.
>> It seems like it's in the best interests of some groups to identify
>> with with their ancestors, i.e. the department that offers that
>> basket weaving course might have more clout if their association with
>> their college is clear, and their college might have more clout if
>> the fact they're a part of the U is clear (I believe there's data to
>> support the unit to the U as a whole portion, going back to the brand
>> policy). This could be done on the site and also through the hostname.
>> Just an example: maps.umn.edu. The interactive side (and eventually
>> the static pages) of the TC campus maps are under
>> campusmaps.umn.edu/tc. We had to avoid www1 for technical
>> considerations, but maps.umn.edu was already taken. Not trying to
>> sound greedy here, and I imagine you (Kris) and some others have come
>> across similar situations, but it seems to me like this is a clear
>> example of something where a much broader audience could be served in
>> the maps.umn.edu space. Be thankful for redirects, I suppose
>> (umn.edu/maps does something useful).
>> Not that campusmaps.umn.edu is bad name.
>> We've been talking a lot about the architecture of the U lately, and
>> I think it would be helpful for us to understand where all the other
>> units and developers/ecomm folks are coming from. Five models come to
>> mind when you drop down a level, under a college or VP or vice
>> chancellor, for instance.
>> The something.umn.edu does make sense for functions of units that
>> serve campuswide or systemwide purposes, regardless of where they are
>> in the org chart (i.e. onestop.umn.edu, which serves a huge audience
>> and has a cool name).
>> What makes sense to everyone? And why? Is the idea of different
>> hostnames for everything driven more by the client or by the developer?