Work together on this Spec on: https://pad.riseup.net/p/emnTrqLdXzqy When finished change content here:
for “powerplant”/ pp_ / … Document Version <0.14>
powerplant is an opensource webapp that allows anyone planning a garden to utilize companion planting and other permaculture practices. It provides intelligent suggestions to help the gardener by advising the best planting schedules and combinations of crops to maximize the garden's yield.
More detail below.
The goal of powerplant is to help users effectively plan their garden by providing planning and maintenance suggestions which utilize permaculture principles with a focus on companion planting.
Powerplant …
powerplant is open-source and uses and creates data with open copyright.
<pre>
+-----------------------+
| OpenFarm.cc API |
+-----------+-----------+
^
|
|
|
v
+-------------+ +----+-----------------+ +----------------+
| Front End +<------------------>+ Back End +<----------->+ powerplant DB |
+-------------+ +----+-----------------+ +----------------+
^
|
|
|
|
v
+--------------+--------+
| FarmOS API |
+-----------------------+
</pre>
Our vision is that people are able to plan their own gardens using companion planting and other permacultures practices using our app as a central resource for information. The resources we can provide to the user will grow as the app is used more.
The information that we provide is all out there, we want to provide a central source for all of it. Aid those gardening without experience and help make quick and precise descision for the more experienced gardener.
Permaculture guidelines, gardening best practices.
The permaculture ideals are:
Open Source/ Open Data.
A year of use of this software will result in:
>TODO: Add major functions that the product must perform or must let the user perform.
TODO: Figure out where these attributes belong: Soil conditions, grow time, climate, sun direction relative to each bed, labor required for each plant, sun+water required, best season/time to plant, care frequency, nitrogen/ consumption
User should choose between different guides (from openfarm.cc) for a crop that fits their needs
NEARLY the same UX (user experience) both offline and online! This is really important because people will need to use on mobile in their garden
Notify users of tasks that should be done for each garden/bed/crop on a given day
Find optimal planting schedule for a target bed (with at least one user picked crop)
Information accessible on timeline of different stages and locations of growth (i.e. when to grow in greenhouse and transplant them outside)
Users can contribute in the form of editing existing cropinformation, croprelationship, and guides.
Creating Guides should link into OpenFarm directly - Create Guide.
Editing Guides should be put into powerplant “centralized improved guide” (except it is your own guide?). This avoids parallel versions of the same guide edited by different users, and instead puts all the edits in one place. Editing Cropinformation should be edited in OpenFarm directly. Croprelation should be changed in the app and put into OpenFarm.
TODO Create Seperate page to link to
Location: Group of gardens whose permaculture zones are defined relative to a common zone 0
Garden: combination of beds in the same vicinity and permaculture zone
Bed: Section in a garden (can be a greenhouse, a pot or a patch of soil)
Crop: Specific instance of a crop that will be planted in a bed
Transplant: action of moving a crop from a pot (non-bed) to a bed
Zone/Permaculture Zone: Ordered area from 0 to 5 by frequency of visits/maintance requirement (/often also related to proximity)
Data flow diagram for cropinformation/croprelationship data (from openfarm)
<pre>
``````````` `...`
`. .` `.` `.`
`` `` ``` `.`
. . ```-Openfarm-..`
-````. User Interface .``````Send.```>`./.` registered?- `.```````no`````````````-
. . . `....-........` .
. .` . `.` `.` .
. +.` ``` `.` `.` .
. ^ ``/|\`` `-` .
. . : . .
. . . . .
. . . . .
. . . . .
Request . . . .
. . . yes .
. . . . `````````+.`````````
. . .```````````````````````````````` .`` .```````````````````.
. .`` Response to request . `. . .
. `Response . `. . no action allowed .
. .to Request . `. . `` ````` ``````` .
. .-`------ . `. . -
. ^ . `. `````````````````````
. . . `.
. . . `.
. . - \/
. . `````````.-
. -````````` ``` `-:
. .. `. .` .
. .``Openfarm` . `. Power plant .
.>/- `Database` .:<`````Send ```````- Backend ` .
.` ---:::--` . `. .------: .
.` `. .` .
````````` `.` .`
``````````
</pre>
* Hobbyist - small home garden. 20 m2 * Countryside garden - 250 - 1000 m2 * Organic farmer - 1000 m2 + * Consultant - all of the above * Anyone who wants to plan a garden by using companion planting. * People who want to use open source/ open data software.
* All users: consistent harvest throughout the year * Hobbyist - Not too much labor is better; organic/natural garden * Countryside garden - Same as Hobbyist, also wants to be self-sufficient * Organic farmer - Same as Hobbyist, also prioritizing lower labor. Intermixed plants means more labor. Technologically literate, want to use software to improve their yields * Consultant - Provide advice to other hobbyists/gardeners/farmers
Describe the environment in which the software will operate, including the hardware platform, operating system and versions, and any other software components or applications with which it must peacefully coexist. In this part, make sure to include a simple diagram that shows the major components of the overall system, subsystem interconnections, and external interface
* Lower range laptop * Windows 10, Chrome, use in office or garden * Android x.x.x, Chrome, use in office or garden, but mainly garden * With temporary internet connection
Describe any items or issues that will limit the options available to the developers. These might include:
* hardware limitations (timing requirements, memory requirements)
* interfaces to other applications
* specific technologies
* tools
* databases to be used
* language requirements
* User Documentation
* React for front end with JSX to generate HTML * SASS for css * Need to eventually be compatible with FarmOS. * Need to eventually be compatible with Openfarm.cc. * Want to be similar to Openfarm crop database structure. * Want tasks to be similar to FarmOS Log data structure * Text + photo editors. * NodeJS as backend engine running ES6 MongoDB for database with Mongoose as ODM Express for route handling Passport for user authentication Mocha + Chai + supertest for unit testing and integration testing * Mobile-first, offline-first design (ok, maybe mobile-first, offline-second. they can't both be first)
TO DO: Describe what kind of manuals and what kind of help is needed for the software you will be developing.
List the user documentation components (such as user manuals, on-line help, and tutorials) that will be delivered along with the software.
Need to have user documentation. Usability will be severely limited without. Need to have in depth descriptions of how to input data, what screens should look like, how to interpret output. Need to document things before creating them.
TO DO: Describe user interfaces, different screen images, any GUI standards, standard buttons and functions (e.g., Cancel) that will be available to the user. Define error message display standards.
https://material.io/guidelines/ https://medium.com/@marcintreder/the-minimum-viable-design-system-75ca1806848a
“View the prototype! (INCOMPLETE)”:https://marvelapp.com/94c4bh4 If you want to improve it contact franz@ecohackerfarm.org to get an invite.
TODO: add many many more more more more views
Describe the logical and physical characteristics of each interface between the software product and the hardware components of the system. This may include, the supported device types, the nature of the data and control interactions between the software and the hardware.
TO DO: Describe: the connections between the product and other specific software components (name and version), databases, operating systems (Windows? Linux? Etc…), tools, libraries and integrated commercial components.
TO DO: Identify data items or messages coming into the system and going out and describe the purpose of each.
TO DO: Describe the services needed.
TO DO: Identify data that will be shared across software components.
TO DO:
REST
“Auto-generated API specs”:https://github.com/Ecohackerfarm/powerplant/blob/master/docs/spec.md
API error messages have the following format:
<pre>
{
status: Number,
message: (optional) String,
errors: (optional) {
fieldName1: String,
...
}
}
</pre>
@status@: HTTP status code @errors@: Object containing error messages pertinent to specific UI elements, e.g. a login request with an incorrect password would result in @{password: “Incorrect password”}@ @message@: A general description of the error, which can be displayed to the user
TO DO: Provide a use case diagram which will encapsulate the entire system and all possible actors.
TODO: Add more use cases
TODO: Create use case diagrams involving each of the possible types of users
TODO: Convince openfarm to enhance companionship model or find a suitable ruby on rails developer
