Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision | ||
companion_planting:development_log [2017/06/11 23:33] – refactor dokuwiki markup kimparker | companion_planting:development_log [2017/11/13 22:23] – ecohack | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== | + | ====== |
- | ===== Research ===== | + | |
- | [[https:// | + | |
- | [[https:// | + | The ticket #959 is the information base for the specification. Its written in a markup language not compatible with this wiki. Redmine is used to track the tasks around the development so it makes more sense to make this location the primary datasource. To make your contributions usable, write in the ticket or use redmine markup in the CODE text. Copy it over from the redmine everytime its updated there: |
- | [[http:// | + | < |
- | [[http://organic.kysu.edu/BiointensiveMixtures.pdf|Paper by M.K. Bomford]] Further development on the KYSU research above. Has a few key conclusions, | + | Work together on this Spec on: https://pad.riseup.net/p/ |
- | * Results suggest that mixed planting can increase land-use efficiency of BIA systems under resource-limiting conditions. | + | When finished change Ticket: https:// |
- | * Cool-season crops should not be mixed with warm-season crops for synchronous growth in mixed plantings. | + | |
- | [[https:// | + | [[wiki|Back To Overview]] |
- | [[https:// | + | {{>toc}} |
- | [[https:// | + | h1. Software Requirement Specification |
- | The ticket #959 is the information base for the specification. Its written in a markup language not compatible with this wiki. Redmine is used to track the tasks around the development so it makes more sense to make this location the primary datasource. To make your contributions usable, write in the ticket or use redmine markup in the CODE text. Copy it over from the redmine everytime its updated there: | + | for " |
+ | Version <0.13> | ||
- | < | + | h1. Introduction |
- | Software Requirement Specification | + | powerplant is a software 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' |
- | for Companion Planner | + | |
- | Version <0.2> | + | |
- | Introduction | + | h1. Users |
- | TO DO: Identify the product whose software requirements are specified, including the revision or release number. Describe the scope of the product. | + | |
- | Users | + | * Gardeners, including anyone who wants to plan a garden and is happy to use open source software. |
- | Gardeners | + | ** Hobbyist - small home garden. 20 m2 |
- | Goal | + | ** Countryside |
- | Help with garden | + | ** Organic farmer - 1000 m2 + |
+ | ** Consultant - all of the above | ||
+ | ** Anyone who wants to plan a garden by using companion | ||
+ | ** People who want to use open source/ open data software. | ||
- | Taking into account: | + | More detail below. |
- | Soil type | + | h1. Goal |
- | Climate | + | |
- | Growth time | + | |
- | Sun and water requirements | + | |
- | Improve harvest and diversity by adding valuable information during the planning stage. | + | |
- | Product Scope | + | |
- | TO DO: Provide a short description of the software being specified and its purpose, including relevant benefits, objectives, and goals. | + | |
- | Software description | + | 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. |
- | Convert data on crops into something usable by anyone interested in gardening. | + | |
- | Open-source | + | h2. Product Scope |
- | Objectives | + | |
- | Improve planning process for anyone who wants to use permaculture principles in their gardening. | + | > Provide a short description of the software being specified and its purpose, including relevant benefits, objectives and goals. |
- | Save time during planning process who wants to use permaculture principles in their gardening. | + | |
- | Education of users | + | h3. Software description |
- | Improve and collect data | + | |
- | Increase harvest yield | + | * Offer fast and easy solution for knowing which crops (bene)fit together |
- | Overall Description | + | * Provide an easy to follow schedule for planting, transplanting, |
- | Product Perspective | + | * Provide information about the crops themselves |
- | Users | + | * Push and pull crop information to/from several open data platforms |
+ | * User can submit changes to improve data | ||
+ | * Open-source/open-data | ||
+ | |||
+ | > TODO: write more and better text | ||
+ | |||
+ | h3. Objectives | ||
+ | |||
+ | * Improve planning process for anyone who wants to use permaculture principles in their gardening. | ||
+ | * Save time during | ||
+ | * Education of users | ||
+ | * Improve and collect data in open databases | ||
+ | * Increase harvest yield | ||
+ | * Connect with other open source projects for mutual benefit | ||
+ | |||
+ | h1. Overall Description | ||
+ | |||
+ | < | ||
+ | +-----------------------+ | ||
+ | | OpenFarm.cc API | | ||
+ | +-----------+-----------+ | ||
+ | ^ | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | v | ||
+ | +-------------+ | ||
+ | | Front End | ||
+ | +-------------+ | ||
+ | ^ | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | v | ||
+ | +--------------+--------+ | ||
+ | | FarmOS API | | ||
+ | +-----------------------+ | ||
+ | </ | ||
+ | |||
+ | |||
+ | h2. Product Perspective | ||
+ | |||
+ | 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. | ||
+ | |||
+ | h2. Context | ||
+ | |||
+ | 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. | ||
+ | |||
+ | h2. Origin | ||
+ | |||
+ | Permaculture guidelines, gardening best practices. | ||
+ | |||
+ | The permaculture ideals are: | ||
+ | |||
+ | * Care for the earth | ||
+ | * Care for the people | ||
+ | * Fair share | ||
+ | |||
+ | Open Source/ Open Data. | ||
+ | |||
+ | h3. Outcome | ||
- | Anyone who wants to plan a garden. | ||
- | People who want to use open source software. | ||
- | Outcome | ||
A year of use of this software will result in: | A year of use of this software will result in: | ||
- | Users adding to data from all over the world (different climates, soil types) | ||
- | TO DO: more added here | ||
- | Context | ||
- | The information that we provide is all out there, we want to provide a central source for all of it. Gardening without experience and make quick and precise descision more experienced. | ||
- | Origin | + | * Users adding to data from all over the world (different climates, soil types) |
- | Permaculture guidelines, gardening | + | * Maybe make some money for affiliate links (seeds, supplies) or donations |
+ | * Users plan garden and fields with our software | ||
+ | * Users are better educated about gardening | ||
+ | * Enhance other open source projects with valuable information | ||
+ | * More development on powerplant resulting in better software | ||
+ | ** especially including more OS/OD enthusiasts | ||
+ | ** building up networks with different OS/OD projects | ||
+ | |||
+ | h2. Product Functionality | ||
- | Permaculture ideals | + | > 1 TODO: Add major functions that the product must perform or must let the user perform. |
- | Care for the earth | + | h3. Must Have |
- | Care for the people | + | |
- | Fair share | + | |
- | TO DO: Describe the context and origin of the product being specified. Include a simple diagram that shows the major components of the overall system, subsystem interconnections, | + | |
- | Product Functionality | + | * Select different guides |
- | 1 TO DO: Summarize the major functions that the product must perform or must let the user perform. | + | * Offline and online |
+ | * Suggestions for existing beds | ||
+ | * Mark a bed as full or not | ||
+ | * Notifications from schedule | ||
+ | * Tasks and actions | ||
+ | * Schedule | ||
- | Must Have | + | * user can signup/ login or decide |
- | Need a list of available plants | + | * user can create an account |
- | Need to be able to see compatible/incompatible plants | + | * user can create beds |
- | Need to be able to filter by multiple plants | + | * user can create gardens |
- | Find optimal planting schedule for a set of plants | + | |
- | Information accessible on timeline of different stages and locations of growth (i.e. greenhouse or outside) | + | |
- | Read more information on the plant we display | + | |
- | ?? Add information on plants | + | |
- | ?? Print Shopping List | + | |
- | ?? Print what we get List | + | |
- | ?? Print Requirements for selected plants. | + | |
- | ?? List Plants that are only available in a certain timespan | + | |
- | List Plants that are only available in filter | + | |
- | List following plants for harvested beds | + | |
- | List compatible plants for selected beds | + | |
- | List compatible plants for harvested beds | + | |
- | List of plants i like (with autocomplete) | + | |
- | add from all plants | + | |
- | remove | + | |
- | add constraints | + | |
- | compatibility chart | + | |
- | warnings on too many combinations (reason: size of beds, efficient seed usage) | + | |
- | best 5 group combination, | + | |
- | select favourite group | + | |
- | compatibility suggestions, | + | |
- | list plants compatible to this group | + | |
- | schedule (status of garden) | + | |
- | list plant grow/ | + | |
- | list plant fill bed times | + | |
- | define livecycle for plant (percent) | + | |
- | display suggestions for empty times (herbs when only short terms) | + | |
- | define time the schedule displays (min: week, max: month) | + | |
- | create | + | |
- | reports weekly what needs to be done with each plant | + | |
- | filter when nothing has to be done | + | |
- | store the schedule for one ' | + | |
- | load bed from url and display schedule for current date | + | |
- | display plant information dialog | + | |
- | profile to store multiple | + | |
- | Should Have | + | |
- | Find optimal planting combinations for any number of plants per bed | + | |
- | Based on distance between plants | + | |
- | Cool to Have: | + | |
- | Include types of beds required for a crop | + | |
- | Get revenue from links for more information. | + | |
- | ? technical detail? | + | |
- | Have some visualization | + | * Need a list of available |
- | Draw in current crops | + | * Need to be able to see compatible/incompatible plants (internal) |
- | Fill in blank spaces in beds | + | * Need to be able to filter by compatibility with multiple plants |
- | Filter crops added by algorithm based on preference | + | * Find optimal planting schedule |
- | Add/remove crops for any reason | + | |
- | Deny/change crops selected by algorithm for any reason | + | |
- | Save user profiles with all information | + | |
- | Save past combinations | + | |
- | Keep track of nitrogen fixers/ | + | |
- | Take user feedback | + | |
- | Sharing/ | + | |
- | TODO: Still to decide in which section the attributes fit | + | |
- | Need to filter by attribute(s): | + | |
- | TODO | + | |
- | 2. Organize the functions to make them understandable to any reader. | + | |
- | Aimee says: Urgent: Good combinations | + | |
- | Less Urgent: Planting location | + | |
- | Not urgent: Visualizing beds | + | |
- | 3. Provide | + | |
- | will create later | + | |
- | TO DO | + | |
- | Users and Characteristics | ||
- | Identify the various users that you anticipate will use this product. | ||
- | Hobbyist - small home garden. 20 m2 | ||
- | Countryside garden - 250 - 1000 m2 | ||
- | Organic farmer - 1000 m2 + | ||
- | Describe the pertinent characteristics of each user. | ||
- | Hobbyist - Not too much labor is better, | ||
- | Countryside garden - Wants to be self-sufficient. | ||
- | Organic farmer - Prioritizing lower labor. Intermixed plants means more labor. Technologically literate, want to use software to improve their yields | ||
- | Operating Environment | ||
- | 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, | ||
- | Lower range laptop | + | h3. Should Have |
- | Windows 10, Chrome, use in office or garden | + | |
- | Android x.x.x, Chrome, use in office or garden, but mainly garden | + | |
- | Design and Implementation Constraints | + | |
- | Describe any items or issues that will limit the options available to the developers. These might include: | + | |
- | hardware limitations (timing requirements, | + | * When offline: |
- | interfaces to other applications | + | ** Get suggestions for where to plant crops |
- | specific technologies | + | *** TODO: Figure out if this is possible offline. |
- | tools | + | *** Only for plants currently in local memory |
- | databases to be used | + | * If we get the data, notify the user of maintenance tasks include watering, weeding, pruning, etc. |
- | language requirements | + | * Suggest plants based on distance between plants |
- | User Documentation | + | * List suggestions for following plants for harvested beds |
- | Need to have user documentation. Usability will be severly limited without. Need to have in depth descriptions | + | * Sharing/ |
- | screen should look like, how to interpret output. Need to document things before creating them. | + | * Add a crop entry |
- | Need to use vanilla Javascript for front end. | + | ** fill out form |
- | Plain HTML, LESS for css | + | ** should |
- | Need eventually be compatible with FarmOS. | + | * validation |
- | Have to use FarmOS database. | + | ** flag trolls/... |
- | Text + photo editors. | + | * Keep track of nitrogen fixers/ |
- | Back end: PHP to deal with database, Javascript | + | * Save edit history |
- | TO DO: Describe what kind of manuals and what kind of help is needed for the software you will be developing. | + | * permaculture zones: |
+ | ** a garden can have zones | ||
+ | ** suggestions based on zones | ||
+ | *** plant zone is dependent on how much attention they need/how often you harvest | ||
+ | **** TODO: think about this, how to figure that out | ||
- | List the user documentation components | + | h3. Cool to Have |
+ | |||
+ | * Include types of beds required for a crop | ||
+ | * Get revenue from links for more information. | ||
+ | * Plant pictures | ||
+ | * Print Shopping | ||
+ | * modify | ||
+ | * Have some visualization of garden beds with plants | ||
+ | * Draw in current crops | ||
+ | * Gamification | ||
+ | ** Levels/ | ||
+ | *** Contributor | ||
+ | *** Expert farmer | ||
+ | *** etc. | ||
+ | |||
+ | > 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 | ||
+ | |||
+ | h3. Minimal Viable Project | ||
+ | |||
+ | * The User should be able to select a minimum of two plants and the app will produce a result to list of plants in groups that are compatible with each other. | ||
+ | * It should only list small groups that are not contained in a bigger group | ||
+ | ** Example: {Nasturium, Potato, Onion} = {Nasturium, Potato}, {Onion} != {Nasturium, Potato}, {Onion}, {Potato}, {Nasturium} | ||
+ | * Search by Common english name or binoial name in the same field | ||
+ | ** If crop not found it should tell: "Plant not yet in the database or you wrote the name wrong :) - or you can try again using the binomial name" | ||
+ | * This should represent the function of creating multiple beds from a list of seeds/ | ||
+ | * TODO | ||
+ | ** Backend: Import plant data from PFAF database, import basic plant relationship data (firebase), create HTTP API call to get compatible groups from a big group of plants. | ||
+ | |||
+ | h3. Detailed function description. | ||
+ | |||
+ | h4. Select different Guides | ||
+ | |||
+ | User should choose between different guides (from openfarm.cc) for a crop that fits their needs | ||
+ | * When adding a crop to a bed, users have the option of selecting a guide available from openfarm | ||
+ | * Users can view the guide for a crop at any time from the crop details page | ||
+ | * Guides can be removed, added or changed to a crop in crop view (only one guide per crop) | ||
+ | |||
+ | h4. Offline and Online | ||
+ | |||
+ | 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 | ||
+ | * Things a user will most likely want to do while offline. Use command pattern for the actions and queue them up. They sync when the phone/ | ||
+ | ** Add a new bed | ||
+ | ** Add existing crops to that bed | ||
+ | ** Change the status of a crop | ||
+ | ** Change status of a task | ||
+ | ** Switch to any other bed in their garden | ||
+ | ** View a guide/ | ||
+ | |||
+ | h4. Suggestions | ||
+ | |||
+ | * Provide suggestions for adding specific crops to existing beds | ||
+ | ** User can ask for crop suggestions when adding crops to a garden or bed | ||
+ | * Provide suggestions for adding specific crops to a specific bed | ||
+ | ** User can also ask for suggestions for crops to add to a specific bed | ||
+ | * Must have at least one user-selected crop to provide suggestions | ||
+ | |||
+ | |||
+ | h4. Notifications | ||
+ | |||
+ | Notify users of tasks that should be done for each garden/ | ||
+ | * Email notifications | ||
+ | ** should be opt out by default | ||
+ | ** include weekly summary of upcoming tasks | ||
+ | |||
+ | * Push notifications | ||
+ | ** Need to be enabled in browser (would only work on desktop) | ||
+ | ** include events happening on the current day | ||
+ | |||
+ | h4. Tasks and Actions | ||
+ | |||
+ | * Right now, this would include planting, transplanting, | ||
+ | * Users can add custom tasks from a predefined set of actions (or " | ||
+ | ** Tasks are associated with a location, bed, or crop | ||
+ | ** Repeatable tasks | ||
+ | * Mark tasks as complete, or postpone or ignore them | ||
+ | |||
+ | h4. Schedule | ||
+ | |||
+ | Find optimal planting schedule for a target bed (with at least one user picked crop) | ||
+ | * When adding a crop, users can get suggestions for when to plant it based on the duration of growth | ||
+ | * Goal is to maximize the overall yield and allow for consistent harvest throughout the year | ||
+ | |||
+ | Information accessible on timeline of different stages and locations of growth (i.e. when to grow in greenhouse and transplant them outside) | ||
+ | |||
+ | * Users can view the schedule for a location or bed as a chart | ||
+ | * Growth periods are shaded in bars, single events are represented as lines | ||
+ | * Should allow the user to see, at a quick glance, what is growing and when things can be harvested | ||
+ | ** Also be able to identify gaps in the schedule which could be filled | ||
+ | * Should also show information about compatibility interactions | ||
+ | ** Needs to be intuitive and simple to understand, obvious from one look at the schedule | ||
+ | |||
+ | h4. User Contributions | ||
+ | |||
+ | Users can contribute in the form of editing existing cropinformation, | ||
+ | |||
+ | Creating Guides should link into OpenFarm directly | ||
+ | * pro: less work for developer | ||
+ | * contra: might be confusing for the user | ||
+ | Editing Guides should be put into powerplant " | ||
+ | Editing Cropinformation should be edited in OpenFarm directly. | ||
+ | Croprelation should be changed in the app and put into OpenFarm. | ||
+ | |||
+ | h3. Terminology | ||
+ | |||
+ | |||
+ | 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/ | ||
+ | |||
+ | h3. 2. Provide a Data Flow Diagram of the system to show how these functions relate to each other. | ||
+ | |||
+ | Data flow diagram for cropinformation/ | ||
+ | |||
+ | < | ||
+ | |||
+ | ``````````` | ||
+ | `. | ||
+ | | ||
+ | | ||
+ | -````. User Interface .``````Send.```> | ||
+ | . . | ||
+ | . | ||
+ | . +.` | ||
+ | . ^ ``/ | ||
+ | . . : | ||
+ | . . | ||
+ | . . | ||
+ | . . | ||
+ | Request | ||
+ | . . | ||
+ | . . | ||
+ | . . | ||
+ | . .`` Response to request | ||
+ | . `Response | ||
+ | . .to Request | ||
+ | . .-`------ | ||
+ | . ^ | ||
+ | . . | ||
+ | . . | ||
+ | . . | ||
+ | . . | ||
+ | . -````````` | ||
+ | . | ||
+ | . .``Openfarm` . `. Power plant | ||
+ | .>/- `Database` .:< | ||
+ | .` ---:::--` . | ||
+ | .` `. | ||
+ | ````````` | ||
+ | `````````` | ||
+ | |||
+ | |||
+ | </ | ||
+ | |||
+ | h2. Users and Characteristics | ||
+ | |||
+ | h3. Identify the various users that you anticipate will use this product. | ||
+ | |||
+ | * 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. | ||
+ | |||
+ | h3. Describe the relevant and important characteristics of each user. | ||
+ | |||
+ | * 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/ | ||
+ | |||
+ | h2. Operating Environment | ||
+ | |||
+ | > 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, | ||
+ | |||
+ | * 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 | ||
+ | |||
+ | h2. Design and Implementation Constraints | ||
+ | |||
+ | > Describe any items or issues that will limit the options available to the developers. These might include: | ||
+ | > * hardware limitations (timing 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, | ||
- | User manual | + | h2. User Documentation |
- | FAQ | + | |
- | First time user prompts | + | |
- | Community talking points | + | |
- | Chat rooms (FarmOS) | + | |
- | Tutorials for most exemplary tasks | + | |
- | User Documentation | + | |
- | TO DO: Describe what kind of manuals and what kind of help is needed for the software you will be developing. | + | |
+ | > 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.// | List the user documentation components (such as user manuals, on-line help, and tutorials) that will be delivered along with the software.// | ||
- | User manual | + | Need to have user documentation. Usability |
- | FAQ | + | |
- | First time user prompts | + | |
- | Community talking points | + | |
- | Chat rooms (FarmOS) | + | |
- | Tutorials for most exemplary tasks | + | |
- | Specific Requirements | + | |
- | External Interface Requirements | + | |
- | TO DO: Describe | + | |
- | TODO: Warnings / Suggestions all over the place, define toast/ | + | * User manual |
+ | * FAQ | ||
+ | * First time user prompts | ||
+ | * Community talking points | ||
+ | * Chat rooms (like FarmOS) | ||
+ | * Tutorials for most exemplary tasks (Videos, ...) | ||
- | Hardware Interfaces | + | h1. Specific Requirements |
- | 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. | + | |
- | 800x400 display * 100kB/s * 200mb memory on mobile * 512mb memory on non-mobile * 5mb local storage | + | h2. External Interface Requirements |
- | Software Interfaces | + | |
- | 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. | + | |
- | FarmOS | + | > TO DO: Describe user interfaces, different screen images, any GUI standards, standard buttons |
- | TO DO: Identify data items or messages coming into the system and going out and describe | + | |
- | FarmOS specs go here | + | h3. GUI standards |
- | TO DO: Describe the services needed. | + | |
- | TO DO: Identify data that will be shared across software components. | + | https:// |
+ | https:// | ||
+ | |||
+ | * Lots of rounded rectangles to contain components | ||
+ | * Font size standards based on Marvel prototype (maybe change to be based on screen size in the future) | ||
+ | ** Main page title: 26pt | ||
+ | ** Subtitle: 18pt | ||
+ | ** Body text: 14pt | ||
+ | * Sidebar menu accessible from any screen which shows the current location and allows jumping to any screen above it in the hierarchy (All Gardens -> Garden Dashboard -> Bed Dashboard -> Crop) | ||
+ | * Gardens and Beds contain 3 subscreens (fragments? | ||
+ | ** Dashboard, Beds/Crops, Schedule | ||
+ | ** Dashboard shows relevant tasks | ||
+ | ** Beds/Crops shows all Beds/Crops contained within the Garden/ | ||
+ | ** Schedule shows history of all past, present, and future crops for the Garden/ | ||
+ | * Any time there is a title/ | ||
+ | ** Menu items: Edit, delete | ||
+ | ** This is the main mechanism by which user can change settings/ | ||
+ | |||
+ | h3. View Description | ||
+ | |||
+ | "View the prototype! (INCOMPLETE)": | ||
+ | If you want to improve it contact franz@ecohackerfarm.org to get an invite. | ||
+ | |||
+ | > TODO: add many many more more more more views | ||
+ | |||
+ | h3. Hardware Interfaces | ||
+ | |||
+ | > 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. | ||
+ | |||
+ | * 800x400 display | ||
+ | * 100kB/s | ||
+ | * 200mb memory on mobile | ||
+ | * 512mb memory on non-mobile | ||
+ | * 5mb local storage | ||
+ | |||
+ | h3. Software Interfaces | ||
+ | |||
+ | > TO DO: Describe: the connections between the product and other specific software components (name and version), | ||
+ | |||
+ | * FarmOS | ||
+ | ** FarmOS users can provide the url of their server and save/load all of their data BESIDES crop guides and crop information from there | ||
+ | ** There will have to be a moderate amount of translation between powerplant data format and FarmOS data format | ||
+ | ** Rather than building a seperate FarmOS module, we will make our web app compatible with FarmOS | ||
+ | ** A FarmOS module could be possible, but requires much more time and expertise than it is worth at the moment | ||
+ | * Openfarm.cc | ||
+ | ** Openfarm stores CropRelationships, | ||
+ | ** Powerplant users can choose to register their accounts with Openfarm as well | ||
+ | ** Users who do this will be able to save/modify this data | ||
+ | ** All users (registered or not), while load this data from Openfarm | ||
+ | |||
+ | > TO DO: Identify data items or messages coming into the system and going out and describe the purpose of each. | ||
+ | |||
+ | * FarmOS specs go here | ||
+ | * openfarm.cc specs go here | ||
+ | |||
+ | > TO DO: Describe the services needed. | ||
+ | |||
+ | > TO DO: Identify data that will be shared across software components. | ||
+ | |||
+ | * need to look at what FarmOS stores and what we store | ||
+ | | ||
+ | |||
+ | |||
+ | h3. Communications Interfaces | ||
- | need to look at what FarmOS stores and what we store | ||
- | figure out what we can store in FarmOS | ||
- | Communications Interfaces | ||
TO DO: | TO DO: | ||
- | 1. Describethe | + | 1. Describe the requirements associated with any communication |
- | 2. Define any pertinent message formatting. | + | 2. Define any pertinent message formatting. |
+ | |||
+ | h2. communication standards that will be used, such as FTP or HTTP. | ||
- | communication standards that will be used, such as FTP or HTTP. | ||
REST | REST | ||
- | communication security or encryption issues, data transfer rates, and synchronization mechanisms. | + | " |
- | Profile could have sensitive info | + | |
- | Even in case of illegal crops being grown, info cannot be accessible by anyone | + | API error messages have the following format: |
- | Yield is sensitive | + | < |
- | Complete transparency within network of gardeners, zero transparency outside | + | { |
- | low bandwidth because garden usually has bad reception (GPRS traffic) | + | status: Number, |
- | Behavior Requirements | + | message: (optional) String, |
- | Use Case View | + | errors: (optional) { |
- | TO DO: Provide a use case diagram which will encapsulate the entire system and all possible actors. | + | fieldName1: String, |
+ | ... | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | @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: " | ||
+ | @message@: A general description of the error, which can be displayed to the user | ||
+ | |||
+ | h4. communication security or encryption issues, data transfer rates, and synchronization mechanisms. | ||
+ | |||
+ | * Profile could have sensitive info | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | * Sync profile data between local and server | ||
+ | |||
+ | |||
+ | h2. Behavior Requirements | ||
+ | |||
+ | h3. Use Case View | ||
+ | |||
+ | > TO DO: Provide a use case diagram which will encapsulate the entire system and all possible actors. | ||
+ | |||
+ | " | ||
+ | |||
+ | h3. List of Use case | ||
+ | * a user has an empty garden, and they want to know what they should plant | ||
+ | * a user has a non-empty garden, and they want to know what they should add to it | ||
+ | * user wants to track their garden' | ||
+ | * user has some data they want to contribute | ||
+ | * cool to have | ||
+ | ** user wants to manage a garden with multiple people working on it | ||
+ | > TODO: Add more use cases | ||
+ | |||
+ | h3. Diagram | ||
+ | > TODO: Create use case diagrams involving each of the possible types of users | ||
+ | General TODO: | ||
+ | Convince openfarm to enhance companionship model or find a suitable ruby on rails developer | ||
+ | | ||
+ | Diagrams: https:// | ||
</ | </ |