Skip to content Skip to navigation


Posted by Kerri Augenstein on Wednesday, August 5, 2020 - 12:41pm

Navigation is one of the most important functions of your website. Meant to organize your content into discernible sections, good navigation afords users intuitive pathways to discover or find content. Without good navigation, the effort you spend creating meaningful and compelling content is diminished if a user cannot find it.

Achieving good navigation is two sided. There is the work of a content team, deciding what the navigation actually is, what the pages are called, and how to organize them—your sitemap. The other side of that content and architecture strategy is how the system actually functions technically. What are the interactions? How are they displayed? How does a user understand where they are on your site? How does the navigation work on desktop, and collapse down to mobile? 

Stanford Web Services and University Communications have worked over the last several years (and will continue to) in persistent iteration on our navigation model. Our goal has been to refine multiple implementations into a single, robust, and fully tested model that would be available in our Decanter Framework, and Wordpress and Drupal platforms. 

That single model is now available. Designed and engineered based on secondary research findings from industry leaders, our own independent research, and conforms to the AA accessibility standards as defined by WCAG 2.1

Where we started: secondary research

Our first step is always to look across the research from our industry leaders. What can we learn from the existing domain of knowledge in navigation design and engineering? What conventions have users become accustomed to on the internet that we want to take advantage of with our solution? What trends may we want to avoid that prove not to be user friendly? 

