andrewalker

Yesterday, I described how I had approached developing PearlBee by reworking the data models and writing tests. That worked fine until a point, where the pipeline of user interaction was fairly obvious.

For example, it’s easy to write tests for a “reset password” feature. The user is supposed to go to the login page, see a link to reset password, click that. They should then submit their email or username in a form, and get an email with a link to a reset password form. All pretty obvious, since we’ve all used that several times (at least until password managers became popular :) ).

When I moved into the admin section of the website, though, it became a lot more subjective how it was supposed to look like. Not even from a design perspective – from a test perspective. What am I actually testing for?

I started browsing through PearlBee’s current dashboard, paying attention to what was available, and what should be available. I thought it would be a good idea to compare with different CMS’s and blogging engines, to try and come up with an appropriate result. I tested Movable Type in blogs.perl.org (which, of course, is an older version, so not very fair), Wordpress, Ghost and Medium. I loved the design of both Ghost and Medium’s dashboard. Extremely clean, no distractions, a pleasure to write.

I’m not a frontend developer, much less a designer, so it wasn’t my intent to come up with anything nearly as beautiful. But I wanted to sketch something new, as I wasn’t satisfied with what was currently available in PearlBee. If I could come up with a clean basic layout, it would probably be enough for the time being. Later on a designer or frontend dev could take it from there, if desired.

Now, I must confess that at this point I made a decision that wasn’t very objective. I was eager to try out this frontend programming language called Elm, that’s based on functional programming. So I decided to try to implement this sketch in Elm. And I did it, I wrote an initial implementation of it with mocked data. The language has some extremely helpful features, and it enables one to write code that’s very reliable, fast, and elegant. But it was a little out of my depth. Especially when trying to use things like a markdown editor, or any other third party javascript library, I ended up fighting the language for way too long before I could get it to work the way I wanted.

In any case, once I was happy with the basic interactions and layout, I went back to Perl and implemented the API endpoints. I tried to be as RESTful as possible, but also pragmatic. For example, it’s a bit weird to use Cookie based authentication in REST, but it’s the easiest in the browser environment. Also it was already set up for the current dashboard, so I just reused it.

What I ended up with was a pretty good JSON based API to insert, update and retrieve posts, and to retrieve and update user data. Basically everything that the dashboard will need is implemented as an API.

With the frontend, on the other hand, there’s still quite a lot missing, and I often get stuck. Instead of ironing out all the issues, I decided I already got what I wanted from it: the basic interactions and layout, and the matching code in the backend. So my next step is to just convert everything to plain HTML, and keep it simple so it can be productionized now. If a frontend developer ever wants to give it a go, whatever the stack, all the API endpoints are ready and tested.