L’Open Source Drupal et Acquia pour la Stratégie Digitale des Administrations Publiques [October 9, 2012]

Harmonious Development: Standardizing The Deployment Process via Vagrant and Puppet [October 4, 2012]

How to Use Drupal 7 to Meet Your Accessibility Goals [September 27, 2012]

Click to see video transcript

Hannah: Hi everyone. Thank you for joining the webinar today. Today’s webinar is “How to Use Drupal 7 to Meet Your Accessibility Goals with Mike Gifford from OpenConcept Consulting. I’m Hannah Corey. I’m a Marketing Specialist at Acquia.

Mike: My name is Mike Gifford as Hannah said and I’m a Drupal 7 and 8 Core Contributor and I’ve also been active in accessibility space having organized some accessibility end conferences or accessibility conference. I’ve also contributed a section to the definitive guide to Drupal 7 for accessibility so that was a nice thing to have the largest and most comprehensive Drupal book to also include the section on accessibility. I’m also the president of OpenConcept Consulting and I’ve been working with Drupal now for over seven years and I’m happy to be part of such vibrant and dynamic community.

I’d like to talk a bit more about, specifically, what are some of the goals that we are looking … What are we talking about when we’re talking about goals and alternative of trying to use Drupal 7 to go up and to accomplish that? It’s important to trying to find what that is. Of course, everyone would like to have a barrier free implementation for the website that is completely universally accessible to everyone that follows the principles of universal design and progressive enhancement and these are definitely worthwhile things to try for.

There is no complex website that is 100% accessible to everyone so there’s an element right now where because of assistive technology and the pace of change in the internet, there’s nothing that's perfectly accessible. There’s a lot that being done to move in that directions, standards and guidelines to help evaluate accessibility, but there’s nothing that’s completely universally accessible. One of the things that...one of the guidelines that’s available is the Web Content Accessibility Guidelines,the WCAG, and this is part of the worldwide web consortium.

W3C is involved in setting up all sorts of standards for the internet and it’s really critical institution for looking at and defining standards for the internet. They released, in December of 2010, they released WCAG 2.0, which is right now seen as the standard that people are looking at for accessibility internationally. There's also a number of draft standards that are being released that are worthwhile to consider and one of them is ATAG, or the Authoring Tool Accessibility Guidelines, and ATAG is still in draft but it’s...anytime you’re dealing with a content managing system, you have to worry not only about how the content is viewed from the user’s perspective but how it’s generated as an author and is it the tool that can, as an authoring tool, also go off and meet the same level of accessibility guidelines.

Finally, section 508, although Section 508 itself is one of the oldest internet standards for accessibility. It was initially published in 1998, and it is in a process of being refreshed and we’re very hopeful that in the next year or two, we’ll see a release of that that is able to keep up with and perhaps, we can exceed the standards set by the international community. Those are some ideas about goals and what is possible within web accessibility, and it’s important that this is something that we do work to establish this as more than just a lip service towards accessibility. That we need to look at what are the practical implementations and what are the practical approaches that we can do to achieve that. A lot of people in their publications and promotions talked about accessibility, but often, that’s more of a sale side than a practical on the ground. This is what has been done and tested and this is what we know worked for people with these disabilities.

I’m not sure what the status is of everyone who is in the call, but I wanted to enhance and talk a bit about the cost of the internet and the internet is constantly evolving, and this isn’t new for anyone here I’m sure, but I’m trying to understand both the clients that the users are using for whether it’s Firefox or Opera, or Safari or Internet Explorer. All of those tools are changing on a regular basis, so are the assistive technology devices that are being used.

If somebody is using a screen reader or is using a plugins tool to enhance the accessibility, these are tools, which change on a regular basis. Likewise, the demands of the internet and demands of what your website are, are constantly going to be changing, and there’s going to be new expectations for client deliverables and what matters as your site is being implemented. Even the software within that is changing on a regular basis as you’re keeping up with Drupal upgrades, and ensuring your site is secure. There may be changes within the code that is accumulated in Drupal, wherein the underlying infrastructure of jQuery or even how Apache is potentially dealing with requests that are changing.

You’re not dealing with the static implementation, and so there’s a need to constantly go through and look for barriers, and look for ways to find ways that your users are being limited too to access on the website. I would encourage people to look for feedback from the users and to elicit information and directions in terms of what's possible, and also to schedule a regular accessibility review. If you’ve done a full audit of your websites, then in six month’s time, it’s important to go up and look at a gate, and look at how, not necessarily doing a full audit, but to look at your website to find the ways to improve the process.

The best practices are changing and there's a lot of dialogue and discussion about what is the best way to approach things, especially when you’re trying to implement something like a responsive design, or you want to be able to even just add any feature like that, a slideer on the front page or something like that, that allows people to have a more interesting visual presentation for your front page. If you’re approaching and upgrading, you’re able to go up routine to look forward and to work with community, then there's always ways to improve and to constantly make your websites better if you’re working with the community of users and developers around the world.

It’s important to plan to go out and see that your website is accessible, and Drupal is a complicated system and accessibility itself is quite complicated. If you’re looking to implement an accessible implementation of Drupal, it’s important to try and leverage what expertise is out there and to where possible eliminate the unknowns. There’s a lot of modules that have some evaluation for accessibility and have some reviews or patches that improve the accessibility of them.

There's certainly places where there are problems that are known and also places where we know we’ve addressed the issue. If you can work with these known elements and read up on the board set that has been done to improve accessibility; that will certainly help a lot. It’s also important to try and contribute back to your changes. You’re going to find things with your users that are going to be ... that maybe something that others in international community have not yet identified. So if you you have an audit done on your website and the person doing it identifies that there's a problem with one particular widget It's useful to go up and to contribute, even those problems back, so that we can work through and try and resolve them as quickly as we can.

I wanted to also talk specifically about this in terms of WCAG. WCAG has a structure of their guidelines called POUR, that all of the information must be perceivable, the website must be operable. It’s important that it also be understandable and finally robust. There’s quite a lot of documentation available on this, but I wanted to make sure that people had a basic exposure to that as well.

Drupal seven has a lot of codified best practices built into it. We’ve done a considerable amount of work in about a three-year period of time to find issues and problems and to fix them in Drupal seven, and also to think beyond a single site implementation to try and say, "What can we do to see that we have a solution that works well for everyone?" I see that a lot of what we’ve done in Drupal seven has a lot of best practices, that if you just follow what is in core, you’re going to have a more accessible website, than not in many cases. When you’re working on developing Drupal that's of course an obvious example of where to look for, for example on how things should be done and how things should work.

One of the great things about core that Drupal Core has built with, there's a lot of information or APIs application processing interfaces, so that you can access the information and be able to organize its potential ways. That’s quite useful as well. The things are centralized and modular so that improvements in Core will propagate out to other pieces to your web setting.

There's also really excellent international communities that meets on a regular basis. There was a sprint earlier in March and there’s another one being organized in November. We do get together and meet, and then look at ways of improving Drupal for accessibility and there's also a very vibrant issue queue as well as the discussion group that we'll provide both of those at the end of the presentations.

Finally, one of the great things that we’ve accomplished in Drupal seven is the ability, not only to publish content that's successful but also to be able to administer the website in a way that is accessible. A blind user can install Drupal, can maintain Drupal, and can add content to Drupal, administer Drupal, and also read the content from Drupal. That operative is seen as a huge issue, but as websites become more interactive, the distinction between what is an administrative piece and what the user piece, they get kind of fuzzy. You may want to have a dashboard available to your users, you may want to be able have a discussion forum where they’re able to log in and have to have access to pieces of Drupal that are, within many cases would only be available for the admin users. It’s really useful to have the flexibility to know that the administrative pieces of the website has also been tested for accessibility and for the most part, had those barriers removed so that people can access the website.

I wanted to talk about some of these specific victories that we’ve brought into Drupal seven and ways that this can help you maintain your website in the future. The first one that you may notice if you’re needing to install Drupal is that there's a Skip to Main function that’s part of all Core themes. This is a great best practice for people who are keyboard only users or people who are blind and use a screen reader to navigate the website. What the Skip to Main section does, is it allows you to jump through all of the navigation that's generally part of a website and get right down to the content. It’s a great way to skip the navigation and get to the content and this is something that's also part of the admin themes as well that come with Core.

