Skip to content

Home

Jump to bottom
nallen05 edited this page May 6, 2016 · 6 revisions

Welcome to the spike wiki!

Here is the original problem statement:

User Personas

  • Jesse - designer
    • Goals
      • To make the app as beautiful as possible
      • With as efficient of a workflow as possible
    • Challenge
      • Having to communicating with developers in order to implement changes is inefficient & error prone
    • How we help
      • Enabling the designer to implement updates directly without having to communicate them to a dev
  • Eric - SW
    • Goals
      • Implement updates as efficiently as possible, with as smooth of a process as possible
    • Challenge
      • Being involved in small updates is a bother & distracts from real work
      • UI programming is complicated & there is a lot of duplication between projects
    • How we help
      • Reduces dev involvement in small updates & iterations with client
      • Enforces best practice architecture
      • Helps enables more sharing between projects
  • PM - Product Manager person
    • Goals
      • Get the customer to agree on a specific design
      • Make sure that the agreed upon design is what actually gets implemented
    • Challenges
      • Interacting with designers & devs to iterate over mockups is inefficient & error prone
    • How we help
      • More efficient way for application to leverage initial mockup effort

Terminology

Background Terminology - Nouns

  • Webpack configurations - Already exists
    • JavaScript library that loads a configuration file
    • Webpack is a javascript engine to create a Javascript/CSS application bundle given a webpack configuration file.
  • Bundle (Webpack terminology)
    • Collection of JavaScript code, aka module, defining the logic of a page & the components in it.
    • Provides dependencies required by components

Background Terminology - Verbs

  • Webpack compile
    • Extracts a subset of the codebase corresponding to a specific webpack configurations

New Terminology - Nouns

  • Page
    • A collection of components that can be displayed to the user.
      • Only one page is displayed to the user at a time.
    • A page corresponds to a JavaScript application bundle
  • Page state
    • Dictated by URL &/or JavaScript values
    • Controls the state of the page’s components
  • Components
    • A widget-like section of a page.
      • Components can have subcomponents
    • Components change based on Page State
    • Each component has:
      • HTML template
      • SASS stylesheet
      • Javacript file
  • Component field
    • A value that can be used by the HTML template to display dynamic data to the user
  • Application
    • Entire end-user facing applications (eg: Spike, OASIS 3 server)
    • Entire codebase
  • Offline Bundle
    • A bundle that enables the application to run without back end
    • A subset of the Application codebase
  • Online Bundle
    • A bundle that enables the application to run connected to the server / back end API
    • A subset of the Application codebase

Under the hood

Managing application state:

  • URL changes -> Page state changes -> Components change

Natural lifecycle of a project:

  • Step 1 - Define dependencies
    • Eg: pick graphing library, etc
    • Note: we may want to have a project template with default dependencies defined that we can clone at the beginning of new projects
  • Step 2 - Design React architecture
  • Step 3 - Scaffold components in code (HTML template, CSS template)
    • List of directories, each corresponding to a component.
    • Trend to larger number of smaller components
  • Step 4 - Application logic
    • URLs, global data, how components react

Potential lifecycle of the project w/ Product Manager that knows HTML/CSS:

  • Step 1 - PM starts with boilerplate template directory
  • Step 2 - PM adds HTML & CSS to make something like what the client wants
  • Step 3 - SW Engineer React-ifies the mockup
  • Step 4 - PM can download Offline Bundle & make minor tweaks
  • Step 5 - PM either emails zip file of tweaked files, or pushes the changes to Github & makes PR

NOTE:

  • Hard to automate management of fields
  • Need to document fields by hand (component-level)

North Star Stories

North Star Stories - New project story

ACME_CORP wants a new app for tracking WIDGETS. Starting from a default project template, Paul the PM creates a mockup of the new app using HTML + CSS. Paul iterates over several version of the mockup with ACME_CORP, finally converging on a final design. Eric takes this final mockup & React-ifies it so that it runs as an Offline Bundle. Paul then creates some tests to ensure certain important behavior get’s implemented down the road. Eric & team then go about programming the backend.

North Star Stories - Small tweak story

ACME_CORP wants user’s middle names to be displayed on the dashboard when users log into ACME_APP. So Eric compiles an offline bundle of ACME_APP & emails it to Jesse. Because Eric had previously documented the Component Fields, Jesse is able to add the user’s middle name data to the component’s HTML template. He then makes some small tweaks to the component CSS to polish the way it looks & emails Eric a new zip file containing his changes. Eric then merges those changes into the code with a new PR. Now users middles names are displayed like ACME_CORP wants.

Clone this wiki locally