Bounty for developing Edgeryders form interface

Other than the error above, it seems to work! Now @natalia_skoczylas does the thorough testing and we hunt down any remaining bugs. Great work @gdpelican.

And @matthias, the API seems to work like a charm. I got a confirmation email for a new account. Great work!

1 Like

Alright, I’ve done some more stuff this evening:

  • Added the map as a final slide rather than external link to visit
  • Added key events for the left and right arrow to move forward and back in the slides
  • Patched up the error handling from the Discourse API; we should have more user friendly responses now.
  • Fixed the safari display bug on the close button (I think… I don’t have an iphone for testing unfortunately…)
  • Added the consent translation (in English)

This should be good for a new deploy and another pass of testing.

I’ll unfortunately be away this weekend, but can pick up further feedback starting on Monday next week (NZ time).


I installed that new version on now. And did a bit of testing myself (in Chrome on desktop). Result:

  • When I enter everything correctly, the posts are created successfully and correctly.

  • When I enter an already-used e-mail address, the error handling does not yet work as expected. I added more details to the Github issue.

  • On the submission result page, the software mentions:

    […] you will receive the confirmation of your participation and access to delete or edit your data on your email […]

    That’s not really true, as Discourse does not send e-mails with access credentials for new accounts, or e-mails with confirmation of topic creation. The only e-mail people get immediately is a request to confirm the e-mail address of their Discourse account. Also they will get e-mails about replies to their topic. To edit or delete information, people would first have to log in, and for that, to reset their account password as a random password is used right now, and they are not told which one.

    @natalia_skoczylas could you please either (1) adapt the text quoted above and if needed (2) tell what else the software should do. For example, it could show the account information on the screen incl. username and password so people can take a smartphone camera photo to have it. (Sending a custom e-mail is not an option though. In-browser applications can’t do that directly, and another API extension is too much to ask for :wink: )

Overall I think we’re close to the finish line :slight_smile:

1 Like

Sorry for the late response, I messed up my Github notifications … and somehow expected updates only via this thread.

The good news is, with your patch to the multisite_account.json API code, error handling works fine now.

Also I moved the installation to the final place: . (The domain is a forwarder to there now.)

Last step for me (hopefully!) is to install the English / Slovenian version:

How’s this supposed to work? Two sets of files with a .env.production in each, or some clever trick with one set of files plus URL rewriting plus environment variables set at the webserver level? I’m happy with a simple “two sets of files” solution, but if you already figured out the other option I’d be equally happy to get the recipe for that :slight_smile:

Also, if you have a clever idea how to put a language switcher button on the very first page of the application, please do so. (Add it to the invoice as extra effort.) It should only be on the very first page, as clicking that link button on any other page would discard the user’s input on previous pages.

I could add a language chooser page with links to both versions in front, but it’s not an elegant solution. Proposal: Maybe change the application slightly so that the very first page is also defined as a slide in the en.json / sl.json configuration file. Then, the language switcher button could be defined as a new field of type “link”, maybe like this:

    "name": "Slovenian version",
    "type": "link_button",
    "required": false,
    "settings": { "target": "" }

@natalia_skoczylas we still need your input for this. The texts are not exactly describing the behavior of the software. This also applies to the following texts I saw on the first slide:

The collected data is anonymous, collected on an open source platform. You can see, edit or delete it by visiting a link we will send you as confirmation.

They will get an account confirmation e-mail, but that does not include a link to what they posted, unfortunately. So the text should be adapted …

You can finish this questionnaire at any point - but the further you get, the more concrete your vision of retirement will become.

Right now, they cannot finish at any point. The “Submit” step is only accessible on the last slide, and all previous slides have to be filled out to get to the last one. The simplest solution would be to make input on all of the previous slides optional. Does that make sense?

1 Like

Two installations with separate ENVs would work today, since we still have a little time I’ll have a poke at an in app language switcher as well. :slight_smile:

EDIT: I’ve put in a language switcher, which took ~2.5 hours of time. Here’s a video of it:


That looks great, thanks a lot! I could not yet get it to work so far … added a Github issue about it.

Sorry sorry

i somehow missed that!

How about this - the final information is only:

  • you will receive the confirmation of your participation on your email. You can opt out at any time, no spam guaranteed.


*na email račun boste prejeli potrdilo o sodelovanju. Odjavite se lahko kadarkoli, zagotovljeno brez neželenih sporočil.

Regarding the finish button, yes, I would say let’s make them all optional

About the last part, would that be enough? Or should I explain even more?

