Introduction
- Mikah Pinegar
Here is an overview of materials to help your programmers get on their way.
The first thing your team will want to do is step through both council’s high-fidelity prototypes according to their respective scenarios. The prototypes work best when using the Figma app on a mobile device, but they work just fine in desktop browser too. Starting with these prototypes will allow the developers to understand the flow of the user experience.
MCCC Prototype. MCCC Cog Walkthru Protocol
NECCC Prototype. NECCC Walkthru Protocol
Second, the developers should review the Figma files to see the components and the libraries. I have duplicated the file for your team and removed pages that are deprecated to avoid any confusion. Please note that the MCCC prototype was created first and tested at the PSA meeting. From the feedback we received, we updated the design for the NECCC prototype. We did not re-make the MCCC prototype according to the updated design used for NECCC because SO MUCH TIME. Please note that the design in the NECCC (i.e., the change in the navigation menus and the side bar) should be the design that is implemented, not the one in the MCCC prototype. However, the logical flow of the MCCC prototype is still valid and thus is still a useful resource. In implementing the NECCC prototype, I incorporated components and built out the component library. This was not so much the case for the MCCC prototype, which was initially built out by our design student.
Third, the developers need to visit the repository which is currently hosted by axi lab, but is in the process of being migrated to PSA. I set up milestones for development (which can be modified or abandoned entirely) to more-or-less align with each navigation step in the SRC. I set up issues for the containers, and first two navigation steps: Home and Planting site. All components that are used have both a template and instance issue. For example, there is a generic drop down component template issue. Then there are separate issues for each time a component is actually featured on a page (e.g., a drop down for location selection, and another drop down for soil drainage). The templates are intended to set up the design system, where as the instances are the actual objects on the page. My goal in specifying templates and instances separately is to basically reduce duplication of code. In the past tool implementations, we found that somethings as simple as a button might have show up twice in the design system/CSS with little but unintentional or no variation.
Something else that I did when creating the issues, which is perhaps most important to this development team, was find material component analogs to the things that are in the Figma file. We don’t need things to look exactly as they do in the Figma file, we’d much rather use tried and tested material ui components that approximate the design in the Figma file.
In terms of ensuring that the process logic is correct, please reference the process logic prototypes in Airtable. The prototypes are in each base’s Seeding Rate Calculator table, and links to data in the other tables.
Finally, for a historical reference of how we got to these points, there is the Design Sprint Miro Board. A lot has been revised since the design sprint, and so this should be used only for historical context.
Happy SRC developing :)