awesomefoundation / awesomebits Goto Github PK

From Kara:

I've noticed that there's some confusion on behalf of applicants and fellows regarding the "Sign-in" link (
http://www.awesomefoundation.org/sign_in?locale=en) on the homepage footer.

If a project has images associated with it, links to those images should be displayed in the dashboard view for the project.

If we're feeling fancy, the full-sized images can open up in a lightbox or something - otherwise, we can just open them up in a new window.

The main page animated intro is busted in the latest version of Chrome (21.0.1180.57). There are no errors - it just doesn't load. This is CSS animation, so we have to dig into this a little more.

Recent commits have changed the locales file, and the Portuguese translations need updating. See the history of the English locale file here:

https://github.com/awesomefoundation/awesomebits/commits/master/config/locales/en.yml

Since the main point of the Awesome Foundation is to actually fund projects, the individual chapter pages should have apply buttons, maybe up next to all of the social media connection links.

Currently, additional questions do not show up in the application review area, which makes it hard for trustees to actually review applications.

The "password" field on the invitation acceptance page is confusing. Clarify to indicate that the user is choosing a new password, not entering an old password. Also, make sure errors are displayed, if there are any.

This still needs discussion before implementing, but the idea is that the dean (or someone else I suppose) should be able to mark applications as hidden to make the review process for the trustees easier.

Issues to consider:

• Hiding an application shouldn't necessarily hide it for everyone - especially in cases where another chapter might want to fund something that has been passed over by the "intended" chapter
• Does hiding expire or is it just a toggle? (I think it should be a toggle -jcn)

Currently, the Photo model does not limit the kind of attachment it can have, which means that people have been uploading TIF and PDF files, which, when displayed on the homepage or on the project page, just break (since we're expecting them to be images).

Add a restraint to the paperclip attachment to prevent this and add the appropriate error notifications.

The email icon on the individual chapter page should just not display if there is no email set for a chapter.

In order to make the review process easier, trustees should be able to search by the following fields:

• Title
• Description
• Applicant Name

The search box should probably just go in the header along with the other filters since search should really just be another filter (along with date range, shortlist, etc).

Simple SQL search should be sufficient to get started.

Right now, only admins can do this.

Logged in users can create press items, so that everyone can see the awesome press we get.

As a trustee
I should be able to view contact information for a grant application
So that I can be in contact with the applicant

It's not clear right now that photos come from gravatar. Provide a link to Gravatar with instructions on the user's profile editing page.

Currently, projects that have been promoted to show up on a chapter's page will show the original application text, which might not be appropriate to show off to the public. Instead we should do the following:

• Add a new field that will hold the winning description
• Trustees (any trustee) should be able to see this field when editing the project, but it should not be visible to the applicant
• When a project is selected to be a "winner," the original description should be copied into the winning description field
• There needs to be a migration for existing winning projects
• The editing page needs to be clear about what the different fields are for. Maybe even do not allow editing of the original field for winning submissions

Right now, the edit button is just on the project page. A link to edit the project should also be added to the project view on the dashboard.

We should build some kind of "admin" section (dropdown, hover) which would hide the links to the following actions:

• winner assignment
• a link to the edit page
• delete project

The preferred image aspect ratio (940x470) should be displayed next to "Image Upload" option on application form and project page editor.

We currently do a pretty crappy job of letting trustees know that winning projects can have a funded description and can import an RSS feed from another site (say the project's actual blog). When a project has been funded, a status bar should appear at the top of that project somewhere that just links to the project editing page, anchored to the internal admin section.

Reading through apps on-the-go currently works, but could be better. This ticket is for adding some mobile-friendly styling. I think the simple approach is to do this in CSS with media queries (with some JS) rather than modify the renders that come from the app itself.

I'd love to take a stab at this unless someone else has started.

There is currently no way to do this. The easiest way to do this is to probably just build it in to the user editing page, but it could also be done in a completely different interface. Open to suggestions on how to make this work.

In Firefox, one of the application images seems to be getting uploaded twice. It looks like it's a function of how Firefox handles a clone() of an input field (it keeps the filename in place).

For consistency, all chapter slugs should be converted to lowercase before they are saved. We should also redirect any mixed-case chapter requests (/chapters/Ottawa -> /chapters/ottawa).

We should NOT just make the URLs case insensitive, because then we're going to end up with all sorts of SEO inconsistencies.

Filtering finalists up to yesterday and up to today yield different counts. I expect the count for a project to always be consistent.

This is probably a low priority, but Avi Caplan [email protected] has reported that the site is throwing an error in IE7. This only represents about 1.4% of our traffic, but if there's something we can do to at least keep the error from being thrown, that would be great.

We should do some user testing or heat mapping whatnot, but someone pointed out that the chapter page itself might be a bit confusing for someone with no context into the site. Swapping the "about" section with the "trustees" section would give some insight into the chapter first, and then highlight the people.

Though one of the reasons for the trustees being higher is that the trustees ARE the chapter, but I still think this would be a fair tradeoff.

No idea what this might look like, but it's an interesting thought.

It would be nice for trustees to know how many projects they are going to be reviewing in the dashboard. This should show up for all lists (time-filtered, chapter-filtered, shortlisted).

(originally requested by Jesse Taggert)

Since all of our dates are stored in UTC, our end date when searching for projects and not specifying an end date should actually be today's date at UTC, not today's date locally.

It seems that many chapters want to be able to print off grants, and I can see how this is useful.

I'm wondering if adding an "export to PDF" below the CSV export would be of benefit to enough people to merit inclusion into the site.

Format-wise, i'm thinking that one grant per page might be the most useful, so they could be printed, spread out on a table, etc.

As a user
I can view a feed of successful projects
So that I can know awesome.

When sharing the homepage on Facebook (for example), the description and image should be reasonable values.

And since every page on the site seems to be displaying the menu text instead of actually reasonable data, let's just set this for all pages unless we explicitly set it (which we will do for pages like project pages and individual chapter pages).

As an admin, after updating a user, I should be redirected to the user list, not the dashboard. A user editing his/her own profile should still be returned to the dashboard after editing.

When going directly to a chapter's page (http://www.awesomefoundation.org/en/submissions/new?chapter=seattle), the chapter's optional questions do not show up. Selecting the chapter via the dropdown does make them show up.

This project is blocked on the following stories: #70, #71

In order to streamline the application process and to allow trustees to send links around to each other, all submissions (published or not) should have internal permalinks. This is probably just an additional filter on the projects list, a la:

http://www.awesomefoundation.org/en/chapters/nyc/projects?id=123

This accomplishes several goals:

• Remove duplication of data display between the dashboard view of a project and the unpublished project view
• Make it easier for trustees to send links to projects
• Remove confusion as to what state a project is actually in - if it has a "published" view, it's published, otherwise, it is not

Currently the chapters in the submission form are just listed alphabetically. What do people think about grouping them by country/region the way they are in the header?

Right now, the main chapter page is showing the first image correctly, but the actual project page is showing the images in the wrong order.

The problem is actually with the way that the image carousel works. Because the images are piled on top of each other, the last image in the list actually ends up on the "top" of the stack (presumably with the highest z-index). They're in the correct order in the HTML, but they effectively display backwards.

There are two solutions:

• Fix the Javascript so that it actually cycles through the images in the correct order
• Reverse the images so the first image actually shows up last and thus is at the top of the pile

The first option seems more "correct" but the bottom option is much easier, so I think we're going with that.

See the "this is not a trash pile" project at http://www.awesomefoundation.org/chapters/nyc

Would like to be able to see more fields, like how money would be spent.

Going to a chapter page returns a "not found" page instead of the chapter page.

Looking at the values in the RSS feed field, it's clear that most people don't know what an RSS feed is. It makes sense to make this something that gets added only when a project is funded.

People are attaching way too many photos to their applications, which is causing many requests to time out. We're going to limit this to an arbitrary 5 photos, at least for now.

This came up in an NYC meeting, and for data, it might be good to gather this data. I'm thinking about slipping it into the application as an optional field, and also making it optional for a chapter itself - they could turn off the question from showing up in their application.

Thoughts?

When sharing on Facebook (for example), the description should be set to the first x characters of the actual public project description.

There should be a new role defined called "alum" so a trustee can be designated as having been associated with a chapter, but is no longer active.

• These Alumni should be listed on the chapter page in a separate section below the active trustees
• For simplicity (for a first pass) we can indicate that alum is mutually exclusive to any other role (if this actually makes things easier)
• Note: This feature might not make sense before we make it easier to modify existing roles

Self-explanatory. This is just a font-end fix so these pages don't look weird. See attached screenshot for current behavior.

When clicking the "Export Filtered" or "Export all from date range" links on the projects list, the user should download a file, but in the newest version of Chrome (22.0.1229.79) the exported list just displays in the browser.

This actually looks like a new "bug" in Chrome (though it was actually a design decision) - I think we should add a content-disposition header in this case since I'd imagine that everyone will always want to download this file and not view it in the browser.

http://code.google.com/p/chromium/issues/detail?id=152911