June 4, 2021 Read 11 Min

A UX and Technical Review of The Official JKJAV Website

From a web developer’s point-of-view, is the JKJAVMY website up to par? We talk about the good, the bad, and everything in between.

JKJAV Malaysia Vaccine Supply Official Website Review "What could be better?"

To add to the recent conversation surrounding the JKJAVMY vaccine registration system, we decided it would be helpful to look beyond just the AstraZeneca vaccine registration page by reviewing the official site for the Malaysian Special Committee on COVID-19 Vaccine Supply (JKJAV) as a whole. 

Since this official Malaysian site aims to effectively and accurately disseminate information on available COVID-19 vaccines in Malaysia, it’s only necessary to ask: How helpful are its design, usability, and structure to Malaysians of all age groups, socio-economic backgrounds, and health conditions? 

To answer this question, this review shall be broken into two parts — one part that focuses on user experience (UX), and another on the more technical aspects from a user with technical background.

In the UX part, we’ll break the review into two sections — one for the good, and one for the bad. Each section may further break down into smaller subsections that are relevant to the discussed topic. In each subsection of the bad, we’ll also discuss some ways we can improve the situation. As for the Technical Review part, we’ll focus only on technical design.

User Experience Review

Before we start diving into the review, I’d like to first set our expectations and even reset our mindsets to accept that we can agree on the fact that something can be bad, despite it being our only option, where we were given no other choices.

The public is more familiar with bad design than good design. It is, in effect, conditioned to prefer bad design, because that is what it lives with. The new becomes threatening, the old (or existing) reassuring.

— Paul Rand

With that being said, it is important to acknowledge that (1) change is a good thing, despite it being uncomfortable at first, and (2) progress is what any product designer should aim for. On that note, let’s dive right into the review.

1. The Good

The User Interface

For most users, I believe that the website has a clean layout, and relatively easy to navigate and locate resources that they need. Links to the registration form are in the navigation menu, and in the largest hero banner — as to be expected of one of the main functionalities on the website.

A button to get help is tucked to the bottom right of the viewport, and follows the user as they scroll.

Ease of Use

For most users, for the purposes of finding out how to register for the vaccine, the website should be fairly easy to use. We can see that links that are likely important to the user (e.g. to register for the vaccine, or to check for their registration status) are either in the navigation menu, or in one of the immediate hero banners.

The option for switching languages is easily noticeable on the top right of the page, in the navigation menu. This is very important for Malaysians, and especially for elders who may not know languages outside of their mother tongue. It can likely be made better if the website would automatically send the user to the page with their preferred language.

2. The Bad

Can I click on this?

Let’s take a look at the following screenshot, and notice the shape of the cursor.

That’s the regular cursor on macOS, so this card in the carousel is probably just an image, right? Let’s try right-clicking to get the context menu.

There’s no option to “Open this link in a new tab”. Interestingly, I also don’t have an option to open the image on a new tab. Hovering over the text changes my cursor into an I-beam, so the image is likely just in the background, and so I can’t open the image separately. That’s expected.

What if I try left clicking?

It… opened up a new tab with a PDF?

It turns out that each of the cards in the carousel are links to either PDF attachments, or articles elsewhere online. However, none of the cards, when hovered over with the cursor, changes the shape of the cursor to a pointer, which is what most people would expect about a link. Outside of changing the cursor into a pointer, we would at least expect that the linked item will have some other visual indication that it is an actionable item, which there is none in the above.

It’s also worth pointing out that the question cards on the FAQ page are the same — the cursor doesn’t change when you hover over the cards, but they are interactable. This makes navigating the page difficult especially for people who have weaker computer literacy, which is a problem because FAQs should be accessible in order to be fully effective.

Now let’s look at another example of a similar problem, their statistics section.

All looks fine. Looks like there are two buttons here that I can interact with. That’s what I thought, until I saw my cursor change as I hovered over the certain areas in the section.

