AstroGrid Online Presence

Introduction

In order to work out what types of online presence AstroGrid needs to provide, I will consider, first, who the primary stakeholders are in AG and what types of information or services each might require. This will provide our first way into the AG online presence: a person is directed to the information relevant to the role they are currently playing. But those who come to the AG site may know exactly what they want so we will need to provide access to all the above in a functional way as well.

Stakeholders

AstroGrid can be considered to have the following types of stakeholder:

• Funding bodies
  groups which will provide financial or other types of resource to AG
• Astronomer
  person who uses AG components to carry out science
• Administrator
  persons who administer the configuration of an AG installation (or specific components of an installation), including lists of users within a community, access privileges to datasets, registration of resources ...
• Partner
  a site, organisation or projectwith which AG has a collaborative arrangement, eg a body which adopts the AG suite or selected components in order to offer a service to its own set of users; or a project which needs to interface with AG services; or other organisations with which AG is developing standards
• Systems administrator
  persons who install and are responsible for updating AG components at a given partner site
• Developer
  persons who may develop and maintain AG infrastructure components and/or add-on components and/or stand-alone applications which interact with AG components

Note that there is broad overlap across those divisions and any one person or organisation may be able to take on more than one of the above roles.

What is AstroGrid

The AG project is different things to different people. To the people employed on the project it is, primarily, a project tasked with developing the VObs software infrastructure and initiating its deployment and use in the UK. To an astronomer, it is a provider of services that he/she accesses via a portal or some other software. AstroGrid needs to provide information relevant to each of the different parts it plays. Those parts can be summed up as:

• systems development project
  • this is what the AG project currently spends most of its time doing - the software developed can be either server-based or client-based but the majority of it is infrastructure: little effort goes into writing astronomical tools or applications
• systems provider
  • the software is packaged on a roughly six-month basis into a release which is made available for people to deploy: system administrators at sites running AG software will be required to download components and install them so that services provided by that site are up to date
• service provider
  • AG has also started the rollout of components to specific sites in the UK, primarily those sites from which the AG consortium is drawn: these deployed components are available to end-user astronomers but AG provides only limited support to those users
• service consumer
  • the majority of components that make up the AG suite are written by the project development team but some command-line and other types of application have been wrapped to deliver VObs-style services; AG can also consume services simply by invoking them in a workflow
• partner in other efforts

What information is wanted

• what has been done: historical information, documentation
• what will be done: plans and designs
• what is being done: progress information
• what can I do, where do I find it and how do I use it

Reference exemplars

• NVO front page
• Open Sky Query

Online presence for stakeholders

It is now time to look at how each stakeholder will get to where they want to go. I will look at each section of information wanted above and note how that stakeholder would want the information delivered.

Funding bodies

Generally funding bodies and their representatives will look at AG on a periodic basis, say every 6 or 12 months. They will want to track progress against goals, look at future plans and to see how well the system is being taken up and used by astronomers.

• what has been done
  • historic mapping of goals: planned against actual
  • summary of current capability of system, including:
    • data and apps available
    • portals deployed etc
• what will be done
  • long term roadmap
  • deliverables for current milestone
• what is being done
  • summary of how system is being used
    • what science is being done
    • and by whom
• what can I do, where do I find it and how do I use it
  • n/a?

Astronomer

The users of the AG system, the astronomers, will generally only be interested in what the system can do for them now and in the future. Their perspective will be, not just on the capabilities of the AG system itself, but on any astronomical tool that can help them solve their problem. It is essential that we bear this in mind and show how non-AG tools can be combined with AG components and tools to achieve scientific goals.

• what has been done
  • able to see what science has been done
    • and access to workflows used (if allowed)
• what will be done
  • services planned for future versions
  • integration with other tools planned
• what is being done
  • exchange of views with other users
• what can I do, where do I find it and how do I use it
  • examples of science that can be done
  • pointers to tools & portals which give access to VO
  • online tutorials, FAQs etc linked from tools & portals
  • links to help forums, helpdesk (email only)
  • links to workshops, meetings etc

Administrator

• what has been done
• what will be done
• what is being done
• what can I do, where do I find it and how do I use it

