carlobeltrame
commented
1 year ago User requirements
Almost all needed pieces of information are needed only once per camp, e.g. we don't need a different Coach name on each page of a multi-page picasso, or in each period. (A notable exception is the location of the camp, but that may vary even within a period; in eCamp v2 this wasn't supported either, and we have previously decided to stay with one location per camp and migrate later.) At the same time, I'd like to keep everything to do with J+S optional (e.g. for school camps, music camps or non-J+S camps there might not be a Coach or LKB). Ideally, all the necessary (and possibly optional) fields could be specified via the camp template. PDF exports should be easily repeatable after updates to the camp.
Options for storing the information
Option 1: Not storing anything
Information needs to be entered every time a PDF is printed, in one or more free text fields on the print configurator. Pros: Relatively easy to implement, few dependencies within the project. Cons: User has to enter the information every time a PDF is printed. Details may be inconsistent between PDFs because of human error. Is not a solution for printing the picasso directly from the picasso web view.
Option 2: Storing in generic fields such as "picasso_header_left" etc.
Either on the print configurator or in the camp admin, we could offer free text fields for e.g. 3 separate columns which will be printed onto the picasso. Pros: Flexible. Could be initialized via camp template. Cons: Very unstructured. The information realistically can't be re-used in other parts of the PDF.
Option 3: Storing in a JSON field on the camp
Somewhere, e.g. in the camp settings, there could be a UI for adding either arbitrary metadata fields to the camp. Pros: Flexible. Relevant fields could be initialized empty via camp template. Might go in the direction of the feature request "Gestaltungsmöglichkeiten für den Ausdruck des Grobprogramms" (via contact form). Cons: Unclear how eCamp should know where exactly to put which information on the PDF. If there are multiple "columns" of information like in eCamp v2, the JSON could also store the "column" where each piece of information should be rendered. Data is relatively unstructured, meaning there could be a lot of small variations in the naming of the fields, and it will be hard in the future to re-use the same information in other places / other parts of the PDF. We could work around the unstructured-ness with something like RDF, but that might be just another can of worms...
Option 4: Storing in separate, dedicated fields on the camp
Add additional fields for all the needed pieces of information. Pros: Easiest to handle the information for developers. Validations and migrations are easy. Re-using the information in the future is easy (e.g. if we decide to implement a printable material ordering form etc.). Moving some of the information to period-specific fields is easy (e.g. in case we decide to allow separate geographic locations for each period etc.) Cons: Not all fields are relevant for all types of camps and courses. Unclear how the camp template could influence the available or visible fields. Not very flexible in case a requirement of J+S or BSV or something else changes, or if someone needs a custom field for their camp. For many of the required pieces of information, we have posponed adding fields for Post-MVP, so this decision would need to be revised.
Option 5: Fetching the data from external services (namely, hitobito)
Much of the needed information is already entered on hitobito (MiData, CeviDB, jubla.db). It would be possible to fetch these data from hitobito. If the user has not set up a login via OAuth yet, they have to go through the consent screen while "connecting" the camp to hitobito. Pros: User only has to enter the information once. Long-term we could offer the option to create a new camp by "importing" from hitobito. Cons: So far there is no connection between camps on hitobito and eCamp v3, so connecting the camp would have to be implemented from scratch. MiData, CeviDB and jubla.db have slight differences in the fields, see table below. There might be some J+S camps which are not stored on any hitobito (e.g. J+S school camps, camps of other sports organizations, test camps in courses etc.), and they need a solution for printing as well. Could be confusing for the users, where this information gets taken from and how they could change it. The name of Coach/LKB could be accessible or inaccessible, depending on who exports the PDF (because we would use the hitobito API in the name of the user).
| Datum | MiData | CeviDB | jubla.db |
|---|---|---|---|
| Organisator (Name der Jugendorganisation) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
| Lagerart (Haus-, Zelt-, Unterwegslager, Sommer-, Herbstlager) | :x: | :x: | :x: |
| Lagerdaten (inkl. Jahr) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
| Ort und Name des Lagerhauses bzw. Lagerplatzes | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
| Name(n) der Lagerleitung | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
| Name des J+S-Coachs | :heavy_check_mark: | :sweat:[^1] | :sweat:[^1] |
| Lagereinkleidung | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
| Kursnummer | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
| Kursbezeichnung (bei J+S Kurs: J+S Bezeichnung) | :confused:[^2] | :confused:[^2] | :confused:[^2] |
| Kursort | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
| bürgerlicher Name von HKL | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
| bürgerlicher Name von LKB | :heavy_check_mark: | :sweat:[^1] | :sweat:[^1] |
| J+S-Kurs yes/no? (for decision whether J+S logo is required) | :confused:[^2] | :confused:[^2] | :confused:[^2] |
[^1]: Not stored directly on the camp / course, but could probably be determined via some extra work (fetching the roles in the camp's organizer group). Then again, if there are multiple matching roles, we would need a way for the user to select the correct one. [^2]: The course kind could be fetched via the hitobito API. But all of the hitobito instances use different names for the J+S courses, and none of them use the "official" J+S Bezeichnung. In fact, these course kinds are dynamically changeable on each hitobito instance, so we couldn't even hardcode a mapping in eCamp.
Proposal
After listing all these options, I lean towards option 4 (which was not my favourite before researching all this), with future possibility of filling many of the fields via option 5. From option 4, it is easy to migrate to any other option later if we see the need to do so. Also, to address the disadvantages of option 4, we would need especially good UI design, which allows to show/hide the fields easily depending on the user's needs.
Where to put the information on the Picasso
Long-term, I envision multiple picasso renderers (or even external PDF rendering services for very specific use-cases), and the user could choose which one suits them best. Maybe there could be a camp picasso, a course picasso, a compact picasso, an accessible picasso, a "safe to show to the participants" picasso, etc. Short-term however, in the closed beta, we have only youth organization users, and only camps (anyone planning a course is doing so at their own risk). I would propose for now to just add the J+S-required fields to the single picasso version. I propose this because the first deadlines for the first camps approach, and the Coaches need to be able to upload valid picassos to J+S.
I would say the precise position of each piece of information is left up to the implementer. But below, I have collected as many different picasso implementations as I could find, for inspiration.
PBS: [Template] Jubla: [Template], [course picasso from jublakurse.ch] Cevi: (found nothing) J+S: [LS/T Kids], [LS/T Teens], [LS/T Kids + Teens], [template for non-LS/T sports on mobilesport.ch], [BASPO course "picasso"] eCamp v2: Example camp picasso, example course picasso my-scout-camp.ch: Example camp picasso Manually created picassos: Sommertop 22
| Datum | J+S | mospo | PBS | Jubla | m-s-c.ch | eCamp2 | jublakurse | Top | BASPO |
|---|---|---|---|---|---|---|---|---|---|
| Organisator | H ml | :x: | H c | H ml | H l | H tl | :x: | tr | :x: |
| Lagerart | H br | title | :x: | H br | :x: | H tr | n.a. | n.a. | :x: |
| Lagerdaten | H bl | :x: | :x: | H bl | :x: | H ml | H l | F bc | title |
| Ort, Name Lagerort | H tr | :x: | H l | H tr | :x: | H mc | H l | F tc | first SE |
| Name(n) der Lagerleitung | H tl | :x: | H r | H tl | :x: | H mr | H c | F tc | bel. CAL |
| Name des J+S-Coachs | H tl | :x: | H r | H tl | :x: | :x: | H r | F bl | n.a. |
| Tag Datum | D t | :x: | D t | D t | D t | D t | D t | D t | D t |
| Tagesverantwortliche | D b | :x: | D b | D b | D b | D b | D b | D b | :x: |
| Titel jeder Aktivität | SE t | SE t | SE t | SE t | SE t | SE t | SE t | SE t | SE t |
| Verantwortliche Person jeder Aktivität | :x: | :x: | SE t, CAL tr | :x: | :x: | SE t | SE br | SE br | SE b |
| J+S-Aktivitäten als LS oder LA gekennzeichnet | SE t, CAL br | :x: | CAL br | SE t, CAL br | SE t, CAL t | SE t, bel. CAL | n.a. | n.a. | n.a. |
| An- und Rückreisezeit | SE | SE | SE | SE | SE | SE | SE | SE | SE |
| Lagereinkleidung | H mr, D m | :x: | H l | H mr, D m | :x: | H tc | :x: | :x: | n.a. |
| Daten | H bl | :x: | :x: | H bl | :x: | H ml | H l | F bc | title |
| Kursnummer | n.a. | n.a. | n.a. | n.a. | n.a. | H tr | :x: | F tl | title |
| Kursbezeichnung | n.a. | n.a. | n.a. | n.a. | n.a. | H tl | :x: | title | title |
| Kursort | H tr | :x: | H l | H tr | :x: | H mc | H l | F tc | first SE |
| bürgerlicher Name von HKL | H tl | :x: | H r | H tl | :x: | H mr | H c | F bl | bel. CAL |
| bürgerlicher Name von LKB | H tl | :x: | H r | H tl | :x: | H bl | H r | F bl | n.a. |
| J+S logo | tr | n.a. | n.a. | tr | n.a. | bl | tr | tr | tr |
Abbreviations: :x: - missing required data n.a. - not applicable H - page header F - page footer CAL - calendar (the graphical, mostly tabular time overview) D - day header SE - schedule entry (the graphical element denoting a single activity at a certain point in time) tl, br, mc etc. - top left, bottom right, mid-height center, etc. ab. - above bel. - below
Fun facts found in the making of this analysis:
- No single picasso implementation has been found yet which contains all the data for both camps and courses
- The Jubla template is just a copy of the J+S template, including all mistakes, with some Jubla-specific examples inserted.
- eCamp2 is the only one which does not write the leader and coach / LKB name next to each other
manuelmeister
J+S requires some things to be presented directly on the picasso which is submitted to J+S coaches and in the NDS. We should probably make sure these are always displayed on the picasso when printing, at least for now, as long as there is only one non-configurable way to print the picasso. For legal reasons I can't link to the brochure (Lagersport/Trekking Lager) where this defined, but I hope it is okay to list the requirements here. The brochure is available digitally to J+S leaders here.
J+S Camps
Bestandteile des Grobprogramms als Wochenraster
Users can theoretically add the missing information to the picasso e.g. as activities on a first camp day. But that is not a very elegant solution for a requirement which concerns most of the real camps on eCamp.
J+S Courses
Source: Anker chapter 4.1