Skip to content Skip to navigation


Posted by Kellie Alison B... on Monday, November 28, 2016 - 11:22am

University IT will be rolling out a round of updates December 6th through 9th to all websites hosted on Stanford Sites.  Updates start around 10PM Pacific and usually wrap up around 4AM, during which time your site may be unavailable for approximately 1 minute.  If you have questions or experience issues with your Stanford Site, please contact us through University IT's new Services Portal at:

Tuesday, December 6th (10PM through 4AM December 7th): Personal websites hosted on Stanford Sites (at
Wednesday, December 7th (10PM through 4AM December 8th): Group and department sites hosted on Stanford Sites (at
Thursday, December 8th (10PM through 4AM December 9th): Group and department sites hosted on Stanford Sites (at; Also, personal, group, and department development sites (at and
Updates are a valuable part of the Stanford Sites service.  Regular updates ensure that your site remains secure over time and continues to benefit from the latest community contributions.  This round of updates primarily features security updates and bug fixes unlikely to affect the public appearance of your site.  The updates are also not expected to change the experience of using your site as an owner and editor.  The list below includes which modules we’ll be updating and examples of what might change on your site.
Before pushing updates live, we run through over 1,624 different tasks to be sure critical functionality still works.  However, if you encounter any issues following these updates, please contact us through University IT’s new Services Portal at:  We’re happy to help make it better.
The modules we plan to update include:

Security updates

  • Views Data Export - Security update and bug fix related to exporting data in batches. (7.x-3.1)
  • Workbench Moderation - Security update to prevent content in review from being visible in Views, or lists. This only happened when the content status, ie. draft, changed at the exact time a View or list refreshed. (7.x-3.0)

Bug fixes

  • Auto Nodetitle - An empty token field will no longer display the token string, ie. [node:field-name:value].  Instead, it will display an empty string. (Patch)
  • Display Suite - Vertical tabs and field groups can now be placed in custom regions.  Previously, fields could display in custom regions but not their groupings. (Patch) 
  • Drupal - Improvements to error and log messages.  (7.51)
  • Field Permissions - Code cleanup, improvements to error messages, and deleting permissions after deleting field. (7.x-1.0)
  • Flag - Flag Bookmark will now install and enable without an error message about the module being out of place. (7.x-3.9)
  • Menu Attributes - Small redesign of menu link attributes setting. (7.x-1.0)
  • Node Form Columns - Domain Access settings now available in Manage Form tab of Node Form Columns. (7.x-1.1)
  • Rubik - Bug fixes related to padding and admin experience. (7.x-4.4) 
  • Webform - Improvements to help text, especially around improving security with hidden fields. (7.x-4.14)

Feature improvements

  • JW Player - Adds support for cloud-hosted skins, account tokens, and better install instrucutions. (7.x-1.0-beta2)
  • Stanford Landing Page - Gives admins the ability to set a pathauto pattern and improving help text. (7.x-1.4)
  • Stanford Feeds Helper - Gives admins the ability to set import limits and protect against duplicates. (7.x-1.2)
  • New Maintenance Page - During server maintenance, site visitors will now see a Stanford branded maintenance page with information on where to go for updates and help.

New modules

  • Token Tweaks - Gives admins more token options, solves out-of-memory errors, and improves performance. (7.x-1.x-dev)
  • Drafty - Now required by Workbench Moderation.  This module improves handling of drafts and content revisions. (7.x-1.0-beta3)
If you would like to suggest additional modules to be added to the list of modules currently available on Stanford Sites, please contact us through University IT’s new Services Portal at:


Posted in:
Alyssa Hislop portrait Posted by Alyssa Hislop on Thursday, October 20, 2016 - 9:00am

Are you creating a new site on Stanford Sites, but don't want Search Engines to see it? The NoBots module is here to replace Stanford MetaTag NoBots. 

NoBots recently joined the growing list of modules available to Stanford Sites during the Summer 2016 Updates. It replaces the soon-to-be-deprecated Stanford Metatag NoBots module, which was featured as a Module of the Day here on the SWS Blog in 2014.

Why is Stanford MetaTag NoBots being deprecated?

Two great reasons are driving this change: 1) NoBots has a slight performance increase over Stanford MetaTag Nobots 2) NoBots is supported by the Drupal Community. The latter point means, among other things, that the module is covered by the Drupal project's security advisory policy.

How does NoBots work? 

This module blocks (well-behaved) search engine robots from crawling, indexing, or archiving your site by setting a "X-Robots-Tag: noindex,nofollow,noarchive" HTTP header. NoBots is created and maintained by our own Stanford Web Service developers John Bickar and Shea McKinney.

How to enable NoBots on your site

  1. Log into your Stanford Sites website
  2. Go to Modules in the Admin toolbar at the top of your page
  3. Filter by the phrase "nobots"
  4. Select the module No Bots
  5. Click Save configuration

Then continue creating content and developing your website. When you're ready to unleash your site to the robots, go back to Modules and disable No Bots. 

Blocking only one page from robots

NoBots is an all or nothing tool. It cannot block only one page from search engine robots. The best way to block selected content from search engines, once NoBots is disabled, is keeping the content unpublished. 

Not using Stanford Sites? 

You can still use this module! It's available on

Posted in:
Photo of John Bickar Posted by John Bickar on Monday, October 17, 2016 - 9:00am

As part of the Summer 2016 updates to Stanford Sites, we recently added several new modules that bring enhanced features and functionality to all users of the Stanford Sites service. This post is a highlight of the new modules added; detailed posts on several of them will follow.

New Modules Added


NoBots is a lightweight way of hiding your site from (well-behaved) search engine robots. It is a drop-in replacement for the (soon-to-be-deprecated) Stanford MetaTag NoBots module.

Stanford Event Series

Stanford Event Series integrates with the Stanford Events Importer to allow site builders to create collections of events.

Stanford Gallery

Stanford Gallery integrates with the Colorbox Drupal module and Javascript library to allow site builders to create lightweight, accessible image galleries.

Stanford Landing Page

Stanford Landing Page provides a content type that supports dynamic layouts on a single page. With multiple view modes, site builders can choose which layout they want to use on a per-node basis. Included view modes are:

  • List
  • Blocks
  • Cards

Stanford News

Stanford News provides an out-of-the-box solution for displaying news content on your website. This Feature contains a content type, a news page layout, and taxonomy. This module is a great replacement for the default Article content type.

Stanford Publication

Stanford Publication is a set of Features for highlighting publications on your website. Included in this feature is a content type, a set of fields, and a collection of views for displaying and listing the publication content. It is a lighter-weight alternative to the Biblio module.

All Modules on Stanford Sites

A full list of all modules on Stanford Sites is available at

Contributing Back to the Stanford Community

All of the above modules were originally developed as part of the Stanford Sites Jumpstart suite of products, and are now being made available for free to members of the Stanford community. We would like thank all of Stanford Web Services' clients for supporting the development of these enhancements.

Posted in:
Linnea Williams profile pic Posted by Linnea Ann Williams on Friday, October 7, 2016 - 11:45am

One of the challenges we at Stanford Web Services face as both a software development group as well as a client-facing web design team is finding time to create new and innovative tools for campus amidst client projects. Most of the time we are heads down, working with clients to launch scores of websites each year. So how do we approach innovating for campus?

Ever since we opened our doors in 2011, our team has taken one week about once a quarter to turn off our email, cancel meetings and sprint on campus-wide tools. During those weeks, we create new reusable solutions, research future technologies, and fix nagging bugs. These heads down weeks, or "product sprint weeks", have become a source of some of our biggest wins for campus.

Product sprint weeks lead to product improvement and popular features

New fancy tools

In past product sprints, our team created some of the tools that transformed the services and products we offer to campus. Examples include:

  • Our first Jumpstart product: a clean and easy-to-use static website solution designed to support clients with simple web needs much faster. Jumpstart Simple became the core of our Jumpstart product approach to building websites for Stanford.

  • Customize Design: an extension to our products making it possible to create a homepage layout switcher with more design options.

  • Stanford Framework's multiple design options: multiple website color palette and font options that allow clients to make websites suited to them.

  • Landing Page: a special page type with three different layouts making it easy for clients to present complex content more clearly.

Research and documentation

We've also used this time time to investigate and invest in new technologies, or improve documentation. Examples include:

  • Evaluating Drupal 8: researching the state of Drupal 8 and how we might approach adopting it.

  • Creating automated tests: building infrastructure and test scripts with the Behat testing framework to check the functionality of every module on Stanford Sites’ stack during regular security updates.

  • Redesigning the Jumpstart user guide: answering common questions and improving navigation and search options to help clients.

Fixing nagging bugs

We've also used this time to root out the source of nagging bugs or usability issues affecting multiple websites. As Jumpstart grows and supports more sites, these nagging bugs can become big pains if not resolved early. In fact, one sprint was dedicated to pet peeves that we and our partners and clients faced again and again. Bug fixing doesn't always give you the TED talk material that innovation does, but it sure makes everyone's lives better!

Best results happen with the entire team

To create the best solutions, it's important for every voice on the team to be heard and for all our unique skills to come to bear on the solutions we offer to campus. Product sprint weeks allow teammates who otherwise may not interact much on a daily basis to have the opportunity to work together on mini task forces, sharing lessons learned from multiple projects. We also make a point of spending little time at desks or in offices, instead choosing to work in a shared collaborative space so that we are working side-by-side all week long. Sharing a mission and space (and delicious snacks) boosts our team spirit, and the week ends in a fun demo day where we celebrate what was built and settle on next steps.

A one week sprint

When we have time to focus on critical issues and goals without the interruption of meetings, we get more work done more quickly, and a week is required for any substantial development to take place. Also, because we "get in a groove" the focus of the team grows along with momentum each day, so we gain more and more goodness for campus. (That said, our clients are important to us, so we wouldn't want to pause their projects for longer than a week!)

Thank you to our clients and partners!

It’s through your support, ideas, and feedback that we have driven the product improvements made to Jumpstart since its very inception. If you’d like to see something new in Jumpstart, tell us about your idea in the Jumpstart Suggestion Box. And we’ll look forward to sharing what we’ve created after our next sprint at the beginning of November.

Photo of John Bickar Posted by John Bickar on Wednesday, September 7, 2016 - 8:00am

Today's post is a quick tutorial how to use "git grep" and "git tag" to find the earliest tag that contains a particular line of code.

TL;DR: use:

git grep <regexp> $(git rev-list --all)


git tag --contains=<commit hash>

The Longer Version

In this case, I want to find the earliest tag that includes a given update function (stanford_courses_update_7300() in the Stanford Courses Drupal Module).

I'll first search for all commits that include the text "update_7300" (that string is specific enough that it will return only stanford_courses_update_7300):

% git grep update_7300 $(git rev-list --all)

That outputs a list of every commit that contains the text "update_7300" (which is a lot in this case). I can hit my spacebar to scroll through the list; I'm looking for the last commit in the list (i.e., the earliest commit that contains that code):

1cb28cee3c09ecee0208b3d25650a2e4d1a16a63:stanford_courses.install:function stanford_courses_update_7300(&$sandbox) {

I've found my commit hash; now I want to find the earliest tag that includes that commit:

% git tag --contains=1cb28cee3c09ecee0208b3d25650a2e4d1a16a63

From that, the earliest tag that contains the stanford_courses_update_7300() update hook is 7.x-3.1

Posted in:
Posted by Joe Knox on Wednesday, August 24, 2016 - 12:10pm

We’re excited to announce the August 2016 release of our updated mobile-responsive Drupal 7 themes:

  • Open Framework 7.x-2.5

  • Stanford Framework 7.x-3.2*

  • Stanford Wilbur 7.x-3.0*

  • Stanford Jordan 7.x-3.0*

* Stanford-branded themes are available by request for official university group and department websites. To request use of a Stanford-branded theme, visit

How to receive updates

For websites hosted on Stanford Sites: updated themes will be rolled out August 23rd through the 26th, 2016. If your website is on Stanford Sites, and is using an earlier version of one of these themes, the updated theme will be enabled automatically.

For websites hosted elsewhere: themes will be available for download August 23, 2016. To download the latest theme versions, visit


Below are improvements made to the themes since the last release (July 2015).

Open Framework 7.x-2.5

New functionality

  • Added responsive print styles
  • Removed @page dimensions to allow for landscape printing

Bug fixes

  • Updated targeting of views-grid-* classes to be more succinct and endless
  • Matched print viewport to desktop screen viewport
  • New page template for views groupings to address content flow issue: added grouping div and H2

Stanford Framework 7.x-3.2

New functionality

The newest version of Stanford Framework includes several new options for displaying organization signature lockups, a new design option, and new regions:

  • Added site title theme options to accommodate the different organization signature lockups at Stanford
  • Added Vivid design style in theme options
  • Added full-width top and full-width bottom block regions

Bug fixes

  • Fixed incorrect header brand bar padding in mobile view

Stanford Wilbur

New functionality

  • Added full-width top and full-width bottom block regions

Stanford Jordan

New functionality

  • Added full-width top and full-width bottom block regions

Have a question or concern?

Stanford Web Services creates and centrally maintains Stanford’s Drupal themes. If you have any questions, please file a HelpSU request at, and we’ll respond as soon as possible.

We're excited to bring these new theme developments and improvements to the community. We appreciate your support!

Posted in:
Alyssa Hislop portrait Posted by Alyssa Hislop on Thursday, July 28, 2016 - 2:45pm

Today we’re launching our new Jumpstart User Guide! It’s now live at:

We revamped our User Guide, originally built in 2013 on the first version of Jumpstart. Since Jumpstart has experienced tremendous growth over the past three years, we implemented today's Jumpstart features and enhancements into our new User Guide.

So, what’s new?

  • Search capability
  • Simplified, modern homepage design
  • Glossary -- perfect for new Drupal users!
  • ​Top asked questions featured front and center
  • Website lifecycle guides
    • Getting started
    • Launching your site
    • Your site post-launch
  • Built on Jumpstart 4.5
  • Updated Stanford Web Services contact information
  • Cleaner menus for navigation

Questions? Feedback? 

Leave us a note in the comments or contact us through your Jumpstart site. We’d love to hear what you think about our new User Guide!

Not using Jumpstart yet?

Learn more about the products and services here:

Posted in:
Photo of John Bickar Posted by John Bickar on Monday, July 25, 2016 - 11:00am

(Post last updated on: 9/6/16, 10:30AM)

University IT will perform maintenance on all websites on the Stanford Sites Drupal hosting service approximately bi-weekly from July 26th through September 23rd. Details on what is included in each update window are below, and we will update this post as we have more information.

September 13th - 16th

These changes include security-related module upgrades, bug fixes, and new modules for Drupal 7 sites. See below for a complete list of new and updated modules.

Websites are scheduled to receive upgrades on a rolling basis. Please note that when the upgrade begins on a website, any logged-in users will be logged out, and the website will be placed offline temporarily. Visitors will see a message that the website is offline for maintenance. Security patches and database updates will be applied, and the website will be placed back online. We expect each website to be offline for approximately 1 minute during the updates.

If you experience issues with your website hosted on Stanford Sites, please submit a HelpSU request. We will respond as soon as possible. Thanks for using Stanford Sites!

What is included in the September 13th - 16th upgrade

Drupal 7:

  • bean-7.x-1.11
  • context-7.x-3.7
  • ctools-7.x-1.10
  • date-7.x-2.9
  • default_image_ft-7.x-1.6*
  • ds-7.x-2.14
  • entity-7.x-1.7
  • feeds-7.x-2.0-beta2
  • feeds_xpathparser-7.x-1.1
  • nobots-7.x-1.0*
  • services-7.x-3.17
  • uuid-7.x-1.0-beta2
  • stanford_bean_types-7.x-3.0
  • stanford_capx-7.x-2.0-php54
  • stanford_courses-7.x-4.0
  • stanford_event_series-7.x-1.1*
  • stanford_feeds_helper-7.x-1.1 *
  • stanford_gallery-7.x-2.2 *
  • stanford_helper-7.x-1.0 *
  • stanford_landing_page-7.x-1.4+3-dev *
  • stanford_news-7.x-3.3+8-dev *
  • stanford_person-7.x-5.2
  • stanford_publication-7.x-2.2 *
  • stanford_sites_helper-7.x-1.6

* New

The following suggestions for new modules to be added to Stanford Sites are currently under review:

If you would like to suggest additional modules to be added to the list of modules currently available on Stanford Sites, please submit a HelpSU request.


August 23rd - 26th (Completed)

What was included in the August 23rd - 26th upgrade

Drupal 7:

  • Drupal core 7.50
  • admin_views 7.x-1.6
  • better_formats 7.x-1.0-beta2
  • computed_field 7.x-1.1
  • googleanalytics 7.x-2.3
  • libraries 7.x-2.3
  • menu_position 7.x-1.2
  • services 7.x-3.15
  • uuid 7.x-1.0-beta1
  • views_data_export 7.x-3.0-beta9
  • views_field_view 7.x-1.2
  • webform 7.x-4.13
  • workbench_access 7.x-1.4
  • wysiwyg_filter 7.x-1.6-rc3
  • stanford_carousel 7.x-2.3
  • stanford_date_timepicker 7.x-1.3
  • stanford_events_importer 7.x-3.3
  • stanford_image 7.x-3.5
  • stanford_slides 7.x-3.1
  • open_framework 7.x-2.5
  • stanford_framework 7.x-3.2
  • stanford_jordan 7.x-3.0
  • stanford_wilbur 7.x-3.0

More information on theme updates.

July 26th - 29th (Completed)

  • Tuesday, July 26th (10PM to 8PM July 27th): Personal sites on
    (Note: Several unanticipated issues pushed these updates into business hours on July 27th.)

  • Wednesday, July 27th (10PM to 4AM July 28th): Group and department sites on

  • Thursday, July 28th (10PM to 4AM July 29th): Group and department sites on; development sites on and

What was included in the July 26th - July 29th upgrade

Drupal 7:

  • block_titlelink 7.x-1.3
  • node_clone 7.x-1.0-rc2
  • colorbox 7.x-2.10
  • css_injector 7.x-1.x-dev
  • ds 7.x-2.10
  • file_entity 7.x-2.0-beta1
  • filefield_paths 7.x-1.0-beta4
  • flag 7.x-3.6
  • google_analytics 7.x-2.1
  • link 7.x-1.3
  • metatag 7.x-1.6
  • mollom 7.x-2.14
  • pathauto 7.x-1.2
  • views 7.x-3.11
  • workbench_moderation 7.x-1.4
  • stanford_easy_wysiwyg_css 7.x-1.1
  • stanford_image_styles 7.x-3.2
  • stanford_video 7.x-2.1
Posted in:
Posted by Sofie Van Creveld on Monday, June 27, 2016 - 11:00am

University IT will perform maintenance on all websites on the Stanford Sites Drupal hosting service on the following dates:

These changes are significant and include updating Drupal core to the latest release, as well as security-related module upgrades for both Drupal 6 and 7 sites. See below for a complete list of updated modules.

Websites are scheduled to receive upgrades on a rolling basis. Please note that when the upgrade begins on a website, all logged-in users (if any) will be logged out, and the website will be placed offline temporarily. Visitors will see a message that the website is offline for maintenance. Security patches and database updates will be applied, and the website will be placed back online. We expect each website to be offline for approximately 1 minute during the updates.

If you experience issues with your website hosted on Stanford Sites, please submit a HelpSU request. We will respond as soon as possible. Thanks for using Stanford Sites!

What is included in the upgrade

Drupal 7:


  • drupal 7.44
  • block_class 7.x-2.3
  • colorbox 7.x-2.10
  • encrypt 7.x-2.3
  • features 7.x-2.10
  • field_group 7.x 1.5
  • xmlsitemap 7.x-2.3

Drupal 6:

  • drupal 6.38
  • ctools 6.x-1.15
  • filefield 6.x-3.14
  • views_bulk_operations 6.x-1.17
Posted in:
Jamie Posted by Jamie C. Tsui on Thursday, June 23, 2016 - 1:16pm

Three days after Stanford’s commencement on June 12th this year, we quietly launched a completely new website for Stanford’s School of Engineering. From start to finish, the web project took 10 weeks. This project included new design, new feature development, content migration, and feature and browser testing. In the end, the site launched smoothly with no downtime. 

Its success with an aggressive timeline can largely be attributed to two factors: 1) the agility and dedication of a high-performance project team; 2) the conscientious design and technical architecture decisions that Stanford Web Services made previously on the product on which the new site is based: Jumpstart Engineering.

Old School of Engineering Homepage

    Previous School of Engineering homepage

Addressing The Need

The previous Stanford School of Engineering (SoE) website used Drupal 6 as its CMS, which reached end-of-life on February 24th, 2016. With no active development on a replacement website, each passing day the School of Engineering's previous site presented a growing security liability and technical debt. Furthermore, the previous website had an outdated design -- it first launched approximately 6 years ago -- that was not mobile friendly in an era where currently 30% of the website’s traffic comes from mobile devices.
To address the immediate, practical concerns of the website, the project team within Stanford Web Services (SWS) collaborated with School of Engineering stakeholders to develop the “Quick Strike” plan: to leverage a website product previously developed for the School of Engineering and launch a new school website in less than 3 months.

Jumpstarting Engineering

Stanford Web Services has a core product line known as Jumpstart, a Drupal 7-based “website-in-a-box” that is available to Stanford organizations, such as departments, labs, centers, and programs. In Spring 2015, Stanford Web Services formed a partnership with Stanford’s School of Engineering to develop a Jumpstart product that would cater towards SoE “PICAL” groups -- Programs, Institutes, Centers, Affiliates, and Labs -- to address a growing need in the SoE community for a scalable, secure, mobile responsive, and Stanford Engineering-branded web platform. 
After a pilot with 5 trial groups in Fall 2015, Jumpstart Engineering (JSE) was released to the SoE community in February 2016 and is available for free to any SoE organization.

Leveraging JSE

JSE was designed and developed with PICALs in mind, with features and a site architecture structured around people, courses, publications, research, and resources -- content that is very different than what would be the focus on a school’s website: news, events, admissions, alumni relations, and more. 
To meet the aggressive timeline of Quick Strike, we knew that we could and should leverage the existing framework that JSE already provides: data models, features, mobile responsive homepage and page layouts, branding and styles, authoring roles, security (through upgrading to Drupal 7) and more. After an evaluation of the gaps, we estimated that JSE would fulfill over 80% of the needs for a minimum viable product (MVP) for a school site. 

School of Engineering Homepage

    New School of Engineering homepage

The Plan

To fill the remaining 20% gap between what JSE offered and what the stakeholders envisioned for a new, launchable school website, the project team defined areas of improvement that offered the highest return on investment, segmented into “Minimum Viable Product” (MVP), defined as a site launchable with 0-days notice:
  • New custom website theme that focused on color and typography changes
  • New masthead design on top of an existing JSE homepage layout
  • Integration with the Community Academic Profiles (CAP) system for automatic people information management for 275 faculty profiles on the website
  • Streamlined and simplified site architecture, and culled over 230 outdated pages
  • Separation of intranet onto its own site, simplifying permissions, maintenance, and navigation
  • Migration of all core school site content: homepage, news stories, faculty profiles, admissions information

and “Minimum Lovable Product” (MLP) reach goals:

  • New design and features for news, which affected over 900 news stories
  • Implemented an improved search solution, Apache Solr
  • Migration of secondary school site content: faculty awards, student programs, and other tertiary pages

The Execution

The Quick Strike process embodied the essence of agile and scrum. In addition to the standard sprint framework of scrum (with sprint kickoffs, reviews, and backlog grooming), the team also embraced the tenet of self-organizing sub-teams to quickly tackle tickets and smash blockers. As project manager and scrummaster, it was my responsibility to communicate clearly and closely with the project team to understand and remove all impediments, including reprioritizing their other commitments and removing them from any meetings they weren’t necessary to attend, and to also maximize their focus/productive time.

Screenshot of Stanford Engineering News page

    New news listing page

Because we operate on a 2-week sprint cycle, there were only 5 sprints available for the project from kickoff to launch and therefore intra-sprint meetings within the team were essential to move and communicate quickly. In addition to daily team morning scrums, we also added an end-of-day scrum on our “focus days”/”no meeting days” (Wednesdays). Furthermore, we had dedicated working meetings on Mondays and Tuesdays to facilitate communication and quick resolution of questions or issues that arose mid-sprint. 
At the end of each sprint, I evaluated our progress and coordinated with the product owner to adjust priorities as necessary. And once we were 1.5 sprints (3 weeks) away from launch, the requirements for bringing into a ticket into a sprint became more stringent: each ticket had to pass validation: “Is this a blocker to launch?” or it would not make it into the sprint.

The Launch

Prior to launch, we conducted cross browser and mobile testing, accessibility testing, and quality checked the content several times. Our developer handling the launch coordinated with the various other IT infrastructure and administration groups around campus to ensure that the necessary people were on standby during the launch in case any mishaps occurred, and that a contingency plan was in place for each point of failure. 
During the launch, there was an issue with securing and transferring the virtual host (vhost) for the site, and we followed our contingency plan successfully with no downtime. After the vhost issue was resolved, our developer quickly re-coordinated the teams to reattempt the launch.
Three hours after the originally scheduled launch time, we smoothly launched the new School of Engineering website to the world.

Screenshot of redesigned news story page

    Redesigned news story page

What’s Next?

Since launch, we’ve had over 16,000 visitors with 42,000 pageviews and to our pleasant surprise, have not received any notice of complaints and issues. Anecdotally, the reception of the new site by the SoE community has been positive. 
Our mobile device visitor ratio has increased by 15% since launch (from just under 30% to now over 34%), which reflects positively on our improved mobile experience. 
We plan to continue to monitor the traffic and stability of the site, and will compare the analytics pre-launch vs post-launch to look for trends. Having accomplished everything we had planned to address with Quick Strike MVP and MLP (security, stability, mobile-responsive design, improved search, improved faculty profiles), the stakeholders and development team can dream big from scratch for Phase Two work on the school site, and also rest assured that Drupal 6 end-of-life risks have been mitigated in the meantime. 
Quick Strike was the quintessential result of agile, scrum, lean startup, and MVP practices, and was also one of our team’s most ambitious and aggressively timed project to date. There were many firsts accomplished with the project that came as a result of not just “failing fast,” but also “recovering fast,” and the success of Quick Strike reinforced the benefit of our team’s early investment in developing a scalable product and platform. 
Look forward to our next big projects leveraged from Jumpstart!


Subscribe to Stanford Web Services Blog