Revamping the Job Search Experience on Career Centre
How we rapidly built and shipped Career Centre’s brand new mobile-friendly job search experience
A frontend developer’s mildly terrifying nightmare is hearing “yes” to the daunting question of “Are we releasing this for the mobile web”? You first wonder how that’s going to impact estimates.. then the testing.. font sizes.. performance.. Your head starts to spin as you suddenly notice how your vision is blacking out..
A few developers working on the Career Centre at upGrad had a comparable incident some time back. We were tasked with bringing the slick, revamped jobs experience to the mobile web.
mWeb — why it’s not dead.
Across the internet, conversion for prompts to install a native app convert less than 4% of the time. Allowing a native app real estate in what is your most personal gadget, is still seen as a long term commitment — you need to first hook the user and then incentivise them to to install it. So unless your app does something that is not technically feasible on a mobile browser, addresses a high frequency use case or needs heightened security — your key focus should still be on mobile first web-apps!
mWeb also allows us to bring key features to users much quicker than native apps! It’s an easier platform to A/B test our features on and we routinely use mWeb to gather important insights into user behaviour or to gauge the success of a feature before introducing it to the native apps.
With increasingly larger strides in how mobile browsers are tapping into processing power and how new frontend technologies promise an app-like experience, modernising our jobs experience on mobile was a no-brainer.
The technical challenges
The Career Centre is built on Vue.JS, which happens to have a rich ecosystem of libraries. We went into the jobs project knowing that going forward, we should be targeting the entirety of the Career Centre to be served through a cohesive, responsive web experience.
UI library
We needed a scalable and flexible component library that could accommodate upGrad’s growing design system — Hygge. Our top priority when choosing the ideal library was customisability, performance and community support. After deep-diving into the availability of event hooks, template slots and general stylability, we narrowed down on Vuetify and Quasar.
These libraries had very similar underlying philosophies and component coverage. With that in mind, we tried out a real-world PoC showdown, trying to implement the screens provided by design in two very real-world tests. After pitting the two against a selected set of metrics which included ease of development, production package sizes, responsive design coverage and more, we narrowed down on Quasar!
Another “first” we tried out for this release is using theme-neutral components and iteratively evolving it to make it our own. This allows us to bring the product to the users much quicker, evolve our component libraries and setup the processes to share it between teams, while also making sure that other teams can shift to the new design system.
Why a UI library?
UI libraries allow rapid development of consistently styled UI components, that can be later shared across teams. Besides being responsive, these components are built to be compatible across browsers, while allowing developers to not worry about accessibility. Components also unify the way we feed and store data going to and from the components.
The immediately visible caveat is that the initial learning curve is a bit steep, but that time lost is easily made up in the additional time it takes to QA any custom UI component. Diving a bit deeper, there might be one possible argument against component libraries in the fact that a custom UI library would be leaner alternative to bloated and overly customised off-the-shelf components. While this concern is valid, in the real world, we were able to customise components globally to fit our design needs with a couple dozen or so lines of CSS.
After narrowing our list down to just 2 libraries, we chose Quasar over Vuetify and here’s how we evaluated it objectively.
Vue 3 support
Vue 3 brings with it some major features centered around performance and we definitely do not want to miss out. While both Vuetify and Quasar have a detailed roadmap to support vue3, we felt that the jump would be marginally easier to make with Quasar, since it promises reverse compatibility. That said, we really did like how Vuetify has a highly organised roadmap on Notion.
Emphasis on Security
When you first look at the sections on Quasar’s page, what really stands out is the security tab! It consists of a surprisingly exhaustive set of security DO’s, DONT’s and limitations for each of the most commonly vulnerable components. To top it off, a few components come with in-built sanitisation that are really handy!
Core Philosophy
Quasar, before it was officially released, started off as a mobile first framework that focussed primarily on building hybrid and electron apps. Then as it expanded to include desktop web-apps, it gained traction soon.
Dev Experience
Documentation and ease of use
When developing large scale web experiences, the documentation aspect of any library plays a huge role in shipping quality code on time. At first glance, Vuetify’s well presented documentation, coupled with a relatively lower barrier for entry made it a clear favourite. However, once we started delving into the more complex use cases, Quasar really started to shine.
Styling
The component styling are equally easy in both the libraries. Quasar has a custom class with a —inner prefix that can be used as a hook to create custom styles. It also has modifiers to changer styles based on element states. (This is especially useful in cases like the one illustrated below where the input element is much lower down the DOM tree than the element controlling the style)
Flexibility
The core component coverage of both the libraries is quite identical. However, Quasar has a slight edge in the extended components (stepper, timeline, etc). So then we started to analyze the number of customizable props and slots, etc for all of the core components, we found Quasar to be significantly more customizable than Vuetify.
The flexibility of the component library was very important to us since it’d enable us to write code and test faster, and bring the feature to production sooner. Moreover, if all the Vue repos at upGrad to shift to a single library, it would be easier to share off-the-shelf components bundled with the settings, rather than a custom written component with deeply-linked dependencies.
Let’s have a look how we assessed flexibility -
When we first had a look at the search bar’s functionality, it seemed like we’d have to build a component from scratch to account for the unique use cases.
The search bar has 3 states — recent searches, search suggestions and custom search. While the recent searches is straightforward to implement, the latter 2 cases operate on all the tags present in the search bar as well as the untagged input.
The closest components that resemble the functionality of the searchbar in Vuetify and Quasar are the v-combobox and q-select, respectively. Looking at the APIs for v-combobox, there’s no built-in way to access the the untagged input value.
The example below gives an idea of how easy it would be to customise the behaviour of a component to suite a complex use case.
Typescript
Another aspect of the release was a shift towards TypeScript. The immediate advantages are IDE autocomplete and static type checking. The well defined types makes it easier for newer developers to understand code (this is especially useful when sharing components between teams). The biggest tradeoff for us was an increased learning curve. In the longer term, we were expecting slight dips in productivity.
The Release
We split the releases into two, one for desktop and a subsequent one for mobile-web. We started by laying out the foundations for responsiveness in the desktop release. However, we used a conditional flag to hide the mobile version in production. The second release that brought mobile responsiveness was written in a mindful way that made sure that the previously tested code was mostly untouched
Once the desktop release went live, we quickly got back to work (after a quick break to celebrate, of course 🍻). We re-looked at key factors like interactions, touch targets and spacing using a mobile-first lens and after using BrowserStack to do extensive dev-testing, handed it over to QA.
Future scope
We have a series of features that would improve the general ease of use for our learners who are accessing the Career Centre on mobile. We’re focusing on improving the page speed performance and bringing more of the desktop functionality to mobile. Going full-PWA is next up on our list of TODO’s. PWAs will open the doors for background processing and push notifications, and that will take us a step forward in bringing a world-class learning experience to everyone.
Do visit upGrad.com to check out our programs that are completely online! If you wish to work with our ever-enthusiastic team, check out our careers page. We are always on the lookout for ambitious, talented folks!
Contributors: Adarsh Sosale
