Support multi-category initiatives

[ohadschn]

For example: https://www.hamal.org.il/ - They belong to many categories - transportation, equipment, hosting etc. We need to move to a reference-based JSON, something like initiatives.json and links.json (where the latter references the former)

This might replace the current "general help" category which I personally don't like (as many people wouldn't think to look inside it, rather go to their specific category exclusively)

[4tal]

@ohadschn What are the next steps?

[ohadschn]

@ohadschn What are the next steps?

I guess it would be kind of funny, as I'm basically suggesting we undo most of our splitting work and put everything in initiatives.json. All other JSONs would become pointers. For example, this:

//_data/links/EquipmentNFood/Main/links.json
{
  "name": "EquipmentMain",
  "displayName": "",
  "links": [
    {
      "name": "SupplyMatch",
      "displayName": "Supply Match",
      "shortDescription": "",
      "description": "יוזמה המחברת בין מבקשי ציוד לנותני ציוד",
      "tags": [],
      "url": "https://supply-match.com/",
      "website": "https://supply-match.com/"
    },
    {
      "name": "WoltFoodDonations",
      "displayName": "תרומות מזון ישירות דרך וולט",
      "shortDescription": "",
      "description": "מארזי תרומות של מזון דרך ולט לקניה של מזון בסיסי ושימורים",
      "url": "https://wolt.com/he/isr/tel-aviv/venue/support-the-south",
      "website": "https://wolt.com/he/isr/tel-aviv/venue/support-the-south"
    },
    {
      "name": "HamalFoodLogistics",
      "displayName": "חמ״ל שינוע מזון לחיילים",
      "shortDescription": "",
      "description": "קבוצת וואטסאפ לתיאום ושינוע של מזון ללוחמים",
      "url": "https://chat.whatsapp.com/KPZ7JqQyBLG3OSvtGlUAdx",
      "whatsapp": "https://chat.whatsapp.com/KPZ7JqQyBLG3OSvtGlUAdx"
    }
  ]
}

Would become this:

//_data/links/EquipmentNFood/Main/links.json
{
  "name": "EquipmentMain", 
  "displayName": "",
  "links": [ "SupplyMatch", "WoltFoodDonations", "HamalFoodLogistics"]
}

//_data/initiatives.json
{
  "initiatives": 
   [
     {
        "name": "SupplyMatch",
        "displayName": "Supply Match",
        "shortDescription": "",
        "description": "יוזמה המחברת בין מבקשי ציוד לנותני ציוד",
        "tags": [],
        "url": "https://supply-match.com/",
        "website": "https://supply-match.com/"
      },
      {
        "name": "WoltFoodDonations",
        "displayName": "תרומות מזון ישירות דרך וולט",
        "shortDescription": "",
        "description": "מארזי תרומות של מזון דרך ולט לקניה של מזון בסיסי ושימורים",
        "url": "https://wolt.com/he/isr/tel-aviv/venue/support-the-south",
        "website": "https://wolt.com/he/isr/tel-aviv/venue/support-the-south"
      },
      {
        "name": "HamalFoodLogistics",
        "displayName": "חמ״ל שינוע מזון לחיילים",
        "shortDescription": "",
        "description": "קבוצת וואטסאפ לתיאום ושינוע של מזון ללוחמים",
        "url": "https://chat.whatsapp.com/KPZ7JqQyBLG3OSvtGlUAdx",
        "whatsapp": "https://chat.whatsapp.com/KPZ7JqQyBLG3OSvtGlUAdx"
      }
   ]
}

It should then be a simple modification of the liquid code that accesses the data (in the index & search HTMLs), Something like replacing subcategory.links with site.data.initiatives[subcategory.name].

[ohadschn]

@4tal revisiting this, perhaps another approach would work better.

I suspect that the vast majority of initiatives are either:

1. Specific to a category
2. Relevant for most categories

As such, perhaps what we want is:

1. Keep everything as-is and add something like a generic-initiatives.json file with things like https://www.hamal.org.il/ (where they have forms for most types of issues)
2. Think of some way of displaying these in a special way, maybe have them always on top somewhere, or have them expanded when you first enter the site. for example see "Hamal1", see how a few links are special and always visible:

Alternatively, we could consider some alternative view like a grid, where you see everything and then filter by tag/category etc. (but that is a more radical change and can lead to info overload if we're not careful).

[4tal]

@ohadschn What about: { "tags": [ { "id": "tag001", "name": "Environment" }, ... ], "initiatives": [ { "id": "init001", "url": "https://initiative1.example.com", "tags": ["tag001", "tag002"] }, ... ], "categories": [ { "id": "cat001", "name": "Green Tech", "tags": ["tag001", "tag002"] }, ... ] }

but in 3 separate files

[ohadschn]

@ohadschn What about: { "tags": [ { "id": "tag001", "name": "Environment" }, ... ], "initiatives": [ { "id": "init001", "url": "https://initiative1.example.com", "tags": ["tag001", "tag002"] }, ... ], "categories": [ { "id": "cat001", "name": "Green Tech", "tags": ["tag001", "tag002"] }, ... ] }

but in 3 separate files

Might as well have one big file, where each initiative has a categories and tags property. However as mentioned above, I think we might be able to get away with keeping everything as is, but making the "general" category special and prominent in some way (see my comment above) - always on top / always implicitly added to each category (or at least linked to it with some text like "also see generic category" / page starts with it open, etc.

[chiptus]

May I suggest:

data/links - path for links
data/categories - path for categories

Link {
   ...info,
   categories: Array<CategoryId>
}

Category {
   id: CategoryId,
  order: number,
   parentCategory: CategoryId,
   ...info
}

each item has one file.

It will make PRs cleaner, as they only need to add a file. no conflicts.

About links order, I think we should support sorting by different fields.

[ohadschn]

I guess for order we could also name the files with sorting in mind, something like 0000-foolink.json 0001-barlink.json Then we can change order by renaming We can also leave empty places like 0000-foolink.json 0010-barlink.json so it's easy to put things between them

[ohadschn]

This will also leave the question of - what do we do when an initiative belongs to multiple categories? Display it multiple times? I guess we could ...

[4tal]

I guess for order we could also name the files with sorting in mind, something like 0000-foolink.json 0001-barlink.json Then we can change order by renaming We can also leave empty places like 0000-foolink.json 0010-barlink.json so it's easy to put things between them

Ohad, please don't choose violence today - https://www.youtube.com/watch?v=aknepzqkjiw

Let's not do naming based order

[ohadschn]

Let's not do naming based order

Well, we're going to have to sort by something... what do you suggest?

[chiptus]

Client side sorting. Have some order property for the initial order, but also let the user decide

On Tue, 31 Oct 2023, 23:30 Ohad Schneider, @.***> wrote:

Let's not do naming based order

Well, we're going to have to sort by something... what do you suggest?

— Reply to this email directly, view it on GitHub https://github.com/4tals/LinksForIsrael/issues/210#issuecomment-1788064185, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKRKF4D2UT3ADFKW4UTLWDYCFUWPAVCNFSM6AAAAAA6FOFUZKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBYGA3DIMJYGU . You are receiving this because you commented.Message ID: @.***>

[ohadschn]

I think we might be able to get away with keeping everything as is, but making the "general" category special and prominent in some way (see my comment above) - always on top / always implicitly added to each category (or at least linked to it with some text like "also see generic category" / page starts with it open, etc.

@4tal considering the above is now implemented, do we still want this?