Forms: Styling


Functionality and Styling for Webkit Form elements


Github repos: key ones are the one for

Other useful repositories: add here (e.g the illustrations repo used by @owen : you had a place where you pick up most of the illustrations I think? Could you add it here please? )*


Form-to-display blocks














Slideshow block


  1. The Layout:
    • Question Header on one side
    • On other side: question bread text and response/ text entry field
    • Buttons: Back and forward on bottom
    • Indicator of where you are in the process (like a slideshow)
  2. The ability to set up multilingual form



Our goal

We want to be able to set up and edit new forms using pre-styled standard elements from the webkit:

  1. Ability to add/combine different standard webkit form elements into a form:
  2. The form is editable by modifying code posted in a discourse topic.
  3. Login via SSO: If the person filling in the form is already signed in as an edgeryders member - they just complete the form fields and when they submit, their contents are posted on the platform.
  • If the person filling in the form does not have an edgeryders account, a new one is created for them automatically. Once they have confirmed their accounts the content is posted on the platform by their newly created user account.

We want to be able to

What we want to transfer/ include in the webkit:

  • fill in any form as a signed in Edgeryders member and have it automatically be attributed to your profile
  • determine which fields are public and which ones can only be seen on Edgeryders
  • include multiple choice options (checkboxes)
  • associate a form with a category, topic and or tag
    • Event Registration: you can add url/topic id of the event topic on edgeryders.eu)
    • Topic Response: you can add url/ topic of the topic id, and entry into the form can be posted as comment on the topic on your behalf
  • We also want to keep this Information Architecture for those webkit elements/flow between them:
    • Display of user profiles that have filled in the form
    • Intermediate Funnel for (choice between filling in form as signed in user vs as new)
  • Changes to Styling:
    • Adapt fonts, colours, Link and button design, to those of the campaigns site.

We want to make it easy to

  • When we create a site where we add the webkit form block for event registration, at the user end they get a checkbox list with all the events on the platform, so that they can be made aware of what else is happening, and ideally, register to multiple events at the same time .

  • Create a form that is where people respond to an invitation or call for action that has been published as a topic (for example: events are one kind of topic that are just tagged “event” and have additional tags for date, times etc.)

  • See where the responses (filled out and submitted forms) to a specific topic end up (ideally as topics within a dedicated subcategory so that we can easily reach everyone who has submitted a form e.G in order to get tickets for an event)

  • Be able to find ones own submitted forms so as to be able to modify the contents.

  • The admins, organisers and people who have submitted forms can then review the submissions and where needed verify the information submitted is accurate - that links work etc.

Translation of what this means/requires into features requested:

  1. Markup in a Discourse topic that is the established standard of configuration for a form.
  2. A site to display & answer user created forms.
  3. A ‘configuration wizard’ to easily create (or edit) a form for any non technical user
  4. Each form can be referenced and displayed on any webkit site.
  5. Each form can create an account or use an existing account to post the response.

State of completion of the feature - development

Feature 1: done, requires documentation
Feature 2: not done, estimated level of difficulty/ time requirement is -
Feature 3: requires the post to Discourse feature to work (feature 5).
Feature 4: done, requires documentation
Feature 5: is being worked on by @nirgal.

Remaining work: Tech development

What we have now:

  • A form component that reads from a configuration topic that can be hosted and edited on Discourse
  • It creates an account (yet to be tested)
  • It posts a topic to Discourse (yet to be tested)

What is being worked on right now:

  • Logging in existing user
  • Posting to an existing topic / category
  • Testing all use cases

What remains to be done:

  • Production of configuration wizard: to easily create (or edit) a form for any non technical user
  • Input components from freelance form
  • Layouts:
    • Full page with slides
    • Standard view
  • Clear markup for configuring and styling
  • Reference a form by topic ID => reuse on different sites and layouts.
  • We need the script James wrote to be able to update existing topics (in order to get the wizard to work).

Remaining work: Production of (NON TECHNICAL) manual for event organisers

  • We want to get to: ‘configuration wizard’ to easily create (or edit) a form for any non technical user
  • To get this wizard to work we need the script James wrote to be able to update existing topics.

FAQs from event organisaters:

  1. How do we define/ create a link between each form and the relevant topic (e.g event) or category or tag that is on the edgeryders.eu platform?
  2. Step by step description of the process from filling in the form all the way to where you can see your content posted on the platform.
  3. Where/ how can the contents of that confirmation email be edited?
  4. What does the definitive version of the consent funnel that has been oked by the research team and our ethical advisors contain?
    • Events consent funnel: add url here
    • Platform conversation consent funnel: add url here

Hopefully this answers a few.

A form has to be configured with a topic ID or category ID to which it posts to. Do you mean a thematic/design link?

Step 1
The form component builds an object with key-value pairs based on the configuration of the fields array.

