- #Stop cursor from going to rocketchat on message how to
- #Stop cursor from going to rocketchat on message android
- #Stop cursor from going to rocketchat on message free
#Stop cursor from going to rocketchat on message android
Our initial version will be Android (IOS and Web to follow).ĭesign question #1: Can we simply add a new attribute (“customResponse” or something) to the message object that is passed through the Rocket.chat server and sent to the Android client? Would this require a modification to the Rocket.chat server or would it simply pass the attribute through to the client? And, would this break IOS and web clients? This bot will send back rich messages to the hubot adapter which will send them to the Rocket.chat server, which will send them to the Rocket.chat client. I’d like to discuss here some aspects of the design to see if we can implement an approach that will align with the upstream Rocket.chat team thinking/approach.įirst, we are using a modified version of hubot-apiai adapter to direct message a bot that is implemented in dialogflow/api.ai. Our requirement is to support a subset (not clear which we need yet) of the following rich messages ( ) as well as persistent menus. The issue for tracking Android support is #1027 in repo.
Our immediate need is Android support but of course we’d like to see the features implemented in web and IOS as well. We have an urgent need to add FB Messenger style rich chatbot messages and plan to do it in our fork but want to make sure our approach is at least somewhat aligned with the overall team vision for this. We gave Zulip (and Mattermost, Element/Matrix, Rocket Chat etc) a try when our company was looking for self hosted alternatives to Slack.Issue #6786 in Rocket.chat repo is an issue covering this general topic. Zulip seemed like technically the most polished product. Smooth and easy get-running experience (Element was the polar opposite).
#Stop cursor from going to rocketchat on message how to
I'd have liked to see a bit bigger font but what ended up being the showstopper was that new users were very confused about how to write in a channel (or stream how they call it). Everything needs to be in a second level "topic". In pretty much every other chat app one can just select a channel on the left and get a text input field where you can write your message. In Zulip though you don't get the text input. You have to either create a completely new topic which new users really don't understand or click on any of the past messages in the stream to create a reply to that topic (but not that specific message). I suppose it works well after you understand the messaging model but it represents such a high initial point of friction that we had to give up on it. Non-technical users had a really hard time and the switch from Slack was not high enough on the priority list to push through with it. scrolls the window all the way down when clicking on a stream scrolls the window down when sending a message allows sending a message by pressing enter doesn't put the cursor in the "topic" input but the actual message input by default always shows the text input no matter if you clicked on a stream or topic Tabbot: if you happen to see this, please please consider some kind of easy-mode which:
You don't need the name of the stream above every message (see ) maybe also some simplification of the UI. I'm convinced with a bit of work to make it easier for new users you'll have a big boost in growth. Thanks for the feedback! It's much appreciated. We are actively working on several ideas in this space. (One of the most important that was released in 4.0 is the redesign of the Reply button to make starting a reply feel like it does in other chat tools). I expect we'll be able to get into a really nice place with a combination of new settings with some mixture of "Easy mode" defaults, design changes, and onboarding adjustments.
It is impossible to hover cursor on the pencil icon of the edited messages, underneath the first message. (We will do this while carefully preserving model/paradigm, in case anyone's worried).
#Stop cursor from going to rocketchat on message free
Feel free to stop by if you want to discuss specifics.įWIW, we regularly hear from large organizations, including some with thousands of nontechnical users, about their having great luck migrating to Zulip. Usually they tell us they did a 30-minute training and then things went smoothly from there, or they didn't and it took a couple weeks for some users to get the hang of it. In the scheme of things, doing a training is a pretty minimal investment to be able to use a better product for hundreds of hours a year.
But of course Zulip would grow a lot faster if nobody worried whether their nontechnical users will thrive on it, so this area is a priority for us.
0 kommentar(er)