One of the issues in Drupal six that became a problem was the drag and drop, and drag and drop is a wonderful functionality that has a lot of – a much nicer user interface for people, but we had to go off and create a work-around so that we could more evenly and intuitively make it so that people who could not use a mouse were able to easily drag and drop the content and have the direct access with content, and to the administration of content rather. There’s also work to go off and improve the semantic markup in the breadcrumbs and the list, things like ... just trying to make sure that especially as we’re dealing with smarter assistive technology, the more semantics you can provide to the market, the better they ... to the assistive technology, the better they can interpret that and provide tools to help the ... or to assist the user in navigating the website.

We’ve also worked on improving the color contrast in the number of places and also added the area support. One of the tools or standards that W3C is building now is the web accessibility area, the Accessible Rich Internet Application Support. It’s nice way to build in more semantics, particularly when you’re dealing with dynamic content, so content that’s changing as you’re clicking on the website. More and more websites are becoming more like desktops than they were, the web pages of even two or three years ago, the type of functionality that users expect, and the type of dynamic responses are so much more complicated than what they were shooting back in 1998.

Being able to present the assistive technology with semantic information that describes what has happened and how to engage and how to go up and to make the information that’s been presented with the user in a way that is meaningful to the assistive technology. It’s a great thing that we’ve started, and there's certainly a lot more than we can and will be adding to Drupal eight, but there’s initial implementations of area for both the auto complete and ultimately, installation pages in Drupal seven. There will be considerably more available in Drupal eight.

Another great tool that we’ve added is a consistent way to go off and to deal with CSS displaying; none or visibility: hidden. This is a well-known problem, and one that we’re starting to have some good solutions for now and certainly the HTML5 boiler place has a solution that’s very similar to what we’ve implemented in Drupal seven. The issue is that assistive technology interprets display: none or visibility: hidden literally, so it will not display the information that's there to a blind user.

You need to actually find a different way to make that information, to hide it off screen and to ensure that people who are ... people do not see the information but it’s available for screen readers. We created a class called element-invisible that allows for screen readers to do this, or that works properly, we've tested it, and this is a larger challenge that one might think, because there are only a few lines of CSS.

Finding a solution that works well and is something that can be implemented across the board is a huge challenge. The solution that we had implemented prior to Snow Leopard, but Apple put out a release of its Operating Systems that destroyed the functionality that we’d implemented before, but simply even creating the class name .element-invisible, and standardizing on that was a huge move for Drupal seven, because it means that even if you want a different approach to how we implement this, you can just override that, but everyone who is ... all the modules and themes have a consistent way to name their information, to hide information off-screen and also to make sure that it’s visible on focus.

That’s like the Skip to Main link that shows up in the themes is one of the pieces that uses the .element-focusable, and there’s other elements where you would want to hide them unless a keyword only user is navigating to that particular element. Finally, there needs to be clear way to go up and hide it to make sure that it’s not presented to anyone, so that's the .element-hidden that’s available there. This will also be supported into Drupal eight, but we are changing the names a little bit. It'll have the same functionality but probably have a slightly different name space.

Another, we’ve done a considerable amount of work is with the Form Elements, and this is a huge challenge for a lot of sites that need to be accessible because so many web forms are not very accessible. The biggest way that they fall down is that there is not a direct link between the description of the input field and the input field itself. There’s no semantic tie between the two. We’ve added a title to ensure that it is with... We have a title setup so that there’s a direct link between the title and the label, so that
anytime you’re creating an input form that that information is setup and structured so that it's consistently convening over to the browser and that there's a semantic tie between the two. We’ve also built in control so that from a programmatic point of view, a developer can associate a label before, after, or make it invisible so that it isn't something that is going to necessarily ... that consistently to hide that information from the screen, but also make sure that it is all hidden from the screen, but it is available for users to be able to ... for an assistive technology to be able to read the information. This is all part of the Forms Application Programming Interface.

Essentially, all modules, and if they have a form associated with it, will use the Forms API to create them, so by addressing things in Core we’re able to go up and to address them in the application. There’s also work that we’ve done in the forms to ensure that there are more headers and greater semantic information associated with the form's interface, so it's easier for people to navigate, or especially for blind users to be able to navigate through the interface.

We didn't fix everything in Drupal seven and we won't fix everything in Drupal eight, as this is a continually evolving process and there is always going to be changes and new standards and new things that need to be addressed. If you're aware with those problems are, then you can look for it and design ... You can focus your efforts and attention on either avoiding them or focusing your programmerss on implementing solutions that will help get around that. In some cases, the problems that have been identified in Issue Queue already have patches for them, and they have a patch that you could apply back from Drupal eight to Drupal seven or that you could go to the modules that will allow you to take the ideas that are discussed in Issue Queue and bring into the application itself.

One of the problems is fieldsets, and complex forms. One of the issues with the complex form is you need to have something to bind them together, and the approach that is recommended is to tie them into a fieldset so that a phone number, if you've got an area code, a phone number and an extension, if those are in three different input forms, that those are bound together and that there's a label associated with the fieldset to explain what it is those different elements are, and that this is part of a group.

Likewise, dates are something that are often not dealt with properly, or if you've got ... if you have even an X and Y coordinate, you want to go up to express. If that X and Y coordinates are in two boxes to graph for accessibility, that should be wrapped in a fieldset. Unfortunately in Drupal, I'm not sure when it came in, but certainly since Drupal five, a lot of the collapsible elements have been done with fieldsets. Fieldsets have been used inappropriately in the past, and we’re hoping to go out to turn fieldsets into details in Drupal eight and address that particular issue. If you’re looking at moving your site to the HTML5, that is worthwhile to look forward to.

There's also some uses of HTML or other implementations like labels were used inappropriately in some cases and now we’re going through it and changing the HTML for that. We’ve addressed most of the issues where labels were used, but there still are some outstanding issues, and you can use the tool like WAVEY. Those will be identified and you’ll be able to see the user interface where label is used inappropriately. When form errors are being ... and they’re much better in Drupal seven than they were, but in terms of meeting AA compliance, and this is something -- this is a goal that the Drupal community has and we haven't been able to evaluate Drupal Core and verify that it does meet the AA standard.

There are some issues there, but we’ve made some dramatic improvements in terms of how error messages are displayed to users. So if somebody's filling out a web form and they hit submit ,a user, a blind user can navigate through that and can see that information, and be able to access the error messages, but they do need to be ... that does need to be improved. In order for it to be AA compliant, you want to ensure that there is a direct link into the issue or if somebody didn’t put in their name, that there's a direct link into or from the error message to the input form to allow them to add that information in.

Also, the publish status is something ... again, if you’re trying to go up, and to ensure that your website is set up for low vision users, there's ways to tweak Drupal seven so that the published status are in fact ... some Drupal themes do a better job than others in terms of marking up the published status, so that it's clearly visible what stuff is unpublished and draft versus what content is published, and the zen theme did quite a good job of that historically, and making sure that that was clearly visible but that’s not a hard thing to build into the theme.

There are also problems with the data tables.
If you’re looking to create data tables there in order to meet the guidelines, one of the things that is being proposed is that -- or one of the things that’s suggested is that there is a scope attribute added that clearly denotes when a header element is ... the header element has the scope of row scope colon. This is particularly important for complex tables.

For Drupal, most of the tables that are generated by Drupal are very simple and there’s very little accessibility advantage for the end user in terms of having this information in here. It's mostly a matter, trying to go up and make sure that the table data meets the guidelines so that it is following the best practices, and there’s a number of discussions on how to do this with both Drupal Core as well as the themes. That’s another area to look at. In terms of comments, if you are unable to comment, one of the challenges is in terms of threading comments, and what is the parent issue versus the child, and sort of establishing that semantic relationship.

We’ve also made some improvements in international innovation that have been brought forward. But for organizations that need to implement a multilingual implementation, you need to have a way to go up and tell the assistive technology what language you're viewing it in. If your main content is English, that’s great. If you have a link to translate to French it should say Francais, so that the screen reader does not trying to go out and pronounce Francais in English. These are useful pieces of things that are going to be added. In fact, some of them have already been added for Drupal six. It’s trying to standardized and build the best practices into Core, and there's certainly a number of issues where we’re looking and working on doing this for Drupal eight that can be used as examples or a great resource for people who are needing to go off and to setup multilingual websites.

One of the challenges that is not just the Drupal, but of websites in general is one of Modal Dialogs. This is essentially switching back and forth between and popping up an interface underneath it. In Drupal seven, the overlays module is a great example. If you’re logging in to the website, and you’ve not disabled overlays, then it’s very difficult for assistive technology to be able to know where the content is and be able to navigate with overlays enabled. One of the things we’ve worked on is a way of ensuring that a screen reader user can disable Modal Dialogs, but if you have people who are content editors who are using the assistive technology, then that will be something that you would want to disable for them because they may not necessarily know that this is a problem with overlays. In terms of the solutions for this, in many ways this is an issue that have been brought forward to the jQuery community, and jQuery is a much larger community of users.

