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.
Hooray! Awesome! I’m happy to see progress in this topic!
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…
Points:
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.
I think it makes a lot of sense to add Task to a general purpose group 
. 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.
Ok, I implemented it like this now:
It’s not the most beautiful in the world but maybe/hopefully acceptable!
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!
@bruno activity types is just about ready to merge, but just before we do, maybe you want another look at the translation string changes? Me and @tiltec went through and changed some, putting the activity type name into the strings a bit more, you can see those changes here → Support activity types by nicksellen · Pull Request #2207 · yunity/karrot-frontend · GitHub
… and also changed wording on the dialog above to make it sound more positive!
Sooo much better! And the changing the title to show new possibilities was spot on.
I’ll do a quick review of the translation strings
The work on extra activity types hasn’t been deployed to production yet, but I already started on being able to edit the activity types. Maybe I should create another thread for it, but I’ll just put it here for now…
I made a little video of my work in progress, maybe this is a nice way to show people…? I don’t know if this video will work, in the preview it just shows a video camera picture, but nothing to press play on… let’s find out… (update: after a few iterations, I needed to convert to yuv420p pixel format, using ffmpeg option -pix_fmt yuv420p)
Or a screenshot version:
Some of the open questions, which me and @tiltec discussed a bit today in our co-working session are:
To implement the feedback idea only impacting future ones we probably have to add a feed to the activity table to store the value. If we end up wanting lots of different options like this, it might be beneficial to implemented a versioning scheme, where editing an activity type, actually creates a new database entry and transparently “archives” the previous one, so past activities are still able to refer to it, but new ones would use the new one. This would add a lot of implementation complexity so probably only worth considering if there is need from the user/group perspective.
Another aspect we discussed is about communicating edits to the users. For example, if you enable feedback, it would be nice to communicate to the users what that means for the context of the group. One way would be to have a text field when you are saving that you can write a brief description of the change. And in the more general way this could be an enhanced history feature, that you can see more clearly the changes to things over time, who changed it, and why (and maybe this dreamed-about feature of “revert change” too)… takes dreaming hat off again.
It might be nice to be able to customize the feedback label too, to use either the default one (“Was everything alright? Did everyone show up?”), or specify a custom one. It does touch the topic of translations, as custom text is not translatable. This seems ok for most groups as I guess they have a main language, but for more multi-lingual groups would be nice to have multiple languages. For now, they can just put multiple languages into one field though… (oh, maybe some more dreaming of some kind of dynamic integration with weblate to push custom messages into it…).
Ok, thats all for now!
