New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Public locations for food distribution (Food-share points, open fridges) #354

Open
tiltec opened this Issue Feb 27, 2017 · 15 comments

Comments

Projects
None yet
5 participants
@tiltec
Member

tiltec commented Feb 27, 2017

These are places where people can exchange food. Many foodsaving groups have this, sometimes as permanent places (public fridges), sometimes as pop-up events (e.g. Monday 10:00 regularly).

They should be per group, and publicly visible. A small to medium-sized backend task, and many people would like to have this feature.

Frontend: should show share points on the public map, enable group members to create and modify share points for their group.

Backend: design a share point model, serializers and endpoints
Should include the following features:

  • name, description, location
  • group it belongs to
  • optional: times of pop-up events

This is very similar to stores, so we could think of ways to reuse existing code. Maybe generalize stores as location & description and pickup dates as events? But that's just a very first idea.

@tiltec tiltec added this to the Release 5 milestone Feb 27, 2017

@tiltec tiltec changed the title from Share points to Food Sharepoints Mar 7, 2017

@djahnie

This comment has been minimized.

Show comment
Hide comment
@djahnie

djahnie Jul 4, 2017

Member

This is very similar to stores, so we could think of ways to reuse existing code. Maybe generalize stores as location & description and pickup dates as events?

That sounds very reasonable to me and since I was just talking about this with Stefan from Taiwan I'll add my two cents:

  • The marker on the map should look differently from the store's marker, e.g. different color.
  • Pick-up dates are either not needed for the FSP or can be reinterpreted as cleaning times.
  • In the group view the FSPs should be displayed above or underneath the stores in the list on the right. They could be seperated by a horizontal line and introduced by a headline saying 'Stores:' and 'Food-share points:' respectively.

When there's communication possibilities:

  • In the detail view of an FSP the users should be able to post comments for when they brought food there.
  • In the group view a new tab called 'Food-share points' could be introduced, that leads to an overview page where the newest messages from all FSPs, as well as upcoming and still open cleaning shifts are displayed.
Member

djahnie commented Jul 4, 2017

This is very similar to stores, so we could think of ways to reuse existing code. Maybe generalize stores as location & description and pickup dates as events?

That sounds very reasonable to me and since I was just talking about this with Stefan from Taiwan I'll add my two cents:

  • The marker on the map should look differently from the store's marker, e.g. different color.
  • Pick-up dates are either not needed for the FSP or can be reinterpreted as cleaning times.
  • In the group view the FSPs should be displayed above or underneath the stores in the list on the right. They could be seperated by a horizontal line and introduced by a headline saying 'Stores:' and 'Food-share points:' respectively.

When there's communication possibilities:

  • In the detail view of an FSP the users should be able to post comments for when they brought food there.
  • In the group view a new tab called 'Food-share points' could be introduced, that leads to an overview page where the newest messages from all FSPs, as well as upcoming and still open cleaning shifts are displayed.

@djahnie djahnie changed the title from Food Sharepoints to Food -share points Jul 4, 2017

@djahnie djahnie changed the title from Food -share points to Food-share points Jul 4, 2017

@tiltec tiltec changed the title from Food-share points to Public locations for food distribution (Food-share points) Jan 24, 2018

@tiltec tiltec changed the title from Public locations for food distribution (Food-share points) to Public locations for food distribution (Food-share points, open fridges) May 21, 2018

@tiltec

This comment has been minimized.

Show comment
Hide comment
@tiltec

tiltec May 21, 2018

Member

From foodsharing Poland

it would be very helpful to have an 'open fridge' pins on the map (i'm not sure about the english name, i'm talking about those places where we leave food for others to take). for now we will probably use blue pins, originally for 'negotiating' stores

Member

tiltec commented May 21, 2018

From foodsharing Poland

it would be very helpful to have an 'open fridge' pins on the map (i'm not sure about the english name, i'm talking about those places where we leave food for others to take). for now we will probably use blue pins, originally for 'negotiating' stores

@tiltec