JQuery is used in so many different content measure systems and also for proprietary or custom built web applications because it’s a really powerful JavaScript library. There’s work to go up on, and to be able to fix this you need the latest version of jQuery to bring that into Drupal eight, so that’s something that we can have addressed and have a common way to go up and address, switching the content and switching the focus of users between the pages of you now and to a particular element that they want to be able to access or edit.

I want to talk briefly about best practices now and to talk about things I've mentioned. Having regular reviews for accessibility is quite useful. and I really like the WebAIM’s WAVE Toolbar. You probably can’t see it very well here but there’s a link here for the main Acquia webpage, and I use this as an example of one that all of us will have probably seen having gotten here. If you use the WAVE Toolbar to evaluate a website, you can see areas where accessibility can be improved.

A red mark in many cases will indicate that there maybe there's a missing input form or maybe there's a label missing or maybe there's a heading or something that looks like a heading but isn’t marked up as a heading. It’s a great tool to go off and do a quick evaluation and grab the low hanging fruit. It doesn’t give you everything. None of these tools ... no automated tool will be able to effectively cover all of the accessibility challenges that you need to evaluate in order to make your website AA compliant. It does capture the low-hanging fruit and it’s really important to keep that in mind.

It’s also important to look at training your content owners. Your content owners are -- if they’re not writing good content that's well-structured and it has all text in it, it doesn’t matter how much you’ve spent on building a great framework, if it isn't implemented with the content owners keeping in mind accessibility and using tools like this, or there's another great one called -- a simple tool called CSS Home that basically use just CSS to alert the content owner if there is an accessibility, if there's alt tags missing, if there's use of an attribute tag, there's all kinds of things that can be done and highlighted simply with CSS if the content owners are educated about this, and there’s also growing tools like the Quail Library to do some basic accessibility auditing before a page gets launched.

Again, it requires training for the content office to go up and to have more awareness about accessibility issues. I definitely recommend getting an audit from a professional web accessibility individual, because there are things that you’re not going to be able to see that they are, so if you can look at it ... get somebody to give you feedback on your site from a professional perspective and give you places for improvement, it would be extremely useful. There are not enough websites out there that are actively going out and trying to reach out the users and to get the feedback from the user community, to see if there are any problems or barriers for the users.
I know that we haven’t done enough testing for people who use Dragon Naturally Speaking.
This is an area that if there are people on this call who have done testing or done work with people who have severe mobility issues and need to navigate by voice, the Drupal could probably use a lot of help because we don’t have access to enough people who are working to get access, to navigate the web in this way. Whenever you discover accessibility issues and whatever problems you run into, if you're able to contribute those back to the community, it will help a lot of us to build solutions in the future that address that. This is an ongoing issue, and if we can find the problems and address them in Core or contribute modules, will all be much further ahead.

There’s a lot of continuing work being done in Drupal, and those people who are using Drupal seven, there are 14,000 Drupal modules out there, and you're not using all of them but using a handful of Drupal modules and themes to go up and to build your websites. Many of those may have accessibility problems, and they would inherit things in Core, but they can always be overwritten by the module Maintainer. Almost all elements that we’ve worked to go up and to build into Core can be overwritten, and certainly if people are upgrading websites or modules from Drupal six to Drupal seven, they may not yet have updated their site to the new server or the accessibility standards that have been adopted in Core for Drupal seven. That’s an area that does need attention and you can look in the Issue Queue for any of the modules you use to see what are the accessibility issues that are there.

The ability to tag issues with the tag accessibility, so you can again look for modules that have been tagged with accessibility problems, or in Drupal Core there's also needs accessibility review. There's work done on Drupal eight as well, and in Drupal eight we're bringing the entire interface up to HTML5, and we’re also building Drupal so that it is responsive by design. All of the themes from Core will be responsive and flexible for mobile users. That’s again a huge improvement but it does require testing and evaluation to see how well it’s going to work for users in terms of ... too often people need to go off and added a new mobile theme.

They decided they want to add a mobile version of their website, and forget that it has to also be an accessible version of their mobile site, that in many cases the accessibility guidelines that are available for the main public website, also apply to the mobile website and it’s working with Drupal seven and in the future with Drupal eight, you'll have the confidence that a lot of that has gone through a consistent testing an evaluation to identify and address problems that have come up.

We'll need to have ... When ATAG 2.0 is released, it’s still in draft, and Section 508 are settled, we’re going to need people to review based on that as well, and to look at it and see if there’s ways that we can improve those, and if there’s a way that Drupal needs to be additionally configured in order to meet Section 508. Yes, that will be a challenge when it comes up, but we've made a solid ground work for this implementation so it should be easier for us to go up and to also address those issues. There’s a lot of work that’s being done on accessibility for CQ editor, BU editor and Aloha editor, editor have that fronts with a lot of work on addressing accessibility issues. Those are all part of -- the prominent parts of Drupal seven and eight.

Finally, I wanted to go off and to talk a little bit about the Drupal seven Web Experience Toolkit. This is something that we may be offering as a feature webinar. There's a limited organization that are working together and collaborating mostly governments, but not entirely. The Government of Canada, and University of Ottawa and the City of Ottawa are all collaborating together to go up and build a distribution of Drupal that has a lot of accessibility and usability components built into it. This is something that is going through quite a lot of testing and building on a framework that has been established by the Drupal community, but it’s something that we hope to involve more people who are looking to set up accessible websites, but also people are looking to build multi-lingual websites as well. With that, I'd be happy to go off and entertain questions, and to talk more about ways to get involved in the Drupal community and to address the accessibility issues in the future.

Hannah: Okay, great. Thank you. We have a couple of questions for you. The first is where is the best place to add area landmark in page pcl.php.Javascript or other? Can we attach an area landmark to a region?

Mike: Mostly it depends on whether you wanted to be validated by the ... the reason why people have been adding area in JavaScript is because the W3C validator has had problems with it historically, and I would suggest that the best place to add it is at this stage, in the page.pcl.php file. We weren't able to go up and add it historically into the templates for Drupal because we wanted to make sure that it was something that was going to validate when people went through the W3C. That was why it wasn't added.
There's also elements where the accessible helper module goes and adds them also in a block layer. That’s another space where it’s useful to add area landmarks, is with the blocks that are moving and migrating within the sites. If you can identify those programmatically -- or not programmatically. If you can identify those and expose that information, it helps out considerably. I would say, yes, those are the two places that I would look to add area landmarks.

Hannah: Okay, we have more questions. If I understood correctly the tool will become more linguistically diverse?

Mike: Drupal itself? The Drupal is already quite multilingual, and in Drupal six, the ability to have multilingual sites was brought into Core. It needs to be enhanced, so that you need to have additional modules to make that happen, in terms of a fully functional website, but the Core elements that were brought in Drupal six, they’re also part of Drupal seven. In terms of making it accessible, there’s extra elements that you need to do in order to be able to convey to the user that the language has changed.

To make sure that they have dedicated elements that show up in alternate language ... the most common instance for this is, if you have a website that is primarily in French, and somebody is trying to navigate that website in French, and there’s a string which has not been translated and it shows up in English. The screen reader will try to read that English screen in French, and if there isn't a default means to go up and to convey to the screen reader that the language has changed it won't know how to interpret that text. Did that answer the question?

Hannah: Yes, they didn’t specify anything else. There is one more question that just came in. What themes would you recommend for accessibility especially if you’re getting started with Drupal?

Mike: There’s a couple good themes I would recommend and certainly the Core themes are quite good in this, and has gone through some evaluation. Jeff Burns' is adaptive theme, is the one that we’ve settled on, and that has also brought its way into the web experience toolkit distribution. That’s another great base theme that we recommend. Jeff has been quite involved in the accessibility efforts around Drupal seven. The Zen theme is also a wonderful framework and John Elton has done some terrific work there as well. Particularly, in trying to look at simplifying and streamlining the CSS components, and we are really happy to go up and see the adoption. It’s definitely something that we’re very happy about, happy to see that there’s now a standard, consistent way to be able to programmatically code CSS, which historically is often a bit of a mess.That will have advantages for accessibility, and then also for performance as well. Those are the two main things that I would recommend for accessibility.

