Author: Kellen Greenberg

Kellen is a dynamic consultant, who excels at analysing how people, information and technology work together. As Director of Government Service Excellence, Kellen is focused on helping the Government of Canada solve the complex problems related to serving Canadians. This is done with a focus on effective and strategic use of the web, integrating with other channels such as telephone, in-person, social media and mobile platforms. His strength is bringing clarity to complex situations, and Kellen achieves this through his skills in facilitation, change management, process design and creative problem solving.


Web Accessibility from PDFs and Apps to Project Planning: A conversation with Derek Featherstone

On November 20, Systemscope co-hosted a talk with Simply Accessible’s Derek Featherstone about accessibility and usability in light of the fast-approaching July 2013 TBS Web Standards on accessibility and usability compliance deadlines.  Shortly after the talk, I met with Derek to go over some pressing topics our attendees had that we didn’t have time cover at the event:

  1. PDFs and Accessibility
  2. Meeting GC Web Standards Deadlines
  3. The Best of All Possible Worlds
  4. Testing for Accessibility

1. PDFs and Accessibility

What’s your take on making PDFs accessible?

PDFs are often published in that format because it is convenient for the publisher more so than the person getting the information.  The first question to ask is whether the content should be published in a PDF format or not?

If the decision to publish in a PDF format has been made already and it’s a standard operating procedure, what can be done to make the PDF accessible?

For a report, a strategy for dealing with publishing to PDF is to publish the report from pieces that are initially accessible, instead of trying to convert a PDF to its HTML equivalent. An accessible PDF can be just as accessible as HTML.

Some things to consider for building accessible PDFs:

  • Build the report using an accessible Word template
  • Make sure the reading order is right and that all the image assets have alternative text
  • When creating big reports that are built in Word and merged with Excel tables, make sure there’s an accessible baseline or template that exists.

Is it possible to retrofit PDFs and make them accessible after they’ve been produced?

You can take the PDF that’s produced and fix it, which can be very time consuming if you’re not a PDF accessibility expert.

To retrofit PDF format documents you can go back to the source document and once you make the source document accessible, you can regenerate the PDF as an accessible PDF. This can be efficient because it then becomes reusable. You can also employ a service from PDF accessibility experts to fix up your PDFs.

Overall, spending money to retrofit PDFs after they have been published is one-time money spending.  Creating PDFs from accessible templates that have been built before publishing to PDF gives you a multi-use accessible production baseline.  The money invested upfront to create those templates can be more effectively spent than spending time and money retrofitting PDF documents. Of course, this really does vary depending on how complex your PDFs are. In some cases it might be just as cost effective to have them converted to accessible PDFs by a 3rd party.

(^top)

2. Meeting GC Web Standards Deadlines

With the compliance deadlines looming, are there any other pragmatic takeaways you can offer Government of Canada web professionals who are now racing against the clock to meet the standards?

Any takeaway depends on the types of work you’re dealing with.

For document-centric accessibility work:

  • Start by checking the overall structure and making sure there is a page structure that exists. Whether it’s in PDF or HTML format, there should be properly tagged headings, lists, paragraphs and alternative text for images.
  • If your documents are not interactive, i.e. forms, and your accessibility compliance tasks centre around content, check image assets that are included to make they are located in the right place on the page.   For example, check that an image at the top of the page is not related to a paragraph at the bottom of the document.

For web applications-centric accessibility work:

  • Deal with your most important assets first by asking if this is a mission-critical application that has to be made accessible.  For example, at the Canada Revenue Agency, a payroll calculator is an employment-related application that everybody needs and that is central to the CRA’s service offerings.
  • If your application is a map, try to understand who is using the map and for what purpose.  Too often, web accessibility is reduced to blind people who need to ‘hear’ the application to use it.  If, however, the mapping tool is one that requires the user to draw a map to then calculate the area, accessibility moves beyond blind people using the application to people who might need a keyboard accessible way to ‘draw’ the map.  Other people might be using voice recognition software to use the application.  The understanding around web accessibility has to move beyond blind people to understanding different interfaces for different users.

In many cases, when attempting to retrofit applications, it becomes obvious that the wrong tool was purchased to accomplish the task. That’s when usability testing and understanding user needs and tasks is critical to accessibility.

(^top)


3. The Best of All Possible Worlds

What would be an ideal Government of Canada scenario in terms of web accessibility for you?

When we work on large-scale accessibility projects, we try to cover off five pillars:

  1. Planning
  2. Procurement
  3. Professional development
  4. Process
  5. Policies

These pillars are not sequential, but they have to exist.  From a process sense, you need to make sure your entire software development lifecycle takes into account the needs of people with disabilities from design to testing to roll-out.

