Table of Contents

Date

01 Sep 2016

Attendees

Actions items from previous meeting

• Send screenshots of demo app (bot+renderer) to Matthew Gardner @ Blackrock - Former user (Deleted)
• Review internally with Blackrock team re interest in early access to renderer framework - Matthew Gardner
• Review internally with FactSet prioritisation folks re interest in developing a custom composer (perhaps starting as a POC) - Johan Sandersson

Agenda

Meeting notes

• Roll call
• Bruce: Update from LLC on complex objects:
  • We've talked at lengths about a 2 party demonstration around a single object.  No further progress - nothing from Markit on the integration they were going to do, and no one else has stepped forward to implement a custom renderer.  We have the FactSet bot that enhances an object.
  • We do have progress on a JIRA integration however:
    • <Screen-share shown, demonstrating sample object structure for a JIRA ticket>:
      
    • Moving forward with implementing the infrastructure to support this.
    • Symphony is hosting an Innovate event in early October, and we hope to demonstrate something at that event.  The aspiration is that all of the necessary code change to make this work in production will be included in Sprint 42 and the target date (not a committed date) is that that would arrive in production around the middle of October. In the October timeframe we'll be in a position to exchange structured objects.
    • In terms of moving forward with financial objects, the question is which participants would be interested in participating in a cross-organisational boundary collaboration.  Does anyone have anything they'd like to say about that?
  • Emmett: we'll set up a call to discuss this in more detail next week.  For one of our fixed-income analytics platforms we'd like to look at a POC to pass some of that content, leveraging the message format and looking at how we render that.  We've shared some emails, and it's something that team would like to look at.  We'd also like one of the engineers from that team to join this WG.
    • Bruce: what's the user story / business use case?
    • Emmett: we have a fixed income analytics platform that has it's own internal chat capability that's used to pass analytics and charts to users, both internal and external clients.  This team has a lot of expertise around passing content, on that internal chat platform.  Seems like a natural extension to pass that content to an external client in the not too distant future via Symphony.
    • Bruce: ok so we're talking about a conversation between a Credit-Suisse employee and a Credit-Suisse customer, and both users would have a Credit-Suisse app on their Symphony UI?
    • Emmett: yep
    • Bruce: great.  Looking forward to moving that forward.
    • Bruce: if anyone else is interested in getting a demonstration going, along the lines of the use case Emmett described, or better, in my view, something where the sender & recipient have two different apps - that really demonstrates the interworking - it would be great to demonstrate that.  If anyone is in a position to demonstrate that, please get in touch with me, either privately / bilaterally, or in the open in the context of the WG.  Open would be preferred, but if privacy is important I'm happy to accommodate that.  We have a non-production environment available where we can do this today, and we'd be happy to share that with folks who are interested.
    • Johan: From the FactSet side we'd be happy to work on our bot to add more information that other folks need.  More than happy to engage.
• AOB:
  • Johan: have you had any further thoughts on what would happen with the message that's being sent with an entity in the post-popup or signaling fabric?
    • Bruce: in the first instance, you can expect that the web UI will be able to support renderers, and in all other contexts the messages will be treated as regular MessageML.  I don't expect that in the initial release the mobile client will support renderers.  I would expect it would just be MessageML.  Obviously as we go on there's no reason in those other contexts we can't do other things.  We have in mind that there could be multiple dimensions that an app may want to render to (thumbnail vs fullscreen, for example), and in that context it would make complete sense to have support in the post-popup.
    • Johan: I was also thinking about the search capability.  We may want to search things coming from the renderer.
      • Bruce: general point is that as I have said before we have a very long backlog and limited bandwidth of development, and at each sprint there's a prioritisation process.  We're a customer-driven organisation so we react to the requirements customers give us.  My expectation is that once we put something into production that will generate more demand from customers - once customers are saying things like "it's great I can see a JIRA ticket, but I want to see it in the popup, etc." then that will help with prioritisation.
      • Bruce: with search, it's slightly complicated because of encryption.  We generate encrypted tokens for the search to operate over, and you would not out-of-the-box be able to do the kind of search you would want to e.g. "show me all messages about JIRA tickets in the open state".  The current search doesn't provide enough capabilities to do that kind of search, but they're all obviously things that would be great to have in the product.
      • Johan: no worries - just interested in general thoughts.
      • Bruce: yes renderer should be able to render into multiple contexts.  Wherever you're seeing an object, a renderer should be able to provide the richest possible experience.
• Action items review:
  • Bruce sent the screenshots to Matt Gardner
  • Matt Gardner isn't present, and Bruce didn't receive a private update from him - this one remains open
  • Regarding custom composer @ FactSet:
    • Bruce: the work in sprint 42 does not include composition - we're only providing rendering support.  The only way to extend these objects is via API, and specifically for the JIRA use case (which is driving this), this isn't a limitation - these messages are injected by a JIRA webhook.  It's academic whether we have any current needs for a composer.  Johan?
    • Johan: our main compose use case is that the user is in a FactSet product, and the message will be sent by a back-end API, so we're good with the current functionality.  We are willing & interested in looking at the composer framework, but it's not a priority - we'd prefer to focus on the other items first.  When you [ed: Symphony LLC] have some bandwidth to start thinking about composers, we'd be happy to participate.
    • Bruce: without the requirement, it's hard to prioritise the engineering work to enable composition.  I think the reality is that once we start to see some things working, it will fire people's imagination.  Let's mark this action closed.
• Bruce: there haven't been a lot of updates in recent meetings - is the frequency of these meetings right?  Perhaps if things haven't picked up in a few more meetings we can reconsider the cadence?

Action items

<no new action items this week>