Hannah: Okay, great. I think that’s it for questions. Thank you Mike for the great presentation and for answering these questions for everyone. Thank you everyone for attending. Again, the slides and recording on this webinar, will be posted within the next 48 hours and sent to all attendees via email. Thank you.

Agile Desktop and Mobile Content Authoring with Spark [September 26, 2012]

Increase B2B Engagement Rates with Personalized Web Experiences in Drupal [September 20, 2012]

Integrate and Take Action on Real-Time Chartbeat Data for Your Drupal Site [September 18, 2012]

Requirements & Drupal: Planning for Successful Projects [September 13, 2012]

Click to see video transcript

Female: Hi everyone. Thanks for joining the webinar today. Today’s webinar is Requirements & Drupal: Planning for Successful Projects, with Jon Riekse, who’s Director of Business Analysis and R.J. Townsend, Manager of Drupal Solutions at NavigationArts.
R.J. Townsend: R.J. Townsend with NavigationArts. I have been working with Drupal for about six years now and working with NavigationArts for about a year. I lead the Drupal practice here and a small team of Drupal developers.

Jon Riekse: Hi. My name’s Jon Riekse. I’m the Director of Business Analysis for NavigationArts. I’ve been a developer in the past. I’ve worked with Drupal for about four years as a PM and a BA.
Thanks for everyone’s time today. I hope you really get a lot out of this presentation. I’ve been focusing just on requirements for about three years and I hope we have some good stories to tell, lessons learned from our requirements and build practice with Drupal here.
I’ll go ahead and get started. Feel free to ask questions through the presentation. We’ll try to respond as topics come up here.

All right. A little bit about NavigationArts, the market position, we are unique in the web space in the sense that we practice User Experience Design and Technology Consulting and really specialize where these systems and specializations overlap here as the diagram shows.

We focus on a user-centered design methodology that aligns business goals with user needs creating user experiences that drive enterprise value. We definitely take a user first approach as we think about requirements and then specifications.

The agenda for today is Requirements Overview. I’ll probably try to get through this pretty quickly, unless there’s a lot of questions concerning types of requirements, business user, etc. Then we move on to Requirement Types and Samples. Typically, when I’ve done this, a lot of people are most interested in the sample of documentation of requirements. Then R.J. will talk a bit about Translating Requirements to Specs and Dev and we want to talk a bit about the iteration between these two activities because that’s where you really get the most out of Drupal is aligning to what Drupal does best. Requirement Activities, Drupal-specific Requirements, the Business Analysts … sorry, (laughs) Analyst’s Role in Drupal. I should know my title now. It’s a maturing role. I think in the web space, they started to pop a bit four, five years ago and I think they’re vital so I’ll talk a little bit about that. Functional Re-use and then Requirements, Contributing back to the Open Source Community.

All right. Requirements: What are they good for? A lot of baggage around this term, kind of a lot of people think bureaucracy. I’m going to write stuff down. I want to build something already. What are we doing with all this paperwork, right? We’re developers.
The second bullet there is describing something complex should be easier, faster, and cheaper than actually building it when using the appropriate level of abstraction. It’s about the right level of detail. It’s also about the right people giving the right input at the right time. If we’re planning a big design and the approvers of that design aren’t involved early, well, you might go down the road a bit before you realize you have to change that and its significant impact to the rest of the project. Same thing with critical requirement, architecture decisions, try to get the right decisions made early.

Promoting mutual understanding, this is a big part of my job. Typically, you might work with clients or you have business stakeholders who don’t know a lot about technology. You need to talk with them and make sure the expectations are aligned about what you’re going to build and they know what they’re going to get out of the project. I see this as 75% communication and 25% documentation. The requirements should be the product of communication, not the means. Samples and the actual deliverables are extremely important and that might be why you’re on this call. You might have an upcoming deliverable you’re working on, but communication is really key here so I hope I get that across throughout the presentation.

Keep the docs interesting, meaningful and digestible, and productive, a means to explain and educate. This is the challenge. If you come out of a project with 100-page word doc that’s mostly text, you typically are not going to get a lot of response to it. It’s just too large. Diagramming is really helpful, modeling, and any visuals you can put in there. I have some examples here.

All right, The Case Against, we don’t have the time or budget to document requirements. Well, when something’s not what people expected in the development and you’re changing things, you don’t have the time for that either.

Seems like too much paperwork, let’s build something already, definitely understand that.
Our project is too small to necessitate requirements. My case against that is just do a couple pager. Do a two-pager if you need to. Just outline scope and the detail where you need to.

Our project is too large to necessitate requirements. We will never know everything until we start developing. Related to that is we use agile. Around that, but the view we take, we do waterfall. We do agile. We do a lot of hybrid methodologies, but when we’re thinking about the user experience, we kind of need to back up and get the big picture of what the website’s going to do to really architect, for example, high-level site map. You need to kind of bound and understand the whole system and especially from an architect standpoint.

If you’re using agile, I’d say start with some high level requirements. Understand all the scope. Understand kind of at a high level what you’re doing and then drill in as you’re doing each spread as needed if that’s the approach you’re taking.

All right, Case For, taking planning seriously, adding some formality, mitigating risk. Mitigating risk is really what a lot of this is all about, aligning expectations. For some of you, if you’re in an agency, sometimes you have to meet the formality of your clients and stakeholders. Maybe you’re doing a defense contract or something for the government and you might need this documentation just to kind of not only give them the door, but to keep the project on track and keep everybody agreed on the progress and formality of the project.

Question real quick about agile and contracts, how do you get the customer to embrace an agile delivery contract? That’s definitely I’d say an important question. When you’re contracting and scoping, a lot of the reason waterfall is so still common now and the kind of agency contract space is because you’re saying this is exactly what we’re going to do and this is how we’re going to do it. You’re getting approval, gate keep so you know you’re not moving onto spec ‘til requirements are done or ‘til visual designs are done. Agile can be a little hard because it’s about changing priorities and adjusting as needed and that is contractually hard to do. Joseph, maybe we can take that at end. That’s definitely … maybe you need a longer answer there.

All right, the second bullet point on this slide is it doesn’t assume we are talking about the same thing or speaking the same language. This is what can bite you if you don’t write things down is you’re doing a lot of talking and you think you agreed with the client. The client thinks they agreed with you, but yet at the end or when they first see a prototype or they first see completed code, it’s not what they expected. The documentation is the risk mitigation there.

Leaving a paper trail, a lot of what I do can be about consolidation, organization, and hopefully, clarity. If any of you have experienced I have an inbox and that’s all I have and that’s my documentation. It’s pretty tough to manage, especially with a multi-developer team.

Describing and agreeing to the end state before it’s done, definitely important for scoping.
Agreement to the outcome, how do we know when we’re done? In the quality assurance phase, how do we know when we’ve met the requirements and the system is bug-free and we’re not talking about feature changes?

Then managing change, being on the same page as your project sponsors, your client. Really, really important when you talk about waterfall, we’re not in the day and age of nailing down requirements for six months and then building for six months without change. Change with websites can happen every day, every week so you need to manage that change. You can't always resist it. You shouldn’t resist it. You should figure out how to manage change, look at impact, and look at level of effort and communicate that in a straightforward and honest way to your stakeholders or clients.

All right, Requirements Overview. A requirement is a description of what the website will do and we can use shall statements or natural language, but this is the outcome we expect. It can consist of a text description, visual representation. It can be an annotated wireframe, design, model, diagrams, whatever it takes to get the point across.

A requirement document is a collection of consistent requirements. You can describe the same thing a few ways to ensure the client knows what you’re talking about. Consistency is huge. If you have … example I use a lot is maybe you have a wireframe with an advanced search link and that’s it. You don’t have the advance search documented. You don’t have anything around there. Your stakeholder might say, “Great. I can't wait to get that advanced search.” Really, it was just a link left in and that can cause a whole lot of confusion there.

The goal is to describe as precisely as possible what is to be built and giving more attention to the most complex aspects, where the highest level of risk can occur, using your time wisely. This is where I think it can get a little trick, too. You might want to describe that global header is going to be on every page or talking about global elements, and maybe a little bit too much. Really what you want to be focusing on is this advanced three-step form and what the job script’s going to do, what fields are required and what happens with business logic. Really focusing on the right pieces is key here.

Defining the boundaries of the website system helps avoid scope creep.
Around that, here’s a sample I have for an integration diagram and this comes back to modeling is important. I could describe this with probably a couple of paragraphs of text or a huge bulleted list, but I don’t think it would be as effective. This is how we think about initially bounding a scope of a system. I know I have this website here and on the left, I’m integrating with a database and a geolocation service. On the right, I know I have a social media integration that I’m dealing with. This is just a good way to look at the big picture and for everybody to conceptualize what we’re about to do here.

