January 2010


Options: Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
UofMN CSS Web Development <[log in to unmask]>
Wed, 27 Jan 2010 13:31:35 -0600
UofMN CSS Web Development <[log in to unmask]>
"Aaron J. Zirbes" <[log in to unmask]>
multipart/mixed; boundary="------------090907060104060709070405"
University of Minnesota
text/plain (4 kB) , ajz.vcf (4 kB)
... here's my $0.02.  Note that I am not at all against sub-folders.  I 
just thought I'd point out that sub-domains are useful, and I'd argue 
not bad at all.

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
This is a rather easy and painless process using service gateway and a 
quick call to 1-HELP.
> 2. I believe search engines treat subdomains as separate sites - 
> anyone know?
They are typically treated as sub-sites are many orgs do things like 
www1, www2, www3 for load ballancing
> 3. A manual search of "h1n1 site:www.umn.edu" may not return results 
> from "h1n1 site:www.research.umn.edu"
True, but site:umn.edu will search any subdomain of umn.edu
> 4. In print/verbal promotion it is easier to remember/promote 
> "umn.edu/h1n1" then "www.boyton.umn.edu/h1n1"
h1n1.umn.edu is also easy to remember...
> 5. Subfolders mimic a user's desktop organizational experience. 
> Everything is contained it it's respective compartments.
You assume users understand folders and path names.  Ah, I wish this was 
> 6. People are being trained not to trust and question sub domains 
> because of spam issues.
Really?  I'd hope they are being trained to ensure the root domain is 
who they are looking for.  When I log on to my banking site, page 
redirects and image loading crosses at least a half dozen different 
> 7. Subfolders create a stronger sense of unity and connection in the 
> university environment. All housed within "umn.edu"
Isn't "unit.umn.edu" a pretty good connection within the university 
environment?  I can see where stand-alone domains are not (example: 
umphysicians.com), but I think sub-domains are.
> 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.
It'd be nice if it was universal, but an actual breadcrumb navigation 
tool on the page is much better than messing around with the URL path.  
This is especially true for hosted applications... most things backed by 
a database.

> 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?