First my quick summary of where we currently stand. This is intended to list the web sites that people are charging the VAO to support. I'm sure there are inaccuracies.
Services currently using USVAO web address:
- www.usvao.org Primary Web site (at CalTech)
- help.usvao.org JIRA (at NOAO)
- dev.usvao.org TRAC (at NCSA?)
- wiki.usvao.org Wiki (at CalTech)
- portal.usvao.org Portal GUI (at ST ScI)
VAO supported services not using USVAO Web address:
- nvo.stsci.edu/vor10 VAO registry
- cxc.cfa.harvard.edu/csc1/temp/sed IRIS help and download
- heasarc.gsfc.nasa.gov/vo/... Validation, monitoring and notification
- voservices.net/nvolog Logging
- nvo.ncsa.uiuc.edu/dalvalidate/... Validators
- iraf-nvo.noao.edu/vo-cli VO Client services (site?)
- sso.us-vo.org Single Sign on service (NCSA/NOAO)
- astrobabel.com Forum
- usvao.blogspot.com VAO Blog
- twitter.com/usvao Twitter
- facebook.com/usvao Facebook
- calendar.google.com Calendars
- ivoa.net IVOA website/reg. of registries (rofr.ivoa.net)
- skyalert.org Not sure this belongs or perhaps its moving to being a core function...
- ipac.caltech.edu Cross-correlation service, time series service
- jhu.edu Cross-correlation service, TAP server
- cfa.harvard.edu TAP Client
- stsci.edu EPO pages
My belief is that simply adding new virtual web sites willy nilly like
iris.usvao.org
and
timeseries.usvao.org
will lead to a cluttered and potentially confusing web site. In fact I think we're already getting there.
So here's a suggested strawman organization for the VAO web site. I'm not particularly wed to the specific
tags or this structure but I do think that having some structure will make it easier for us and our users to follow.
www.usvao.org (current)
science.usvao.org (new -- directed towards scientists)
/discovery (current portal.usvao.org)
/iris (currently at Harvard)
/tapexplorer (TAP Client)
/xcorr (integrate TBR x-corr interfaces)
/time (TBR timeseries services)
support.usvao.org (new -- directed towards developers/institutions)
/software (new)
/clientTools (Voclient and such)
/serverTools (DALServer and TAPserver)
/svn (Link to SVN or its replacement)
/docs (new probably has lots of custom links underneath)
/repository (documentation repository)
/wiki (wiki if visible to public)
/devel (trac if visible to public)
/status (operations validation/stuff currently at HEASARC)
help.usvao.org (reuse name. Pages that help users.)
/request (Form for users to submit requests to user input)
/internal (the current top level page. JIRA for VAO users only)
/forum (the current forum)
/staff (pages to help users identify/contact staff)
epo.usvao.org (new, directed towards teachers, students, public)
internal.usvao.org (new, directed to VAO staff)
/resources Resources that must be hosted outside our web site
/staffGuide Documentation to help employees understand VAO.
/dev Non-public development pages (current dev.usavo.org)
/ops Non-public operations pages
/logs Logging
Please feel free to comment. We may try to discuss this at the Ops telecon next Monday but this clearly affects all of us not just ops.
One technical issue does need to be kept in mind. Given a remote site it is possible to link to it as both
remote.usvao.org
or
usvao.org/remote
but the mechanisms are different and we may have access to only one or the other. So at least in the short term we may not always be able to get the site we want. However I think we should first design the site we'd want to see and then recognize that we may need to have deviations.
I think "support" and "help" are very confusing as they are commonly (that is VERY commonly) used to mean similar things. in fact i hate them both so much that my suggestions doesn't even reuse them:
ReplyDeletei would suggest (just to stir the pot -- i haven't thought these through yet) the top domains be these:
science.usvao.org
systems.usvao.org
community.usvao.org
internal.usvao.org
again, these next ones are also straight out of my head so please don't kill the pigeon (oh, and i'm saving bits and not writing the root domain name in the paths)
- epo would become community:epo
- help:internal (jira) is not about community (nor about "help") since we censor it from the public eye so that would move to internal:jira or internal:dev
- move all docs to community:docs
i like the fact that these changes lead to setups like (examples only):
systems:software/svn
systems:dev [public trac site]
systems:status
community:forum
community:staff
community:epo
community:docs
internal:dev [jira]
internal:wiki
----
so my extracted suggestions are:
1. do not use support and help as top level domains (you can't its too confusing)
2. do not put internal sites on anywhere but on internal
Can someone say more about the pros and cons of
ReplyDeletewww.usvao.org/topic
vs.
topic.usvao.org/
For example, I see that amazon.com is organized the first way, although they have some (unadvertised) aliases like books.amazon.com that resolve to amazon.com/books. But they don't have them for all (or even most) of their categories.
With the form topic.usvao.org, doesn't every topic then have to get registered (and paid for)?
With respect to Bob's question, my thoughts.
ReplyDeletexxx.usvao.org
yyy.usvao.org
uses two host names and suggests that the pages are on different machines. It can be set up using only DNS servers. To my eye it suggests that these are independent of one another. The names are shorter. There is no obvious location for a page that refers to both of these.
class.usvao.org/xxx
class.usvao.org/yyy
This suggests that xxx and yyy are in the same machine and allows for there to be some hierarchical organization. E.g., class.usvao.org (without any extension) is a natural place to put a summary page.
If data are actually on different hosts, then forwarding needs to be set up, i.e., we do this at the application (Apache) level rather than DNS. Names are longer (though that's because
we added the 'class' host.
As your experience with Amazon suggests they aren't exclusive. In discussions with Sarah she suggested that we do something very similar, using the hierarchical names as the 'Full name' for the service, and the simpler host name as a shortcut.
I like community a lot more than epo in Gus's suggestion. I don't really like either support or systems too much. I certainly take his point that support and help are easy to confuse... Systems seems a bit to esoteric though. The idea is that this is for an audience who is willing to look at the underpinnings of the VO, not just interested in using it to do science...
ReplyDeleteI think I find Gus's suggestion slightly less confusing, although as I've said elsewhere I have a feeling we may be overthinking this a little.
ReplyDeleteI don't understand where online help/support/documentation comes in in Gus's suggested structure.
As I said at the Ops telecon earlier today, I prefer the hierarchical format (build on the right) because it requires fewer bookmarks for users and also easier to come back to a URL with auto-completion.
ReplyDeleteI'm cutting and pasting the full discussion from the Ops telecon here ...
ReplyDeleteWeb site organization. See article and comments on http://usvao.blogspot.com for discussion.
TM: This is of general interest
SB: From the blog post, it doesnt look like there's much interest
AT: Isn't heirarchical organization (building on the right) better
for users in terms of requiring fewer bookmarks and easier to
find URLs via auto-completion?
SB: Sure, but from website organizer's POV, doesn't really matter
which way you do it
TM: Bob was comparing amazon's approach, they actually use both
approaches
Dont mind having shortcut names in addition to heirarchical
URLs
SB: Having science.usvao.org seems redundant - everything we do
is science
AT: Dont we have different classes of users (scientists, public,
those looking for help)?
TM: Yes, and science.usvao.org can be the default
AT: Not sure why Gus hated "help" too in additon to "support"
DT: "help" seems better and more intuitive
TM: Static web pages should be under one site
Services like the portal can be distributed
SB: Would like to keep the shortcuts, e.g. iris.usvao.org
DT: This would become the standard URl for that service wouldnt it?
SB: No, the shortcut would resolve immediately to the real URL
TM: Dont have any objection to shortcuts but would like to go to
a structured format for website org, with science being default
url (so "science" wont actually appear in URL).
FWIW, my preference is that 'build-to-the-right" is for the public facing user pages, e.g. usvao.org/help (since then everything the public sees is branded as usvao.org and the function is a subset of the site). OTOH, 'build-to-the-left" is for internal use, e.g. iris.usvao.org is a developer's page (team or otherwise), perhaps with a redirection to the project host site.
ReplyDelete-Mike
a few points:
ReplyDelete1. i would assert that there is NO *user oriented* difference between using a subdomain:
iris.usvao.org
and using a vanity url:
usvao.org/iris
that also redirects (say to www.usvao.org/tools/science/vao/iris if you were to over engineer the hierarchy). I would also hypothesize that any argument that anyone makes about this is going to reduce to hasty generalizations or personal preferences unless one actually gives me a reference or citation.
2. I read around a wee little bit on SEO (search engine optimization) and the advices (ref: r1, r2,) are that subfolders have some SEO benefits over subdomains. For example, lets say that we have a wildly successful tool like iris and a new one like timeseries. if we use subdomains then:
iris.usvao.org gets all its SEO love while timeseries.usvao.org has to start from scratch.
On the other hand, if we use subfolders then www.usvao.org/timeseries gets all the SEO love from www.usvao.org/iris
Similarly, if one is searching for the vao forum or help or docs instead of tools then one needs to think about how the search engine will react. grouping the wildly successful 'iris' under the same subdomain as 'forum' will negatively impact the discoverability of forum (it may not appear 1st on a search for 'vao forum'). So if one wants users to find "forum" or other community based aspects of VAO *first* then one wants to subdomain community:
usvao.org/iris
community.usvao.org/forum
Repeating my original argument, the primary user oriented reason to use subdomains is to subset the audience. iris.usvao.org is a bad idea. QED.
(note I've intentionally ignored the fact that CNAME/subdomains are related to independent IP addresses/servers. My model presumes the system engineering should be subservient to the user oriented needs. it may be 'easy' to subdomain/CNAME machines at the cfa, at caltech, etc but that is less important. much less.)
3. A few direct responses:
@AT. help and support were originally proposed by Tom to group different content but the terms are completely synonymous. This is confusing without cause and causeless confusion should be hated. ;)
@Sarah: in my first response I gave the locations I proposed for help docs etc. They are under community.usvao.org.
References:
r1. http://www.seomoz.org/learn-seo/domain
r2. http://www.seomoz.org/blog/understanding-root-domains-subdomains-vs-subfolders-microsites
We just had an EPO telecon where we discussed this issue as far as it relates to the EPO site. I think some others from the telecon will make individual comments, but here are mine:
ReplyDelete1) For the general public, we have to have a simple domain name (or several that direct to one place) that is intuitive and does not use acronyms. epo.usvao.org or some variation means nothing to the general audience and they will have a difficult time finding us. This is why HST's epo program has a separate url called Hubblesite.org. It is a fallacy to think that the public/educators will be motivated enough to keep trying to find our site until they happen upon epo.usvao.org, or community.epo.usvao.org, etc. If they hear us on a podcast, or a similar venue, this would be meaningless and difficult to remember.
2) Jordan Raddick at JHU informed me that we have such a name purchased already through JHU. It is virtualobservatory.org. This would be my preferred site to use. It is a bit outdated and still refers strictly to the NVO, but it is a great starting place. If there are other similarly obvious urls we could purchase for cheap I am in favor of that as well. I inquired about virtualobservatory.com, but not sure who owns that. For epo purposes, we should not be afraid to create as many urls as necessary.
3) In thinking ahead about some of the comments I might get, I would also like to point out a possible compromise where we advertise our site as virtualobservatory.org and it is redirected to whatever structure is decided, i.e. epo.usvao.org. My preference is point #2 above, but this is an option as well.
Remember, the epo site is opposite to that of special interest groups. We are trying to reach, essentially, everybody and make them interested in the VAO. Our site can easily point to the general VAO site and vice versa. I think these comments generally reflect comments given by EPO members on the call, but hopefully a few more EPO members will speak up as well.
Brandon was too quick for me, and the post I said he'd make actually appeared before mine.
ReplyDeleteI second what he said, and I would add to his points:
1) Don't pay any heed to what's on virtualobservatory.org right now - it's outdated, and I'd be happy to throw it out and start over again, repurposing and/or rewriting anything that's helpful.
2) In addition to hubblesite.stsci.edu, STScI also has amazing-space.stsci.edu for one specific set of formal education activities. There are likely a lot of K-12 teachers who have used activities from amazing-space.stsci.edu who have never gone to hubblesite.stsci.edu.
That's OK. EPO audiences will seek out only what they need; if they find things they don't need, they are much more likely than astronomers or developers to lose patience and bail before they find what they need.
We should use the same approach as needed; if we create a set of great college physics activities, we should not be afraid to get buy a URL something like:
collegephysicsactivities.org
I'm making that up, but the point is that I agree with Brandon - we shouldn't be afraid to buy and post on several URLs.
In addition, to the comments that Brandon has made, for content it will be important to include "The Story of the VAO" and the telescopes/observatories/facilities that collaborate with the VAO. At STScI, a word document has been created briefing describing the telescopes.
ReplyDeleteBrowsing through the virtualobservatory.org there is a good foundation to begin to restructure things for the VAO EPO website.
Things to keep and reconstruct:
1. What is NVO (VAO)?
2. FAQ
3. Partners (Observatories/Collaborators)
(just to name a few)
For the VAO EPO website it may also be helpful to provide links for teacher/students to other resources and information like what is done on the virtualobservatory.org "Partners" section. A good addition would be pointing to the Great Observatories on the Amazing Space website, "Telescopes from the Ground Up". (Material from Amazing Space is used in every state across the US).
It is also important to reiterate the comment made on the telecon today, that we should only provide content that we have. So no empty pages saying "Teacher Section coming soon".
virtualobservatory.org is a great EPO landing spot plan
ReplyDeleteI must make a few other points however:
1. Brandon, I think you are overlooking something by making a core assertion that people absolutely have to 'remember' the web address. this is just not true -- SEO wins the day. as i pointed out people will do a web search for the topic and will hit various related sites. the goal is to have the right site at search result spot #1. Related sites should be appropriately linked to enable discovery via click through -- for example, usvao.org should have a prominent tab and link to education and outreach no matter what its final web address is named.
Let me also be clear: when we say 'buy and post on several URLs' we had better mean, 'buy multiple URLs and use 301 redirects to virtualobservatory.org' because content mirroring is just about the worst SEO activity you can engage in. Google will KILL YOU for content mirroring.
2. other very successful epo efforts do not have vanity urls. chandra has a pretty good epo team as well. they use a very simple web address:
chandra.si.edu/edu
it changed recently. it use to be:
chandra.harvard.edu/edu
Both still work. This subfolder links off the main site via a tab called "Education." in this vein I bet that podcasts about chandra educational materials yield a google search for chandra educational materials, and people then click through as necessary.
similarly, EPO projects like "cool cosmos" have memorable names that resolve via search to coolcosmos.ipac.caltech.edu.
the point is that these completely successful efforts have best practices that undermine URL memorability as a core reason for a vanity url. this is because SEO wins the day.
(though we should still use virtualobservatory.org because I imagine myself as devious and desire a pan-VO EPO effort rather than one that focuses exclusively on VAO efforts/products).
3. hubblesite.org is a great example of simple to remember website name but hubble EPO is NOT a good example of simple to understand EPO effort:
http://oposite.stsci.edu/
http://hubblesite.org/
http://heritage.stsci.edu/
http://hubblesource.stsci.edu/
http://amazing-space.stsci.edu/
http://origins.stsci.edu/
http://outreachoffice.stsci.edu/
This represents a level of fracture that I don't frankly understand.
virtualobservatory.com was bought up by a cybersquatter 12 years ago.
ReplyDeletehttp://whois.domaintools.com/virtualobservatory.com
My original post above was suggesting different virtual hosts based upon different audiences:
ReplyDeletescientists doing research
engineers building tools
the VAO itself
the public
so that each of these audiences had their own host. Of course a given individual might participate in different audiences at various times.
Gus brings up the very good point that we need to think about how any choice affects search engines since that is how people are going to find us no matter how we organize things. He suggests that putting everything under a single domain (except perhaps EPO) might have both advantages and disadvantages.
I've been thinking about help a bit... In the first plan above, there's a single help entry which is presumably unified help for all of the audiences. Is that desirable or should we have specialized interfaces for different groups? There's clearly some overlap between the kinds of help we might give, but there is a lot of stuff that's inappropriate too so that specialized interfaces might be more effective.
Where to go next? My feeling is that the center of the discussion (including our discussion in the Operations telecon) is that there is some need for hierarchical structure. The EPO might be outside the structure for the rest of the VAO (or might not). Using shorter names as 'soft links' to elements deeper in the structure may be useful.
At today's management telecon I'll bring this up and propose that Betty (since user support is responsible for Web site design) and I and anyone else interested put together a top level hierarchy in the next week or so.
Some discussion points made on this blog:
ReplyDelete1) Tom M. wants a structure enforced or we run the risk of becoming messy and hard to find content.
2) Gus want us to factor in search engine optimization (SEO) in order to make it easy for the end user to find the content they are looking for.
3) Brandon and other EPO folks want their own URL or at minimum treated at the level of the science.
4) From a Ops perspective, a top level design and should be one that is easy to implement and manage.
I suggest the level hierarchy:
In context of r2, Gus's suggestion are 'sub-domains', we don't need to register or pay for:
usvao.org/
/iris
/timeseries
/discovery
/epo
systems.usvao.org/
/software/svn
/dev
/status
/..etc
community.usvao.org/forum
/doc
/staff
internal.usvao.org/
/dev [jira]
/wiki
I would argue that having epo at the same status level as the science initiatives is better than having it's own vanity URL. Using sub-domains to separate the content to not adversely impact the discoverability of forum (or vice versa).