Category: Apps

Categories
Blogs Apps communications design ux

WCAG 3.0 – the next generation of accessibility guidelines

WCAG 3.0 – the next generation of accessibility guidelines authored by Léonie Watson

WCAG 3.0 is coming and everything is changing including the name.

The Web Content Accessibility Guidelines (WCAG) 1.0 were released in 1999. By the time WCAG 2.0 were released in 2008 the web had undergone huge changes and WCAG 2.0 gave us a new generation of accessibility guidelines to follow. We are now at the same point again; the way we design, build, and use technology has changed in the intervening years and so the time has come for the next generation of accessibility guidelines to emerge.

Let’s start with the name. Too much has been invested in WCAG as an acronym for it to be set aside, so with a small sleight of hand, the new version will be the W3C Accessibility Guidelines or WCAG 3.0.

When you look for information about WCAG 3.0 you’ll find references to the Silver Guidelines and the Silver Task Force. This is because work on WCAG 3.0 is being done by the Silver Task Force of the W3C Accessibility Guidelines Working Group. It was called the Silver Task Force because it needed a name and a name for the new guidelines had not yet been decided. The name came from the chemical symbol for silver, which is AG, which also happens to be the acronym for Accessibility Guidelines.

A common criticism of WCAG 2.x is that they are hard to read, hard to understand, and hard to interpret. They are also constrained to a structure (Level A, Level AA, and Level AAA) that is completely rigid and there are gaps that mean certain groups are less well recognised than others, people with cognitive disabilities for example.

While WCAG 2.1 and the forthcoming WCAG 2.2 attempt to close some of those gaps, they are still confined to the same basic framework of principles, guidelines, SC, and levels. WCAG 3.0 aims to move away from that to a whole new architecture.

 

Guidelines, outcomes and methods

We know that WCAG 3.0 will consist of multiple guidelines; each guideline will have multiple outcomes; and each outcome will have one or more methods.

The guidelines will be written in plain English. They will be based on functional needs, grouping multiple outcomes together, and will be independent of specific types of technology. The idea is that anyone will be able to read and understand the guidelines, that they will focus on a person’s ability to do something, and that meeting the guideline does not depend on any particular type of technology.

We know that WCAG 3.0 will consist of multiple guidelines; each guideline will have multiple outcomes; and each outcome will have one or more methods.

The guidelines will be written in plain English. They will be based on functional needs, grouping multiple outcomes together, and will be independent of specific types of technology. The idea is that anyone will be able to read and understand the guidelines, that they will focus on a person’s ability to do something, and that meeting the guideline does not depend on any particular type of technology.

One of the proposed guidelines is: Provide text alternative for non-text content.

An outcome associated with that guideline is:

Outcome: Text alternative available

A text alternative for non-text content is available via user agents and assistive technologies, which allows users who are unable to perceive and / or understand the non-text content to determine its meaning.

The outcome is associated with one or more functional categories. In this case the categories are:

  • Sensory – Vision & Visual

  • Sensory Intersections

  • Cognitive – Language & Literacy

  • Cognitive – Learning

  • Cognitive – Memory

  • Cognitive – Mental Health

  • Cognitive & Sensory Intersections

The outcome also has one or more methods associated with it. For example:

Bronze, Silver and Gold

We know that WCAG 3.0 will not use Level A, Level AA, or Level AAA. The thinking is that levels like this are OK for making statements of legal conformance, but they are not a good reflection of real accessibility. A website could pass 29 of the 30 Level A SC and 19 of the Level AA SC and still not declare itself to be accessible under WCAG 2.x as used in law. So a more nuanced way of measuring conformance is needed.

This is still up for discussion and could change before WCAG 3.0 are released, but the current proposal is that it will be a points based system. Each guideline will be given a score between 0% and 100%, and a score of 100% equals 1 point.

Let’s take a (likely but theoretical) guideline as an example: all informative images must have a text description. If there are 100 informative images on a page and 90 of them have text descriptions, the page would score 90% or 0.9 of a point.

