What I learned from switching roles as an experienced hire.

Despite being in the early stages of my professional career, I’ve had 3 role switches over the past 4.5 years. The first was due to the end of my research contract, whereas the second was in pursuit of growth and learning opportunities. It was only on my most recent switch that I joined a company as an experienced hire.

Unlike joining as a “freshie” or “trainee”, joining as an experienced hire comes with additional expectations. This is no surprise. What caught me off guard, however, was the extent to which everything has to be taken and approached with a pinch of salt.

I’ve only been in the new role for a few weeks, but here are the 3 things that shocked me the most so far:

1. Suboptimal practices can outperform the best practices
2. Context change both externally and internally
3. Balancing expectation, personal drive, and acclimatisation is difficult

Suboptimal practices can outperform the best practices

One of the biggest and most widely-used buzzwords in the IT industry is Agile. For those who are unfamiliar, a couple of software developers came together 20 years ago and wrote a manifesto dictating their view on how to develop software better. These 4 ideals led to the inception of various frameworks designed to encapsulate them in a formulaic manner.

One of the most popular frameworks today is Scrum. 94% of all agile businesses use Scrum. Even though the framework is open-source, its creators are now billionaires, and countless certifications sprung up as a result of its popularity.

And yet companies are still struggling to yield highly motivated and performing teams. There are still countless poorly-implemented softwares being sold to the market. Most ironically was how in ComparativeAgility — the tool provided by ScrumAlliance to compare a team’s agility against various benchmarks — even the global benchmark lies on the poorest performing quadrant.

I became a firm believer of Agile and Scrum ever since I learned more about it, and I still am. However, having seen how much my current employer outperform some of the other firms who claim to be “Agile”, I no longer believe that it is the one true solution for excellent software craftsmanship.

A framework, ultimately, is just a guideline. We should always make the best decision based on the context we are in, and that includes our software development approach and methodology.

Context change both externally and internally

When switching roles we often pay more attention to the apparent changes that will happen: new workplace, new colleagues, new culture. In anticipation to these changes, we may proactively conduct research: reading Glassdoor reviews, asking friends who work in the firm, stalking our future manager and colleagues on Linkedin. Having done exactly this, I believed that I had a strong, bullet-proof game plan to acclimatise myself to my the work environment I soon find myself in once I moved.

However, I learned that I forgot to account for one very important context change: my increased wealth of knowledge and experience.

My previous manager once encouraged me to get out there and try things out while the stakes were low. Why? Because I was a “freshie”. Hiring me came with the expectation that I was bound to stumble, fail, and make mistakes. It also came with the expectation that I would learn from them and grow professionally.

And grow I did, by trying out new things, always embodying the “can-do” attitude, taking initiatives, and promoting changes/new practices internally. Through all my actions, I built a reputation as a capable, creative, proactive, outspoken, and dependable contributor to the company.

When preparing for my most recent switch, I accounted for the less forgiving culture and my status as an experienced hire. I told myself to make a strong positive impression, apply all that I know, and ensure I do not make the same rookie mistakes I made 2 years ago. Initially, it all seemed to work just fine; I was commended for my speed of onboarding and proactive nature.

However, I came to realise that while my plan was fine considering just the external context changes, it was flawed if I accounted for the internal context changes. These internal context changes encompassed my skillsets and experiences, and they affect the way my colleagues perceive me and my actions just as much as the culture of the company I just joined. I learned that whereas my eagerness, candid nature, and “can-do” attitude were all seen as proactivity and openness in the context of a “freshie”, it came across as arrogance and overstepping in the context of an experienced hire.

Balancing expectation, personal drive, and acclimatisation is difficult

Which brings me to my last point, and that is the fact that balancing the expectation of a being an experienced hire, my own personal aspirations, and the need to adopt to a new culture and establish professional relationship with new colleagues is not easy. On the one hand, the need to convince the manager that he made the right choice in hiring me is evident (I am, after all, still under probation). In an environment with informal onboarding and minimal handholding, taking initiatives and trying things out may be required. On the other hand, doing so may make me come across as trying to impose myself too much without first understanding the ins-and-outs of the company today.

