Koa11y 4 design and planning discussion.

[TheJaredWilcurt]

There are a lot of possible new features that could be added to Koa11y that would require us to update and change it's, currently, very simple interface.

New designs for Koa11y should retain all existing functionality:

• URL
• Filename
• FileType (HTML, CSV, JSON, Markdown, XML)
• Standards (508, A, AA, AAA)
• Output Folder
• Image Alts (copy console code/paste image array into textbox)
• Enable/Disable returning results for Errors, Warnings, Notices
• Run

New designs should take into consideration possible new features:

• Creating multiple projects
• Grouping projects
• reorganizing projects
• Allowing Pa11y Actions on a per project level
• Settings for language selection (en, de, fr, etc.)
• Settings for possibly different engines (Pa11y, aXe, etc.)
• Changing what controls are shown depending on the engine (standards, filetype, etc.)
• Running a group of projects all at once
• Checking for updates

[Johnsoct]

Since there are many different considerations and needs (language selection, multiple projects, inputs, etc.), we could pick a design style and build out individual components.

Advantages:

• Easier to manage individual components
• Easier to organize and perform usability and accessibility tests on a single component than an entire built application
• Having a component repository would be great for future feature additions we don't predict today
• Easier to focus on one component at a time
• Easier to collaborate and work in parallel
• Great way for newcomers to learn about UX, design, and accessibility by focusing on core concepts within smaller problems (such as contrast or button color)

Disadvantages:

• Many more pieces
• Requires more organization
• Doesn't resemble a complete project
• Possible lack of vision for a final product

[TheJaredWilcurt]

@Johnsoct We will be doing what you are suggesting, but that comes later.

The purpose of this issue page is to centralize the planning of Version 4's design. It is for the big picture. I'd like to have all the wireframe's and ideas for it in one spot so we can discuss the pros and cons and each idea. How everything interacts together. Then from that we will gain a stronger understanding of the best design solutions we can implement. What you are suggesting will come when it is time to implement each individual feature. But first let's figure out which things we need before we start building stuff we don't.

Here are some examples of this process:

• #186 Scout-App 2 - Planning out how to move forward with Scout-App. Oct 17, 2014 - Aug 30, 2016
• #273 Redesign FTUX - Improving the First Time User Experience. Oct 11, 2016 - Dec 5, 2016
• #285 User Experience Overhaul/Scout-App 3 - General discussion, design critique and potential planning for Scout-App 3. Nov 16, 2016

Since version 3 of Koa11y will have a lot more features than version 2, we'll need a place to put them in the app, and more importantly we'll need a way of conveying they exist and how to use them in a natural, intuitive, and accessible way. That process will take some time and effort.

If we start building individual components without any idea of the big picture or how those components will connect or where they will be placed it will waste a lot of development time creating something that will need to be recreated later once the designs are improved. It's much cheaper in cost of development time, to do our trial and error in the wireframing phase than in the coding phase.

Plus we've already been through that pain once on Koa11y. We rushed ahead and made something functional as quick as possible, and we are still paying for that by refactoring the code to be more easily maintainable and modifiable.

[TheJaredWilcurt]

Here is one way we could proceed. It solves all the problems noted above. With the exception of where to place a switch for the engine (Pa11y/aXe). Since the two engines may accept different required parameters, I would think it should go at the top of the "Required" tab. Since it can be a per-page setting. Changing it should change out the form elements below to reflect what is required for that engine.

We should also add to the list of things that need designs a First Time User Experience (FTUX). How do we go from an empty state to walking the user through creating their first report without it being confusing or intimidating.

[TheJaredWilcurt]

Possibly add in a checkbox next to the page name in the sidebar to allow enabling/disabling when running the whole group.

[ryanparrish]

I am not super stoked about this idea yet it needs more work

[ryanparrish]

This is a second idea I had for the app

[Johnsoct]

@ryanparrish I can go through and give you feedback on these designs if you'd like? I can be a soul-crusher, though.

[ryanparrish]

@johnsoct it can't be worse then an art school critique:)

[TheJaredWilcurt]

Visually it is an improvement over the wireframe. It seems to be missing how to interact with the contents on the sidebar.

Maybe the controls for running individual pages should only exist on their page, and the controls to run a group all at once should be accessible only when you click on the Site name in the sidebar. Then it would have like cards or something of all the pages for that site with a summary of their settings. and you can enable/disable what gets ran in a batch.

[Johnsoct]

@ryanparrish what I do have are a very particular set of skills, skills I have acquired over a very long career. Skills that make me a nightmare for people like you.

[TheJaredWilcurt]

Quick mockup of the idea. Card design would need a lot of work. Maybe there is a better way to display them than as cards too.

[ryanparrish]

This page is how a user would add a page to a group

[ryanparrish]

I had some thoughts about the side nav as well

[TheJaredWilcurt]

I think it would make more sense to store links to the files inside the page settings as another tab (required, image alts, actions, reports).

[ryanparrish]

I am trying to wrap my head around the Required Image Alts and actions part of the cards

[TheJaredWilcurt]

@ryanparrish Those are a really good start.

Here is a screenshot of the existing App (V3)

The pink border contains the "Required" settings. The Blue border contains the "Image Alts" settings. However both sections will be redesigned in the new version. The "Actions" settings are being designed in Issue https://github.com/open-indy/Koa11y/issues/27.

[ryanparrish]

[TheJaredWilcurt]

deactivated cards can still be edited. Editing is only disabled when a page is being ran/processed.

[ryanparrish]

I will make the change. When I was running a batch of cards. I was thinking that it might be an easier workflow for the user if they could make the change at the card level rather than having to go to another page to make the changes.

[ryanparrish]

These are concepts around activated cards