This comment has been minimized.

Show comment
Hide comment
@tiltec

tiltec Jul 16, 2018

Member

This seems to become more relevant. There have been related ideas such as scheduling hangout locations on karrot (ask Bruno) and marking locations to drop off food (Essen für Alle?).

Member

tiltec commented Jul 16, 2018

This seems to become more relevant. There have been related ideas such as scheduling hangout locations on karrot (ask Bruno) and marking locations to drop off food (Essen für Alle?).

@tiltec

This comment has been minimized.

Show comment
Hide comment
@tiltec

tiltec Jul 27, 2018

Member

It's unclear whether we should generalize stores and pickups or add new data structures to handle locations and events.

Member

tiltec commented Jul 27, 2018

It's unclear whether we should generalize stores and pickups or add new data structures to handle locations and events.

@tiltec

This comment has been minimized.

Show comment
Hide comment
@tiltec

tiltec Jul 27, 2018

Member

Would be useful to collect the requirements from groups:

  • what should be publicly displayed and what should be internal?
  • do we need event management or is a simple description enough?
  • should there be a conversation feature attached (e.g. public wall)?

It would be good to write a post on the community forum about this and gather feedback.

Member

tiltec commented Jul 27, 2018

Would be useful to collect the requirements from groups:

  • what should be publicly displayed and what should be internal?
  • do we need event management or is a simple description enough?
  • should there be a conversation feature attached (e.g. public wall)?

It would be good to write a post on the community forum about this and gather feedback.

@djahnie

This comment has been minimized.

Show comment
Hide comment
@djahnie

djahnie Jul 28, 2018

Member

I wrote a post. You find it here.

Member

djahnie commented Jul 28, 2018

I wrote a post. You find it here.

@nicksellen

This comment has been minimized.

Show comment
Hide comment
@nicksellen

nicksellen Sep 14, 2018

Member

So, I split it into two considerations:

  1. implementation (whether to make stores/pickups generic)
  2. user interface

I will share a few thoughts regarding 1 here, I think 2 can be discussed a bit more on your post, but can sort of happen in parallel.

I have the feeling that making stores/pickups generic is the way to go. Loosely store = location (but maybe the word "stores" is actually general enough anyway), and pickup = event (or "activity", or something else).

The post mentioned a few types of patterns we should consider, I would consider those as 3 different concepts:

  1. places you can drop-off and pickup-up food (e.g. public fridges/shelves)
  2. places you can drop-off food (e.g. charities)
  3. events where the location is not dedicated for that purpose (e.g. distribution events)

For 1 and 2 the "store" is obviously the location, the "events" part of it is about related tasks (cleaning up, meetings, etc.). For 3 the event part of it is the main thing, and the location kind of secondary, so I would consider either:
3a. make "events" not need to be connected to a seperate "store/location" entry, but just have location information directly on them.
3b. have additional "locations/stores" that would not be really shown on the map by default (as you can only do anything there if there is an event) <--- I would probably favour that one

