Skip to content Skip to navigation

Blog

Caryl Westerberg Posted by Caryl J Westerberg on Wednesday, December 19, 2012 - 9:26am

Getting a new Drupal site set up takes a few steps before you can begin building your site. Also, Stanford Sites is a little different than other hosting environments. One of the first things to tackle after creating your new site on Stanford Sites is setting up the accounts, roles, and privileges.

SUNetID versus admin

Each account on a Drupal site must have a unique email address.  If you used your SUNetID as the email address when requesting your site, this will be the email address for the admin (a.k.a. user 1) account. However, if you want to log in to your site using your SUNetID and Stanford's WebAuth, the admin account  cannot use that SUNetID email address. You may need address this by changing the admin account email address to something like: sunetid+admin@stanford.edu.

If , for some reason, you lost or forgot the password for the admin account, 

Note: if you're already logged into the site, you'll need to log out by navigating to https://mysite/user/logout. Substitute "mysite" for the name of your site. 

  1. Navigate to the user page at https://mysite/user
  2. Select Request New Password
  3. Enter admin for the username
  4. Click on E-mail new password

A one-time password reset link will be sent to the email account associated with the admin. Click on that link to log into your site. At this point you'll be able to change the password for your account.

To have admin privileges while logged in with your SUNetID, you'll need to add administration privileges to your user account. These privileges are defined through "Roles."

To add or change a role for any user account, visit admin/people or People from the admin menu.  

  1. Select edit for the user account you'd like to change.  
  2. Scroll down until you see Roles and select or deselect the desired role(s). 

If you want to add additional roles to your site, such as an "Editor," you can add them at admin/people/permissions/roles or from the admin menu:

People > Permissions > Roles

To define privileges for a role, visit the "Permissions" page at admin/people/permissions or

People > Permissions

With your user accounts, roles, and privileges set up, you can proceed with building your site!

Posted in:
Megan Erin Miller Posted by Megan Erin Miller on Monday, December 17, 2012 - 5:07pm

Often when we hear that little voice in the back of our minds, "Wouldn't it be great to have a new website?" what we're really thinking is, "Wouldn't it be great to have a new look for our website." While getting a fresh style or "skin" for your site is absolutely a valid reason to want a redesign of our website, in most cases what will really make the most difference for our site visitors is to rewrite, restructure, and rethink the content. Now, this is no easy task, but I would argue that if you start with content first, your website will be immensely more successful at reaching and exceeding your goals.

So how do we think "content first?"

The first thing to get clear on when you are considering a website redesign is who your audience is, and what they need to do and learn on your site. Is your audience an external public trying to find directory information about people or programs? Are they students trying to connect with faculty and find courses? Try to articulate who they are and identify their main tasks and goals when using your website. Once you know your audience, you can tailor the message of your website.

Your audience will drive the message and focus of your content, which will in turn drive the structure and design of your site as well. Once you are able to identify your primary site audiences, you can approach each page in your site, and the information architecture (structure) of the site from the perspective of how to reach your audience. Here's a nifty checklist modified from Chapter Three's page table worksheet:

For each page in your site, answer the following questions:

  • Who is the most important audience for this page?
  • Who is the second most important audience?
  • What's the #1 message we want to get across on this page?
  • What things should a user be able to do on this page, or act on?
  • What buckets of information do we need on this page? Rank from most important to least important.

For a hypothetical departmental homepage, you might come up with this:

  • Who is the most important audience for this page?
    Prospective students
  • Who is the second most important audience?
    Press editors
  • What's the #1 message we want to get across on this page?
    That our department has an active community, creating relevant publications and projects
  • What things should a user be able to do on this page, or act on?
    Learn about the department, Read recent news, See upcoming events, Read featured stories about current students
  • What buckets of information do we need on this page? Rank from most important to least important.
    #1) featured student stories, #2) news and events highlights, #3) information about the department

This last bullet is important—make sure to consider your audience and messaging goals when ranking your buckets of information.

The next step is to create a list of the content that will go on your hompage and define what assets might be needed to create that content.