(Disclaimer: the age of the following research may degrade the findings over time.

We find a great wealth of information from the prodigious work of the Nielson Norman Group. We looked at a many number of articles they’ve written on the topic of navigation, a number of them highlighted at the bottom of this article.

Based on that secondary research, here are some of the specific items we implemented: 

  • Display a link to “home” in your main navigation

  • Display navigation when the screen size affords the space—as Nielson Norman states—“if you can show it, show it”. Specifically on desktop, we deliberately display primary navigation in our header, which is visible on every page. A left sidebar of links is also visible on any page with sub pages. 

  • Include the word “menu” with the hamburger icon, to increase user understanding and recognition, that this is where to find navigation on mobile

  • Indicate with some visual differentiation, where the user is on the site

Where we went next: our own research

Accordion or split-button mobile navigation menus?

There was also research that left us with pause. Specifically, how to engineer the interactions of our responsive and hover-menu navigation. For a time, we actively designed and developed two different mobile interactions for our navigation, accordion and split-button, because we found it too difficult to decide without tests. The Nielson Norman Group had suggested we employ an accordion style, instead of split buttons, but in our own navigation model—used on various platforms, namely Drupal 7—we had used the accordion model, but were unhappy with it.

What is the Accordion model? 

Animated gif displaying the interaction a sighted user will experience when clicking on an accordion-style drop-down menu.

The accordion model presents users with a type of interaction that would expand menus on-click, on both the text link and at the downward facing icon. The only way to see menus below, would be to click the text or icon and expand the menu. This implies that a user cannot click on the text itself to go to the top level landing page, they first have to open the menu, then click on the text with some additional word like “Overview” or “Explore xyz”. In this example, we’re forced to create a second menu item called “Explore Admissions & Academics” in order to afford the user the link to go directly to that landing page.

What is the split-button model?

Animated gif displaying the interaction a sighted user will experience when clicking on an split-button-style drop-down menu.

The split button model allows a user to click on the text of a link at the landing page level to go directly to the page (no “Overview” or “Explore xyz” link needed), or click to expand the menu with the downward-facing arrow.

The goals for our users

  1. With either model the business objective was the same. The business wants users to hit those top level pages as the content presented on these pages is enormously relevant to the end user, providing them the contextual keys to their find or browse tasks. 
  2. Confirm through usability testing that a user knows where and what to click or tap, and their expectations match the outcome of those interactions. 
  3. The interactions are easy and user-centered.

Accordion navigation model

This approach to navigation forces a duplicate page to be made for a top level of navigation, because when a user clicks the text-link of a page, that click opens a menu, it does not take the user to that page. 

This is problematic for any pages with pages below itself. Those pages will need a duplicate page with some additional term to help a user understand that they must make a second click to visit that page. As you could imagine, we had concerns about this, both from design and engineering perspectives. We didn’t want to make weird duplicate pages called, “Admissions & Academics Overview” or “Explore Admissions & Academics” when the text link itself should be the endpoint of task completion.

Split button model

A split-button model presents the user with a text-link, that when selected will take that user directly to that page. But it also provides a second interaction with a down-facing-arrow, to expand the navigation items below. 

p dir="ltr">Based on the Nielson Norman study, there are inherent issues with a split-button model. 

Although users will probably be able to achieve their goal whether they use the menu or the category landing page, they will be unpleasantly surprised when the site won’t behave as expected. When it comes to touch gestures, users are rarely precise or consistent: sometimes they will tap the arrow and sometimes tap the label, looking for the same result. If the interface does different things after two instances of (seemingly) the same user action, it will seem buggy and erratic.

But we couldn’t ignore that through this model, a user would be able to drive directly to the link text without an additional click or through a weird secondary page that is needed in the accordion model.

So we needed our own research

Though we were presented with secondary research from industry leaders, internally, we just did not agree with their findings. We had hypotheses of our own, and details in our questions that were not covered in industry research.

What we found

We spent a series of five research studies on our navigation to date. The first two studies were deliberately divergent including a mix of questions directed at both visual design and usability. They gave us a place to start, but are not as relevant to this article. Round three focused in its attention to usability for accordion versus split-button, but it revealed test-flaws—not uncommon—so we moved into round four. 

Round four revealed an interesting outcome to our question, “in which model are users more likely to select top-level landing pages”, a primary business goal”. Outcomes are described below. 

Round five—which focused on the usability of mobile navigation functionality—found both accordion and split-button interactions to be sound.

The unexpected outcome of research study 4

Format: our study was specifically shaped for desktop interactions. That is, the user interacted with our navigation on screens over 1024px wide where the header was fully present and subnavigation was displayed in the left sidebar of interior pages. No user used “tap” to interact with the test sites. Users were presented with hover-menus at the top level navigation in the header, that revealed navigation below it where it existed.

Screen shot displaying a Stanford Site, at the top of the page, with the user's cursor hovering over a main navigation item to display the drop down menu that appears.

Primary goal: do users visit landing pages more often through split button or accordion? 

Secondary goal: is the usability of the desktop navigation sound and intuitive?


  1. Users did not make it to top level pages more using either model, failure rates were comparable.

  2. Usability of navigation on desktop is sound. Users understood where navigation was displayed, how to find it, and how to interact with it. 

Unexpected hypotheses

  1. Due to the presence of hover-menus for each of the top level navigation links in both tests, users rarely hit landing pages at all. 

  2. Additionally, displaying these hover-menus puts a lot of pressure on the navigation structure—the sitemap/information architecture—to be really, really well designed and tested (lots of testing). That really, really good navigation, for all the levels that are visible (including that hover menu) would have to include the terms that users have in their own heads to get to the content they are looking for. For that really, really good navigation to be framed in that user-centric way, the team creating that navigation would have to be mind readers (for lots of different kinds of people) or, would have run their navigation through lots and lots of user tests to confirm that the terms they selected were the right ones. And even still, that leaves the potential for users to misunderstand a term under a certain section—as is true for all humans—without enough context, make assumptions, and go down the wrong path. And this is why we think that the removal of these hover-menus, forcing users to go directly to the top level page, where the context of the subpages below it is clearly present on the page itself providing significant contextual information to help them understand what content is in fact nested in that section. Theoretically increasing the likelihood that a user will find the content they are looking for. Users will always go down unintended paths. The removal of a hover menu isn’t going to make task completion for a user perfect. But it may remove some of those wrong paths, increasing the usability of the site.

Research outcomes at work

Based on our research outcomes our default, out of the box Drupal 8 platform includes: 

  • Split-button navigation model where users can go directly to the text-link of a page through navigation terms and expand/collapse pages below where the UI presents expand/collapse icon-buttons

  • By default (though it will continue to be available on the platform by-request) the platform does not include hover-menus on the desktop primary navigation items in the header. Instead users go directly to top-level pages. 

With two research outcomes that were unexpected, many others confirmed, and many tests needing to be tested themselves, the effort put into creating a sound user-friendly and accessible navigation model has proven invaluable. As navigation is one of the single most important functions of any website, we knew it deserved an immense amount of attention.

What’s next?

Like any other element of a digital product, we will continue to monitor the usability of our navigation model and continue to test it against web conventions, trends, best practices, and secondary research. 

Below, you can learn more through the secondary research we used in our own work. 

Secondary research of note

Our user experience and user interface practice actively seek secondary research from industry leaders to inform our positions and recommendations on work. Often, pre-existing studies inform us to the extent that conducting our own research would be superfluous and a poor use of resources. Where research is limited, not conducted, or where we may disagree with industry findings is where we may choose to conduct our own independent research. 

We wanted to share some of the research from industry leaders that we have used to learn about user behavior with respect to navigation, information architecture, finding information, responsive design, and more. 

Where am I?

Summary: On a website, “navigation” doesn’t mean just links. Navigation is, like most elements of a website, about communicating with the user. Good navigation tells a story, and good stories have a beginning, middle, and end.

(Disclaimer: this article is still relevant, having been written during the prehistoric era of the web, 2006)

Information Foraging: A Theory of How People Navigate on the Web

Summary: To decide whether to visit a page, people take into account how much relevant information they are likely to find on that page relative to the effort involved in extracting that info.

Homepage Links Remain a Necessity

Summary: A site logo linking to the homepage is not enough. Logo design and placement, as well as the presence of a text link to the homepage affect success of navigation to homepage.

Flat vs. Deep Website Hierarchies 

Summary: Information can be organized in either flat or deep hierarchies; both have their advantages and pitfalls.

Killing Off the Global Navigation: One Trend to Avoid

Summary: For desktop sites, demoting your main content categories into a drop-down menu makes it harder for users to discover your offerings.

How Many Items in a Navigation Menu?

Summary: A key question in information architecture (IA) is to decide the number of items in navigation menus (including global menus and local menus). 4 main factors determine the answer, but it's not 7, despite a common myth.

Navigation: You Are Here

Summary: You-are-here navigation consists of signs that help orient website visitors as they explore the site. Many websites need stronger location indicators.

Menu Design: Checklist of 15 UX Guidelines to Help Users

Summary: In both applications and websites, users rely on menus to find content and use features. Use this checklist to make sure your menus do their job.

Footers are Underrated

Summary: There's a footer at the bottom of every web page, but the design of this utilitarian page element is often overlooked, making the website perform below its potential. In our usability studies, users often turn to page footers for important information and tasks, making them an integral part of the overall experience of a site.

The 3-Click Rule for Navigation Is False

Summary: While it is important to keep key information easily accessible, the 3-click rule is an arbitrary rule of thumb that is not backed by data.

A Brief Overview On Responsive Navigation Patterns

Summary: Looking specifically at responsive navigation. We will first talk about information architecture, then the purpose of navigation, and finally we will look at three responsive navigation patterns that have served well over time.

Designing Drop-Down Menus: Examples and Best Practices

Summary: As a general rule, most Web developers, especially usability enthusiasts, say it is bad practice to use drop-down menus because they are confusing, annoying and oftentimes dysfunctional. From a design standpoint, however, drop-down menus are an excellent feature because they help clean up a busy layout. If structured correctly, drop-down menus can be a great navigation tool, while still being a usable and attractive design feature.


Posted in:
Posted by Rebecca Hong on Tuesday, December 3, 2019 - 10:30am

I am sure some of you have noticed that there is a Stanford Light sample image of Jane Smith's personal website and were wondering how to recreate the same page for yourself. 

In this blog post, I'll show you how you can put together an About page layout similar to the Jane Smith's personal website preview image seen on the Appearance page.

Before we get started, I do reocmmend checking out the following blog posts to familiarize yourself with some of the things that we will be using:

How to set your front page (*This is important if you would like to make this page your homepage!)

Stanford BEAN Types Module

Using Context to Add Blocks to a Region

Open Framwork Regions

Font Awesome Icons

Stanford Light Theme

Creating a Basic Page

This will be the About page that the sidebar blocks will sit on. 

1. Navigate to Content > Add Content > Basic Page.

2. Fill in the Title and Body text fields. 

3. Save!

Enabling the Stanford BEAN Types Module

1. Navigate to Modules from the admin toolbar.

2. Search for Stanford BEAN Types and turn the switch from OFF to ON.

3. Save configuration!

Creating the Profile Photo Block

1. Navigate to Content > Add Block > stanford_large_block

2. Add the label — I named mine Profile image.

3. Upload your profile image in the Image Insert section.

4. From the style dropdown, select large-square.

5. Insert the Image into the Body

6. Save!

Creating the Contact Information Block

1. Navigate to Content > Add Block > stanford_large_block

2. Add the label — I named mine Contact information.

3. Now at this point you can just input your contact information and Save.

However, if you are interested in incorporating Font Awesome icons and aren't afraid of a bit of HTML, continue onward!

Incorporating Font Awesome 4.7.0

4. We'll want to check and see which version of Font Awesome your theme is currently using. In order to do so, we'll want to navigate to Appearance > Settings > Stanford Light.

5. Locate the Packages accordion and expand it.

6. Make sure Font Awesome 4.7.0 is selected.

7. Save

8. Navigate back to the Contact information block that you had created.

9. Assuming that you had input your Contact information previously in step 3, you will want to change the Text format (located under the Body editor) from Context Editor Text Format to Full HTML from the dropdown. 

10. Now your Body should be displaying HTML! You can now select your Icons from Font Awesome 4.7.0 site. Once you've found the one you want to add, copy the HTML from the Font Awesome site and paste the HTML into the area where you would like the icon to appear.

You can get a preview of how it looks by switching back and forth Full HTML to Context Editor Text Format.

Alternatively, you can copy and paste the following HTML to get you started:

<p><i class="fa fa-building-o" aria-hidden="true">&nbsp;</i>&nbsp; &nbsp; <a href="[destination url]">[Your Team]</a><br />
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;[Location]<br />
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;[Address]<br />
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;[City and Zip]<br />
<i class="icon-envelope">&nbsp;</i>&nbsp; &nbsp;<a href="mailto:[your email]">[your email]</a></p>
You'll want to replace the text wrapped with square brackets accordingly with your own information. 
11. Before you save, make sure the Body Text format is set to Full HTML otherwise the Icons won't show up!

Creating a Context and placing the Blocks

1. Navigate to Structure > Context > Add from the admin toolbar:

2. On the new context page, input the necessary information:

3. On the same page, in the Conditions section, select Path from the dropdown (see image A) and input the path of the Basic Page you had previously created (see image B):



*You can find the node path of the page by editting the page and looking at the URL:

4. Next is the Reactions section. Select Blocks from the dropdown:

5. This is where reviewing the Open Framwork Regions come in handy. You'll want to select the Blocks you created earlier from the BEAN accordian located on the right handside. 

6. Navigate to the Second Sidebar Section (located towards the end, under Content: Bottom) and click +Add to add the Blocks to the section.

7. Save your changes.

The Final Results!

Now when you navigate to your About page, you should now be able to see the Blocks stacked ontop of one another on the right.

Posted in:
Anna Watt Posted by Anna Watt on Monday, November 26, 2018 - 4:40pm

Let’s say you want to make a cake but you don’t have a lot of time to make one from scratch. You already have a box of cake mix ready to go but this box is for chocolate cake with vanilla buttercream frosting. But you really wanted one with dark-chocolate ganache frosting —because you can never have too much chocolate.

gif of chocolate cake with buttercream frosting switching to chocolate ganache frosting

You’re not going to throw out the entire box of cake mix just because it doesn’t have the frosting you want, are you? You don’t have to reinvent the wheel and make a chocolate cake from scratch. You can still use the box of cake mix to save time preparing the cake and instead focus on making the perfect frosting you want. The end result is the same chocolate cake but with your own unique dark chocolate ganache frosting on top.

This experience is similar to the benefits of our open source software development approach for building websites at scale on a shared platform. We are able to share functionality and features for different units while also accommodating their unique needs or flavors. 
Last summer, the School of Humanities and Sciences (H&S) Web Team sponsored the design and development of an edge-to-edge image or video feature with other fun display options such as a curtain-reveal or scroll button. One example of this feature with the curtain reveal option is currently live (at the time of writing this blog post) on the Center for East Asian Studies website to showcase their 50 year anniversary.
We’ve also used this feature for the Woods Institute for the Environment website to feature videos on the research focal area landing pages.
So when the School of Engineering (SOE) communications team came to Stanford Web Services and asked for the ability to feature content on their homepage with a large image or video, we scratched our heads and thought...this is the same chocolate cake we’ve made before but they just want different frosting!
screenshot of soe homepage
We forked the existing code for the feature we made for H&S—which essentially means we took a copy of the code (like starting with our box of cake mix) and added new code to it—that allowed us to add new functionality and design on top of the existing code (our dark-chocolate ganache frosting) all with the specific needs of the School of Engineering website in mind.
We released the first version (or minimum viable product) of the new feature on SOE’s site within four weeks of forking the existing code from the H&S project. This would have taken far longer without the boxed cake mix (reusing an existing feature and adding customizations.)
Sharing features allows us to save time and money for our clients. This means we can focus on building more advanced features and improving our existing features for the platform benefiting even more people in the long run.


Alyssa Hislop portrait Posted by Alyssa Hislop on Thursday, August 16, 2018 - 5:28pm

You've put time into creating your Stanford Sites website, so you'll probably want Google (and other search engines) to know about it. One of the ways to get this done is by submitting your website sitemap. This blog post will walk you through how to claim ownership of your Stanford Sites website, then submit the website to Google for indexing. 

This process works best if you have two tabs or windows open. One for working with Google, the other for working on your website.

Part 1: Get your verification code from Google

Step 1: Go to Google Webmasters tools and click Search Console

Step 2: Click Add A Property

Step 3: Enter your URL

Step 4: Select the Alternate Methods tab (see below image)

Step 5: Click HTML tag

Step 6: Highlight and copy the ID inside content=" " (see below). In this example it's I0sOm_SqSBOzB_xEisS2NDkn7hCI0gSLERTRfTiK7LI. 


Part 2: Apply your verification code to your Stanford Sites website

Step 1: Log into your Stanford Sites website

Step 2: Enable the Site Verification module (more info on this Module)

Step 3: Go to Configuration > Search  > Verifications (or: admin/config/search/verifications in your URL)

Step 4: Click Add Verification

Step 5: Select Google from the dropdown menu, then Next

Step 6: Paste the verification code from Part 1 into the Verification META tag field

Part 3: Verify your site

Step 1: Return to Google Webmaster tools where you first copied the verification code

Step 2: Click Verify

Part 4: Submit your sitemap

The Search Console allows you to see which pages of your site have been indexed. You can also request that your site be indexed. Check out the Sitemaps report to learn more.

Did it work?

Good question! Hopefully? Check out the Index Status report to find out. 

How many people are visiting your website? Which pages are the most popular? 

Check out our blog posts on Google Analytics to find these answers:

Get more help on Google Search Console

Request a Stanford Sites website

Posted in:
Alyssa Hislop portrait Posted by Alyssa Hislop on Wednesday, August 8, 2018 - 12:02pm

Starting July 12, new group and department websites requested on Stanford Sites will live in the cloud. These websites have new modules available to them. What are they and what do they do?


New modules

For new group and department websites created on or after July 12, 2018:

  • bigmenu: Allows direct access to submenu sections of a big menu, so links within a section can be managed without loading the whole global menu.

  • always_visible: Administrators can use this to override the visibility of menu items.

  • chosen: Makes <select> elements more user-friendly. This is a jQuery plugin.

  • contextual_view_modes: Set view modes based off a context.

  • multiple_selects: Set up multiple select fields with an ‘Add another item button’.

  • switch: Add an iphone-like switch form element & widget.

  • video_embed_field and submodules: Embed videos and show a thumbnail preview using this new field.

  • view_unpublished: Allow specific user roles to view unpublished nodes of a specific type.

  • views_select_sort: Change the “weight” of each select list option and sort within the view.

View all included Drupal modules for group and department websites

New module highlights

There is one module in particular that brings some pretty neat functionality to the Stanford Sites platform:

view_unpublished: Use this when you have unpublished content that other people with editing powers need to review.

Why is this a big deal? The unpublished node's default allows only the author of that page to view in its unpublished state. By using view_unpublished, we can override that default.

For example: I have administrator privileges on my website and I write a blog post. My intern has a smaller set of privileges and is assigned a different role. I need her to proofread and add images. Enabling the view_unpublished module and adding that permission to her role will allow her to view the unpublished item.

Removed modules

  • stanford_metatag_nobots: We retired this service in Fall 2016. Read more about this change on our blog.

  • mollom: Mollom was used to help prevent spam submissions on forms, but it's come to its end of life. We recommend using Honeypot now for your spam prevention needs.

Learn more about the move to the cloud

Posted in:
Alyssa Hislop portrait Posted by Alyssa Hislop on Friday, August 3, 2018 - 11:23am

The inaugural 2018 Stanford Global Energy Forum website stands out as a Stanford Sites superstar. The forum is coming up in November 2018 and will gather thought leaders and decision makers from the private sector, government, academia, non-profits and media to engage in strategic and balanced dialogue about the Future of Energy.

I think this is a such an eye-catching website. It features rich imagery, colorful accents, and a modern design to spread the excitement and inform potential attendees.


Check out the subtle transition as you hover over the host’s pictures on the homepage.

This is achieved through styling on the host photos using the CSS injector:

.honorary-hosts-photo img { border-radius: 50%; transition-duration: .9s; transition-property: transform; }

.honorary-hosts-photo img:hover { transform: scale(.95); -webkit-transform: scale(.95); }


Learn more about CSS injector on our blog and the transform property on W3Schools.

To make the whole website shine they’re leveraging the Stanford Framework theme, CSS injector, block views of custom content types, and so much more.  This website is a great example of how to use Stanford Sites for events, like forums and conferences. Well done!!


Visit the Stanford Global Energy Forum website

Learn more about Stanford Sites

Posted in:
Cynthia Mijares Posted by Cynthia Mijares on Wednesday, May 2, 2018 - 1:14pm

Are you excited about the web and looking to learn more about how web products and projects unfold? Join the friendly and collaborative Stanford Web Services team! 

Stanford Web Services (SWS) is an on-campus web design and development team offering:

  • web design, development, and production services;
  • oversight of university web branding, including themes and style guidelines; and
  • project consultation and guidance

Learn more at

SWS is looking for a self-directed and detailed-oriented student interested in web design and development to assist with multiple ongoing projects. Potential tasks may include: user research and usability testing, migrating web content and basic website building and styling, conducting quality assurance on new site development, content strategy for external communications, automated testing, and writing/reviewing documentation.

What you’ll gain

  • HTML, CSS and Drupal theming and/or Drupal development and testing skills
  • Behat automated testing skills
  • Using Git in a collaborative web development environment
  • Best practices for communicating with clients
  • Experience working in a web development shop
  • Agile (scrum) project management basics

$18/hour full-time for 8 weeks over the summer quarter. 

What you are now

  • A clear and concise writer
  • Comfortable learning new technologies quickly
  • Organized and good at time management
  • Good in a self-directed environment
  • Happy on a collaborative, detail and goal-oriented team
  • A little bit crazy about the web

Also, it would be great if you had any of the following, but it's not critical (we can teach you!):

  • Familiar with web technologies (Drupal, HTML, CSS)
  • Skills in Photoshop, Illustrator, Balsamiq, etc.
  • Familiar with the basics of user testing

To apply

Email Alyssa Hislop (, Customer Experience Specialist at Stanford Web Services

Please include a résumé (and a link to your portfolio or LinkedIn profile, if applicable), details about any relevant experience, and a bit about why you want to work with Stanford Web Services. Bonus points if you are active on Github or and include a link to your profile!

Application deadline: May 18, 2018

Posted in:
Sara Worrell-Berg Posted by Sara Worrell Berg on Thursday, April 5, 2018 - 3:41pm

Stanford Drupal Camp 2018 is already upon us!

The ninth annual Stanford Drupal Camp will be hosted at the  Stanford Law School on April 6-7, 2018.

Our Stanford Drupal Camp emphasizes introductory sessions for beginners, as well as use cases of Drupal in higher education. Those new to Drupal will be particularly interested in the events on Friday, whereas experienced Drupallers (yes, we spell it with two "L"s at Stanford) may be more interested in Saturday's program. Learn more about the sessions and log in to start your schedule planning.

As always, it’s free and open to the public.

If you have any questions, please contact

Hope to see you there!

Posted in:
Sara Worrell-Berg Posted by Sara Worrell Berg on Thursday, December 21, 2017 - 4:04pm

As 2017 draws to a close, the Stanford Web Services team is closing sprints, cleaning our desks (mostly), emptying inboxes, submitting our final timesheets, and hoping no one reports a bug in the next 24 hours. Goodbye 2017, hello winter break! 

It was a big year, and we have so much for which to be grateful. We said hello and welcome to our new teammates Andy, Dena, and Bhavika, and we celebrated the birth of new babies and puppies. (So. Many. Babies.) We said farewell and best wishes to our teammates Grace, Claus, Kevin, and Jamie as they moved on to new adventures.

In 2017, we hosted a successful Stanford DrupalCamp and launched dozens of new websites, including Stanford Earth and Stanford School of Engineering, with the help of their talented communications and web teams. We kept millions of lines of code secure and accessible, and we kicked off Drupal 8 development and a move to the cloud. We even got our own website refreshed, thanks to our awesome communications friends in University IT. Best of all was the experience of working with our many talented and friendly colleagues from all over Stanford.

In short, we're as busy as ever and fortunate to be a part of this world-class university, and we look forward to all of the exciting changes coming up in 2018. 

Happy holidays to you all and best wishes for a healthy and happy new year!

Sara, Linnea, John, Shea, David, Anna, Greg, Dena, Kerri, Alyssa, Kellie, Andy, Caryl, Mike, Cynthia, Joe, Bhavika, and (St.) Nick

Group photo of Stanford Web Services staff members with Happy Holidays in white text on red background

Posted in:
Grace Kiburi profile photo Posted by Grace Kiburi on Friday, November 17, 2017 - 11:23am

Stanford Drupal Camp is a two-day annual event that connects people in the South Bay who work with websites. The Camp started in 2009 to discuss the many facets of web design and development, as well as learn about Drupal, an open source content management system. The camp places an emphasis on introductory sessions for beginners, as well as use cases of Drupal in higher education. Beginners sessions take place on Fridays, while Saturday's sessions are designed for more experienced Drupal users.

What happened at this year’s camp?


This year’s Drupal Camp took place on March 10th and11th at Stanford University’s Law School. The sessions kicked off with a keynote about how technology is impacting legal practice and the law more broadly, with practical examples on how technology is automating monotonous law processes and how this is just the beginning of legal tech boom. The keynote speaker was Dr. Roland Vogl, the Executive Director at Stanford School of Law and Executive of CodeX, The Stanford Center for Legal Informatics. He also shared how some of the tech startups like LegalZoom and Clear Access are disrupting the law profession.

Keynote speaker Dr. Roland Vogl talking about how tech is disrupting the law profession.

To make it easier for attendants to select which sessions to participate in, the sessions were split into 6 main categories dubbed tracks:

  • Site building

  • UX/ Design

  • Dev/ DevOps

  • Content Strategy

  • Research / Academia

  • Project Management / Business

Day one sessions were mostly attended by Stanford University site builders and content editors. The sessions focused on content strategy, user experience, and site building through the hands-on use of Drupal tools.

Shea talks about CAP and how to integrate it with Drupal Site.

Learn how to use CAPx to get your Stanford profiles looking nice and pretty on your site @sherakama #SUDrupalCamp

— SU Web Services (@SUWebServices) March 10, 2017

Zach Chandler and Pui Shiau present How To Make a Snowflake with a Cookie Cutter: Innovative Site Building on Stanford Sites.

Joe Knox and Alex Wilson presenting Stanford Page 3.0

Day two sessions were tailored for intermediate to advanced Drupal developers and site builders and the main track was Dev/ DevOps. The sessions were mostly attended by the off-campus community. The developers shared their latest developments and how they have managed to solve various Drupal challenges.

Another huge thanks to the @FFWglobal crew for their part in making this year's #SUDrupalCamp a big success.

— SU Web Services (@SUWebServices) March 11, 2017

The lunch that brought the attendees together:

Hey #SUDrupalCamp join us for lunch in the Student Lounge at 12pm!

— SU Web Services (@SUWebServices) March 11, 2017

Who can attend?

  • Stanford staff/faculty/students who need to learn Drupal or are working with a Drupal site

  • Stanford Drupallers community (developers, themers, site builders, site admins)

  • The larger Drupal-interested community

  • Those working in the web (or wanting to): project managers, designers, content writers

Shout out to our Sponsors

Stanford Drupal Camp is made possible by our sponsors. We would like to thank this year’s sponsors:

  • Stanford Web Services

  • FFW Agency

  • Stanford University Open Source Lab

  • Pantheon

Thank you, Stanford Law School for providing the space to host 2017 Drupal Camp and for all the folks who showed up and made it a success. See you next year! 

Posted in:


Subscribe to Stanford Web Services Blog