Adding insights/holons/challenges as plugins requires a very different file structure and some build process adjustments.

This part only addresses the front-end part of the architecture. Getting the plugin system functioning correctly involves more back-end work. See #28.

Images. Description. Features. Purpose. Anything else?

Using grunt-gh-pages plugin, or something like it.

The happathon engine is a standalone black-box form and alert generator that will eventually be ported to other platforms so that other apps can include it to trigger actions in their own app based on well-being states. This issue only addresses the alert generator.

For specs, check out the scenarios in the specs doc

The engine should be encapsulated in its own directory ([here](Directory at:
https://github.com/IDCubed/oms-happathon/tree/master/src/common/happathon-engine)).

Related to:
#22

At https://github.com/IDCubed/oms-inside/blob/master/PLUGIN-AUTHORING.md

Should contain info on authoring all types of plugins necessary for v0.1

The happathon engine is a standalone black-box form and alert generator that will eventually be ported to other platforms so that other apps can include it to trigger actions in their own app based on well-being states. This issue only addresses the form generator. The alert generator will be separate. For now, the plan is to make it angular-based and encapsulate it in its own directory. It should have a simple API that allows it to:

• Generate consistent forms upon request
• Add to existing forms.
• Not remove or change its existing internal forms (to keep measurement consistent)
• Generate the base forms out of the box through sensible defaults.

For more details on how it can work, check out the forms scenario. Improvements on those scenarios are always welcome.

Directory is located at:
https://github.com/IDCubed/oms-happathon/tree/master/src/common/happathon-engine

I'm unsure what's involved in the android app dev process necessary for us to get started on the android piece. Android dev help welcome!

Will likely progress with #11. If anyone sees something in the doc linked with #11 they want to take a crack at, feel free to submit a pull request.

Get Bower installing packages correctly in OMS. Per luminous, it'll likely involve the virtual resource controller. We can discuss.

For more on the design/data details, see #36.

In https://github.com/IDCubed/oms-happathon/issues/milestones

Outline these before going for visuals?

Eventually we'll need to move from the mock backend I have in place now to an OMS backend.

Here's the link to it in Basecamp. To get started on this, read through the discussion in #17, comment here that you're starting, and dive in!

There was an issue with some invisible characters in the eslint.json config file. I upgraded grunt-eslint while fixing it.

Specs continually evolving at:
https://docs.google.com/document/d/1nIsGD8hBZzxtAUj9Vmxt7dpShjy4JgYDCFzDG7uG_s4/edit#heading=h.aecza7kb23ul

What should we use to generate hackathon design artifacts? Ideally we'd be able to do some form of user testing with them also.

Some options:
Balsamiq
Proto.io
Lucidchart

Others?

Let's find a good example of mobile form design to model how forms in the app look and function. If you have any examples of excellent mobile form design, linking those here is a great place to start.

At what frequency and duration.

This is code free, though general geekiness may help. :)

Here's the link to it in Basecamp. To get started on this, read through the discussion in #17, comment here that you're starting, and dive in!

In progress.

https://docs.google.com/document/d/1nIsGD8hBZzxtAUj9Vmxt7dpShjy4JgYDCFzDG7uG_s4/edit#

requires #22

Sections (or links)

About
Specs
Usage Scenarios
Contributing

Architecture:
The build process should know nothing about the presentation. That way we can eventually shift to a native Android UI by switching which presentation parts we use, without having to change the plugins themselves.

Utils folders:
Each type of plugin (e.g., forms) will get its own utils folder specific to each presentation platform. So there is an Angular form utils folder for displaying the form as HTML. It contains html partials, css, and js files. Eventually there will be an Android form utils folder for displaying the form in Android.

Plugin folders:
Each form plugin itself should only contain a happathon.json file which which references the form parts in the form-utils folder. (I need to finish changing all the references from "happathon" to "inside". This ticket needs to be updated also afterward).

How to integrate:
How to get the css and js to run without the build process knowing about them... placing it in the utils plugin's json config would work. I don't have a config json specced for utils plugins yet though. Need to create that.

We currently have a style guide at https://github.com/IDCubed/oms-happathon/blob/master/CONTRIBUTING.md. Okay. Well. I thought we did. Looks like I left those sections TBD.

Check out http://flippinawesome.org/2013/12/02/eliminating-code-smell-with-grunt/

We're using jshint right now, but not jsbeautify. Implementing jsBeautify with grunt would allow us to mostly eliminate style differences in how we write our js without needing to learn complex style guides.

Entering notification settings (e.g., hours a notification can display, # of notifications) in the web app should modify those settings in the Android shell.

The instructions for downloading a VM are located at http://docs.openmustardseed.org/get_started/tab_dev_environment/

The VMs require an ID3-provided key to decrypt. Soon there will be a UI to automatically download the VM and get the key emailed to us. I'm getting one manually for @sDurgam and I so we can get started. It should be coming via email this evening or tomorrow.

@sDurgam The last line of the VM instructions says that phone interaction isn't yet supported. We'd have to do some DNS configuration and port forwarding to get it working on the VM.

@illumin-us-r3v0lution I pasted the updated sequence diagram in #9. Does that help for what we're trying to do?

5 personas. Use specific census data for New Beford and Somerville.

This also involves some general cleanup, including updating the README's directory structure.

Getting this in place to start iterating on these since there is some tension over what should be public vs. private. Helpful links:

• http://ben.balter.com/open-source-for-government/
• http://producingoss.com/en/getting-started.html

Current communication channels:

• Github
• Basecamp
• Meetup
• IRC
• Email
• Google Hangouts
• In person at Code for Boston

Types of communication:

• App development
• Engine development
• App customization for cities
• City marketing campaigns - for positive public response
• Presentation Decks - for org funding opportunities, speaking publicly about the project, stakeholder updates, etc.
• Bug reports
• Feature requests
• Developer Chat
• Beta Tester Feedback
• UX Feedback

Risks:

• Sensitivity from those of us contributing personal data - to how it is used. We need to understand that super clearly.

Stakeholders:

• Psychologists
• Happathon staff
• City staff
• Programming volunteers
• Design volunteers
• Data Science
• UX volunteers

Considerations.

Paper, pencil, and taking a pic with a phone will work fine. Something digital is great too.

Here's the link to it in Basecamp. To get started on this, read through the discussion in #17, comment here that you're starting, and dive in!

Here's the link to it in Basecamp. To get started on this, read through the discussion in #17, comment here that you're starting, and dive in!

After recent discussions and architecture changes, the UI needs improvement. For example, as people add holons, the current horizontally scrolling design will get cumbersome. A vertical list is easier to navigate and more scannable. The large buttons and menus were also an inefficient use of screen space.

I completely rethought the UI this evening and drew up some thoughts on paper. Stay tuned for photo attachment.

Redoing the build process for #30 took them out. If we're comfortable with the navigation (see #33), getting tests in place to make sure it continues working as expected is a super high priority.

Hey @MarioCarloni

Initial form thoughts:

• Slider: Life satisfaction, 0-10.
• + button to journal an event that increased my satisfaction today.
• + button to journal an event that decreased my satisfaction today.

The + buttons each add textareas when you click them, so some initial data would be:

• of well-being increasing events

• of well-being decreasing events

• Words chosen
• Typing speed is possible
• Common words (word cloud?)
• Word relation to life satisfaction

We can pull lots from just those as a start.

I'll work on building the form. Any thoughts on ways to visualize the data for self or city that would be interesting to you?

It'll be easy to create other forms, so we can branch out from the initial one. For example, another form might involve relationships. So we can see how various aspects of our internal lives vary according to the people we interact with.