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!
I installed that new version on bio26testing.edgeryders.eu 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 )
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
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:
@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?
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
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:
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.
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.
Note for @natalia_skoczylas: We updated Discourse yesterday, so as a side effect weāre now able to redirect the bio26.edgeryders.eu posts to go to edgeryders.eu. No need to migrate them later.
Small problem: I changed the configuration already but one small bug prevents it to work with edgeryders.eu. 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 edgeryders.euAcademy of Life category.
We adapted the form on bio26.edgeryders.eu according to your proposal now. (Only deviation: I discovered that the Slovenian version referenced the bio.si 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 bio.si 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 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.
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).