Quality

operable

  • Migrations correctly migrate from previous version to the current one, without losing data etc. (only within the dev branch migrations can be modified or squashed).
  • Frontend+backend are (re)-deployed together, so there cannot be version mismatches.
  • Only a minimal set of configuration options and everything is configurable only via .env.
  • Everything builds and runs on Linux and the CI.

usability

  • Compliance with UI style-guide.
  • Design and implement components responsively as described by general-responsiveness-guide and component-responsiveness-guide
  • Design and implement features to be easily accessible.
    • Alternative ways to access a feature may be provided wherever possible and helpful.
  • Easily understandable acceptance test cases.
  • Usability tests with own case studies and gardeners.
  • (Future) Usable despite color blindness.
  • (Future) Usable with tablet gloves.

Usability Scenarios

  • New users are introduced to all features (guided tour, documentation, tutorials, ...) or can intuitively understand them.
  • Existing users are introduced to new features (guided tour, documentation, tutorials, ...) or can intuitively understand them.
  • After opening a page, scrolling is only possible vertically or hoizontally.
  • After opening a page, all information is visible or becomes visible when using the scrollbar.
  • After opening a page, all interactions are possible or become possible when using the scrollbar.
  • After opening a page, all interactions have a clearly understandable effect, are intentional and consistent.
    • After opening a page, a user interaction does not lead to an unexpected result.
    • After opening a page, a user does not interact with a feature unintentionally.
    • After opening a page, a user does not fail to interact with a feature unintentionally.
    • After opening a page, a user does not interact with an unintended feature.
    • After opening a page, a user interacts with a feature multiple times with the same result each time.
  • After opening a page, at least 75% of it displays the main content.
    • After opening a page, a user interaction does not unexpectedly reduce the display size of the main content.
    • After opening a page, a user interaction does not unexpectedly overlay the main content.
  • When working with a mobile device, accessing a feature requires at most an additional click compared to working on a personal computer.

efficient

  • At least 3000 users should be able to use the backend simultaneously.
  • Application should stay usable with 10.000 elements.
  • Startup time of backend should be less than one second.
  • Near instant search results.
  • Good carbon emission efficiency.

secure

  • Avoid common vulnerabilities
  • Use reliable software for security concerns
  • Everything encrypted (https)
  • Only encrypted or local storage
  • Only authenticated users can access non-public data

flexible

One of our least important goals. Users or programmers do not need simple ways to extend PermaplanT or to change features. The only quality requirement we have are:

  • All features should be available regardless of input device and screen size.
  • Features limited to a specific input device like keybindings may be unavailable otherwise.
  • localized to German and English

Backend Tests

Tests are split into unit and integration tests (see here for reference).

Integration tests can be found here.
Unit tests can be found in the modules they are supposed to test.

Code documentation

The code documentation of the backend can be built using cargo doc --open.

You can find a more detailed explanation of which modules do what there.

API documentation

The API documentation can be viewed by running the backend with cargo run and then navigating to http://localhost:8080/doc/api/swagger/ui/.
It is automatically built using utoipa.

Frontend Code Documentation

The code in the frontend is documented by two different mechanisms. On the one hand components are documented via storybook, on the other hand the public API of a feature, shared hook or utility, etc. should be documented by doc comments. We use TypeDoc to extract the documentation from code comments. More details about supported tags and syntax can be found in the TypeDoc documentation.

The code documentation of the frontend can be generated via the command npm run doc. Under the hood, this command executes TypeDoc that generates .mdx files to be viewed in storybook.

Afterwards it can be opened in storybook via the command npm run storybook.

More details about documentation can be found in the contribution docs