From a procurement standpoint, we would ideally have the proper tools that are accessible in the first place.  For service procurement, requirements have to have accessibility built into the final deliverable.  Sometimes, vendors will say that a tool or piece of software is accessible, only for clients to find out that it hasn’t been tested appropriately or evaluated properly for all dimensions of accessibility. Other times, vendors will understand document-centric accessibility but not web application accessibility.

We often get called in to evaluate third party work to assess whether the tools or applications that have been delivered meet people’s accessibility needs and standards.  We work as an advocate for the client since they might not know or have the time to understand all the dimensions of web accessibility.

(^top)

4. Testing for Accessibility

Is it possible to do accessibility tests in-house rather than post-purchase or pre-launch?

A good place to start is with the WCAG checklist and being to understand how to interpret it.  The expertise to interpret the checklist takes years to develop, but there are W3C resources on WCAG out there with techniques on how to test accessibility and usability and why it’s important.  Often for clients though, it’s easier to get somebody else to come in and assess the work for you.

How is that important to an enterprise-level project?

If you’re not making professional development and continuous improvement part of an overall program to achieve accessibility and treating it as a one-time project, the work won’t be sustainable.  Training on accessibility, whether from a technical, compliance or user experience dimension gives you a base that goes beyond a one-time project.

When we give training sessions to various clients, whether they are designers, quality assurance staff or testers, we offer an initial assessment of their project and how to fix it.  More importantly, we help them fix it and teach them how to avoid the issue in the future.  Knowing how to avoid issues and fix problems takes accessibility out of project mode into a built-in process that’s part of a bigger program.

Embarking on a redesign takes years to accomplish instead of fixing other more basic problems on a day-to-day basis.  Compliance to these new standards should be a starting point, not an end point.  Executing these compliance standards is the beginning, not the end.  Accessibility and usability should be part of a continuous, iterative process, not a one-time annual project.

With that, our conversation came to a close.  In sum, with a fast approaching compliance deadline, well-planned, prioritized efforts to meet accessibility will enhance usability while also realizing operational efficiency and improving overall user experience.

(^top)

If you are interested in attending future Systemscope Lounge talks about the Government of Canada web presence, please contact Denise Eisner (eisner@systemscope.com) to be included on the mailing list. We appreciate all inquiries, but preference is given to Government of Canada professionals.

5 Misconceptions About Change Management

With the amount of transformation currently underway in the Government, it’s no big surprise that Change Management has been a popular topic of conversation. What has been interesting across the sum of these conversations is the wide range of definitions and perceptions about what Change Management is. Here are the 5 most common misconceptions that we are seeing regarding Change Management.

  1. Change Management = Communications: When talking about change management activities within a project, we often discuss which resources are being tasked with leading the CM activities in a transformation project. A common answer is “oh, we have a Comms person on our team already, so change management is taken care of.” It’s a start – constant and consistent communications are critical to any change initiative – but there is more to effectively managing change than communications. Just because you tell people about the change, that doesn’t mean they’re going to do it.
  2. Change Management = Project Management: There is a difference between these two streams of activity and areas of expertise, but it’s not always a distinction that is well understood. Project management is an area of practice that largely focuses on ensuring that the activities and milestones are undertaken in a way that allows a project to be completed on time and on budget. Change Management is more focused on the people side of change, working with all levels of staff to ensure that they are willing and able to make the change. You can hit all of your project milestones, but if the staff in your organization don’t change their actions, will the transformation really be sustained?
  3. Change Management = Checklist of Deliverables: This misconception is sometimes a subset to the previous, where “change management” is a line item in a project plan with a handful of associated deliverables, such as a communications plan and training plan. These deliverables are important to complete and should be used by the project team as a way to guide their actions and communicate plans with others in the organization… but there’s the rub. Far too often the creation of the deliverable is where the activity starts and ends, with good thinking and planning being little more than a tick on a checklist of deliverables. Implementing change successfully is about working closely with those who need to change – the deliverables are but some of the tools that enable this collaboration.
  4. “It’s an IT thing”: Change Management is best known by our clients in IT, while many clients in program areas or business lines often tell us that they don’t need change management because change management “is an IT thing”. The way we see it, change management is about working with the people in an organization to ensure that they not only know about a change initiative and its merits but it’s also about working closely with staff, managers and executives to ensure that everyone is willing and able to make the necessary changes in their skills, actions, behaviours and attitudes.
  5. It’s about the group, not individuals: In large and complex changes, the number of different teams and staff that need to be engaged can be overwhelming. An easy way to short cut some of that work is to aggregate your change management activities – dealing with targeting 3 branches is easier than targeting 1,500 individuals, right? While this can indeed find some efficiencies, it brings risks too. Teams are made of individuals, each with their own challenges and barriers about implementing the change. If these aren’t addressed at an individual level, there is greater risk to having the change successfully implemented. This is even more dangerous to the success of a project when it comes to resistance management – dissent and resistance can ruin a project if left unmanaged. So if you find yourself batching together your CM efforts, never forget that a chain is only as strong as its weakest link.

