search

fossasia / open-event

Open Event Project, Samples, Documentation and Artwork http://open-event-dev.herokuapp.com
GNU General Public License v3.0
1.71k stars 175 forks source link

Google forms, websites, alternatives - What options do we have to collect event data? #5

Closed mariobehling closed 9 years ago

mariobehling commented 9 years ago

To collect data for events, we are using Google forms. This is a convenient solution, but we are currently not able to create multiple relationships, e.g. one speaker is doing to several talks or one talk has several speakers. Also in Google forms there is no way to have fields like "add more speakers".

Is there a way to handle this, e.g. a plugin for Google docs? What other options exist Limesurvey? Are there suitable event systems? What options are there to create our own lightweight service, e.g. a JS site? Pentabarf and Frab are solutions used by some older events in Europe, but they are not "straight forward" and design is outdated.

mananwason commented 9 years ago

@mariobehling We can have 2 json api's, one with the data where we have 2 speakers and one with data where we have 1 speaker or we can just have one json array with objects for multiple speakers.

creativepsyco commented 9 years ago

I believe once the schema is finalised we can create a bunch of scripts to generate JSON from which ever data source we choose. For Google Forms, you can perhaps decide a number of maximum speakers allowed. And some how hide, the unfilled ones. Don't know if that is possible. I have some experience with generation of data from Google Sheets.

mananwason commented 9 years ago

@creativepsyco What about if we just set a null field for 2nd speakers and use it wherever needed.

championswimmer commented 9 years ago

If we finalise the json schema, wont be just most convenient if we write a small php/node/python server-side form that generates the json? On May 7, 2015 10:10 AM, "Manan Wason" notifications@github.com wrote:

@creativepsyco https://github.com/creativepsyco What about if we just set a null field for 2nd speakers and use it wherever needed.

— Reply to this email directly or view it on GitHub https://github.com/fossasia/open-event/issues/5#issuecomment-99712881.

mariobehling commented 9 years ago

At the moment we are also using JSON, that is generated from the google spreadsheet. @batraabhishek could you provide more info how this works, please?

@championswimmer Could you check, if there are any standards for JSON etc., that events using already? re:publica has its data here http://data.re-publica.de/data/ and there is this project on github https://github.com/opendatacity/re-data

creativepsyco commented 9 years ago

@championswimmer Yes it would be easy but the Google document doesn't change much, so I would recommend generating the json from any data source separate from the backend. The backend can be a simple sinatra app that serves static generated JSON files.

championswimmer commented 9 years ago

I meant in the way of creating a dashboard that the event organisers can use to update their event details. It'd store the data as a json (exposing the endpoint for the app), and also show human readable + editable form for the event organiser.

On 7 May 2015 at 11:55, Mohit Kanwal notifications@github.com wrote:

@championswimmer https://github.com/championswimmer Yes it would be easy but the Google document doesn't change much, so I would recommend generating the json from any data source separate from the backend. The backend can be a simple sinatra app that serves static JSON files.

— Reply to this email directly or view it on GitHub https://github.com/fossasia/open-event/issues/5#issuecomment-99735935.

mananwason commented 9 years ago

This sounds like a good idea @championswimmer but how'd it be different from google forms?

rafalkowalski commented 9 years ago

@creativepsyco I think Sinatra or Ruby on Rails app it would be easy to create.

championswimmer commented 9 years ago

@mananwason, control and flexibility over it. the main reason we started discussing this. Google forms wont allow for adding a speaker, or other such manipulations that do not exactly conform to a spreadsheet schema

On 7 May 2015 at 14:39, Rafał Kowalski notifications@github.com wrote:

@creativepsyco https://github.com/creativepsyco I think Sinatra or Ruby on Rails app it would be easy to create.

— Reply to this email directly or view it on GitHub https://github.com/fossasia/open-event/issues/5#issuecomment-99786204.

mananwason commented 9 years ago

Oh sorry @championswimmer I misinterpreted earlier

creativepsyco commented 9 years ago

@championswimmer The problem with creating a full-fledged event management application is that of maintenance. There will be a requirement to do testing, monitoring, access control, audit logs, scaling etc which I don't think anyone has the time for. I would aim for something that works, but can be replaced in the future. Abstracting away the implementation details (whether the backend is a fully fledged app vs a simple static server serving JSON files) makes the client rely on just the data schema, no matter where the data comes from.

mariobehling commented 9 years ago

@creativepsyco @championswimmer Yes, agree, we need a modular solution. We have some man power here, but abstracting also offers the possibility that other systems can implement the same data schema. So, we are advancing to the question: What data schema should we use?

championswimmer commented 9 years ago

re-data looks like a good point to start form. They have done a lot of work, and they HAVE a node.js webapp to generate the json. We can use their solution or create a simpler one for our needs, but their schema looks good to use.

leto commented 9 years ago

I agree with @championswimmer :+1: to using the schema from re-data @mariobehling I think we need to design a database schema for our own needs. re-data requires CouchDB and NodeJS and suggests using Docker.... It seems awfully complex for what we need. I wrote a sketch of a database schema for open event while I was at FOSSAsia. I will dig it out of my notebook and create a new issue to talk about it. My suggestion would be a PostgreSQL database that stores the raw data (as columns/tables or raw JSON or both) and a cron job which publishes the latest JSON at a public URL with nginx. This can be done purely with Postgres and Nginx (no Ruby/Python/etc needed) which makes it very performant, i.e. it can support many, many concurrent users and events. Then any standard phpmyadmin/Adminer app can be used to update the database or a custom solution with Flask-Admin: http://flask-admin.readthedocs.org/en/v1.0.9/ , which I have recent experience with and can highly recommend

mananwason commented 9 years ago

@leto this sounds great. It will simplify things a lot. What about using gcm based on a server to provide updates to the app?

batraabhishek commented 9 years ago

Hi everyone. Sorry for the long absence. In FOSSASIA app, we are fetching data from Google Spreadsheet, Each sheet in the spreadsheet is visualised as table with first row as column and following rows as data. Google visualisation API converts the spreadsheet into JSON response. Few drawbacks of using Google Spreadsheet:

  1. No provision of constant data validation.
  2. JSON returned by API cannot be simply parsed. It contains JS functions and some extra data. Need to remove JS functions by matching a function regular expression.
  3. Even a small change in the spreadsheet that doesn't match the format, will fail the parsing of data on app side.
  4. With increase in traffic and content, each request takes a long time.
  5. Obviously one to many, many to many relations are not possible.
  6. Last, JSON response contains a lot of data which is not required, thus adding extra bytes to every response.