A content list for our hypothetical departmental homepage:

  1. Featured student stories (requires: image, title, teaser, link to read more)
  2. Recent news (requires: thumbnail image, date, source, title, link to read more)
  3. Upcoming events (requires: date and time, title, location, link to read more)
  4. About the department (requires: short paragraph with link to read more)
  5. Featured programs (requires: links to featured programs)
  6. Featured people (requires: thumbnail image, name, short bio, link to people profile)

Now, this order is important. The order we list things here (in order of most important to least important) is what will drive the placement of this content on the page such that we can highlight the most important information first. In this way, the design will truly be derrived from the content hierarchy.

Hierarchy of content in layoutUnderstanding our content hierarchy is extremely important when considering how our website will translate to mobile devices. When using responsive themes (the Stanford theme stack is responsive), we must pay attention to how the "desktop" layout of content will translate to mobile. In the list we created above, we want to make sure this content appears in the order we specified when viewed on a mobile device. To better understand how your responsive theme handles your content, you can use a tool like responsive.is to preview your page in various screen sizes. The Open Framework theme, which is at the base of the Drupal 7 theme stack at Stanford, will provide (soon) a useful block order overlay tool which tells you the order of hierarchy of blocks placed on a page. You can use this ordering to better understand how your content will shift when it is reduced down to a mobile screen size. If at all possible, it is best to consider a mobile first approach when creating your page layout—think first how your content will appear on mobile, then work your way up to desktop screen size.

Thinking of your content first might be a bit more work, but the results are worth it—a website that is driven by audience and a design that truly supports your communications goals.

For more information about responsive web design and how you can implement this in your Drupal site, check out Brian Young and my BADCamp 2012 presentation, "A 'content first' approach to designing responsive Drupal layouts using Twitter Bootstrap," or connect with us online at http://openframework.stanford.edu.

Photo of John Bickar Posted by John Bickar on Friday, December 14, 2012 - 11:42am

In December, 2011, we released the Stanford Courses module for Drupal 6. This is a Features-based module that polls the XML feed at ExploreCourses and creates Course and Course Section nodes on a Drupal website.

Taking PWR 1AT: Writing & Rhetoric 1: A Mountain for Itself: The Rhetoric of Wilderness as our example, the Drupal Course node contains information such as:

  • Course title: Writing & Rhetoric 1: A Mountain for Itself: The Rhetoric of Wilderness
  • Number of credits: 4
  • General Education Requirements: Writing1
  • etc.

The Course Section nodes are the individual offerings of that course, including such information as:

  • Instructor: Todhunter, A
  • Dates and times: Tues/Thurs 1:15 - 3:05PM
  • Terms offered: Autumn, Winter
  • etc.

Initially, the concept was to import all Course and Course Section nodes and create CCK Nodereference relationships between them (Drupal 6).

After using this module for several months and deploying it in production on several sites, we have realized several limitations with this approach:

  • When a course section is deleted on ExploreCourses, it is not deleted on the Drupal site
  • When a tag is deleted from a course on ExploreCourses, if the course was previously imported to your Drupal site with that tag, it will retain that tag

In short, data that is removed on ExploreCourses will be retained on your Drupal site.

Because course sections are volatile and subject to change, we have added a field on all course nodes that links to the course listing on ExploreCourses. Users are encouraged only to import course information and refer to the listings on ExploreCourses for up-to-date section information.

The Drupal 7 version of the Stanford Courses module currently does include a Course Section content type and associated importer. However, due to the limitations described above, the Course Section functionality will be removed in future versions of the Drupal 7 version.

Special thanks to Stephen Shireffs and his team in the Office of the University Registrar for working with us behind the scenes to get a working course importer.

a face for radio Posted by Zach Chandler on Wednesday, December 12, 2012 - 3:53pm

In my role as Web Strategist, I enjoy a privileged perspective on the state of the web industry in higher ed. I get an inside look into the new methodologies employed by some the best agencies in the business. Agile project management is a growing trend, and one that different vendors employ in different ways: some scrupulously follow the Scrum method and all of its rituals, while others prefer a “hybrid” approach. In this article I gather some of the lessons learned from some of the largest web development projects at Stanford over the past year, in the hopes of sharing them with others that are about to embark on their own projects.

What is Agile exactly? At its core, Agile project management means that work happens iteratively, and that the Product Owner (the client) has the ability to change directions, and doesn’t have to define everything in the beginning.

