phillydsa/phillydsa-com

Website of the Philadelphia Local of the DSA

phillydsa-com's Issues

Twitter Card Validation Fails

Expected Behavior

PhillyDSA.com links should validate and show a card in tweets

Current Behavior

Possible Solution

Getting this error from https://cards-dev.twitter.com/validator :

INFO:  Page fetched successfully
INFO:  26 metatags were found
INFO:  twitter:card = summary tag found
ERROR: Required meta tag missing (twitter:text:description)

Steps to Reproduce (for bugs)

1. Tweet a link from phillydsa.com
2. No card expansion

Context

poor engagement makes me sad and i want to fix

Your Environment

• Version used (if applicable): master which I think is @ 0.21?
• Browser Name and version (if applicable):
• Operating System and version (desktop or mobile) (if applicable):
• Link to your project (if applicable):

Difficult to find out where to sign up for updates

Expected Behavior

Should be easy for folks to sign up for updates from a chapter.

Current Behavior

Currently, in PhillyDSA this is hidden away on our Contact Us page

Possible Solution

Maybe add something in the footer or a sign-wide banner? Footer is a little less discoverable, but seems to be a widely-used design pattern. Site-wide banner (like at the top) is easier to find, but also a little pushy. Definitely no modals.

Context

New member wanted to sign up for updates from the local, couldn't find it. Sent them a message about where to find it and opened this issue.

Your Environment

• Version used (if applicable): https://github.com/PhillyDSA/phillydsa-com/releases/tag/0.23.1

FundraisingSnippet name is inapplicable to other use cases

Expected Behavior

The FundraisingSnippet class is basically just a generic embed code snippet, but the name implies that it's only for fundraising.

Current Behavior

Current naming scheme implies it's just for fundraising, when it's actually just generic.

Possible Solution

Change to EmbedCodeSnippet.

CTA in email template takes default color

Expected Behavior

The <h2> in the email template should be #fff.

Current Behavior

<h2> renders in most email clients (notably GMail) as the default black or grey.

Possible Solution

Maybe add an !important to the color declaration in the style sheet or inline it.

Steps to Reproduce (for bugs)

Context

Your Environment

• Version used (if applicable): 0.20.0
• Browser Name and version (if applicable):
• Operating System and version (desktop or mobile) (if applicable):
• Link to your project (if applicable):

Add email list sign up form

Requested to add an embedded sign up form a la http://www.socialists.nyc/info/

Page titles not properly set

Page titles for certain pages aren't being properly set. cf. https://phillydsa.com/events/

Expected Behavior

Page title should be set to something like "calendar" or whatever for https://phillydsa.com/events/

Current Behavior

Title is blank

Possible Solution

Ensure that the title of the page is the default fallback option.

Steps to Reproduce (for bugs)

1. Go here https://phillydsa.com/events/
2. Title not set.

Context

Your Environment

• Version used (if applicable):
• Browser Name and version (if applicable):
• Operating System and version (desktop or mobile) (if applicable):
• Link to your project (if applicable):

UX for ADA Compliant Venues

Expected Behavior

We would like to display on each event page whether or not the venue is ADA compliant. This information is somewhat difficult to track down unfortunately, but it is exceedingly worthwhile to do so. At a minimum, we should encourage event staff to affirmatively state whether or not a location or venue is wheelchair accessible.

Current Behavior

There is no indication of whether a venue is wheelchair accessible or ADA compliant, meaning our members are left in the dark as to possible access.

Possible Solution

For any event, we should have a field on the event that delineates whether or not the venue is ADA compliant. The expected values are Yes, No, Unknown. To the degree possible, the use of Unknown should be discouraged and possibly eliminated entirely.

Context

Our disabled members are unlikely to come out to our events if this information is not affirmatively provided, leading to the appearance that we have fewer disabled members than we do. It is incumbent on our chapter (or any chapter really) to ensure that this inference is not made because of the choices our abled members make.

Your Environment

• Version used (if applicable): 0.23.1

Better Location UX for Event Detail Pages

This is specifically related to event pages, an example of which can be found here

Expected Behavior

Events should clearly communicate that a location is either available or To Be Determined.

Current Behavior

Right now, if the location of the event is completely filled in, then everything works as it should:

and the event information is displayed clearly and the links to Google Maps works. But if the event doesn't have complete location information, that is not communicated to the user. For example:

The event should clearly communicate that the location is TBD and remove the Google Maps link. For example, if the location isn't filled in and a user clicks on the Google Maps link, this is what they get:

Possible Solution

Either use some sort of validation in the model code or move that into the template code. I'm not sure which is the better option. Template rendering is pretty slow compared to model validation, so that may be something to take into account.

Context

As a user this is going to be confusing for folks that are looking to get information about an event.

Your Environment

• Version used (if applicable): 0.17.0
• Browser Name and version (if applicable):
• Operating System and version (desktop or mobile) (if applicable):
• Link to your project (if applicable):