Requesting a GSD Subsite

Who Qualifies for a Subsite?

A subsite is a website that is hosted under the GSD’s domain name, that bears the school’s name or logo, or that otherwise purports to represent the opinions or work of the GSD, but is not directly part of www.gsd.harvard.edu. Subsites must meet the following criteria:

• Be sponsored (“owned” and “maintained”) by a current member of the GSD faculty, administration, or student group and be related to a GSD-affiliated research center, design lab, program, or initiative.
• Support the GSD’s mission.
• Provide lasting value to the school.
• Satisfy an unmet need.
• Have an ongoing staffing and maintenance plan.
• Demonstrate adequate funding to meet start-up and ongoing maintenance costs (if school funding is not available).
• Register relevant ownership and technical details with GSD Web Staff, enabling GSD Web Staff to make changes in hosting plans or content, as required or needed.

All new GSD subsites must be approved by the Digital Governance Committee before they are created. Student group websites are an exception. Student groups must seek permission only if they wish to make use of the GSD Site Builder, described below.

How to Request a Subsite

Before requesting a new site, contact the GSD’s Digital Project Manager to schedule a meeting to discuss your plans for a new site. If it is determined that a subsite could be a good option for your needs, you’ll be asked to fill out a New Site Information Form . The web team will then review your request. If  your request is approved, you have three options for creating your site:

• GSD Site Builder : This platform was specifically built for the GSD so qualifying community members could create a GSD subsite with minimal assistance from developers. This platform is built using WordPress and provides a drag-and-drop editor so site owners can control their page layouts. It is the only site builder that is maintained by the GSD and is the most cost-effective option. Visit the GSD Site Builder website for more information on the capabilities of this platform. Student groups must request permission for a subsite only if they wish to pursue this option.
• GSD Site Builder & External Vendor*: If you’d like to use the GSD Site Builder platform but want to customize it for your needs, you may hire a third-party vendor to make the adjustments you require.
• External Vendor*: If the Site Builder platform doesn’t meet your needs, you can contract an external vendor to create your site from scratch.

Once you have chosen one of the options above, the web team will advise you on the process and next steps. The GSD web team is available to provide insight on integrating your site with the GSD’s API and making sure your site adheres to Harvard policies and best practices, including the GSD’s Digital Governance Policy, and Harvard’s Digital Accessibility Policy . All GSD subsites must be hosted through the GSD.

*If you choose to hire an external vendor for your subsite, you must provide the GSD web team with documentation of your project plans, a timeline for the project, and technical details when the project is complete. External vendors will be responsible for maintaining your site after launch.

Unauthorized Subsites

An Unauthorized Subsite is a website that purports to represent the opinions or work of the GSD or uses the GSD name or branding elements and has not been approved and does not meet the requirements for a GSD Subsite set forth above. In the event that GSD Web Staff become aware of an unauthorized subsite, GSD Web Staff will attempt to contact the site creator(s). If the responsible parties can’t be contacted, GSD Web Staff may take all possible measures to assume control of the site or to have it taken down. If the unauthorized site creators are responsive, they will be advised of the non-conforming elements of the site, and asked to provide a remediation plan and schedule to resolve the issues, and may be asked to immediately modify or take the site down in the interim. In this remediation, GSD Web Staff can provide strategic guidance and technical oversight, but all costs associated with bringing the site into conformity will be borne by the site owner.

 

Social Media

Public Programs

Planning a Public Event

Department and program heads collaborate with Public Programs staff to invite guests and organize each program. Faculty and students are encouraged to share ideas for programs with their respective Chairs. Students, staff, and faculty are also invited to submit suggestions using the community submissions form .

Veronica Bagnole

How to Post an Event to GSD Now

Summary

There are two parts to planning an event that you also want posted on GSD Now: (1) submitting an event proposal, and (2) after your event is approved, returning to your event proposal to provide event information to be posted on GSD Now. These two parts are summarized below. If you do not want your event posted on GSD Now, you only need to complete Part One in order to propose an event. For more information and general guidelines about planning events at the GSD, students should consult Event Planning For Students and faculty and staff should consult Event Planning for Faculty and Staff.

Part One:  First you must submit an event proposal. To get started, please log into SERT and navigate to the top-left corner of your home page and click “Create a Reservation.” Detailed instructions for completing and submitting your event proposal are outlined below this summary. Event proposals are reviewed and approved by committee every Thursday afternoon while classes are in session. Proposals received by 9 am EST on Thursday will be reviewed that afternoon. Events must be approved in order to be eligible for publishing in GSD Now. Proposals that are submitted as incomplete will not be reviewed.

PLEASE NOTE:  Faculty who plan to open a course session to be attended by the rest of the school should follow this process.

Part Two: After submitting your event proposal, you will receive an email notification that your event is approved or requires a different date or further information. If your event is approved and you would like your event to be posted on GSD Now, you will be asked to return to this page in SERT to complete the second half of the event proposal form, in order to provide all event information and confirm that the event is ready to be posted to GSD Now. After confirming that your event is ready to be posted to GSD Now, your event will appear on GSD Now within four hours. If you do not want your event posted on GSD Now, disregard Part Two. You may fill in these fields during Part One if you have the GSD Now information when you are submitting the event request form. If you choose to do this, your event will be published to GSD Now within 4 hours of being approved by the Events Committee.