R.J. Townsend: One of the things that I would say as I’m working with Jon and helping to kind of map out how a diagram like this fits into Drupal and some of the both core and contrip modules that are available, that’s where I come in to requirements and I say, “Hey, we’re looking at this geolocation service. Well, there’s these modules available and these modules have these core components available.” I’ll talk to Jon about, “Hey, these are the modules that are available that’ll help you define your requirements.”

Jon Rieksi: Great. Yes. David has a great question, then I’ll get to here about requirements and technology agnostic here.
Here’s another sample in here. I know I have a CMS. Here’s digital asset management system I might integrate with, just another example of looking at the big picture there.

All right, Abstraction Ahead. All right, this is where (laughs) you can't get out of this unfortunately with requirements. We’re talking about abstract concepts, about an abstract system using language. Use pictures. Know your audience and your risks. If you have a stakeholder that doesn’t know a lot about say email versus RSS or something along the lines that’s a little more sophisticated, you might want to explain that and concentrate on that piece, if you’re seeing questions or some comments from your stakeholders where things don’t seem to be really jelling here.

Avoid documenting the documentation. Software tools will help you here. When you start having too many traceability matrixes, too many artifacts, it’s really hard to be flexible and be agile in that sense. Depending on what the scope is and the complexity of a project, be careful of that.

Use common sense. Trust your intuition over the correct way to document requirements. This is a practical exercise of getting from point A, starting a concept to point B, being done with a quality project. There’s a lot of ways to go about this and just use your common sense there.

At the end of the day, if it doesn’t make the project better, it wasn’t worth it, and quality assurance definitely starts with this initial work here.

All right, a little bit of types of requirements and I’ll talk about David’s question in this context. Typically, you’re going to start with the Business Requirements and I think of that as the why. This could be at the executive level. Why do we need a new website? Why do we need this new feature of the website? Why do we need to migrate to Drupal? Are we going to save money? Is it the staff we’re looking at? Are we looking to kind of gravitate towards an open source model in general for Enterprise versus for example Microsoft Stack. This is kind of why the project is funded and the purpose of it. Sometimes we will come in, we’re at the kind of agency level where we’ll come in. Sometimes this will already be documented and really fleshed out. Sometimes we come at the strategy to figure this out. What are the KPIs? Why are we going to look into a new website?

I put technical req next. This is really an overlapping process. I put it here because before we really get too deep into the next steps, I want the whole team to know what are the constraints, right? To David’s question, maybe we’re definitely using Drupal 7. That could be something that was made as part of the project or maybe we’re definitely going to integrate with the sales force system or maybe the whole project is about … it’s already figured out as about getting mobile users to interact with the website. I’ll talk about this, but technical constraints are really important at this point in the project.

All right, user reqs, who and the what, and then functional reqs are definitely the what and you get to a good level of detail of what you’re about to do. Here’s where I think being specific to Drupal, it’s really, really important as opposed to a completely custom map where it’s kind of greenfield is about this process of aligning Drupal and what it does best to the requirements and really educating the clients on what modules are out there and the level of effort in particular.

Around David’s question, good requirements can definitely be technology agnostic, but kind of as I mentioned in the technical reqs and the constraints, sometimes we come and we know it’s going to be a Drupal project already. I’m already in this mode of aligning the requirements to what is in scope and in budget for Drupal. Maybe it’s not completely the kind of rulebook about how to do great requirements, but that’s when I try to get a little more practical and I might go, “Okay, we’re going to use Drupal. Let’s go ahead and align this as good as we can.” We can talk about that later, David, if that doesn’t quite answer your question.

All right, Biz Reqs, aligning business goals to the project. How do you envision success for the project and how is it measured? At this point, you might be talking about KPIs. You’re talking about increased visits. You might be talking about cost savings for the organization. For Drupal, I see it as the value of open source technology, free licensing. Let’s go ahead and leverage that. It might be a business requirement. Or leveraging all the available modules and codes that’s out there. You don’t have to buy. That’s user contributed. Very powerful reasons to use Drupal.

We do a lot in higher ed. Some business requirements here, more applicants to your university, updating the brand of your website, more efficiency, easier maintenance, SEO-based redesign, looking for keywords, increased level of satisfaction of prospects through the enrollment process, qualified applicants, etc. One thing you can do here that’s helpful is run a recurring survey. Some of these … sometimes you run into business requirements that are soft, can't be measured by hard numbers. It’s great to run a survey year over year, ask students, “How well did the website affect your decision to come to this university,” etc.

All right, User Requirement, this is really a specialty of NavigationArts. It’s really wonderful to be working with an amazing group of information architects. I learn something new on this aspect every day. Aligning the User Experience to the business goals of your organization.

Really helpful to think from the outside in, think from your user’s point of view, very hard to do. That’s kind of our specialty. We’ll come into an organization that’s thinking really from internally out. Maybe their website is built around their internal infrastructure rather than how users see them and needs there. We do redesigns kind of based on that point of view.

Define your audience segments, their needs, concerns and what task do they need to complete.
What relationship does your organization have with your visitor segments? Are there donors, are there members, investors? Defining that is helpful as a kind of step in User Requirements.

It informs your sitemap and your taxonomy, information architecture. I see this whole process really, as you’re going from the analogue to the digital, you’re starting out with these high level business goals and you’re getting things to a digital state with kind of requirements that are very clear and kind of binary, yes, no, they can be tested. That really helps the developers begin to think about a spec and a code, to have that level of granularity and organization in the planning.

Here’s some examples of Higher Ed User Segments. Students, undergrads, transfer students, prospect students, all have maybe some different tasks they need to complete, different concerns. Adult learners might be interested more in parking or the nighttime or weekend class schedule where undergrads are really concerned with the atmosphere and maybe even social aspects of university.

All right, Use Cases, not a huge fan. Sometimes I use them. Sometimes … because websites are often very nonlinear, doesn’t always get you there from the kind of user point of view, but if you have an ecommerce, highly transactional website, things that are kind of linear and steps, maybe even back in work flow, it can be helpful. I don’t like them that much so mine is based on a SharePoint Stack here, SharePoint Service so you need to have this in your toolkit. Some clients or stakeholders really want to see this. Certainly, a formality about doing business analysis here. I’ll talk about it a little bit.

This is a business use case as opposed to a system level where you might talk about things happening on the backend of systems talking to our ERP or the CMS updating another internal record.

Primary actor in this case is a customer administrator. You have a trigger. This is why this Use Case is initiated. You have a set of preconditions. The customer has Purchase SharePoint, etc.

You might have a preconditioned Use Case, like in this case they logged in. A post condition, they got SharePoint and then some steps.

These type of Use Cases I kind of blow out. You have alternative steps. You have exceptions. There’s a lot of way to go about this. It can become kind of a tangled web if you don’t keep it simple. You can extend Use Cases. You can include other Use Cases. It starts to feel like programming a little bit.

The question from Joseph, no, I definitely don’t always use it. I’m with you. I actually probably only use this on 20% of my projects at that. Oh, sorry, the question is about this use case graphic, do you always use it? It seems a bit overkill for a medium sized project. I’d agree, I’d agree, Joseph. Like I said, I keep this in my toolkit for advanced transaction functionality, but it’s kind of the exception here.

All right, here’s some high-level requirement samples, very high level. Maybe you’re using this as initial scoping or this is what you’re getting to think about your personal or development team estimate.

A couple things about this table. Important little housekeeping stuff, have a unique ID. This is very important to start early. When you come to QA, you really do want to say, “Hey, there’s a bug on FR 161. I typically use acronyms for functional requirements, FR, technical requirements, TR, that type of thing.

Then you actually have the requirement. At this point, it’s very high level, just think about scope. Prioritize requirements are great. This is how you can definitely get your stakeholders to think about what they really need. You can go ahead and align this to business goals, if there’s too much or too much outside the scope of what you get done in a certain time.

Then LOE here, and LOE, this is how I think about it with Drupal. On the left here, high level of effort requires significant development effort, may be completely custom coded in Drupal. You’re talking about customization here and if you all haven’t been down this road with Drupal, you want to know where you’re going to focus all your customization at. You don’t want to have the whole site not leveraging user-contributed modules or core modules. You want to pick your battles here.

Medium level of effort requires some customization to existing code base or to existing Drupal modules, but is not built from the ground up.