This all sounds pretty wonderful right? Well, it can be. At SWS we are using some Agile methods in our in-house development, as well as in vendor projects. This has been incredibly effective for our team, as Agile has the ability to stand up prototypes very quickly, and therefore at a reduced cost.  When the machine is working well, communication channels are established, and everyone knows their role, Agile can yield incredible results.

In other cases Agile doesn’t work very well, and it often comes down to the client, their culture, preferences, and customary way of working. On the vendor side it requires an expert PM and careful monitoring of budget burndown.  A lot of things have to go right. So, does Agile work for web projects at Stanford? Will it work for you? Maybe not. One important part of Agile development that takes some getting used to is that there may be no firm specification at the beginning--the requirements take shape over the course of the project, and can change based on evolving needs. At Stanford we typically do not use pure Agile for web projects, in part because of institutional preferences and ways of working.  Even when we engage in Agile methods (mostly we use Scrum), we have an endpoint in mind, and a set of requirements articulated at the end of a Discovery phase.

Minimum Viable Product

A key concept in Agile development is Minimum Viable Product (MVP -- the nature of which is pretty evident in its name).  MVP is a barebones version of the project, a prototype that includes all the must-have functionality.  If the Agile process has gone awry (due to miscommunication, excess communication, etc.), MVP is all we will have at the end of the project.  If the Agile project has gone well, we will have MVP very quickly, and many rounds of subsequent improvements. In a recent project with SWS, we engaged with a vendor in a T&M (Time and Materials) contract that spanned a maximum of 10 weeks.  The team was very efficient, with clearly defined roles; we got to a functional prototype in the very first sprint (!) and we essentially reached MVP in the very next sprint (in this case sprints were 1-week long).  
Bottom line: we achieved what we set out to do using only 20% of the allotted budget.

Ugly First, Pretty Later

A Minimum Viable Product is, well, minimal.  Agile focuses on building a rough version as fast as possible, and then adding more and more each sprint until we have a polished final product.  The website will be ugly for a while. This is normal. Your developer will be focused on the underlying content and data structures--content types, taxonomy, user roles and permissions--and pretty doesn’t usually make it into the first sprint.  It’s important to know that from the outset.

Working with a barebones prototype and incrementally improving it can be a challenging proposition for clients because it focuses on what’s under the hood first (which is harder to appreciate), and the visual layer comes into focus gradually. This is especially challenging when we need to communicate progress to higher level stakeholders--which we should always do.  For this reason, Waterfall methods, in which a discrete design phase precedes development, often make more sense for institutions like Stanford.  The challenge is to discern why Waterfall works better for client communication, and borrow what we need from it.

What Works for Stanford

Regardless of the project management methodology employed, getting stakeholders on board with the direction the project is taking --in particular the creative direction-- is vitally important.  Project leads (cf. Product Owner) are typically empowered to make all the decisions in the development of the project, and approve invoices, which can make it challenging to know exactly when we should check in with the higher level stakeholders on whose behalf we are acting. At minimum, I recommend that we seek signoff from stakeholders for visual design, which tends to be a component that generates a lot of feedback, and people tend to get more involved around page comps.  There are other key moments that might also be good to gather feedback (such as final wireframes, and style tiles) but comps should be shared at minimum … and here is where we can start to have problems with Agile.  

Agile projects might not even produce comps at all, and some shops have begun “prototyping in-browser” rather than wasting time with lo-fi wireframes or hi-fi HTML prototypes. For client communication and signoff, we need to take a page from the Waterfall playbook. Even if the developer is prototyping in-browser we still need some form of visual to share with stakeholders for their feedback.  In the event that your Agile process skipped these shareable artifacts, we still need to come up with something portable to circulate (likely via email).  A jpeg screenshot of the site (assuming that it has crossed the ugly->pretty threshold) will suffice. This may seem backwards to some, but experience shows that a jpeg comp is an important communication tool for Stanford clients (and I would wager for many other institutions and clients in other verticals as well).

Be Careful What You Ask For

