Skip to content Skip to navigation

Megan Erin Miller's Blog Posts

Megan Erin Miller Posted by Megan Erin Miller on Tuesday, October 6, 2015 - 8:00am

Over the past three years, I have been the sole designer with Stanford Web Services. I like to think that I’ve levelled up the rest of the team to embody user experience best practices and approaches to everything we do, though the reality is that I’ve had to wear many hats: user experience designer, content strategist, visual designer, themer… As our team has grown, this role I’ve played has grown as well, and it’s given me a perspective on how different facets of design fit best for different types of projects. In this post, I want to share some thoughts, best practices, and insights.

“Design” vs. Theming

One of my major lessons over the years is that discovery and design work is significantly different than theming work (duh?). When you are doing both (as I have been), you get to cheat a little, in that assumptions made during the design phase can pass on and be solved in the theming phase more smoothly. There are many moments in theming when you make small but important design decisions that add up to creating a holistic design. Being the “owner” of the visual design can bring a lot of benefits when you are also implementing that design, if you have the skills to do it well. You can wait until the theming phase to solve more holistic visual design system challenges – seeing how different components interface together, and how if you change a margin in one place, you might also want to adjust it elsewhere to match. It means you don’t have to make as many comps because you can just interpret the few you have made and apply to new interfaces. In some ways, you carry the design in your head and paint it on as you go. This has worked well for me as sole designer/themer.

That said, I strongly believe that designers should not have to write production-ready front-end development code. There are many times over the past few years where I’ve wished to have a themer partner to pass designs to and collaborate with. Instead I’ve just had themer-me to lean on. This is heavy for context switching. So I do think it’s best for teams to think about discovery/design as different than theming, and acknowledge that this might not be best assigned to a single catch-all “designer” unicorn. (Talking about unicorns will have to wait for another post...)

The Design Process

For client work, major redesigns, and projects with a clear delivery date and hand-off, I strongly believe that a true discovery and design process is best approached in a waterfall way. You can chunk it up however you’d like and call it sprints, but I believe there is a natural order of operations when defining and designing.

In the diagram below, I outline how I have approached major redesign projects coming through SWS:

Waterfall Redesign with Agile Development Diagram

Figure 1: Waterfall Redesign with Agile Development (click to view larger)


In the first three phases of the process, you go through a waterfall approach to discovery, content architecture, and user experience. During this process, you want a tight feedback loop with the development team, to make sure what you are designing makes sense and is buildable.

After this first phase, there is a critical moment where you have your wireframes, content model, functionality specs defined, and you can create a functional backlog of development work. What’s important to note here is that a wireframe is an unprioritized backlog. Part of the nature of design deliverables is that it is hard for them to be agile by nature. If a block on a page is prioritized down in the backlog during the design process, but it was a prominent block on the structure of the page, the designer has to be available later in the agile process to address changes in layout based on prioritization of features.  This is why it is important to pay due diligence in the discovery/design/define phase to make sure that at least the wireframe(s) captures the vision for the project completely, even if there might still be some hard choices ahead. It’s hard to make prioritization choices with half-baked requirements.

After client approval and prioritization of the backlog, you can dive into developing specific functionality and features, and you can start the visual design phase. In our process, you may note that the visual design phase overlaps with the start of development, since for the most part all you need to get started with development is a spec (and that’s what a wireframe and annotation are good for). Visual design then runs in a waterfall way with client revisions and approval on top of (or in parallel with) the agile development process.

After sign off on the visual design, you can start theming. Theming trails development, and can be managed in an agile way – as things get built, they get ready to be styled. And to what extent you can in advance, you can write up styles for components and core elements.

At the end, after development has finished, there is a design review phase, where you polish all the corners, discover bugs and minor changes, and tie a bow on it.

Integrating waterfall design into agile development

I think the key to integrating a waterfall design process into an agile development shop is collaborating with a rockstar project manager to anticipate and plan in advance the time, space, and resources to allow for the discovery/design process to play out, so that we know we are building the right thing and solving the right problems. In a way, this has more to do with managing the backlog than it has to do with the specific order of tasks.

Agile in its best form allows teams to prioritize work, understand it’s size and value, and make smart decisions about what to do next. The tricky part is that discovery and design defines the size of the work, and is often an unknown variable in the process as you build requirements with a client.

Design in Agile Feature Development

Although I feel strongly that there is a natural order of operations for discovery and design in order to come up with clear requirements for a project, there is absolutely a place for design to live in agile feature development, where you have ongoing, iterative, continuous improvement product work.

In the diagram below, I try to capture how a typical feature design and development process looks:

Agile Feature Design and Development

Figure 2: Agile Feature Design and Development (click to view larger)


In some ways, this is the miniature version of the first diagram. I still believe there is discovery/design work that needs to happen before development starts, but I believe this has to be done in a tight loop with the developers to ensure viability.

The more iterative and agile way to work on feature development is to create tight feedback loops between designer and developer throughout the entire process. In the first half, the loop insures that the designer is creating something that is buildable and makes sense. In the development phase, the developer should be leaning on the designer for QA and feedback on what has been developed. At the end, as the feature is being styled, there is often some back and forth between themer and developer to make sure that what was created is most efficient for theming, and vice versa.

Because there are basically three phases to this process (design, development, theming), you can imagine that each phase might fall into a sprint, and in this way you can have overlapping sprint cycles, where one sprint the designer is working on defining the feature that will be built in the future sprint. (see figure 3 below)

Agile Sprint Cycles Diagram

Figure 3: Agile Feature Design and Development Sprint Cycles (click to view larger)


While this process helps you fit feature design and development into agile sprints, I am still not sure if this isn’t just a mini waterfall process, dropped into an agile schedule. What this does do well is give teams a tighter feedback loop by chunking the work into manageable pieces and engaging the team in collaborating.

When it doesn’t work

When we have tried to apply this more iterative cycle to complex client work, we have faced some challenges. When you break discovery and design of individual components down and out of the context of the bigger picture, it is harder for stakeholders to communicate requirements and see how the work fits with the rest of the project.

Another situation where this process becomes challenging is when the feature or component that it’s focused on is too big or too undefined. In this scenario you have to step back, and spend more time doing careful research and discovery, getting input from the right stakeholders to make sure you are coming up with the right solution. In this scenario, it is very possible that design and discovery may take much longer than a typical iterative sprint cycle, and it’s hard when you are basically saying, “Hey developers, not sure when we’re going to know what you’re building.” The solution to this is more advanced planning, more lead time, and setting clear expectations around new feature requests, and clear guidelines for decision making on what is in-scope vs. out of scope for whatever version you are planning for.

In conclusion…

Evolving your process is… a process. At SWS we’ve focused on having an open dialogue about our process in an ongoing way. Having debriefs and retrospectives helps us grow our process over time, try new things, and reflect on what didn’t go so well. As you can see, “Design” is a big bucket, and encapsulates a lot. How does your team approach integrating design into an agile process (or not)?

I would love to hear your perspective! Please share your thoughts in the comments below and let’s have a conversation.

Accessible Long Descriptions for Diagrams

Figure 1: Waterfall Redesign with Agile Development

From left to right: The first section shows a discovery phase, which includes requirements, research (data and qualitative), personas, and conversation with developer on “What are our development constraints and strategy?” In this phase you are figuring out “What is this?” and it requires a client sign off that might have some back and forth.

The second section shows a content architecture phase, which includes content model (e.g. taxonomy), information architecture, testing IA, and conversations with developer on “Does this make sense for development?” This phase requires a client sign off that might have some back and forth.

The third section shows a user experience phase, which includes UX flow, wireframes (or interactive prototype), usability testing, and conversations with developer on “Is the design buildable?” This phase requires a client sign off that might have some back and forth.

In the second and third phases you are figuring out “How is it structured and how does it work?”

After the third phase you now have enough information to build a development backlog which kicks of an agile development process.

Parallel to development, you have a visual design phase (phase four), which includes style tiles, high-fidelity comps (and accessibility testing), and style guide. This phase requires a client sign off that often will have several iterations and much back and forth.

After sign off on visual design, you can start theming the site. Theming can be done in an agile way, trailing on development. As a feature is developed, you can start to theme it. This process includes QA (is what was build correct, and ready for styling?), styling, testing, and merging the code back into the feature.

There is a point at which enough has been developed that the client can start entering content. This often results as a back and forth around development and design.

The final phase is a design review/QA phase, which includes design QA, “polish” of final styles, testing (responsive, cross-browser, accessibility), and in this phase you often work back and forth with a developer until launch.

Figure 2: Agile Feature Design and Development

From left to right: The first phase is discovery, which includes requirements and research (data and qualitative), and conversation with developer on “What are our development constraints and strategy?”

The second phase is design, which includes UX flow, wireframes (or interactive prototype), usability testing, high-fidelity comps, development specs, and conversations with developer on “Is the design buildable?”

Then development happens.

The last phase is theming, which includes QA (is what was build correct, and ready for styling?), styling, and testing (responsive, cross-browser, accessibility), and merging the code back into the feature.

