Event app upgrades for discussion

[mmmavis]

Just wanted to capture the discussion we had in London. Here's the notes extracted from this pad

Improve what we already have:

• Improve UX
• users view of now, next, and favorites
• Preserve app state across session
• Offline functionality
• Reduce scrolling (on mobile especially)
• Explore options for syncing between devices (ex. desktop to mobile)
• Feedback from staff on London use of pads
• Improve admin experience of session management
• Evaluate benefits of Reactication? (Improves scalability)
• Identify diverse use-cases across org (ex science sprint, maker party, ...)

Add new features:

• Add stream (etherpad-esque images, text and links)
• Think about data management (researching) - Spreadsheet vs database (cms)
• Prototype beacon possibilities
• Does the schedule app need to facilitate post-session connections between leaders?
• Meet with program managers for user feedback and interviews
• Apply mofo universal design style to app

[xmatthewx]

@gvn @flukeout @mmmavis – Here's a summary of 3 things we could estimate. Let's find a time to discuss.

How many people & heartbeats would be required to:

1. Reactify the app + Improve biggest UX pains + Design better UI
2. CMSify the data. (Will this require more or less time and heartache than supporting spreadsheets?? Maybe yes, maybe no.)
3. Enable documentation (see below)

Documentation: Every session has a button that links to a view. That view displays attachments and has a button & picker to add a new image, text, or link. There are no user defined styles. No login. Just a simple thread. Think visual etherpad. Attachments would receive the session tags as their own metadata, so that a user could view everything related to a track or issue. Again, as a simple list. No frills.

[gvn]

I'd be curious to know what the current process is for managing content and what the pain points are.

It seems like this is a perfect candidate for Django given that events require structured data. I'm not a Django expert, but from a schema POV this app should only require a few tables (maybe even just 1 with the current functionality).

[gvn]

As to "Reactification" I feel like we absolutely should rewrite in React. This is the kind of app that React was designed for and it will allow us to scale up with grace.

[mmmavis]

Before we start doing any improvement work, I think it's essential to find out what the real use cases are. Is this just gonna be MozFest use only? Or do we plan to use it for other MLN related events as well. Scale / specs / type of the events vary a lot so I think it would be nearly impossible to design a one size fits all event app. 😁

[xmatthewx]

It could be used for Mozfest and Hive Chicago buzz, but also distributed events like Science's Global Sprint or even MakerParty (depending on what they plan). The IoT hub is also trying to figure out how to manage events as it grows. The time blocks, location, categories, and tags create a lot of flexibility. It'd require some UX redesign, but the data model should remain the same.

A feature like integrated documentation, gives the app enough value to justify continued use.

Whether or not we invest in it though, depends a lot on how much time and energy it requires to bring the app to the next level. These estimates will help us figure that out.

[xmatthewx]

@gvn – data is managed in a spreadsheet to give a handful of people easy access to make updates. Validation is obviously an issue. Original input could be done via a form, or get extracted from Github (as it was done for Mozfest).

Spreadsheet has a table for Location values and Timeblock values. These then become options in the Session table, but they are not tied together. If you update a Timeblock, you have to do a find/replace to update the corresponding sessions. << That is a big pain point. I'd estimate it ate 2 hours in prep for London. So... while it's a pain, a CMS will take a lot more time to build.

The second pain point – some staff get nervous about adding a row and setting a unique ID. This could be solved with use of Google forms to initiate a new session and a wee bit of training.

Google forms allows a user to save a link to edit their submission later. I wonder if we could write a script that would allow an admin to look up a session and then edit the info in Google form. This would greatly reduce risk of errors. It might be a good halfway solution if Django seems like too big of a lift.

[xmatthewx]

notes: http://etherpad.io/event-app-estimating

[xmatthewx]

cc @kristinashu