IT Development Plan 2019-2021

Yep. As I wrote above, I see some value (potentially, even some financial value) in a single Neo with all the corpora ever coded. It becomes “digital ethnography central”, so that we make a claim to own that space. Plenty of network externalities in the RECODE vision, I am loathe to throw them away.

In practice, if a federated site goes dark, we still have all the data with a #ethno-something code in Neo (and perhaps in ER as well).

Since it’s a bit buried in the document above, I should bring the attention to this myself:

My current plan for both the POPREBEL and NGI Forward online platforms is to launch them as federated Discourse websites. It’s the thing we called “whitelabel platforms” but with a new implementation. Means: each platform has its own domain, shows only categories related to its own project on its homepage, and is integrated with edgeryders.eu only via a “single log-in” function, a cross-platform notification menu and some cross-links in other places. It will also have its own data set (“corpus”) in Open Ethnographer and Graphryder. For more details, see here under “1. Solution: Federated Discourse sites”.

If that technical implementation would conflict with anything else in the project, now would be the time to tell me :slight_smile: @anique.yael @amelia @directors

1 Like

I don’t like it much, Matt. Because:

  1. I would like to involve the existing ER user base in the new projects.
  2. I would like to pull the participants of the new projects into ER.
  3. I would really like to keep the database (including OpenEthnographer stuff) into the main site.

This is both for technical reasons and for commercial pitching. The larger our community and our dataset, the stronger we are.

Can you reassure me on these points?

Wait, I would like to store the database on the main site when this ends.

1 Like

My main reason was that the NGI Forward project wants this:

“Interoperability” probably means just a link from ngi.eu, and choosing similar colors. But I’d consider it weird and not smooth if that link goes to (say) edgeryders.eu/c/ngi-forward and then users find a truckload of other, unrelated information on edgeryders.eu.

Still possible by cross-site @mentions and a content cross-propagation plugin displaying in the footer. But serendipitous content discovery by users would likely suffer …

Again possible by cross-site @mentions. But it forces users to understand how they can be referenced from a site they never visited. So the confusion would be moved from the point of arrival to the federated platform to this point of discovering the other parts of the federation …

When the project ends, yes, totally. We’ll import over all the content of “our” federated Discourse sites into the main site when they fold up. I even think we should even put that into a contract template that we’ll use for other whitelabel clients such as Trust in Play and Timisoara: that the public content has to come with a CC-BY licence and that we may archive it incl. all metadata on edgeryders.eu if and when they want to close down their whitelabel site.

 

So, hmm. A federation setup has its own technical complexities, and avoiding it for these two projects is certainly less work on the tech side. So if we don’t have to host the POPREBEL and NGI Forward content on their own domains, maybe it’s better not to? We could take our time to get the multisite setup “right” in smaller projects like Trust in Play, Biofabforum and (if Hugi wants to migrate) Blivande.

Anyway, still interested in other opinions. The advantage of a federated setup is “more freedom”, of course: everything we customized on edgeryders.eu can be customized differently.

3 Likes

I do, I think it would makes sense to have Blivande be a federated site rather than a category on Edgeryders main. And much like Alberto, I’d like to be able to pull people from Blivande into other ER sites and vice versa.

Thank you for this comprehensive plan @matthias!

I don’t understand some of it due to my level of technical knowledge but trust @alberto’s feedback has filled the gap there.

Some questions:

  • One of the selling points of our contributions to both POPREBEL and NGI Forward has been that we will leveraging an already existing online community. How will the activities of the federated sites feed back into the Edgeryders main site? For example, how will the “Content cross-promotion plugin for whilte label platforms” feedback into edgeryders.eu rather than just between federated sites?

  • Similarly, can I double check that the while Discourse-to-Discourse migration script mentions content import after decommissioning, will it also enable users from the new sites to continue to be active on edgeryders.eu?

  • On this note, having just come across how OPENCARE’s fora have been archived into one workspace, I’m wondering if there is a way to expand on this such that the sub-fora can be kept clear? The sub-fora made it really easy for people to go to their content of interest easily and considering the content will maintain relevance, as well as the projects as examples of our work, I’m wondering if there’s a way to create a kind of portfolio subsection that can maintain the past projects in their form, while still avoiding what you rightly so have called a “category graveyard” @matthias?