As each guideline is assessed the total number of points is updated. The proposed model then goes on to use a three tier system, using Bronze, Silver, and Gold, instead of Level A, Level AA, and Level AAA. If you’re thinking this sounds a lot like the old Level A, Level AA, and Level AA model, you’re right in one sense; whether we like it or not, laws and policies will always demand a rigid statement of conformity. For everyone else there is an important difference though – the points based model means that progress from one tier to the next can be measured, and that implicitly encourages efforts to reach the next tier.

There is another subtle but vital difference with this model – it recognises success, instead of focusing on failure. Under the WCAG 2.x model if you fail an SC, that’s that. Under WCAG 2.x, a single informative image with a missing text description fails SC 1.1.1; it doesn’t matter how many other images there are, or how good their text descriptions are, that one missing text description means you’ve failed to meet that SC. Under the proposed WCAG 3.0 model that same missing text description might mean you score 0.9 instead of 1.0, but it recognises all the text descriptions that were provided whilst still acknowledging that one was missing.

Timetable

It takes time to produce a W3C Recommendation, the formal name for a standard that has been published under the W3C’s Process for peer review and production readiness, but the first milestone on that journey is called a First Public Working Draft (FPWD). The Accessibility Guidelines Working Group is currently preparing to publish the FPWD of WCAG 3.0, and if they agree it meets the criteria, we could see it released sometime in the next few weeks. An FPWD is still a long way from Recommendation though, and there is still much to be discussed, and much will change before WCAG 3.0 is formally released. In the meantime you can track progress and get involved in the discussion via the WCAG 3.0 (Silver) Github repository.

Categories
Blogs Apps communications design ux

5 UX design principles for communications platforms

Perhaps the most important goal for any UX design is clarity. A user logs in or adds something to their cart without thinking too much about how they’re doing it. They just get the job done be it on your app or your intranet.

The following five principles are based on getting stuff done simply, quickly and clearly because of good UX design.

What goes where and why — Structure

If you don’t understand your content — what it says, where it lives, how to find it — your users won’t either.

Before you can begin to think about UX design, grab your content and shake some logic into it. You’ve got to lay it all out and put it back together in an order that makes life easy for users.

Use speech cards, post-it notes, Google Sheets, mind maps, whatever you prefer; and figure out how to best organise your existing content and predict where future content will go.

To get you started, here’s Toby Ward and his intranetblog.com, with some sample intranet architectures: Intranet information architecture: don’t reinvent the wheel.

Keep in mind the titles, labels and copy users will expect to see and search for too. If you do this, you’re taking a big first step towards good UX design. You’ve got everything you want, now put it together.

Where you put what and when — Details

Especially important when you start to break down the purpose of each page on your platform.

Think about each stage in a user’s journey, whether they’re navigating somewhere or completing a task. Figure out what needs to be shown and at what point.

Decide the weight of the headline, the length of a summary, where the tags go, related links and share icons… whether this content is fair game for comments, or if it’s locked down and read-only.

For consistency’s sake use templates, so if there are multiple publishers on your platform, the UX design is automatic and they can’t go rogue. This, significantly, establishes familiarity which is an essential part of clarity.
Every element and component should justifiably be there, that justification being the users need it to be there. Collect the data, do the user testing and stakeholder interviews, and then design, just as Paul Boag advises in his blog: Why Intranet design is so bad and how to fix it.

How long is it and does it scan — Interactions

We’re not going to get into the quality of content here. How well written something is or how evocative an image might be. No, we’re assuming that’s done.

What we want to do is set the boundaries for that content to work as best as it can.

Get your grid patterns and layouts right and users will effortlessly absorb your information. Flowing down the screen with a focus and concentration that’s all (well, 70% at least) down to your UX design skills.

  • Line length: Think about line length, are lines longer than 14 words. They shouldn’t be.
  • Font size: Think about font size, is any of your text less than 12 pt. It shouldn’t be.
  • Headings: Think about headings, are there consistent subheadings. There should be!

