Better implementation events informations fields

[thaliawww-service]

In GitLab by @se-bastiaan on Jan 28, 2019, 12:20

One-sentence description

Better implementation events informations fields

Motivation

The fields are currently (mis?)used in ways that we have not foreseen. It seems that committees have found different use cases for the fields Frankensteining them in ways they were not meant to be used.

For example: list selection, using plain HTML to describe a field. Something that doesn't work in the app because it renders the description as placeholder.

Desired functionality

I'm not sure how we should change this functionality, probably a way to create dropdown selectboxes for the kind of questions in the example. That's why we should look into this, maybe with the people that use them the most (educacie?)

[thaliawww-service]

In GitLab by @se-bastiaan on Jan 28, 2019, 12:35

Here is another example of unintended (but working?) usage:

[thaliawww-service]

In GitLab by @se-bastiaan on Mar 17, 2019, 21:26

We sent this email (only in Dutch):

Beste leden van de EVC, Educacie en Weekendcommissie,

De afgelopen maanden is het ons als Technicie opgevallen dat ieder van jullie zo z’n eigen manieren heeft om evenementen op de website te zetten. En dan vooral met verschillende soorten informatievelden die je leden kunt laten invullen. Niet altijd gaat dit even geweldig en wij zouden deze functionaliteit daarom graag willen verbeteren.

Om iets meer inzicht te krijgen in wat we moeten veranderen leek het ons een goed plan om met jullie te overleggen. Een vergadering met z’n allen lijkt ons heel gezellig maar niet noodzakelijk. Daarom zouden we jullie willen vragen om binnen jullie commissies te overleggen wat je wel/niet fijn vindt aan de huidige implementatie en dit aan ons door te geven. Geef een aantal positieve en negatieve opmerkingen, maar als je precies weet hoe het er voor jullie uit moet zien is die visie ook welkom. Denk aan het type (nu: integer, string, checkbox) veld en de informatie die je hierbij kunt tonen.

Met jullie input hopen we dat we hier in de toekomst iets beters van kunnen maken wat past in waar het voor wordt gebruikt.

Namens de Technicie,
Sébastiaan

[thaliawww-service]

In GitLab by @se-bastiaan on Mar 17, 2019, 21:27

Responses so far:

Educacie - Ward

Over het algemeen lijkt me het enige laaghangende fruit mbt inputvelden de mogelijkheid om een dropdown menu (of evt radiobuttons) te gebruiken als je een gebruike wilt laten kiezen tussen een aantal opties. Momenteel moet je bij daar namelijk de gebruiker bijvoorbeeld zelf een integer laten invullen.
Verder vind ik het allemaal wel goed werken.
Eventuele andere wijzigingen zouden over de administrator-interface gaan, maar het lijkt me niet zozeer belangrijk daar UI-verbeteringen door te voeren: weinig mensen zien het en de functionaliteit is er.

Weekendcie - Roland

Ik heb het er vandaag met de commissie over gehad en bij ons kwamen er 2 dingen naar boven: het zou fijn zijn als we radio buttons kunnen gebruiken in plaats van tekstvelden voor vragen met meerdere opties en dat sommige tekst niet zichtbaar is in de app. Hopelijk heb je hier wat aan.

[thaliawww-service]

In GitLab by @se-bastiaan on Apr 3, 2019, 11:21

EVC - Jesse

We gaan er eigenlijk vanuit dat jullie goed extra invoervelden kunnen maken. Wat we nu vooral missen is:

• Velden kunnen niet ingevuld worden bij handmatige aanmeldingen
• Velden zijn niet zichtbaar in de backend op je telefoon
• Het is nu onduidelijk welke invoervelden required zijn
• Een soort preview zou chill zijn, dat je dus kan zien hoe het er uiteindelijk uit gaat zien als je het aanmaakt.

[JobDoesburg]

Maybe it is nice to store this information in a JSONfield of an event registration?
An event gets an optional JSONfield that contains the questions and what kind of output it expects, and the event registrations itself then contain the responses. And we make a validator that makes sure that the user responses are conform the event requirements

So for the event, people can fill in something like this:

{
  "information_fields": [
    {
      "type": "boolean",
      "optional": false,
      "question": "This will appear as a checkbox and is required",
      "help": "This text explains the question for people that are stupid"
    },
    {
      "type": "dropdown",
      "possibilities": [
        "a",
        "b",
        "c"
      ],
      "optional": true,
      "question": "This will appear as a dropdown and is optional",
      "help": "This text explains the question for people that are stupid"
    }
  ]
}

And for the registrations, we store something like this:

{
  "information_fields": [
    {
      "question": "This will appear as a checkbox and is required",
      "response": true
    },
    {
      "question": "This will appear as a dropdown and is optional",
      "response": "a"
    }
  ]
}

That makes the model-part of the problem a lot easier because we can just remove the whole information fields model and just store it as additional fields.

The event details admin and event registration view only need to be updated to be able to parse these JSON fields but that should be feasible I think

[se-bastiaan]

Don't forget that the API should also support this. Which makes saving the fields as JSON probably the best solution anyways.

I'm not sure how to make a custom admin form out of this though, that is what the current model structure is perfect for. Or do you want even organisers to input the JSON directly?

[JobDoesburg]

Don't forget that the API should also support this. Which makes saving the fields as JSON probably the best solution anyways.

I'm not sure how to make a custom admin form out of this though, that is what the current model structure is perfect for. Or do you want even organisers to input the JSON directly?

I think the organisers should be able to input JSON directly yeah (and if they complain we can always let them open another issue (and close it as feature creep))

[se-bastiaan]

Okay I don't think that is a bad idea actually. It will make it WAY WAY WAY easier for us to support and maintain this. JSON is terribly easy to write.

It would definitely require a validator even for the organiser-side input though. And some documentation somewhere.

[se-bastiaan]

I would like to note for future reference that a JSON array is an ordered collection and that no id or order key would be required. https://stackoverflow.com/questions/7214293/is-the-order-of-elements-in-a-json-list-preserved

Probably wise to put up a warning that editing the field will change the registration responses though. Especially since you need to match answers with questions and the order is the best way to do so.

[JobDoesburg]

Okay I don't think that is a bad idea actually. It will make it WAY WAY WAY easier for us to support and maintain this. JSON is terribly easy to write.

The event information feature even isn't used that often and when it is used, it is often used to make some sort of schedule afterwards. So it shouldn't be too much of a problem if the organizer would need to think about it for a bit (and the current UI also isn't that great either). If we put something in the docs and add a link to the docs in the help-text we should be fine.

[pingiun]

If we implement the json box, people will probably complain that they liked the old system better. But maybe we could have both systems?

[pingiun]

I think we can use jsonschema for the json validation

[JobDoesburg]

I think people will not complain too much. The current system doesn't work ideal either.

[JobDoesburg]

Another idea: pull the giphouse website questionnaires app and add a foreign key from event registrations to questionnaire submissions.