Submitting an Event Proposal in SERT

1. Once you are logged into SERT , navigate to the top-left corner of your home page and click “Create a Reservation.” When you are taken to the next page, click “book now” next to the reservation template “GSDNow Event Request, [Semester, Year].”

2. Select a date, start time, and end time for your event. All times should be Eastern Time, and SERT defaults to this time zone.

3. Beneath the event date and time, you will see a box titled “Locations.” Please click “Search” just below it. On the right side of the page, SERT will show you a list of rooms that you can select, including the Virtual Event Space for virtual events. In the box titled “Rooms You Can Request,” click the green button showing a plus sign next to the space you want to select. Then, when prompted, enter any value for number of attendees that is more than zero.

4. Click the blue button “Next Step” on the top right of the page. Clicking “Next Step” will take you to the portion of the event proposal form titled “Services” (please request custodial services if necessary) and then “Reservation Details,” where you are asked for specific details about your proposed event.

5. After the screen advances to the next page—”Reservation Details”—you will see that this portion of the event proposal form is organized into a few discrete sections. The first section is titled “Event Details.” Under “Event Details,” enter a name for your event in the space provided—note that this name is used for internal reference only. Later in the process—if your event proposal is approved and you would like to post your event on GSD Now—you will be asked for the official name of the event, as you would like it to be communicated to the school.

6. Under “Event Type,” select the format of the event that best describes what you are planning. Please note that your selection will determine how your event is categorized on GSD Now, if you choose to post your event there.

7. Move on to the next section, titled “Group Details.” The “Group” name is related to your role at or connection to the school, and it will automatically be populated according to information collected from your HarvardKey. Under “1^st Contact,” please select the name of the person whom GSD staff should contact for questions and further information. Name and contact information for that person will be automatically populated. If that person’s name does not appear in the drop-down menu, please manually enter their name and contact information.

8. Move on to the next section, titled “Additional Information.” In this section, please fill out the prompts (nine prompts, if you select “yes” in response to the first one) in order to submit your event proposal. If you do not have an alternative date and time for your event, do not enter one. After the prompt asking if your event needs advance registration, you may scroll down to the bottom of the page, fill in the question about food and drink, agree to the terms and conditions, and click the “Create Reservation” button on the bottom right corner of the page. Alternatively, you may choose to respond to the remaining prompts (outlined below) if you already have all the information you need to publish the event to GSD Now. If you choose not to fill these in, you will need to return to this form to respond to those prompts after your event is approved if you would like your event to be posted on GSD Now.

Event Approval

Event proposals submitted through SERT by 9am EST on Thursday will be reviewed on Thursday afternoon. After your event proposal is reviewed, you will receive an email notification that your proposal has been approved or requires a different date or further information.

PLEASE NOTE: Proposals submitted by or on behalf of faculty who plan to open a course session to be attended by the rest of the school can be expedited by contacting [email protected].

Posting Your Event to GSD Now

After your event is approved, if you would like your event to be posted on GSD Now, return to your homepage in SERT and click on “My Events.” Locate the event you would like to post to GSD Now, and click on the event name.

SERT will then show your event details as you provided them in your event proposal. Click on “Edit Reservation Details” in the top left corner of the page. Next you will see the event proposal form and all of the details you already have provided. Scroll down to the section titled “Additional Information,” and respond to the remaining prompts on this page, beginning with the prompt that starts “Before proceeding, click “Create Reservation” at the bottom of this form to submit your proposal…”

In all of these prompts, be sure you are providing information about the event that is accurate, complete, and free of errors. The details you provide in these fields will be posted to GSD Now and communicated to the school exactly as you enter them on this form, so you are strongly encouraged to proofread all details. Please note that you can enlarge text boxes in places where you are asked to provide text—doing so will make editing much easier.

When you are confident that all of your event information is accurate, complete, and error free and ready to be posted on GSD Now, please confirm “Yes” in the final prompt at the bottom of the page, and then click “Save Reservation Details.” If your event has already been approved (see Part One) then your event should be published to GSD Now within 4 hours. If your event has not been approved yet, your event will be published to GSD Now within 4 hours of being approved by the Events Committee (Thursday afternoon). Please check your event in GSD Now to make sure it looks correct.

Please direct questions about your event to [email protected].

Please direct questions about GSD Now to [email protected].

Harvard Design Press

Chad Kloepfer

Digital Governance Policy

The Harvard University Graduate School of Design website (www.gsd.harvard.edu), and other public GSD digital properties, play a key role in strengthening the School’s online presence. It is, therefore, of vital importance that our community maintains gsd.harvard.edu, subsites, and other public digital properties according to best practices, institutional policies, and at the highest quality possible. This document details the online management and governance of the GSD’s public digital environment.

Digital governance pertains to people, policies, procedures, standards, and guidelines that govern the creation and maintenance of our official website and other public digital properties. These include all pages managed in the main website’s Content Management System (CMS), GSD subsites (on Site Builder and other platforms), externally focused applications and services, social media sites, mass emails and e-newsletters, tools supporting public e-communications, and all media hosted on external sites.

