Custom activity and place types

This has been a long discussed topics in various forms! :

The concrete things that have been done so far are:

  • implementation of “general” and “bikekitchen” themes that make karrot more suitable for other non-foodsaving purposes (limited to frontend changes in language and images - and English only)
  • rename stores to places and pickups to activities everywhere in the code and database (but “pickups” is still the word used everywhere)

I’m ready for the next step now - custom place/activity types :slight_smile:

Sorry it’s a big wall of text, and no nice explanatory pictures or user interface mockups… (would welcome collaboration for anyone who wants to do some of that too!).

When we renamed stores to places there was some resistance as not all groups need this stuff, and perhaps are concerned it will stop working so well for foodsaving groups, or confuse the users.

So I think it’s important to be clear that foodsaving groups are a really important use for karrot and will always be important, any of these changes should be so that:

  • foodsaving groups can organise the themselves better (as not all their tasks are “pickups” at “stores”)
  • non-foodsaving groups can use karrot too without being confused why there are these “pickup” things, and lots of food-related stuff
  • groups can actually be mixed-purpose, and configure their group to work in the way they want

There have been many discussions and it’s been quite unclear how to progress with this, but I have some clarity now and so this is a proposal for how to progress it…

  • each group would have their own activity and place types, existing foodsaving groups would automatically get a “pickup” type (and perhaps a “store”) type defined for them
  • new groups registering would be setup with a default set of types (at some point they could pick a “group template”, e.g. “foodsaving group”, which would set them up with a predefined set of types)
  • at any point groups can add/remove/modify their activity/place types

Initially I’m thinking that the types would have the following things:

  • a name (e.g. “pickups”, “meetings”, “stores”, “drop off points”)
  • a colour (to show in interface and for place map markers)
  • an icon (to show in interface and for place map markers)
  • for activities:
    • whether to collect feedback
    • whether to collect weight for the feedback

And later on some other ideas:

  • custom fields
  • custom fields for the feedback
  • enable/disable some of the standard fields (e.g. whether a location is required)
  • custom translations for the type name (so if a group has a special word for a “pickup” they can use that, but also translate it into other languages if their group is multi-lingual)
  • some control over the notifications that are relevant for that type
  • custom place status options (i.e. don’t have to have “co-operating” as the active status)
  • whether an activity needs to have slots at all (maybe some are just more like public events)
  • whether an activity needs a place (see Decouple pickup/event and store/place #1128 )

What does this solve?

It’s quite important to make sure whatever we are making, it’s going to solve something real! So I’m thinking that after doing this, the following things should get much easier:

  • organising meetings
  • adding sharing locations (fair share points, public fridges, etc)
  • using places as “virtual” spaces for organising (e.g. for discussions)
  • co-ordinating a bunch of more specific tasks for things like foodsharing brunches, or festivals (see Generalization of store pickups for other tasks #359 ) - here maybe a “foodsharing brunch” type for the actual brunch event, then a more generic “task” type for related activities (opening up, cleaning, etc…)
  • … more things?

Implementation details

I’ll just mention a few details here, but not go into great depth:

  • new db models ActivityType and PlaceType with required typus fields on activities/series/places
  • initial fields for ActivityType:
    • name
    • colour
    • icon
    • feedback (boolean)
    • feedback_has_weight (boolean)
  • db migration to create “pickup”, and “activity” (generic) type, and set existing activities to be pickups or activities depending on theme
  • for custom fields I am thinking extra db model for each field definition, e.g. ActivityField, which holds info that is used to dynamically create a DRF Serializer, that is used to manage data in a JSONField on the activity/series/place. This could then be just simple types (e.g. textfield), but also more complex types (e.g. a choice field with options), or even complex nested types (e.g. an “opening times” field?)… (I can imagine people then want types like “user”, or “place” or “image” fields, which get even more complex, or messy :confused: )
  • possibly useful to populate colour/icon fields on the activity/series/place itself too, and allow them to have an override setting for an individual activity/series/place…

I’ll stop now as this has got a bit long… would be very interested in thoughts feedback. Ping @tiltec, @djahnie, @bruno, @karolina, @danveg, @Disa, @mzpawlowski, @Teddy, @ConexionUtopia - everyone else welcome to feedback too :slight_smile:

3 Likes

Here’s my contribution… A mockup of how it could look like on the sidenav menu and on the activities page, just to get the visual imagination going. We could also do other mockups, like the page to select and create types of activities and places.

1 Like

Thanks for creating this detailed proposal, @nicksellen, and for the mockup, @bruno! Thinking of food saving groups, I imagine that this will make it easier to include sharing locations and event planning.

2 Likes

Damn, I even forgot the sharing locations on my mockup! :slight_smile: At least in my group we would definitely have them.

Some progress! Still quite a lot to do, but these types are defined in my local database, and displayed by the frontend.

The idea would still be to try and get this ready for deployment before allowing groups to create their own custom types, but when they can create them it will still include the ability to edit the existing types with no limitations.

2 Likes

Hooray! Awesome! I’m happy to see progress in this topic!

1 Like

Btw, I forgot to mention that one activity type, “distribution”, is recurring in my group and some others that I’ve seen, if 4 default types are a good start. Otherwise, if we want to keep 3 types only for foodsaving groups, I’d guess that Tasks can be put aside in favor of Distributions.

I’d quite like to include the most minimal number that might make sense to all groups, and anything less common can be created by them (once I’ve worked on that functionality of course). On the other hand, once the functionality is progressed they’d also be able to remove types that don’t seem relevant.

I wonder if distribution events are that common though? Maybe just a generic “Event” type is more useful?

On our weekly meeting we decided to make a poll to ask users what types of activities they’d like by default in their groups!

Let us know what you prefer here: Which activity types should we enable for new and existing groups?

Taking the input from the poll, I have this update…

activitytypes

Points:

  • I added “Activity” for totally generic activities, mostly actually thinking about something to set existing “Pickup” activities as for non-foodsaving groups…
  • input on icons/colours? (font awesome icon list and maybe these material icons too, there is a nice colour palette we can use, I suggest we only use dark colours)
  • is this a final list before deploying to dev?
  • I didn’t quite figure out
    a) which types should be added for general/bikekitchen groups
    b) which type to set for existing activities for general/bikekitchen groups
  • in general I don’t want to implement a feature that let’s people change the type of an activity (as it makes the programming a lot harder to think about, feedback, and lots of stuff…), but initially it seems like it could be useful, hmmm.