Getting over these points, especially the last 2, definitely require more contemplation, pondering, and adjustment on my end. However, if there was anything I could immediately adopt as of this writing, it was that context matters more than we think, and as such everything has to be taken with a pinch of salt, with more salt pinched the more uncertain the context became.

Maintaining human connection throughout remote working.

Roughly a year ago, I wrote some tips on how to stay connected with our loved ones while working overseas, far away from where they are. What I did not expect was how pervasive the struggle to maintain human connection would be, so much so that we began to lose that human touch with the people we typically spend most of our time with: our colleagues.

I began noticing this around the 3rd quarter of 2020. Superficially, it looked like business as usual; everyone was busy working towards completing their sprint tasks and goals, and every day we would see our “burndown chart” steadily charting our progress. However, I could sense that something was not quite right, that interactions with my fellow teammates felt more curt and transactional, and all conversations began with the need to extract some information from the other party. For a while, I pondered the reason why this was the case until the obvious hit me: whereas the office setting catalyzes impromptu casual conversations (whether through accidental bumps along the hallway, tea breaks in the pantry, or lunch breaks), remote working meant all interactions were confined within the remote working tools we were using (Microsoft Teams and Webex), typically accessed only when we are deep into our work.

The question, then, was how we could bring back those catalytic moments into our remote working setup, and the answer to that question for our team was a combination of an online collaboration tool and a tinge of fun.

Inspired by a sharing done during a Friends of Figma Singapore Meetup, I decided to adopt the idea of an “emotional scale” into our team. At that time, the online multiplier game Among Us was taking the world by storm, and I thought what better way to incorporate fun than to design the avatars based on the Among Us characters. Within a few minutes, I whipped up a prototype on Miro and showed it to my manager.

The above board is a duplicate of the one we actually used in alternate Daily Scrum Meetings, but the principle is identical. Each person within the team is assigned an avatar (they are allowed to customize the color insofar as no 2 people end up with the exact same color). At the start of the meeting, everyone will log onto the platform and move their avatars onto the scale in the middle based on how they are feeling that day, with 1 being the worst and 10 being the best. The meeting facilitator (in our case the Scrum Master) will then facilitate either (a) an open forum for everyone to chit-chat for a few minutes and share their feelings or (b) dedicated sharing time for each person. The idea was for the Board and the sharing session to become a substitute for those casual conversation moments that happen in the office.

The idea was approved and we are still doing using the “Among Us” Board up to this moment. Personally, I found an open forum to be a better format than a dedicated sharing time for each person, as the latter is bound to feel obligatory and routine-like. However, an open forum brings forward the challenge of encouraging everyone to speak, instead of just a handful of people. My manager found it useful to actually graph out the ratings given by each person in order to deduce some patterns, and hopefully intervene when necessary before it’s too late.

Should you wish to give this a shot with your team, I have made a version of the file available for duplication in Figma. I sincerely hope you find it useful in navigating this new way of working!

I have always used WordPress for my personal website/portfolio. I started with the SaaS version that is WordPress.com, before transitioning into WordPress.org earlier this year. Like many have told me, WordPress.org indeed opened up a lot more possibilities compared to WordPress.com, courtesy of its mature theme and plugin ecosystem, as well as better access to HTML and CSS customizations. It was truly a state of “whatever you can think of, you can build”.

However, for the longest time, I thought a WordPress site would always be that: a WordPress site. I thought there was no way I could get the transition that modern site builders offer, where only part of the page refreshes on navigation into another page.

Until I came across a certain JavaScript library called Smoothstate.js (and its close competitor, Barba.js).

I looked at tutorials on how to integrate Smoothstate.js into WordPress, and truthfully it looked simple. However, none of the tutorials provide a comprehensive guide on how to organize your WordPress site in order to ensure that everything works as it was prior to Smoothstate.js integration. After spending a whole weekend overcoming the obstacles I came across and ironing out small kinks here and there, I decided to write the whole process out with the hope that others who encounter similar struggles may benefit from this documentation.

Creating a Child Theme