This policy does not pertain to websites, digital tools, or educational technologies that are not intended to be shared publicly, including those for internal administrative use or for use within courses, studios, and other non-public learning groups.

1. Objective

The primary objective of this document is to provide collaborative centralized governance for the ongoing development, deployment, delivery, and maintenance of the GSD’s public online presence and to represent the GSD brand consistently across public digital channels through standard processes, roles, responsibilities, and practices.

This objective will be pursued with the school’s underlying strategic priority in mind: to facilitate a user experience that will develop a lasting digital relationship with all visitors—particularly current and prospective students, faculty, and staff—providing them with the information they need quickly, easily, and enjoyably.

2. Governance Structure

The Digital Governance Committee is composed of the assistant dean and director for communications, the assistant dean for information services, the assistant dean for information technology, the digital project manager, the web services manager, a faculty representative, and other GSD community members who may be invited from time to time.

It is the responsibility of the Digital Governance Committee to set the direction and policies for the GSD’s public online presence and digital properties, including the school’s official website and the web operating environment, based on best practices. In order that directions and policies are set with a full understanding of the issues and impact of any given decision, decisions appropriate to the jurisdiction of the Digital Governance Committee will be reached by consensus. If the group cannot reach consensus, options will be presented to the GSD’s Executive Committee with a recommendation for resolution.

Responsibilities of Digital Governance Committee include:

• Establish appropriate policies, processes, and procedures to govern digital strategy and standards for public GSD-branded communications.
• Evaluate effectiveness of policies and standards.
• Ensure compliance with all legal and regulatory standards, including accessibility, security, privacy, etc.
• Authorize global changes to taxonomy, structure, branding, look and feel, navigation, styling, etc., as needed.
• Ensure quality, consistency, and content integrity across digital platforms.
• Facilitate and resolve non-compliance issues.
• Provide guidance for the use of web properties for the GSD community

The Digital Governance Committee will meet at least once per semester to review requests from academic and administrative stakeholders for major changes to the GSD website, other digital properties, and/or relevant policies and procedures. They will update the Dean and Executive Committee on project plans, if necessary, and disseminate information to their staff and department members, as needed.

Community members are invited to send ideas, requests, problems, and concerns to the Digital Governance Committee via email to the Web Team. Ideas, requests, problems, and concerns will be logged into a ticketing system and reviewed with the committee on a semester basis.

3. Governance Policies

The GSD’s main website, subsites, e-communications, and social media sites provide public platforms for showcasing the School’s best qualities and projecting a positive image of the School to the world. They are strategic assets that carry enormous influence and provide global access to multiple aspects of the School. With a distributed content team managing these sites, guidelines that encourage clarity, accuracy, and consistency are essential to protecting the GSD’s online image. This document aims to cover most areas of digital governance, but if you have questions that are not answered upon reviewing this document, please contact the Office of Communications.

The website gsd.harvard.edu is the sole property of the GSD. While designated staff will have access to edit certain portions of the site, create new content, and remove old content, the site and all its subdomains remain the property of the School.  Additionally, the Site Builder theme and all sites built with it are the sole property of the GSD.

4. Policies and Procedures for GSD Websites

A ‘GSD website’ is any website, including gsd.harvard.edu and all subsites (as defined below), that purports to represent the views and activities of the GSD community, that is owned or managed by any GSD employees or official student-organization, or that uses any GSD branding. Any such website must be approved by the Digital Governance Committee and is subject to all the requirements in this document. Please see section 4.2 on GSD subsites (below) for information about how to request approval of a new GSD-branded website.

4.1 GSD.HARVARD.EDU

a. Content Management System

All content is published to gsd.harvard.edu using the WordPress Content Management System (CMS). No other software product may be used within the GSD’s approved CMS and its build architecture. Additional sites, upon approval, may use the gsd.harvard.edu API when appropriate. Content editors located in offices and departments across the School are expected to regularly check all content on pages they manage to ensure that it is up-to-date and that all links are functioning correctly.

b. Roles and Permissions

A group of content editors, representing offices and departments throughout the School, manage the content on the website. Department and office administrators may nominate a staff member to be a content editor if they meet the criteria outlined in the GSD’s Content Editor Policy, and if their allocation of editors has not already been met. These requests should be submitted through the Content Editor Request Form. If the nomination is approved by the Web Team, the editor will be granted access to a Canvas course where they must complete the required training, after which, they will be given access to the CMS. Access will not ordinarily be granted to students, faculty, or temporary workers.

Department administrators must maintain a list of current content editors, and should contact the Digital Project Manager if an editor’s access should be revoked (e.g., when an employee changes jobs or leaves the GSD).

Editors will be assigned a contributor role that gives them access to the content areas they need to maintain their pages. Editors will not have access to areas of the site where they do not maintain content.

In addition to the contributor roles defined within our CMS,

