Preparing the new interface for edgeryders

It’s the next thing on my list. Will create and publish an API spec, give it 2-3 days for you guys to comment, and then @daniel will make it happen.

For the frontend development it seems that time plan, developer time and management are roughly sorted out already :slight_smile: So @natalia_skoczylas please work with Hugi and Owen directly for this. I will not intervene there or be responsible for results, except you tell me to (say, in case something goes wrong, but I don’t expect that to happen …).

What I need @natalia_skoczylas are the wireframes from your UX person.

I wrote the API specs for the custom API extension required to support this feature. In a sane world, that would finish what I had to do for this little project :slight_smile:

But I’m surprised I don’t see any progress here? Maybe you guys got caught up in the waterfall model (where you need full upfront specifications for the software and everything should flow from there …). Or something else is not working out. @natalia_skoczylas are you aware that you’re expected to provide wireframes for the user interface in order for this to progress?

Damn, how come that I missed this thread, really interesting discussion (from my techie-perspective). @hugi @matthias : Next time feel free to reach out to me as a sparring partner wrt to these more technical discussions.


Oh, totally! I just didn’t expect you or anyone to find this stuff interesting, otherwise I’d have tagged you. To me this is just the same old software plumbing work. Trying to make systems harmonize with each other that were never meant for that …

1 Like

I’ll get this done by the end of the weekend, our designer was swamped with other work


Do you have the designer’s work to share with us now, Natalia? Just trying to unblock the progress here …

And for the record for @nadia as we were discussing about this in the H2020 call that ended just now: the original budget allocate to this was on the basis of a simpler tech way to implement this post-to-Discourse interface.

Then somewhere above, me and Hugi decided it makes sense to split things into a Discourse API (“backend”) and a JS/HTML form (“frontend”) so that the tech integrates properly with the JS+HTML minisite tech stack we are building. That tech decision makes the post-to-Discourse interface more expensive / the current budget “tight”, but is nothing of Natalia’s doing.

The current budget would still suffice for the relatively simple interface that Natalia wants, and then we can test the whole system and see if it’s a promising thing to invest in. But I agree with @hugi that UI/UX development that’s up to the standards of UX in one of our H2020 minisites would need additional money.

So it’s the typical “requirements changed while IT project underway” story, and I did not see that coming :expressionless:


ok. got it, @hugi and I will follow up on this.

still waiting for it, 3 people now working and it’s not making it faster

1 Like

I just modified the API specs (under the link above) because we were running into some, umh, complexities when trying to implement the previous version.

(@hugi, you were asking to see this update when it’s ready. It is now. Your team could start to write API clients against this spec “as if the API existed”. It will exist in 8 days … if everything works as planned now.)


Here is the wireframe v1

We will have a version 2 ready tonight i hope - there will be some small changes in the design of the v1 as we dropped the narrator, plus the last bunch of questions, demographic data, has to be somehow solved in a better flow.

How does it look @matthias @hugi @owen ?

I am getting Pika registred, so she can answer the questions with me

This looks like it could be quite efficient at getting people to share. Good design and thinking!

However, it looks like a native iOS app. Is the intention to build a native app? If it’s supposed to be a website that looks like a app, how does it look when you open it on a larger screen?

1 Like

No, it certainly shouldn’t be an iOS native app - i think it looks like this just because Pika works on mac devices, but it should work across devices and systems and look slightly differently when on the desktop - I’d say more typeform style, wide screen, one question at a time situation

I see! Well, that’s what we need a design for - how it should actually look. Can she develop that too?

1 Like


1 Like

Second version

@pika is here so she can also join the talk

Pika, will you be able to prepare versions for mobiles/all kinds of devices once we settle for one of these

Which one do you like better? @hugi @matthias @owen

Looks good but I ask you to please not collect so much private data about people. Other than email, a handle for their account on edgeryders and country…


This will be optional and its for the research we are doing - what do you suggest dropping?

I see this from the perspective: You are a perspecuted minority. Some day someone with a gun knocks on the door of a keeper of records - asking them to hand over all information they have about members of your minority. What information would you absolutely not want them to be able to give?

Cool, will adapt this - how about email and name/nickname as the only obligatory info, and then a window where you can share other data you want to share, or leave a comment?

Also - at the programming team - is it an option to have a voice recording option or maybe even voice to text converter attached to it? Would that be difficult? I can approach some companies to ask for a free run for a few months as part of the biennale, we could test how it works (it probably works terribly with slovenian anyway) @matthias @hugi

1 Like