Statement of Work: STScI JWST Website
Redesign
Version 2: April 2, 2015
Statement of Work: STScI JWST Website Redesign ......................................................1
1.
2.
3.
4.
5.
6.
7.
8.
Overview .............................................................................................................................................................1
Interface with STScI ........................................................................................................................................1
Initial work & deliverables ..........................................................................................................................2
3.1. Draft/Preliminary Deliverables & Current Labor Tally ................................................................ 2
Alternate Website Formats: Integrated Public/Scientist Sites .....................................................3
4.1. All content (public & technical) integrated into a single site in a single CMS/CMA........ 3
4.2. All content integrated into site that appears to be a single site to the user, but is
hosted on different servers/CMSs ......................................................................................................................... 4
4.3. All content integrated into a “single” site, but that has two modes: Public & Scientist . 4
4.4. Landing page is launchpad to other related sites............................................................................ 4
Next Steps ...........................................................................................................................................................5
Schedule and Final Deliverables................................................................................................................6
Development Process.....................................................................................................................................6
Appendices ..........................................................................................................................................................7
8.1. Frameworks ....................................................................................................................................................... 7
8.2. Production .......................................................................................................................................................... 8
8.3. The Basics of our Base CMA .....................................................................................................................10
8.4. About the ICE Team .....................................................................................................................................11
1. Overview
In this document, we describe the web development framework, process and
infrastructure for a proposed architecture design and front-end redesign of selected
parts of the STScI/JWST website (stsci.edu/jwst).
2. Interface with STScI
A critical component of the development is the formation of a small team at STScI
empowered to make design, format and content decisions in an agile/iterative
manner; for convenience we will call this the ST-Hub team. We anticipate that the
work on the website will be highly collaborative been the IPAC Communications and
Education (ICE) web team and ST-Hub, and will require frequent communications
and check-ins in an agile/iterative development model.
The development process is described in more detail in section 7.
Interactions between the ICE group and ST staff are currently managed by Janice
Lee (STScI/SMO).
3. Initial work & deliverables
In order to fully scope the proposed work, we had an initial one-week, face-to-face
meeting, March 9-13, 2015, between ICE and ST-Hub, at STScI. During this time, the
ICE team collaborated with the ST-Hub team to:






Define the intended audience for the website
Review desired/potential users for the website (both internal and external).
Identify top-level navigation requirements.
Identify key information to be exposed on the homepage.
Identify and develop key-design elements: use of logo, imagery, color
schemes, with inputs from the STScI OPO design team. We understand there
is a desire to have a consistent look-and-feel among the website, outreach
materials, etc. We are collaborating directly with Lacey Bordeaux and John
Godfrey (STScI/OPO) to create the website design, and implement style
choices which are consistent with the newly developing STScI Branding
Guide.
Begin to create an inventory of content to be migrated to the new site.
During this phase, ICE and ST-Hub also discussed how to maintain consistency
among the top level Institute webpage (stsci.edu), the JWST homepage
(stsci.edu/jwst) and the Hubble astronomers website (stsci.edu/hst).
The various meetings and discussions that took place during the on-site visit are
summarized at:
https://confluence.stsci.edu/display/websiteredesign/IPAC+Web+Design+Team+M
aterials
and
https://confluence.stsci.edu/display/websiteredesign/IPAC+Web+Design+Team+O
n-Site+Work+Schedule
Assumption: After this in-person meeting, our initial understanding was that the
scope of the work was to design and develop and architecture for a website
primarily targeting astronomers, but with a landing page that would be appropriate
for all audiences (i.e., it would direct the public to separate websites dedicated to
public outreach). Our initial efforts have been directed by this assumption. However,
if an alternative model for the website is desired (e.g., a more fully integrated
public/scientist website) we will need to replan and revise some of our initial work.
See section 4 for more detail.
3.1.
Draft/Preliminary Deliverables & Current Labor Tally
As part of our development process, along with creating an architecture and design,
we find it useful to implement at each stage the proposed elements on the existing
ICE CMA. This will allow the ST-Hub team to not only review design and
architecture proposals, but also exercise a functioning website; this informs to the
usability of the site.
In the April 3, 2015 ICE delivery package (see
https://confluence.stsci.edu/display/websiteredesign/Delivered+Materials+and+R
eviews) , STScI will receive draft designs for the following pages, implemented on
our Ruby-on-Rails based CMA:
 homepage draft design,
 generic page design
 news landing and news item page draft designs
