Computing & Information Services | Brown University

Service Descriptions:

• Service descriptions should be as short, yet complete as possible. They describe the basics of the service. Details about the service should be in the support information, not in the description.
• The description should be no more than a few sentences.
  • The first sentence or two should describe the service as it exists on its own, as completely as possible.
  • A third or forth sentence can be used to describe or elaborate on features or uses.
  • Optionally, a final sentence can indicate any important technical info such as the platform on which the system runs.
  • If the service contains sub-service or related services, a second paragraph could list sub-services or describe a related service in 1-2 sentences. As such, the related service(s) should be linked in that paragraph.
  • To see this done well, with a related service see:
  • http://www.brown.edu/it/services/service/web-hosting-services
  • To see this done well using a list of sub-services and a related service see:
    http://www.brown.edu/it/services/service/web-design-and-development-serv...
  • Additionally, tags can be used to group a set of services and tags can be linked from that second paragraph.
  • See Google Sites: http://www.brown.edu/it/services/service/google-sites
    There is a created GoogleApps@Brown tag that all services have and the link to that tag is in the last paragraph of the description.
  • When necessary, for complicated similar services, the service description should link to a page of documentation that compares two services in detail. For instance, both the Brown-Secure and Brown-EZ descriptions should link to the wiki support doc that distinguishes the two services. The text on Brown-EZ would say, "Alternatively Brown-Secure [link to that service] allows users to access additional services that would otherwise require wired access. Learn about the [link start] difference between Brown EZ and Brown Secure[end linked].

Cost:

• Use 'Free' when possible instead of 'none' or other language.

Service URL and Service URL Screenshot:

• Not all services have a URL, but for those that do, the URL and a screenshot can be stored in the catalog. For instance, the Service URL for the wiki is wiki.brown.edu. If the service is used online and the service has a web address, then that address is the Service URL.
• Some services will not have a Service URL. For example, there is no URL where, where the service ‘SSL Certificates’ live. There is a website that describes how to order an SSL certificate (this should be in the ordering information) and there may be a website for what to do it an SSL Certificate is broken (this is the support URL) , but there is no Service URL. Additional links that may relate to the service can be placed in the service description when approriate.

Support Type:

• The support information for most CIS services should be the Helpdesk. Typically, non-CIS services The goal should be that there should be the smallest number of support types possible. Ideally, CIS has no more than the helpdesk, telecom, and maybe a special one for ATS. Anything else is confusing to users and the helpdesk when they get calls.

Tags:

• Tags serve two purposes: relate content, provide an alternative search keyword/method. All tags should do one of these. If they don't, then delete them. If the search term is already in the description, and it doesn't connect services, consider deleting the tag.
• The Google Apps example provides a good example of grouping services with a tag. Similar tags could exist for "collaboration" or "printing."
• The preference for the catalog is to have fewer, more meaningful tags. Capitalization and formatting do not matter. Choose existing (auto-suggested tags) when possible. When creating new tags, there is only a need for 1 variation (ie GoogleApps@Brown is good, there is no need for googleappsatbrown or googleapps@brown, etc).
• Whenever possible, a tag should not relate to only one service.