Also…make sure it’s obvious that a link and a download are different. These are the small details that make a big difference on a subconscious level. And in 2020, they’re just expected.

For instance, think about examples of outstanding UX design you interact with every day. Strive for that, be minimalistic and tidy.

What goes where again and again and again — Standardisation

In 1996, Bill Gates predicted that content would be king. He was right. Although in today’s internet of everything, where content is blasted out everywhere every millisecond, for UX design to work well… consistency is king.

When users rely on your communications platform to do their jobs, they want to be two steps in front of every click and tap. They should ‘get’ your design without too many trial and error experiences and soon just know how it works.

Standardisation is multi-layered, but for brevity and your concentration span, we’ll focus on the consistent placement of information.

If your sub navigation is always on the left in a three column grid, don’t move it to the bottom right of a four column grid in another page. If your downloads are at the bottom of a page, don’t move them to the top for the sake of mixing things up.

Because here lies the problem: if UX design is not standardised it competes within and against itself. Sounds messy, it is. Don’t do it.

Make your communications platform a clear and obvious space because everything’s consistent and in the right place.

Where everyone can go, without a problem — Accessibility

You cannot achieve good UX design if you have not considered all of your users.

From the visually impaired to the physically disabled, accessibility standards include the elderly and people with slow internet connections too.

The key here is usability.

To have factored into your UX design what works for everyone. Are links clearly links? Is an image necessary and if it is, does it have alt text? What happens if a user tabs through the screen; does the content hierarchy make sense?

This topic is just too big to cover here and do it justice, so here’s the link you need (and we subscribe to) for WC3’s ‘Accessibility principles’.

Good UX design = clear communications.

We hope you found our brief tips useful. And clear.

If you have any questions about the advice or topics we’ve mentioned, please get in touch with us.

As a consulting team, we work with enterprises across the world. It’s our job to ensure their professionals can connect with the information they need to get work done each day.

Categories
Blogs Accessibility Apps consulting

Accessibility Guidelines: What’s new in WCAG 2.2?

Accessibility guidelines: What's new in WCAG 2.2?

What’s new in WCAG 2.2

The W3C is working on the next, and possibly last, 2.x version of the Web Content Accessibility Guidelines (WCAG). On 11 August 2020 a Working Draft of WCAG 2.2 was released for public comment.

As a W3C Working Draft, WCAG 2.2 is still a work in progress. It will almost certainly change before it becomes an official W3C Recommendation, but publishing periodic Working Drafts for public comment and review is part of W3C’s Process.

What do we know so far?

Based on the 11 August Working Draft, WCAG 2.2 introduces 9 new Success Criteria (SC), and upgrades 1 SC.

New Level A SC

There are 4 new Level A SC in WCAG 2.2:

2.4.1 Fixed Reference Points

When a web page or set of web pages is an electronic publication with pagebreak locators, a mechanism is available to navigate to each locator and each locator maintains its place in the flow of content, even when the formatting or platform change.

3.2.6 Findable Help

For single page Web applications or any set of Web pages, if one of the following is available, then access to at least one option is included in the same relative order on each page:

  • Human contact details;

  • Human contact mechanism;

  • Self-help option;

  • A fully automated contact mechanism.

3.3.7 Accessible Authentication

If an authentication process relies on a cognitive function test, at least one other method must also be available that does not rely on a cognitive function test.

3.3.8 Redundant Entry

For steps in a process, information previously entered by or provided to the user that is required on subsequent steps is either:

  • auto-populated, or

  • available for the user to select.

New Level AA SC

There are 4 new SC at Level AA in WCAG 2.2:

2.4.11 Focus Appearance (Minimum)

