Skip to content Skip to navigation

Blog

Shea McKinney Posted by Shea Ross McKinney on Wednesday, December 9, 2015 - 9:14am

Not all modules belong on Drupal.org

Over time Stanford Web Services has built a large library of custom modules, features, and themes. Some of the work made its way back to Drupal.org, but some of it is specific to Stanford or higher education types. You can find most of this work on our GitHub organization page as we like to be open source. Not only do we share our code with the Stanford community...we share with the whole Drupal community. Anyone and everyone can download and use the things we build. 

Sometimes the things we build have bugs and need to be updated. A problem with our features and custom modules is that they don't have an update status like those available from Drupal.org. Some folks have asked us "Why don't you run a features server" to support update status? The reason is that we like to work with GitHub, and it provides us and our developers many tools that a features server does not have. The good news is that GitHub has an API and a release system. This allowed us to create a module to get update status information from GitHub into Drupal.

We called it ERUS

You can find ERUS on the project page of Drupal.org or on our GitHub account. ERUS stands for External Repository Update Status. With this module, and a line in your module's .info file, you can get information about release status for your custom modules and themes right in Drupal. This has proven valuable for us as more and more teams across our campus adopt and use our shared work. We don't know where our work will end up next and cannot expect those who install our modules to follow our GitHub pages. Using this module, they can get the update information they need right in their website.

How it works

  1. Pick one of your features or custom modules on GitHub. It has to be in its own repository like: https://github.com/SU-SWS/stanford_bean_types
  2. Add `project status url` to the .info file of the module that is the full url to the GitHub page. Look at this example.
  3. Set the version number to something that conforms to the Drupal 7 version naming scheme, e.g.: 7.x-1.0-dev or 7.x-1.1
  4. Create a new release via GitHub's release system using the same name as the version.
  5. Download and enable the ERUS module in your Drupal site.
  6. (optional) If the repository is private you will need to enter a GitHub username and password that can read from the repository.
  7. Visit the update status page in your Drupal site to see the versions.

You can also use Drush to view and update the modules.

For more information on the installation, configuration, and extension of this module, please visit: https://github.com/SU-SWS/erus and https://github.com/SU-SWS/erus/blob/7.x-1.x-dev/plugins/README.md

Example of ERUS in action

Update Status Bar

Credits

Thanks to Zach Chandler and Brian Wood for their contributions to this project.

Johan Baath Posted by Johan Baath on Monday, November 30, 2015 - 8:15am

Even though it feels like I have known the SWS team for years, the truth is that I have only been here for two months. The reason it feels that way might be because of the amount of things I’ve learned from my colleagues over the past 8 weeks could be compared to an intense 4-year combined degree in Computer Science/Customer Relations/Project Management. Another reason could be that the amazing people that comprise this team make you feel at home right away.

Why is SWS so good at what they do?

Something that became clear to me after just a couple of days working here was that the SWS team doesn't just call themselves a team, they area team. When someone has a lot on their plate while others don’t, they simply help each other out. This might sound banal, but far too often people within an organization do their own thing and don't bother about helping their coworkers because “it’s not their job." The reason why SWS manages to function as a team is because everyone on the team is highly flexible: the developers help out producers with their tasks; the producers help out developers with some of their tasks; the PMs jumps in wherever they’re needed. This allows for a high-productivity team that wouldn’t be able to function as it does now if part of the team just stood by the sideline and observed the bottlenecks that slowly brings down the overall productivity.

The power of communication

Communication is the key to everything in organizations such as SWS. Without good communication the team would hit multiple brick walls everyday, but SWS rarely (never as far as I know) does. Every morning at 9.30 am the team gathers in the collaboration space for a SCRUM meeting where everyone briefs the others what is on their agenda for the day. This is a perfect opportunity for people who are blocked from doing something to bring this up to the team’s attention, and by doing so opens up the possibility to get help from someone who knows how to tackle the issue at hand.