Then low, requires only minor customization to existing functionality. Hopefully, at this point you’re talking about config, Drupal config to get there.

Okay. A little more detail here. On this slide, at this point in this example, we’re talking about managing testimonials. In the second item, you can see we’re talking now about types so that the business stakeholders are helping me to find these types of testimonials and this will probably drive taxonomy in Drupal later. We talk about text and images. We talk about images being optional. The system shall support video integration, written testimonials. We’re getting to a level of detail that starts to be digestible from developers taking this and thinking about how they’re going to build this.

I have a question from Brent here. Where do you, if you have introduced translation into the requirements, would each FR or later as a separate FR? If you’re talking about localized content and translating content into German and Spanish, I usually have a different section for translations and it talks about the type of content that will be translated. It talks about translational workflow, how it’s going to integrate with maybe a third party service and workflow around that. Then of course, which languages. Then of course, the real big important one, can the client add new languages later? It’s good to think about that.

All right, here’s another example. We released a new website for St. Jo’s not too long ago. Some kind of advanced AJAX interactivity on the home page, definitely worth checking out and we documented this. This is an example of functional annotations. We’re looking at a visual, and I’m annotating it, and I’m describing the requirements of how it’s going to work.

This is really getting into spec. Some people might think of these as a functional requirements document or FST, a functional specification document, and you can adjust your deliverables as needed, but really this starts to get in the fact that we had some requirements, something was probably wireframed. We’ve now put visual design on it and now we’re wrapping up this level of detail to build it. You’re of moving into spec at this point.

All right, Tech/Nonfunctional Requirements. Be afraid, be very afraid and it’s all tongue in cheek, but not for the faint of heart here, experience, this comes back to the fact that you need technical input when doing these type of requirements. If I put these out here without talking to R.J. and the technical team about performance requirements, that’s going to be a bad thing. If we’re starting to say, “This is what someone with a broadband connection is going to expect across the country.” A lot of risks there. Be very accurate here.

Availability requirements, we’re thinking about how many nines. We’re thinking about infrastructure, server loads, server performance, failover. Security requirements, if you’re in a agency model, you’re typically going to provide these. I would never go to a technical client and say, “Tell me how secure you want your website to be, right? They’ll say, “You’re the experts. You tell us.” There are some special circumstances where you’re talking about just things like SSL, which pages and functionality have to be encrypted.

Capacity requirements, analytics, compliance, we’re near the DC area here so 508(C), government websites, big deal. Definitely figure this out before you do wireframes, before you do visual design. If you’re doing heavy interactions, then the main corporate website needs to be compliant. You need to throttle that down or come up with an alternate theme.

Basically, a bucket for anything you want other technical stakeholders to review. The way I think about this is I usually with my requirements documents, I will write a clear technical requirement section just to tell the client make sure your technical person reviews this and maybe not your marketing manager. You’re kind of guiding the client into who need to participate in the process, too.

All right, Device/Browser Support, at a lot of these recent Drupal events, looking at responsive design and kind of mobile first and everything around that, mobile and tablet requirements are causing a paradigm shift in how we think and plan for website projects. There’s no way around it. I think Drupal, its ability to get a prototype out there and think about it is really, really a nice angle as opposed to kind of custom code or some other CMS platforms that require a lot of customization before you see something. The days of “I have a PSD that’s 1,000 pixels wide and this is it. This is the design,” have come to an end, so I think we’re all embracing this change recently and moving into the future here.

IE6, IE7, here’s our take on that. It’s really almost always in the client’s best interest to receive modern maintainable code that is not hacked for older browsers, but verify this is the case. You might have a group, an organization that is using IE6 because they have an old CRM that requires IE6. Definitely find that out.

The first step is to look at analytics. I would never tell a client, “Don’t use an older browser,” until I can tell them, “You have 0.3% people on IE6. It’s time to kind of let them go a little bit.” The way we do that is progressive enhancement. Otherwise, graceful degradation using CSS3, HTML5, for an optimal experience while older browsers getting some semblance of the experience, maybe not the whole thing.

One way we’ve gone about this is take screenshots of websites we’ve done in IE7 and show that these HTML5 features or CSS3 features like drop shadows and rounded corner. This is what it will look like. It’s not the end of the world. It’s not going to break. That’s one way to get there.

Responsive Design, I have a screenshot of the Omega theme here. That’s one way we think about how to think about requirements and how to initially be built.

This is the slide about how we think about aligning those.

R.J. Townsend: Right. I’m going to talk a little bit about how in the process of working with Jon, how I helped to align the requirements that he’s gathered from the client to the functionality that is available within Drupal.
A lot of that is it’s this communication process of talking to the client about the benefits of using open source code. There’s code that’s available. There’s a big community of people around that help to support it. It’s quick. It’s fast. It’s license-free. It’s very valuable.

One of the things that you’re going to be able to do is through reusing your code. It’s going to help to reduce the time it takes to develop. It’s going to reduce any type of budget that it’s going to take to code.

Really, we have this 80-20 rule. We say, “Okay, if this specific module can meet 80% of the requirements as documented, and there’s going to take another 20% of us to do custom code or something like that, then that’s great.” We’ll say, “Okay, this module will meet requirements,” because in the end, hopefully we’re going to be able to build something that we can contribute back to Drupal, whether it’s a new module or a patch or something like that. Really, we’re taking a look at modules, asking the question does it fit, what can we do to make it fit, and can we contribute that back to Drupal?

Translating Requirements to Specifications, what we use is we use a document called the CMS tech spec and this is what we use to align these requirements to specifications. Obviously, it requires a thorough understanding of the client, the documentation that Jon has been working on and whether that’s a statement of work or wireframes or Photoshop files or list of requirements, requires a thorough understanding of that, and also a thorough understanding of not only how Drupal works, but the various modules that are available, where people are focusing their efforts on, which modules tend to be the ones that are going to last the longest.
Basically, the CMS spec maps out requirements to modules. Most, if not all, of your spec document and dev plan should be determined by the time requirements are approved. When Jon and I are working together, I know when we’re talking through requirements, we’re talking with the client, I know the direction that I’m trying to push requirements because in my mind, I haven’t mapped out, “Hey, this is the requirement. This is the module. This is how we’re going to do it.” Your spec document, it should provide framework for how the site will be built. CMS spec complements Photoshop design files and requirements documents.

Jon Rieksi: Yes, and a big kind of overriding topic of this is just getting the development input early enough when things are still being planned. That is just critical. It’s probably a little less waterfall in the planning of requirements are final and then you’re moving to spec, and I think we’re kind of agile, but in our way and should be with Drupal about providing those feedback mechanisms to allow solutions to impact kind of the beginning and thinking about it. As I tell some clients, requirements sound probably boring to a lot of people, but framing the problem leads to how the solution is built. There’s just no way around that. If you can be creative in how you think about your project and your problem, that’s going to influence the solution in most cases.

All right, thanks for the typo there. Someone had a question. All right. On to the next one here.

R.J. Townsend: Translating Requirements to Specifications, so our CMS spec documents, they’re usually anywhere from 75 to onwards of 200 pages. It is a complete documentation of all the content types we’re going to use, all the fields that we’re going to use, views, contexts, panels if you believe in those things, blocks, themes, boxes, beans, (laughs) I feel like I’m rhyming here, and also the naming conventions for each and then some of the required config settings as well.

For example, what tokens are you going to use for pathauto or what specific beans are you going to use for blocks or regions or what different contexts are you going to use depending upon if it’s a one-, two- or a three-column design?

We also talk about deployment architecture. How is it that we are going to number one, be developing internally and number two, how are we going to share that code with the client. Other times it’s more complicated. Let’s say you’re doing continual releases. The question is how, and what we discussed is how do you go about continuously releasing code in such a way that there’s little to no downtime and anything, any type of config settings that are done on the production site, you aren’t overridden by what we’re doing.
We also talk about required modules, whether it’s core, contrib, custom, features and also if you believe in features, and also the high-level config settings around that for each, and then a little bit of redundancy here, but naming conventions as well.
Our CMS tech spec, it’s used in conjunction with Photoshop files and requirements doc. It’s not a document that lives by itself. It’s very much when we as developers sit down and start building the site, we are continuously flipping between requirements and Photoshop files and in the CMS tech spec as well.

On this next page, we built the site for the National Museum of Women in The Arts and this ended up being … it was about 150-page CMS spec. I just included a snapshot here of what the table of contents looks like. You can see we started off with we have our table of contents. We have overview of what this document is. We talk about the organization of the document.

