Getting developers up and running with Kafka

The brief was to simply guide the development team to make minor UI updates to support some back-end changes. The front-end was out of date, so I got learning React!

Date

2018 – 2020

My Role

Design and [eventually] Dev

The starter application

With regards to Lesley, the full stack developer from the previous Event Streams project, we'd covered most of user story 2, however, this project explores the "Starting from a sample application..." part of that user story.

User stories

User story 1

Kevin, the Event Streams admin, can deploy Event Streams into ICP (IBM Cloud Private) and be confident it's fully functioning within 15 fully occupied minutes.

User story 2

Starting from a sample application, Lesley, the full stack developer, can use Event Streams to write events to, and visualise data in Kafka, enabling incremental app creation.

User story 3

While using Event Streams, Lesley can intuitively give feedback, receive assistance and raise issues, getting a response in one working day, regardless of whether she’s using the free or paid version.

The intention of the starter app was to give Lesley a super basic introduction to what Kafka is. The simplest concept we could boil it down to, is the one of messages in, and messages out. It's a simple concept but Kafka does it really well.

We decided to build an application that can be installed outside of the Event Streams build environment (so it wasn't tied to our product) that demonstrated best practice in terms of producing and consuming messages.

The earliest interface idea we had was to have two tabs (the thinking here was so that to Lesley these felt like two separate applications). The application was extremely simple, with one button to start the producer, and another button to start the consumer. Lesley can see the messages get produced from, and consumed by our UI (in the other tab). (Though this didn't turn out to be the case).

What we got wrong

Having these operate over two tabs didn't turn out to be a good decision. Feedback from users was that our UX was too heavily impacted by having to change tabs to see how this all worked. They didn't want to be forced to use two internet browsing windows.

Because of the feedback, I produced a clickable sketch prototype that combined the two tabs into one single application. This now meant that Lesley could see data move from one side to the other.

What we got wrong

A big problem that remained, despite both the producer and consumer being in one window, was that Lesley couldn't actually see the data move. There was no motion, that meant that when a message was produced and consumed, the UI rendered it immediately without animation, so the 'arrival of messages' aspect was lost. This got worse once the page was filled with events as at that point the only thing she could observe was a number changing.

These were just my issues, and they weren't a priority to fix, but I had them on my personal backlog of problems to solve!

I did however manage to squeeze in some of my own code into the production environment, in the form of this SVG animation!

Hello Carbon X

Once Carbon X came in, and the company directive was to move everything over to the updated style, I was tasked at first with the installation page (below).

This page was designed to help with the installation of the starter app. Unfortunately at the time of writing this I couldn't find the deliverable, but I found another one that I produced which was using the exact same template and componentry.

But more importantly, I saw my opportunity to improve the UX of the application itself, to visit the backlog of items I'd created. I pulled the latest code, updated the package.json to use the new version of Carbon, spent about a day chasing down bugs, but then finally I had it running.

I'd only ever tweaked the HTML/JSX and CSS of React applications before this – this was a steep learning curve! (But one that ultimately led to my obsession with building in Gatsby and React!). I demolished all but the back-end of the app to rewrite it to a) use more modern CSS grid features, b) use CSS modules, and c) have motion so Lesley can see her messages leave and arrive with ease!

Notice how when a user hovers over any of the tiles on either the producing or consuming side, the corresponding message on the alternate side gets highlighted. This used React context, which once I got my head around it, is amazing!

What we got wrong

This was the final state of the application as I delivered it initially. If I were to do this again I'd make sure the initial loading state (which could be 100+ messages) is more graceful. I concentrated on the case where Lesley is coming to this with a completely new topic, rather than the case where she's coming to a topic that already has messages on.

(I'd also stop the pointless green tick animating in! That was one step too far!!)