Figure 3: Agile Feature Design and Development Sprint Cycles

This diagram shows three example features and the way that the work on these features lays out over five sprint cycles. In sprint one, you may be doing design and discovery for feature one. In sprint two, you may start development on feature one, and start design and discovery on feature two. In sprint three you may continue development on feature one, start development on feature two, and start design and discovery on feature three. In sprint four, you may start theming on feature one, theming on feature two, and development on feature three. In sprint five, you may finish feature one, continue theming feature two, and finish theming on feature three. This shows can you might plan for discovery/design to take place the sprint before development, and how these might play out.


Megan Erin Miller Posted by Megan Erin Miller on Thursday, April 23, 2015 - 9:00am

As designers, in order to come up with innovative solutions, we must embrace a “yes, and” mindset. But to really get the job done, our most important weapon is the ability to say “no.” To be successful, we have to constantly find a balance between a mindset of “yes” and a mindset of “no.”

This balance is at the core of finding and implementing creative solutions to meet business needs, yet it is a challenging balance to sustain, and not a skill that is taught (directly) in design school. This is one of those soft skills you learn by doing, on the job, with real requirements.

Open, explore, narrow, close

This balance is inherent in common design thinking practices. It is the essence of good ideation to open, explore, narrow, and close.

Open Explore Close diagram from Gamestorming
From the Gamestorming playbook

This framework for ideation and decision making is one way to handle the yes/no balancing act, by providing a process for switching contexts through the phases of open, explore, narrow, and close.

We can use this technique to guide clients through the design process, giving them a healthy way to participate more actively in the project and feel ownership over the results.

Internalizing the critic

But to be honest, it’s hard. Constantly on our feet, switching gears. Demanding from ourselves creative solutions and fresh concepts, while at the same time cutting features and design elements to simplify. Saying no to our own work constantly.

It is a labor of love and a state of constant compromise. But if done right, this narrowing in on the true goals of a project and putting the rest in the icebox will result in a better product.

We are not alone

In short, we designers occupy an interesting space where our responsibilities are to envision the unimagined, explore infinite possibilities, and make the critical decisions to narrow in on the right solution.

We are not alone in shouldering this balancing act – our project managers are our greatest partners in understanding and guiding the decisions that we have to make at every stage of the project. Working together, we can develop a practice for client engagement that cultivates a healthy balance between “yes” and “no.”

Cultivating Yes and No

This takes practice. Practice critiquing your own work. Practice receiving feedback. Practice facilitating workshops with clients. And the more experience you have handling complex requirements, the better you will get at this balancing act. Be open to influence and also confident in your decisions, and you will grow as a designer.

What tricks do you have to switch gears between a yes and no mindset?

How do you facilitate getting good feedback in your design process?

How do you productively engage your clients in ideation?

Megan Erin Miller Posted by Megan Erin Miller on Wednesday, April 8, 2015 - 11:00am

On March 20, we released a major version update to our Stanford-branded, mobile-responsive, Drupal 7 theme, Stanford Framework (read more about the update here). This version includes several new theme options that greatly expand functionality and flexibility of the theme. In this post, I'll highlight ways you can use the new Stanford Framework to create beautiful, customized designs faster.

"Style" options

We had found that many department and group sites were further customizing their look-and-feel using CSS Injector, with mixed results. We wanted to give people an easier place to start to get a more unique look-and-feel. The 3.0 release now lets you choose from seven different color palettes and three font options (below) to allow for easier customization of your site. All colors and fonts fit within the Stanford identity guidelines, and together can create over 21 combinations.

Stanford Framework style options

Stanford Framework font options

By starting with one of these style options, you can get closer to how you want your site to look through the theme settings page, and then add only minimal CSS to enhance the existing styles.

We had originally introduced this functionality in the Stanford Light theme, and very quickly realized that there was a larger demand for this kind of stylistic customization from sites that required the Stanford brand bars (only available in Stanford Framework). So we ported over the custom style options, improved them, and integrated them into Stanford Framework.

Subthemes as options

Another shift in the flexibility of Stanford Framework is that we now incorporate the subthemes, Wilbur and Jordan, into the Stanford Framework theme as theme options. There really was no reason for these to be subthemes in the first place, as they are simply a layer of custom CSS, and do not include any custom template code. So in 3.0 we moved the CSS for Wilbur and Jordan into Stanford Framework and you can now enable them from the theme settings page. This does not mean that we will be neglecting the stand-alone Wilbur and Jordan themes, but that it should be easier going forward to provide variety for groups and departments through Stanford Framework as a single theme, instead of requiring multiple themes to be enabled all at once.