Then one of the things that we do is we talk about page types. A site can have anywhere from say 10- to 20- to 30-page types. You have your home page. You have your generic page. You have say a list of upcoming events. That’s going to be a page type as well.
What I’ll do is within this document, I will take that actual Photoshop file, put it in there and then annotate that with, “Hey, this header region is going to have these three blocks in it, B1, B2, and B3.” Then I’ll say, “In this entire home page is going to be controlled by this specific context and it’s going to have these views on it.” That’s the page types to technical components.

Then you can go through from that and see okay, here are the specific blocks and related modules to those blocks. Here are the content types that are involved with these page types. Here are the views. Here are the menus. It’s going through and on every page of the requirements doc and on every Photoshop file that we had, it’s mapping out the various components to what Drupal has to offer. Then you could see, we also use a couple appendices as well, if there’s any additional module configurations, any type of custom modules, maybe if we have content migration, some of these more … something that doesn’t happen on every project, might be isolated to a specific project.

Jon Riekse: Okay. I might take this time to address a couple questions that popped up here. From Joseph, when working with a customer, usually we do not own the servers. Any requirements you suggest on server infrastructure, especially for hosting providers?

There’s probably actually some good info on Acquia's site. They’re hosting. Things I look for up time, capacity requirements, encryption. Anything on your list R.J., you can think …

R.J. Townsend: I say one of the more important things on my list is just the ability to SSH into the server and to know that either I can have root access or at least pseudo in and get the various permissions to do things that I need to do on the server.

Jon Riekse: Okay, so management and the access you need to kind of …

R.J. Townsend: Exactly.

Jon Riekse: Sure.

R.J. Townsend: Then also we use an open source tool for deploying to various environments and really, I prefer that any type of server we’re going to be working on is able to work on with that tool.

Jon Riekse: Okay. An interesting question here from David Math, upon matching the elicited requirements to Drupal modules, if you find existing modules don’t quite support the desired functionality without a lot of customizations, how do you go about communicating the tradeoffs to your business clients? Thanks. Yeah, great question.

That’s really kind of core to what we’re doing here. Basically, trust and transparency just goes miles at this point in these conversations and hopefully, you’ve done good work and you’ve built a relationship that really allows that direct communication to say, “Hey, you know what, you have some interesting requirements for user generated content and the ability to upload this type of file, but this module we have for say updating a forum or kind of commentary model doesn’t quite support that. This is probably the level of effort, even a rough magnitude of what it would take or maybe we need some customization there.”

Then you talk about priorities and you can do that in the … that’s where business requirements, even though sometimes they might see … they could seem a little fluffy if you don’t have KPIs and strong measurements, that’s where it can really help out. “Tell us about a user uploading this file. How does that really fulfill a core business objective?” At this point, you’re kind of doing a little bit of that conversation, primarily with the business teams and not necessarily with the technical input, but you’re getting them to really prioritize and say, “You know what, this is important,” and if it was kind of not scoped first, if your scope was good in the beginning and you’re kind of … how you kind of priced or estimated it, you can make a good case, we didn’t know about this so it wasn’t in our estimate if it’s new.

If you kind of knew about it, but you just didn’t know the exact definition, then you say, “Listen, we’ve basically elicited a lot of requirements, a lot of new things, let’s go and prioritize and think about how much customization.” Let’s look at the 80-20 rule R.J. talked about. I guess to sum that up, it’s about prioritization at that point.

All right. Requirement Activities, with all this said, you’re a developer, project manager, you’re either starting a website that you know is Drupal or you don’t, and you said, “You know what, go ahead and document the requirements for this project.”
Let me talk about my process just a little bit here outside these bullets. What I do first is I take every piece of known information about the project and try to summarize it up and put it into groups. Maybe we know it’s Drupal 7. That’s a technical requirement and constraint. Maybe we know it has to support mobile devices. That’s a technical requirement. I know these are the high-level business goals. I document those.

I think about what I know about users. I think about what I know if anything about functionality. I take that list and I start thinking about questions. Maybe I know we need to play videos, but no video provider service has been selected. I start thinking about requirements to ask stakeholders around social. Is it important to get some social traction with your videos? Is it important to have HTML5 video playback? Is it important to support flash? Is it important to support related videos? I come up with a big list of questions for these stakeholder interviews.

Back to the slide here, it’s about talking to the right people at the right time. I might have a list that’s really about marketing angle. I have a list of marketing questions. Then I might talk to their technical team and ask them to tell me about their problems, issues they’ve had, concerns they have about supporting functionality or integrations, etc.
Then if the client has any documentation, analytics reports or other requirement activities or list of functionality, they want to go ahead and analyze that.

Ask the question different ways to ensure understanding. I might kind of slice and dice things a couple of different ways just to make sure the stakeholders are giving me information that backs itself up and is not contradictory. If I hear contradictory information, I’ve got to iron that out. That can really happen. If you talk to different groups of people, some people might want functionality A and some people want functionality B. Then what I usually do, I tend to try to get those two people in the same room and iron it out. If we can't figure it out together, I go up a pay grade and talk to the people that are sponsoring the project and then have them prioritize. That’s one way to go about it.

I write all this down and then I rinse and repeat. I might go six or seven iterations of this on a common project and every time, I’m getting a better level of detail. I just keep on finessing this, getting feedback, getting priorities, and getting to the point where the business is pretty happy with what they want out of this project, but in the meantime, I’ve gotten technical feedback. We’re aligning to that scope typically sometimes in the background the whole time. That’s how I go about it. Managing requirements is part of it. Updating and change control.

Moving the conversation forward, this is where we get into these requirement versus spec conversations that are really tough to kind of unravel sometimes. I don’t stick just to the requirements. I don’t avoid the how questions when it’s appropriate. There are a lot of levels of what, how and what, how.

A high-level requirement coming back to the video analogy is we need to play video. Well, if that’s into my requirement and then the development technical team have to take that over for a spec, they don’t have a lot to work on. Through requirements I might figure out, “You know what, we’re going to use YouTube or we’re going to use Bright cove,” and then there’s follow-on questions that come to that. “Okay, you’re going to integrate with YouTube. Let’s think about how that’s going to work. You need to have related videos for Bright cove.” We start thinking about the different formats and maybe they’re going to display based on taxonomy and think about those relationships. I just keep on drilling through. I think it’s the most efficient way for the second bullet.

I might not know workflow, but I know this third party API integration so I’ll write that on the same document. Now this kind of goes against our nature of trying to keep documents the same level of abstraction. I just don’t try to go there. If I know things, I keep on pushing, just try to get to the end goal.

Work forwards and backwards, this is where development experience can really help you when you have requirements. You know with the developer what information you need to build it. I try to think about that when I get to the end game there before … as I’m moving along the process.

Here’s the key point. You have to use your brain and experience to realize if you are making too early an implementation assumption. Like my goal for R.J. and his team is a lot of what they need to do with a spec can be done without going back to the stakeholders and opening backup scope and requirements. That’s the type of thing I’m trying to get consistent. If we have to go back later and we miss something or it wasn’t bounded and there’s a contradictory requirement, we might be in the middle of development and now we’re accidentally opening back up a question that might have severe impact to flow through all sorts of other areas of developing the site. That’s where you can get hurt if you miss something. Important to kind of be diligent. Make sure you have a whole solution that is not contradictory.

I’m going to go ahead and answer some questions here. Let’s see, the one came in from Joseph Hurtado. Any experience with the cloud providers? R.J., would you like to take that one?

R.J. Townsend: I think there are a lot of cloud providers out there that provide Drupal specific services. Obviously, Acquia is one of them, Pantheon, seen a number of other ones out there. Some of them even offer tools that help you through the deployment/staging process. There’s definitely some good providers out there. There’s also some shady providers out there.

I always say go with the good name brand that you hear, that you trust. Talk with your colleagues, with other people about, “Hey, have you heard about so and so? What’s their reputation like?”

I think the only … I want to go back to what I have, requirements in a server, just make sure that you have SSH access and that if you’re going to have to … let’s say there’s some type of special script or program that you need to have running, just make sure that you have these requirements documented and that any type of hosting provider you go with is going to be able to meet those requirements.

Jon Riekse: Okay, great. Next from Randy, what experience do you have working with nonprofit membership driven heritage preservation organizations?

We in NavigationArts have a ton of experience working with nonprofits, certainly, the membership driven model of you have a member log-in and there might be something around donations or e-commerce with membership fees and special functionality from members. I don’t have a lot of direct experience I think with heritage preservation organizations, but maybe Randy for that specific question, if you could send us an email, we’d be glad to get back to you.