For the keyboard focus indicator of each User Interface Component, all of the following are true:

  • Minimum area: The focus indication area is greater than or equal to a 1 CSS pixel border of the focused control, or has a thickness of at least 8 CSS pixels along the shortest side of the element.

  • Change of contrast: The color change for the focus indication area has a contrast ratio of at least 3:1 with the colors of the unfocused state.

  • Adjacent contrast: The focus indication area has a contrast ratio of at least 3:1 against all adjacent colors for the minimum area or greater, or has a thickness of at least 2 CSS pixels.

  • Unobscured: The item with focus is not entirely hidden by author-created content.

2.5.7 Dragging

All functionality that uses a dragging movement for operation can be operated by a single pointer without dragging, unless dragging is essential.

2.5.8 Pointer Target Spacing

For each target, there is an area with a width and height of at least 44 CSS pixels that includes it, and no other targets, except when:

  • Enlarge: A mechanism is available to change the CSS pixel size of each target, or its spacing, so there is an area with a width and height of at least 44 CSS pixels that includes it, and no other targets;

  • Inline: The target is in a sentence or block of text;

  • User agent: The size of the target is controlled by the user agent and is not modified by the author;

  • Essential: A particular presentation of the target is essential to the information being conveyed.

3.2.7 Hidden Controls

Controls needed to progress or complete a process are visible at the time they are needed without requiring pointer hover or keyboard focus, or a mechanism is available to make them persistently visible.

New Level AAA SC

There is 1 new SC at Level AAA in WCAG 2.2:

2.4.12 Focus Appearance (Enhanced)

For the keyboard focus indicator of each User Interface Component, all of the following are true:

  • Minimum area: The focus indication area is greater than or equal to a 2 CSS pixel solid border around the control.

  • Change of contrast: Color changes used to indicate focus have a contrast ratio of at least 4.5:1 with the colors changed from the unfocused control.

  • Unobscured: No part of the focus indicator is hidden by author-created content.

Upgraded SC

SC 2.4.7 Is a Level AA SC under WCAG 2.1 but has been upgraded to Level A in WCAG 2.2.

Success Criterion 2.4.7 Focus Visible

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

What’s coming next?

The WCAG 2.2 Editors Draft is where changes are made before being approved by the Accessibility Guidelines Working Group. Editors Drafts are not stable but they do offer a glimpse of what may be coming in WCAG 2.2.

The WCAG 2.2 Working Draft is updated whenever the Accessibility Guidelines Working Group approves a set of changes. Although not completely stable, a Working Draft contains changes that have undergone peer review by the Working Group, so they are more settled than those in the Editors Draft.

Ultimately, WCAG 2.2 will become a Candidate Recommendation and then a Recommendation, and this is the point at which WCAG 2.2 becomes an official W3C standard and can no longer be changed.

In the meantime you can file issues and comment on discussions in the WCAG 2.2 Github repository, or send your comments to the Accessibility Guidelines Working Group by email.

Accessibility Guidelines: What’s new in WCAG 2.2?

Categories
Blogs Accessibility Apps consulting

3 positive habits for creating an accessible intranet or website

3 positive habits for creating an accessible intranet or website by Leonie Watson with image of Leonie
It is often assumed that an accessibility assessment (sometimes called an audit) is the first thing you should do when you want to make your website more accessible. If you want to know if your website conforms to a standard like the Web Content Accessibility Guidelines (WCAG), then an assessment is the way to do it, but if you want to move a little bit faster and start making changes that will make a real difference, there are 3 things you should get into the habit of doing.

Use an automated tool

It is important to understand that an automated tool cannot check for 100% of possible accessibility issues. For example, an automated tool can check if an image has a text description but not if the text description is appropriate or helpful to a human. Estimates very, but it is generally accepted that automated tools identify around 25% to 30% of possible accessibility issues. With that limitation firmly in mind, using an automated tool to check your website for accessibility is a useful thing to do. There are many to choose from including browser extensions like Wave, Tenon, Axe, or ARC Toolkit, Audit in Chrome dev tools, or external tools like Webhint.io. Whether you’re working on a pattern, component or page, get into the habit of checking it with one of these tools – and fixing the issues it identifies. As mentioned before, you won’t catch everything, but you will be about 30% closer to where you want to be.

