Given the task ofgeneralizing pickups for other kinds of events and even for use cases different than foodsaving (like the Bike Kitchen project), I was wondering how one would go about sorting them out. A practical example is that we usually put up meetings and hangouts as pickups, but they might get a bit lost on the list among all of the other pickups. In the case of Bike Kitchens, they use their “pickups” mostly as volunteer shifts to keep the workshop open.
Putting tags to events/pickups might be a solution that is flexible enough for the particular groups and other use cases.
A bit about names: to me, the word “tag” is usually associated with a n-to-n relationship (e.g. each pickup can have 0 or more tags), in contrast to a “category” (each pickup belongs to exactly one category). I think the name “category” or “type” would fit the concept better.
Nice! I was thinking of tag as something more flexible set by the user-admins instead of a category pre-defined by the system. But I’m thinking in terms of forum, I guess… If it’s not a n-to-n relationship we can call it category, but I think we should also consider it working as a tag too, to keep the flexibility. (I’m not sure about that though) For example, we have meetings/hangouts. Maybe a pickup requires a car, so the tags pickup and car together could be useful.
The downside maybe is that too many unnecessary tags would be created?
There are some implications for how the software should work given the different types - e.g. a meeting should not ask you for feedback on how many kg you saved. Also, the translations become tricky - if the “event/task” types are only user defined then they will only work in that one language.
For this reason I think the software needs predefined types to be allow the right kind of interaction with them. Another option would be to allow it to be super flexible so that user groups can define custom types with custom behaviour (like whether there should be a feedback, and with what fields, etc), but this comes at a high implementation cost.
Yes, tags would be defined in the group’s language of communication and I think could be excluded from translation. The downside is that an English-speaking person at a Swedish group, for example, would need to learn that upphämtningar means pickups.
whether to allow user-defined types for events or not
whether an event can have multiple types (“tags”) or just one (“category”)
I tend to choose no user-defined types and to just have one type per event for those reasons:
it’s translatable - although translation activity went down a lot lately
needs less settings UIs (those are hard to get right from a usability perspective)
we don’t need to think about every possible combination of types while implementing it
I would also tie the type of the event to the type of the place, e.g. you can have a “meeting place” that has meetings, a “food pickup place” that has pickups or a “share point” place that has cleanup shifts.
I think your proposal makes sense and would be the best choice to Karrot with the purpose it has now, for foodsaving groups.
Having in mind another use case, the Bike Kitchen project, and trying to figure out how to develop in the direction of a general purpose tool for different groups to organize horizontally, I’d still go with user-defined and (still not sure though) multiple types.
But then we get to another question of what kind of tool we’re focusing on and that is probably best to be discussed on another topic or on a call.
