STEP 1: PRODUCT GOAL

Define a complete goal for the Spotterz app. Include the purpose, appeal, problem, and solution the app provides. See the Product Goal for the Spotterz App as an Example below.

 

 

STEP 2: SKETCH PRODUCT

Sketch what the UI might look like. Nothing comprehensive like a wireframe or storyboard yet, just a drawing of the different views using basic shapes to get the idea out there.

The sketches button depicts what the Spotterz app might look like on a mobile platform (phone and tablet/horizontal views). Try to be as detailed as possible for these drawings to see what each view could look like. They should be a good reference point for a more comprehensive storyboard and wireframe which you can refine as you see go. We used Visio.

 

 

STEP 3: SOFTWARE REQUIREMENTS SPECIFICATIONS

Developing the SRS is next. Doing so will help us weigh alternatives to things like APIs, servers, and data diagrams in the future as well as to better understand the user, as this could also affect the user flow. It will also serve as a more complete definition for the app's design, at which point a user flow/wireframe can be developed, then the UI and back-end can be worked on.

 

This information should help with the development of the SDD and a more formal storyboard/wireframe. It's important to catch these things early on in the design phase so time and effort is not wasted in the future implementing functionality that is unnecessary, unwanted, or poorly planned. 

 

STEP 4: SOFTWARE DESIGN DESCRIPTION

Complete an initial version of the app's SDD and a basic Requirements Matrix

 

STEP 5: UI

The next step is to jump in and start developing the UI. First you need to ascertain that you have a functional understanding of the framework so you can more effectively develop the UI.

You can fork the Forkaia repo on GitHub and push commits to your fork so the workflow will be something like this:

  1. Create local experimental branches for adding new screens/features/functions/assets

  2. Merge local experimental branch to local master branch when things are working normally

  3. Commit and push changes to my remote forked repo

  4. Make pull requests so Forkaia can decide if my code should be merged into the origin master branch or not

After the frontend is complete and more work begins on the backend, there will certainly need to be API functionality for the app's main features. This means that we will need API keys.

Please exclude a file containing the required API keys from Git commits so that they are not part of any remote repo (thus invisible to others). Then once the app is ready for deployment, it would be necessary to obtain standard, deployable keys for distribution of the app.


Basically, each developer of the project can have their own "development" API keys that they obtain themselves. Then for deployment there are standard API keys that get compiled with the app for distribution.