Use the W3C Easy Checks

The W3C has put together a set of Easy Checks to help you get started with accessibility testing. The Easy Checks are based on WCAG, but unlike WCAG there are just 10 things to check (there are 78 in WCAG 2.1).
  1. Page title
  2. Image text alternatives
  3. Headings
  4. Colour contrast
  5. Resizable text
  6. Keyboard access (including visible focus)
  7. Forms, labels, and errors
  8. Moving, flashing, or blinking content
  9. Multimedia alternatives
  10. Basic structure
With the same warning that comes with automated tools, these Easy Checks do not cover all aspects of accessibility. What they do cover is some of the things that are most helpful to people who find seeing, hearing, moving, or cognitive processing difficult. If you get into the habit of using these 10 Easy Checks in complement with automated testing, you’ll take another big step towards a more accessible website.

Use assistive technologies

Every platform and device now has a range of different assistive technologies that can be enabled or installed. This includes screen readers, magnification or zoom capability, and (although it is not strictly speaking an assistive technology) the keyboard.

Keyboard

Abandon your mouse or trackpad and make sure all functionality can be navigated to and operated with a keyboard. Make sure that:
  • All interactive elements can be navigated to using the Tab key (or arrow keys where appropriate)
  • All interactive elements can be activated with either the Enter or Space keys
  • All custom controls can be operated using the keyboard
  • The interactive element that has focus is clearly indicated, and that it is always possible to see which element currently has focus

Screen readers

Turn on the screen reader for the platform you’re using and make sure all content can be navigated to, understood and interacted with using a screen reader. Make sure that:
  • The screen reader tells the user what kind of content they’re dealing with (link, button, heading, checkbox, list etc).
  • When there is an implied visual structure (table, list, heading hierarchy etc.) the screen reader announces it correctly
  • When navigating a data table the screen reader announces the row and/or column header as focus moves between cells in the table
  • It’s possible to move between landmarks (like the header, main content area, navigation and footer)
  • The purpose of every link is clear when using the dialogue of all links on the page
  • All interactive elements can be navigated to using standard keyboard commands or screen reader keyboard commands
  • All interactive elements can be activated using either the Enter or Space keys
  • All custom controls are announced correctly and can be operated using the keyboard

Magnification and zoom

Make sure all content can be navigated to, understood and interacted with at maximum zoom. Make sure that:
  • All content can be viewed without any overlaps
  • Multi-column layouts reflow to a single column
  • It is not necessary to scroll both vertically and horizontally to view the same bit of content
  • Page features are consistently located across the website
If you get into the habit of enabling these assistive technologies, or setting aside your mouse in favour of your keyboard, you’ll find you quickly start to understand how different modes of interaction work. With that understanding you can take another, albeit cautious, step towards better accessibility. The caution is based on the fact that you are most likely not a full-time assistive technology or keyboard user, so your experiences will not match those of people who are, but like most things – the more often you do it, the better you get!
Categories
Blogs Accessibility Apps consulting

What is an accessibility audit and what does it include?

what is an accessibility audit and what does it include? by leonie watson

Accessibility audit overview

The Public Sector (Websites and Mobile Apps) Accessibility Regulations of 2018 require public sector organisations to make sure their websites, intranets and apps meet Level AA of the Web Content Accessibility Guidelines (WCAG) 2.1.

Key dates for meeting the regulations​

New public sector websites (published on or after 23 September 2018)by 23 September 2019
All other public sector websitesby 23 September 2020
Public sector mobile applicationsby 23 June 2021

Typically an assessment or audit is used to find out whether the standard has been met (or not), but what is an audit and what does it include?

An accessibility audit is an assessment of your website or app against a set of recognised guidelines, in this case WCAG 2.1 Level AA. The purpose of an audit is to verify that your website or app conforms to the guidelines or to tell you what you need to do if it does not.

Representative samples