The Product Owner of an Agile project is empowered to change or refine direction at the end of any given sprint (an intense period of concentrated work, usually 2 weeks in length). That is awesome. It’s also dangerous.  Most projects have fixed budgets, and we have to be very mindful that for every new feature that is added midstream--each sprint spent on researching the applicability of that new javascript library that didn’t exist at the start of the project--those are all billable hours, and we are choosing to give up something else as a result.  For this reason, Agile projects cannot be beholden to a specification that was minted at the outset.  Product Owners must know that they have to exercise their powers of prioritization judiciously.

Summary: Lessons Learned

  • Formal agreements, formal process structures are important.  Vendors that have well established PM structures and habits tend to be the most reliable on Agile projects.  However, if they use terms like “Agile-ish” or “hybrid agile” it doesn’t mean that they don’t know what they are doing. We have to dig deeper, there is no litmus test.
  • Stakeholder Signoff Plan. Have a plan for how you are going to communicate with stakeholders and keep them in the loop at an appropriate level.  Avoid design-by-committee. Luckily everyone thinks that is a bad idea … even committees.
  • RACI Responsibility Matrix. In a recent project SWS was able to hit the ground running because we drafted a formal responsibility matrix that eliminated the possibility that anyone wasn’t clear on who was doing what.
  • Fully sized and ready backlog. Scrum projects work by atomizing work into user stories that reside in a backlog, and are prioritized by the Product Owner.  If the stories in the backlog have not been properly “sized” by team consensus, you may have a problem on your hands. Insist on a “sized and ready backlog” if attempting Scrum with a new vendor.
  • T&M is okay so long as there are checkpoints, and only for trusted vendors
  • Burndown charts are an important way to make sure that we are not surprised by a budget shortfall.
  • Project Managers are the most valuable resource for overall success, and really great PMs are hard to come by. If you have one, hold on to them! The best ones not only keep everything moving smoothly, but also provide pushback to clients when needed. At Stanford we don’t like pushback, but we need it.  

So, is Agile right for Stanford? Yes.  Assuming that Stanford clients go into a vendor contract with a clear idea about what it means to be part of an Agile project, are fully cognizant of the hazards, are working with a trusted vendor, and have a plan for engaging stakeholders, Agile is an efficient, cost-effective, and fun way to work. It is also worth noting that the Waterfall method is still relevant, tried and true, and is proven to work well at Stanford, so not every project should use Agile.  We are fortunate to have a number of excellent web vendors that are sensitive to our needs as clients, and can adapt their process to help us build the next generation of web experiences for our users.

Sara Worrell-Berg Posted by Sara Worrell Berg on Monday, December 10, 2012 - 4:06pm

In late September 2012, Stanford Web Services (SWS) reached the one year milestone. We took this opportunity to reflect on the past year - our successes, failures and lessons learned - including:

  • We recruited seven top-notch staff and an intern, offering a combined 65 years of web experience.
  • A close collaboration between teams in IT Services and University Communications resulted in the launch of Stanford Sites, a robust Drupal-based content management platform freely available to Stanford departments, groups, and individuals. In nine months, nearly 600 sites were started on the service.
  • SWS worked with clients and partners from all areas of campus on over 27 projects, ranging in scale from vendor consultations to full planning, development, training, and support.

SWS is building a service with empathy for the community we serve: our faculty, students and staff who become our site owners, editors, developers, and visitors. Stanford Sites offers major strides for university websites in supporting accessibility, mobile responsiveness, and a polished, consistent identity. It's off to a great start, and our highly motivated team and valued partners will continue frequent improvements to the platform and our methods for delivery, training and support.

What's next

Now that our second year is underway, SWS goals include:

  • Streamline the basic website development process through features-based development and agile methodology.
  • Grow capacity through augmenting SWS staff and forming strong partnerships with select vendors.
  • Expand Stanford Sites with new reusable features and data integration.
  • Encourage a strong campus web community through events, knowledge-sharing, and training opportunities.
  • Design and develop more websites with clients.

Our goal is simply this: efficient, reliable service and open collaboration with our campus community. With your help, we're on our way.

On behalf of Stanford Web Services, thank you all for your encouragement, support and collaboration. Please drop us a line with your ideas, suggestions, links to your Stanford Site, or questions. We'd love to hear from you!

Posted in:

Pages

Subscribe to Stanford Web Services Blog