If this is what change management is not, then what is change management? Ironically, “all of the above” isn’t a bad place to start. It includes all of what is listed above, just not in isolation. Successfully managing change does indeed require communications and project management, and good documentation goes a long way. It does have a place in IT, but also plays a role in any project where people need to change. It is definitely about teams, but it is also about focusing on the individuals that make up the team.

In addition, though, there are more pieces that are true change management activities that need to be integrated into any change initiative:

  1. Change Characteristics – understanding the size, scope and complexity of the change in order to define concrete steps to mitigate any potential issues or risks
  2. Organizational Attributes – recognizing the organization’s past experiences, organizational tendencies and cultural influences related to change in order to define concrete steps to mitigate any potential issues or risks
  3. Transformation Team – defining the right individuals with the right competencies, and the right relationships to the project team and sponsors to drive the change management efforts in order to define concrete steps to mitigate any potential issues or risks
  4. Sponsorship Team – defining the right  individuals with the right competencies, and the right relationships within the organization to effectively sponsor the change in order to define concrete steps to mitigate any potential issues or risks
  5. Risk Assessment – defining the risk levels associated to the project in order to define concrete steps to mitigate any potential issues or risks
  6. Special Tactics – bringing all of the above together in an integrated and highly customized set of special tactics that ensure that people are willing and able to make the change

Change management is about managing the people side of change; not just to complete the project, but to ensure that the people in the organization are willing and able to make the change, and to ensure that the change sticks.

Mobile media trends and Government of Canada online service delivery

The growth of mobile media consumption and use via mobile devices is exponential. There are three major trends:  amplified convergence; data tracking; and, the multi-screen universe.  All three trends not only enhance device mobility and user expectations and experience, but also exemplify how web management practices within the Government of Canada should evolve to meet growing citizen expectations for online government service delivery.

  1. Amplified convergence: Convergence on digital platforms usually refers to the intersection of various types of content enabled on different devices, from smartphones to tablets to laptops.An example of amplified convergence is the mobile wallet. Transactions of all sorts will take place via the mobile wallet, not just between consumers and retail businesses but also between citizens and government services. An eventual 5G network will further enable the ‘internet of things’ (see this helpful infographic for more details) and allow for a seamless convergence of content between all devices.As a result, content creation, usability and development will rely on various groups sharing their skills and resources to provide a cross-platform user experience. Having a solid organizational governance structure in place with clear roles and responsibilities outlined for each group becomes a critical success factor for efficient delivery.
  2. Data tracking: From body weight to geo-location indicators, mobile devices enable real-time data tracking. Never before has so much data been collected at such customized levels.The upside of collecting all this data is that the way in which we receive information can be tailored to our specific needs, based, if warranted, on our exact location.In two years, we no longer will seek apps, they will be pushed to us based on where we are and what we’re doing. The downside to tracking and collecting all this data is to what ends it could be used for.With the amount of data being tracked and how quickly it can be adapted to meet user needs, organizational information management standards and processes will be important to maintaining the balance between privacy and usability.As Linda Daniels-Lewis at Systemscope points out in Is your information really an asset?: “We have to transform the concept of information management from “filing” information to “using” information”.
  3. The multi-screen universe: Content will no longer be restricted to a set screen size since screens can be enabled or enhanced via mobile devices. Screens will display location-based information tailored to individual users.Augmented reality plays a role in creating screens seemingly out of thin air through applications such as Wallit or Blippar. Adding to the multi-screen universe and additional reality layers can be viewed on this video for the Google Glasses Project.Content therefore should be scale-able for various screens and appropriately labelled to enable customized access. Content lifecycle guidelines and regular ROT exercises should be planned as website content management becomes an ongoing process.To quote another Systemscope blogger, Denise Eisner, finding ROT is only the beginning.

For success in the mobile space, David Armano states in a Harvard Business Review article that organizations should “learn from past lessons in Web, digital and social”. Given that mobile media is still a growing market in Canada, there is time within the Government of Canada context to revisit organizational governance structures, IT applications and website content and incorporate citizens’ experiences and expectations about online service delivery and mobility to Government of Canada websites and web applications.

User Centred vs. Audience Based

In a recent presentation on Information Architecture at Health Canada, I was asked the question “should we be targeting our users or our audience”? This question was followed by a bit of a debate and confusion over the matter, roping in other concepts like user centred design and audience based navigation to further complicate things.

Following the meeting I circulated a short document to bring clarity to the issue and thought it would be worthwhile to share some of the concepts as I’m sure Health Canada isn’t the only organization users and audience have some delta between them.