WCAG 2.1 is divided into principles and guidelines and each guideline has a number of requirements known as Success Criteria (or SC for short). Each SC is assigned a different level: Level A, Level AA, or Level AAA. There are 30 Level A and 20 Level AA SC in WCAG 2.1. The basic premis of an audit is that your website or app is checked against all 50 of them, but there is an obvious problem with this – in most cases it would take too long and/or cost too much to do.

The recommended approach is to audit a sample of pages or screens instead. The idea is that the sample is representative of the whole; in other words it should include at least one example of each page or screen layout, each different type of content, and each different type of functionality.

Procurement tip: look for services that include a test plan so you know exactly what will be included in the audit and what won’t.

If the sample is chosen well it should contain at least one example of most (if not all) possible accessibility issues. Once one instance of an issue has been identified within the sample, the same solution can then be applied to all other instances of the same issue throughout the website or app.

Procurement tip: look for services that offer detailed solutions for each issue and ask to see examples so you know the level of detail provided is what you need to be successful.

Testing tools

An audit is essentially a manual process but tools help make the process more efficient. The important thing is to know when to use a tool and when to do something yourself.

There are tools that can help with checking for things like colour contrast, line height and spacing, or for mistakes in HTML that cause accessibility problems. Developer tools in Firefox, Chrome, Edge and Safari all have features for inspecting the accessibility properties of web page code, and there are tools for scanning and inspecting native apps on both Android and iOS.

Automated tools are useful for quickly testing a lot of pages, but they cannot test for all accessibility issues. Estimates vary, but it is generally thought that automated tools can identify around 30% of possible WCAG 2.1 issues. Those issues are worth monitoring and fixing of course, and the number of issues detected by an automated tool is often a good indication of how well the website is doing overall, so automated testing is certainly a worthwhile part of the process too.

Procurement tip: look for automated testing platforms that are open about what can and cannot be tested automatically.

Assistive tech testing

An audit should include testing with different assistive technologies and alternate input devices, but there is an important distinction to draw between expert testing and proper usability testing: expert testing is carried out by people who do it professionally, usability testing is carried out with people from your target audience (who tend not to be professional testers).

There is a time and a place for both expert testing and usability testing because they both deliver valuable insights. Like consulting with a Doctor and asking someone who completed a first aid course for their opinion, you’ll get two very different but nonetheless valuable responses.

Expert testing is typically included in an audit, whereas usability testing is a separate but complementary service that includes participant recruitment, professionally led test sessions, and results analysis and reporting.

Procurement tip: look for services that are clear about the differences between expert testing and usability testing.

Results

Depending on whether the audit was carried out internaly or by a third party, the results will probably be presented in different ways.

The format isn’t really important though, what is important is that the information is presented in a way that is appropriate to the team who need to use it, that it’s apparent how well the website or app did in the audit, and that there is a clear path for fixing issues and ultimately to meeting the expected standard of accessibility.

Retesting

There is one final step to an audit and that is making sure that all issues have been addressed, and that no new accessibility issues were introduced along the way. Like all updates, changes and fixes to a website or apps, regression testing for accessibility should be done before considering the task complete.

An audit is generally a single event. Although it’s possible to carry out iterative audits throughout the production lifecycle, it isn’t a good way to avoid accessibility issues in the first place. 

Empowering teams with the knowledge and skills they need to design and develop accessible websites and apps, and QA testers with the ability to test for accessibility, is by far the best investment you can make. That said, when legislation like the Public Sector Accessibility Regulations require that a particular standard of accessibility must be met, an accessibility audit is a robust and reliable way to find out whether your website or app succeeds or not.

We're here to help

We are passionate about supporting organisations to create a great experience for 100% of users. Invuse – the new name for Invotra Consulting – offers both accessibility reviews and accessibility audits.

Get in touch today to see how we can support you.

Categories
Blogs Apps business analysis communications consulting design ux

4 key stages for effective business analysis

4 key stages for effective business analysis

4 key stages for effective business analysis