You can see, edit or delete it by visiting your profile via the link we will send you as confirmation.

Great work again @gdpelican!

Changing the text is very easy with this setup, so I wouldn’t worry about that too much.

@natalia_skoczylas and @matthias, would you say the delivery is done?


Yes from my side. Configuring the forms is something we can totally do ourselves. And I’m not aware of any remaining bugs. Big thanks to @gdpelican from a happy customer :slight_smile:

I then conclude that @gdpelican has delivered the project as agreed, and is also eligible to claim extra billable hours for the work authorized by @matthias here:

And here:

@matthias, can you confirm this too?

As Matt agrees, I do agree as well. Thank you all!

Confirmed about the additional budget for the extra work. This will be paid from the IT budget, so should go into a separate invoice.

We never talked about a budget for the second part (the Discourse API CORS issue we had) as James has already implemented it by then. So let’s bill that by time as well.

1 Like

Gotcha. So @gdpelican, we will need two invoices; one for the initial 1000 EUR, and another for the additional work billed by the hour. You can send them in a PM to me here in the platform, and I will put them up for processing.

It’s been a pleasure working with you again. :slight_smile:


Note for @natalia_skoczylas: We updated Discourse yesterday, so as a side effect we’re now able to redirect the posts to go to No need to migrate them later.

Small problem: I changed the configuration already but one small bug prevents it to work with So it’s broken right now, but expect it to start working later today, or at latest tomorrow. From then on, posts will land on the Academy of Life category.

I’m removing the corresponding category on Trust in Play already.

We adapted the form on according to your proposal now. (Only deviation: I discovered that the Slovenian version referenced the website for looking at, while the English version pointed to e-mail. As there will no such information by e-mail, I adapted the English version:

You will receive the instructions on your email, or you can grab the special BIO zine that explains it.You can find the instructions on the website, or you can grab the special BIO zine that explains it.

Personally I think the new copy as proposed by you (and live now) is not that clear so far:

* You will receive the confirmation of your participation on your email. You can opt out at any time, no spam guaranteed.

I would rather do something like this:

* You will receive an e-mail with information to access the online forum where your contribution has been published. There, you can see, edit discuss about and delete your contribution any time. You will also receive e-mail notifications if other participants react to your contribution, or when there are updates about the Academy of Life program and events. You can opt out from all of these any time. And of course, no spam e-mails guaranteed!

Make it shorter, of course :slight_smile: If you want, go through the whole copy texts again one last time to fix glitches that you see. Send me both the English and Slovenian versions for changes, ideally by editing these two files as that makes it much faster to understand and integrate your changes.

Also done now. All the form questions are optional now, just the fields for account creation on the last slide are required. If that turns out to attract a lot of incomplete replies, we can easily switch back to making the fields required.

Cool, I’ve just merged @matthias 's changes into the development branch, and have invoiced for this piece of work. We did it, woo!

From now on, let’s make the source of truth for this; I’ll submit further updates to that repo if they need to happen.

Some things that weren’t in the original scope of work for this contract but might want some thoughts on them at some point:

  • Holding the data file(s) in the code isn’t the best experience for updating copy / adding translations etc, and particularly the danger of modifying one data file and getting the settings / structure of the form out of sync with the other translations is somewhat high.

  • The single json file approach is good for this scale, but if this starts facing heavier use you’ll want to split out the structure of a form (what fields it has, how it behaves, what fields are required etc) with the content (what the titles / buttons / fields say in whatever language is selected). This will allow you to throw a translation file up on something like Transifex and allow the community to update translations without needing any technical ability.

  • There’s some initial gestures towards style customization in here, but at the end of the day the styling is hosted in this repo and requires a code change to modify; ideally there’d be a way to apply an external stylesheet to an arbitrary form, so you don’t need to fork this repo to host two forms with different questions / styles

It’s been a pleasure working on this one; best of luck with the conference and hopefully we’ll work together again soon!


Yes, good idea to keep everything in order. It seems the cleanest way to do this is that you’d delete your edgeryders-form repo. While doing so, you’ll be able to make edgeryders/edgeryders-form new parent repo (source). In case of more work, you’d then fork from that one.

Thanks for these, all good points (and added as Github issues now: #12, #13). To add one more: I am thinking about standardizing and expanding our form description language. We already have two different JSON formats for different types of forms, the other one being used in edgeryders/forms. In the medium term, I’d like to standardize these into a (subset of) QML, maybe building on one of the existing mechanisms to use QML for web applications (PureQML or qmlweb; see also qmlweb examples).

1 Like