Create project filtering on HFLA Home Page

[harishlingam]

Create project filtering on home page that allows for filtering by programming language, location, and project status. This filtering replicates the functionality found on the Projects List page as wireframes earlier.

[StephenVNelson]

submitted this pull request to add filters to the front page.

[ExperimentsInHonesty]

this issue has a pull request is we need to determine where it fits in the redesign

[yuikomajima]

Filter items discussed on 5/3/2020:

1. Topic
2. Location
3. Language
4. Framework
5. Status
6. Site
7. Open Roles

[yuikomajima]

Hi @harishlingam @ExperimentsInHonesty , I did a draft wire here showing 2 things. For the sake of time I used Harish's mockup and includes wires on top of the mockup for the filters.

1. How a grid may look like. Left wire is 3 column grid, right side is 2 columns but a bit more compact than what we have.

Question: is there a character limit for these cards? If we are maintaining the current copy, going smaller than what we have now is a bit hard.

2. 2 types of filters. The left side would be individual dropdowns with smaller menu, and the right side the dropdown menu would take up the entire screen. For both filters would automatically filter the project below.

Question: Can you please tell me how many items there would be for topic, languages, frameworks, and open roles? Depending on this how we should show the items may differ.

Draft so far here: https://www.figma.com/file/0RRPy1Ph7HafI3qOITg0Mr/Hack-for-LA-Website?node-id=388%3A211

[harishlingam]

1. @yuikomajima We agree on going with the 3 column route. As for the character limit, thanks for bringing this up. We are going to make all descriptions limited to one sentence (so much shorter than they are now) across all projects.

2. I actually like way the layout of filtering looks on the right hand mockup, but the left hand mockup may be more mobile friendly. Please see comments below.

[ExperimentsInHonesty]

@yuikomajima We had this screen shot from this issue https://github.com/hackforla/website/issues/156#issuecomment-560940316 where it used a mobile friend sort buttons instead of the drop downs.
also, it allows us to break up the rows if screen size dictates.

NEVERMIND the above. I just realized we have to have the drop down because otherwise the sorts are exclusive instead of multiple factors.

@harishlingam provided a link to an article with some other options - work checking out as well.

[harishlingam]

@yuikomajima Just to clarify: One of the locations is "South LA" not "South Bay". Additionally, please add "Remote" as a location to the drop down.

Concerning project filtering:

Please see Best Buy's project filtering for an example of what we may do. Please see the execution of drop down filtering of the above page on mobile as well (screenshots are below):

https://www.bestbuy.com/site/searchpage.jsp?_dyncharset=UTF-8&id=pcat17071&iht=y&keys=keys&ks=960&list=n&qp=tvscreensizeplusrange_facet%3DTV%20Screen%20Size~55%22%20-%2064%22%5Etvscreensizeplusrange_facet%3DTV%20Screen%20Size~65%22%20-%2074%22&sc=Global&st=tv&type=page&usc=All%20Categories

[ExperimentsInHonesty]

The below screenshots represent what the user is shown after any filters have been selected. Please note that for development purposes, our design choice must be cross-compatabile across mobile and desktop browsers. In other words, we don't have the ability to show different filter styles depending on device.

Desktop Screenshot:

Mobile Screenshot:

[yuikomajima]

Thanks @harishlingam I changed the edit to "South LA." I added what a mobile version could be like using the filter that was on the left-hand wire. We could let the dropdown appear right below the dropdown, or alternatively we can make it into a slide-up menu similar to best buy.

figma link: https://www.figma.com/file/0RRPy1Ph7HafI3qOITg0Mr/Hack-for-LA-Website?node-id=503%3A823

[yuikomajima]

New updates on figma:

1. Real time Filtering
2. Not real time filtering

I created a new page in figma as these pages will now be its own page. I can add more styling once we confirm which direction we will be going.

https://www.figma.com/file/0RRPy1Ph7HafI3qOITg0Mr/Hack-for-LA-Website?node-id=532%3A1455

[ExperimentsInHonesty]

@yuikomajima These designs are great! @harishlingam I have asked @myastark to write something up for the top of the pages.

[ExperimentsInHonesty]

@myastark We need to convey the following information on this page. We are not completely sure where all of it is going (other than the filter stuff below). A rewrite will help us to have the next conversation with design about how to illustrate these themes.

• All projects open source
• civic tech
• for the public good
• use technology as a lever to amplify the work of our partners

The teams that make them possible

• staffed by multi-disciplinary teams of volunteers (from ??)
• various skills levels (from beginner to expert)
• educational background (From informal to formal, from highschool student to PHD)

This part needs to be rewritten so we can have some kind of tool tip or "How do the filters work" button, that displays the following:

• How the filter work
  • every filter you select reduces the total items shown, choose less filters for more results
  • some filters in the same category apply to the same project
    • e.g., DTLA and remote, all projects are currently remote and also retain their original location.
    • e.g., Most projects will have multiple topics: Heart project has both homeless and record-expungement; HomeUnitUs has both homelessness and youth.