First things first, like many of the tutorials I found, I recommend creating a child theme to host all the customizations we will be doing, unless you built your own theme from scratch. The reason being that any customizations made to the parent theme would be lost when it is updated to the latest version, and updating all your 3rd party dependencies is highly recommended to patch up any possible security vulnerabilities.

I won’t go into the details of creating a child theme, but should you need help you can find plenty of tutorials online. I would recommend following the steps provided by the 3rd party theme you selected. For example, Astra has great documentation on this and even provides a tool to generate the child theme for you! Once you are done, activate that child theme and we’ll be good to start!

Aggregating Your Custom CSS

The next thing we need to do is to aggregate any custom CSS you may have written into a single file that will be enqueued on the initial load of your site, regardless of which page it’s loaded from. Whereas inline CSS added directly into your HTML will still be rendered properly with Smoothstate.js, the same cannot be said with styles applied through a class attribute. I believe if you use a plugin like Autoptimize that has the option to aggregate your CSS into a single file, you may be able to skip this step. However, should you decide to do it anyway, let me share with you the two ways this can be done:

1. Adding all your CSS directly in WordPress Customizer’s built-in CSS editor. You can access this through Appearance → Customize → Additional CSS. The advantage of doing it this way is that you can preview your changes live, as long as you’ve added the respective classes into your HTML in each page.
2. Adding all your CSS into the stylesheet of your child theme. You can access this Appearance → Theme Editor. Select your child theme, and edit the style.css file. You won’t be able to see the changes live if you take this route, but I personally decided to do it this way because I installed a plugin called HTML Editor Syntax Highlighter, which color codes my classes and CSS attributes nicely.

Adding Smoothstate.js into Your Site

Finally, the steps we are all here for! For integrating Smoothstate.js into WordPress, I followed the steps outlined by this tutorial. I liked this one more than the others simply because it skipped the creation of a wrapper div tag in the HTML, which may not be easy to do if you use a 3rd party theme. Both the element with “page” as an id and the element with “site-content” class seemed to be universal WordPress elements, but I might be wrong (my Astra theme do have them). If upon following this tutorial Smoothstate.js does not work, you may want to inspect your HTML in your browser.

For reference, the element with “page” as an id on my site is the div tag which is the direct child of the body tag, and the element with “site-content” class is the sibling of the header tag, located directly after the latter.

The first thing to do is to download the latest Smoothstate.js. Then, add the downloaded script file and another file containing the script gist below into the same folder. I personally prefer adding them both in assets/js under my child theme folder, because they will then appear under the Theme Editor together with the child theme’s stylesheet and PHP files, making editing that much easier. To do so, use your hosting provider’s FTP client.

The opening of the script above is slightly different than the tutorial’s because I opted to use the jQuery bundled with WordPress, which has use-strict enabled.

Once the above is done, all that’s left are to enqueue the scripts and add some CSS. For the latter, you may adopt and modify the tutorial’s CSS, as the classes it affects are not changed in the script above. Or you may copy my version below which does not include the sliding animation.

Remember to add the CSS the same way following the way CSS is aggregated in the previous section. With that out of the way, open Appearance → Theme Editor and add the following lines to the functions.php file:

You need to replace your-child-theme with the name of your child theme. However, if you decided to place your scripts elsewhere then you need to trace the directory accordingly.

Save your changes, and run your site to see Smoothstate.js applying partial update when you navigate around your site!

Ironing Out Kinks

So are we done? Unfortunately not, unless you don’t use any other plugins in your site then probably you are done (then you might want to go straight to the next section). However, if you do use any other plugins to generate your site’s content, then chances are they don’t work or render properly. The reason is that when applying the changes, Smoothstate.js does not reload any stylesheet or run functions specific to that page, because technically the page is not reloaded; it’s just “updated”.

Personally, none of the content-generating plugins I use require any scripts to run on load. If the same applies to you, then it’s a matter of enqueuing the required CSS file on the initial load of your site. To know what stylesheet needs to be enqueued, you can follow these simple steps:

1. Open an incognito tab on your browser.
2. Launch the browser’s developer console (you can do a quick Google on how to do this since the instructions are specific to each browser).
3. Click on the Network tab of the developer console, and apply the “CSS” filter.
4. Now, launch your site’s homepage and see what files are loaded by the browser. Take note of them.
5. Once that’s done, open a new incognito page and repeat steps 2 to 4.
6. If you notice any file being loaded that was not on the previous list, click on that file in the developer console and then click on the Headers tab.
7. Look at the Request URL. It will point out where that file is fetched from. Take note of the path from “wp-content” onwards.

Do this for any page where you notice a rendering issue. Once you got all the additional stylesheets’ paths, head to Appearance → Theme Editor and open up the functions.php file. Now, see if there is already a stylesheet enqueuing function there. If not, create a new one and enqueue it following the snippet below:

For every path you noted down, apply the code written in line number 8. Replace my-missing-theme-name with the stylesheet name, my-missing-theme-path with the stylesheet path, and my-missing-theme-version with the stylesheet version, if any (otherwise leave it as ‘’). Click on “Update File”, and try launching and navigating around your site again. Hopefully, all the rendering issues are now fixed.

The above fix is only applicable to fix the missing stylesheets issue. If your plugin requires one or more functions to be run on page load, then according to this blogpost you will need to call that function again by adding it to the onAfter property of the Smoothstate.js setting.

Adding a Loader

By this stage, I hope you have a revamped site with Smoothstate.js properly integrated. If you host your site on a managed hosting plan with excellent bandwidth, then chances are you would not need this. However, if like me, you host your site on a shared hosting plan, then sometimes your site might take longer than expected to transition from one page to another. This is where the loader comes to the rescue!

The idea of a loader is to provide an indicator to the user that the site is not broken. I believe that showing a visitor something is better than nothing. Yet, having a loader shown in each page transition will also be annoying to the user. Hence it’s important to tune the tolerance time before the loader is displayed.

As our site now applies Smoothstate.js transitions, this loader will only be shown when a visitor is already inside your site and is transitioning between pages. It will not be shown on the initial load of your site.

As we are transitioning the div tag with the “site-content” class, we will need to add the loader as a sibling to this element. We will also need to ensure that the loader takes up only the remaining space below the header, which remains unchanged throughout the visitor’s visit to the site.

To do this, we would need to modify the child theme’s header.php file. However, chances are the child theme you created did not come with a header.php file. If so, all you need to do is copy the parent theme’s header.php file into the child theme using your hosting provider’s FTP client. Once that’s done, you can go to Appearance → Theme Editor and access the child theme’s header.php file. There, look for the HTML tag with the “site-content” class.

Before modifying the header.php file, browser the web for or design yourself a good pure CSS loader. If you prefer adopting someone’s design, I recommend getting one from loading.io. The 12 designs shown in the hyperlink are all CC0 licensed and can thus be used freely.

Copy your choice loader’s HTML tags right above the HTML tag with the “site-content” class. Give an id property to your loader so that we can easily refer to it in our script later on. You can refer to the snippet below for reference. Don’t forget to add the CSS into the aggregated CSS file following the steps in the previous section.

As you can see, the loader is initialized with an inline “display: none” style attribute. We will handle the display and hiding of both the content and loader with some jQuery by augmenting the custom script we did above.

With that said, head to the custom script file in the assets/js folder (or wherever you put yours just now) and prepare to do some modifications. The first thing we need to do is to tell Smoothstate.js to do something while the page is rendering. This is done by adding an onProgress property to its settings object. During onProgress, we would display the loader and hide the content. And then, in onAfter we would do the reverse.

However, as discussed before, we do not want the loader to display right away all the time. Hence, we need to set a tolerance window. Only when loading takes more than the tolerance window will we show the loader to alert the visitor of the unfortunate delay. We can easily do this by calling the “setTimeout” function provided by JavaScript.

However, now comes another problem! Imagine we provide a tolerance window of 1 second (1000ms). When the page is refreshing, the onProgress state initialized an internal timer to show the loader after 1 second. However, the page actually loads after 700ms, during which the onAfter procedure takes place. If we do not tell the code to stop and reset the internal timer, the loader will be shown after the page is loaded, which is wrong! Hence, we also need to modify the onAfter by adding a “clearTimeout” to reset any initiated timer before rendering the page.

With all that said, the complete code can be seen in the snippet below:

In the sample above, we assign a tolerance window of 1 second (1000ms). When the page is loading, the set an internal timer and assign it to the loaderTimer variable. If the page is loaded before the tolerance window, the check on if loaderTimer exists would return true and we would reset the internal timer. However, if the page takes more than 1 second to load, the internal timer would render the loader, which would be removed once the page is rendered.

Adding (or Restoring) Google Analytics

With the above implemented properly, your site’s UI/UX should look snazzy and modern. Unfortunately, if you’ve incorporated Google Analytics into your WordPress site, it will not work correctly anymore.

The reason being that when readers navigate around your site, the Analytics script is fired only once during the initial page load. Any navigation afterwards results in only partial updates of the HTML body tag. As such, scripts that normally run when page reload completes will not be run.

In order to make Google Analytics track page navigations within your website again, we will need to use Autotrack, which is the official Google plugin to make Analytics work on AJAX-based website. Thus, we need to make the following changes:

1. If you use the Google Site Kit plugin (which, you should if you haven’t), head to Settings → Analytics and switch off the “Let Site Kit place code on your site” feature.
2. Before we re-insert the analytics script back into our site manually, we will create another custom JavaScript file (see the analytics-autotrack.js file in the gist above) and add it to our child theme’s assets/js folder.
   That script is basically a modification of the default script provided by Google. You can actually keep the default script if all you are interested in is the page view.
3. Finally, let’s head to the functions.php file of the child theme and add the following code to enqueue the custom script above together with the analytics.js and autotrack.js files into our site’s header file.

With the above changes, when an AJAX call is fired to navigate reader to a new page, this information will be sent to Google Analytics, thus providing you with accurate data again. What’s also nice is that any other event tracker added into the custom JavaScript file above will also be sent to Google Analytics as and when they are triggered. Neat!

Phew! That was rather long. If you’ve made it to the end, congratulations, and I hope you’ve successfully applied Smoothstate.js to your WordPress site! If you read through it all but have yet to give it a go, I would strongly recommend you to do so. It is not as difficult as it looks 😄 And if you need more encouragement to do it, I hope my portfolio website will do just that!

References

1. smoothState.js official GitHub repository
2. autotrack official GitHub repository
3. Adding page transitions to WordPress
4. How to Integrate SmoothState.js Into a WordPress Theme
5. Page Transitions in WordPress with SmoothState
6. Using Google Analytics for Ajax Powered Themes

Figma has its built-in solution, but I am proposing an alternative.

You are the Product Owner of a Web-App. You are looking for ideas on how to further enrich the current version with more useful features. You decided to go to your team’s design software and browse through the mockups of the App and as you go page by page, you saw something you had not seen in the latest version.

“Wait, has this been implemented? If not, why?”

You quickly try to trace the history of this feature; you look through past User Stories, presentation slides, even Release Notes. Yet after a few minutes of backtracking, you still could not find out the reason behind this discrepancy. What’s more unfortunate is that the UX Team makes edits directly on the same file without proper versioning.

How you wish there is some form of versioning of the mockups…

As one of the leading design tools, Figma has a very robust Version History. Here are the key features it offers:

1. Automatically saves when left idle for 30 minutes
2. Supports manual save with custom names
3. Allows restoration of versions in-file
4. Allows duplication of any version into a separate file

The beautiful thing about the last feature is that components are cloned instead of instantiated. This means that changes on the components in the original file will not affect the duplicated file, which is perfect when you want to freeze your mockup.

There are a couple of drawbacks to this. Firstly, imagine the amount of file you will end up with after a while, especially if you’re dealing with an enterprise software with multiple components…

The second one is the fact that duplicating a version clones the entire file, not just the page you are interested in. Hence, if your design file has multiple pages, your clone will contain all of them as well.

You may be able to avoid cluttering your project by cloning and maintaining a limited number of versions backward. Unfortunately, it still won’t solve the issue of cloning the entire file.

Enter, Figma Plugins!

As early as August 2019, Figma finally supports plugins, and with it comes an API that allows anyone to create plugins. Since then, numerous developers and designers have come up with small utilities that make their work easier and faster.