So, "stores/locations" might change in the following way:

  • possibly change the name
  • have a "type" field, something like:
    • sharepoint
    • dropoff
    • shop
    • cafe/restaurant
    • (the last two we don't bother distinguishing, but maybe it's useful whilst we're adding types!)
    • venue (or "transient") - would not be shown on map by default

then, "pickups" might change in the following ways:

  • change the name to something more generic (event, activity, etc)
  • have a type field, with maybe:
    • pickup
    • dropoff
    • event (seems a bit general, maybe it's just "other")
  • ... maybe the types are limited depending on the store/location type, but maybe just leave it simple

Some things that would need changing/thinking about:

  • email notifications would have to either filter just pickups, or maybe send notifications about other types of events too
  • feedback is currently connected to only pickups, doesn't make sense for other event types (unless people want to record how much is dropped off too...)
  • for pickups, we consider them not really ok unless they are full, but other event types are different
  • would like to avoid endless if/switch statements from having different types

As I said before, in this I'm not considering anything about how they would be represented in the UI (which seems to range from completely seperate sections/names, or kind of combine them a bit more and have filters).

Would welcome more thoughts on this :)

Member

nicksellen commented Sep 14, 2018

So, I split it into two considerations:

  1. implementation (whether to make stores/pickups generic)
  2. user interface

I will share a few thoughts regarding 1 here, I think 2 can be discussed a bit more on your post, but can sort of happen in parallel.

I have the feeling that making stores/pickups generic is the way to go. Loosely store = location (but maybe the word "stores" is actually general enough anyway), and pickup = event (or "activity", or something else).

The post mentioned a few types of patterns we should consider, I would consider those as 3 different concepts:

  1. places you can drop-off and pickup-up food (e.g. public fridges/shelves)
  2. places you can drop-off food (e.g. charities)
  3. events where the location is not dedicated for that purpose (e.g. distribution events)

For 1 and 2 the "store" is obviously the location, the "events" part of it is about related tasks (cleaning up, meetings, etc.). For 3 the event part of it is the main thing, and the location kind of secondary, so I would consider either:
3a. make "events" not need to be connected to a seperate "store/location" entry, but just have location information directly on them.
3b. have additional "locations/stores" that would not be really shown on the map by default (as you can only do anything there if there is an event) <--- I would probably favour that one

So, "stores/locations" might change in the following way:

  • possibly change the name
  • have a "type" field, something like:
    • sharepoint
    • dropoff
    • shop
    • cafe/restaurant
    • (the last two we don't bother distinguishing, but maybe it's useful whilst we're adding types!)
    • venue (or "transient") - would not be shown on map by default

then, "pickups" might change in the following ways:

  • change the name to something more generic (event, activity, etc)
  • have a type field, with maybe:
    • pickup
    • dropoff
    • event (seems a bit general, maybe it's just "other")
  • ... maybe the types are limited depending on the store/location type, but maybe just leave it simple

Some things that would need changing/thinking about:

  • email notifications would have to either filter just pickups, or maybe send notifications about other types of events too
  • feedback is currently connected to only pickups, doesn't make sense for other event types (unless people want to record how much is dropped off too...)
  • for pickups, we consider them not really ok unless they are full, but other event types are different
  • would like to avoid endless if/switch statements from having different types

As I said before, in this I'm not considering anything about how they would be represented in the UI (which seems to range from completely seperate sections/names, or kind of combine them a bit more and have filters).

Would welcome more thoughts on this :)

@tiltec

This comment has been minimized.

Show comment
Hide comment
@tiltec

tiltec Sep 15, 2018

Member
Member

tiltec commented Sep 15, 2018

@nicksellen

This comment has been minimized.

Show comment
Hide comment
@nicksellen

nicksellen Sep 15, 2018

Member

I got quite put off the django model inheritance stuff before. That seems to complicate things quite a lot in an abstract way. Anyhow, I think the next step here would be playing around with the code a bit and see how various approaches feel.

My goal would be to avoid lots of if/else, possibly by abstracting behaviours into seperate classes that can handle different types - so instead of 5 methods each with if/elses for each type, have a handler for each type with 5 methods each. This is still sort of inheritance (as the handler classes would adhere to an interface), but avoiding some complexity by not coupling this with the database/model inheritance. But yeah, needs some research and play :)

Member

nicksellen commented Sep 15, 2018

I got quite put off the django model inheritance stuff before. That seems to complicate things quite a lot in an abstract way. Anyhow, I think the next step here would be playing around with the code a bit and see how various approaches feel.

My goal would be to avoid lots of if/else, possibly by abstracting behaviours into seperate classes that can handle different types - so instead of 5 methods each with if/elses for each type, have a handler for each type with 5 methods each. This is still sort of inheritance (as the handler classes would adhere to an interface), but avoiding some complexity by not coupling this with the database/model inheritance. But yeah, needs some research and play :)

@nicksellen

This comment has been minimized.

Show comment
Hide comment
@nicksellen