Responsive header background images

An exciting new feature in Stanford Framework is a robust theme option to support a responsive header backgroud image. This includes a subsetting to set the background image to fill the entire page on the homepage for greater impact, and a subsetting for choosing light or dark text color to contrast with your background image for greater accessibility. See below for examples.

Stanford Framework header background

Stanford Framework header background full bleed

See a demo

Join us at Stanford Drupal Camp where we will be demoing the new theme options and how to use them creatively to get beautiful, customized designs faster for your Drupal site. After Drupal Camp, we'll upload the recordings to the resources page on the Drupal Themes website for reference.

If you are interested in requesting use of Stanford Framework for your department or group website, please visit the Drupal Themes website request form.

Posted in:
Megan Erin Miller Posted by Megan Erin Miller on Tuesday, March 17, 2015 - 8:00am

We are excited to announce the upcoming March release of our updated mobile-responsive Drupal themes:

  • Stanford Framework 7.x-3.0 (major version release) *

  • Open Framework 7.x-2.3

* Stanford-branded themes are available by request for official university group and department websites.

How to receive updates

For websites hosted on Stanford Sites: updated themes will be rolled out over March 20-22, 2015. 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 March 20, 2015. To download the latest theme versions, visit

To see demos and request use of a Stanford-branded theme, visit


Below are improvements made to the themes since the last release (September 2014).

Stanford Framework 7.x-3.0 (major version release)

New functionality

The newest version of Stanford Framework includes several new theme options that greatly expand functionality of the theme:

  • The ability to choose from seven different color palettes and three font theme options (all fitting the Stanford identity guidelines but allowing for easier customization of the look-and-feel)
  • The ability to select Wilbur and Jordan as theme options (instead of requiring an additional subtheme)
  • A theme option to add a responsive header background image, and sub-options to make the background image fill the entire page background on the homepage for greater impact, and a sub-setting for choosing light or dark text color to contrast with your background image.

Accessibility improvements

  • Fixed empty button element in "hamburger" menu
  • Fixed accessibility and color contrast issues with custom theme option settings combinations

Bug fixing

  • Fixed a myriad of bugs related to layout, theme options, page templates

Style/Cross-browser improvements

  • Fixed IE8 issues
  • Tweaked table, block, pager, image, sidebar, menu, dropdowns, and calendar styles
  • Updated style guide examples in style-guide-examples.html

Theme Settings page improvements

  • Re-organized theme settings page, collapsing fieldsets and adding conditional fields based on style options
  • Added thumbnail images for previewing the custom theme option styles

Code improvements

  • Added allowance for overriding theme settings by refactoring template code
  • Refactored SASS files for managing  theme option styles


Open Framework 7.x-2.3

New functionality

  • Added theme option to select Font Awesome 4.3.0 or 3.2.1

Accessibility improvements

  • Fixed empty button element in "hamburger" menu

Bug fixing

  • Added missing body classes for body background image theme option

Style/Cross-browser improvements

  • Moved body related theme options styles from html.tpl.php to template.php


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 will respond as soon as possible.

We're excited to bring these new theme developments and improvements to the community. Thanks to everyone who has submitted ideas and bugs over the past six months. We appreciate your support!


Posted in:
Megan Erin Miller Posted by Megan Erin Miller on Friday, January 16, 2015 - 9:00am

Welcome back! It's a new year, and that means you probably have some New Year's Resolutions on a sticky near your computer (I have about ten). If one of the goals on your list to learn Photoshop or how to code, then as a seasoned overachiever – I mean, self-driven, life-long learner – I've got some tips for you on how to rock your resolution.

1. Pick a resource

There are some great resources out there for online curriculum to learn technical skills like software or programming, like (which Stanford now provides for free to faculty, staff, and students!). These kinds of sites, which put learning resources on demand at our fingertips, are only as helpful as you make them. It is too easy to drown yourself in the multitude of online resources and get lost in the learning rabbit hole. What I recommend is choose one resource – a book, an online course, and resource like Lynda (which has tracks of curriculum), and stick to that resource to create more structure for yourself. Let that resource guide you in your learning, and give it a real chance before ditching.

2. Make it real

The key to making self-driven learning work for you is to have a real project or goal in mind that requires you to learn those new skills. Do enough research ahead of time to come up with an idea for a project that interests you that can provide focus for you in your learning. Watching videos or reading tutorials is absolutely ineffective if you do not directly apply it to a project. Don't waste your time. Instead, make your goal fun and something you are passionate about so that you will keep it top of mind.

