On 1/27/10 1:15 PM, Aaron J. Zirbes wrote: > 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 > cancerstudy.umn.edu? Nope, not in the current setup. > > As a side note, I'm for "servicename.umn.edu" rather than > umn.edu/servicename > > Google does it, and I want to be cool like them. > > video.google.com > wave.google.com > maps.google.com > images.google.com > docs.google.com > > -- > Aaron > > Andre Leroux wrote: >> I'm **strongly** all for umn.edu/something >> otherwise known as subfolders instead of subdomains. >> >> Reasoning: >> >> 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. >> >> >> >> Andre >> >> >> >> >> >> >> 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 >>>> can't >>>> think of an argument for keeping them there; I'm sure most clients >>>> would >>>> gladly go to a /name.umn.edu/ domain instead of their current >>>> /www1.umn.edu/name/. >>>> >>>> (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. >>> >>> umn.edu/unit/something >>> umn.edu/something >>> unit.umn.edu/something >>> something.unit.umn.edu >>> something.umn.edu >>> >>> 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? >>> >> -- Peter Wiringa Electronic Communications University Relations University of Minnesota (612) 625-3252 [log in to unmask] "I gotta hold on to my angst. I preserve it because I need it. It keeps me sharp, on the edge, where I gotta be." - V. Hanna