Add Side Tabs in Meeting Guide App To Handle Multiple Sources

[MinnesotaSwanny]

I would like to propose that for the next major release of the Meeting Guide App, we re-think how we resolve multiple feeds for the same instance of a meeting for the same google geocode. The current architecture supports, I believe, one entity’s feed being awarded the google geocode for a location as the feeder of choice. I propose that we open that up to all feeders and post up to three different feeds for any given instance of a meeting, each on a different horizontal tab. The three most recently updated would make the cut off, displayed in horizontal tabs based on a point system or random order using a seed. The use case is simply that the end user can flip thru the tabs and choose the version of the listing they want to use. As an added refinement, we could also tweak the API spec to have a bit that indicates whether this instance of a meeting should flow thru to the Meeting Guide App or not so that a feeder could opt to offer some of their listings to the Meeting Guide App, but not necessarily all of them. Why this enhancement? It would go a long way in getting the App Support Team out of the situation of having to adjudicate which entity “wins” the google geocode of a given meeting location when those entities don’t play nice with each other. Thoughts?

[joshreisner]

Thanks for the ideas Alan! I agree that something needs to be done regarding overlaps, and that whatever that is should ease the burden on App Support.

Quick note: we don't make decisions for the app interface (the people who do are reachable through App Support).

But your two proposals are interesting.

Regarding the first, that the app display multiple versions of a listing, I want ask a few more questions:

• what would you do in cases where the listings were essentially identical? Would you still show the multiple-version interface to the user, or would you pick one to show?
• what about the scenario where one entity intentionally deletes a meeting (they think it's no longer there)?
• what about the scenario where the entity provides multiple meetings at the same time at the same location? (this happens more often than you'd think.) would you group them all into a single listing with multiple versions?

My concern about this approach is that it feels like it is offloading the complexity caused by a failure of trusted servants to communicate and get in sync.

We had a meeting about this with the app team recently, and my suggestion (besides, like you, favoring the last updated meeting) was to build a self-service dashboard that trusted servants could use to try to resolve these disputes on the back-end, to spare users the uncertainty. This would, among other things, allow servants to opt their feeds out of being the trusted source for a given address.

The "opt out" checkbox at the plugin and feed level is also an interesting idea. I worry it could end up adding some complexity to the "why is my meeting not appearing?" conversation with App Support, since that's another data point for them to check. Question:

• to achieve the intended effect shouldn't it opt out more than just the current listing, but all meetings at the current address?

[MinnesotaSwanny]

Hi Josh! Great follow-up use cases for my proposal. I am going to flesh this out a bit more and provide more details and answers to your great use cases and maybe come up with a few additional use cases too. I will also put together my take on how the tabs would look in the revised app. I do this for a living, glad to be able to contribute these skills sets to something truly worthwhile! I will respond back to this thread in a day. Thanks again Josh!