Atomizing Project Cards

atomizingCards

##Atomizing Our Module Cards
###A Tangible Example of Atomizing Our Design
Since development practices can often be theoretical and difficult to grasp in concrete ways, I thought it would be worth doing a writeup on a real example of unifying (atomizing) a very prominent piece of UI in our current modules to encourage code reuse and save time.

###RESolution Cards
Currently, there are three modules that utilize "cards" as an entry point for varying module functionality. Those three modules are:

- Resolution Project Management
- Publication Tracking System
- Estimate Module (In Progress)

Their card designs look like the following, respectively:

<img src="https://cdn.pbrd.co/images/GGR1rI1.png" width="200px" align="left" hspace="10px"/><img src="https://cdn.pbrd.co/images/GGR39sj.png" width="200px" align="left" hspace="10px"/><img src="https://cdn.pbrd.co/images/GGR4w8b.png" width="200px" hspace="10px"/>
<br>
<br>
<br>
<br>
<br>

At first glance. These cards appear _very_ different. But many of these differences are superficial variation or unnecessary structural difference. Lets observe the core, shared features of all the cards.

	
- A Header area that contains
	- A Context menu
	- A Title
		- Every single module we go through the same "oh no what happens when the title gets too long issue", and someone spends a day dealing with it.
	- Optional metadata (id/date/type/etc...)
	- An (optional) res alert ribbon
- A content area with transcludable content
- An optional footer that contains
	- A transcludable content area
	- (optional) metadata(id/date/type/etc...)
	- An (optional) trigger for an expandable section with transcludable content (alerts, comments, etc).
- A way of paging card content
	- This is unnecessarily implemented differently on each and every module. Project uses "Current FY/ Whole Project" button toggles, Publications uses a footer link (See reviewers), and estimator uses a tab header. This could easily be standardized.

Defining those features, we see that _all_ of the above card designs can be consolidated into the below design, with optional features being overlayed in blue, and injectable content areas depicted with an 'X' placeholder block:

![enter image description here](https://cdn.pbrd.co/images/GGRGm3C.png)

This is obviously a pretty basic wire frame, but you can see how the different variations would work. But it combines all functionality into a single source in a reasonable manner. The visual differences (rounded corners, gradients, colors, etc) are trivial to add on a per module basis. This has the benefits of:

- Avoiding future duplicate work (saving time)
- Removing code bloat
- Allowing every module to benefit from performance improvements found by a particular team
	- We _dramatically_ optimized Publications Module cards, but performance in Project cards still leaves a lot to be desired, because the changes made to Publications didn't propagate throughout all modules.
- Giving the user a predictable, consistent mental model of data presentation and module navigation when switching between modules.