Fleet UI breakpoints: Drafting and implementing (#27733)
- Update story template as a reminder for Product Designers to consider Fleet's breakpoints: 480, 768, 1024, 1280, and 1440px - Only need wireframes when there are substantial changes (ex. dropping columns or wrapping elements) - Update Product Groups handbook to clarify that Engineers are responsible for filling in gaps for smaller changes. Engineers bring proposed changes to their product group's design review meeting.
This commit is contained in:
@@ -39,7 +39,7 @@ What else should contributors [keep in mind](https://fleetdm.com/handbook/compan
|
||||
## Changes
|
||||
|
||||
### Product
|
||||
- [ ] UI changes: TODO <!-- Insert the link to the relevant Figma cover page. Make sure wireframes show the UI down to 768px (min screen width). Put "No changes" if there are no changes to the user interface. -->
|
||||
- [ ] UI changes: TODO <!-- Insert the link to the relevant Figma cover page. If there are substantial UI changes at one of Fleet's breakpoints (480, 768, 1024, 1280, and 1440px), make sure wireframes show the UI at the relevant breakpoint(s). Put "No changes" if there are no changes to the user interface. -->
|
||||
- [ ] CLI (fleetctl) usage changes: TODO <!-- Insert the link to the relevant Figma cover page. Put "No changes" if there are no changes to the CLI. -->
|
||||
- [ ] YAML changes: TODO <!-- Specify changes in the YAML files doc page as a PR to the reference docs release branch following the guidelines in the handbook here: https://fleetdm.com/handbook/product-design#drafting Put "No changes" if there are no changes necessary. -->
|
||||
- [ ] REST API changes: TODO <!-- Specify changes in the the REST API doc page as a PR to reference docs release branch following the guidelines in the handbook here: https://fleetdm.com/handbook/product-design#drafting Put "No changes" if there are no changes necessary. Move this item to the engineering list below if engineering will design the API changes. -->
|
||||
|
||||
@@ -252,6 +252,8 @@ Anyone in the product group can initiate an air guitar session.
|
||||
|
||||
Please read carefully and [pay special attention](https://fleetdm.com/handbook/company/why-this-way#why-do-we-use-a-wireframe-first-approach) to UI wireframes.
|
||||
|
||||
While Product Designers are responsible for wireframing significant UI changes at Fleet's breakpoints (see breakpoints in the user story template [here](https://github.com/fleetdm/fleet/blob/main/.github/ISSUE_TEMPLATE/story.md)), Fleet relies on Engineers to fill in the gaps and fluidly include all screen widths. If you discovered a gap, please bring the proposed changes as a live prototype to your product group's next design review.
|
||||
|
||||
Designs have usually gone through multiple rounds of revisions, but they could easily still be overlooking complexities or edge cases! When you think you've discovered a blocker, here's how to proceed:
|
||||
|
||||
**For implementation concerns...**
|
||||
|
||||
Reference in New Issue
Block a user