Designing Fictions, Part 3: Designing in the Browser
(This is the third part to my process of designing my Fictions homepage. Here’s the first and second part, in case you haven’t and want to read them first.)
When it comes to web design, there are those who find the concept of designing in the browser unthinkable, those who think we should be deciding in the browser, and those who believe in designing mainly in the browser. Myself, I definitely belong to the last category.
First Things First: Growing the Concept
No matter the complexity of the page, I’ll mostly start off with hand drawn sketches. Sometimes, even before the design, I’ll have an idea, a concept that I’m hung on, and I’ll draw sketches related to that concept. Years ago, for example, I remember being intrigued by a picture book that depicted the story of some animals getting trapped in a pit, and I decided to use that pit as a concept for the design of a website. (Unfortunately, that website is already taken down and I didn’t take screenshots, so I can’t share the design here.) Other times, I’ll start off with a blank, then start brainstorming ideas for the design. For this blog, for instance, I started off by associating a blog with keywords like chronology, time, the blogger’s thoughts and changes over time, and so on, and then finally settling on the concept of a blog as a retrospective of the blogger’s “works of art” (i.e. his thoughts).
Testing the Concept in the Browser
A concept is only a concept, and needs to be proven and tested. As a web professional, I don’t believe in testing a concept with any other thing than a browser.
With my Fictions homepage, I started off with the simple notion of wanting the Fictions section in a circle, most likely black background with white text. Why? Because webpages are typically so boxy, the first thing I wanted was to break out of that mold.
So with the HTML already in place, I made a quick circle (with simple background-color and border-radius) that’s anchored to the right. It then became apparent that the space to its left should be the Works section. With the simple notion that typography is the selling point here, I set a few larger-than-usual font sizes and quickly put them together to see how they looked:
This, I would say, is my first design draft. At this point, I will decide if the design pleases me, and if I want to pursue it further. For Fictions, I decided that this was the direction I wanted to go down, so from there I started building on the draft and fleshing out the details, mostly with CSS and entirely on the browser.
Sorry, But No Mobile-First for Me.
Yes, yes, sure I understand the arguments for a mobile-first design. But from a creative standpoint, coming up with design ideas on a tiny canvas the size of a mobile viewport is way too limiting. In the physical world, there are artists who relish in the joy of making art on the smallest canvas possible. Well, I’m not one of them. I like to have a big blank canvas in front of me for me to play around with and splash paint on. To me, the desktop viewport is the digital equivalent of that canvas.
The one thing I will have to take note of here is that I will need to move some of the styles I already have into desktop-and-above media queries afterwards and modify the remaining styles to cater to smaller viewports. Which, really, doesn’t present much of an issue; since the desktop design and the mobile design typically overlap a great deal, it doesn’t require a lot of work. I’ll trade that effort for an interesting concept anytime.
Go with the Flow.
At this stage, I have a solid concept that is tested out on the browser and that I’m satisfied with. The rest of the work of writing CSS to flesh out the concept into a real design is relatively straightforward. As long as I have a solid concept as the foundation, it’s simple (though not, obviously, easy) to build up the design around it. In the case of Fictions, since it’s a single page, it’s even more straightforward. And because it’s a simple, personal project, I used this as an opportunity to try out the BEM approach of writing CSS. (I’m still not sold on it, but I can see its strengths.) In any case, as the design isn’t particularly complicated, I will not go in-depth into the code. Most professionals will know how to code it up quite easily, I’m sure.
Oh, but allow me to share a small episode when I was designing Fictions. It was straightforward enough to design for the mobile version of the page, since the circular Fictions section didn’t fit on a small viewport, so I had everything boxed up again on mobile sizes:
What gave me a bit of a challenge was the in-between, “tablet” size. While it wasn’t narrow enough to ditch the circle, it wasn’t wide enough to show it in its full glory. After a bit of tinkering and testing (e.g. making the circle a box, placing it directly on top of the other sections like with the mobile viewport), it suddenly dawned upon me: why not hide the circle partially? That is, allow a sneak peak of the circle but hide it partially so that the user will be intrigued enough to click it. Like this:
I’m sure there will be UX purists who think hiding things from users this way is bad. Well, I’d like to think that engaging users is part of good user experience too, and a little intrigue never fails to engage users, isn’t it?
Good Design = Tried and Tested Design?
Frankly, I’m not sure. And clearly there is no right answer to that question. Often, when I read the reasoning and rationale of clever designers/developers on the merits of using tried and tested design patterns and layouts, I feel convinced. Yet I can’t help but look at bold, unconventional designs in fields such as product design and architecture and think, no, breaking out of the mold doesn’t necessarily bring about bad design. I got a feeling it’s because design on the Web is still at its infant stage, so the notion of bold, unconventional designs that challenge the user is not seen as viable yet. But when the Web matures sufficiently, things should change. Guess we will see.
Next Up: Injecting Interactivity