Version 2 Roadmap

[bbertucc]

Overview

For Equalify to compete with existing enterprise solutions, we'll need to make significant changes. This ticket details our work toward realizing those "Version 2" features. Not all features will be incorporated. Strong opinions on what we work on are always appreciated.

Process

Feature Development has the following process (we'll tick off items as we work through them:

• User Story Development(Version 2 Roadmap #373): Develop descriptions of the users we're building for. These should be educated by past work. Note: All users work toward the same goal: fixing accessibility issues.
• Design Phase (Version 2 Frontend Design #492 ): We'll mockup features in a visual and text-based design document that helps work out a cohesive user experience for sighted users.
• Roadmapping: All features will be added to a product roadmap, which will prioritize features that customers want.
• Development: We'll continue to develop all features on this Version 2 roadmap.

Key User Stories

Equalify is built to fix web accessibility issues, so every user story is focused on that goal. These are the core users that Equalify is hoping to reach:

Developers

Developers, experienced and new to accessibility, will use Equalify to fix issues. After adding pages, Developers would be notified of any new issues related to reports. They don't want to be bugged a lot, so they would need to change the frequency of issues they are notified about. Some developers need hours approved to work, so they should be able to share reports. Developers also hate any UX that they didn't create, so API access is vital to generate raw data that Equalify uses. Developers who are experienced with web accessiblity also use tools, like https://wave.webaim.org/report to visualize issues that they need to fix, so a way to visualize would be key to fixing issues.

Accessibility Managers

Accessibility managers make sure thousands of pages remain accessible to people with disabilities. They like to have a general view of issues. From those general views they create specific tickets that developers execute on. Some tickets include a lot of nodes related to a message. Others are specific about an individual node or page. Accessibility managers also want to ignore nodes that they don't think are useful or create custom scans for information that governance policies require. A job well done is reducing the number of issues per page over time. Accessibility Managers will share these reports of successes with their bosses, or add peers to the account to view or create their own reports. Finally, Accessibility Managers really love emails. They follow updates and continue to use Equalify with regular emails sent.

Agency Owners / Executives / Purchasers

Agency Owners love reports that get their clients to pay them for additional work. An agency owner may add their existing clients into Equalify and forward emails or share reports when an issue occurs. Once a client pays for a fix, the agency owner will create a ticket for his developer or share a link to the report. Agency Owners can make clients happy by showing them a report that proves they decreased the density of issues per page.

Blind Accessibility Professionals

Professionals who rely on screen readers are important users of Equalify. Oftentimes, these testers lead accessibility decisions at their organizations. Blind accessibility pros should be able to analyze Equalify reports, just like other accessibility managers. Additionally, Blind pros can validate issues that are reported in Equalify - marking them as ignored if they are false positives. Equalify can also act as the eyes for a blind user, testing for issues that they might miss because they rely on screen readers.

[bbertucc]

@kevinandrews1 any additional accessibility items we should put on our Version 2 wish list?

[bbertucc]

We'll probably put this up for bounty. Assigning @wilsuriel03 because he expressed interest, but open for any feedback / ideas.

[bbertucc]

@wilsuriel03 added three critical things:

• Node history
• Option to Ignore
• Notifications

[bbertucc]

We'll have to refine the bug reporting tool. @alexstine reported:

Actually, it looks like Sentry is injecting this Report a Bug button. We probably need to remove this as it is a 3rd-party widget and we've got little options to fix it as it is loading in the shadow root.

@wilsuriel03 responded:

I can come up with something cool for V2, but right now, I don't see any problems with the sentry button.

@alexstine reported:

The main issue is it opens a dialog and does no focus management. It's tricky experience but not a blocker. I would like us to roadmap it for V2.

[bbertucc]

@azdak @wilsuriel03 I updated this ticket with User stories. I also added user stories to a google doc, here, and added a bunch of comments to the figma file.

[bbertucc]

From @wilsuriel03 :

I’ve put together a detailed user flow based on what we’ve discussed and the new user stories. However, there are a few things that still need clarification to make sure we’re aligned on how these features will work before we finalize the design and move into development.
Here are the key areas we need more details on:

1. "Pages" vs. Properties
   You mentioned wanting to replace the Properties page with something called "Pages." It would be great if you could describe exactly what a "Page" is, how it differs from a property, and how the users will interact with it. Are Pages entities for individual URLs? Will they have unique features or settings compared to properties?
2. Reports Across Multiple Properties
   You also mentioned that reports can now be tied to multiple properties (or Pages?). Could you clarify how this works? What is a report in this new context, and what’s the purpose of a report if it’s connected to multiple entities? How will users manage and navigate these multi-entity reports?
3. Defining Features and Setting Boundaries
   We’ve added a lot of flexibility to the user roles and features, but I think it’s time we set some clearer boundaries on what’s available to which users. For example:
   What features are exclusive to certain user roles? (e.g., Can individual users share reports? Who has API access?)
   What are the core features we absolutely want to offer in v2?
   How do we balance flexibility with ensuring the platform remains simple and accessible?
4. User Flow Review and Adjustments
   I’ve attached the user flow we’ve created for Equalify V2. Please use it as a template, and feel free to edit or adjust as needed. It’s important that we lock in the specific steps, workflows, and permissions for each feature, so we don’t end up with confusion during the design and development stages.
   The goal is to finalize this flow so we can move forward confidently, knowing that the user journey makes sense and the features are clearly defined.
   Once we’re aligned on these points, we’ll be in a solid position to finalize the designs and proceed with development!
   Looking forward to your feedback. Let me know what changes or clarifications you have in mind.
   Here is the link to the user flow we talked about: User Flow Document

@azdak do you think you can take a first pass at this? I know you have some good rationale around the dashboard and pages vs properties.

[azdak]

"Pages" vs. Properties
You mentioned wanting to replace the Properties page with something called "Pages." It would be great if you could describe exactly what a "Page" is, how it differs from a property, and how the users will interact with it. Are Pages entities for individual URLs? Will they have unique features or settings compared to properties?

Reports Across Multiple Properties
You also mentioned that reports can now be tied to multiple properties (or Pages?). Could you clarify how this works? What is a report in this new context, and what’s the purpose of a report if it’s connected to multiple entities? How will users manage and navigate these multi-entity reports?

So I think it'd help here to outline how the system works now. Currently, we have a "Properties" page, which lists all Properties.

Properties (current)

• Each Property is actually a collection of pages
• Pages are basically just a single URL (which we can scan/track/etc)
• Pages are 'added' to a property under Property->Edit Property by inputting a URL:
  • A single page URL will just add that URL to the Property
  • A sitemap URL will add all the pages in the sitemap to the Property

Now, obviously this setup is confusing to users (or else we wouldn't be having this conversation), and makes it a little unclear what pages are in the system, and what the system is actually doing.
So the proposed change would be treating "Pages" as the base entity, and through the UI/UX making clear that Properties are in fact just user-created collections of Pages.

So:

Pages

• The "Pages" screen will replace the current "Properties" screen
• Each Page is a single, scannable URL
• The "Pages" screen should be a filterable/sortable table of these URLs, perhaps broken down by domain name.
• "Properties" would remain, but would be explicitly shown to be a collection of pages- similar to a tag or category in other apps, and be a drilldown option, not a base/top-level one
• Example:
  • "mysite.com/some-cool-page.php" is a Page
  • That page could be added to a "Property", which would have a user-defined name and could contain an arbitrary number of pages ("My Cool Pages")
  • That page would have a "Domain" of "mysite.com"
• So the overall information architecture would be Pages->Page and Pages->Properties->Page, not Properties->[unclear], which is what it is now.

Reports

• Reports are summaries of the scan results of many pages.
• When creating a Report, users should first add Pages to the report. Either:
  • Individually, by selecting and adding each page, or
  • In bulk, by selecting Properties and adding each property
• After adding the desired Pages/Properties to the report, the user should be able to Filter by the scan results: Messages, Tags, Types, etc.

Does that make sense? I think this should make the UX more conceptually intuitive, and better clarify to users what's actually happening in the app. I also think that this is really more of a presentation change, and shouldn't require a ton of changes/rewrites to the backend (but would love any thoughts/feedback from @heythisischris on that aspect).

[bbertucc]

@azdak did a good job of touching on pages and reports. Let me now discuss the other items you mentioned @wilsuriel03:

What features are exclusive to certain user roles? (e.g., Can individual users share reports? Who has API access?)

For the purpose of the mockups, each user should be assigned to set various hypothetical actions. Here are some examples:

• Change Report Visability
• Edit Report Filters
• Add and Delete Users
• Update Billing Details
• Create Custom Scans
• Manually Trigget Scans

What are the core features we absolutely want to offer in v2?

The features we'll offer in version 2 are listed under the "Requirements" section, but things will change. Mockups will help us guide our roadmap.

How do we balance flexibility with ensuring the platform remains simple and accessible?

These mockups need to be able to speak to all the features listed under requirements because those are the features that other competitors have. We might not build them. These mockups are made to visualize a roadmap that we can use to get clients excited.

[bbertucc]

Just pasting a message from @azdak on Slack:

Still working through it, but one big thing I would note is how reports work: first off (I talk about this in the Pages writeup as well) but Reports start with collections of pages, and then we're filtering the scan results from there. The other big thing is that the way we're presenting issues/"messages" in reports isn't actually reflective of what axe is giving us back- we're just treating everything (messages, tags, urls, etc) as top-level entities, but really it's hierarchical, with nodes (ie the code snippet with an error detected) being what's returned, and each node then having attached messages, url(s), and tags (I've attached a flowchart to show what I mean).
Users can and should be able to drill down and get all the nodes with a particular message, or all the nodes on a particular page, etc, but at core node is the base entity. This ambiguity in our current presentation/organization of the data is imo what makes it so confusing (and is why we currently have so many ''messages" that appear to be duplicates- they're actually just multiple messages about an error tied to a snippet, but we're presenting them as independent).

[bbertucc]

@wilsuriel03 i don't think it's necessary to turn the axe-core data architecture that @azdak described into the UX. That's because nodes mean very little to accessibility pros. They are first looking at the messages related to the nodes, then they ignore messages that mean nothing to them by ignoring nodes inside those messages.

If we showed an accessibility pro a list of nodes, the first thing they would do is group them by messages. Which is the UX we already have.

[bbertucc]

I was totally dumb to the actual problem, which is this:

Currently, the messages table has a count that makes it seem like there are a ton of issues per message. But, it's really representing how many nodes each message is connected to. Furthermore, that doesn't actually speak to the total number of nodes because a single node can contain many messages.

We need to figure out a way to create something called "Violation". Violations are Rule Messages. Violations include Check Messages, associated to those Rule messages.

Another issue is the numbers (active + equalified) are not actually counting the number of violations that are fixed or active. A node has multiple messages associated with it. The node will not technically be marked "Equalified" until I fix all the messages associated with it. That needs to be visually displayed.

[wilsuriel03]

Compensation Request: Equalify V2 UI/UX Design Work

Overview

This comment outlines the work performed on Equalify V2's UI/UX design from May 16, 2024 – October 31, 2024, encompassing the design and development of 15+ core pages, 20+ interactive components, and multiple complex features. The scope involved creating user-centered, accessible designs for Equalify's core functionalities, incorporating feedback, and iterating based on evolving requirements.

Key Contributions

Initial Design and Mockups (May - June)

• Created comprehensive design brief covering authentication, onboarding, and core platform functionality
• Developed detailed user flows for authentication, account management, property management, and reporting
• Designed foundational UI components including timeline visualizations, message lists, and node management interfaces
• Implemented WCAG 2.2 Level AA standards across all designs
• Delivered 10+ complex modals and 8+ custom dropdowns for various user interactions

Revisions and Feature Additions (June - August)

• Developed advanced filtering and management systems with multi-select capabilities
• Enhanced dashboard components with violation breakdowns and monitoring alerts
• Created comprehensive Trial Report experience with progress indicators and upgrade paths
• Implemented detailed property management features including bulk actions and CSV import
• Designed 5+ data visualization components for metrics and status tracking

Monitoring Features and Advanced Systems (August - September)

• Designed complete monitoring system with real-time change tracking
• Developed chatbot interface functionality with ML model interaction patterns
• Implemented credit system for scan management
• Created automated report generation system
• Enhanced accessibility features with customizable appearance settings and screen reader-optimized interfaces
• Delivered 6+ management interfaces for various system controls

Entity and Workflow Redesign (September - October)

• Completed platform architecture revision, transitioning from "Properties" to "Pages"
• Integrated comprehensive user stories for developers, accessibility managers, agency owners, and blind professionals
• Implemented node and rule management with ignore functionality
• Enhanced report automation with density tracking and custom filtering
• Delivered complete settings dashboard with 5+ subcategories

Challenges and Revisions

The project involved significant complexity due to evolving requirements and competitive considerations:

• Continuous adaptation to changing feature priorities based on market competition and client needs
• Balancing enterprise-level functionality with intuitive user experience
• Deep integration of accessibility requirements across all features, ensuring usability for both sighted and screen reader users
• Complete restructuring of entity relationships to simplify user workflows
• Extensive research to maintain competitive edge while prioritizing accessibility
• Regular refinements based on evolving product roadmap and @bbertucc's vision for the platform

Proposed Compensation

After reflecting on the depth of this work and its impact, I propose a fixed compensation of $5,555 for the work completed from May 16, 2024 – October 31, 2024.

This number reflects:

• Over 250 hours of dedicated design and research work
• The significant value added to Equalify V2, aligning it with high accessibility and usability standards
• Development of 15+ core pages and 20+ interactive components
• Comprehensive scope of work, including multiple major feature additions and revisions

Future Work

As agreed upon in our contributors meeting on November 18, 2024, I will be transitioning to an hourly rate of $70/hr until we secure investor funding. This arrangement ensures clarity and alignment with the project's current phase.

Next Steps

1. Approval of the proposed compensation
2. Transitioning to an hourly model for future work
3. Continuing collaboration on any remaining deliverables

Looking forward to your thoughts and feedback on this proposal! 😊

[bbertucc]

@wilsuriel03 $5555 breaks our bank! I understood you were volunteering your contribution because it wasn't part of an approved bounty. Open Source projects, especially with as tiny a budget as ours, rely on a lot of volunteer work. Our bounties are a mere token of appreciation, with the knowledge that everyone is worth a lot more.

I'm going to pay you $1111 and just call it a lesson for both of us on the importance of communicating expectations. I'm also going to forfeit my payment for #492 and I updated the handbook with a note on bounties: EqualifyEverything/handbook@afa15dc

As for the other work, I would like to focus your time on "styled mockups" I mentioned in #492. Our design process needs to be screen-reader first, focused on making our platform accessible to people with disabilities first and foremost. Once we have developed our screen reader spec and system architecture, we will be ready for mockups. I know seeing your work realized is really important to you. The structure we've laid out in #492 gives your design the best chance for making Production. Before that, I would also like to include you in the reviews of the screen reader spec and system architecture, as mentioned in #492.

Thanks again for all your hard work. I know it's a bummer not to get all the money you expect. In my years of Open Source contribution, I've realized that volunteer work has a funny way of paying off. I'm pretty sure it'll pay off for you too. ❤️

[wilsuriel03]

@bbertucc ,

Thank you for your response and for acknowledging the work I've done. However, I feel compelled to clarify a few things, as this situation doesn't align with my understanding of our initial agreement or the expectations that were set.

1. Bountied Work and Expectations

When I began contributing to Equalify V2 in May, it was with the understanding that this work was bountied. You specifically tagged me on tasks because you knew I was interested in contributing and had already started working on the design. I recall messages and conversations where you mentioned that this would be compensated work.

I made repeated attempts to clarify the compensation structure and discuss pricing, but these questions were either delayed or went unanswered. Despite this, I continued contributing because I believed we were aligned on this being paid work.

2. Volunteer vs. Paid Work

Nowhere in the documentation or discussions was it ever stated that my work was voluntary. If that was your expectation, it should have been made clear from the beginning. However, my understanding was that I was "hired" to redesign and improve Equalify V2, and I proceeded with that mindset.

Volunteer contributions to open-source projects are often explicitly stated upfront. In this case, not only was compensation implied, but there was also active encouragement for me to invest significant time and effort into the platform.

3. The Value of the Work

Over the course of 6+ months, I dedicated 250+ hours to Equalify V2. This work went far beyond mockups or minor tweaks; it involved:

• UX research
• Extensive design iterations based on evolving feedback
• Accessibility-focused enhancements to align with WCAG standards
• Strategic rethinking of core entities and workflows

This level of effort and expertise added significant value to Equalify, making it more robust and aligned with its mission of accessibility.

4. Compensation Proposal

While I understand budget constraints, $1,111 is not reflective of the work I've done or the value I've contributed. It also undermines the understanding I had when I began this project.

My proposal of $5,555 was thoughtfully considered to balance the value of my work and Equalify's financial situation. I've kept the amount below what it could have been, taking into account that we currently have around $28k in the bank, as you mentioned, and recognizing the outstanding payments to Trey, Chris, and Kevin.

I also want to stress that I'm not rushing for immediate payment. I understand the timing of funds coming in and am more than willing to work with you on a timeline that works for Equalify. For example, we could arrange for half to be paid now and the remainder when additional funds are available.

5. Moving Forward

I'm excited to continue contributing to Equalify and helping it achieve its mission of accessibility. Moving forward, I believe having clear expectations will help us work together more effectively and keep the focus on Equalify's goals.

I deeply care about Equalify and its potential to make the internet more accessible for all. I've treated this project as if it were my own, but I also need to ensure that the effort and value I bring to the table are recognized fairly.

If there are any points that require further clarification or additional context, I’m happy to address them here to ensure transparency and alignment.

[bbertucc]

@wilsuriel03 I am going to stick firm to the $1111 amount I paid you for unbudgeted work.

Again, I stress the need to clearly budget and get my approval via a bountied issue on GitHub for any work you expect to be paid on. We've all volunteered a lot of time to Equalify. It's important any work that you don't consider volunteering to be clearly budgeted in a bounty ticket that is approved by me.

[wilsuriel03]

I appreciate your response, but I cannot agree with your stance on this matter. From the beginning, it was clear that the redesign work for Equalify V2 was to be compensated. Around May 17, I began working on V2 following conversations we had about its direction. On May 21 (screenshot attached), you acknowledged the redesign efforts, and by July 23 (screenshot attached), you explicitly tagged me on GitHub, stating the work would “probably be put up for bounty” and assigned me the task.

Over the following months, I dedicated myself to the redesign, making changes and incorporating your requests. During this time, I repeatedly raised the topic of compensation, as shown in my October 8 Slack message (screenshot attached). My questions were ignored or left unresolved, which is why we find ourselves here now.

Unfortunately, I cannot provide screenshots of earlier Slack conversations due to Equalify's Slack workspace limitations, which hide messages older than 90 days. However, I stand by my recollection of our discussions where you mentioned this work would be paid. If there were any misunderstanding, it arose from the lack of clarity in your responses, not from my side.

The notion that this work was voluntary is simply inaccurate. To my knowledge, no current contributors—including Trey, Chris, or Kevin—have done unpaid work for Equalify. All contributions have been compensated through bounties or maintenance payments. This makes the treatment of my six months of work on the V2 UI/UX design different and, frankly, unfair. If this work had been framed as unpaid from the beginning, I would not have approached it in the same way.

The $1,111 you sent doesn’t reflect the scope or value of the work completed. I stand by my request for $5,555, which is a fair and thoughtful amount considering the time and effort I’ve invested. I’m open to working with you on a payment plan or timeline that fits Equalify’s current situation, but I hope we can align to resolve this matter fairly and appropriately.

I value Equalify and its mission, but this situation needs a fair resolution for us to move forward positively.

[bbertucc]

@wilsuriel03 Your comments have honestly kept me up at night, struggling with the reality that we can’t bow to the desires of every contributor, no matter how much I wish we could. My heart would love to distribute funds as freely as possible, valuing everyone's vision and passion over the constraints of budgets and money. But Version 1 taught me a hard truth: management is necessary if we’re serious about achieving our goals.

Every step we take must directly align with our ultimate mission—making accessibility more accessible—and position us to challenge companies like SiteImprove, which do not share our values.

To that end, I need to clarify that compensation at Equalify has always been tied to tasks with approved budgets in GitHub tickets. Since the time spent on your redesign work was not defined or approved in this way, it cannot be compensated directly. The $1,111 I sent is a token of appreciation for your efforts, reflecting Equalify’s gratitude while staying within the boundaries of our process and financial reality.

Taking on the role of “manager” was never part of my ideal world, but I know it’s necessary if we’re going to realize any ideals at all. I hope we can continue to align on the importance of this mission and move forward with clarity and purpose.

As noted in #492, I would love to continue getting your feedback on frontend points and eventually have you develop a styled mockup from validated direction. Additional work would have to be figured out after we go through the complete design process.

[bbertucc]

Closing this in favor of #500 that's more focused on the task