Leslie, great question. What level of Drupal expertise do your BAs need and how did you get them to that level?
Well, that comes back to the technical background. It’s great to have BAs that have done web development of some capacity, are familiar with Drupal, maybe have been a web master, understand configuration, a little bit about what’s happening under the hood. What we do here is a lot of internal training. It’s all about Drupal knowledge transfer. R.J. gets to do a lot of that here.
I had the luxury of listening to Kiran Lau a couple of years ago about him speaking about Drupal, Drupal 7, Drupal 8. He’s part of Acquia. He talked a lot about Drupal has had huge success in the technical community, but the future of Drupal is about getting that information and knowledge back to the business community so project managers, business analysts, stakeholders, people funding projects. A lot of what I’m talking about is around that aspect of moving out of technology into the kind of business community and communicating that out.

A lot of training, there’s a lot of things you can do with BAs for different aspects of their work. BAs can help with QA and they’re going in there and helping QA to back-in so maybe they’re moving some blocks around and learning about that way. BAs can help with content entry and just getting to the Drupal camps and reading about it and if they’re technical enough to even play with the hosted version and try a little bit out themselves. That’s great.

From Judy, how do you get clients to write content in a timely manner?
I might have to take that one off line. That’s a long … that’s a great question and giving a discrete content entry phase for them to prepare for that and spreadsheets that model your content types is very important. I’ll be glad to follow up that through an email if you like.

All right, I’m going to get through a few more slides before I move too much further along with the questions. Yes, we’re … kind of a time check here.

A couple of Drupal specific requirements, simple work flow. All right, common one, workbench maybe for Drupal 7. I had some problems with the revisions and things for Drupal 6. I look at this and go, “This is a great workflow. This is an easy one. Let’s define some email copy and we’re good to go.” R.J., what’s your perspective on this one?

R.J. Townsend: I think you definitely want to align that to what’s available as far as contributed modules because this can be just a very deep rabbit hole.

Jon Riekse: Okay. An even deeper rabbit hole is here’s an example of another one we did. I look at this and go, “Let’s make sure that this is what the business needs. We have corporate review. We have other departments involved. A complex work flow, so let’s make sure this is worth the energy to pull off.” What’s your take, R.J.?

R.J. Townsend: Once again, just make sure you align it to what is available and I think that’s a lot where I’m going to come in and I’m going to say, “Hey, this is what, for example, the work bench module, this is what’s available within the work bench module. I know this is what the client is requesting, but if we can kind of shift our model or do something just a little bit differently, we’re going to be able to meet that 80-20 rule.”

Jon Riekse: All right. This comes up a lot in requirements. Me and R.J. kind of go back and forth about how much of this should be in requirements and how much is spec. I take the user’s point of view and in this case, it’s the Drupal admin user of it’s very different to edit a page that’s a big block of WYSIWYG versus having structured data around defining my content type and my content entry has a discrete date field, a title field. I don’t need to know HTML, all of that type of thing. It has significant implications to the website. Do your content people know HTML? For me, when we think about content types, this affects the other page types and modularity of the whole system. I’ll keep moving along here as we’re running out of time.

One quick thing for structured data, what fields are included? Sort orders for list, min/max, number of elements, what happens if there’s nothing, descriptions of empty results sets. We always want to know that, right? What if you have a page and there’s four content types and all of them are zero, right? Think about that and controls for paging and filtering large sets of data.

Here’s an example of WYSIWYG versus plain text. Something we did for the National Aquarium. You’ll see the annotation number four is rich text. We expect them to put in their WYSIWYG editor, they could do HTML, but they might pick if it’s going to be red or green or italicized. In contrast, on number five there, you’ll see a button and basically that will be plain text. They can't break it. It’ll always be a consistent file.

CKEditor, customization, just some things we’ve done here.
Taxonomy, I will say try to get your taxonomy into the Drupal language in the middle of the planning, really start fleshing out vocabulary names that match to Drupal.
Block Configuration, Reusability, if you think about this early, you can do usability … I mean reuse … if you don’t think about it too early and you have too many variations, you lose that modularity. It’s what we call here the unique snowflake approach. Try to avoid that.

We’ve done a lot with D7 migrations I’d say at this point. Call us if you need to. Functional analysis, content type inventory, you’re looking for a functional gap between current state and future state.
BA role & Drupal, talked about some of this. It can be creative in how you think about the problem. Got to be flexible. You can run some logic interference from your technical team, that’s probably usually pretty busy.
We try to use functionality between different projects. It really helps to build up this library. As you specialize, you specialize in Drupal. It’s nice to be able to reuse something you did from your last project.
Hopefully, contributing back. To the earlier point, I think to myself sometimes I know from a lot of people’s questions, they’d love this. What if you had a sample requirements for every user contributor module that you could just kind of copy and paste and start from there? Wow. Wouldn’t that be great. I hope we can get there by contributing there.
I’m going to go through a few more questions as we ran out of time here.

Caroline Mullen: Let me just jump in for a second. This is Caroline Mullen from NavigationArts. I just wanted to thank Hannah from Acquia and the rest of the Acquia team for allowing us to present today. Then a huge thanks to Jon and R.J.

We have ran out of time. We are running out of time so if your questions were unanswered, we’ll follow up with you via email, but feel free to send us an email at sales@navigationarts.com or ask us questions on Twitter and we’ll get back to you over the next couple of days.
But I think you have time to answer maybe one or two more.

Jon Riekse: Okay. Yes, I’ll get through a few more. Good question about how much work is done from Dave before you sell or commit in some level to an estimate of your internal organization?
It’s great to have maybe a … if you’re coming in cold, we have sales activities that we typically take on to scope things correctly. If things need more work in a paid capacity, it’s great to have a discovery budget where you can come and do requirements work to get a better estimate for the build. That’s really ideal. Not everybody’s happy with that. I would say going back to one of my slides, you’re looking for high level functional scope at least before you commit I would say.
We’re doing a website. There’s got to be some forums. There’s got to be some integration with a third party. It really comes down to risk mitigation. Definitely more of an art than a science. We don’t do official requirements, but we do a scope, scoping done using on any spec work.

From Jason, would you offer any additional advice for preparing requirements for smaller projects? We provide grassroots advocacy service with often a rapid response with little planning.

My advice is back to doing the two-pager, three-pager if you need to. You don’t have to blow it out, but think about these high-level functional groupings and put just some bullet points under it. That’ll be my advice for you. We’re doing an e-commerce site. It’s going to support these type of products. Administrators will be able to update the products. There’ll be some text. There’ll be some shopping cart. At least get that high-level bullet list and then focus on the complex pieces with a little more detail. That’d be my advice there.

Mauricio asked is there a particular module that you use for AMS integration, IMS, I work a lot with these associations. I’ve worked some integrations with IMS from a .net based system. I can't think of … I know there’s some modules for association management systems out there.

R.J. Townsend: I remember looking that up not too long ago and I didn’t find anything that was very really production worthy.

Jon Riekse: Okay.

R.J. Townsend: That was a while ago.

Jon Riekse: There was a good presentation on this at Capital Camp in DC a couple of months ago. If you go to I think it was capitalcamp.com or .org, search their presentation. There was a good one I saw there.

From Eric, how would you work with a client who’s technical team has little to no experience with agile development or their nontechnical project team is particularly large?
Well, you don’t have to convince them to do agile. I’m fine with waterfall. As long as you’re doing the technical check-ins, I’m completely fine with waterfall if that’s what you need to do. I would say it’s pretty rough when you’re taking a client who’s non-agile and try to get into an agile methodology. It’s just sometimes too much of a culture change from my experience.

R.J. Townsend: Agree.

Jon Riekse: Okay. All right. That’s all we have time for. Anything about Drupal 8, etc., feel free to send us an email. We’re going to wrap up here. I know the slides will be posted soon. I appreciate everybody for your time.

R.J. Townsend: Yes, thank you very much.

Female: Yes, thank you. Thank you, Jon. Thank you, R.J. for the great presentation. We really appreciate your participating today and answering all the wonderful questions.
Thank you everyone for joining us today. Again, the slides and recording will be posted in the next 48 hours to acquia.com so you can find them there. Thank you.

Passer de zéro à 100km/h sur Drupal grâce à Acquia [September 11, 2012]

Securing Drupal Sites for Government Agencies [September 5, 2012]

Become a Drupal Hero with BuildAModule and the Acquia Network! [August 30, 2012]