Here is how I like to define the difference between the two:

The difference between users and audience isn’t rocket science, but it is an important distinction to make when making design decisions. Following that thread, I want to clarify two design approaches that are related to (and confused with) user and audience: User Centred Design and Audience Based Navigation.

User Centered: A website that is designed to address the needs and behaviours of the different users of your site. This includes both the users who are coming to your website today and the audience that you would like to have visiting your website (See image above). Effective user centered web design balances the needs of different users by following all of the following guiding principles:

All users want content that is:

  • Well written and easy to understand
  • Easy to find
  • Clear and to the point
  • Helps them achieve their purpose for visiting your site

Different user types may want:

  • Different amounts of detail and technical information
  • Access to explanatory context vs. Access to raw data

No user wants content that is:

  • Generic to the point of having no value
  • Detailed information/data without any context for application

Audience Based Navigation: A navigation structure for a website that divides content by audience type (i.e. Seniors, Immigrants, Scientists, health care professionals, etc.). Ironically, Audience based navigation often stands in opposition to user centered design. We have known for a while now that for the most part, audience based navigation is not the most effective means of structuring a website to help users achieve their desired tasks online. Users decide what content they want and do not want to be told who they are.

Web Renewal Series: 6 Departments, 3 Consultants, 4 Blogs

by Kellen Greenberg

Recently my colleagues Denise, Alex and I met up at the local diner to catch up on our projects. Over eggs and coffee we realized that despite us working on Web-related projects in six different departments, the issues, challenges and at times high stress levels faced by our public sector clients are very similar. We decided to put together a series of blogs to pull together some of the important lessons learned from this aggregate of projects.

This series of Web Renewal blogs is designed to help the Federal Government continue in its quest to deliver meaningful web content to Canadians.

Part 1 – More Than One Piece to the Puzzle

All six of the Web Renewal projects we were working on tackled seemingly similar challenges under similar labels: Web Renewal, Web Renovation, Web Transformation. However, when we lifted the rock to see what these projects were really about, we were presented with a host of different challenges. The rubric of “Web renewal” (or something similar) is being used as an umbrella for what we’re seeing as four different types of project:

  • IA Renewal: Often the stepping stone to a deeper problem, clients are looking to fix a broken Web experience by cleaning up their navigation and underlying information architectures.
  • Content Integration: A lot of our Government clients are still working hard to clean up their footprint on the Web. We’ve helped several organizations forge ahead with taking their 200+ websites and streamline them into a single, cohesive Web presence.
  • Content Renewal: This type of work involves taking all of walls of policy text from your website and turning into useful, findable, readable, meaningful Web content. If only people would spend more time and money in this area!
  • Technical Migration: Moving from one technical platform to another. The panacea of managing and delivering content through a Web Content Management System (WCMS) (or a shinier newer one), often gets embedded with cleaning up content and navigation.
  • None of the above: In some cases, the issue being manifested on the Web is rooted in issues that have very little to do with the Web. Absence of organizational vision or direction, poor leadership, misunderstanding of client needs, or complicated policies and operations can all be brought to the surface by trying to make a usable Web experience. However, just because the website is unclear, doesn’t the mean the problem is with the Web.

What’s the point of all these definitions? Fixing a large GC website can have many different facets to it, and moving forward towards a fix requires a good understanding of what the true problems are, a solid project plan and the support of senior management.

Mixing up the right Web Renewal cocktail from the outset can save a lot of pain and frustration down the road. If you’re looking onto a similar type of project for your organization, here are a few quick notes about how to best shape your project and avoid shooting yourself in the foot.

  • Content Integration and Information Architecture work are a natural fit together.
  • Content Integration and Content Renewal are also a good pairing.
  • Content Integration, Renewal, and IA can all be done at once too, but it’s a big project.
  • Content Renewal on its own or combine with other things is a lot of work. It’s incredibly valuable and necessary work, but a lot of it.
  • Technical Migration is just different. Doing this in lock-step with the uprooting your IA and content can be extremely challenging.

Our next post in this series will focus on some of the foundational pieces often overlooked in Web Renewal projects that can make or break its success.

This blog was written by Kellen Greenberg with support from Alexandra Katseva and Denise Eisner.

Of Clocks and Clouds: The Right Support For Your Processes

In the May 2010 edition of Wired, Jonah Leher’s article got me thinking about philosopher Karl Popper and how his theory on Clocks and Clouds isn’t far off an approach I use when designing processes. Popper:

“..divided the world into two categories: clocks and clouds. Clocks are neat, orderly systems that can be solved through reduction; clouds are an epistemic mess, highly irregular, disorderly, and more or less unpredictable.”

Processes are of clocks and clouds too.

read more