codefordenver/comrad

Open-source web application for radio stations to manage show schedules, traffic and compliance

comrad's Issues

/traffic/create/schedule

Create traffic schedule

/traffic/details/:id

Getting all details for a particular event

README

Need to work on building a README file with all of Comrad documentation as well as on boarding details

Supporting Pieces of the Software

These aren’t standalone modules, but are used by all the other modules as core pieces of Comrad.

TODO: details on these

• Login/Security
• API Token Creation
• Editable Pages?
• Where a station could add any information they want in an internal portal for their DJs

Paper Prototypes

Paper Prototypes

You should have several ideas from your brainstorming session.

• Group any similar ideas together.
• Take one idea (or group of ideas) per person and spend 5 minutes building a paper prototype.

How to build a paper prototype

It's simple! All you need is a piece of paper and something to write with to draw out your solution.

No one expects it to be pretty, don't worry! Add as much detail as you can around how your solution might look or work.

Pitch for Active Development

Pitch for Active Development

If you have gotten this far, and have completed all the previous cards you should be confident to move this into the Active Development phase and build a minimum viable product. (If you don't feel this way, it is totally fine to not move forward with the project)

To pitch for active development to the group, coordinate a time on the weekly agenda to take five minutes to update the group on the state of the project (this does not need to happen on standard 1st Monday of the month pitch night).

The purpose of this pitch is to present the state of the project, and pitch that it is worth putting the effort in to develop the MVP.

There are a few specific things that we'd love for you to preset:

• who is the partner organization
• who are the users
• MVP mockup
• show overview of research
  • what already exists
  • how do you know this solution will be valuable

Similar to the original pitch, there might be a call for further refinement, and a request to hold while work in progress is wrapped up before moving forward.

Hope to get your MVP developed shortly! 😄

Keyword search of library

Search for library of tracks via some API

API Endpoints

We would like to have the following endpoints for reading data from Comrad:

• Plays endpoint
  • Shows the most recent tracks played
  • Allows filtering by:
    • Host (string)
    • Host id (int)
    • Show name (string)
    • Show id (int)
    • Start time
    • End time
  • Default of 30 results
  • Can set “page” parameter to go back further. For instance, page=2 would return recent plays #31-60 instead of #1-30.
  • Can set “count” parameter to return the number
    • Todo: check other APIs to see if the naming of “page” and “count” is generally consistent across APIs. There may be different terms that are more commonly used.
  • Results are ordered with most recent track first
    • API accepts the Sort=asc parameter, which changes this so the most recent track is last and the oldest track is first
  • Returns this data:
    • ShowName (string)
    • Host (string)
    • StartDateTime (date/time)
    • TrackTitle (string)
    • Artist (string)
    • AlbumTitle (string)
• Shows endpoint
  • Shows the most recent shows
    • Only shows event instances that are ScheduledShowInstance, will not show other events like ticket giveaways or legal ID events
  • Allows filtering by:
    • Host (string)
    • Host id (int)
    • Show name (string)
    • Show id (int)
    • Start time
    • End time
  • Default of 30 results
  • Can set “page” parameter to go back further. For instance, page=2 would return recent plays #31-60 instead of #1-30.
  • Can set “count” parameter to return the number
  • Calling with count=1 and without filters to get the current show being played.
  • Returns this data:
    • Id (int, scheduled event instance ID)
    • ShowName (string, ie, “Sleepless Nights”)
    • Host (string)
    • StartDateTime
    • Duration
    • ShortDescription
    • LongDescription
    • RecordedFileName (string, path to archives)
• Playlists endpoint
  • Shows the playlist for a particular show
  • Must specify show instance ID (can be retrieved from Shows endpoint)
  • Results are ordered in the order they were played, with the earliest first
  • Returns this data:
    • Type (string, ie, “Underwriting” or “TrackPlay”)
    • StartDateTime (date/time)
    • Title (string, could be track title or the title for another event, like “OZO Coffee—trade” for underwriting)
    • Artist (string)
    • AlbumTitle (string)

/scheduling/search?start=*&end=*

Getting the shows in a specified timeframe

/traffic/create/event

Creating traffic event

Define the testable MVP

Define a testable Minimum Viable Product

An MVP is the smallest possible increment of your solution that delivers enough value for you to be able to ship it and learn from customers as quickly as possible.

• Agree as a team: from your paper prototype and lean canvas, what's the riskiest assumption you're making?

For example, if you were building a device that would automatically pour beer for you, the riskiest assumption might be technical - how do you know how much volume of beer to pour? If you were building AirBnB, the riskiest assumption wouldn't be tech, but instead would be trust - will users rent out a bedroom in their house to a stranger?

• Take your riskiest assumption and figure out the smallest increment you need to build to test that assumption.

• Take that increment and create cards on your board to represent what your team needs to get done in the next Sprint to build that iteration. Think about what it will take to test your MVP - it's not just about building something, it's about building something you can use to learn from as fast as possible.

This backlog of work can be used in your pitch too, to answer "What's next?"

/traffic/custom/event

Create individual instance of event

/traffic/delete/event/:id

Delete traffic event via ID

/scheduling/delete/show/:id

Delete show via ID

/traffic/search?start=*&end=*

Get events in a particular timeframe

/traffic/delete/schedule/:id

Delete traffic schedule via ID

/playlist/create

Create playlist

/traffic/edit/schedule/:id

Edit schedule via ID

Needs

/scheduling/delete/schedule/:id

Delete show schedule via ID

/traffic/edit/exception/:id

Edit traffic exception via ID

Test Your Guesses

Test your Guesses

By now you should have:

• Boxes 1-4 filled out on your lean canvas
• A paper prototype of a solution

So far we've made a bunch of guesses. What problems we think exist, what customers we think have that problem, and what solution we think would solve it.

Before moving on, we need to test those assumptions with some potential customers.

• Spend 1 hour trying to find people who fit your customer segment and talk to them. Call your friends, find people on twitter, even pick up the phone and call businesses. The more people you can talk to, the better!

Who's Your Customer?

Who is your customer?

Fill in Box 2 of your lean canvas.

Ask yourself:

• Who do I think this problem (from Box #1) is most painful for?
• Who do I think my "early adopter" will be?

Be specific! For example, instead of saying "Teenagers," narrow it down to "Female high school students who own cell phones."

/traffic/delete/exception/:id

Delete traffic exception via ID

Does this Project Already Exist?

Does this project exist?

Have you found solutions for the same challenge that exist already? Are there apps or solutions out there that are already being used to address this issue? If so, how do they fall short of meeting their goal, if at all? Be honest with yourself. Is it worth our time to build something that competes with what’s already out there? Are there ways we could improve on existing projects to be more impactful? If there’s nothing already out there that addresses this challenge, ask yourself why not. What barriers exist that inhibit progress in this area? Does this challenge call for a technical solution? Maybe the issue is at heart an organizational or physical one, rather than something that a tech approach can solve.

Identify existing alternatives

Take time to discuss as a group how people solve this problem today. Document all of the existing ways people solve the problem you want to solve.

/scheduling/delete/exception/:id

Delete show exception via ID

/scheduling/create/schedule

Create a show schedule

/scheduling/edit/show/:id

Edit show via ID

Test with Users

###Testing with Users
Great! You've created something for your project!

Now we want to get user feedback to make sure our assumptions match customer expectations. Hopefully by now, you have a relationship with a partner or partners to which you can throw your newly-developed software.

Be sure to put the product in front of them to how they use it, and incorporate feedback into your next iteration. Validate that you're solving the right problem, and check to make sure you've reduced any friction involved in the user experience. Pivot as necessary.

This cycle of refining after demoing should go a long way towards injecting life into the project. That should translate into the customer getting a lot of value from our efforts!

For more information on UX research, see this presentation given at one of our Code for Denver Meetups.

Copyright 2016 CA, Inc.

/scheduling/create/show

Creating a show

Music Library Module

TODO: add details

CRUD of a music library that provides the song database for the playlist module
APIs to access
Ability to import from external systems & export

Brainstorm solutions

Brainstorm Solutions

• Using a timer, take 5 minutes to write down as many rough ideas on sticky notes as you can.

• Go around as a team and put your sticky notes on a wall as you say what you wrote.

• Group similar ideas together.

When you're finished, you're ready to move on to creating paper prototypes!

/traffic/custom/event/edit/:id

Edit traffic custom instance event via ID

Team Formation

Form a team of 2 to 5 people

Gather with at least one other person to create a team around an idea or a problem that's interesting to you.

Spend a few minutes asking these questions:

• What's our shared vision?

  • Talk about what goal you want to accomplish as a team.

• What's in it for me?

  • Talk about each individual's motivation - what do you as an individual want to learn or accomplish?

• What talents do we bring to the table?

  • Share a bit of your experience and skills

• Set working agreements

  • What agreements do you, as a team, want to make for the time you are spending together?
  • Suggestions:
    • Show Up On Time
    • Agree on when you'll meet
    • "Art of the Possible" - no idea is stupid, let's consider everything.
    • Be Present - when you're here, you're here, be intentional with your time.

That's it! Now you have a clear goal for your team to accomplish and you know why each of you are here.

Build!

Let's build something!

You should now have a backlog of cards on your board representing what you need to do to build and test your MVP. Let's get to work!

For best results, timebox your development into 20-30 minute mini sprints using a timer to continually check on progress and give you the best chance of reaching your goals by the end of the event.

Traffic Module

This is the most useful module in Comrad given the current landscape of community radio software. There are not other affordable solutions that do this.

Traffic, in radio terminology, refers to the timing of legal ID announcements (“KGNU broadcasting on 88.5FM”), underwriting announcements, and other information that DJs need to be aware of that is not a part of their show, necessarily.

This module will include:

• Traffic event creation
  • Will allow event types like underwriting, legal IDs, ticket giveaways
  • TODO: pull the current list from Comrad
• Traffic event scheduling
  • Will allow scheduling events,
    • Including repeating an event in a series with intervals like “every two weeks”, “every first Friday”, “the 6th day of each month”, “every Monday and Tuesday”
    • Should allow exceptions to the schedule – for example, shows may be canceled on Election Day to make room for special Election Day programming
  • Will allow customizing an individual instance of an event without affecting other events in the series
• JavaScript widget for:
  • Displaying all events in a particular timeframe,
    • Should show the high-level of the details of the event,
    • With the ability to drill down to see all details of the event
      • Or edit some details for the event – for example, enter a winner’s information in a ticket giveaway event
    • And, should have an indicator to display the current time
• APIs for:
  • Getting the events in a particular timeframe
  • Getting all details for a particular event
  • Creating an event
  • Editing an event
  • Deleting an event
  • Creating a schedule for an event
  • Editing a schedule for an event
  • Deleting a schedule for an event
  • Creating an exception to a schedule
  • Deleting an exception to as schedule
  • Customizing an individual instance of an event without affecting other events in a repeating series
  • Deleting the customizations for an event and reverting it to the original

Other Components

• Language Localization
• API documentation
• General documentation

/scheduling/edit/exception/:id

Edit show exception via ID

Is the Problem Worth Solving?

Is the problem worth solving?

When deciding on what projects to build at Code for Denver, one of our primary concerns is the impact a given project will have on the community. This is why we emphasize the user aspect of the project: does this project benefit an identifiable group of people? Can you find real persons to test prototypes and the MVP? If you can’t identify who will benefit, and this project can’t be quantified in terms of users and user-testable MVPs, then this project might not be a good fit for Code for Denver.

There is no ego associated with a project, so it’s not a personal reflection on you or your interests if the problem isn’t a good fit. It’s entirely okay to do some research and determine that a project isn’t worth solving or not a good fit for CFD.

Try a lean canvas model

A lean canvas is a great way to lay out key components of your project success model so you can start testing your assumptions and get to building something customers want as fast as possible.

To create a free digital version of a lean canvas, go to Canvanizer. Alternatively, you can print this lean canvas

How to write a problem statement

Choose one of these two formats, and write down your problem:

• I believe [type of people] experience [type of problem] when doing [type of task]
• I believe [type of people] experience [type of problem] because of [limit or constraint]

You can have more than one problem statement, but no more than 3.

Research Potential Partners

Research Potential Partners

• Teams should identify at least two potential project partners.

• Potential partners should be non-profit, government, or quasi-governmental organizations, community-based organizations or other community groups or organizations consistent with the CfD mission.
  Teams should identify if the initial idea is consistent with potential partner organization mission and goals.

• Teams should be able to clearly identify how potential partners could used the built solution, how they would maintain the end product and partners overall role in the built solution product live cycle.

/traffic/create/exception

Creating traffic exception

/scheduling/edit/schedule/:id

Edit show schedule via ID

Pick a Solution

Pick a solution

Which of the paper prototypes is your team most excited about?

• Decide as a team on the top 1 or 2 prototype(s).
• Add the solution(s) in Box 4 of your lean canvas.

Remember to ask yourself: Does this solution solve the problem (Box 1) for your customer (Box 2)?

What Makes Your Solution Different?

What is your Unique Value Proposition?

Fill in Box 3, the "Unique Value Proposition."

What is a UVP?

Your unique value proposition is the promise you're making to your customer that's compelling enough for them to jump on board.

Writing a UVP

Here are two suggested formats:

1. Ask yourself: "If I solve the problem [by doing this] for my customer, is that compelling?"

When you can substitute [by doing this] with something compelling, that's the Unique Value Proposition you're proposing.

2. Complete the statement: "I can promise [the customer in Box 1] who faces [the problem in Box 2] that I can give them [unique value proposition in Box 3]."

Lastly, don't forget to fill out the High Level Concept! This serves as a clear way to describe who you are. For Uber, this would be "Order a taxi with your phone." It can also be an 'x for y' concept like "Instagram for Pet Lovers."

Playlist Module

This module will allow for letting DJs record what tracks they have played in a particular timeframe. This is done both to make that information accessible to the listener and collect data for reporting that’s needed for legal compliance

TODO: add details to these

• Reporting
• Music Library Config – API config to access? (how can this be used if you aren’t using comrad’s music library module)
• Can pull data from itunes APIs for finding tracks
• Widget: show playlist
• APIs
• Metadata Push: how to feed metadata so that you can see what is currently playing in a now playing widget, send this data over radio airwaves for radios in car to display current song, etc.

TODO: how do we do this, technically?

/traffic/custom/event/delete/:id

Delete traffic customer event instance via ID

Pivot or Persevere

Should you Pivot or Persevere?

What feedback did you receive from potential customers?

If the feedback confirmed that you're solving the right problem, for the right people, in the right way, awesome! Let's move forward.

If you received feedback that makes you want to rethink your problem, customer segment, or solution, now's the time.

• Update your lean canvas, and consider going back to the brainstorming and paper prototyping phase to take another shot at it.

Keep iterating until you get feedback that tells you to push on! Keep track of your pivots to share how you arrived at your end solution during your pitch.

/scheduling/create/exception

Creating an exception to a show schedule

/traffic/edit/event/:id

Edit traffic event via ID

Show Scheduling Module

This module will provide a way for stations to specify what shows occur at what timeframes.

The functionality will include:

• Show creation
• Show scheduling:
  • Functionally, this is the same as the scheduling for traffic events – allow repeating events and allow customizing of individual events
• JavaScript widget for:
  • Displaying the show that’s currently on air
    • An option for linking the show title to a URL
  • A widget that shows the schedule for the day
  • A widget that shows the schedule for the week
• APIs for:
  • Getting the shows in a specified timeframe
  • Creating a show
  • Editing a show
  • Deleting a show
  • Creating a show schedule
  • Editing a show schedule
  • Deleting a show schedule
  • Creating an exception to a show schedule
  • Deleting an exception to a show schedule
  • Customizing an individual instance of an individual show
  • Deleting the customization of the individual show, reverting the show back to the repeating instance’s details