You can try it out now at https://add-custom-activity-types.dev.karrot.world (uses same credentials as https://dev.karrot.world)!

For foodsaving groups I made it create: Meeting, Pickup, Distribution, Event (as per the survey) (and set existing activities to “Pickup” type)
For other groups: Meeting, Event, Activity (and set existing activities to “Activity” type)

Still scope for setting the icons/colours (actually I notice I used a different one that the screenshot for distribution… I prefer the screenshot one actually fixed).

Two outstanding questions me and @tiltec have been pondering over are:

how to handle lots of pickup -> activity changes in the text

once this change is merged, there will be a bunch of translation work to do, right now I mostly did “dumb” conversations replacing the word “pickup” with “activity”, but we have the opportunity to make the texts more intuitive/helpful/clearer, etc… given they will all need to be re-translated anyway… you can see a code level diff of the texts over here (the old on the left, in red, the new on the right, in green). I guess we should also leave some time before deploying to give time for the translations to get updated…

how to help the users understand "what happened to the pickups page?"

I think this is most clear in the case of the main navigation menu (see below), I tried an option to have a little “badge” showing that something was updated, with a hover tooltip to explain that it used to be called “Pickups”, but maybe not sufficient? the hover tooltip probably isn’t very useful on mobile… would welcome other ideas! There may also be other places that are confusing?

This is the issue on github, but here is probably best place to comment, I’m easy though!

I think a question mark instead of updated and a dialog when clicking on it with a simple explanation and maybe a link would work fine. What’s this is also good, easier to click on than a question mark, but a question mark feels friendlier and more inviting to me personally to click on, for whatever strange reason.

1 Like

I think it makes a lot of sense to add Task to a general purpose group :slight_smile: . I think it’s something that a lot of groups could use as a to do-list. I can see this being used on the Bike Kitchen group for the task of buying tools or some other bike parts. And this would probably be a type that would not necessarily require a specific time and place, thinking now about future development…

Sounds reasonable, would that be instead of the Activity type? And also to set all existing activities as an Activity?

I was thinking of Task as a fourth type, and set existing activities as an Activity, since Activity is the most general type I can think of.

1 Like

Ok, I implemented it like this now:

theseusedtobecalledpickups

It’s not the most beautiful in the world but maybe/hopefully acceptable!

1 Like

Not a work of art for sure, but very functional!

Where does the “Read More” lead to? I think a nice little informative text would be something like “Activities named pickups are still available in foodsaving groups. We just added other types of activities, like Meetings, Events and Distributions”

Ah yeah, the idea was to write a community forum post about it. Although that has the downside it’ll only be in English. So maybe a short text on the site similar to what you said in addition to what is already there?

Yep, sounds good to me!