• The Office of Communications is responsible for generating and maintaining content for the homepage and top-level landing pages, and provides content writing, editing, organization, and design guidance to departments school-wide.
• Academic chairs, department directors, non-departmental program directors, and office managers, are accountable for:
  • Providing content editors with recommendations regarding content direction for their webpages that align with the school’s strategic web goals and the established site structure.
  • Ensuring that content is accurate, up-to-date, follows best practices for web content and usability, and meets the School’s quality standards.
  • Coordinating with the Digital Project Manager to ensure that an editor is assigned and trained to maintain their pages.

c. Quality Control

Maintaining the quality and accuracy of the GSD website is a shared responsibility that needs to reflect the brand, mission, and values of the institution. Typos, poor grammar, outdated information, etc. detract from effective communication of what makes the GSD an outstanding place to study and work.
The GSD’s Office of Communications has access to all areas of the main website and social media channels. To ensure quality control, the Office of Communications may edit or alter content as needed, for clarity, consistency, and style, to ensure quality control and to conform with school naming conventions and branding. The GSD reserves the right to revise or delete content housed either on school resources or external resources that does not meet acceptable use guidelines, or the standards outlined in this policy.

Department and office administrators are responsible for ensuring the quality and accuracy of all content changes made on their pages. If error(s) appear on a page, administrators should contact the editor responsible for that page first, and if the error is not resolved within a reasonable time, the administrator should contact the Web Team.  If quality control issues recur, the Office of Communications will relay the concern to the editor’s manager and may suspend editing privileges until the editor completes further training.

In addition to regularly maintaining their content, editors and their supervisors are expected to carry out an annual content audit on all of their web pages. During this process, content should be updated, unnecessary pages should be unpublished, and a general review of usability and accessibility should be conducted.

d. Change Management and Classification of Changes

Changes to the GSD website may arise reactively in response to problems, or proactively in seeking improved efficiency or effectiveness, as well as to enable or reflect institutional goals and priorities. Change Management ensures that standardized methods, processes, and procedures are used to facilitate efficient and prompt handling of all changes and maintain the proper balance between the need for change and the potential detrimental impact of changes. Changes are classified as follows:

• Fixes: A fix can be an urgent, unplanned change (aka a “hot fix”) or a planned change that goes through the standard release and deployment process.
  • An “Emergency” is defined as a change required to immediately restore service or to avoid an outage where no other workaround is available.
  • An “Error” or “Bug” is defined as a deviation from expected behavior that does not require emergency change handling and where a workaround is available. Examples of “bugs” include incorrect data fed from third party services, inconsistent cross-browser support, errors in site search, etc.
  • An “Urgent Bug” is an error that impacts core functionality (e.g., site search), operations (e.g., course directory), or system performance, or that exposes the School to security or legal liability (e.g., Harvard Key authentication errors or failure to meet University guidelines for accessibility). Bugs should be reported via the Error Report Form .
• Enhancements: Enhancements are planned changes that go through a review and approval process.
  • A “Small” change is defined as an update to existing content. “Small” changes can be implemented directly in the content management system by an authorized editor.
  • A “Medium” change is defined as any change that impacts the information architecture, organization, and search engine results of the site. Examples of “medium” changes include modifications to site navigation, the creation of new pages, or the reorganization or renaming of existing pages. Medium changes must be implemented in collaboration with GSD Web Team members with specialized knowledge of best practices in content strategy, web usability, information security and accessibility, and search engine optimization (SEO). Medium changes may require approval of the Digital Governance Committee. Requests should be submitted via the Enhancement Request Form .
  • A “Large” change is defined as any change that impacts the data structure, theme, or functionality of the site. Examples of “large” changes include the creation of new sections or content types; modifications to the look and feel or user interface design of the site; adding or removing attributes of a data type; modification to an existing feature; creation of a new form, feature, or interaction; integration with a third-party system or service. Large changes must be implemented in collaboration with GSD Web Team members with specialized knowledge of best practices in web design and usability, information security and accessibility, and web development, and have experience with the GSD’s custom implementation of WordPress. Large changes typically require approval of the Digital Governance Committee. Requests should be submitted via the Enhancement Request Form .

e. Change Management Process

The Change Management Process begins with the identification, recording, and classification of the change, and continues with its review, approval, scheduling, development, testing, and staging for implementation. Changes must be submitted with appropriate lead-time to allow the Web Team to perform these tasks and to ensure that individuals impacted by the change receive adequate notice.

1. Request Change: All “Errors” or “Bugs” (defined above) should be reported via the Error Report Form . Errors reported via this form are automatically logged in a ticketing system and reviewed by the core Web Team. “Emergency” errors will be addressed immediately. “Urgent” errors will be scoped and prioritized upon receipt. Non-urgent errors will be scoped and prioritized along with other change requests during weekly meetings of the core Web Team. Requests for Medium or Large “Enhancements” (defined above) should be submitted via the Enhancement Request Form . Members of the GSD Web Team will review these requests in their weekly meeting and will evaluate whether the request can or should be fulfilled. Submitting an enhancement request does not guarantee that the site will be updated to accommodate the request.
2. Define Scope and Impact: Defining the scope of a change includes identifying the platforms impacted; cost of development; maintenance requirements; units or departments affected; business case or rationale for change; alignment with known strategies and stated objectives; potential conflicts; skills or expertise required to implement the change; availability of internal or external resources; and an assessment of institutional and technical risk. This data is used at many decision points within the process. Examples of questions used in assessing the risk or impact of a change:
   1. Who will the change affect?
      1. Staff resources
      2. Business units or departments
      3. End users
   2. What will the change affect?
      1. Sites, sections, or pages
      2. Platforms, systems, or services
      3. Data models, feeds, or flows
      4. Internal processes or workflows
      5. User behavior
      6. Identity, look and feel
   3. What is the impact on?
      1. Other scheduled changes
      2. Other business units or departments
      3. System design
      4. System performance
      5. Search engine results
      6. Institutional identity
      7. Other resources (budgets, staffing, security, etc.)
3. Approve, Reject, or Modify Change: Change requests will first be reviewed by the core Web Team. After review and initial scoping/risk assessment, the Web Team may either approve or reject the request. Every attempt to resolve issues or conflicts will be made prior to rejecting a change, including suggesting modifications to the scope, design, or timing of the original request. If there are questions about the appropriateness or feasibility of a request, it will be referred to the appropriate technical or communications lead for a decision. If a decision cannot be made or the requesting party disagrees with the decision, the request will be reviewed by the Digital Governance Committee, which will make the final decision.
4. Prioritize/Schedule Change: Every effort will be made to implement changes in a timely manner while recognizing the need to balance required maintenance, upgrades, and fixes with desired enhancements to existing content and functionality. Following approval of a change request, the Web Team will use their judgment to prioritize the request among other planned changes. If a change involves high risk, it may be scheduled to minimize impact (e.g., during intersession or summer break). Technical or operational interdependencies discovered during the review and scoping process may also affect timing. If the requesting party disagrees with a scheduling decision, it will be reviewed by the Digital Governance Committee, which will make the final decision.
5. Implement Change: Implementation of an approved medium or large change may only be performed by the GSD Web Team, a staff content editor working in collaboration with the Web Team, or a designated vendor. Changes will be deployed to a web staging environment for review and approval. Upon approval, the Web Team will follow the standard release and deployment process. Documentation of changes will be stored in a common location to allow for coordination among team members. Criteria for a successful change include:
   1. The change was implemented in accordance with the implementation plan
   2. The change was implemented within the planned implementation timeframe
   3. The change met anticipated objectives defined in the Change Request
   4. The change did not cause unplanned impact to business units, departments, or end users
   5. The change did not result in a system outage

f. Requesting URL Redirects

A URL redirect automatically forwards a user from one URL to a different URL. There are a few reasons why a redirect might be needed:

• The page or file needs a human-friendly URL for sharing.
• A logical alternative URL is needed for GSD section. 
Example: the URL
  https://www.gsd.harvard.edu/library/
  redirects site visitors to the URL
  https://www.gsd.harvard.edu/frances-loeb-library/
• These requests are evaluated on a case by case basis and are implemented by the GSD’s Web Team. To request a redirect, please fill in the Redirect Request form and a member of the Web Team will get back to you within 2 business days.

4.2 GSD Subsites

A Subsite is a website that bears the school’s name or logo, or that otherwise purports to represent the opinions or work of the GSD but is not directly part of www.gsd.harvard.edu. Subsites must be sponsored (“owned” and “maintained”) by a current GSD faculty member or administrator and be related to a GSD-affiliated research unit (centers, labs, groups, initiatives, offices, etc) program, official student group, or initiative. All new GSD subsites must be approved by the Digital Governance Committee (see below). Subsites must meet the following criteria:

• Group or initiative has been officially sanctioned by the GSD.
• Provide lasting value to the school.
• Satisfy an unmet need.
• Have approval from the Digital Governance Committee.
• Have an ongoing staffing and maintenance plan.
• Demonstrate adequate funding to meet start-up and ongoing maintenance costs (if school funding is not available).
• Register relevant ownership and technical details with GSD Web Staff, enabling the Web Team to make changes in hosting plans or content, as required or needed.

a. Requesting a GSD Subsite

All GSD subsites must be approved by the Digital Governance Committee, regardless of what technology, vendor, or hosting provider is used. To request a new website, Sponsors or Site Owner should fill out a New Site Information Form . The request will be reviewed by members of the Digital Governance Committee. Once a decision is reached, an email will be sent to the person who submitted the form, informing them of whether the subsite has been approved or denied. The review process can take up to 10 business days, and additional information may be requested in order to make a decision. Subsite approval does not imply an approval of costs or vendor, but only that the existence of the site has been authorized.

The GSD’s Finance Office will not accept a contract related to the creation of a new subsite unless the Sponsor or Site Owner can show that the subsite has been approved by the GSD. The GSD’s Finance Office will not reimburse website costs (eg: design, development, domain name, hosting, etc) unless the Sponsor or Site Owner can show that the subsite has been approved by the GSD.

Student groups should contact the Office of Student Affairs to request approval for a new website. Once the Office of Student Affairs has granted approval, the request will be forwarded to the Digital Governance Committee for final approval. Student groups must be officially recognized by the GSD to receive approval for a subsite. Please visit the Student Group Directory for a list of active student groups.

