dobtco / dispatch Goto Github PK

Admins should be able to export lists of vendors, more?

An assumption: when a vendor looks at an opportunity, they care about this information in order of priority:

1. When submissions are due (or, if the submission period hasn't started, when the period opens)
2. When questions are closed (or, if it's not yet open for questions, when it opens)
3. When it's posted, to confirm it's a fresh listing

The timeline should visually reflect these priorities. So, for example, if submissions and questions aren't yet open, the sidebar could look like this:

Once submissions and questions are open, users don't care when that happened. So the sidebar could change to this:

cf #52 (comment)

I like the timeline that Beacon has:

If the user is viewing a filter which is already saved, the page should show an Unsubscribe link.

• Enum (permission_level)
• What else?

If the admin presses "Edit answer / Write answer", types in nothing, and presses "Save", an error should appear.

Repo uses a vulnerable version of rubocop: rubocop/rubocop#4336

Vulnerability is low severity and only affects developers.

Fix should be as simple as updating the rubocop gem

A "deploy to Heroku" button would be great, too.

opportunities/new/ and /opportunities/edit/title are two different pages with exactly the same content. They shouldn't both exist.

One idea: We remove the title page from the wizard, and add a Rename button to the wizard's page header. This would summon a Rename modal, like in Screendoor.

I need to be able to specify separate i18n for these pages, even though they have the same fields:

• Vendor signup
• Staff signup
• Sign in
• Account page

The desired tone of language needs to be different for the onboarding process than other pages. (For example, "What's your email address?" vs. "Email".)

Since the signup form for vendors is twice as long as that for government staff, it would be great to have separate i18n for each of those forms as well.

When a user unsubscribes from a filter (or, rather, "deletes" a subscription), we should let them know that the action has been performed successfully.

When an attachment is uploaded, we attempt to extract the text and store it in the attachments table. That text is then used for full text search when filtering in /opportunities. This triggers very expensive joins, aggregations, and to_tsvector function calls which collectively consume
large amounts of memory.

To better support searching through lots of large attachments we should find another approach to FTS other than pg_search's "associated_against" feature, which is not ideal for this use case.

I think it would make sense to create a dedicated search index and use pg_search's "multisearch" approach. We'd possibly have to make some changes to, or work around Filterer code.

Steps to Reproduce

1. Click on an opportunity in the Approve page.
2. Delete it.
3. The user is taken back to the homepage.

Expected Behavior

In Step 3, the user should return to the Approve page, so they can continue reviewing submissions.

Something that would work in the nav bar...

in the mailer...

...and also in the README.

It would be great if it was able to work for different color schemes, since the color variables are likely to be customized.

Outcome

Help alert government staff if they accidentally sign up as a vendor.

Structure

It would be nice if we could validate client-side for agency email addresses as they're typed in, and display an alert accordingly:

1. Not sure how to change the copywriting for the submission adapter options. I'd like them to be as follows:

2. Email should be the default selection here, I think. Otherwise, it's easy for admins to post opportunities while overlooking that there is no way for vendors to apply. If email's selected by default, the worst-case scenario is that someone gets a few emails by mistake. But that's easy to fix: they can manually enter in Screendoor or forward to the correct individual.

3. If the user selects "Neither", we should warn them of what they need to do. Something like:

The "Save and continue" button in the wizard is very confusing. I usually find myself clicking another tab and forgetting that my work didn't actually save.

At the very least, we should have a beforeUnload alert if the user clicks another link, asking them whether they want to discard their changes.

A few usability issues with the datepicker I'm having trouble implementing myself:

1. The default time on the datepicker should be 12:00am, not the current time.

2. The datepicker input fields should have placeholders, so that disabled users understand the format in which they should type:

This list is pretty worthless from a cognitive perspective. It's very hard to remember a filter by the time at which you subscribed to it.

Better: describe the contents of the filter in the list.

This could use a mockup before implementation.

Make a nice-looking page that contains the README text in a layout that's easier to visually scan.

Is this a bug?

vs

• README
  • Overview
  • For governments
  • For vendors

I assume that @jrubenoff can go through the app and find a bunch of things to fix that aren't visible to me as a non-designer.

• CSS should be added to themes/dvl-core/assets/stylesheets/themes/
• Templates should be edited in app/views/

Perhaps grab some more data from http://bigideasphl.com?

When a user is filtering a response, we should show them the number of matching search results.

Introduced in https://github.com/dobtco/dispatch/pull/41/files.

It is impossible to tell if you are hovering over the "Unsubscribe" link, or the "View" link.

We could ask a user to choose from a list of project templates, and automatically create the project for them on Screendoor.

Pending questions:

• How does a user authenticate w/ Screendoor (no OAuth...)
  • If we use a sitewide API key, how do we know which user to invite to the project?
• Do we pull a list of templates, or specify them in config vars?