Some clarifications:

  • The “interoperability” with the existing NGI.eu site is important yes. But keep in mind that we are taking over “consultation” from that project in NGI Forward. As above, this is based on an already active community. If we have an empty site it will be an issue. How can we work with your suggestion of federated sites while showcasing the existing active online community?

  • Multimedia coding requirements in OpenEthnographer are indeed image, video and audio. I recommend you liaise with @amelia and @mette for further specifications.

  • Please note that if we win AgriAgent, the two stage proposal that we should hear on in December or January, there will be increased Graphryder integration requirements. We have 18K allocated to this in addition to 12K for tech development and maintenance (30K total). If you’d like further details at this point, I suggest you review Work Package 4: Design and Development of AMB/DL framework from p45 of the Agri Agent proposal here. Specifically we would be working on integration of Graphryder into a project wide interface as follows:

  • On Dynalist integrations, I agree with all your points here, and the Gantt chart integration is a fine idea. I haven’t had a chance to move on freemind integration and let’s see if it becomes a priority for others.

  • On financial reporting, I’ve shared my thoughts in the thread Financial reporting for a Horizon 2020 project

  • On timing, please note that the POPREBEL platform cannot go live until the Ethics and Impact Plan is approved by the Commission. This is due at in February (hopefully we can submit as early as possible), with the platform going live planned for March.

Thanks again and do let me know if there’s anything else you and your team need from me at this stage.

This has been true across the board. If clean whitelabeling means separate databases, we keep it as a solution of last resort: some clients will ask for it, and might make sense for ongoing communities, but we will always try to steer them towards cats in edgeryders.eu for one-off projects, like all H2020 stuff. This is the way that most adds value to our user base and our data base, and this is where it is our best interest to go.

Maybe we can think about a solution made of:

  1. A cat in edgeryders.eu.

  2. A self-standing site that populates itself via queries to the edgeryders APIs. @owen showed me a framework that does just that, and was saying how easy it is to create specialized sites based on anything that has JSON APIs (cats, tags…) . He is using it to make the particip.io website. This is read-only, but it might be enough to placate the client’s comms gods. Meanwhile, the real work is done on the platform.

3 Likes

That seems like a pretty good compromise. Generally, I think the way Open Care worked was pretty good. And, as Matt points out, because of tagging it is easy to call it all back up if you wish.

Seamless movement between communities of interest is a good goal and not that simple to solve.

Ok, so I think we agree on a solution by now.

So: both the POPREBEL and NGI Forward projects will live in public top-level categories on edgeryders.eu. And, as Alberto proposed (and we usually do) we will have landing pages. These may pull featured content from the edgeryders.eu site and display it, and can be multilingual, but in total will “just” be read-only funnel websites, without a way to log in there.

1 Like

I think @owen has discovered an efficient way to make read-only sites that update dynamically from Discourse APIs. Maybe we could ask him to make these pages outside of the platform (give partners more aesthetic freedom etc.)

1 Like

Good idea. I’ll discuss with him about that. Hopefully we can make it in such a way that we can more easily re-use the basic structure and code of these funnel websites for future projects.

Thanks @matthias, you can see some of the work here - https://participio.netlify.com

I’m currently working on integrating these API calls into individual components in Vue, so they can easily be used on any webpage and styled accordingly - this should make things a little easier for templating.

1 Like

This is cool and could be very helpful for the different topics @noemi see https://docs.google.com/spreadsheets/d/10bdjvFshsJSkn9dsxPSe5xEl8eg760YqzMLPSJd0Y7Q/edit#gid=0

Let’s collect the requirements for the façade websites for POPREBEL and NGI Forward

In the plan above, I propose this item to create the façade / funnel websites for both POPREBEL and NGI Forward:

@owen has some nice way of creating such things, so let’s collect the detailed requirements for it so that we can contract him for that and he can get to work.

Outline of things I already know or decided

  • The façade websites will have their own domains and serve as the first point of contact with the POPREBEL / NGI Forward project.

  • We want the façade websites to be single-page websites. If they have a menu, the menu items should scroll the page down to the corresponding section.

  • We’ll collect requirements for the content of these sites, but leave the visuals / design to Owen. There may be a few exceptions to that, where needed.

  • We can (and will) pull live information from Discourse and embed it on the façade website. This can be recent posts, statistics like numbers of likes and comments, a list of contributors etc… For inspiration / examples of such content, see Owen’s previous work at participio.netlify.com.

  • Self-hosted. Unlike Owen’s site for Participio which is hosted on netlify.com, we want to host the POPREBEL / NGI Forward façade sites on our own server. Should not present an issue, as netlify.com is only a deployment platform, not locking in development to that platform.

  • No server-side scripting for page rendering. One options is that the façade website would query the Discourse API using client-side JavaScript code to obtain the featured content etc. – but that puts unnecessary load on Discourse. The other option is to use a static page generator and let that run regularly (once per hour? once per day?) on our server to re-generate the static façade websites. (Does any of these options work for you @owen, and which one?)

Open questions

  • Which main sections do we want on the POPREBEL façade website, and which on the NGI Forward façade website? How to call the menu item for each section?

  • What live content elements and statistics should we pull from Discourse for the POPREBEL façade website, and which for the NGI Forward façade website?

  • What introductory content do we want on the POPREBEL façade website, and what on the NGI Forward façade website? Note that this should be very short content pieces (a paragraph max, plus image / video / animation).

  • Who should Owen contact to write that introductory content in each case?

  • What are the exact requirements by the NGI Forward consortium about the integration with the project’s current website (which is a point in the application)? Does that affect the requirements for the façade website collected here? Or, if any of these is not known so far, who do I have to contact about it. Probably that’s a question for @anique.yael.

  • And for @owen: Do you need any additional information to what I asked for above in order to be able to give us a price quote for these two façade websites? Assume complexity to be very similar to what you created for the Participipo project.