That’s interactable? Every one of the names of the states are? When you click into any of them, it turns out that they bring you into statistics dedicated to that state. So they’re links. I can hear you say, “Wait, when you hover over a link, there’s usually a little indicator from the browser telling you where this link will bring you. Is that showing up?” Nope.

If you’re wondering what this indicator looks like, at least on this browser I’m using, here’s an example from the same page.

Incidentally, this is the context menu when I right-click on the name of the state.

You might ask, “Well, what’s the problem with that? You can visit the link that they want to show you, and the cursor changes to a pointer. That’s all the things that they need to let you do, isn’t it?” Alright, but what if I’d like to open up a new tab for each state? One of the most prominent features of a browser is rendered unusable!

Also, there are users who cannot use a mouse, and they generally rely heavily on the keyboard to navigate websites. In particular, for the unaware, you can continually hit the Tab key to cycle through each link and button, and hit Enter to trigger the click action on the item (Note: This differs across browsers on different operating systems. In particular, it’s not the default on macOS. See this article from the A11y Project on how to enable this feature on your browser of choice.). Out of the many links and buttons on the website, only a handful of them are selectable by this action. None of the links in the navigation menu were selectable through Tab-cycling.

All these, unfortunately, are not solvable through design alone, as it requires changing the underlying code for the website. We’ll explore this later in the subsection They are not standard links.

Insufficient Contrast of Text on Images

Text on images is stylish. It saves space. It makes associating an image with text easy, but doesn’t reduce the text to simply captions, which a lot of people will automatically ignore. However, finding the right color for the text is tricky. If not enough care is given, we run into a very common problem in UI designs — having too little contrast between a block of text and its background. Let’s take a look at several instances where this surfaced on the website.

The following is a screenshot of the carousel that contains link cards to attachments and articles.

It’s quite clear that the white title in each of the cards start to be hardly readable, especially when the title is long enough to fill outside of the dark shade meant to accentuate the contrast between the background and the title. Notice that the text does have some text shadow, but unfortunately, it was not enough to improve the contrast.

Furthermore, notice that the white background is just an extreme. Here’s another screenshot of the same carousel with a different set of contents.

You’ve probably noticed that the white title is just bad for a lot of images that are sufficiently bright. But, they do shine quite well on darker images, or images with a dark shade, as seen below.

On a related note, at this point, you may have noticed that the left-right buttons are really hard to notice — a similar problem! In fact, these buttons even cover up some parts of certain titles.

To improve this, at least in my opinion, we can first move the carousel controls outside of the area where the cards show up. Next, we can add a semi-transparent, dark overlay that will cover the entire image, so that the white text is accentuated. Here’s a screencast after making these adjustments.

While putting the carousel controls to the side breaks the fully rectangular structure, and some of the images have become a little too dark (as they were already darkened in the first place), I believe they are fair trade-offs for the sake of wider accessibility and better experience.

Problems with the Registration Form

The registration page is rather unfriendly, especially for the elderly. The page is, arguably, unnecessarily long, making it easy for the elderly to forget where they are, and simply give up on filling the form. I’m saying that as someone who’s had to take over filling in the form for my grandparents.

I also noticed that certain fields are unnumbered, while others are.

The logical grouping of the fields is also weak. You fill in personal information near the top of the form, and enter into some questions that you need to answer. Suddenly, the form goes back to asking for your address.

There is also no visible validation while filling in the form. While somewhat time-consuming to implement, it’s almost always better to show messages that help the users validate their input.

Technical Review

We shall now look at the more technical side of the website. Of course, we do not have access to the original source code of the website, and so we shall review based on the rendered DOM, as well as certain networking level information. Furthermore, note that we’ll only look at certain components instead of the entire website. Let’s talk about one good thing, and one bad thing.

Language Switching

Something that I appreciate about JKJAV’s website is that the option to switch languages is presented clearly. While it is expected of a website from a government for an officially multilingual country, I find that language-switching is rather rare in many websites that mean to support various languages.