That said, keep your project goal small enough so that it isn't scary. Don't dream up the next Facebook, come up with an idea like a one-page website Valentines card for your significant other. As you learn your new skill, you will have more ideas about how to expand your project goal and make it more interesting, so start off with a simple idea and let it grow.

3. Create accountability

There's nothing like creating accountability when it comes to reaching your self-driven learning goal. This is actually what real school does, but you can create this accountability for yourself! Here are some ideas:

  • Find a buddy: An accountability partner can be someone else committed to a goal they have. Set a regular day each week that you email each other an update on what you did that week, and what you plan to do the next week. It's a way to build your friendship and become partners in reaching your goals.
  • Blog your adventure: Create a learning adventure blog where you publish each week a post of something you made that week, and what you learned. Public accountability and a nice record of what you did to show your progress.
  • Put it in the Calendar: That's right. Pretend it's a real class, and put it on your calendar and PROTECT YOUR TIME! Make sure your colleagues and family/friends understand that this time belongs to your learning goals.
  • Report back: If your skill-building is related to work, even if you are doing it as a side project, create public accountability by telling your team what you are doing, and setting a lunch time with them aside to do a little presentation at the end to share what you learned. Everybody benefits.

4. Set intentions, not goals

Lastly, be kind to yourself. For self-driven learning, it is often better to set intentions rather than goals. You can't actually know what the end result is going to be, because learning is a process, and you'll discover that along the way. So instead of setting a goal like, "Learn Photoshop," or "Build Fakeblock," set an intention.

"I intend to spend 1 hour each week on learning Photoshop."

"I intend to spend three months learning CSS."

What's great about this is that every week you stay committed to your intention, you get positive reinforcement to continue, instead of at week two saying to yourself, "Man, I still don't know Photoshop! It's going to take forever. I'm not reaching my goal."


I hope these tips have helped you make your self-driven learning goal a little more achievable. What are some of your New Year's Resolutions, and what has worked for you in the past when setting self-directed learning goals?

Posted in:
Megan Erin Miller Posted by Megan Erin Miller on Friday, December 19, 2014 - 8:15am

2014 has been a blast. We are so grateful to get to work with so many talented and dedicated colleagues around the university (and beyond!). We wish you happy holidays over the winter break, and we'll see you in 2015!

SWS team photo

Posted in:
Megan Erin Miller Posted by Megan Erin Miller on Tuesday, November 18, 2014 - 9:00am

During BADCamp this year, I participated in the Front End Summit. We learned about Drupal 8, had a series of lightning talks, and a lively panel featuring a diverse range of voices from the Drupal front end community. Here are some of my take-aways.

Drupal 8 Core Rocks

Learning more about Drupal 8, it’s exciting to see that so many of the modules we work with in our “toolkit” on Stanford Sites have been moved into core in Drupal 8, like Menu Block, for example. It validates the direction we are going with Sites and with our stack.

The Front End Community

Although UX and design was drastically improved in Drupal 8, the way the community talks about it is not inclusive. The “Front End” Summit should have been a home to everyone working on design, UX, mobile, responsive, and not just a home for themers. Being a Drupal Themer is actually kind of hard core, and the code of a theme, even with all the great improvement in D8, theming is still intimidating for people just getting started and wanting to change the styles of their site. How can we onboard new themers better and give them a toolkit to get started? Scaring them into sprinting with you won’t work. We need hand holding. How can we hold hands at scale through online tools?

Designing for Drupal 8

Similarly, what I need to know about Drupal 8 as a designer is not what new variables are available in the twig theme layer, or new syntax for looping, but I need to know the high level stuff. The “why” and the story behind the new features and changes so that I can pitch this product. I need to know how what is available in core can be a new set of recipes for success in site building. All of these things influence design decisions, and as designers, we need to understand the tool with which we are designing so we can communicate with our developers, clients, and other stakeholders about what is possible.

Some big themes

There were quite a lot of other very interesting threads that I could probably dive into deeper, but for the sake of brevity will summarize here:

  • Accessibility — how this is hard, and what people are doing to automate/integrate it into their process
  • Tools that we use — and how this landscape is still changing, but for the most part people have settled on a few key tools (e.g. SASS, Grunt, Bower) and stopped trying every new thing
  • Task automation — but particularly for testing, and especially challenging for accessibility testing
  • The wide range of “what is Front End” — and how this is challenging for the Drupal community
  • What a Designer should be creating as a deliverable — and specifically if a Designer should know how to code.. verdict: undecided
  • Particularly troubling was the question of how happy are Front End Developers with Drupal — the answer has not been a resounding yes (re: D7), and we hope Drupal 8 will attract more Front Enders

