New Label, "Use Cases"?

[neurobe]

Great job with this guys.
With all the enhancements proposed and recent addition of video, got me thinking that the most precious commodity was now screen real-estate.Todo list, youtube, maps, calendar and also the question of Roles. Quite a handful.
We have the notion of Rocket.Chat as meteor plugin, but it seems to me that a more valuable concept would be to consider Rocket.Chat "payloads" (Rockets have payloads!). Payloads would be a sort of a super Plug-in whose purpose is not to augment Pocket.Chat, but to use the Rocket.Chat infrastructure to implement business solutions of which collaborative working is a secondary part.
Firms adopting Rocket.Chat in this way get locked in and need expensive support, get my drift?, rather than either being just another chat app, or worse, just another meteor package!
And?
Well, I think some more thought on architecture here. What resources payloads and plugins can use. Like the flex side panels (two please) and center window. My thought is that payloads should be able to push the messages off the center window (sacriledge!) to the side panel, and maybe the side panels can be tabbed to allow multi-use??
$0.02.
PS> My use case is Instrumentation for which I have an meteor app in production. I could use ancilliary chat functionality. Many other possibilities come to mind. Education, gaming of course, finance etc etc etc ...

[jmatsushita]

Interested in following the discussion about architecture. From #346 the main benefit is to have seamless integration with Rocket.Apps (Payloads is cool - https://xkcd.com/1133/) and I agree that avoiding lock in would mean to allow other apps to deeply integrate and therefore having well defined behavior within the chat interface.

With Glip, the key elements of this integration from the user experience side are:

• the Add button to create a "Rocket.App" item. (i.e. Add Task or Add File, or Start Screenshare, or...)
• the rendering of the item itself in the Chat stream (including contextual actions like Convert to Task, or Move)
• The right hand side "Shelf", where Rocket.Apps can render their items (Where Slack "Pins" items, but where Glip automatically register any integrated App item. I really like the Task Sections for Glip tasks for instance, which help create a project structure, which is missing for instance in Files which can't be tagged or grouped).
• The left hand side panel which allows to get the "Cross Channels" view for an App. i.e. All the Tasks, or all the Files...

In a small modules way, create a Rocket.Tasks app and a Rocket.Files app, might help create a reference implementation which other Meteor, or even non-meteor apps could follow to integrate deeply with Rocket.Chat.

Own 2 cents.

Jun
PS: Don't get the title of this issue :)

[neurobe]

Re: "don't get the title of this issue" (ie 'Use cases')
A tag of "use cases" allows folks to indicate how they would like to use Rocket.Chat. This can help inform the team making the architectural decisions.
A classic use case would be gaming, many of which have chat capability as a secondary function. Gaming then becomes one of several payload classes.

My comment on a (very brief) perusal of Glip is that its premise is that the communication channel is the focus for getting things done, ie for the business process. That's fine as far as it goes, (again highlighting the need for understanding use cases), but I would argue that a much larger set of potential apps is represented by the business processes that have comms channels as an occasional (but important) need - for when thing go wrong, if you like.
And why not use a separate app for this occasional need? Well you can or course, however integrating it into the main business app allows for a seamless front of house. I for one, place high value on that.

[jmatsushita]

@neurobe Got it. You're requesting to add a github issue label.

Yes you're right about the communication stream becomes the main place where business process actions can be created, updated, listed, etc... That's a specific use case indeed, and one were chat becomes the main business app.

Maybe I'm misunderstanding "business processes that have comms channels as an occasional (but important) need", but isn't this "simply" about allowing your business apps to have an integration (incoming hook) allowing them to post into the chat? We use this currently with Pager Duty integration with Slack for instance to notify us if a service goes down, or various github activity in other channels.

[Sing-Li]

Closing this, original content of ticket, except for the github issue label, implemented by #292 and RocketChat/Rocket.Chat.Ops#1.

Please create new ticket if something else is missing from original.

[engelgabriel]

HI! First of all, thanks! :) and sorry for the late reply.

Your thinking is very aligned with what we are planning.

Have you guys seen this?

http://www.fastcompany.com/3051046/elasticity/in-the-battle-against-startup-darling-slack-hipchat-throws-a-punch