Skip to content

Mixins

Jump to bottom
mitchelljkotler edited this page May 8, 2015 · 11 revisions

Problem

What is the problem mixins are trying to solve?

Solution

Users should be able to design and save mixins that contain repeatable, boilerplate language.

For example, if a journalist regularly includes a few paragraphs about their professional background, they should be able to save that and then, when on the generate request page, have it be included with a single click.

Data

  • Title
  • Description (answering 'why does this mixin exist?')
  • Text (that the mixin should substitute into the communication)
  • An attached file (optional)

Conversation

Michael

Users should be able to save and design "mix ins" that either supplement or replace wizard language.

For example, if a journalist regularly includes a few paragraphs about their professional background, they should be able to save that and then, when on the generate request page, have it be included with a single click.

We can start as simple as we need to, but mix ins should:

  • Be definable and editable at will by a user.
  • Be able to be set to either on or off by default.
  • Be public by default, and allowable to private for pro users.
  • Be assignable by admins to agencies and jurisdictions, instead of users, so that we can suggest language per department or per jurisdiction.
  • Be trackable in how often they're used so we can see what is popular and effective.
  • Have a title that succinctly describes them on the request generation page, and previews the first sentence or two.
  • Be able to be relatively long (1,000 words max? More?)
  • Be able to replace intro language, outro language, or appear after the outro, or appear right after the specific document request (might be able to get this down to three options rather than 4).
  • Be savable to your mixins list from another user's profile.
  • One click to turn on or off from the request page.
  • Typing in an agency or jurisdiction that has mixins will suggest or add them to your request after you select that agency.
  • Users might be able to go to an agency or jurisdiction page and save mixins on a per agency/jurisdiction basis, though this seems to be getting complicated. It would be a good way for people to add advice.
  • Possibly have a note on mixins in why they're useful ("this agency always forgets that you don't need a form").

Allan

  1. Does this supersede Shawn's issue? If so, close/delete that one.
  2. This seems like something that should be a Pro-only feature.

Michael

Sorry, I asked Shawn for feedback via email. Lesson learned about backchannel confusion.

  1. Yes. Closed.

Regarding Pro, Shawn suggested the same thing. My arguments against:

This saves us work if we can add default language to certain agencies. For example, IRS, saying "Please see attached form" and including the attachment, or dealing with other weird agency requirements.

The users who have suggested the kinds of language in the past have all been community users with really great suggestions, but no organizational backing for a Pro account.

Over time, we want mixins to benefit from network effect, where we continue to have better and better requests organically over time (which we can analyze because we track how often they're used and how well they work). Limiting to Pro users not only makes the community user experience worse, but it means we have less data and it makes the Pro user experience work because they can't piggyback off of Community users. Keeping your mixins' private seems like a good fit for how to divide this line while not losing the overall site benefits.

The mixins name is probably bad and if you think of a better one, please let me know.

Allan

Once a mixin is made, is it editable afterwards? And if so, where does that editing happen? Sometimes you'd want the text field to be prefilled, sometimes you'd want to be given the chance to fill it in. The distincting between a boilerplate and a prompt mixin is interesting, something we should think about harder.

Other questions:

  • Can the text include HTML? Markdown? Just plain text?
  • Multiple files, or just one file per mixin?
  • Do you define the file at the time you create the mixin, or at the time you include it in the request? Kind of similar to the boilerplate/prompt mixin idea up above.

Mitch

Is the file suppose to be a file that is attached to the initial request?

Mike's original proposal is quite extensive. While being able to add to or override any part of the letter language would be useful, making it too customizable will make it a usability nightmare. I think starting with something simple and adding to it over time might be best. Like start with just an extra paragraph after the main request. These can be per user (credentials) or per agency (this agency always needs to be given special instructions). Not sure if per jurisdiction is useful. Having meta data on them (notes, stats) should be fine.

To Allan's question, I'd say plain text only... I don't think we currently support any formatting in requests

Clone this wiki locally