WEBSTANDARDS Archives

January 2010

WEBSTANDARDS@LISTS.UMN.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Subject:
From:
Peter Wiringa <[log in to unmask]>
Reply To:
UofMN CSS Web Development <[log in to unmask]>
Date:
Wed, 27 Jan 2010 14:29:07 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (134 lines)
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

ATOM RSS1 RSS2