The url for the Ruby-on-Rails live prototype will be provided during the meeting,
and posted on the confluence space. Corresponding development materials
including html code and css style sheets will be provided in a zip file. We also
provide alternate draft designs for the homepage, and an idea for the “Observer
Workflow” page in Photoshop/jpg format.
To date, 264 hours of labor have been performed on the project by ICE: by lead
developer Jacob Lllamas (130 hours), ICE Visualization Scientist Robert Hurt (104
hours) and ICE lead Gordon Squires (30 hours).
4. Alternate Website Formats: Integrated Public/Scientist Sites
We understand that STScI has been exploring an alternative model for the scope of
work for this project, namely a closer integration of public and scientist websites for
JWST. We have done some preliminary thinking about this model and have three
possible scenarios we wish to explore with STScI.
4.1.
All content (public & technical) integrated into a single site in
a single CMS/CMA
With this approach we would build a single site living at
http://www.stsci.edu/jwst/ that would encompass public and educational content
as well as all the technical science support.
All the pages would therefore utilize essentially the same overall design template
and maintain consistent top-level menu navigation structure.
Generally it is confusing for pages within a single site to use different top-level
domains (that makes them functionally like different websites) or to have radically
different page styles and menu options (users lose track of where they are in a site
and how to navigate to other areas). As such, URLs for different sections would take
the form of something like:
stsci.edu/jwst/public & stsci.edu/jwst/education
not
public.jwst.stsci.edu & education.jwst.stsci.edu
or
someotherpublicsiteurl.org & someothereducationurl.org
This would entail pulling all content over to match the new site design.
4.2.
All content integrated into site that appears to be a single site
to the user, but is hosted on different servers/CMSs
This is a variant on 4.1 -- allow the content to remain split across different servers,
but replicate all the CSS and menu navigation exactly and keep it synchronized if
updates are made. Maintenance is more difficult in this scenario.
4.3.
All content integrated into a “single” site, but that has two
modes: Public & Scientist
This is also similar to 4.1/4.2, but the difference is that there would be a nav
element (like a tab on the upper right) that toggles the site between the public and
scientist modes. (An example is sketched photoshop and included as a jpg in the
delivery materials.
This distinction is a compromise in which both sites use matching styling,
navigation elements. Each site may share some basic menus (e.g., About, News,
Images).
This compromise allows the top-level menu navigation to be audience-specific avoiding the confusion of a long, multipurpose nav bar of 4.1 but still giving quick
access to the other site. It also allows the look and feel to be uniform across the
whole site, but better customized to each audience when they are in their respective
sub-sites.
4.4.
Landing page is launchpad to other related sites
In this mode, the landing page layout would be designed to clearly advertise content
for different types of engagement as links to external sites. There could even be a
"for public" page on the main site (in the menu structure) that duplicates and
expands on this functionality. These shortcuts are links to take the user outside of
STScI.edu to other sites with their own design and navigations structure.
The bulk of content natively hosted on stsci.edu/jwst would thus be the core
information for scientists. Public interests are not specifically reflected in the top
menu structure (top menu nav should only take you to other pages within the site; it
is confusing when some menu links lead to an external site with completely
different menu navigation). They only appear as "above the fold" links on the key
landing pages.
This design makes it easier to accommodate the current system with several
different sites that already exist without having to dismantle them and rebuild them
under the new stsci.edu framework.
The home page and menu design is of necessity significantly different between 4.1
and its variants and this option, making this a significant issue that would be helpful
to resolve before further extensive work is performed.
The advantage of 4.1, 4.2, 4.3 is that you consistent look and identity for all core
JWST materials.
The advantage of 4.2 is that it allows each site to be designed to best benefit its
target audience, and given that multiple sites already exist for JWST, it can be
implemented almost immediately. It still maintains stsci.edu/jwst as the main
landing page and allows public content to be accessed as quickly as if it were on the
same server through the shortcut links offered on the home page. On the down side
it means that users may just bookmark other sites if all they want is the public info,
and it means that things like image galleries and new may need to be maintained on
more than one site, or built in such a way that the assets from one site can be
exported automatically to other client sites.
5. Next Steps
In telecons on April 3, 2015, ST-Hub will review the deliverables in Section 3, be
briefed in using the back-end interface to modify content, identify next steps for
content/designs & revisions, and work on a timeline for next steps.
If STScI requires more time to decide on the scope of the project, as described in
section 4, ICE can still continue work on design for lower level pages. At the time
the level of integration desired between public and science sites is determined, we
can provide a more detailed estimate of time required.
We recommend telecons every 3 weeks with the STScI management oversight
group, with informal check-ins on more focused topics with other staff in between.
Although the full scope of the project has not yet been determined, we still believe it
is very reasonable to complete the full design and architecture by the end of June
2015.
Throughout the project, ICE offers to work collaboratively with the Institute IT
department and Jahia developer(s) to transfer knowledge and information needed
for their efforts to develop a back-end using Jahia, and help to communicate
decisions made/lessons-learned, etc. during the initial work phase between ICE and
ST-Hub to streamline their Jahia implementation.
6. Schedule and Final Deliverables
As final deliverables, ICE will provide layered Photoshop files for the design of all
pages in the JWST domain, suitable for coding by the Jahia development team
designated by STScI. ICE will also provide a detailed site map and wireframes for
stsci.edu/jwst. Further, all preliminary drawings, designs, plans and documents will
be maintained and shared with the Institute. The Ruby on Rails prototype
implementation will also be available to the Institute, on a server hosted by IPAC.
Further, if agreed by the Institute and ICE within the scope of this work, ICE will
deliver layered Photoshop files of designs for select top-level pages for other (nonJWST) site sections as well.
ICE will remain available throughout the implementation phase, and can revise
designs or the site map if needed in this phase if implementation issues are
identified. ICE will provide, at minimum, 40 hours of additional support to the
Institute and the Jahia development team in the implementation phase, and will
remain available on an as-needed basis once the site is deployed. Additional hours
for support may be negotiated at this stage, if desired or required.
7. Development Process
Web development happens in 4 phases: Wireframing, Design, Implementation and
Content Deployment.
Because we've have developed a base content management application (CMA) for a
number of other astronomy websites (see section 8.4), we can deploy a production
server early in the development process and start Content Deployment to the base
resources (e.g., Pages, Image Gallery and Video Gallery and other simple treestructure pages). Once we establish the top-level navigation, users at STScI will be
able to easily create and populate lower level pages in an intuitive fashion and, most
importantly exercise the architecture and design choices made.
Wireframing
At this point we sit down with ST-Hub and define the elements for the various toplevel pages; these may include: Homepage, News, informational tree structure pages
(e.g., Observatory, Instrumentation, etc.), Images and Videos. By drawing on paper,
we white box the layout iterating with the ST-Hub until there is approval of how the
resources are laid out. We often then turn the paper and pencil sketches into Google
Drawings, where we can define the boxes, label and categorize them.
Design
Once the wireframes are done we can start designing in Photoshop a layout for the
top-level pages (or pages described by wireframes). This is where we'll decide color
and font treatments. Often the initial design on these pages will inform the rest of
the layouts, 2nd level pages, listings and paragraphs etc. Again we iterate on the
design internally and with ST-Hub until all parties are satisfied.
Implementation
This is the point where development and production start to overlap. We copy any
content deployed to production down to our development server. We start to deploy
the layouts using the content from production as to get an accurate example of what
it will look like when its done. Once a few of the layouts are working in
development, we review internally and with ST-Hub to make sure everything is still
on target. Once changes are approved we can deploy them to the production server.
This process repeats until all the layouts from the design phase are deployed.
Once all the defined layouts are deployed, we circle back and fill in any 2nd level
page layouts as needed. We also deploy any new layouts that were missed or later
decided that they were needed.
Deploying to an active/production server adds very little overhead to the process,
as the existing ICE CMA will suffice for testing purposes. The benefits of this include:
the opportunity for ST-Hub to actually exercise the website navigation and custom
components, to insure they work as required; inform back-end page design so that
the Jahia implementation can include template input pages that meet the needs of
the Institute content providers.
Content Deployment
Most of the RoR websites we've developed have had extensive content like Spitzer
and Cool Cosmos. If at all possible we start content development and deployment as
early as possible. We have a major advantage here since we already have a starting
place, our base CMA to build on.
8. Appendices
8.1.
Frameworks
Although this does not apply to the STScI websites since the implementation will be
in Jahia, we include this background for information and completeness.
There are 2 different paths for Ruby web development used at the Infrared
Processing and Analysis Center (IPAC).
The first path is using the Middleman framework, which is good for small sites that
need minimal content updates.
The second path uses the full Ruby on Rails (RoR) framework, which works well for
large sites with lots of features and content updates.
Middleman

Pros
o
o
o
o

Cons
o
Simple development environment, requires Ruby but not much else.
Generates static HTML, CSS and Javascript.
Runs on typical server installation, no Ruby or any other server
modules required.
No database server required and is rarely ever used.
Content updates are handled in the development environment,
requires a little more knowledge of HAML and Middleman framework.
Full Ruby on Rails

Pros
o
o
o

Cons
o
o
o
8.2.
Content updates handled through content management web page.
Complex features like slide shows and comparison galleries are
updated through simple web forms.
Advanced features like user authentication, resource publishing,
resource auditing and many others are available to a RoR application.
Complex development, depending on what features the website
requires. For example, Astropix (astropix.ipac.caltech.edu) has a
complex development environment compared to the Spitzer Site
(spitzer.caltech.edu).
Complex server environment, requires more modules to be installed
for the web server.
Database server is not required, but almost always used.
Production
The following describes the production server environment. We provide this simply
as information to STScI, understanding that the Jahia implementation may/will
require a different environment.
The RoR production environment can be as complex as development, again
depending on what the web site does. A typical Middleman production environment
could be as simple as just an Apache install. A complex RoR application can run on
several Apache instances, connect to many db instances and under all that could be
a high-availability file system from another server. Here we'll outline a simple
Middleman environment, a basic RoR environment and a complex RoR
environment.
Middleman Production Environment

Single *nix based server, could be a virtual machine


Basic web server install, like Apache or Unicorn.
Static HTML, CSS and Javascript deployed to the document root.
Basic RoR Production Environment






Single *nix based server, could be a virtual machine
Basic web server install, like Apache or Unicorn.
RoR specific modules i.e. Passenger
Basic DB server install, like Postgresql or MySQL.
Ruby gems deployed to server, could be several, managed through RoR
framework and bundler.
Code updates often trigger other server actions:
o Migrating Database
o Updating Asset Files (compressing CSS and Javascript elements)
o Running any other application specific rake tasks
o Restarting the application
Complex RoR Production Environment







Many *nix based servers, could be a virtual machine, often each of the major
functions are on a separate machine
Load Balancer
Several Web Servers
o Ruby gems deployed on each server, could be several, managed
through RoR framework and bundler.
2 or more Database Servers with implementation of High Availability
2 or more File Servers with implementation of High Availability
Application specific processing servers. Astropix has a server dedicated to
downloading and ingesting images from remote sites.
Code updates often trigger other server actions:
o Migrating Database
o Updating Asset Files (compressing CSS and Javascript elements)
o Running any other application specific rake tasks
o Restarting any application specific processors.
o Restarting the application
As we noted above in the “Pros/Cons” for RoR development, Astropix
(astropix.ipac.caltech.edu) has a complicated development environment as
compared to Spitzer site (spitzer.caltech.edu). Spitzer’s site's production
environment looks more like the complex environment outline. This is because the
amount of traffic Spitzer generates. It started on a single VM and later migrated to a
multi-server high-availability environment. Finding the right balance of hardware vs
visitors to a site is an essential task. Too much hardware wastes money vs
underpowered hardware can give the visitor a poor experience.
8.3.
The Basics of our Base CMA
Our custom built base Content Management Application (CMA) starts with
resources that almost every website will inevitably need. For public websites, these
include: Pages, News, AVM Images and Videos. We also have a catch-all resource
called Media Files. We've also built out several behaviors that are very common
amongst content management systems. Built in behaviors include Pendable,
Visibility and Sluggable.
Behaviors



Pendable: Resources that can have a pending status. Pendable resources have
the ability to save and preview changes before publishing them to the front
end.
Visibility: Resources that can hide from the front end. Quickly remove from
the front end but not delete the resource on the backend.
Sluggable: Resources that have meaningful URLs. Resources in a RoR
application are often linked to by a resource ID number. We can change it to
easy to remember text slug, e.g., page/5 changes to page/contact
Resources

Pages
o
o
o

News
The news resource usually drives several serial style resources, like
information updates, articles, announcements, blogs, etc.
o By using categories we can define several front-end resources from
one admin resource.
o News resources are pendable, sluggable and have visibility.
AVM Images
o AVM is a special metadata standard developed specifically for
astronomy images. You can find more information about AVM and the
VAMP project here: http://www.virtualastronomy.org/
o Our CMA is the only one that starts with AVM support out of the box.
o Most sites feature an Image gallery, these galleries are built from the
AVM Images resource.
o AVM Images are sluggable and have visibility
Videos
o Videos resource handles video in one of two ways. Either a link to an
external video service like Youtube/Vimeo (prefered) or you can
manage and upload three HTML5 video files. Managing your own
o


Pages are the main resource of any website. Generally contain the
majority of the content.
Pages generally define the navigation structure.
Pages are pendable and sluggable.
video services are outside of this app. To support html5 video across
the most devices and formats is a significant undertaking all by itself.
o Videos are sluggable and have visibility
 Media Files
o Media Files resource is the catch all, or for everything else.
o Pages that need many images embedded in them will use Media Files.
o Sometimes you need to offer downloads of zip, tar, doc or pdf files.
These files will also be managed through Media Files.
o After a file is uploaded into the Media Files resource, you can link
them into other resources like Pages or News.
Media files do need any behaviors since they are never accessed directly from the
url and always linked into other resources.
8.4.
About the ICE Team
The IPAC Communications and Education (ICE) team is a Workforce, Education,
Public Outreach and Communications (WEPOC) service supporting a number of
astronomy and science projects with WEPOC management, planning, activities, and
support. Depending upon the need of a particular project, ICE can provide full
WEPOC support, or select activities as required.
As such ICE is a unique team and service in astronomy WEPOC support; to our
knowledge so other service exists anywhere in the U.S. with the broad capabilities
that ICE has to support a number of projects, including:










NASA’s Spitzer Space Telescope: full WEPOC support
ESA’s Herschel Space Observatory: full WEPOC support for U.S. community
Thirty Meter Telescope (TMT): full WEPOC support for the TMT
international collaboration (Caltech, UC, China, India, Japan and Canada)
NASA’s Nuclear Spectroscopic Telescope Array (NuSTAR) mission: public
communications support; website development and maintenance
Palomar Transit Factory: website development and maintenance
Laser Interferometer Gravitational Wave Observatory (LIGO): website
development and maintenance
IRSA and Exoplanet Archives: homepage designs
NASA’s Kepler telescope: multimedia/graphics support
ESA’s Planck mission: U.S. Planck Data Center website development and
maintenance; multimedia/graphics support
NASA’s Wide-field Infrared Survey Explorer (WISE): multimedia/graphics
support
As well, ICE has developed several central on-line web services that cross-cut NASA
missions and projects including:



Coolcosmos: NASA’s long-wavelength astronomy education and public
outreach website
Astropix: NASA’s repository of astrophysics public release images
STEMDeX: NASA’s searchable database of summaries of peer-reviewed
education papers
The following websites use the base CMA developed by ICE. These sites are almost
entirely maintained, updated and developed by users at the home institution, often
by personnel with limited web development experience. This is a key feature of our
CMA; it provides and easy to use, intuitive back-end, allowing for easy content
updates and creation of new tree-based page structures.
8.4.1. Palomar Transient Factory (ptf.caltech.edu)
Custom features include:
 Homepage appropriate for general public and astronomers
 2 (fiscally) independent websites integrated to a common architecture: iPTF
and ZTF are funded separately and, for various reasons, need to be thought of
as distinct projects, even though they are based at the same telescope
 Dynamic, automated updates to publication lists
 Dynamic, automated sky-coverage plots
8.4.2. IRSA and Exoplanet Archives (irsa.ipac.caltech.edu /
exoplanetarchive.ipac.caltech.edu)
The IRSA and Exoplanet Archives homepages were redesigned and deployed to
integrate with websites having a long heritage, most content created dynamically,
involving high-level software interfaces with the archive software and databases.
Key features
 Finding a solution to expose a significant amount of content in a navigation
structure that is visually intuitive, and in a simple, clean design
 Expose key archive interface tools to the user in a clean, simple to use format
8.4.3. CoolCosmos (coolcosmos.ipac.caltech.edu)
Fully responsive tablet/handheld implementation