With any internal communications platform, it is vital to embed an experience that supports your culture and is focused on meeting user needs.

In order to achieve a platform that meets all of your organisational needs, the process has to begin with a thorough analysis from all stakeholders and target audiences.

Ensure you have the means to discover and analyse the following:

  • What do your users want from the platform?
  • Who are the stakeholders, and what does success look like for them?
  • The process of transitioning business needs into technical requirements
  • How can you design the platform and the service model to allow you to continuously evolve your platform when your user needs change?

1. Understanding your users (User research)

The success of internal communications depends on analysing your end users, then fully understanding their behaviours, needs and motivations for using your current internal communications platforms.

To gather this information, a range of processes are available and one or all may be appropriate to your users:

  • User interviews can offer more in depth understanding of what does and does not work, perhaps to take place after a questionnaire or survey has helped to identify the main challenges your users are having.
  • Interactive Workshops that analyse a number of tasks that users would usually be asked to complete. Observations of your user’s behaviours can help to identify any challenges faced when completing the tasks.
  • Platform analytics allow a better understanding of the types of journeys your users are taking. Identifying recurring trends will help to understand challenges your users are facing.

Once feedback is gathered, analysed and combined with any available data analytics, you will have a better understanding of the bigger picture of the challenges your users face with your internal communication platforms.

This thorough evaluation of your previous or existing platform(s), will determine what things worked well and what things didn’t, helping you to create a plan to ensure your new platform meets all of your users’ needs.

2. Understand your data (Data mastery)

At this stage, you have established what you need to achieve and you are able to move on to the ‘how’.

Data Mastery & Integrations

It’s really important to understand the information your users are looking for on your platform, the types of data that provide this information, and where that data should be mastered.

Often, it’s a lot more beneficial to master your data in a ‘single source of truth’ and then integrate this into your platform(s). This prevents information becoming outdated and inaccurate across multiple platforms. For example, an Active Directory mastering all of your user data.

By analysing the data that will be included on your platform, you’ll have a better understanding of the stakeholders that you’ll need to engage as part of your project to avoid any surprises and gaps in resource.

3. Identifying your stakeholders (Stakeholder engagement)

Determining your success criteria demands an understanding of the requirements in all parts of your organisation. Different departments will have different goals so it’s important to implement a solution that meets as many needs as possible.

Defining the objectives involves identifying exactly what your stakeholders want. Do they need a tool to improve engagement and collaboration, or do they value a place to house all of your documentation such as policies and manuals more?

A successful solution requires you to connect the dots between all stakeholders, creating and structuring success criteria for your communications platforms, to deliver a meaningful outcome for each of your stakeholders and their users.

  • Creative stakeholder workshops can be useful, with the primary focus of understanding the collective thoughts of the wider team of what is and isn’t working with your content and communications strategy.
  • Stakeholder interviews, and using questionnaires and surveys, can also establish a clear understanding of their thoughts on current and prospective content and communication strategies.

Once you have established stakeholder requirements your information strategy reviews are made much more straightforward.

Everything achieved so far will be identified, and you will have a much clearer view of any challenges that may prevent you from delivering.

In identifying who your platform stakeholders are, you will also introduce accountability to the platform which will ensure the system is always valued and invested in.

With all this addressed, you are in a position to outline your initial vision, what you want to achieve and also establish Key Performance Indicators (KPIs) to monitor progress.

4. Identifying the best solution (Solution mapping)

Once you’re aware of:

  • the challenges your users are facing
  • the stakeholders who are going to help you make the platform a success
  • the types of data and information that will be on, or plugged into, your platform

all that’s left to do is select your preferred solution. At least you thought.

All of the above provides you with half of the information you need, the second half is actually understanding whether there is a platform on the market for you to procure out-of-the-box, or if you need to build it yourself and therefore find the resources to do so.

On many occasions, an out of the box product will never meet 100% of your requirements from the outset, so it’s important not to expect it to.

Categorise your final requirements into:

  • must haves
  • could haves
  • should haves