b. Unauthorized Subsites

An Unauthorized Subsite is a website that purports to represent the opinions or work of the GSD or uses the GSD name or branding elements (logo, wordmark, etc), has not been approved by the Digital Governance Committee, and does not meet the requirements for a GSD Subsite set forth above. In the event that the GSD Web Team becomes aware of an unauthorized subsite, they will attempt to contact the site creator(s). If the responsible parties can’t be contacted, the Web Team may take all possible measures to assume control of the site or to have it taken down. If the unauthorized site creators are responsive, they will be advised of the non-conforming elements of the site and asked to provide a remediation plan and schedule to resolve the issues, and may be asked to immediately modify or take the site down in the interim. In this remediation, the Web Team can provide strategic guidance and technical oversight, but all costs associated with bringing the site into conformity will be borne by the site owner.

c. Roles

For communication purposes, people involved in the creation and maintenance of GSD subsites are assigned roles, so the Web Team knows who to contact if an issue with a subsite arises.

• Sponsor: GSD department or office that is responsible for the subsite. Manages budgets and contracts and makes decisions on the site handover or decommissioning if Site Owner leaves the GSD.
• Site Owner: GSD faculty or administrator responsible for the subsite. Responsible for goal setting, strategy & quality assurance; managing funding to support development & maintenance; overseeing continuity through personnel (staff/student/developer/consultant) turnover.
• Site Manager: Is the primary contact for the GSD’s Web Team and oversees the day-to-day management of the subsite and its content.
• Content Editor: Individual with access to the backend of the site and responsible for editing and updating content and other settings.
• Site Developer/Technical Contact: Individual or vendor involved in the build out of the site, including theming and other customizations. Technical contact for errors, upgrades, and other issues.

Every GSD subsite must have a Site Owner and Site Manager on record with the GSD Web Team, in addition to documentation including hosting details and passwords for emergency access.

d. Domain Names

Current GSD faculty and administrators may request a GSD subdomain name (e.g., mysite.gsd.harvard.edu or research.gsd.harvard.edu/mysite) for a subsite related to a GSD-affiliated research center, lab, program, course, or initiative.

A vanity domain name (e.g., “mysite.com” or “mysite.org”) may be used as an alias. Upon request and availability, the GSD Web Team will purchase a vanity domain on your behalf, set up the Domain Name System (DNS), and bill your group or department for the cost of the domain annually.

A GSD subdomain name may not be used for personal sites or portfolios. Individual faculty members wishing to use a harvard.edu domain for personal use should request a site on a platform managed by Harvard Web Publishing .

To request a GSD subdomain name, site owners should fill out the New Site Information Form .

e. Harvard University Subdomains

All Harvard domains are managed by Harvard University Information Technology (HUIT). The GSD requests domain names from HUIT and is subject to HUIT’s workflow and approval processes. Although requests are often processed quickly, please allow at least several business days for domain name changes.

Student groups may not use a GSD subdomain name and must purchase their own domain name (e.g., mystudentgroup.org) through a domain registrar (e.g., aws.amazon.com). Note that student groups must obtain advance permission to use any form of “Harvard” or “GSD” in an internet address. Student Groups should contact the Office of Student Affairs to request permission.

A Harvard subdomain name (e.g., “mysite.harvard.edu”) may be requested for websites sponsored by inter-school groups and programs. Please contact GSD Web Staff for assistance requesting a Harvard domain name.

f. Web Hosting

The Web Team manages web servers for the GSD’s primary website and subsites. Only WordPress-sites are hosted on these servers (installed, updated, maintained, and hosted). The GSD prefers to host all subsites on GSD-managed servers, however, exceptions can be made if approved in advance. Typically, exceptions are approved if there are valid reasons why the subsite cannot be hosted on a GSD-managed server, for example, the website is not built in WordPress, or there are technical reasons why the GSD cannot support the site.

We have partnered with a third-party vendor to provide basic system administration and support for subsites hosted under the GSD’s domain name. Web hosting accounts are managed by the GSD’s Web Team. Any associated costs will be billed directly to the requesting group or department.

External consultants or vendors may be given access to site administration tools after requesting Sponsored Role status from Harvard University Information Technology (HUIT).

g. Non-WordPress Sites

For some special purposes, WordPress may not be a satisfactory medium for web design or hosting. In the rare event that an authorized GSD subsite requires a CMS other than WordPress, it may be permitted only by consent from the Digital Governance Committee. Such consent will be granted only in extraordinary circumstances, where the GSD’s existing technologies do not adequately meet the needs of a project that has been determined to be worth the costs to the School of engaging new technologies to enable it. In such a situation, the site owner must agree to bear all costs of ensuring the new subsite is otherwise continuously compliant with this policy and all costs related to ongoing maintenance of the site. Furthermore, the platform must adhere to Harvard’s digital security requirements , and must be approved by Harvard’s Digital Accessibility Services group as adhering to Harvard’s Digital Accessibility Policy. The GSD Web Team must be given access to the CMS and hosting platform (where applicable) for non-WordPress sites.

h. Security

