Finalize and Launch Minimum Viable Frontend for Equalify V1

[wilsuriel03]

As we approach the crucial stages of the Equalify.app redevelopment, I propose a structured plan to complete the frontend development, ensuring seamless integration with the backend and establishing a robust foundation for the upcoming V1 release. This proposal builds upon my initial work and the collaborative efforts with our backend development team led by @ heythisischris.

Objective

Finalize the frontend development for Equalify, ensuring it is fully functional, seamlessly integrated with the backend, and prepared for comprehensive testing and deployment.

Development Phase

The primary focus will be on implementing the interactive components and integrating API endpoints that Chris is developing. Key tasks include:

API Integration:

• Work closely with Chris to integrate new backend endpoints as they become available.
• Ensure all views and components are dynamically populated with data from the backend, transitioning from mock data to live data feeds.

Action Implementation:

• Develop and test frontend actions for property and report management, including adding, updating, and deleting properties and reports, as well as queueing scans.
• Implement frontend logic to handle these actions, ensuring they interact correctly with the backend.

Enhanced Testing:

• Expand our testing framework to include Cypress for end-to-end testing, ensuring all user flows work as expected.
• Increase coverage of unit tests using Vitest to ensure reliability and stability.

Accessibility Enhancements:

• Continuously evaluate and enhance the accessibility of the platform, ensuring conformance with WCAG 2.2 Level AA standards.
• Collaborate with accessibility testers like Kev to refine and optimize user interfaces.

Final Preparations for Launch:

• Conduct thorough testing across all components and user flows.
• Work with the backend team to fix any integration issues.
• Prepare documentation and developer guides to facilitate a smooth transition to the new system.

Maintenance Phase

Post-launch, I will oversee the frontend to ensure its operational efficiency and adaptability to user feedback and evolving requirements:

Ongoing Support and Iteration:

• Provide immediate support for any issues encountered post-launch.
• Implement incremental improvements based on user feedback and analytics.

Community Engagement and Documentation:

• Update documentation regularly to reflect any changes or enhancements.
• Engage with the developer community to encourage contributions and facilitate the onboarding of new developers.

Future-proofing and Scalability:

• Monitor performance metrics and optimize the application to handle increased traffic and data.
• Plan and implement scalability features in collaboration with the backend team.

Checklist

Remaining Tasks:

• [x] Integrate new API endpoints
• [x] Develop and test frontend actions
• [ ] Expand testing framework with Cypress
• [ ] Increase unit test coverage with Vitest
• [x] Ensure WCAG 2.2 Level AA conformance
• [ ] Conduct thorough testing and final adjustments
• [ ] Prepare documentation and developer guides

Cost & Maintenance

Development Budget: Given the scope of remaining tasks and the necessity for high-quality integration, I propose a budget of $3,000 for the completion of the frontend for the V1 launch.

Maintenance Budget: A monthly maintenance fee of $650 to ensure ongoing optimization, support, and updates.

Timeline

Completion of Development: All major development tasks are targeted to be completed by the first week of June 2024. This includes final integrations and functionality enhancements.

Testing and Final Adjustments: June 2024 will be dedicated to extensive testing and final adjustments. This phase is critical to ensuring that all components work harmoniously and that any potential issues are addressed before the public launch.

V1 Launch Target: I aim to have the platform ready for production by the end of June 2024 latest. This allows for a brief period of real-world testing and fine-tuning, ensuring the stability and usability of the application upon launch.

[bbertucc]

Hey @wilsuriel03-

Would you integrate a payment form on the signup? Version 1 will have to generate revenue so we can continue to sustain our work. This could be a basic integration via Stripe.

Also, can you give an example of updates and optimization tasks that would be included in your maintenance, and what wouldn't?

[kevinandrews1]

Looks good @wilsuriel03. My only concern is the use of the word "compliance." I'm not a lawyer, but we should change this to "conformance." While the difference is subtle, it's important to be precise, especially in a publicly available repository. Compliance typically refers to adhering to legal requirements or regulations. Conformance, on the other hand, is about meeting specific standards or guidelines, like those outlined in WCAG. By using "conformance," we are accurately reflecting our adherence to these established standards without implying a legal obligation. Fwiw I've worked with and engaged stakeholders who have been actively sued and sued in the past, so I'm particularly sensitive to this topic.

[wilsuriel03]

Hey @wilsuriel03-

Would you integrate a payment form on the signup? Version 1 will have to generate revenue so we can continue to sustain our work. This could be a basic integration via Stripe.

Also, can you give an example of updates and optimization tasks that would be included in your maintenance, and what wouldn't?

Hey @bbertucc,

I can definitely add a subscription form with Stripe integration to the signup process.

From my understanding, this ticket focuses on the MVP, which was discussed to be used internally while V1 undergoes its redesign. However, if you'd like to change that, I'm open and flexible.

Regarding the maintenance tasks, here's a more detailed breakdown:

Included in Maintenance:

• Regular bug fixes and patches to address any issues that arise.
• Performance optimizations to improve loading times and responsiveness.
• Implementing small feature updates and enhancements based on user feedback.
• Continuous accessibility improvements to maintain conformance with WCAG 2.2 Level AA standards.
• Routine updates to dependencies and libraries to ensure the tech stack remains current.
• Monitoring and resolving any integration issues with the backend APIs.

Not Included in Maintenance:

• Major new features or big redesigns (like a full UI/UX overhaul).
• Large-scale changes to the frontend's structure.

[wilsuriel03]

Looks good @wilsuriel03. My only concern is the use of the word "compliance." I'm not a lawyer, but we should change this to "conformance." While the difference is subtle, it's important to be precise, especially in a publicly available repository. Compliance typically refers to adhering to legal requirements or regulations. Conformance, on the other hand, is about meeting specific standards or guidelines, like those outlined in WCAG. By using "conformance," we are accurately reflecting our adherence to these established standards without implying a legal obligation. Fwiw I've worked with and engaged stakeholders who have been actively sued and sued in the past, so I'm particularly sensitive to this topic.

Hey @kevinandrews1,

Thanks for the feedback and for pointing that out. You're absolutely right about the distinction between "compliance" and "conformance." We'll update the proposal to use "conformance" to accurately reflect our adherence to WCAG standards without implying a legal obligation.

I appreciate your insight and sensitivity to this topic

[bbertucc]

Cool @wilsuriel03 - I pinged you this on Slack, but I think my confusion was the naming of the two versions. I think we should call this "Version 1" and redesign something else, like "Redesign".

One final note: How are you going monitor use of this so you can take what you learn into the Redesign?

[wilsuriel03]

@bbertucc,

I replied to you on Slack to clarify your questions and confusion.

and to monitor the use of Version 1 and gather insights for the Redesign, I will/can use:

User Analytics: Integrate tools like Google Analytics to track user behavior. Heatmaps and Session Recordings: Use tools like Hotjar to see user interaction patterns. User Testing: Conduct periodic user testing sessions with customers and testers like Kevin for direct feedback. Error Tracking: Implement error tracking with tools like Sentry.

with these strategies it will help gather valuable data and feedback for the Redesign.

[bbertucc]

Great. This is approved. I will send you a 50% deposit for your initial buildout work then we can start the maintenance billing after that initial buildout. We can try 3 months of maintenance. I'll set the agenda for our September 15 meeting to review maintenance budgets.