It was all going smooth. And then this happened.
Google Summer of Code is a 10 week global open-source program for students.
It has been in the running for 16 years! In case you're new here, I recommend checking out my first blog in this series.
Bonus: While it's been a smooth ride, there's one thing that happened that made all of us scratch our heads. Hang tight!
Here’s a recap of the features I built in Coding Phase 1:
- Improved Response Visualizations: Previously the Poll App displayed simple grayscale reponses. This was dull and boring. Moreover, there wasn’t a way to distinguish winners and total votes cast. Here’s how we changed this.
- Mixed Visibility Mode: The Poll App allowed only two modes — open where voter identities were visible and closed where they were not. What about something in the middle? Introducing Mixed Visibility Mode.
- Word Clouds: Bar graphs are simple. Bar graphs do the job. And bar graphs are just “okay”. Word Clouds are lit! Visualize responses in word clouds here.
While planning my timeline within my GSoC proposal, my strategy was to take up easier features at the start. This would allow me to have more time to explore the Rocket.Chat Apps Engine while still shipping out features consistently.
Coding Phase 1 was a success. It was time to bring out the big guns.
Until now the Poll App only allowed the Poll Creator to add options. Once they posted the poll no changes to the options could be made. What if users have an idea not covered within the options?
Now if you’ve ever used Facebook polls within groups you might’ve noticed a subtle feature. All group members can add options after the poll is posted. Allowing group members to vote not only involves the community better but also evokes ideas and opinions from the entire group, not just limited to the poll creator.
We decided to give the Poll Creator an option — allow or disallow users from adding choices. Here’s how the poll message looks when the poll creator allowed users to add options.
See that Add option button? That becomes available to all the users within the room. Let’s click on it and see what happens.
It opens up a modal that allows users to add an option. On clicking Add the option gets added to the existing Poll message with both vote quantity and voters set to 0.
The Poll message updates for everyone within the room with the new option. Yay!
The PR for this feature along with a video demo can be found here.
Adding options to Poll was kind of repetitive. Especially if you’re doing a 1 to 10 poll typing 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 was what you had to do (okay I just did that). I thought:
The Poll App only had two modes — Mutliple Choice and Single Choice. That. Is. It. What if I could add more modes that would auto-fill all the options?
Over the next few days (and nights) I added the following modes:
Overrated/Underrated Polls (Options: Overrated, Appropriately Rated, Never Tried, Underrated)
1-to-5 Polls (Options: 1–5)
1-to-10 Polls (Options: 1–10)
Agree/Disagree Polls (Options: Agree/Disagree)
Emoji Rank Polls (Options: Watch the demo! 🚀)
The best part is that the modal is completely interactive. This means that as soon as you select one of the additional poll modes the Options fields automatically disappear. Not to mention that Additional Poll modes support Mixed Visibility. How cool is that?
To view other additional poll modes, checkout the PR for Additional Poll Modes.
If you’ve attempted an online quiz before. Well this it!
Introducing Live Polls. To be honest about it, the effort and thought that went into this feature qualifies it as a mini-GSoC project itself.
Live Polls are an array of regular Polls with additional functionality of having a time limit to vote upon after which the current Poll ends and the next one is posted. Poll creators can also click on a new “Next Poll” button to trigger a pre-scheduled finish of the current Poll.
The scheduling magic happens using the Scheduler API. Every time a Poll within a Live Poll is posted, a processor is scheduled to end it after the user-specified time to vote.
Live Polls are triggered using the command
/poll live <number of polls>.
An excellent use-case for the Live Poll are stand-up and retro meetings. An additional use case is by teachers wanting to conduct timed quizzes on Rocket.Chat.
My mentor suggested that in addition to having the Polls timed, the user should also be able to create a Live Poll at a time and retrieve or play it at a later time.
I created a subcommand
/poll live save <number of polls>. It saves all the Poll states in the Poll App’s persistent storage. A unique Live Poll ID is provided to the user.
The created Live Poll can be subsequently retrieved using the
/poll live load <Live Poll ID>. In case the user enters a wrong or non-existent Live Poll ID they’re shown a notification. On executing the above command with a correct Poll ID the Live Poll can be retrieved at any time.
Speaking of teachers using Rocket.Chat for exams, the Live Poll Late Retrieval features proves an excellent tool for teachers to create quizzes even weeks before and then schedule the quiz on D-day with ease. All this while having control over the time limit to answer each question.
The PR for Live Poll and Live Poll Late Retrieval features can be found here.
While this API works well when your Rocket.Chat server is connected to the Internet, a lot of organizations (my mentors org Credit Suisse, US Defence) use Rocket.Chat in an isolated environment. That means no Internet access. What then?
We thought why not host Quickchart locally using their open-sourced codebase? But…Wait-for-it. Quickchart has all APIs except wordcloud open-sourced. Ha!
Another problem was rate-limits. Quickchart has a rate-limit of
60 requests per minute per IP on their free tier. This means it is totally unsuitable for rooms with more than 60 members. My mentor Murtaza shared a perfect explaination. Quoting him from the PR comment:
if all the users are accessing the room from a different network then the limit is fair enough, however if all the users are on a private network behind a (Router + NAT) then although each of them will have a different local IP, but the same public IP — In that case if there is a single room with more than 60 users, they all would be identified as a single entity/IP and the rate limit will come into picture.
I thought, why can’t I build my own API and remove Quickchart out of the equation altogether? And:
Within a few days I had our own in-house developed Wordcloud API. The best thing about it? It offered more customizations than Quickchart Enterprise, worked without an Internet connection, had practically no rate-limits and was free.
I have open-sourced the word-cloud API here. Feel free to use it in your own projects or raise a PR for further customizations.
My API also factors in the number of votes cast per option. For example, if English received twice as many votes as Hindi on a Poll then “English” would appear twice as big as “Hindi” within the word-cloud.
I provided the repository link within the Poll App settings page for users to self-host the API. This solved our Wordcloud frenzy forever.
Have you faced an unexpected problem while coding a project? How did you solve it? Could you find a solution or did you just leave it for the future? Let me know in the comments section below!
In case you haven’t checked out my previous blog about GSoC First Evaluations, go check it out now —it covers in detail how a GSoC student is evaluated.
Like what I do? Help me pull my next all-nighter. Consider buying me a coffee.🥤