Can people please give me their input on the above questions? Just pick what you can answer or contribute to, please – @nadia @johncoate @noemi (@alberto). Thank you.

From the phone and in a hurry, but: project websites are an EU obligation, so subject to certain standards (logos etc.). They fall within the remit of the coordinator. We cannot just make a move and build websites that make sense.

Two possibilities:

  1. Negotiate with the coordinators. This should start very soon, I believe in POPREBEL the website is due at month 3.

  2. Leave the institutional websites alone, and build onboarding funnels instead, as we did in the past.

Thanks @alberto and I agree although not completely across all the technicalities. As far as I see it, project coordinators are responsible for the project’s websites - and yes @alberto POPREBEL’s is due for Month 3, the specs for which are already under way I believe. The idea is that we can pull from there and aggregate to there. But perhaps I’m not clear on what you mean by a facade website - do you mean more a facade for all our fora and discussions as per [quote=“matthias, post:22, topic:9202”]
This can be recent posts, statistics like numbers of likes and comments, a list of contributors etc…
[/quote] ?

Something to keep in mind is that we are still in discussion internally and with some partners around how to go about the multilingual component and accessibility - for example: do the Czech audiences go to a Czech only landing page or do they go to one with all fora in all languages? This came up in POPREBEL and will quite possibly be different in NGI Forward considering the different nature of the project.

NGI Forward is a sector-building and stakeholder engagement project for a high profile initiative, with a whole other project taking care of communications and media. We will have to work very closely - particularly @nadia - with the coordinator Nesta and the communications project (name not yet known) on all our comms. I’ll bring up your question in the kick off meeting Monday-Tuesday and get back to you.

That’s what I mean by the “façade website”: we’re not dealing with the institutional website at all but simply need a pretty-looking overview site where people arrive and are then guided to our actual, Discourse based discussion platform. Since we decided above to host the POPREBEL and NGI Forward discussions right on edgeryders.eu and not as a federated Discourse website on their own domains, a façade / onboarding funnel website is the only way to add more customization, own domain, some branding and a proper sense of what’s going on to the first page people see when visiting an invitation link they got.

That should also answer your question @anique.yael what I mean by “façade website”. As an example, Owen’s participio.netlify.com is a façade website for the Participio category here on edgeryders.eu.

To and from where, the institutional project websites for POPREBEL / NGI Forward? If that implies automated data exchange between our Discourse based discussion platform and that website, please provide the tech specs for that. Didn’t hear about that requirement so far.

As far as our Discourse based platform is concerned, that’s just about sharing a link to a language-specific sub-category vs. the link to the top-level category. But Discourse is not about landing pages, so that’s a decision that will be needed for implementing the façade website(s), which is meant to provide the landing page(s).

Means, we’d need a rough / basic decision about this quite fast (a week?) so that Owen can get to work.

Thank you. My question is especially about how much the look and feel has to be the same as that of the existing NGI Forward institutional project website and what else is meant by “integration”. If a link that goes directly from their website menu to edgeryders.eu/c/categoryname is not acceptable (because the look&feel and domain is different) then I would propose to link to the to-be-developed single-page façade website instead. It would still not be on the same domain as the institutional project’s website. If they want that, it’s better that we develop the Discourse façade website within the same framework and code base they use for the institutional project website for NGI Forward.

1 Like

Got it thanks @matthias! RE: multilingual architecture / landing and [quote=“matthias, post:25, topic:9202”]
Means, we’d need a rough / basic decision about this quite fast (a week?) so that Owen can get to work.
[/quote]

I defer to @noemi and @johncoate here. No doubt they’ll be in touch to pull you into the discussions. NGI Forward may take a little longer but I’ll prioritise feedback from the consortium at the kick offs.

1 Like

Exactly!
What I can report back from these training days is that most partners and our comm mgmt team is ready to work with a big POPREBEL category + subcategories per countries, as well as anything that we propose i.e. different POPREBEL [country] category + subcategories.
No strong questions or opinions were voiced about language and web design.
Happy team over here.

1 Like

Good. In that case, I’ll simply decide for POPREBEL as follows:

There will be language-specific versions of the façade website, but these will simply be translations of the English version, with links adapted to point to the respective language-specific spaces of the POPREBEL discusson on edgeryders.eu (however our community builders decide to structure the space on edgeryders.eu).

Links to share to the façade website would look like this, using an example domain name:

  • http://poprebel.eu/ - English version, the default
  • http://poprebel.eu/cz - Czech version
  • http://poprebel.eu/hu - Hungarian version
  • … and so on

Not all of the translated version might be there on launch day.