It is this support for plugins that make my alternative proposal feasible. Instead of cloning the entire file, we can clone only a page within that file. Now you might ask, “Why do you need a plugin? I can just duplicate the page using Figma’s built-in function, no?”

Well, here’s why…

If you focus on my erratic mouse movement after duplication, you will see that in the new page, the “Components (Hidden)” frame contains not the components, but instances of the components. This means that any changes made to the components in “Page 1” will affect the instances in “Page 2” as well!

To prevent this, I would need something that duplicates the page while ensuring the new page is completely detached from the old page so that any changes to the components linked to instances in the original will not affect the duplicate in any way.

Anyone can create a plugin that achieves all the above points. However, to illustrate how this can be done and how the result may look like, I will be using one which I created: PageClone.

As you can see from the image above, when PageClone is run on “Original”, it created a copy of the said page within the same file. However, inspecting the duplicate page more closely and one will notice the absence of any components or instances. This is because every component or instance in the original page is converted into standalone frames in the duplicate, which ensures that the copied page stands separate from any other pages within or even outside of the file.

However, having too many pages in the same file will make the latter heavy and take longer to load initially. As with using Version Control, you can alleviate this by maintaining only several versions backward.

So, am I saying to ditch Figma’s built-in functionalities and exclusively use a plugin instead? Well, not really.

On the contrary, I believe that the best way of achieving mockup freeze is to combine both of them hand in hand. I propose using something like PageClone for short-term freezes based on your team’s SDLC. Once enough cycles have passed, you can then archive the file using Version History (or just simply duplicate the file), which would allow you to delete the plugin-created pages from the original file, hence keeping it lightweight.

For example, if a team follows a monthly sprint and releases a major version of the application every 4 sprints, the team can:

1. Use a plugin (e.g. PageClone) for freezing the mockup corresponding to each sprint’s delivery
2. Use Version History (or duplicate the file) to create a new file containing the last 4 sprints, which corresponds to a release
3. Once the file is duplicated, the last 4 sprints’ pages can be removed from the original page

This, I believe, brings out the best of both worlds.

Staying connected with your loved ones amidst global immobility.

The best thing one can have when riding through a difficult time is the companion of one’s dearests; to be able to share the pain with them, and to have them reassure you in their own unique ways that “everything will be alright”. In ordinary times we frequently get annoyed over their presence, yet in extraordinary times the sense of comfort they provide is beyond words.

As an immigrant in a foreign land, their constant presence has long been a privilege that is out of my reach. My family is one of those that pushed the definition of “global citizenship” to the limit: my brother works in Hong Kong, my mother and girlfriend are both in Jakarta, and I mostly call Singapore my home. We rely on messaging, voice, and video calls to stay in touch on a day-to-day basis. Thus, for 11 years the reliefs to my longing for their physical presence are periodic temporary gatherings, usually on special occasions like Christmas, college graduations, or Lunar New Year. They may be short, but in retrospect, they make the distance that much more bearable.

It will all be different this year, however, in light of the COVID-19 pandemic. I was lucky to still be able to meet all three of them back in January, and the last time I met my mother was in March when we traveled to Medan together. With the ongoing global lockdown and looking at how rampant the virus spreads, it is unlikely that the situation will get better anytime soon. Who knows how much longer will it be before I can be reunited with any one of them.

Nonetheless, I believe that there will be light at the end of the tunnel, and it is in our best interest to persevere through the tunnel together so that emerging from it will taste that much sweeter. Thus I am sharing with you the three simple pointers I am adopting keeping the relationship with my loved ones strong as ever:

1. Stay in touch. This one goes without saying, whether it is simply by text, voice, or video calls. Before you send good morning messages on your team’s Slack workspace, send your greetings to those miles apart from you first. Ask them how was their night, and what they plan to do today. Show them pictures of your home-cooked meals during lunch and of your “Work From Home” desk setup. Distance is no excuse for not doing the things you would normally do when they are around.
2. Stay updated with the situation where they reside. I have adopted this multiple times, not just during the ongoing COVID-19 pandemic. When the series of riots tore through Hong Kong in 2019, I kept myself updated with the news so that when interacting with my brother, I would not irritate him by falling for false paranoia, but instead engage him in a meaningful and informed conversation about the situation. I also did the same with my mother and girlfriend when the riots broke in Jakarta. Keeping myself updated with their local news gives me a clearer picture of the different challenges each of us is facing, and which allows me to be more empathetic with what they are each experiencing.
3. Go the extra mile for them. Often we feel powerless in alleviating the inconveniences faced by those who are so far from us. However, remember that technology has made a lot of impossible things possible. Being miles away from them does not mean you are unable to act for them. For the past two months, I have been assisting my mother in getting her health supplements and necessities through Shopee, a popular eCommerce platform in Jakarta. I sourced the items, made the order, and simply provided her with the internet banking number to transfer the payment to (thankfully she knows how to use internet banking). Similarly, when my girlfriend accidentally broke her iPhone 11 case, I got a new one shipped to her in one day so that she does not have to go out and get it herself. They may be small acts in the grand scheme of things, but it shows that you are with them in this trying time.

Extraordinary times do not always require extraordinary measures, and the above three points prove that. They are simple and very much within your means. Yet I firmly believe that they will go a long way in keeping you and your loved ones engaged and connected while riding out this COVID-19 pandemic, or any situation that reduces mobility. Hopefully, when it passes, all of you emerge stronger and more bonded than ever.

Creating an immediate plugin-document-plugin loop based on where the user focuses.

One of the most confusing parts of writing a Figma Plugin is differentiating between the code.ts and ui.ts (or the JS script within the ui.html file). The way I understand them is as follows:

1. code.ts contains the code that is executed on the main Figma Document UI. It has access to the Plugin API as specified in the figma.d.ts file.
2. ui.ts (or the JS script within the ui.html file) contains the code that is executed when the user interacts with the Plugin UI (rendered as an iFrame). It does not have access to the Plugin API.

In many cases, a plugin you are trying to create requires it to extract some information from the Document UI (e.g. current selection). It will then present this information to the user, who then makes some changes or decisions based on it (e.g. wanting to change the size of the selected rectangle). Once the user decides on the appropriate course of action, the plugin needs to tell the Document UI to execute it.

In order to facilitate this two-way communication, Figma designed a protocol similar to Events for its Plugin API. You can read all about it by going to the official documentation.

What I want to show you in this article is how to use this protocol to allow the Plugin UI to be aware of changes made in the Document UI without having to re-instantiate itself. In other words, I hope to show you how to establish an immediate plugin-document-plugin feedback loop using the above protocol.

Essentially, the trick is having the Plugin UI inform the Document UI when the focus is back on the former and then having the latter send an immediate response back. Take a look at the ui.html and code.ts files below:

What happens is that when you first launch the Plugin, the figma.showUI(__html__, uiOptions) is executed, which renders the Plugin UI. The focus is also automatically set to the Plugin UI.

When the user shifts focus out of the Plugin UI, nothing happens. However, when the user focuses back into the Plugin UI, it runs the window.onfocus code block, which contains a parent.postMessage call that sends a message back to the Document UI. Notice that instead of sending a simple data type, I decided to send an Object. This allows for the flexibility needed in more complex plugins should there be different types of back-and-forth communication between the Document and Plugin UIs.

When the Document receives the message from the Plugin UI, it runs the code block within figma.ui.onmessage. In this case, since the Plugin UI has sent a "focus" type of message, it increments the count variable and sends it back to the Plugin UI.

Finally, the Plugin UI, on receiving the reply from the Document UI, updates the HTML and shows the count as the number of times the user shifts focus out of itself. This is how the working prototype looks like:

Extending this into a more complex communication mechanism only takes coming up with multiple types of messages which would take different ways of handling within the code.ts code block. Conversely, you may also introduce a type key for the message from the Document to the Plugin UI should you require the extra flexibility on the Plugin UI-side as well. Here is an example of how I used the above implementation to automatically change the suggested name in the plugin’s textbox:

And that is how you fetch updates from the Document UI to Plugin UI using the messaging protocol of the Figma Plugin API!

Note: If you want to see the source code, just click on the “Communication Snippet” GIF above.