The Gulls Link Project

Here at Elegant Seagulls our team is split between our Marquette, MI office and various other locations across the United States making Slack our communication lifeline. In fact, we have sent over 22k messages in the last 30 days alone amongst just the 11 of us. Out of those 22k messages are links to websites that we have shared either as inspiration for design work, useful programming tricks, or because the website just plain looked amazing.

As you might imagine with this volume of messages, it has been very easy to lose track of an awesome inspirational link simply because no one wants to scroll that far back in our Slack message history. A few months ago is when my colleague Brett came up with an idea to consolidate all shared links into one, easy to use and searchable location — thus starting The Gulls Link Project.

While brainstorming ideas for what language to program the project in, as well as what features to add, we agreed that we would utilize a variety of different libraries and third party tools that we have used in previous client projects.

Our initial list looked like this:

• React (front end) using NextJS framework
• Microlink API
• AirTable (data storage)
• Algolia (search)
• Slack (slash commands)
• Express

We chose AirTable because it would be easy to manage the data instead of building a front-end admin panel. Our initial prototype proved that the data we wished to store would not play well with AirTable and moved on to the document-oriented database program, MongoDB. Both our current front-end site and Mongo server are on a DigitalOcean droplet.

The Prototype

Sharing links should be easy and is why we opted for the simple Slack slash command. To share a link you could type the following command in any channel or direct message:

Slack then would send a POST object to our API to start the sharing process.

First and foremost we would run the URL provided through the Microlink API to retrieve the following metadata:

site_title, site_image, site_description

and return an error if the site didn’t exist or a majority of the metadata was missing.

Next, we would utilize the Slack API to get the sharers full name and check if the link wasn’t a duplicate. If we reached this point, the link (url, metadata, sharer’s name, and tags) would be saved and indexed to Algolia. To take full advantage of Algolia and future proof for a search feature, we added a “click count” to each shared link in Algolia (more on this later).

The links would then be displayed on our front-end site using a card layout. The cards load 12 at a time in a infinity scroll style using a neat pagination component Brett wrote.

The component calls our API’s data endpoint when the user hits a certain waypoint and appends it to the current links.

On the front-end you could click a tag to filter the links as well. Filtering was done via a separate API endpoint that pulled the data directly from Algolia. This allows us to sort the links by tag and popularity using the “click count” I mentioned earlier.

The Concerns

Our #1 one concern brought up by our creative director, Ben Johnson, was something that happens to us all quite often, and especially on the cellphone: misspelled words.

This is where Slack’s interactive messages came into play. We added Atom’s spell-checker module to verify the tags accompanied with each share and upon any misspelled word returned to the Slack user the following interactive message:

You could cancel, use anyway, or select a spelling correction.

Our next concern was the Slack slash command. How easy is it? Would our co-workers remember the command (and how to separate the arguments) quick enough to actually want to use it?

We opted for the Slack dialog message instead, making the process a more concise and easier work flow (peep the share in our #inspire Slack channel below).

Lastly, the meta image concern. Originally we were storing the URL to the image in our Mongo database and calling on it front-end. This proposed the question of “what happens when that site changes or deletes their meta image?”. We also didn’t want to hot link.

We had two options here: 1) store the image on our server, or 2) resize, optimize, and upload to AWS. We chose option #2 so we could utilize another third party service. This also helped speed up page load times.

V2 & The Future

Version 2 rolled out with all the features talked about in the above concerns as well as the much needed search functionality.

We also wanted to tie a shared link to a co-worker and so added the “{user} shared” to the Slack share message. Front-end we created a new page for all the user’s shares.

Because errors do happen, we setup a error message system that sends the error (along with assigned priority levels) to our dedicated “Gulls Link” slack channel.

After the project was put in use, we noticed sometimes the metadata returned by the Microlink API isn’t complete and so we have to manually update fields in the database. To keep Algolia indexed properly, we created a /reindex slash command that takes all the links in the database and reindexes Algolia with any changed data. Long term this will be changed to a batched queueing system.

For the future we will be updating how the links are searched and retrieved from Algolia. I mentioned the “click count”, but currently it is not in use. Our plan is to increment the count every time a user clicks on a link, thus increasing its “popularity” ranking. We also started indexing tags into a separate Algolia index and will track clicks on them as well.

TL;DR

We created a simple method to share inspirational links in our Slack channels to store for further access on a front-end site.