If you attended the Front End Summit, what were some of your big take-aways? Leave a note in the comments.

Megan Erin Miller Posted by Megan Erin Miller on Monday, September 8, 2014 - 8:44am

We are excited to announce the release of a new mobile-responsive, Drupal 7 theme, Stanford Light, available now to all users on Stanford Sites. Stanford Light is a new, flexible theme that allows you to easily customize the look-and-feel of your site using several new theme options. In this post I'll walk you through how to customize Stanford Light on your Drupal site.

Who is Stanford Light for?

Stanford Light gives you seven different visual styles and three font families to choose from. All colors and fonts are variations on those recommended in the Stanford Identity Toolkit, but the theme does not include the Stanford brand bar, Stanford universal footer, or Stanford logo. This lets you have a Stanford "feel" without the presence of Stanford branding elements. Because of this, Stanford Light is ideal for personal websites, student group websites, and websites that do not require Stanford branding but still want the look and feel of a professional Stanford website.

Get Stanford Light for your Drupal site

If you would like to enable Stanford Light on your Stanford Sites website, visit the Appearances admin page and enable and set to default. As of September 2014 Stanford Light is now the default theme enabled for newly requested personal and group sites on Stanford Sites.

Spiffy theme options

Once you have the Stanford Light theme enabled and set to default on your Drupal site, go to Appearance > Settings > Stanford Light. Here you will see a myriad of theme options that let you choose whether or not to show the logo, site name, site slogan, etc. For now, we are going to skip down to the section Customize Design.

In the Customize Design section, you can choose from seven visual styles, three font families, and decide whether to enable a global thin red bar at the top of your page. Demo these options live at the Drupal Themes website.

Stanford Light - example 1Stanford Light - example 2Stanford Light - example 3Stanford Light - example 4

Examples of design combinations you can create with Stanford Light


If you want to add some splash to your website, consider adding a background image to your header. To do this, find the Header Background section of the theme options and upload your custom image. Make sure your image works as wide and short, and make sure the file is at least 1200px wide for optimal image quality. In the settings, you can choose whether you want your image to stretch to fill the available header space (recommended for big images), or tile as wallpaper (recommended if you are making a patterned background). You can also choose the color of the Site title text that overlays on top of the image. If your image is dark, choose light header text color. If your image is light, choose dark header text.

In addition to adding a header background image, you can also add a body background image in the Body Background section of the theme options.

Stanford Light - example 5

Example of custom header and body background images


There are many other theme options you can explore with Stanford Light, including adding border styles to blocks and containers and hiding and showing breadcrumbs and page titles.

Demo time!

To preview the theme options available in Stanford Light, visit Use the sidebar block to preview different combinations of theme options.


If you have any questions regarding this new theme, contact us via HelpSU at and we will respond as soon as possible.

Posted in:
Megan Erin Miller Posted by Megan Erin Miller on Wednesday, September 3, 2014 - 8:09am

We are excited to announce the upcoming September release of our updated mobile-responsive Drupal themes:

  • Open Framework 7.x-2.1
  • Stanford Framework 7.x-2.2 *
  • Stanford Wilbur 7.x-2.1 *
  • Stanford Jordan 7.x-2.1 *
  • Stanford Modern 7.x-1.6 and 6.x-1.6 *
  • Stanford Light 7.x-1.1 (New!)
  • Stanford Basic 7.x-1.5 and 6.x-1.5

* Stanford-branded themes are available by request for official university group and department websites.

For websites hosted on Stanford Sites: updated themes will be rolled out over September 5-7, 2014. 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 September 5, 2014. To download the latest theme versions, visit

To see demos and request use of a Stanford-branded theme, visit


Below are improvements made to the themes since the last release (October 2013).

Open Framework 7.x-2.1

Accessibility improvements

  • Pointed skip links to correct region
  • Improved mobile navigation button
  • Fixed focus visibility on form-submit buttons
  • Added IE support for search box placeholder value

New functionality

  • Added .visually-hidden class
  • Added .views-row-lines class
  • Added responsive views-grid classes
  • Made equal column height class dynamic on window resize
  • Added site login block region
  • Changed CSS to be output from SASS files

Bug fixing

  • Fixed missing region from subtheme starter kit
  • Added project variable to .info to fix undefined index error on update status page
  • Removed check for $body contents in node.tpl.php
  • Updated header section display

Updated packages

  • No packages were updated in this release. (e.g. Bootstrap, Font Awesome)

