The idea of Emojinate came to me like most ideas; out of sheer boredom. In 2015, I was working as a front-end web-developer for a boutique creative agency in Washington, D.C. Several of us had been kicking around ideas for web projects on Slack, and the idea of randomly generating emoji popped into my head. From where? Who can say?

A New Beginning

Emojinate was originally built back in 2015 as a web application. It was submitted to Product Hunt where Ryan Hoover said “I’ve seen many emoji products amd this is one of my favorites”. It got enough traction that Mashable wrote about it, calling it “kind of like Mad Libs, but for Emoji”. A a couple teachers in Australia sent emails saying they were using it in their grade-school classes as an educational tool! Cool stuff!

But life moves on. Other projects came and went. Costs increased. Emojinate was eventually shut down.

Now, almost a decade later, Emojinate has been rebuilt into a more refined mobile application; the sharing and voting systems have been removed to provide a streamlined focus on the writing experience. Removing these systems also allow Emojinate to be a truly offline application, as none of your data exists outside of the phone.

Emojinate is now available on both Play Store and the App Store.. It’s also open source on GitHub so feel free to build your own version (just stick to the licensing found in the repo, wouldya?)

From Web To Mobile

The initial web application was built using Meteor, a JavaScript framework that offers real-time updates over web-sockets. At the time, Emojinate allowed users publish their stories which could then be upvoted in real-time. Seeing votes go up and stories get published without having to refresh a web-page provided a neat user-experience, and Meteor provided that with very little setup.

Emojinate has now been redesigned to be more of an educational / productivity tool. The sharing and voting systems were determined to be more of a distraction than benefit. Removing these systems meant there was no longer a need for a hosted database, meaning Emojinate could exist without any costs for as long as the app stores exist (and the developer license gets paid!). This also meant that Meteor was probably not the best tool for the job.

As a web-developer with 8+ years of React development, it made sense to use React Native as the framework to rebuild Emojinate. I chose the Expo platform to handle the development and production builds as well as handle the screen routing with Expo Router.

The application data sits inside of a local SQLite database on the native device. Its never sent anywhere, and its very minimal; just two tables. Kysely is used to provide type-safe SQL queries.

Improving The Experience

In order to improve the experience of creating an idea out of the emoji, some improvements to the user interface were made:

• Sharing and voting elements were removed, reducing clutter and distraction
• Settings screen was added allowing users to:
  • Adjust the number of emoji from 3 to 30 (for you novelists)
  • Select which categories of emoji are included
• Refresh Emoji by performing a “pull-to-refresh” gesture on the string

For more technical details, read my blog post about rebuilding Emojinate.

Design assets