Partner

• what has been done
• what will be done
• what is being done
• what can I do, where do I find it and how do I use it

Systems administrator

• what has been done
• what will be done
• what is being done
• what can I do, where do I find it and how do I use it

Developer

• what has been done
• what will be done
• what is being done
• what can I do, where do I find it and how do I use it

Functional access

State information

what is happening in the project

Service access

where do I go to do X

Download and install components

finding them and installation instructions

Coding

getting code, contributing code, interfacing code

Communications

Email

main point of contact should be helpdesk@astrogrid.org

Blogs

want to provide blogging tool for anyone involved in the project - can help to build loyalty and allow those who interact most with the project to establish an ag-oriented identity

VoIP

providing voice contact should be longer term - need some way of allowing us to use voip to contact people without having permanent people associated with a help line

News

events coming up etc - scrolling list on front page of last 5 headlines

Wiki

do we want to keep the existing wiki or launch with a new one, more closely managed? or maybe we need to keep existing one for development project and create a new one for operational use

Support forums

am impressed with quality of VMWare forums and am in touch with provider (Jive software) to find out how much they cost

FAQ

will need these for different areas: nice thing about Jive software is that FAQ can be built from forum answers by indicating which answers qualify

Website

Given the different audiences that we need to address and the variety of information we have to provide, I suggest that we look at another site which has similar site needs to us (though is a slightly bigger organisation)...

Exemplar: Microsoft

What MS has is a front page - http://www.microsoft.com - from which you can get to the start pages for they type of user you are or the products you use:

• products: Windows or Office or Server products
• user types: Home users or Business and Industry or Small Business
• developers: MSDN
• support personnel: TechNet
• partners: Partner Program

Structure suggestion

So, let's take a leaf out of the Microsoft approach. First we need to start with a home page which tells everyone who hits just where they need to go for the next step. From that we need to provide the core start pages. We ought to create one for each product and user type:

• products
  • Workbench and related tools
  • Server products
• user types
  • Astronomers
  • Developers
  • Tech Support
  • User Support
  • Partners
    (I'll include all other stakeholders - eg funding bodies - in this category)

As with the MS home page, we should have a sidebar which links directly to common AG destinations, such as:

• About Us
• Downloads
• FAQ
• Blogs
• Astro-Wiki
• Dev-Wiki
• Forums & Mailing lists
• Contacts

and links to associated sites:

• PPARC
• EuroVO
• IVOA
• US NVO

Communities

The other good feature of the MS approach is to build communities where it is appropriate and to give those communities their own sub-domains and style of web pages. In the case of MS, they seem to focus on the user-types and that makes sense for us as well. So, we could have:

• AGDN: AstroGrid Developer Network: agdn.astrogrid.org
• TechNet: for Tech and User Support groups: tech.astrogrid.org
  (decided against SupportNet and support.astrogrid.org because it sounded too much like user support and might get confusing)
• Partner Programme: for partner projects, countries using AG etc: partner.astrogrid.org

There doesn't seem to be any attempt, with MS, to build basic user communities, perhaps because they'd be so large as to not work, or because MS expects user support to come via the organisations who sell or provide access to their products. We'll need to provide some user support via the web sites, or at least pointers to where user support can be obtained but I'm not sure what to call it, so, for now, let's work on:

• AG User Network: for astronomers using the workbench or portals: user.astrogrid.org

Each community should have its own wiki and forums (perhaps not the partner one - I suspect it'll be mainly used for executive access - read-only - getting at plans etc).

The other useful thing with splitting the site into communities is that different individuals or groups can look after the content of each community sub-domain.

Technical approaches

The ideal would be to have a complete separation of content from styling with a professional CMS (content management system): in such a system, a piece of information is provided with little or no styling information, is stored in a database, and when someone accesses that information it is displayed using the styling of the community from which the user requested it. I've not seen this in any open source CMS and suspect it'd take too much for us to manage anyway. This is even more than MS provide anyway.

But it would still be useful to employ an OS CMS. http://www.opensourcecms.com/ is a good source of comparative information. We'll need to decide whether the time needed to learn how to deploy and use such a package is worth the time saved in the long run in creating content.