Decide on reasonable git workflow approach

Don't have to belabor this, but we should start with something reasonable to help manage commits and minimize code conflicts. This is about workflow and not about technology.

Good overview of workflows here:
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow

Add headers and footers - scaffolding

Create home page structure/scaffolding

Include pop-over or description of column info.

EX: Need to provide column descriptions somewhere to help user understand what data they are looking at. For instance, would be rad to describe what sector gpc detail is

Implement testing framework

Per https://medium.com/@scbarrus/how-to-get-test-coverage-on-react-with-karma-babel-and-webpack-c9273d805063#.sghyj9ddg

Need render chart when new dataset is selected.

This maybe logged somewhere else already. Previous chart gets rendered when you select a new dataset.

EX: I was looking at stop sign dataset. Went to look at Bike network dataset. When I clicked on the bike network dataset, the old stop signs charts were displayed.

Develop embed component that reuses the charting components and accepts parameters from url

Decide on upper limit for number of groups displayed

Need to figure out upper limit for displaying categorical data

This is tight:

also affects group by multiple and group by single

Decide on upper and lower bounds for filter columns

Similar to group by display issue....need to set bounds on columns that you can filter by.

For instance, in the film locations dataset, consider the following:
by writer --> filter by fun facts

Fun facts has like 100+ groups. Since there are so many potential values, filtering by a specific value in this column is unlikely yield any results.

Introduce color into the column buttons to differentiate among column types

Reorganize and document folder structure

Not to lock in stone, but just to start out with something consistent and reasonable.

As a user, I would like to have a way to see a summary of current filters applied to the visual

This is regarding the "subtitle" to transparently indicate what filters are applied.

Give users stack and unstack options

Test filter cards and log improvements as necessary

First:

Finish filter card refactor
Address flickering via shouldComponentUpdate on chart

Removing filter options from a multi-select filter does not work as expected

This is another bug related to grouping and filtering that I'll try to fix all at once.

Basically when removing single elements from a multi-select list, the reducer chokes because it wants to merge the inputs, but it should actually be deleting from a copy of state and then returning that. The main fix should be in reducers/index.js

In the screenshot above, you can see it's showing 2 Outer Richmond values after trying to remove that category.

Adopt semantic versioning

Again, more of a workflow/code practice thing, but we should be intentional about this from the get go and just make sure we put it in the documentation. We can use tagging/releases to capture major, minor and patch releases.

http://semver.org/

Under this scheme we're under 0.1.0 until we finish MVP and then we will be 1.0.0-alpha.

Remove column that you are viewing from group by statement

Should be able to group by the same column that you are viewing.
EX: viewing "locations" column; but also can group by this column in the group by drop down.

Fix numeric charts so they display on appropriate chart

Remove columns with null values from charts

Column with no values display as clickable option.

EX: In the film dataset, the column "Smile again Jenny Lee has no rows. We shouldn't display this as column that you can explore.

Improve category based date filters

Date columns still visible in filter option drop down. Duplicates the date range filter.
Note: data column filters don't trigger an action/state change- so we should be able to just filter the text list getting passed to the dropdown

Consider using immutable.js to handle data immutably

While we can handle data immutably without immutable.js, the library does a lot things for us that are annoying to keep track of or handle.

For example, Object.assign({}, state, updatedState) can be used to make deep copies of objects, but it has interesting side effects. At this point, the code is simple enough that I'm not worried about this for the sprint, but as I've been working with reducers, I'm beginning to realize how immutable.js could help simplify issues related to treating data/state as immutable.

Should be easy enough to implement without too much code upheaval. I'll put this in the backlog for now.

Deep copy operations can be expensive so we should still apply common sense when updating state as we don't always need to create a copy for every action, but immutable.js could make our code simpler as we scale.

Add sort by options to charts

Roadmap to MVP

I'll flesh this out some more, but wanted to get a draft roadmap going so we can track overall progress. I'll also link to all of the collateral (wireframes, design specs as needed) for reference. This is just a list, we'll track the order/priority of these using issues and Zenhub.

Feature breakdown

Home page

Create home page structure/scaffolding
Build search component with autosuggestions

Dataset catalog search

Finish fine design on dataset cards
Finish fine design on facets
Determine data structure, fields and approach for loading datasets into search index

Dataset explorer

Finish fine design on persistent dataset information (title, description, basic metadata fields)
Create persistent related datasets footer just above site footer
Create tab for dataset overview
Create tab for dataset details
Create tab for charts
Create tab for map
Create tab for table preview

The following break down the dataset explorer into chunks of features

Related datasets

Develop approach to surfacing related datasets using existing infrastructure
Create components that show related datasets by certain dimensions (department, program (tag), etc.)

Overview

Create chart card component
Design parameterized URL structure for use in embeddable charts

Dataset Details

Develop component containing full metadata, including attachments when present
Develop field definition cards including name, type, stats based on type
Investigate Desk.com API
Develop component that shows any related knowledge base articles, if any

Charts

Embeds

Develop embed component that reuses the charting components and accepts parameters from url

Map

Develop approach to thematic mapping where a column exists representing the boundary
Develop approach to point-based maps
Develop approach to basic mapping of data stored as lines and polygons
Develop component that provides information to user on click of map feature
Develop component that allows searching by address
Develop basic query by radius and export to...functions (based on pd prototype)

Table Preview

Provide clearer UI indicator for sorting
Reuse field definition card component for on hover interaction for fields to provide JIT information

Implement eslint

Initiate and integrate eslint into the build process to help enforce javascript/jsx code standards.

http://eslint.org/docs/user-guide/integrations
http://eslint.org/docs/user-guide/getting-started

Investigate using context to implicitly pass variables down hierarchy

https://egghead.io/lessons/javascript-redux-passing-the-store-down-implicitly-via-context

We don't have much complexity in the codebase, but there are a handful of places where we're nested a couple of components and it would be good to make sure we're passing the store down in the most reasonable and maintainable manner we can.

Blank categories aren't labeled

When categories are identified in the socrata middleware, we currently pass through null categories as blank. The impact of this is you can't then see them in filter options and more importantly, can't filter by those blank categories. The fix is pretty simple.

Add just in time context for fields on filter cards

Per issue #37 instead of adding in code to remove certain categorical dates, I think we should provide some context to the user as a first pass so they can make informed decisions about which date fields to use. I want to avoid introducing programmatic controls that remove a field from filters that may or may not be duplicative of another field as this could introduce issues later on as we look at more datasets.

This will also improve the ability for users to understand other columns as they interact with the charts and is easier to implement.