Style/Cross-browser improvements

  • Added IE 7 support for postcard layouts
  • Updated more-link to use CSS instead of image
  • Updated vendor prefixes in CSS
  • Tweaks to margins and padding on regions and blocks
  • Removed Bootstrap transparent background print style
  • Updated mobile display of float-left and float-right classes
  • Added line-height and margins to field labels
  • Updated postcard styles to be more robust
  • Removed duplicate nested container div in navbar region

Stanford Framework 7.x-2.2

Accessibility improvements

  • Pointed skip links to correct region
  • Added focus indicators to links in global brand bars
  • Made main menu "hamburger" button keyboard accessible

Bug fixing

  • Added project variable to .info to fix undefined index error on update status page
  • Removed duplicate nested container div in navbar region
  • Updated header section display so blocks in header region don't show up between first and second line of site title

Stanford Identity style/template improvements

  • Updated global footer to reflect current links and styles in Stanford identity toolkit, including the new Emergency Contact link
  • Adjusted site title lockup styles to more accurately match Stanford identity guidelines
  • Updated Stanford favicon
  • Hardcoding font styles in global brand bars

General Style/Cross-browser improvements

  • Adjusted styles in sidebar menus
  • Fix banner overlay styles
  • Added style overrides for Stanford Carousel feature
  • Updated font-family in Admin Shortcuts region for cross-browser compatibility
  • Added color override for .views-row-lines class
  • Added custom blockquote style
  • Added responsive styles for global footer at smallest breakpoint
  • Removed Bootstrap blue color from links and pills in focus state
  • Added red button styles and arrow button styles
  • Updated .more-link style to use CSS not image
  • Removed site title font size change at tablet breakpoint
  • Added header section class for header table display
  • Fixed premature wrapping of name and slogan in Chrome
  • Updated margins on regions and blocks

Stanford Wilbur 7.x-2.1

  • Tweaked breadcrumb styles (removed left margin, updated color)

Stanford Jordan 7.x-2.1

  • Removed unnecessary positioning classes
  • Adjusted spacing in dropdown menus

Stanford Modern 7.x-1.6 and 6.x-1.6

  • Updated links and copyright text in global footer

Stanford Light 7.x-1.1

  • Initial release

Stanford Basic 7.x-1.5 and 6.x-1.5

  • Added terms of use

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 will respond as soon as possible.

We're excited to bring these new theme developments and improvements to Stanford. Thanks to everyone who has submitted ideas and bugs in the past year. We appreciate your support!

Posted in:
Megan Erin Miller Posted by Megan Erin Miller on Tuesday, August 12, 2014 - 9:00am

Drupal is (in)famous for providing an egregious amount of class selectors to target every layer imaginable in its rendered HTML. Some superstar culprits are Field Collections, Field Groups, and complex Views. When we see so many handy, available selector classes, it's so tempting just to target them directly in your CSS. But today, I want to share a lesson I learned the hard way about why you've just gotta resist that temptation, and instead create reusable classes.

One of these things is not like the other...

Here's where my story starts – a beautiful, complex, custom design, being built out by my talented teammates as I began to translate Illustrator comps into CSS. As my team created blocks, menus, pages, views, and contexts, I chased after the functionality, skinning it as fast as I could, moving from one section of the site to the other. My CSS started small, maybe a hundred lines, but soon it began to balloon.

As I began polishing the corners of the site, I inevitably realized that many different elements needed to look the same across the site, even though sometimes they were rendered differently in the HTML. Ah, the joys of Drupal theming, where sometimes you can't change a view label from an H3 to an H2, so you just style them to look the same. But when you have dozens of different elements being rendered in subtly (and not so subtly) different markup, how can you get all the things to look the same without an overwhelming amount of CSS?

Here's what my CSS started like:

h2 {
  color: #8c1515;
  text-transform: uppercase;
  font-size: 1.2em;

But soon, the selectors got out of control!

h2, #my-crazy-view .view-header h2, #another-crazy-view .view-grouping h3, #block-ap9f8uqc4umweirut9p83WTF h2, .page-some-custom-type-of-page .region-lower #block-sadflkj0239u40984OMG {
  color: #8c1515;
  text-transform: uppercase;
  font-size: 1.2em;

OK, you get the point.

Now, stringing selectors together is better than listing duplicate CSS rules for each selector individually, but there's still a real problem with the way that we are targeting these elements across the site.

Hi, I'm a block, and I changed my name!

So someone else is editing the site and they decide to do some cleanup of a view block display. They add a nice semantic name to that block, which is great, except that I targeted that block name specifically in my CSS, and suddenly I get an urgent email telling me the styles are broken. I quickly load up the site and open Firebug trying to see what's wrong. I don't see any CSS loading in the sidebar when I target that element, which is weird, because I know I themed that block, and that it should look like that other H2 on that other page... now what page was that on again? So, as I ponder why all of a sudden my CSS is missing (because I haven't figured out yet that the block name changed) I dig through the site trying to find an example of the CSS it should have, and finally I find it. To alleviate the problem, I create a CSS Injector rule targeting the new block name and copying the CSS I found on that other page instead of hunting down the lines of CSS in my theme files and pushing out a fix.

This sounds terrible, and it is.

But have no fear! There is a better way!

Your friends, reusable class names

So, that was the last time I mindlessly targetted Drupal-created selectors in my CSS. I say mindlessly, because sometimes it is impossible to style something without targetting a Drupal-generated selector class, but it was the last time I did that without thinking first about how it might affect the longevity of the site and the sustainability of my theme files. Instead, every chance I get, I try to create and add a custom reusable class name to the HTML that Drupal renders.

What do I mean by reusable class names?

A reusable class name is a semantic name that describes what the end result is. For example, color-block would be a nice class name for blocks that are colored differently from the default block, or views-row-lines for a style of views rows with lines in between, or top-line for a block or section style where there is a border on the top. These are all examples of real classes I have created to be reusable across a project, or several projects even. The names are functional, and not specific to certain views, features, or Drupalese. This is important, because right now, you might be thinking, well, only the people view should have lines between the rows, but then your client might come back next week asking if all the other views can look like that one.

Reusable classes become a style guide

So when you start translating your design into CSS, think about how you can break your styles into semantic classes. The way I do this is I create a Google Doc and start listing out the new classes I am creating. This document eventually becomes a style guide reference, and for each class in the document, I describe how and when to use the class, what it's for, a screenshot or code snippet, and how to apply it to a view, block, or page. Some classes even become so useful that we add them to our base themes, or reuse the same class names across several client projects. Other classes are specific to a client's design and wouldn't translate universally.

Adding your classes to Drupal

My style guide for these classes usually contains instructions for site builders on how to add the class in Drupal. Here are the most common ways to add your custom classes to Drupal:

Block Class

Using the Block Class module, you can add custom classes at the block level. This is perfect for theming different looking blocks, specific view blocks that show up in multiple places (like entity referenced content), menu blocks (like if you want a sidebar menu style), or any other custom blocks you've created. Block Class lets you add a class on a per block basis, so it lets you cherry pick your styles. I use Block Class to target the background color of the block, the heading style, the link style, and the margins and padding of a block or elements within the block.

So my CSS might look like this:

.color-block { background: sandstone; }
.color-block h2 { color: black; }
.color-block img { margin-top: 0; }
.color-block .more-link { font-size: 1.1em; }

And all you have to do is click "Configure Block," and paste color-block into the Block Class field on the block to apply your style, and if someone renames the block, your CSS won't break.

block class field

View Class

Another way to get a custom class on a View is to add it to the View class. Edit your View, and under the Advanced section you'll find a field to add your custom class name. This adds it to the view level of the HTML. What's great about this tactic is that you can add your view style to any View and not have repetition when you want a few different Views to match in style.

view class settings

Manage Display

Lastly, if you need to wrap a field or set of fields in a custom class, you can create a Field Group div in Manage Display for a content type, and add your custom class to the field group. Make sure to hide the label though, you don't want "Descriptor Group" to show up in text on the page.

Manage Display field group class

Wait, I have to do more work?

Yes, adding custom classes adds more work for you and your site editors and builders. For you, strategizing as you convert design to code, creating a style guide, and helping others build out the site with the correct classes does add more to your plate, but you'll sleep better at night knowing that your CSS is semantic and robust, and that you've promoted best practices for your team. For your site editors and builders, they now have to add your custom classes to all the right places, but that isn't too hard as long as you provide them with good documentation (marked up wireframes are usually what I provide). What's fun for them now is they get to feel that instant satisfaction of adding a class and suddenly seeing their view block look awesome, just like magic! And you can write your CSS in advance of the team building out the site, knowing that you don't have to wait to target a specific view or block name.

It's worth it.

All this hard work pays off in the long run. You develop a library of reusable class names that you and your team adopt for projects going forward, and your CSS stands the test of time and minimizes future style mixups as the site grows and changes in the hands of the client. Don't make the mistake I did on my first big custom theme project, take the time now to strategize on how reusable classes can become part of your daily practice in Drupal theming.


Subscribe to Megan Erin Miller's Blog Posts