While I can’t peer into their source code to know how it’s achieved, one way that I came to notice how the multilingual feature works on different parts of the website. While somewhat by accident, as one of the rare people on the Internet that disables most JavaScrip (JS)t on newly visited websites, I happen to notice that the navigation menu and the footer won’t show up if JS is disabled. 

Here’s a side-by-side comparison for when JS is disabled for the Malay version, and the English version of the website, followed by another comparison for when JS is enabled. Note that the subdomain URL with the base path will give you the Malay version, while when appended with /en, we get the English version.

JS disabled on the Malay version
JS disabled on the English version
JS enabled on the Malay version
JS enabled on the English version

One important thing to notice is that when JS is disabled, some texts are still properly translated in the English version. This likely means that we’re served the HTML file with the English version. However, the navigation menu, a great portion of the statistics section, and the footer, fully rely on JS to even appear, which is arguably awkward.

If we’re already serving the site through different languages, what’s holding them back with doing the same for these parts that rely on JS? I’m sure they have some reason, some of which I can think of; e.g. needing to write multiple similar JS files for the different languages makes it difficult to maintain and keep in sync, and the framework (even if it’s a custom one) behind makes it difficult to just let JS handle everything.

They are not standard links

Let’s first take a look at one of the items in the carousel.

First off, it looks like a single carousel item was actually not what we thought it would be. A carousel-item contains four cards. This was perhaps done so that there will always be four different items in view. However, there shouldn’t be a need to do this, especially since the carousel functions using JavaScript. In particular, we can tell the navigation buttons that we want the carousel to always “scroll” by four carousel-items, although that does depend on how the carousel is designed, technically.

Notice that a card is actually a div with an onclick event, and each of them runs a single line of JavaScript window.open that opens up the given link, in the argument, in a new tab. Now it’s no wonder why we couldn’t discern whether the card is a link or not (see Can I click on this?).

It looks like this is similar for the states that we discovered were interactable.

Granted, a card link, or block link, has proven to be a difficult component, with seemingly conflicting requirements. In particular,

  • we want the whole card link to be clickable; but
  • we also want the text to be selectable;
  • the card may contain other links, e.g. text links, and they should be interactable;
  • we want the usual browser features, like right-clicking or the middle-mouse-click, to work like they do on a normal text link;
  • on screen readers, the alt text of the image may or may not be relevant, and the order of the image and the title requires care;
  • etc.

Despite being a rather common appearance in contemporary web designs, we have yet to discover a complete solution to this component, and some of the closest have required weird techniques involving JavaScript. It is so tricky that some have recommended that we try to look elsewhere, or drop the requirement where we want the whole card to be clickable.

But what’s a good alternative? It’s difficult to give a definitive answer as it differs by UI design requirements, but the rule-of-thumb should be that we make the title of the card, or what constitutes the title, or the largest item into the link. After all, one of the main reasons for wanting a large clickable area is because it is difficult to click on text links on a lot of handheld devices.

On a final note for this subsection, let’s have a look at this “link”.

The following is the same in the DOM.

The email link could have easily be written as:

<a href="mailto:[email protected]">[email protected]</a>

and all of the default styles and browser features for a link would apply.

Summary

Overall, the site is fairly usable for most people, but does not seem very friendly for the elderly, or people with special needs. For a website that is meant to serve people from every facet of life in a country, the lack of a good contrast between content and background, unsatisfactory keyboard support, form with rather lacklustre structure and aid (especially important for the elderly and those with special needs e.g. AD/HD, visual impairment, etc.), and unclear links, are all detrimental to the cause.

As a developer, I have found reading the code rather frustrating, although I will recognize the fact that the website works according to what is expected by most. But I also empathize with whoever worked on this website. They likely had little time to actually do things right — the COVID-19 situation is getting more severe by the day, and this is likely just one of the many things they have to do.