and focus primarily on finding a solution that delivers 90% of the former and allows you to get the ball rolling.

Then, work with a trusted supplier to define a roadmap that helps you achieve the final 10% and targets the could/should haves in the following 3-6 months.

Alternatively, if you have the resources to do so, map your requirements into technical specifications, along with user journeys, and the challenges that will be overcome, before designing and developing a new platform.

You don’t have to do this alone, there are some great suppliers out here with decades of experience in your section and others who have lots of learnings to share.

Remember, whether you procure an out of the box product, or develop a solution yourself, be mindful of the following.

  1. User research and data analytics to drive each of your requirements for the platform
  2. Ensure your platform works just as efficiently independently as it does when connected to others
  3. Your platform should allow you to iterate easily, and evolve when your business needs do so

Talk to us

If we can support you with Business Analysis or you’d simply like to learn more, please feel free to talk to us.

More blogs by this author

Categories
Blogs Apps Javascript Uncategorized

How to use APIs to build Javascript Apps

How to use APIs to build Javascript Apps

Javascript as a language has now evolved to a place where it’s used to build both frontend and backend server applications.

It is a high level scripting/programming language built into all modern browsers, enabling dynamic functionality to be added to static web pages, and enables the creation of single page web applications seen in everyday use from Google’s GMail application to Twitter’s website.

This blog will highlight the main parts and concepts involved in creating a simple Javascript Application, concluding with a ‘sum of all parts’ working application. As you’ll see in the diagram below, 3 parts are required to deliver a functioning app.

Delivering a functioning app

The first of these is the client’s device which can be a laptop, pc or mobile device running a modern browser such as Chrome, Firefox or Edge.

Each browser includes an interpreter which executes JavaScript code. V8 is Google’s open source (http://v8.dev) high-performance JavaScript engine, which is written in C++ making it easily portable to any platform. It is used in Chrome and also in the new Microsoft Edge browser, which was released in January 2020.

The next is the Web Server, which is responsible for serving up files (such as html, images, javascript, etc) over HTTP to the users browser requests. The most popular Open Source Web Servers are Apache and Nginx, between them they run most of the websites on the internet.

The final piece is the Application Server, which is used to host the application that the Javascript app will talk to, over its API (Application Programming Interface).

The API is a specification of the functionality that the application provides, it is intended to enable software components to communicate with each other. The concept behind API’s is that they should abstract away the more complex functionality of the application’s code and provide a simple, easy to use interface for other applications/programs to be able to use. When two systems connect together via an API we say that they are integrated. In an integration, there are two distinct sides: the client and the server, the server is the side that runs the program that provides the API, and the client is the side that uses/consumes the API.

OpenAPI is one of the more popular API specifications, it was previously known as Swagger, it is used to define the API endpoints as well as the format of the response messages which are defined in JSON, a machine-readable data format.

The following are an example of the steps necessary for a Javascript app to request and display a list of contacts.

Stages 1-2

The browser makes a http request to https://www.example.com this requests the index.html page from the Apache web server. Once the browser processes the index page any additional referenced items from the index page such as css, images or javascript are also loaded and then in the case of javascript the script/scripts are run.

Stages 3-4

Once the Javascript app has started up in the browser, it makes a https request, for example to retrieve a list of contacts, to the application server via https://api.example.com/contacts/list which on success returns a list of contacts in json format

[
 {
   "name": "Cassio Zen",
   "email": "cassiozen@gmail.com"
 },
 {
   "name": "Dan Abramov",
   "email": "gaearon@somewhere.com"
 },
 {
   "name": "Pete Hunt",
   "email": "floydophone@somewhere.com"
 }
]

Once the application has received the json data response from the API, it uses this to render a list of the contacts in the browser.

This has been a high level overview of how javascript applications work in combination with APIs, the next blog will cover the security and authentication side of APIs.

Talk to us

If you’d like to talk to someone on our team about this topic, please get in touch.

More blogs by this author