All GSD websites must comply with Harvard University’s Information Security Policy . Confidential information may require authentication via Harvard Key or other conditions. Please review the following policies:

• Harvard University – Information Security
• Harvard University Information Technology – Security Policy

The use of Google Analytics and similar platforms that utilize cookies or tracking data must be in compliance with the Harvard/HUIT PrivSec Umbrella Privacy Statement and Information Technology Security Policy. The proposed use of these tools must be reviewed in advance by the GSD Chief Information Officer and Chief Information Security Officer, with final approval by the Digital Governance Committee.

i. Accessibility

All GSD websites and applications must comply with Harvard University’s Accessibility Policy . Site owners must incorporate accessibility into their development roadmap whenever applications are scheduled for a minor or major upgrade. Developers and content creators must unit test their code and/or content for accessibility. In addition, accessibility testing should occur as part of the test environment to stage environment deployment process. Any accessibility issues identified must be remediated before the application can move to production.

Vendor contracts for web/application development or hosting must conform to WCAG 2.2, Level AA guidelines and include the Accessibility Rider (OGC Model Documents webpage ).

It is expected that any accessibility issues identified through testing or end user feedback will be fixed within 12 months. For complete requirements, please view:

• Harvard University Information Technology (HUIT) Accessibility Policy
• Harvard Web Publishing Accessibility Guidelines (requires HarvardKey)
• Harvard University Information Technology (HUIT) Disability Services – Online Accessibility
• For requirements related to the development of mobile applications, see Harvard Web Publishing Mobile Technologies Guidelines (Requires Harvard Key)

Digital accessibility must be monitored throughout the life of a subsite. HUIT offers all “Harvard employees working on public-facing websites for Harvard” access to Site Improve, an online accessibility tool that provides reports on WCAG 2.2 compliance. Site owners should request access to Site Improve through HUIT   so they can continue to audit and maintain their site’s compliance.

If the GSD’s Web Team discovers a subsite is not in compliance with Harvard’s accessibility policy, the Site Owner will be notified, and will have 3 months to resolve the issue. If the site’s accessibility is not brought into compliance in that time, or if a good faith effort has not been made, the Web Team will report the site to the HUIT’s Digital Accessibility Services team for further review and action.

j. Design

For high-profile subsites, the GSD reserves the right to require the Site Owner to hire a professional web designer for the project. This will ensure the site meets design, usability, and accessibility standards.

Even when hiring an outside designer, Site Owners may use the free GSD Site Builder platform to build their site. This will be a much cheaper alternative to building the site from scratch.

k. Content

It is the responsibility of the Site Owner to ensure that content is fresh, accurate, and up to date; complies with University guidelines for Information Security and Accessibility ; and follows University guidelines for media capture and usage:

• Photography & Video of Harvard Buildings & Facilities
• Media Relations Policies
• Copyright and Fair Use: A Guide for the Harvard Community

Content editors are expected to ensure that all links are live, tested, and appropriately implemented.

To prevent the dissemination of conflicting information, subsites must not duplicate official school information. Rather, they should link to the authoritative source. Official school information includes but is not limited to:

• Tuition, fees, and scholarship information
• Academic requirements
• Academic calendars and deadlines
• Course descriptions and schedules
• GSD’s mission statement, community values, policies and procedures, etc.

Please consult with the Office of Communications for guidance.

l. Maintenance

It is the responsibility of the Site Owner of any GSD website to ensure that all technical details of web hosting, including credentials for administrative access, are provided to GSD Web Staff, to enable ordinary administrative access for maintenance and otherwise as required.

It is also the responsibility of the Site Owner to ensure the site is in good working order, including performing regular software updates, testing the site after updates, ensuring working backups of the site and its data, and reporting errors to an external vendor or GSD Web Staff. All subsites must comply with University guidelines for Information Security and Accessibility .

If the site has been built or customized by an external vendor, that vendor is responsible for ongoing maintenance. The Site Owner must have an ongoing maintenance contract with this vendor. The Site Owner may find an equally qualified vendor to take on this responsibility. Additionally, the vendor must provide the Web Team with documentation, including a user manual, technical specifications, a description of the software/site/server, and contact details. All maintenance costs associated with ongoing maintenance activities are the responsibility of the Site Owner.

m. Decommissioning and Archiving

GSD Web Staff review all subsites annually. Any site that has not been updated in 12 months will be scheduled for decommissioning. A good faith effort will be made to contact the last known Site Owner. If the Site Owner cannot be reached, the Site Sponsor (department or office) will be contacted for a decision. If the Site Sponsor wants the site to remain online, they must provide a content plan outlining when the site will be updated and who will maintain it. To request decommissioning of a subsite, the Site Owner should contact GSD Web Staff.

In some circumstances, the Digital Governance Committee may decide to decommission a subsite even if the Site Owner wants it to remain online. The reasons why this could occur include:

• The site runs on outdated software that can no longer be supported by the GSD because of security risks.
• Accessibility concerns have not been addressed.
• The site is several years old, and its information no longer offers enough value to justify the resources and cost to support it.
• Analytics show that fewer than an average of 30 visitors per month are coming to the site and therefore it is time for it to be decommissioned.