• languages and Frameworks (many projects use Javascript, and you might also want to filter by frameworks like react, view, angular, etc.
• site: some projects have Proof of Concept sites, Staging or Testing sites, and Live sites
• status is either Active, Rebooting, On Hold, Completed, Closed
  • Active: the project is current in development (various stages)
  • Rebooting: restarting/rethinking a project to realign with current environment
  • On Hold: project that needs to go dormant for various reasons. Possibly to be either rebooted, or closed.
  • Completed: project whose work at Hack for LA was successfully completed. They are being maintained outside entities.
  • Closed: project that is not going to be rebooted, for various reasons

[tylerthome]

To make sure I understand the most recent photo posted as it applies to the spec:

1. South LA (0) means that there are no projects which meet both in West LA and downtown. However, if the user were to check this box, they may expect to see which projects meet in either West LA or South LA. Is it correct to assume that checking this box would actually display more projects than leaving it unchecked?

2. Similarly, the PM (10) under Open Roles means that there are 10 projects with open PM roles that meet in West LA. However, unlike the previous case, checking this box would display fewer results than leaving it unchecked.

As I understand it, the displayed projects can be defined as this set, assume that categoryX.valueY means that a project matches value Y for category X

(categoryA.valueA1 OR categoryA.valueA5 OR ...) 
AND 
(categoryB.valueB1 OR categoryB.valueB3 OR ...)
AND
...

If this is accurate, is it possible that the South LA (0) would be confusing to a user? Another option could be to have those numbers reflect how many records adhere to the constraints of other categories, but not its own.

I will be PRing a version which handles the filtering as specified, but with some knobs we can adjust if the team decides a different definition for the count

[ExperimentsInHonesty]

@tylerthome things that have zero results should either be uncheckable, or if you can check them, it literally will deliver you no results.

[ExperimentsInHonesty]

need user stories on how this should work and UX research

[ExperimentsInHonesty]

@tylerthome said

within categories its or (like small and medium), between different categories its an and (like small and blue).

Going to produce first version based on these catagories Status Location

[ExperimentsInHonesty]

@tylerthome please update issue with

1. Progress
2. Blocks
3. Availability
4. ETA

[tylerthome]

I may have commented on a similar issue instead of this one: there is an open draft pr #566 which contains the filter implementation and usage.

Progress: filter implementation complete, with an example UI to drive behavior for demonstration

Blocks: For code cleanliness and stability, data relevant to filtering fields should be consolidated with a consistent schema/layout such that initializing the filter can be automated reliably, and support the addition of new fields

Availability: I am available to continue working on this intermittently this week, and can update the example usage script when source data layout is specified and rendered

ETA: Depends on clearance of blockers -- once cleared, finalized version can be ready in 1-2 days as remaining work on filter is on the order of one hour of work

[ExperimentsInHonesty]

@tylerthome Let's talk about this:

Blocks: For code cleanliness and stability, data relevant to filtering fields should be consolidated with a consistent schema/layout such that initializing the filter can be automated reliably, and support the addition of new fields

Some examples would be good. I think you are referring to things like this, but more specificity about exactly what you need updated/changed would be helpful:

Replacing the current format

looking:
  - One skill
  - another skill
  - a compound skill (part 1, part 2)

With this format

looking:
  - Category: 
     Skill: 
  - Category: 
     Skill: 
  - Category: 
     Skill: 

[ExperimentsInHonesty]

What tyler was looking for had nothing really to do with my comments above.

@cnk is going to produce the json object that @tylerthome's code will consume.

ETA: Next week. Yeah!!!

[cnk]

https://github.com/cnk/website/tree/project-filter has the current state of this code. Before we can proceed, we will need to make some changes to our project.md files:

1. We need to make our locations into a list
2. We need to change the way we are keeping 'looking' data. Instead of the pairs of 'category' and 'skill' that were added in #581, we need a separate list for the categories (makes it easier to call 'jsonify' on the list).

At that point, I think we are ready for styling.

[ExperimentsInHonesty]

@cnk Can you give example of how you want the project.md file format changed. I am generally following but not enough to execute.

[cnk]

The current data for the website project looks like this:

looking:
  - category: UI/UX
    skill: Photoshop artist
  - category: Development
    skill: Junior JavaScript developers
  - category: Development
    skill: anyone wanting to learn how to do Git commits in a collaborative work environment
technologies:
  - GitHub Pages
  - Jekyll
location: Santa Monica, Downtown and Remote

To work well in the filtering code, we need location to be a list and we need the looking categories to be their own list. We could either make them their own top level list, or we could make sublists under looking. So either like this:

looking:
  - Photoshop artist
  - Junior JavaScript developers
  - anyone wanting to learn how to do Git commits in a collaborative work environment
skills:
  - UI/UX
  - Development
technologies:
  - GitHub Pages
  - Jekyll
location: 
  - Santa Monica
  - Downtown LA
  - Remote

or

looking:
  - skill:
    - Photoshop artist
    - Junior JavaScript developers
    - anyone wanting to learn how to do Git commits in a collaborative work environment
  category:
    - UI/UX
    - Development

[ExperimentsInHonesty]

@cnk . I get the locations, but kind of bummed by the fact that the roles wont be tied to their categories. It seems like its a recipe for pms to indicate that they have filled a role, but we are unclear which category it belonged to, so we leave the category on the card, not attached to any roll. Also, precludes the ability to just list all the open roles of a certain type, and then click to find out more about the project it is attached to. Is this really the only way?

[cnk]

I can't produce what we need for the filter in pure Liquid. But I managed to do it with hybrid of Liquid and JavaScript. Because I was working from @tylerthome's branch, I created a PR to merge into the project-filter branch of his fork: https://github.com/tylerthome/website/pulls

[tylerthome]

@cnk to capture what we have informally discussed in team meetings and in Slack, this is a notional example that could serve as a robust data format for the project filter:

{
      'projects': [
            {
                'id': 8379238,
                'attributes': {
                    'Technologies Used': [ 'Node.js', 'React', 'Sass', 'PostgreSQL' ],
                    'UI/UX Support Needed': [ 'Photoshop', 'Figma' ],
                    'Developer Support Needed': [ 'JavaScript', 'PL/pgSQL' ],
                    'Meeting Locations': [ 'Downtown LA', 'Remote' ],
                    'Status': [ 'Active' ]
                }
            }
      ],
     'filterableCategories': [ 'UI/UX Support Needed', 'Developer Support Needed', 'Meeting Locations'  ]
}

The most important aspect of this is that some field ('attributes' in this example) be provided in a uniform way so that we can automate the process of indexing the projects by the relevant values. Since most of the categories so far can have multiple values for a single project (e.g. one project can use multiple technologies), I would suggest that we use a collection type even for attributes that may only take one value at a time, like 'status'. Additionally, a top-level field like 'filterableCategories' can then easily be used to add/remove different dropdowns from the filter toolbar. Thus, a fully config-driven project filter would be made possible.

If this level of extensibility is not important for this feature, we can pursue a more hard-wired approach to build the index for each category in dedicated JS routines. For example, if a single "Looking For" dropdown with nested subcategories is required, with "Location" as a flat string array, and "Status" as a single string value -- the configuration-driven approach may become unwieldy.

@ExperimentsInHonesty this example separates the 'Looking For' into dedicated categories, but could be rolled into one if a single dropdown were more desirable. Keep in mind this is merely a 'view' of the underlying data in the .md files, rendered into a JS object at build/launch time by Jekyll, and does not affect what level of detail is available to the project cards.

[cnk]

1. Progress: Project data is now in the DOM in a usable way. Which filter dropdowns to create is now controlled by the filterableCategories parameter. Latest code is available at https://github.com/cnk/website/tree/project-filter
2. Blocks: None. This is ready for a front end / JS developer to take over, style, and create a final pull request.
3. Availability: @cnk None
4. ETA: depends on someone taking this up and finishing it

[ExperimentsInHonesty]

1. Locations needs to be made into a list (separate PR)
2. taking the whole branch and making it look like designs

[alexandrastubbs]

Data available: Location, Status, Technology, and Looking For.

*Location needs to be revised in markdown files (separate issue)

[cnk]

Currently looks like:

[cnk]

@ye-susan The latest code is https://github.com/cnk/website/tree/project-filter Make a new remote for my fork (just like you have 'upstream' for the main Hack For LA project) and then make a branch in your fork that starts from my project-filter branch.

[ExperimentsInHonesty]

Dependency #593 has been assigned to @efrenmarin45 - which will have him reformat the location structure to be the following style:

location:
  - Downtown LA
  - Remote

[ye-susan]

1. Progress: Basic styling of the filters are finished
2. Blocks: Need to fix arrow on filter when item is selected, and need to add site and language data
3. Availability: Mon-Tue, Fri-Sun
4. ETA: TBD, dependent on retrieving site and language data

[ExperimentsInHonesty]

@ye-susan reminding you to push this for review as soon as you have fixing arrow on filter when item is selected resolved. Better to launch this without all the filters first, improve after. Agile is iterative. Waterfall is nothing gets pushed until it's all done. Don't get wet!

[ye-susan]

@ExperimentsInHonesty Will do! I realized that I didn't create the mobile version of the styling after fixing the desktop version, so I'm currently working on that - I'll push it as soon as I'm done

[ye-susan]

1. Progress: I'm having trouble recreating the mobile version of the project filters to look like the figma, what would the designers think about the following style?
2. Blocks: n/a
3. Availability: Mon-Tue, Fri-Sun
4. ETA: I can create the PR asap if the designers are okay with how the mobile looks for now, and can continue to work on making it look more like the Figma