Skip to content

Add ultra basic support for the SubMessage-based polls feature #3205

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
timabbott opened this issue Dec 10, 2018 · 18 comments
Closed

Add ultra basic support for the SubMessage-based polls feature #3205

timabbott opened this issue Dec 10, 2018 · 18 comments
Assignees
Labels
P1 high-priority webapp parity Features that exist in the webapp that we need to port to mobile. We aren't aiming for full parity. @zulip/shared Good spots to share code with the webapp

Comments

@timabbott
Copy link
Member

Zulip has an experimental "polls" feature, which uses the special SubMessage table in the database for its storage (https://zulip.readthedocs.io/en/latest/subsystems/widgets.html#poll-todo-lists-and-games). You can create one on web by sending a message with /poll as the content. The UI is currently pretty janky; we have a separate issue on web (zulip/zulip#11010) for improving that.

The polls feature has been getting a decent amount of interest from folks who want it in Zulip Cloud, so we need to take steps to make them display in a not-totally broken fashion on mobile.

Structurally, the widgets / submessage feature has some important properties for mobile: The API only sends and receives JSON, via submessage events (or the .submessage field on a message object fetched from the server). The client is completely responsible (and empowered) to render the data as it pleases, as well as enabling UI.

In terms of staging, I think there's a few levels of mobile-side support for this widget (or any other widget for that matter, though the others are more prototypes and don't have a lot of demand so we shouldn't worry about them).

  • First, mobile can literally look for messages with a poll submessage/widget entry as the most immediate hack to detect and say "This message is a poll, which is not supported on mobile yet.".
  • From there, it can process the data from those events properly, and do a basically textual rendering of the poll results, so you can at least understand the message.
  • And then from there we could work on rendering the results and turning on UI to actually participate in the poll from your device.
@borisyankov borisyankov self-assigned this Dec 15, 2018
borisyankov added a commit to borisyankov/zulip-mobile that referenced this issue Dec 15, 2018
This is the beginning of implementing zulip#3205

We currently do not do anything with the received data, but
acknowledge the existance of the `submessages` property in the
`Message` type.
borisyankov added a commit to borisyankov/zulip-mobile that referenced this issue Dec 15, 2018
This is the beginning of implementing zulip#3205

We currently do not do anything with the received data, but
acknowledge the existance of the `submessages` property in the
`Message` type.
@borisyankov
Copy link
Contributor

@timabbott To clarify some aspects that seem to be true:

  • we can differentiate between normal messages and widgets by submessages.length > 0 ?
  • msg_type of a submessage can be only widget currently?
  • submessages can only be added to, no update/delete?
  • content is always intended to be JSON string?

@timabbott
Copy link
Member Author

we can differentiate between normal messages and widgets by submessages.length > 0 ?

yes.

msg_type of a submessage can be only widget currently?

yes; the client can ignore any other submessage until if/when we change that.

submessages can only be added to, no update/delete?

currently, yes, though that could change in the future.

content is always intended to be JSON string?

yes.

borisyankov added a commit to borisyankov/zulip-mobile that referenced this issue Dec 18, 2018
This is the beginning of implementing zulip#3205

We currently do not do anything with the received data, but
acknowledge the existance of the `submessages` property in the
`Message` type.
borisyankov added a commit to borisyankov/zulip-mobile that referenced this issue Dec 20, 2018
This is the beginning of implementing zulip#3205

We currently do not do anything with the received data, but
acknowledge the existance of the `submessages` property in the
`Message` type.
borisyankov added a commit to borisyankov/zulip-mobile that referenced this issue Dec 21, 2018
This is the beginning of implementing zulip#3205

We currently do not do anything with the received data, but
acknowledge the existance of the `submessages` property in the
`Message` type.
@timabbott
Copy link
Member Author

@borisyankov @gnprice how close are we to merging this? We've been getting complaints from users about the frankly poor situation that polls are invisible in the mobile apps.

@borisyankov
Copy link
Contributor

@timabbott we have the #3220 ready to merge.
It does support the processing, understanding and storage of submessages.

It visualizes a placeholder that says we do not support 'widgets' yet though.
That is better than just missing the message but not by much.

I have started the next phase in a PR that is very WIP and far from done.

To clarify where I think the effort in implementing it fully lies:

  • recognizing and processing the general submessage data - 25% (done)
  • recognizing and visualizing all widgets - 50% (10-20% done)
  • interacting with the widgets - 25%

When talking with Rishi about the widgets (not directly this PR) he said we consider it less of a priority, maybe compared to the effort to implement. Thus I have been a bit unclear if we should push on this or other issues.

@timabbott
Copy link
Member Author

I chatted with Rishi about this. I think this is a P1 issue, specifically for just the /poll widget. There's hardly any other widgets today and no other widgets are likely to be important in the next 6+ months, and new widgets we add may involve adding new APIs for them. So while we generally aim to build things generally, hacking together a solution that covers /poll by e.g. copying some code from the webapp is totally reasonable for this feature.

So we should prioritize improvements beyond "/poll isn't supported on mobile" (maybe with a link to open that page in the webapp) to the extent that finishing the rest of /poll is easier than finishing out other P1 issues (of which I feel like we have a ton with an open PR).

@gnprice
Copy link
Member

gnprice commented May 20, 2019

Small update: I just merged #3220 , so we'll now show

  • the /poll Where shall we go for lunch? line
  • and also a big grayed-out box saying "Interactive message -- To use, open on web or desktop".

(The main part of this issue remains open.)

@gnprice gnprice assigned ishammahajan and unassigned borisyankov Jun 20, 2019
ishammahajan added a commit to ishammahajan/zulip-mobile that referenced this issue Jul 13, 2019
Widgets support has been in great demand from users (as it was
implemented in the webapp first, and we haven't supported its
display since support was added to the API). You will also see a
`Poll Widget` marker in the bottom right of the box which shows
it.

This commit adds the `poll` widget support, and modularises widgets
so it will be easier to add other widgets if required. It uses the
newly introduced (c174a0) `getOwnUser` to get the `user_id` of the
current user in order to check it against the `key` provided in
submessages (which are only widgets for now) of type `vote`, to see
if the current user has voted on the `option` in that `poll`.

Styling has been duplicated from and merged with `.reaction`, while
the borders of the `.widget` class has been changed to match the
`.static-timestamp` class.

Fixes zulip#3205.
ishammahajan added a commit to ishammahajan/zulip-mobile that referenced this issue Jul 16, 2019
Widgets support has been in great demand from users (as it was
implemented in the webapp first, and we haven't supported its
display since support was added to the API). You will also see a
`Poll Widget` marker in the bottom right of the box which shows
it.

This commit adds the `poll` widget support, and modularises widgets
so it will be easier to add other widgets if required. It uses the
newly introduced (c174a0) `getOwnUser` to get the `user_id` of the
current user in order to check it against the `key` provided in
submessages (which are only widgets for now) of type `vote`, to see
if the current user has voted on the `option` in that `poll`.

Styling has been duplicated from and merged with `.reaction`, while
the borders of the `.widget` class has been changed to match the
`.static-timestamp` class.

Fixes zulip#3205.
ishammahajan added a commit to ishammahajan/zulip-mobile that referenced this issue Jul 16, 2019
Widgets support has been in great demand from users (as it was
implemented in the webapp first, and we haven't supported its
display since support was added to the API). You will also see a
`Poll Widget` marker in the bottom right of the box which shows
it.

This commit adds the `poll` widget support, and modularises widgets
so it will be easier to add other widgets if required. It uses the
newly introduced (c174a0) `getOwnUser` to get the `user_id` of the
current user in order to check it against the `key` provided in
submessages (which are only widgets for now) of type `vote`, to see
if the current user has voted on the `option` in that `poll`.

Styling has been duplicated from and merged with `.reaction`, while
the borders of the `.widget` class has been changed to match the
`.static-timestamp` class.

Fixes zulip#3205.
ishammahajan added a commit to ishammahajan/zulip-mobile that referenced this issue Jul 16, 2019
Widgets support has been in great demand from users (as it was
implemented in the webapp first, and we haven't supported its
display since support was added to the API). You will also see a
`Poll Widget` marker in the bottom right of the box which shows
it.

This commit adds the `poll` widget support, and modularises widgets
so it will be easier to add other widgets if required. It uses the
newly introduced (c174a0) `getOwnUser` to get the `user_id` of the
current user in order to check it against the `key` provided in
submessages (which are only widgets for now) of type `vote`, to see
if the current user has voted on the `option` in that `poll`.

Styling has been duplicated from and merged with `.reaction`, while
the borders of the `.widget` class has been changed to match the
`.static-timestamp` class.

Fixes zulip#3205.
ishammahajan added a commit to ishammahajan/zulip-mobile that referenced this issue Jul 16, 2019
Widgets support has been in great demand from users (as it was
implemented in the webapp first, and we haven't supported its
display since support was added to the API). You will also see a
`Poll Widget` marker in the bottom right of the box which shows
it.

This commit adds the `poll` widget support, and modularises widgets
so it will be easier to add other widgets if required. It uses the
newly introduced (c174a0) `getOwnUser` to get the `user_id` of the
current user in order to check it against the `key` provided in
submessages (which are only widgets for now) of type `vote`, to see
if the current user has voted on the `option` in that `poll`.

Styling has been duplicated from and merged with `.reaction`, while
the borders of the `.widget` class has been changed to match the
`.static-timestamp` class.

Fixes zulip#3205.
ishammahajan added a commit to ishammahajan/zulip-mobile that referenced this issue Jul 17, 2019
Widgets support has been in great demand from users (as it was
implemented in the webapp first, and we haven't supported its
display since support was added to the API). You will also see a
`Poll Widget` marker in the bottom right of the box which shows
it.

This commit adds the `poll` widget support, and modularises widgets
so it will be easier to add other widgets if required. It uses the
newly introduced (c174a0) `getOwnUser` to get the `user_id` of the
current user in order to check it against the `key` provided in
submessages (which are only widgets for now) of type `vote`, to see
if the current user has voted on the `option` in that `poll`.

Styling has been duplicated from and merged with `.reaction`, while
the borders of the `.widget` class has been changed to match the
`.static-timestamp` class.

Fixes zulip#3205.
ishammahajan added a commit to ishammahajan/zulip-mobile that referenced this issue Jul 17, 2019
Widgets support has been in great demand from users (as it was
implemented in the webapp first, and we haven't supported its
display since support was added to the API). You will also see a
`Poll Widget` marker in the bottom right of the box which shows
it.

This commit adds the `poll` widget support, and modularises widgets
so it will be easier to add other widgets if required. It uses the
newly introduced (c174a0) `getOwnUser` to get the `user_id` of the
current user in order to check it against the `key` provided in
submessages (which are only widgets for now) of type `vote`, to see
if the current user has voted on the `option` in that `poll`.

Styling has been duplicated from and merged with `.reaction`, while
the borders of the `.widget` class has been changed to match the
`.static-timestamp` class.

Fixes zulip#3205.
ishammahajan added a commit to ishammahajan/zulip-mobile that referenced this issue Aug 3, 2019
Widgets support has been in great demand from users (as it was
implemented in the webapp first, and we haven't supported its
display since support was added to the API). You will also see a
`Poll Widget` marker in the bottom right of the box which shows
it.

This commit adds the `poll` widget support, and modularises widgets
so it will be easier to add other widgets if required. It uses the
newly introduced (5046781) `getOwnUser` to get the `user_id` of the
current user in order to check it against the `key` provided in
submessages (which are only widgets for now) of type `vote`, to see
if the current user has voted on the `option` in that `poll`.

Styling has been duplicated from and merged with `.reaction`, while
the borders of the `.widget` class has been changed to match the
`.static-timestamp` class.

Fixes zulip#3205.
ishammahajan added a commit to ishammahajan/zulip-mobile that referenced this issue Aug 3, 2019
Widgets support has been in great demand from users (as it was
implemented in the webapp first, and we haven't supported its
display since support was added to the API). You will also see a
`Poll Widget` marker in the bottom right of the box which shows it.

This commit adds the `poll` widget support, and modularises widgets
so it will be easier to add other widgets if required. It uses the
newly introduced (5046781) `getOwnUser` to get the `user_id` of
the current user in order to check it against the `key` provided in
submessages (which are only widgets for now) of type `vote`, to see
if the current user has voted on the `option` in that `poll`.

Styling has been duplicated from and merged with `.reaction`, while
the borders of the `.widget` class has been changed to match the
`.static-timestamp` class.

Fixes zulip#3205.
@Mnaukal
Copy link

Mnaukal commented Oct 21, 2019

Any update on polls in mobile app? I am still getting "Interactive message -- To use, open on web or desktop".

@gnprice
Copy link
Member

gnprice commented Oct 21, 2019

@Mnaukal This is the issue tracking that feature -- so the status is what you see here. 🙂 There's work in #3554 toward an implementation, but it's not yet complete.

WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jun 4, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jun 4, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jun 7, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jun 7, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jun 7, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jun 7, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jun 8, 2021
gnprice pushed a commit to WesleyAC/zulip-mobile that referenced this issue Jun 9, 2021
gnprice pushed a commit to WesleyAC/zulip-mobile that referenced this issue Jun 9, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jun 10, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jun 10, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jun 15, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jun 15, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jun 15, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jun 15, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jun 15, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jun 15, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jun 17, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jun 17, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jul 2, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jul 2, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jul 2, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jul 2, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jul 7, 2021
WesleyAC added a commit to WesleyAC/zulip-mobile that referenced this issue Jul 7, 2021
gnprice pushed a commit to WesleyAC/zulip-mobile that referenced this issue Jul 7, 2021
gnprice pushed a commit to WesleyAC/zulip-mobile that referenced this issue Jul 7, 2021
@WesleyAC
Copy link
Contributor

WesleyAC commented Jul 7, 2021

We've just merged initial support for polls in #4704! It should land in the app whenever we cut a new release, likely in the next couple weeks.

There's still some more work to do, which is tracked in #4881, #4882, and #4883.

@WesleyAC WesleyAC closed this as completed Jul 7, 2021
@cmprmsd
Copy link

cmprmsd commented Jul 7, 2021

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P1 high-priority webapp parity Features that exist in the webapp that we need to port to mobile. We aren't aiming for full parity. @zulip/shared Good spots to share code with the webapp
Projects
None yet
Development

Successfully merging a pull request may close this issue.