nicksellen Sep 15, 2018

Member

... on the other hand, totally separate models for each type of thing are the simplest thing conceptually. It might be that it depends more on the UI approach more than I thought too, whether the different types are more or less seperate things.

(I also have in mind (more with dreaming hat on) that it nudges it closer to being more suitable as multisharing/general type of platform if it's possible to add types relatively easy)

Member

nicksellen commented Sep 15, 2018

... on the other hand, totally separate models for each type of thing are the simplest thing conceptually. It might be that it depends more on the UI approach more than I thought too, whether the different types are more or less seperate things.

(I also have in mind (more with dreaming hat on) that it nudges it closer to being more suitable as multisharing/general type of platform if it's possible to add types relatively easy)

@taistadam

This comment has been minimized.

Show comment
Hide comment
@taistadam

taistadam Sep 15, 2018

spwireframe_activities
Some UI ideas.

Open questions:

  • are there events for drop-offs?
  • how to prioritise pick-ups from events and distributions?
  • color scheme to differentiate the activities instead of space-taking title?
  • a better idea for a word rather than activities? "happenings"? "stuff going on you might want to join"?

taistadam commented Sep 15, 2018

spwireframe_activities
Some UI ideas.

Open questions:

  • are there events for drop-offs?
  • how to prioritise pick-ups from events and distributions?
  • color scheme to differentiate the activities instead of space-taking title?
  • a better idea for a word rather than activities? "happenings"? "stuff going on you might want to join"?
@brnsolikyl

This comment has been minimized.

Show comment
Hide comment
@brnsolikyl

brnsolikyl Sep 24, 2018

Although the discussion about the feature itself and the reflections about implementation that Nick brought up here are obviously connected, I think we should open a new issue about making generalizations and possibly refactoring the backend. This can be especially interesting when trying out Karrot for new purposes, like organizing Bike Kitchens, as we mentioned on another post. The broader classes of "location" (or "places", one might call it) and "event/activity" makes sense for this Bike Kitchen use case as well, whereas types would be something like "working shifts", "meetings" and "pickups", and that's a matter to be defined in the UI.

Being able to define locations and events as public or internal are applicable to different use cases, I believe. I can say that for Solikyl, having food-share points as public would be quite useful.

brnsolikyl commented Sep 24, 2018

Although the discussion about the feature itself and the reflections about implementation that Nick brought up here are obviously connected, I think we should open a new issue about making generalizations and possibly refactoring the backend. This can be especially interesting when trying out Karrot for new purposes, like organizing Bike Kitchens, as we mentioned on another post. The broader classes of "location" (or "places", one might call it) and "event/activity" makes sense for this Bike Kitchen use case as well, whereas types would be something like "working shifts", "meetings" and "pickups", and that's a matter to be defined in the UI.

Being able to define locations and events as public or internal are applicable to different use cases, I believe. I can say that for Solikyl, having food-share points as public would be quite useful.

@nicksellen

This comment has been minimized.

Show comment
Hide comment
@nicksellen

nicksellen Sep 27, 2018

Member

The broader classes of "location" (or "places", one might call it) and "event/activity" makes sense for this Bike Kitchen use case as well, whereas types would be something like "working shifts", "meetings" and "pickups", and that's a matter to be defined in the UI.

For me the question of where to define the types is more open than that, a few options/considerations:

  1. could be defined in an instance configuration file on the server (so a whole instance has a certain set of types)
  2. could be defined by a status field in the code/db (as we currently do for things that have multiple types)- 3. could be defined in the UI per group by anyone that has editing rights

My default would have been to go with option 2. On the basis that:

  • this is already our approach for managing different things that have the same representation in the code/db (e.g. conversation types, history types)
  • it's flexible enough to add more, but inflexible enough that we have to think about the specific needs of each type

My concern with exposing the generic-ness in the UI (option 3) would be that different types might have different needs in terms of notifications, emails, UI, etc. For example it's much more important to notify people that a pickup has no collectors than a public event has no attendees.

It could be possible to implement these things as options when creating types, but then it also starts to get very complicated for groups that need something simple without configuring lots of options. It also would make stats reporting less meaningful if different groups did not have the same types (I find it much more interesting/useful to know if pickups are happening than if general meetings are).

The other aspect is branding/clarity kind of perspective - having a tool/site focused on saving food is much much clearer than a general tool that can sort of do many things. This doesn't have to be singular at the software level, but maybe at the deployment level, e.g. karrot.world to stay food saving focused, but maybe bike.kitchen is all setup and branded for bike saving. It might be each use-case/purpose have very different community needs too.

So, in general I am all for generalness and flexibility, until it comes at the cost of clarity and purpose.

Member

nicksellen commented Sep 27, 2018

The broader classes of "location" (or "places", one might call it) and "event/activity" makes sense for this Bike Kitchen use case as well, whereas types would be something like "working shifts", "meetings" and "pickups", and that's a matter to be defined in the UI.

For me the question of where to define the types is more open than that, a few options/considerations:

  1. could be defined in an instance configuration file on the server (so a whole instance has a certain set of types)
  2. could be defined by a status field in the code/db (as we currently do for things that have multiple types)- 3. could be defined in the UI per group by anyone that has editing rights

My default would have been to go with option 2. On the basis that:

  • this is already our approach for managing different things that have the same representation in the code/db (e.g. conversation types, history types)
  • it's flexible enough to add more, but inflexible enough that we have to think about the specific needs of each type

My concern with exposing the generic-ness in the UI (option 3) would be that different types might have different needs in terms of notifications, emails, UI, etc. For example it's much more important to notify people that a pickup has no collectors than a public event has no attendees.

It could be possible to implement these things as options when creating types, but then it also starts to get very complicated for groups that need something simple without configuring lots of options. It also would make stats reporting less meaningful if different groups did not have the same types (I find it much more interesting/useful to know if pickups are happening than if general meetings are).

The other aspect is branding/clarity kind of perspective - having a tool/site focused on saving food is much much clearer than a general tool that can sort of do many things. This doesn't have to be singular at the software level, but maybe at the deployment level, e.g. karrot.world to stay food saving focused, but maybe bike.kitchen is all setup and branded for bike saving. It might be each use-case/purpose have very different community needs too.

So, in general I am all for generalness and flexibility, until it comes at the cost of clarity and purpose.

@nicksellen

This comment has been minimized.

Show comment
Hide comment
@nicksellen

nicksellen Sep 27, 2018

Member

We also have #359 which maybe can be reopened :)

Member

nicksellen commented Sep 27, 2018

We also have #359 which maybe can be reopened :)

@brnsolikyl

This comment has been minimized.

Show comment
Hide comment
@brnsolikyl

brnsolikyl Sep 27, 2018

Good points, Nick. Let me see if I understand. The status field on the code that you refer to on option 2, is that the status of the store as "Cooperating", "Negotiating" or "Inactive"? If yes, then I see what you mean and I believe that's a good approach. It's kind of how I played with the Karrot when we first put it up as a test-piece. Our plan is to make our own deployment, branded for the bike kitchens (and then obviously we'd like you developers to get involved ;), but we discuss that anytime soon). The question of having a generic tool for team self-management, not branded for specific purposes, can still be interesting and relevant for the future so it'd be good to keep the discussion open elsewhere.

brnsolikyl commented Sep 27, 2018

Good points, Nick. Let me see if I understand. The status field on the code that you refer to on option 2, is that the status of the store as "Cooperating", "Negotiating" or "Inactive"? If yes, then I see what you mean and I believe that's a good approach. It's kind of how I played with the Karrot when we first put it up as a test-piece. Our plan is to make our own deployment, branded for the bike kitchens (and then obviously we'd like you developers to get involved ;), but we discuss that anytime soon). The question of having a generic tool for team self-management, not branded for specific purposes, can still be interesting and relevant for the future so it'd be good to keep the discussion open elsewhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment