Jessica Gleason's Blog

Resolving to be a better designer

I have a few resolutions for 2021 and one of them is improving my UI design skills.

Partly, this is for my career. As a front-end developer, I typically work closely with designers and my job often involves extrapolating from other people’s design work. I want to make sure that I’m always being empathetic to the designer’s goals and showing attention to detail. When designing things on my own, especially when I expect to add the project to my portfolio, I also want to make sure my interfaces represent me well as a front-end developer.

But design is also fun! In my opinion, anyway. My college degree is partly in web design and there was a time when I considered specializing more in that direction. This year I’d like to create more web projects whose designs embrace the colorful, playful side of the internet, and I want to approach them with care.

Refactoring UI

So how to work on my design skills? I decided to start with a book that I’ve seen praised more than once among developers online: Refactoring UI by Adam Wathan and Steve Schoger (who both work on Tailwind CSS). This book is meant specifically for developers who are trying to create interfaces without the help of a dedicated designer.

It’s also… pretty expensive, if you don’t have the benefit of an educational budget from your employer. So I went into the book thinking that it better be mind-blowing. In reality: it wasn’t, but surprisingly, that’s what I loved about it. Everything they discussed seemed really obvious once they explained it. I just hadn’t thought about all those details so intentionally all at once.

Redesigning BirthdayBot (the front-end, anyway)

Next, I needed a project to apply these concepts too, and it seemed best to start by revisiting something that already exists instead of trying to make something from scratch. Out of the projects I already had in my portfolio, it was clear to me that BirthdayBot was most in need of some UI design help. BirthdayBot was originally an idea I had for a Slack bot that could pull key details about famous musicians (for use in a music-themed slack channel) on request. Instead, it got reworked into a little web app so that I could have an excuse to play around with Node and a templating language like Handlebars. And then in the end I slapped some fonts and colors on it and it was done–not exactly designed with care.

At the book’s suggestion, I resisted the urge to think about the overall layout first and instead zeroed in on some specific features. I then drew a rough concept on paper of how I could lay them out.

A Technical Interlude

It’s good to be cautious about taking on too much at once in any project so I wasn’t looking to do a total redesign of BirthdayBot from back to front. But while I was redesigning my front-end anyway, there were a few new things I wanted to add to the project.

Firstly, this seemed like the perfect opportunity to check out Tailwind CSS! I’ve worked with utility class-based CSS on several different projects (and generally have positive opinions of it) but I’d only done it with Bootstrap or custom CSS frameworks. Tailwind didn’t end up being much different and I picked it up quickly.

Even working with PostCSS instead of my usual Sass was pretty painless. That part of Tailwind had confused me a bit until I actually started setting it up. I set up PostCSS with plugins like postcss-nested, which allows for Sass-style nesting of selectors, and in the end I was writing code that was more or less the same that I’m used to writing with Sass anyway. And generally speaking, I’d already been using PostCSS on a lot of projects anyway via the autoprefixer plugin so there was nothing to be afraid of.

Another thing I wanted to do with a BirthdayBot redesign is get myself a little more content to work with. When you do a search on BirthdayBot, it first goes to the WikiData API to get information about the person you searched for, and if WikiData knows that that person has music on Spotify, then the app uses the Spotify API to get some information about their music. In the original design, I was really only grabbing the person’s birthday, Spotify URL, and followers. This time, I looked more closely at the data I had available and am also grabbing a description about the person from WikiData and a photo of them from Spotify (where available).

Putting it in practice

Once I was set up to work with Tailwind, I started working through BirthdayBot piece by piece. I brought in some big icons from IconMonstr, some background colors to better separate sections of content, and kept the purple color scheme but ditched the gradient.

Some helpful advice I took from Refactoring UI included things like:

• Giving things a lot of space and then scaling back the space until it feels right

• Using font weight and color to indicate importance or hierarchy even more than size

• Using subtle patterns (like I have for BirthdayBot’s background) and strips of color (like the light border on the top of BirthdayBot) to add some visual interest

Tailwind helped too–using the colors and spacing that ships with Tailwind gave some structure to this site that is a bit too small to justify having its own custom design system.

I love how the redesigned BirthdayBot, despite having only a couple pieces of new content compared to the old one, feels more substantial. At the same time, it does a better job of drawing your eye to the information that’s actually important.

In Conclusion

I thought that Refactoring UI was a great book to start getting me thinking more carefully about design, and Tailwind is a framework I’d be curious to try out on a larger project. And I’m proud of the new BirthdayBot!

I started a blog and you are here. When you start a blog, you have to write a blog post about how you started your blog—I don’t make the rules.

Why?

The blog is an accessory to my portfolio that just got a minor redesign. The portfolio’s got a summary of some things I’ve done at work, some things I’ve done in my spare time that are similar to the types of things I do at work, and also some summarizing of skills I use at work—mostly the technical kind, like what kind of languages I write code in and what kinds of tools I use to write code better.

The thing is, I don’t spend every hour of my work life literally writing code. I discuss requirements and provide estimates and help write user stories and review pull requests and write documentation and reproduce bugs and so on and so forth. I don’t know where in my portfolio I get to talk about that sort of stuff, even though I feel like some of those parts are at least as important as any code I’ve written. And even when it comes to the code itself I have some things to share. I hope some of it is useful to other people. So, I decided it was time to get blogging.

It’s important to me that the blog be here—living on my website, and not a part of something like Medium. I like that there aren’t any comments (though you’re welcome to tell me what you think about something I’ve written if we chat somewhere else online or in person!). Quiet, interaction-free corners of the web seem to be a rarity these days and I’m trying to create more of them for myself.

What’s it built with?

It seemed obvious to me that I should introduce a static site generator for a few reasons:

• security, because I already know myself and my tendency to neglect the portfolio so the less I have to keep an eye on it, the better
• performance, because I’m a web developer and want to make a good impression, besides obviously wanting to provide a good user experience
• simplicity, because this site will really only end up being a handful of pages with text on them and anything with a database seems like overkill
• my own education, because I have limited experience with static sites (I know I did some work on a Jekyll site for BarCamp Milwaukee many years ago, and used Metalsmith a couple times at a previous job) and I really want to learn more

I first went to Gatsby, since I hear so much about it and it seems to be a favorite of agencies building static sites for clients, so it could come up in my professional life someday. I was really impressed with their documentation, but at the same time, I started to sweat a little bit. I have to find time and energy to work on my portfolio on top of working full time and alongside whatever else is going on in my life (such as the stress of a pandemic) so I have to be careful not to bite off more than I can chew. I’m trying to learn React in my free time already, and while Gatsby would allow me to practice React and working with static site generators at the same time, that’s also a lot to juggle all at once.

This brought me to Jamstack.org’s list of Static Site Generators. I looked at a few and while not the most popular on the list, I was curious about Hexo, which is written in JavaScript and presents itself specifically as a blog framework. Its documentation is full of reassurances that it’s “quite easy” which I was a little wary of. I feel conflicted about that kind of language in documentation in general—it does imply certain priorities the project has, like getting users up and running quickly, probably keeping the scope of features limited, etc. and I’m sure it doesn’t usually intend to be condescending. But, inevitably, for some people, it won’t be easy. And, indeed, while I figured out Hexo in an evening, that evening involved some frustrated Googling to work through errors and understand things the documentation didn’t necessarily spell out. Then when it came to actually customizing instead of just throwing posts into the default theme (and, the documentation reassures me, “it’s easy to build a Hexo theme,”) I struggled a bit, feeling like the documentation often missed the forest for the trees.

Once I got the blog up and running, I folded my portfolio page into it—which right now means I basically took over the “page” template of my Hexo blog. This is probably not the right way to go about it, but since I don’t have any current intention to add additional pages, I think that’s a bit of technical debt I can live with for now. The process of creating new posts by dropping in new files with markdown in them and re-generating the site is just as quick and simple as I wanted it to be.

Now that my portfolio is more than just a page, it seemed like about time I figure out some way of managing its deployment that is a little more modern and sophisticated than dragging files over FTP, which is how I was still interacting with this shared hosting I’ve had forever. Luckily, a tweet pointed me to just what I needed (and could reasonably tackle in my free time), an article by Jess Rezac: Continuous Deployment of a Gatsby site to cPanel with Git Version Control. Even though I wasn’t using Gatsby, the concepts applied just as well to my Hexo site, and everything came together on the first try.

So here we are! Now that the blog is up and running, I will probably turn my attention to some other side projects, but future plans mostly include:

• cleaning up the Hexo theme, as I used the default theme as a jumping off point and there are some things in there that I’m not using and could probably remove, not to mention a revisiting of the things I changed as I gain a better understanding of how the theme should be organized
• adding more details to my portfolio design to give more depth (pun intended) to my ocean theme
• create a post type for my portfolio projects and manage their listing that way

You can check out the source code for the portfolio and blog on my GitHub.

I have this distinct memory of being about eleven years old and posting in a forum thread where someone was volunteering to make signatures for people—a piece of text that would appear under each of your posts on the forum. Using HTML, they took my username, put it the System font so it was robotic looking, added a lime green glow around it and a marquee effect that made it bounce around. I loved it. I didn’t understand what the HTML that made it work was doing but I wished I did. It seemed to me a really impressive and powerful kind of knowledge to have.

In a lot of ways I feel really grateful to have made my debut online in the early 2000s. A certain kind of self-expression was really at its peak at that time. We loved cool forum signatures, personal homepages, and unique layouts for our social media profiles and online journals. And while there were some tools available to put your own spin on these things without code, it really helped if you could at least copy and paste some lines of HTML from one of the many sites out there offering up sparkly background images, brightly colored buttons, quirky cursors. I wanted to contribute to this world and so I sort of had to learn more HTML.

I quickly become obsessed with the website Neopets, playing games and taking care of virtual pets. This kind of communal game that I could play for free online was the coolest thing my family computer had done for me so far. Each pet on the site had its own webpage that users could edit, so Neopets provided an HTML tutorial (which is still online!) aimed at its young fanbase explaining basic concepts like changing fonts and colors, and then more advanced concepts like site layouts (which at the time were mostly done using tables). So using my Neopets pet pages, I started writing code.

Around the same time, I started developing another online hangout—roleplaying forums. I was reading the Harry Potter series at the time and had looked around the official Harry Potter forums and seen a lot of people taking turns going back and forth writing stories, switching between the perspectives of their own made-up students in the Harry Potter universe. I quickly found that the real roleplaying was happening on independent forums, where a smaller pool of people could write together regularly and develop plot lines over time. After enough time playing in other people’s spaces, I was itching to start my own roleplaying game where I could develop the setting and control the site moderation. I signed up for an account with a service that hosted a forum for you, but I also needed a kind of homepage to establish the rules and setting of my game, and I needed people to play it. So I solved these things together: I used a pet page on Neopets to introduce my game, and I went on the Neopets forums to tell people about it.

Eventually I got my first member, and then more after that. Over time, I moved to my own web hosting, with my own self-hosted copy of phpBB and webpages that were now built with CSS. I started getting really interested in not just making things with code but writing code well. I learned that blind people used the internet with screen readers and was fascinated by the idea that they might visit my little website and started diligently include alt text on all my images. I ran my pages through W3C’s validators and took pride in putting ‘Valid XHTML’ badges on my pages. I read up on SEO and carefully curated my site’s metadata in hopes of beating out other Harry Potter forums in the Google rankings. I worked my way through JavaScript and PHP tutorials, though I found that it was a lot harder for concepts to click when I was trying to learn them for the sake of learning them instead of with a particular goal in mind. This was mostly before I was even in high school. In hindsight, it was obvious that this career would be perfect for me.

But I didn’t know it at the time. Maybe an unfortunate part of coming online at that time (and I’m not sure that it’s all that much better now) is that I didn’t think a web development career was for me, because I associated programming with back-end code written by mostly men who were great at math and had Computer Science degrees. The kind of people who were not always very receptive to my beginner questions in the web development forums I waded into when I got stuck on things. My real community online as I was learning to code was almost entirely teenage girls who were doing the kind of work I was, all about making things look pretty and building communities based on books and TV shows and boy bands. The ones who were old enough to be in college or have college aspirations weren’t planning to do any of this stuff as a career–they were majoring in things like English, more tied to the subject matter of the things they were writing code for than to code itself. I wasn’t particular good at math. I didn’t really want to go learn Java and algorithms in Computer Science courses. I started looking at degree programs and careers in things like theater.

I’m grateful that, as I was struggling to make a plan for college and honestly really just trying to buy myself time before committing to a four-year school, I ended up in some web design classes at a community college. My classes had a very diverse group of students and supportive instructors. We were doing hands-on exercises actually making websites and learning the very stuff (JavaScript, PHP) that I had tried to learn on my own but struggled to do without the structure and guidance of a classroom. I learned that even local businesses had positions for people who did just the parts of web development I liked best–front-end developers. So I became one.