"fields": [
  {
    "title": "Your Name",
    "id": "name",
    "type": "text",
    "placeholder": "enter your name",
    "required": true
  },
  {
    "title": "Your Email",
    "id": "email",
    "type": "text",
    "placeholder": "enter your email",
    "required": true
  }]

Will create an object:

{
  "name": "",
  "email": ""
}

Step 2

The user fills in the form input fields displayed by the Vue component. The component uses the ‘type’ property of each field to determine which input module to show.

As the user fills in the form, his or her response is added to the form object.

Step 3

The user is asked to log in (3.a) or agree to a new account (3.b).

3.a

The user is directed to the communities page to login and is returned to the page with the form. The form must preserve its values if already filled in.

Upon redirection, a User API key is available in the response from the login provider.

This user API key is then used by discourse.js to post to the platform ‘on behalf’ of the user.

3.b.

The discourse.js script creates an account for the user, an automated email is sent (standard Edgeryders account email) to the new user with a password to log in.

** Step 4 **

The form object is parsed and posted either to an existing topic or as a new topic to a category on Discourse under the user’s account profile.

** Where/ how can the contents of that confirmation email be edited?

If you mean the confirmation email for a new account - this is handled by the current email notification system used to send emails to all new account holders. We have little control over this from the front end.

If you mean an email sent specifically with regards to the contents of the form (an event/job/etc) - this needs to be built. Otherwise it is a manual operation through mailchimp.

I meant it in the sense that we want to make it easy for anyone to:

  • Create a form that is where people respond to an invitation or call for action that has been published as a topic (for example: events are one kind of topic that are just tagged “event” and have additional tags for date, times etc.)
  • See where the responses (filled out and submitted forms) to a specific topic end up (ideally as topics within a dedicated subcategory so that we can easily reach everyone who has submitted a form e.G in order to get tickets for an event)
  • Be able to find ones own submitted forms so as to be able to modify the contents.

As an example: When I fill in the freelancers directory form in its current state, all the responses are collected in an airtable form. Which is something we wish to get away from. So what would our equivalent be?

  • My suggestion is that the forms ought to be published first in a closed category to which only community managers and event organisers have access.
  • The admins and organisers can then review the submissions and where needed verify the information submitted is accurate - that links work etc.
  • Create a form that is where people respond to an invitation or call for action that has been published as a topic (for example: events are one kind of topic that are just tagged “event” and have additional tags for date, times etc.)

It would involve creating a topic with a specific tag and with the right markup for a form. We would then have a forms site that collects user created forms and displays them for others to fill in, similar to the campaigns site.

  • See where the responses (filled out and submitted forms) to a specific topic end up (ideally as topics within a dedicated subcategory so that we can easily reach everyone who has submitted a form e.G in order to get tickets for an event)

The responses could be collected either in a thread of comments on that same topic where the form was created, or as individual topics posted to a single category. The former makes more sense to me.

  • Be able to find ones own submitted forms so as to be able to modify the contents.

The forms site could have an ‘history’ overview of submitted forms for that user when they are logged in, where they can see what they have submitted. Editing it would direct them to the specific topic (or comment) on discourse containing their response.

Ok so the layperson’s description is

  1. You fill in the form
  2. You submit it and the contents are temporarily stored but not published
  3. When you click on the confirmation link you recieve in the email, then your form is submitted.

Correct?

The way James set it up is:

  • You fill in the form
  • You submit it and the response is posted to Discourse under a temporary account
  • When the user clicks on a confirmation email, they then have access to this account and it is ‘activated’

but @hugi correct me if I got this wrong

Ok

We need a set of instructions for what to do when you want to set up a form using the webkit that is more like this than the very technical documentation for how to use the webkit.

It is best to assume that the person who is to set up a registration form for an event they want to organise are completely incapable of reading technical spec/instructables. Rather you need to think in terms of wizard logic:

Step 1: Click here (url)
* Change the questions you want to ask here: add code
* Click here to see what your form looks like!: URL
Step 2: Click here (url)
* Change the questions you want to ask here: add code
* Click here to see what your form looks like!: URL

Step 3: Click here (url)
* Change the questions you want to ask here: add code
* Click here to see what your form looks like!: URL

End: * When you are finished, hit “save” button.

  • You can see all of the forms that you have made here: url
  • Every time someone fills in the form, their submissions will end up here: url

Ok - we’re talking about quite a few different ideas:

  1. Markup in a Discourse topic that is the established standard of configuration for a form.

  2. A site to display & answer user created forms.

  3. A ‘configuration wizard’ to easily create (or edit) a form for any non technical user

  4. Each form can be referenced and displayed on any webkit site.

  5. Each form can create an account or use an existing account to post the response.

We have to be clear in separating these concepts.

Features 1 & 4 are done, they only need to be clearly documented.

Feature 2 can be implemented fairly easily.

Feature 3 requires the post to Discourse feature to work (feature 5).

Feature 5 is being worked on by @nirgal.

1 Like