Please forget about the voice based options within the limit of the current budget 
1 Like
How much would it be?
Hard to estimate. 5k maybe for a good pipeline to just upload voice and post it, including both the front end and back end work. Tech is not mature enough for voice to text, and even for only posting voice means hosting big files, buffering to upload and all kinds of complications.
this is totally out of scope afaic
Me I would prefer not to have the data collected at all if edgeryders is reponsible for it.
Me too. The difficulties start with the fact that there is no proper way to store such data in Discourse at the moment: you probably don’t want to publish them together with the post that goes to the platform, but somehow “hidden”. For that, we could create custom Discourse fields in user records and store the data there, but that’s ugly as you’d need quite some fields and they clobber our nice an clean userdata records with all that structure that will be empty for most users. Putting all that data together into one user record field is less ugly in one way and more ugly in another. And then it’s about how to keep this data safe – that’s kind of acceptable if we hand that personal data to Natalia’s research team and delete it from our database, though. It’s additional admin work on our side, of course.
But there’s a nice hack that @natalia_skoczylas could use to work around the issues from above. As far as I understand you use one fixed survey computer for this exercise at Biennale. In that case, just collect the data only locally on that computer, and only send the text content to Discourse. That’s not much additional effort: the web developer would create records in the browser’s local storage for the data that is not to be sent, together with the user ID of the corresponding Discourse user so that you can associate this data with Discourse topics during your research.
With that kind of solution, the potentially more sensitive data does not leave the survey computer and we (Edgeryders company) don’t have to take responsibility for it. Works for me. (If you choose this way, be sure to take backups of the data from the survey computer once or twice a day, to prepare for the case when a user will accidentally wipe browser storage or similar … this type of storage is slightly “fragile”.)
And once again about the audio components:
A good guess if we’d have to build that pipeline ourselves.
Maybe, maybe, there is an implementation of what we’d need out there already, though. In my mind, the ideal case would be posting MP3 files to Discourse because: they are small and can be uploaded as normal post attachments files to Discourse. Then, we’d embed a player inside the Discourse post to play them (maybe that already happens, as for uploaded .mp4 videos it does). That way, no backend work at all would be needed.
But we need the browser to create and upload MP3 files. Turns out, at least one part of that exists: there are at least two libraries for in-browser MP3 encoding. Warning: this is crazy and cutting edge technology. Browsers were not meant to do this, so expect it to not work everywhere. It could be made to work on a single survey computer though.
Even if we’re lucky and find good components, I don’t think the price tag would go below 3,000 EUR for a reasonably reliable implementation.
Another find: there are commercial products for this use case. Not cheap though. I don’t think it would change the above price tag as the challenge now becomes to integrate their product. But at least, success is almost guaranteed with this. The downside is of course that we’d not get an open source end product: spending so much to integrate somebody’s commercial product is a waste in my view.
2 Likes
ok, re data collection - we will reduce what we collect to name, email and age, leaving the age optional. We plan to share links to the website not only on the one laptop, but there are two more locations for the biennale - the retirement home where we work, and a location in the city center. As the questionnaire is an designed as one of the entry points to the retirement home, we’d like to have it accessible in various spaces. But you’re right, I don’t want us to be responsible for handling senstivie data.
The voice option would be nice and I’d love to try it also as a feature for edgeryders in general, since it seems people are increasingly comfortable sharing their news by recording voice messages. I thought it was a thing in Italy and Asia, where people don’t type on phones anymore - but many of my German friends also don’t. I have issues with it, but it’s good to keep ourselves open to these changes. No idea if there are forums based on voice exchanges, yet. That would be a funny evolution. It’s also the surprise - you can kind of see keywords in a written message, but you have no idea what will happen when you press play. Nevertheless, that’s beyond what we have left in our production budget, so some other time 
Thanks a lot!
1 Like
ok @hugi @matthias when do you think this implementation will be ready? So we can maybe include it in the Festival/NGI onboarding process too (ping @johncoate )
As I understand it, the API will be done soon. That leaves the front end. Once we have a design I’ll need to prepare a brief to get someone to take it on. I’m extremely busy this week and going to Helsinki next week, so I don’t think I can make that brief until late next week. It’s reasonably simple once someone is on it, but with all of those factors I think mid October at the earliest.
The API is ready now. Wasn’t easy but @daniel got it to work on the live site today (yay!). I’ll move the documentation with some updates to our API manual now.
How much of the user interface designed by Natalia’s team would these onboarding sites re-use? If they will look and behave quite differently, you can also make your own brief and look for somebody to create the JavaScript application for this. It will still make sense that the same person is then briefed by @hugi later and does the Biennale site as well. But it could speed things up somewhat. I can add the relevant technical parts to that brief, if you decide to go this way.
1 Like
@natalia_skoczylas when are you expecting we’ll have the design?
By the end of this week
1 Like
Great. Remember to also include the ethics. Everything that ends up on the platform needs to pass through some sort of ethical approval for us to use and analyze the contributions. I suppose @alberto and @matthias know how to formulate this in English?
The wording of the current consent funnel questions is contained in consent.hbs. I propose to include a checkbox with a sentence or short paragraph to the same effect, summarizing what people are supposed to learn from this consent funnal Q&A exercise. We can then show it to our ethical advisor for approval, and modify it if necessary.
Ok, finally, after tumultuous developments we have it - the final tablet version. If it’s ok and everyone agrees, I will tomorrow have the mobile and desktop versions as well:
Questionnaire digital 30.09.19 FINAL.pdf (67.7 KB)
I hope it’s all clear if not, I am here to answer any question
the Exit button comes at some point - in my mind, it would actually transport you at any point to the final slide, where you have to give your data and submit. So the information that you can finish anytime will show once you hoover over it. Would that work? Very sorry it took so long. TAblet is most important as it will be part of the exhibition, so let’s start with it.
1 Like
I ask that you
- mention that this tool has been built with support from the Edgeryders community and organisation.
- make sure the code is uploaded onto our github repository.
Of course, I have already sent the credits for the catalogue print and the exhibition design.
I am really thrilled to have been able to get Er to a biennial and to cook up this little thing - very excited to see how it works.
I will make sure the code is there.
@owen and @hugi, let me know if there’s anything you’d like to change, and if not, how long do you think this might take?
Thank you all
Questionnaire digital iPad 01.10.19 FINAL.pdf (68.3 KB)
With a tiny update - this won’t change, we’re moving forward with the mobile and desktop
There are some things that need to be added for the design to work with the API.
- How should these answers be compiled into a post? How should it look on the platform? Should questions be made into headlines and bunched together? Headlines are quite long.
- Where should the age information be stored? API has no place to store it except in the post. Should it be included there, like “Age: 54” at the top of the post?
- Check point 6 under “Typical usage” under 3.4. Multisite account creation in API description, the design needs to include that “Account summary” page once a submission is completed.
- This design does not include how error messages should be handled. Either include that, or the developer will just use the simplest “out of the box” design which you might not be happy with.