In these cases, Site Owners and Site Sponsors will be provided with an email from the Digital Governance Committee explaining the decision, three months before the site is decommissioned.

Decommissioned sites are not automatically archived but may be eligible for archiving by Harvard Library. Site administrators wishing to request archiving of a site should contact the GSD’s Collection Management Archivist.

n. Personal Sites – Faculty

Personal websites are not considered GSD subsites and will not be supported by the GSD’s Web Team. Personal websites promote an individual’s accomplishments, research that is unaffiliated with the GSD, and/or personal opinions. These sites cannot purport to represent the GSD or use GSD branding to identify them. Personal websites do not have to be registered with the GSD’s Web Team.

o. Personal Sites – Students

Students interested in creating a personal portfolio site should contact Career Services for information on platforms and best practices. The GSD Web Team cannot support any student portfolio sites and this policy does not cover any personal websites.

5. Student Content

Web content about students is protected by and must comply with FERPA regulations.  All departments, programs, labs, courses, and other groups who wish to publish student names, contact details, or biographies on the GSD’s publicly-available websites, subsites, or social media accounts should reference the GSD’s Student Handbook for guidelines.

All student work that is published must be credited accurately.

Students and Alumni may request to have their information or projects removed from any websites or subsite by contacting the Site Owner, Site Manager, or Site Editors.

6. Social Media

Individual programs or groups wishing to establish a social media presence should contact the Office of Communications for assistance. All social media sites bearing the Harvard or GSD name must comply with guidelines set forth by the Provost’s office, review Harvard Public Affairs & Communications’ Social Media Guidelines , and owners of such social media accounts are encouraged to complete a short training module about those guidelines.

Social media sites must be accessible by the Office of Communications for auditing purposes and will be subject to regular review. Vulnerabilities identified shall be remediated by the channel owner in a timely fashion. It is the responsibility of the channel owner to ensure accounts are in good standing and that all content complies with University guidelines for media capture and usage:

• Photography & Video of Harvard Buildings & Facilities
• Media Relations Policies
• Copyright and Fair Use: A Guide for the Harvard Community
• Social Media Accessibility Best Practices

7. Emergency Action

The Digital Governance Committee (DGC) may at any time require immediate action to change or remove any element of any GSD website, social media posting, or other digital communication. In such a case, if a good-faith effort to contact the Site Owner cannot be accomplished in sufficient time, in the judgment of the DGC, GSD Web Staff and Office of Communications staff are authorized to take all technical and other steps necessary to try to implement the necessary change. GSD Web Staff and the Office of Communications are at all times authorized to take any steps necessary to protect the integrity of the GSD’s web presence or the school’s reputation, without DGC approval.

8. Artificial Intelligence (AI)

All digital communications and content must conform to the University’s AI Guidelines .

9. Contacting the Digital Governance Committee

Community members who need to contact the Digital Governance Committee should fill in the Digital Governance Committee Contact Form . Members of the Committee will review the submitted form and will respond within 3-5 business days. If necessary, the request will be discussed at the next Committee meeting.

Faculty and Staff Headshot Guidelines

GSD faculty and staff are encouraged to provide their photo for web directory purposes but are free to ‘opt-out’ for valid concerns. Please check with your supervisor about departmental policies.  If provided, your Web Profile Photo (‘headshot’) will be displayed next to your name in various places on the GSD website, most notably the Staff Directory and Faculty Directory, as helpful information for colleagues and visitors.

Profile Photo Guidelines

The GSD’s guidelines for Web Profile Photos photos are similar to those for Harvard ID Photos:

• Color photo
• JPG or PNG  format
• ~ 500 x 500 pixels
• File  Size < 500 KB
• Front view, Center full face in the frame, Eyes open and visible
• Light background; Good lighting; No strong glare or deep shadows
• No other people or objects in the photo
• No hats or sunglasses
• No clothing obscuring the face
• Crop from just above head to the collarbone

Your headshot may be rejected if it does not conform to these guidelines. A typical passport photo will suffice. The GSD may occasionally provide a photographer for a brief photo session for these purposes. The Office of Communications will provide more information when these opportunities arise. Your GSD Web Profile Photo is NOT THE SAME as your Harvard ID Photo, and the processes for managing them are different and unrelated. You may choose to use your Harvard ID Photo as your GSD Web Profile Photo, but changing one will have no effect on the other. (For information on your Harvard ID Photo, including a form to request a digital copy you can use for your GSD Web Profile Photo, see Campus Services website .)

Updating your Web Profile Photo

Faculty members should contact the Office of Faculty Affairs to request an update to their profile photo.

Staff members should contact the Web Team to request an update to their profile photo.

Questions?

To change other information about yourself on the GSD’s website, please contact the GSD’s Human Resources. If you have questions or complications related to the functioning of the site, please contact the GSD’s Web Team, and they will direct you to the correct resource.

Web: Frequently Asked Questions (FAQs)

The following FAQs cover questions about the GSD’s website policies and specifics for web editors of the GSD’s flagship site and Site Builder platform. If you have any questions that are not covered in this document, please contact the Web Team.