Hakuu in the making (5) — Mnjul’s Intimate Home vs-6517

Part of the post series for my process in making Hakuu.

Frankly, I didn’t want to release Hakuu this early half a year ago — I did that (only) because I was on my way to an interview and I wanted to have something more recent and more technically advanced on my portfolio. As such, some aspects of the site was rushed (e.g. the mobile layout), and in the past couple months I’ve taken some time to polish Hakuu in general.

Mobile layout design

The original mobile layout (pictured below) had two major problems: First, it saw virtually no visual rhythm, and the lack of whitespace gave poor readability for content blocks. Second, the menu header would not accommodate more items, e.g. background music control, or more pages (especially for smaller viewports such as iPhone 5S or SE). This is not surprising — I didn’t do any research and didn’t even draw a mockup in XD before I coded the interface hastily, and I tested the responsive implementation mostly on desktop’s responsive view, instead of checking usability from an actual smartphone. D’oh, I know!

Pretty crowded, right?

To tackle the first problem, I sampled some Taiwanese online publishers’ text-heavy content layout:

Content from MedPartner, The Reporter, and The News Lens, respectively

It can be seen that layout-wise, generally, there is more spacious line heights, inter-paragraph margins, and horizontal margins. Typography-wise, these sites choose smaller-than-Hakuu font sizes as they use sans-serif fonts — well, I’m still keeping my serif fonts, even though at the cost of legibility, to give the printed publication feeling.

Anyway, the layout problem was pretty easy to tackle after all — I just needed to make up the neglected process, and imposed on myself a fresh set of eyes when I drew the layout in XD, previewed that with my actual phone, and, well, rinsed and repeated.

The menu problem was a bit more elusive. I was debating to myself that a content/publication site is not an interactive app, and thus a separate view was necessary to host all menu options (this is alluding to the hamburger menu usability issue). Also, to place a menu icon, I did need a header bar to separate navigation area from main content, while I had wondered if I could forego header bar if I didn’t need to put menu items there. However, after iterations and discussions with my UX designer wife, I still decided to put the header bar in, with the current page’s name.

Still, I didn’t want to put a standard three-bar hamburger menu icon, so I experimented with different signifiers:

I also pondered, instead of using iconography, what if I just wrote “menu” (in English or Chinese)?

When I was laying all these options out, I was kinda surprised by my mental model that had been reinforced and trained by all sorts of apps to immediately recognize the hamburger menu icon as a signifier to open a menu view. Well. Anyway, I believe M and m would have worked if of another font, and 選 was pretty out of place. But these did inspire me to come up with the square (with slightly rounded corners) one. Here are the final results:

Also, note that the square rotates when going into menu, a nice micro-interaction.

Finally, it’s worth noting that after I finalized the design, it only took me less than half a day to implement them all, and the implemented result was both bug-free and usable at this first shot. It’s amazing that my expertise has really come to this point that involving a design process really speeds things up!

Other changes

Yet again, I had to reteach myself HTTP cache-control headers, including those for shared caches (proxies), which define how CDN should cache things — my primary goal here is Cloudfront should cache the site as long as possible, while the end-user client should only cache roughly for a session (“session” à la Google Analytics, which I define here as 1 hour). The idea here is it’s hard for end-user client to know if I’ve initiated a Cloudfront invalidation; the industry-standard solution is versioning query parameters, and/or different minimized asset filenames during each build, among others, but I am yet to invent a reasonably simple mechanism fitting Hakuu as a static site. Anyway, caching is a hard topic whether it is as local and miniscule as CPU caches, or as large and distributed as content edge caches!

I’ve also discovered on my virtual machine, Edge is not supporting WebGL. Originally it posed a headache for me as I’ve no longer kept “native” windows machines, but then Microsoft announced they’re building Edge to use Chromium… so let’s just call it a day here.

Finally, Hakuu has had issues with Safari (either on macOS or iOS) — the first time it cold loads, nothing renders on the main content area, apparently because the SVG cannot render webfonts for the foreignObject. However, if the user navigates to another page in Hakuu or reload the site (with cache enabled), everything renders normally. This is actually quite easy to work around with some browser sniffing (I know, not a fantastic concept) — when user visits Hakuu, if Safari or iOS is detected, I trigger two consecutive renders on the homepage. And voilà! My new iOS visitors no longer sees a seemingly broken site. With that said, on macOS and Safari, if the user is using a trackpad / Magic Mouse, scrolling seems broken. It appears that I’m not given the correct delta values that I believe correspond to user’s scrolling inertia/intention. Still on my way to investigate and fix that…

There are other technical and non-technical changes to this recent major release, and I’m going to refer you readers to the GitHub commit message for details, like refactors and etc. Well, perhaps, let me talk about changing raindrop’s optical effects: It now darkens the surface, as we often seen water droplets do on paper.


你的電子郵件位址並不會被公開。 必要欄位標記為 *