Every Friday the team has what is called "Morning of Awesome" (Mo'A), where they sit together in the collaboration space for two hours. During MoA the team could break into small groups and work on a project together, or everyone just sits together and works on their own things and asks the rest of the team for help if needed. One particularly valuable thing with these mornings is how it strengthens the team to work together as an organism, and not as separate entities. This is especially important for teams that have many different roles but also a product that depends on how these different parts come together. 

The willingness to help others

Instead of having someone on the team taking over the tasks that you can’t do, wouldn’t it be better practice to transfer the knowledge on how to solve the problem at hand? This is something that SWS does extremely well: they block a time to go over the issue at hand, solve it together and BAAM: next time the same issue comes up you have two people that know how to deal with it. If you instead frame these issues to only let one person to deal with them, you're depending too much on having this person available all the time. 

This willingness to help others extends far beyond the boundaries of the team - they contribute to the Stanford community by writing this blog, providing a user guide and also by attending conferences where they share their experience and knowledge with other Universities. 

The importance of having fun

In addition to being a high-performing, professional team with lots of flexibility; SWS also knows the importance of having fun. There’s a fine line between ‘having fun’ and ‘just goofing around’ in the workplace, and this is where the excellent management comes into the picture. Having management that is aware of this fine line and knows how to keep the team's eye on the prize while having fun - without wasting precious time - is to me astonishing and what I believe to be one of the key components to this extremely attractive workplace.

Last words

I am extremely grateful that I had the opportunity to work with these amazing people. Even though I’ve only been here for 8 weeks I’m confident when I say that every single one of the people on the team has taught me something that I will bring with me 5,379.96 miles over the Atlantic Ocean when I go back to Sweden.

Posted in:
Posted by Greg Garvey on Tuesday, November 17, 2015 - 8:05am

The development team was recently given the opportunity to stand up a Drupal 8 REST server with the intent of improving on our D7 content server, learning what's new with the framework and seeing how our content types would fit into the revised architecture. Having just attended BADcamp at UC Berkeley, we were excited to use Drupal 8 and its new special sauce (yml, composer, console, bigpipe, twig, etc).

The foray started with a quick win. Standing up a REST service with Drupal 8 was wicked fast (note: I blame the use of the word 'wicked' on marrying someone from Boston). We leveraged the core web services modules HAL, HTTP Basic Authentication, RESTful Web Services, and Serialization.

Next, we installed REST UI and Self Documenting REST API. REST UI gives you point and click configuration of your REST API end-points and Self Documenting REST API provides...well, you guessed it, a self documenting API for your REST server. REST UI has a very easy to use GUI and made getting endpoints set up a breeze. Self Documenting REST API was easy to set up and while documenting GET fairly well, it lacked some of the detailed documentation for using POST, DELETE and PATCH. I tested the endpoints using google Postman, but other tools such as PAW or DHC would work as well.

First reactions to using Drupal 8 for a REST server were positive. HAL (Hypertext Application Language) is awesome! Hyperlinks between resources in your API make it really great for exploring and understanding how the API works. Tacking '?_format=hal_json' onto a node/{nid} path and getting usable objects was effortless. 

Serving up real content types with Drupal 8 REST services was a mixed bag of success and failure based on the availability of working contrib modules that our field types used. The fierce pace of contrib module development will likely have things running more smoothly by the time of Drupal 8's release slated for November 19, 2015.

Shea McKinney Posted by Shea Ross McKinney on Thursday, November 12, 2015 - 12:19pm

Creating a Drupal Feature is easy. Creating a Drupal Feature that everyone can use is really hard.

Features, as in the Features module, allows you to very easily export something that you have created in a Drupal website in order to use it in another. This is an extremely powerful tool that is the basis for how many Drupal websites are built. Not only can you share functionality from one site to the next you can use it to start new websites. Over time as the functionality changes, or matures, the Feature can be updated with new items and then re-deployed to the sites that currently using the Feature so that they get the new changes and are not left behind.

Drupal by nature is a complex mess of data and configuration that could either be in code or in a database. Drupal 8 is making significant leaps and bounds to wrangle this mess but it won't solve all of our problems. In Drupal 7 it is possible to have parts of a Feature in code and parts of a Feature in the database. Modern day site building strategies have determined that having all site configuration in code is the best way to build and maintain a website. Many agencies, teams, and shops, use this strategy, very successfully, to maintain their organization's website or websites. They are able to make changes to their Drupal site Features on a local, or development, environment and use Features to export, or re-export, the code to deploy to a production environment. This works well when you have a developer, or team of developers, working to maintain a handful of similar websites. This does not work well if you let site builders make changes through the UI on the live site.

Unleash the UI!

At Stanford we heavily use Features to create our websites. At the time of this article we have over 1600 websites in production and we have several products (distributions) that we maintain. Our products share many of our Features and use them in slightly different ways. When we deploy a website for a department or group, at Stanford, we hand over the keys to the UI to their team. The other departments team is able to create content, Views, Contexts, View Modes, and more. Any seasoned Drupal builder should be shouting "But think of the Features!" right about now. Yes, with handing over the UI, site owners can override Features extremely quickly. 

As a developer, overridden Features are a big red flag of unpredictability. They say "Don't touch me. I am a special snowflake now." They are no longer the Feature we once knew and we don't know what they have become. This is a problem because now some of the configuration is in the database and some of the configuration might still be in the code.

Finding the common ground

Finding a common set of configuration for anything with a large set of players is difficult, if not impossible. When you whittle down the feature requests, needs, and wants, then take away the "specific to one" functions, you are left with a very small, and most often, not very useful set of features. Do you still try to find this common set? Is it worth the effort? Who does it benefit? Yes, but finding the common ground is not as important. What is important is that the feature either can support the special or unique parts through configuration or accelerates the development of such.

How do you build the feature(s)?

We have four scenarios that we need to account for when building a Feature.

  1. For use in any Drupal website (public)
  2. For use in our (Stanford Web Services) distributions
  3. For use in a client specific distribution or custom website
  4. KIT Compliance (sorta)

This means that not only does the feature have to work and look good and the Drupal contributed module level but also have the special sauce required for specific distributions. We need to support things like namespaces, encapsulation, configurability, and upgradability. 

A. Namespaces

Naming things is hard. Naming something so that it doesn't collide with other similarly named things is even more difficult. With Features in Drupal 7 this means prefixing everything with a namespace. From your content types to your fields to your views, it is important that you prefix the machine names with your namespace. 

Example for a page content type:

content type label:         Page
content type machine name:  stanford_page
fields:                     field_s_page_fieldname
views:                      stanford_page_view
context machine name:       stanford_page
context group:              Stanford Page

B. Encapsulation

Feature encapsulation is extremely important. De-coupling the feature from themes, other features, and site specific features is key to the ability to use it anywhere. Even though you can use a Feature anywhere, there still is the expectation that it will do something and look good out of the box. Providing sensible defaults is a way to support the out of the box issue but as the word default implies, there needs to be a way to change or override them. Some things that change often are:

  1. Permissions
  2. Display settings, theme options, view modes, or page layouts
  3. Fields
  4. Front end and administration views

Keeping Feature modules de-coupled is important. A good example for when it would be a good idea to break something out in to its own module would be when a content type has a entity reference field to an entity type that is also in a Feature module. This relationship field would create a direct relationship and dependency on the other feature module. If possible, it would be a good idea to break out the entity reference field into its own module so that the core content type and fields could be used as stand alone.

C. Configurability

Allowing for site specific configuration within a Feature module is important for its success and adoption. Allowing a feature to have options can be as simple as breaking out choices in to their own separate Feature module. This would allow site administrators, or installation profiles, to choose which options they want to turn on. 

Scenario #1: I want one of the bundled options
For example, if you created a page feature that could have sidebar blocks on the left or the right columns, you could separate the two options in to feature modules of their own and allow individual sites to enable one or the other.

Scenario #2: I don't want any of the bundled options
For example, if you created a page feature with a separate Feature module for the node display, as a site builder I could choose to disable, or not enable, the Feature module with the node display in it. This would allow the site builder to then build any layout for the page feature without overriding the Feature.

Scenario #3: I want what is bundled but slightly different
Creating separate Feature modules for choices is not always a fit as it is an on or off strategy. Sometimes you want more options and for that you will need to have a developer create a configuration page/form/place for the additional choices. Adding modules and custom code to hook into existing features to make the changes will prevent a feature from being overridden. 

D. Upgradability

It is important that as a Feature changes over time that older versions of the Feature do not get forgotten. Newer versions of a feature should not break older versions. For example, if a field called field_s_page_type gets renamed to field_s_page_category, an update hook will need to be written to handle this change. This will include moving all of the data in the previous field name in to the new one. 

The general rule: New versions cannot break older versions. 

E. General practice

  • Stay as close to KIT compliant as possible.
  • Never put content in a Feature. There are better methods for creating content.
  • Content includes but is not limited to:
    • Taxonomy terms
    • Menu items
    • Block classes
    • Nodes
    • Users
  • Never use a strongarm variable that is used outside of the feature it is intended for.
    • For example, Display suite exports a variable for field to block that stores information for all content types. This breaks the encapsulation rule and cannot be used.

Working with shared features

The above article details how to create and maintain Features in Drupal. Please read part two of this topic by navigating to and reading "Tips on how not to bork your features". The second part is geared towards site builders working with a site built with shared features.

Cynthia Mijares Posted by Cynthia Mijares on Monday, November 9, 2015 - 11:11am

This module allows you to save versions of a page in a draft state before publishing.

Posted in:
Cynthia Mijares Posted by Cynthia Mijares on Monday, November 2, 2015 - 7:00am

Our team created the Stanford Sites Jumpstart service to help website owners focus their energy on what matters most: their content. To do this, Jumpstart includes a dashboard for simple content maintenance. This "Manage Content" feature offers an overview of all pages in the site and supports updating individual or multiple pages at one time.

Once you've logged in to your Jumpstart-based site, select Manage Content from the Site Actions menu.  

From here you can see a table with all the pages in your site:  

Manage All Content

Filters

Use the filters at the top to narrow the display of content.  For example, if you only want to see published pages and exclude the unpublished pages, filter by Published status "Yes" and then click the Apply button. As a result, you should only see the event title "Fresh Perspectives...".  Click the Reset button to clear all search filters and to expose all your content.

Sort

You can sort content in ascending or descending order by clicking on the column heading titles.

Actions and Operations

From the Manage All Content page, you can edit, delete, or view any individual page. You can perform these actions on several pages at once by checking the box in column one for the items you want to update. Then choose an operation from the Operations drop down, and click the Execute button.

Manage Content by Type

Depending on the type of Jumpstart product, you may see in the right sidebar the option to manage content by content type. For example, if you only want to manage events, click on the Manage Events link to get a customized screen that has fields specific to the Events content type.

Manage Content by Type

Manage Events

 

 

Read more

Check out more information about the features included in the Stanford Sites Jumpstart service, and let us know what you would like to see.

Posted in:
Jamie Posted by Jamie C. Tsui on Thursday, October 29, 2015 - 2:05pm
 

While Stanford Web Services can be seen as a service provider, often involved with custom projects and closely working with clients, one of our core offerings is also our Jumpstart product. With any product offering company, as adoption and usage of the products grow, more and more customers give feedback and express interest in the future direction of the product. Lately, our group has been contemplating increasing transparency in our product development roadmap, and to what extent.

To be or not to be transparent?

On one level, transparency and inclusivity in the design/development process can turn into a “design by committee” process, potentially paralyzing development in an effort to satisfy numerous specific/one-off types of needs. This is one of several reasons as to why many companies choose not to make their product roadmap public, and to use a “take-it-or-leave-it” approach in whether or not customers adopt their product (Apple and Facebook in particular come to mind). An advantage of making the product/development roadmap more opaque is that customers remain likely to purchasing/adopting the product late in its lifetime, instead of postponing their purchase for the next generation product to wait for better features. Furthermore, especially in competitive and NDA-heavy industries, opaqueness in the product roadmap is necessary to gain competitive and first-mover advantage. 
 
On another level, transparency can be very valuable; it creates a sense for clients that their feedback and input have been heard, and for companies it increases predictability and stability within its customers' purchase habits. For the company, it is a way to gauge customer reception of the product without actually committing to building anything yet. “Leaks” and concepts/prototypes are a common method of creating hype and gauging potential adoption, especially in industries where there is a significant investment in resources to bring a product to market (see: the auto and tech hardware industry).
 
For a product that requires a significant investment (in both time and money) on behalf of the customer, such as a consumer camera and lens ecosystem, having a product roadmap increases the likelihood of customer adoption earlier in the system since they can expect that their investment in the ecosystem will be sustained and improved upon in the future. In the case of the camera/lens ecosystem example, customers can have confidence that new releases of lenses will be compatible with the customer’s existing camera, and also that new releases of cameras will be compatible with the customer’s existing lenses. This customer confidence encourages earlier adoption into the system, bringing in revenue earlier to the company for re-investment in developing and improving the product ecosystem.

"Transparency empowers teams"

Transparency often benefits the internal teams developing the product by providing a vision for team members to follow, and by reducing hearsay, confusion, waste, and complexity. Team members feel empowered when they are “in-the-know,” and also appreciate being part of the conversation and having a sense of ownership, ultimately leading to higher morale. This must be balanced with transparency to the company’s customers, with a level that is just enough sufficient to ensure that customers feel that their concerns are heard and that they are also fairly prioritized. The level of product development transparency a company chooses to reveal to customers ultimately depends on the business goals and the type of product that the company produces. 

Increase transparency gradually

Lastly, one important consideration to note is that it is difficult to renege on a level of transparency once it has been established. Roadmaps are constantly evolving, and customers can lose faith in the company if something is promised and then later deprioritized. Therefore if transparency is the plan for the company, it is best to incrementally increase levels of transparency to clients in order to gauge the level that is appropriate for both the company and for its clients. 
 
Have you considered increasing transparency to your clients with your product development and operations? Did your clients find it useful?
Johan Baath Posted by Johan Baath on Friday, October 16, 2015 - 11:54am

If you're writing CSS Injector styles to adjust the look of your Drupal site, it's easy to accidentally get what I call "CSS bleed" into the administrative experience, which can make things look pretty funky on edit screens. In this tutorial, I'll quickly explain how to avoid overriding the styles of your administration theme.

CSS Injector in a nutshell

CSS Injector is a very convenient module for making small CSS changes without having to dig into the website's code. On Stanford Sites, we use CSS Injector frequently to make tweaks (or substantial changes) to the look and feel of our websites. You can learn more about the basics how to use CSS Injector.

By default, any CSS you write will be applied throughout your site, including on administrative pages like edit screens, even if you are using a different theme for administration, which can make things look very strange for your editors.

Excluding admin pages

Because the makers of CSS Injector are pretty smart, they know that sometimes we want to make style changes for specific pages or sets of pages. This can be helpful for making exceptions in styles for special content. By adding a list of pages you want to exclude from the CSS rules the CSS injector will know to not implement these styles for the listed pages.

Example image of pages to exclude from the CSS rules

Above you can see an example screenshot for how the "Add the CSS on specific pages"-section of the CSS injector administrative page coud look like. In this example, we have decided to add the CSS styles, for a specific CSS rule, to every page except the following pages:

admin
admin*
node/*/edit
block/*/edit*
block/add*
node/add*
user/*/edit
node/*/delete

This means that if you - for example - have added a snippet of CSS code for applying a red footer on your entire site, this red footer will not appear while editing a node (node/*/edit), nor when you're doing other administrative tasks (admin*) on your site.

The wildcard (*) is used to cover all pages related to a path. For example, the "node/*/edit" states that the CSS rules should be excluded from all nodes while editing, no matter of the node id. In this case, the page will be exluded from the CSS rules for the path "node/15/edit" as well as for "node/potatoes/edit", since the wildcard could be anyset of characters.

Conclusion

I hope this post can help you prevent some unnecessary headaches as a result of not being able to target and style the desired pages on your site. The CSS injector has some powerful built-in functionalities and using those will hopefully help you bring your website to the next level of aesthetics and on the right pages (even though a rotating "Save" button in the editing mode could be quite cool sometimes).

Posted in:
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.

 

Tags:
Photo of John Bickar Posted by John Bickar on Monday, September 28, 2015 - 10:30am

Today I'm going to review the features and functionality of the WebAuth Extras module. It extends the venerable WebAuth Module for Drupal (WMD), which offers single-sign on (SSO) capability for Drupal sites at Stanford.

There are two user interfaces for WebAuth Extras: the web GUI, and drush.

Web GUI

What You Can Do

The primary functionality that WebAuth Extras provides through the web GUI is the ability to add a new WebAuth user.

What does this mean, and why would you want to do it?

WMD offers the ability for users to log into any Drupal site with their SUNetID and password. When the user logs in the first time, a unique user account is created for them, and they are automatically given the role of "SUNet User". Additionally, users may be assigned additional roles based on affiliation:

Affiliation Workgroup Drupal Role
Student stanford:student Stanford Student
Faculty stanford:faculty Stanford Faculty
Staff stanford:staff Stanford Staff

If you want to assign additional roles to a user, you either need to use workgroup mapping, or the user needs to have logged in to your Drupal site at least once.

Adding a new WebAuth user via WebAuth Extras allows you to bypass the awkward step where you have to burden a user with logging into the site before you assign them a role ("Hi (Senior Faculty Member), this is (lowly Drupal administrator). Can I get you to go to <url> and click the 'SUNetID login' link in the top right corner? No, you won't see anything yet, I haven't configured your permissions.").

How to Do It

  1. Enable the WebAuth Extras module if it is not already enabled
  2. Go to admin/config/webauth/adduser
  3. Fill in the form:
    1. SUNetID: The users' SUNetID. This is the only required field; if you do not fill out the rest of the fields, Name and Email Address will be populated from LDAP.
    2. Name: Fill this out if you want to override what's in LDAP. (Search the user in StanfordYou if you want to find out their name.)
    3. Email Address: Likewise, fill this out if you want to override what's in LDAP.
    4. Make This User an Administrator: Does just what it says on the tin.

Drush

WebAuth Extras provides three drush commands:

  • drush webauth-add-user
  • drush webauth-map-role
  • drush webauth-write-htaccess

% drush help webauth-add-user
Add a new WebAuth user

Arguments:
 sunetid                                   The SUNetID of the user

Options:
 --email=<<a href="mailto:leland.stanford@stanford.edu">leland.stanford@stanford.edu</a>>    The user's email address
 --make-admin                              Make the user an admin  
 --name=<Leland Stanford>                  The user's name

Aliases: waau

% drush help webauth-map-role
Map a workgroup to a Drupal role

Examples:
 drush wamr stanford:staff administrator   Maps the "stanford:staff" workgroup to the Drupal "administrator" role

Arguments:
 workgroup                                 The workgroup you would like to map      
 role                                      The Drupal role you would like to map to

Aliases: wamr

% drush help webauth-write-htaccess
Write the WebAuth .htaccess file to disk. Performs the same function as saving the configuration through the GUI.

Aliases: wawh

webauth-add-user and webauth-map-role should be self-explanatory. webauth-write-htaccess is a utility command that you can use when you suspect that something has happened to the .htaccess file governing WebAuth restrictions (e.g., you lose workgroup role mappings).

Posted in:

Pages

Subscribe to Stanford Web Services Blog