Vizzuality playbook in progress
This project is maintained by Vizzuality
As part of our objectives around improving performance and client value in the next three months we will create user stories and acceptance tests associated with tasks and functionalities. There’s a separate guide outlining our approach to that here.
There’s a concern around the need to be comprehensive in such stories and tests, and about how to go about populating them (what things should be taken for granted unless stated otherwise, even if they are not specified in the user story/acceptance test)
The following list is not comprehensive and is subject to growth as we progress. The items are in no particular order:
Design, frontend, backend
Whenever it is required for users to be able to log into a site they should also have the means to logout, cancel their registration and change their password.
If the user email is used for log in there should always be a confirmation sent to the user to verify they own the email and that it’s correct.
Design, frontend, backend Whenever an unauthenticated user clicks to enter a page that requires authentication, the application should redirect to a login page (not overlay) and redirect back to the previous page after login.
Design, frontend, backend Whenever there’s a need to store user emails there should be a confirmation sent to the email. User’s should also have the means to change the email (in case they misspell it) and re-send the confirmation email. No other emails (subscriptions, newsletters, communications) should be sent to the user until they have confirmed their address
Design, frontend By default, and unless stated otherwise, all our projects should support the two latest versions of major desktop browsers (Chrome, Firefox, Safari, Explorer/edge) and iOS/Android in mobile
Design, frontend By default, and unless stated otherwise, all projects should be browsable in desktops, tablets and mobile phones. Specific functionalities may vary across them. Please ask if in doubt
Design, frontend, backend All server error pages (404, 500, 502, etc) should be styled according to the site’s visual guidelines, and provide understandable information, plus a link to the site’s home and the previous page.
Frontend Whenever there’s a runtime error in the application there should be a visual cue that tells the user that something went wrong. Visual elements such as spinners, loaders or page overlays should stop to allow the user to navigate out of the page or retry.
Frontend All images should be optimized for internet usage in size
Frontend All staging and unpublished sites should have a valid robots.txt to avoid crawlers indexing them until publication
Frontend, backend All public sections of sites should contain the minimum set of SEO friendly tags [TBD]