DEV Community: Albino Tonnina

Rebuilding My Portfolio: A Week of React, Animations, and Testing

Albino Tonnina — Mon, 07 Jul 2025 15:04:37 +0000

After years of inactivity, I decided it was time for a complete overhaul of my personal portfolio. What started as a simple "let me fix this one animation" turned into a week-long intensive refactoring session that transformed the entire codebase.

🎯 The Challenge

My original portfolio stopped working because of many deprecated dependencies. The animation system was monolithic, testing was sparse, and adding new features felt like walking through a minefield.

🚀 What I Built

Complete Animation System Overhaul

The biggest change was moving from a single, monolithic animation controller to a modular scene-based system. Each section of my journey (freelance → company → ASOS) now has its own self-contained scene with dedicated animations.

// Before: One massive animation controller
const animateEverything = (progress) => {
  // 500+ lines of mixed concerns
}

// After: Modular scene management
import { deskScene } from './scenes/deskScene'
import { spaceScene } from './scenes/spaceScene'
import { contactsScene } from './scenes/contactsScene'

const scenes = {
  desk: deskScene,
  space: spaceScene,
  contacts: contactsScene
}

Brand New Visuals and Interactions

Each career chapter now tells a visual story:

Desk Scene: My freelance days working from home
Space Scene: The journey to London and ASOS
Contacts Scene: Opening doors to new opportunities

Comprehensive Testing Infrastructure

Testing animations is tricky, but I managed to achieve 90%+ coverage using:

// Testing animation state changes
it('should progress through scenes correctly', () => {
  const { result } = renderHook(() => useAnimation())

  act(() => {
    result.current.setProgress(0.5)
  })

  expect(result.current.currentScene).toBe('space')
})

Custom SVG Processing Pipeline

I built a custom webpack plugin to optimize and process SVG animations:

// SVG ID processor for animation targeting
class SVGIdPlugin {
  apply(compiler) {
    compiler.hooks.emit.tapAsync('SVGIdPlugin', (compilation, callback) => {
      // Process SVG files and assign unique IDs
    })
  }
}

🛠️ Technical Stack

React 18 with hooks for state management
Custom animation system using D3 interpolation
React Testing Library for component testing
Webpack 5 with custom loaders and plugins
ESLint + Prettier + Stylelint for code quality
GitHub Copilot for enhanced development workflow

📱 Performance Optimizations

Mobile performance was crucial, especially for iOS Safari:

/* Viewport optimizations for iOS */
.animation-container {
  transform: translate3d(0, 0, 0);
  will-change: transform;
  backface-visibility: hidden;
}

I also implemented throttled scroll handlers and IntersectionObserver for efficient animation triggers.

🧪 Testing Complex Animations

One of the biggest challenges was testing scroll-based animations. Here's how I approached it:

// Mock IntersectionObserver for testing
const mockIntersectionObserver = jest.fn()
mockIntersectionObserver.mockReturnValue({
  observe: () => null,
  unobserve: () => null,
  disconnect: () => null
})

window.IntersectionObserver = mockIntersectionObserver

🎨 Animation Debugger

I built a timeline debugger to visualize animation states during development:

const AnimationDebugger = ({ scenes, currentProgress }) => (
  <div className="debug-timeline">
    {scenes.map(scene => (
      <div 
        key={scene.name}
        className={`scene-marker ${scene.active ? 'active' : ''}`}
        style={{ left: `${scene.progress * 100}%` }}
      >
        {scene.emoji} {scene.name}
      </div>
    ))}
  </div>
)

📈 Key Metrics

After the refactor:

90%+ test coverage (up from ~20%)
Modular architecture with 8 separate scene files
Enhanced mobile performance with iOS-specific optimizations
Custom tooling for SVG processing and animation debugging

🤔 Lessons Learned

1. Modular Architecture Pays Off

Breaking the monolithic animation system into scenes made debugging and extending much easier. Each scene can be developed and tested in isolation.

2. Testing Animations is Hard but Worth It

Finding the right abstractions for testing scroll-based animations took time, but the confidence it provides is invaluable.

3. Performance Matters on Mobile

iOS Safari has specific quirks that required targeted optimizations. Always test on real devices!

4. Developer Experience is Key

The animation debugger and GitHub Copilot integration made the development process much more enjoyable and productive.

🌟 What's Next?

The new modular system makes it easy to add new scenes and animations. I'm already planning:

Interactive scene selection
More detailed micro-interactions
Performance monitoring dashboard

🔗 Check It Out

Live site: albinotonnina.com
Source code: github.com/albinotonnina/albinotonnina.com

The code is open source under CC BY-NC-ND 4.0 - feel free to explore and learn from it, but please don't use it as your own portfolio!

What's your approach to portfolio development? Have you tackled similar animation challenges? I'd love to hear about your experiences in the comments! 👇

11 reasons why I love working from home

Albino Tonnina — Fri, 14 Aug 2020 07:37:35 +0000

Here they are:

I can concentrate. To perform at best, I need to get into the Zone. In an office I don't get into the Zone as much as I'd need to. I'd also need to see my colleagues from time to time because well, they are people I share a lot of time with. Let's meet regularly in the office to catch-up and socialize a bit?

I can communicate better. This may not apply to many. I am a non-native English speaker. Reading comments is easier to me. In online meetings I can concentrate on the voice of the speaker. I can even turn on live captions on some video conference services.

Waking up is not stressful anymore. I'm not a morning person, I do best later in the day, that's when the magic happen for me. My morning routine went from a 12 step process to a 3 steps process, wake up, prepare both mentally and phisically, work. I don't miss the lost extra steps, one of which is:

Commuting. Some of you are happy to, I don't know, take a bike a cycle to work. Personally I see commuting as a daily loss of 2 very precious hours stuck in a too-full-to-be true set of n trains. With those two hours I now can:

Do extra work if I want to. I don't need to rush it, I don't need to prepare to leave the office. I can finish the bits I want to finish for the day, peacefully. Or...

Spend more time with my family. Play with my baby, watch her growing right in front of my eyes. See, on a daily basis, if I haven't been on 3 trains to rush home, I'm more calm, and more grateful, and more happy to help at home. Help my baby, help my wife. Or sometimes, I could even

Relax. Yes, play a game, indulge in my hobbies some more. Or even better, go outside for a walk, maybe with the rest of family. Go for an ice cream with the

Money I saved. Cooking is cheaper than eating out, right? I'm also quite certain it's healthier. So I'm calmer, I can focus more and I eat better, I can now spend some money and time to

Fix my house! At 6 in the evening I'm not too tired to hang a picture or swap furniture around to see how it looks like. I can take 20 from work and go mount that new towel hanger in the bathroom I've been planning to fix for months. I would catch-up with work later! Or, instead of fixing something, one day I may need to

Take a nap mid day. Uhhh. Some days it's 3 o'clock in the afternoon and my eyelids start getting heavier and heavier. In the office I usually soldier on, I try as much as I can to stay vigil. Well, I think nobody now will be hurt if I take a 30 min nap in my bedroom instad. A power nap, the ones that make you feel better after you had one. All of this really contributes to my

Mental Health. So I don't see a reason why I should not be doing this in the foreseeable future. Leave comments about your experience if you want.

Hello!
My name is Albino Tonnina, I'm an italian web engineer in London.

Cover image uncarefully screenshotted from my website: https://www.albinotonnina.com

The most gratifying work I’ve ever done

Albino Tonnina — Mon, 03 Aug 2020 18:30:03 +0000

And the lessons I learned doing all the others

I’ve been doing web development for more years than I would admit.

Good projects, terrible projects, amazing projects, some I still remember, some I completely forgot about, I did them all.

One in particular, a work I commissioned myself really, is the website I made in 2014 to make my skill set a bit more attractive and get a job abroad. What a pivotal moment in my life that was.

It took around 3 weeks to be completed, 2 days to do the bulk, the rest to refine it.

What I didn’t expect was this enormous amount of positive feedback I received, and still receive, for this work.

That’s how it was in april 2014: https://v1.albinotonnina.com

It must have been perhaps some novelty element in it (I like to call it a scrollytelly website), or the fact that I made it open source on GitHub from the beginning. It did get attention.

One or two months later I updated it with the news about my job search: https://v2.albinotonnina.com

Imagine my joy, landed in London, working for a prestigious tech company, everything was absolutely new and inspiring.

Time passed, the website did its part and that would have been it for me but people kept sending me these amazing messages!

I put together enough compliments to feed my ego for the decades to come but what made me really proud were those messages full of sentiment and soaked in inspired words, written by beginners, undergraduates, self taught folks who saw the website and had their passion for web development renewed and reinvigorated.

That is why my website is the most gratifying job I’ve ever made.

I decided not to let the website die and in 2017, with the benefit of a much improved skill set, I gave it a fresh coat of paint: https://v3.albinotonnina.com

And 3 years later, August 2020, days ago, another coat: https://www.albinotonnina.com, the current one

If you asked me in 2017: “Do you have much more to learn?” you would have heard a silly answer. I couldn’t even imagine.

In 2020 I’m wise enough to say that I will never end learning how to do this job.

Nonetheless I did put together this little list of lessons I learned during my career as a web developer, since I get asked that often.

Here it goes:

The best skill a developer can have is persistence. This job involves solving a gazillion little problems, all the time. Sometimes you solve a problem just to create more of them. Persistence.
If you feel down and not good enough, remember that there are no heroes here, everyone is probably doing their part just as you do.
You will be wrong about something so many times. It’s OK.
People know that thing they know that you don’t know because they probably did that thing repeatedly. You will know a lot about that thing, as long as you really do that repeatedly.
If it’s not coming out right, you could just start again. It’s amazing how much one can improve by starting to solve a problem from scratch once you know what you’re really dealing with. Sometimes you mess up and lose code and hours of work altogether. Consider the silver lining there. It really works for your personal improvement, it’s simple repetition.
You cannot solve all the problems all together. Find your system, deal with the micro problems after you have dealt with the macro problems. It’s important to aim at organizing ourselves as much as possible to work in an orderly way.
It’s never as hard as you think it is. Most of the time it’s just new jargon, it’s just a bit of darkness before the light. Persist.
Don’t try to solve a problem at all costs. Sleep on it. Seriously, it works.
Seniors are old juniors. The problems are the same, it’s the speed in solving them. A beginner dealing with a complex problem needs to read every sign on the sides of the road, an experienced developer did that trip a few times already. Simple muscle memory.
Sometimes all you see in one day are error screens, error after error. Persistence.
Don’t rush it. Review your work with a cold mind before you publish anything.
Ask for early feedback, you reached a milestone in your current project? Show it and listen carefully at the feedback.
When you get the feedback, accept and understand it. Feedbacks are precious material, it’s the lenses to look at your work that you cannot possess.
Learn how to filter out info when you are briefed for a new piece of work. Unfiltered data is overwhelming for everyone. Don’t assume you’re getting briefed correctly, if you get lost most probably it’s not you. It’s bad info. Ask for clarification everytime you need it. It’s so worth it.
Never criticize the code you’re about to work on unless you are very aware of the circumstances and the context that code has been written.
I search on Google or Stack Overflow all the time. For 2 reasons: I don’t have a good memory and I want to check if someone came out with new and better solutions than the ones I already know.
Eagerly learn your keyboard shortcuts. It also makes you look cooler. Really, it helps keep you focused while working.
With time your project’s code should get simpler and simpler. If your code starts to look like the one you see in the movies, abort. And restart.
Reached a little milestone? Accomplished a bit? You like what you see? Save it. SAVE IT. Save it and commit. I repeat, save it and commit.
Commit all the time. Not sure I mentioned that already.
The job of removing code while refactoring your work in progress should be one of the best moments of your working day.
Get closer to the metal. Or at least tend to. The more you do, the more you understand the why of the surface layers. Go straight to mdn (for web), instead of stackoverflow. Dig deeper.
Your first iteration is most probably poor. Add your tests now, then refactor your code.
’cause you do test your code, right? Test all the things. Want confidence in your code? Be good at writing your tests. There is no better other way.
If your code stops working all of a sudden, nothing works, then it’s probably a very tiny change somewhere. Did you commit last time you liked it? Did you write your tests? Good, it’s now easy to see where that tiny little insidious bug is.
Have a storyboard of some kind when you start something new. You won’t necessarily follow it but at least you won’t get lost easily. Very important when you work on multiple projects and need to switch context often.
But try not to switch context often. If you have work coming from all sides make clear that you will be concentrating on one piece of work at a time.
Working in parallel may be very unproductive. You wouldn’t feed your baby while trying tightrope walking.
Never skip the documentation of a software. You’ll regret you didn’t check the docs first.
If you solve a problem by mistake, counterintuitively it’s usually bad. You may have created more problems. Be sure about everything. Easy if you have written your tests!
Don’t try to sneak in bad code in the projects you work on, it will always, always, come back to bite you in the behind.

Thank you for taking the time to read this. I’ll be seeing you in 3 years with a new version of this website :)

My latest articles

How to Lose an IT Job in 10 Minutes

Speaking of web layouts…introducing the Magic Hat technique 🎩✨

Designers are from Saturn, developers are from Jupiter: or, why communication matters

Follow me on Twitter and LinkedIn!

Do you want a Design System at ACME inc?

Albino Tonnina — Wed, 13 Mar 2019 20:28:42 +0000

If yes, that’s how I would make it happen

In general, a Design System could be loosely defined as a system built to serve teams, to develop and ship features more efficiently to form a more cohesive customer journey across all the applications.Ecosystem quality through consistency.

Product development is our core business. In our world, our software is in a perpetual state of evolution.

Features are added constantly, while our backlog keeps being fed with corrections and updates. The resources are not infinite, engineers and product designers are constantly busy following the roadmaps.

How do we think we will be able to build even another product such as a Design System when we are already almost buried with features to build? We don’t have enough resources or time. We have many features waiting to be built. We cannot stop the Machine to build and implement a Design System now.

Cohesiveness IS a feature

The ultimate goal of our Product Design department is to achieve a Unified User Experience across all our Products. It is important for our business. It’s what the market wants, it’s what customers want, it’s what every employee of the company wants. Guaranteed.

Design Systems has essentially that purpose, to offer a consistent user experience across products. It does it by consolidating a visual language amongst other responsibilities. Maybe your company has already a visual language built by the Design teams although the lack of a system that connects it with developers lead to problems during the development. Also distributed teams and remote offices could interfere by adding some more obstacles to the process. Design Systems promise cohesiveness as the main outcome.

Designers will be definitely happier and more engaged. Designers hate inconsistencies.

We will deliver features quicker

A Design System produces a UI component library and UX patterns. It’s the result of the communication between Designers and Developers through the system’s shared language.

Product Design and Engineering could benefit enormously from this outcome. Product teams will speed up gradually to a new level by ceding small solutions to a shared effort.

PMs will definitely like this.

We will produce better code

Engineers will worry less about the concerns related to the UI aspect of the products and concentrate more on the business logic. And Engineers in general hate that part of the job anyway.

Less time spent on fixing a layout also has the potential of making the process of visual QA much smoother and lean: having an autonomously tested and controlled UI library guarantees automatically the integrity of the UI.

The Component library also helps our software to be more modular and scalable.

Developers would love this.

Will produce less documentation

Shared languages, shared practices, they all help in making the documentation needed for each feature lean and smart.

Who likes to read documentation anyway?

Everyone will participate

Here’s a great thing about Design Systems, they are great for collaboration. Everyone is called to participate. From departments to teams, to individuals.

Every engineer and every designer will be naturally exposed to the UI library in their daily job so the familiarity with it could encourage knowledge sharing and engagement. This is good in our world, given the high turnover and basically never enough time to do onboarding.

It will increase our reputation as a Company

We will hear about Design Systems more and more in the future, as companies are improving a lot towards the goal of having user-centered products and lean processes in the development.

This will help to attract talented professionals that are naturally inclined to stay updated with the latest cutting edge technologies.

We could also attract them by sharing the experience of building a Design System through articles and presentations.

It sounds interesting, now estimate

A Design System is a living, funded product with a roadmap & backlog, serving a larger ecosystem in order to achieve a Unified User Experience. Nathan Curtis, EightShapes

We need a multidisciplinary committed team

A product needs a team. All members are committed at half-time capacity or less, otherwise remaining committed to the other products. The members of the team can rotate/mutate on a per need basis.

Teams won’t work alone. Their job is to involve teams working on products when needed. Think of the system’s team as both builders and researchers.

We need a roadmap

A roadmap reveals a System’s direction.

It enables a design system team to convey:

commitment to delivering value, justifying their well-defined funding
transparent priorities, especially critical when serving products and platforms with divergent interests
reliable cadence that customers depend on

Roadmaps highlight the most important elements of each release, charting the system’s direction without drowning in detail. Organizing that simple story into a a milestone based, columnar roadmap format works wonders.

One of the first assignments of the Design System team will be the definition of a rough, open to modification/extension, prioritized list of tasks.

A responsibility of the team during the execution of this important task will be engaging with the other teams and individuals that contribute to the development of our products.

We need a workflow to design and build components

The System’s team will make most features — visual style, UI components, documentation tooling, UX patterns, and more — by following simple, identified steps of discover, design, build, documentation, and publish

A defined workflow helps a team mutually understand the scope, reviewers, tools, and the definition of done at each step. With a workflow, collaboration tightens, delivery quickens, and the team predictably delivers features.

A QA checklist is also essential. Visual quality, functionality, compatibility are parts of the checklist.

We need a release strategy

It could be quarters, it could be sprints.

The system team will deliver an initial library that can be adopted by a predictable time. Work initially to launch a 1.0 that delivers a strong visual foundation and 12 to 16 UI components.

Those components will be the tools that designers will use to build the experiences. Developers will do the same having those parts ready to be implemented in their codebases.

After 1.0, we need an adoption strategy

The modular nature of the system let the teams adopt it in bits, gradually. We can identify which product could be our beta tester, for example. Or start implement the system incrementally on every product.

We need to wait 1.0 to start adopting the system?

With fast release cycles or continuous integration, it just sounds right to use the time spent on features to gradually build the library, basically while we go.

I see a problem with this approach. Unlike a feature-based release, I think that a Design System has the duty to be a language with an already established grammar and vocabulary even in the early adoption phases. Letters (components) must combine in infinite meaningful ways (interfaces) so then we can build meaningful sentences (products) with them. The language (system) is created and ready to be used.

Conclusion

Having/maintaining a Design Systems is proving a good choice in more and more companies. I think a Design System would be an important and invaluable product in your company. It won’t produce features by itself but it will serve the other products. It will have a cost at the beginning and no tangible returns, yes, in theory. Practically I see benefits from day one: Design and Engineering in the same room producing the product that will allow them to speak one common language.

I didn't write this very recently.

This article was in my drafts section since 2017. Do you think it's still relevant? Let me know!

Thank you for reading

Do you have positive experiences to share?

Hello, my name is Albino Tonnina, I’m a Software Engineer who works in London, you can find me on Twitter or Github or Instagram or around the city.

My latest articles

How to Lose an IT Job in 10 Minutes

Speaking of web layouts…introducing the Magic Hat technique 🎩✨

Designers are from Saturn, Developers are from Jupiter

Follow me on Twitter or GitHub!

Designers are from Saturn, Developers are from Jupiter

Albino Tonnina — Fri, 10 Aug 2018 20:14:07 +0000

About the ‘But it looks different on the Specs’ effect, UI Toolkits and other stuff.

Two planets but at least the same Solar System! And that’s the end of the analogy with planets.

Allergy Advice

This is an article about Design Systems, particularly on the topic of UI Toolkits and the dynamics of the communication between Designers and Developers.

Designers, something tells me that you know about Design Systems and that you may dig them :) In case you want to read more, Nathan Curtis wrote a lot about it. I do love and respect his work on Design Systems.

Developers, I’m going to show some code at the end. The playground is a React + CSS-in-JS library (such as emotion or styled-components) app.

A kind of a typical scenario

Our Designer produced a series of nice designs, including the layout of our *Documents *page:

https://www.sketchappsources.com/free-source/2576-ooto-productivity-dashboards-sketch-freebie-resource.html

It’s clean, it’s balanced, it’s kinda pleasing to the eye. For the Designers, this is the culmination of a long process, a whole series of tasks involving researching, interviewing, think-ing, review-ing, rethink-ing, white-board-ing, prototyp-ing, wirefram-ing. A fu*k-ing long and tedious process that often Developers are not exposed to.

How did Designers produce this image anyway?
They probably used a design toolkit. A very popular one is Sketch.

Alas, the way this software works is diametrically opposed to the way Developers work. And I say that’s the crux of our matter.

Designers need tools that let them re-iterate quickly, reviewing and updating, feedback after feedback, stakeholder meeting after the other. *Designers need tools like Sketch. *

img: Designing for stakeholders.

Developers, on the other hand, work differently.

They works on ever-changing codebases that at any point in time must produce a working release of an application. It takes effort to implement a layout like the one in our example, designing, abstracting, implementing, refactoring, testing, reviewing, refactoring, bug fixing, refactoring. Developers need to make sure they don’t break anything else or pollute the codebase with bad, duplicated code.

img: Developers

Designers are more like jumping backwards and forwards where Developers work in a continuous loop of development.

The Visual Spec file

Now it’s time for Designers to communicate with Developers, hand off the baton.

There are layouts, spaces and colors and so on to be documented. Sketch or any other tool doesn’t know much about your current codebase, your file structure, your abstraction, so what Sketch can do? Measure things. And that’s what will be produced:

img: Developers with mixed feelings about the spec file.

A few days go by…

Stuff is ready and Designers have the first look at it:

img: Designers with mixed feelings about the final result.

Frustrated Designers, frustrated Developers.

That’s the moment when the enchantment is really broken. The Spec file. Little issues with color, spacing, typography, layout, miscommunicated details, missing behaviours.

Developers will have to interpret and adapt the specs to their own system in the codebase on the fly when they should just worry about implementing the business logic of the new feature. Designers are not to blame though, they may simply not know about such system.

My grandpa used to say:

When Designers and Developers don’t communicate well, get a Design System with a
well shared and communicated set of tools, abstractions and constrains.

You need a good UI Toolkit

It’s through a shared system that Designers and Developers can really communicate effectively without stress. A UI Toolkit aims to reinforce the principles documented in a Design System. It is governed by a highly shared and documented set of conventions, UI patterns, behaviours, designed, tested and agreed by everyone. It’s where Designers and Developers efforts meet.

Why you really need a good UI Toolkit

Is your app getting increasingly more complex?
Designers are talking quite a lot about insconsistencies on the app?
CI/CD? Going fast fast fast?
Remote teams?
Getting a bit messy with those CSS files?
Starting to care about the size of the app?
Is the User Experience at the core of your business model?

You don’t need to tick all the checks, even one may be enough :)

Why you need Your Own UI Toolkit

A Design System is all about the Language. Visual language, UI Design language, etc. It takes a lot of effort to define your own: Product, Design, Engineering, all these departments will be heavily involved.

A lot of times that’s just not a viable option. There are amazing frameworks out there, semantic-ui, ant-design,Bootstrap, Material-UI. They all come with a sort of pre-made Language and a battle-tested UI Toolkit, ready for you to use.

The catch? My opinion? Soon enough they won’t fit you anymore. You will want to evade from it. Besides, the UI toolkit are probably so engineered to be hard to control. Remember that those frameworks are made to pass countless cases, maybe more than what you need. Plus, this extra complexity is paid in kb as well.

Steal as an artist

Do not adopt a UI Toolkit. Copy from others instead, and by that I mean take the bits that fits you the most and implement them** from scratch**. It’s now common for highly user centric companies to have their own Design System, many of them open sourced!

Look at this list of Design Systems:
https://adele.uxpin.com:

BBC: Gel
Trello: Nachos
Salesforce: Lightning

and dozens more. And in the end it’s all a matter of designing and delivering this together. It’s about building something specific for your domain, also unique and representative of your brand. It’s rewarding and you get to give it a nice name too :)

Let’s make one

I’m gonna show you how easy it is to bootstrap our own Design System.

I’m gonna call it Larry.

Let’s take a little portion of our layout and try to build it from scratch:

End result first

The following CodeSandbox is the one and only app in the world that implements Larry:

You can find Larry on GitHub:
https://github.com/albinotonnina/larry

The Documentation

This bit is the most important. Who is in charge of this, maybe Designers? Well typically yes but trust me on this, you should be both equally involved in documenting your Language. You should both agree on literally everything here.

Let’s start defining some really basic conventions:

Colors

Let’s generate a palette for our layout.

I suggest to define a series of semantic names from these colors, like so:

headerText = JapaneseIndigo
paragraphText = JapaneseIndigo

elementBackgroundDefault = Snow
elementBackgroundHover =
BrilliantAzure
elementButton = LightGray — alpha 60%

These are the names you’re both gonna use when *speccing *(which is a word).

Spacing

Pay extra attention to spacing. Without a clear strategy for spacing things can go really wrong.

Define and agree on a spacing system, for example:

A spec file would look like this:

Typography

Make sure that font-sizes, font-weights, line-heights, margins, colors in your headings, your paragraphs etc just match. Call them with names you like, eg. HeaderHuge, HeaderLarge, HeaderTiny or use semantic tags (h1, h2, h3) properly. Just make sure you are aligned on this.

Patterns

What rhymes with UI Toolkit? Pattern library! You need to start populating your library of patterns. What you want is to have the components that you need to behave the way you agreed so you can compose them the way you want, anytime you want.

Start from the particles, primitives such a Box component, for when you have to set spacings and borders around something else.

Add more specialised new particles, such as a Text component or a Flex component, which you could imagine as a Box component + some flex utilities.

See them as particles that live in isolation, not aware of the context in which they will be used and of the space that should exist around them.

Continue with more complex UI Components, compositions of other smallest components and so on.

What’s important here is not the technology or which kind of abstractions in your documentation. What’s important is that you do this together.

Example of a more complex UI Component

You got the gist?

You have defined constants and you have some particles to build.

You will reiterate over this particles and extend the library pretty quickly, so embrace and prepare for elasticity. Developers, you don’t want Designers to finish *documenting the entire System before starting to implement the code. **You have to do this thing together or it won’t just take off.*

So, Designers and Developers,** **straight after the article **go make your own Larry **if you don’t have one!

Code

You have a copy of Larry, you can clone and play with it. Your Larry may be different or you may be using different frameworks so I’m going to go through the key points of this approach.

Theme, define the constants

It’s an object with our theme constants, so spaces definitions, colors, fonts, typography, breakpoints, anything. Here’s Larry’s theme, and here’s a sample version of it:

There’s no limit to the complexity/completeness you can achieve here, after all it’s a matter of generating a JavaScript object, just imagine what you could do!

This is a core file. Every color, margin or padding, font-size or font-weight or breakpoint must come from here and only from here.

CSS-in_JS libraries are amazing tools, styled-system makes them even better. It’s a set of utilities for Design Systems and consist of functions that take props as an argument and return style objects, while making it simpler to use values from a theme and apply styles responsively across breakpoints.

This approach take advantage of this utilities, feel free to evaluate it.

Plug the theme into your app

Provide those constants to your app: every component in the app will have access to our theme constants.

Create basic UI Components

a primitive Box UI Component

More specialised UI components

Here’s a Flex component.

Implement UI components in your feature files

Time to render something

This is where you implement your UI Component and your business logic.

The files structure

This is Larry’s file structure. I don’t have strong opinions on file structures, actually I believe in something different: move around your files until you feel comfortable with them.

Larry is all into a “**design-system” **folder, this is where you can find its constants and generic and reusable UI components.

Notice also the UI folder into the Document layout folder, that’s where I define and export the UI components specific for our feature.

Conclusion

With large and complex apps, it’s never easy to keep the UI consistent and cohesive. Design Systems help. Custom Design Systems and tailored UI Toolkit really help.

Designers and Developers may have very different approaches to the same problem but that doesn’t mean that they cannot communicate effectively.

https://dribbble.com/shots/2712522-Designer-vs-Developer

Thank you for reading

Do you have positive experiences to share?

Hello, my name is Albino Tonnina, I’m a Software Engineer who works in London, you can find me on Twitter or Github or Instagram or around the city.

My latest articles

How to Lose an IT Job in 10 Minutes
Speaking of web layouts…introducing the Magic Hat technique 🎩✨

Follow me on Twitter!

How to lose a Job in 10 minutes

Albino Tonnina — Tue, 12 Jun 2018 17:05:37 +0000

Whiteboard coding interviews can cost you a job

Recently I’ve been quite close to getting a job at one of the Big 5. I went through the screening process and the take-home assignment smoothly but I failed to pass one of the final stages, a set of one to one, or two to one, interviews:

Whiteboard coding interview: algorithms.
Technical interview: JavaScript, CS, React.
Culture fit: that.
Second whiteboard interview

It went wrong

There are a few mistakes that contributed to this temporary debacle.

I may have passed the techical test and the culture fit (let’s just assume that) but I admittedly performed badly at the whiteboard coding interviews.

Thinking in retrospective about that day I couldn’t expect any different outcome.

The truth is: I’m not prepared to do whiteboard interviews.

Whiteboard interviews

The whiteboard interview is, in some ways, a hybrid of a technical test of the depth of your knowledge and also a social exercise
(source)

We all know what it is, right? it’s not much about the code, it’s about your solving abilities, it doesn’t matter if etc etc…

I’m a frontend developer, I generally don’t implement interview-like algorithms or articulate my thought process while I code, I sort of make interactive UIs most the time.

How much do these tests tell about a candidate anyway?

Someone even said:

In real life, you would rarely just whip up an off-the-cuff algorithm from memory in the middle of a coding session. You are almost always going to use an existing library, which has its own test suite, and has survived the scrutiny of other developers.

The only world where you would actually need to be able to recall an algorithm would be a post-apocalyptic one, where the hard drives of all the computers connected to the internet were fried, and all copies of foundational academic papers and computer science textbooks had been reduced to ashes.

My opinion tend to match the one of the aforementioned author although I like to believe that such a skill (being good at whiteboard interviews) is about having a set of very good to have other skills, soft and hard.

Mitigating circumstances first

I’ll make this list because you may relate to some of them but most of all I still have to vent a little bit 😄

I didn’t do the interview in my first language. Under pressure and under the spot it suddenly becomes more difficult to talk in english.
I’m a self taught frontend developer. I lack an academic preparation.
I didn’t do many interviews in my career. And not many of them had whiteboard interviews kind of tests.
I don’t do much public speaking. Unfortunately, at the moment, not much.

You could object that none of these are actually mitigating circumstances and you would be right.

By definition, mitigating circumstances are out of our control: the truth is that I could improve my English, do more CS, do more interviews, do more public speaking.

I’m gonna try to solve that first whiteboard test the way I should have done that day and I’m going to try to report the process here.

The Test

;['Tokyo', 'London', 'Rome', 'Donlon', 'Kyoto', 'Paris'][
  // YOUR ALGORITHM
  (['Tokyo', 'Kyoto'], ['London', 'Donlon'], ['Rome'], ['Paris'])
]

That’s it. If you rotate the letters of each city you may or may not match another city. In case you do, put them together in a array on their own.

At work you’re escaping labyrinths of thousands of lines of code on a daily basis, how difficult is to show these people how to solve this simple and even kinda funny problem? Hold my beer.

Yeah…

Let’s pretend it went slightly differently.

The perfect whiteboard interview

Catchy paragraph title, although wrong. This is just the way I could have solved this test, both code and thought articulation. Who know how many other ways there are!

Me: thank you very much. I’ll gladly solve this problem for you (little bow)

Me: First question, do the letters just ‘rotate’ or they can be randomly mixed up?

Larry (to protect the privacy of the interviewers, I changed their name into a fancy one): Just rotate. First letter goes last, etc.

Me: right.

Larry: right.

Me: Right! I guess to start I would need a way to rotate the letters of each city. Tokyo would became okyoT, then kyoTo, oh cool! we’ve got kyoto now! Ok, I’m going to need a function to do that.

Me: I also need a way to loop through the input cities, ‘rotate’ the letters, do some matching and lastly grouping them together. I see that the input and the output are both arrays and they both contains the same values, the only difference is the depth of the two arrays, a flat one and an array of arrays.

Still me: I’m gonna write some pseudocode now to validate my thoughts. Later I’m going to test it too, cause I’m that good. 😏

function groupCitiesByRotatedNames(cities) {
  // use a variable to contain the output.
  let output = []
  // loop through each of the cities
  //  rotate the name in any possible combination
  //  check if the output contains a city that matches a combination
  //   add that city to the array containing the match
  //   otherwise add the city to the output as a new array
  return output
}

Me, confident as a rockstar: let’s pseudotest my pseudocode (😛).

const input = ['Tokyo', 'London', 'Rome', 'Donlon', 'Kyoto', 'Paris']
console.log(groupCitiesByRotatedNames(input))
// That's how it would build up. The final output would be the last array:
// [
//     ["Tokyo"]
// ]
// [
//     ['Tokyo'],
//     ['London']
// ]
// [
//     ['Tokyo'],
//     ['London'],
//     ['Rome']
// ]
// [
//     ['Tokyo'],
//     ['London', 'Donlon'],
//     ['Rome']
// ]
// [
//     ['Tokyo','Kyoto'],
//     ['London', 'Donlon'],
//     ['Rome']
// ]
// [
//     ['Tokyo','Kyoto'],
//     ['London', 'Donlon'],
//     ['Rome'],
//     ['Paris']
// ]

Let’s start implementing this algorithm.

First, the utility to rotate the letters of the city names. I will create a utility function:

Me: let’s make this function a bit smoother (and less readable). Overconfidence at its peak.

Me: Right! I like the reduce method, I’m gonna use it again! (It’s also very functional-programmy so it’s cool to use in an interview 😎)

The reduce() method applies a function against an accumulator and each element
in the array (from left to right) to reduce it to a single value
(MDN).

Our single value being the desired output.

Let’s sum up what this algorithm does:

We check for each city in the cities array, we rotate the nameand we match
every combination with the accumulator value. If we find something we add the new city to the array containing the matches (with Array.splice) otherwise we just push a new array containing our new city.

Et voila’:

All together now!

Get the Gist here.

The actual whiteboard interview

I started from the solution. I said, ok, I’m gonna need a reduce method. I immediately approached the board to write actual code without really knowing the plan. I did have an idea of the solution, pretty much the one I wrote in the previous chapter, but I didn’t articulate it, I didn’t really explain it consistently to my poor interviewers. So I got lost in the code, I lost the the train of my thoughts several times, I also stumbled on syntax errors, in a mix of poor written pseudocode and actual code. There was no way to turn the tide at this point. A performance like this can make a lot of damage to the outcome of the interviews, especially if you let this affect the rest of the process on your side.

What should I do now

Practice, practice, practice.

Get a whiteboard, pick a problem and talk out-loud to the air and write, do that a lot.

Practice the whiteboard interview, learn the routine. Your routine, any routine. Learn it like a song on the guitar, a card trick or whatever dangerous stunt with your skate.

You need to prepare a speech, it’s like a presentation.

It’s like a presentation with variables.

A variable is the problem.

I’ll go like this:

I’ll spend some time analysing the requirements (1 min)
I’ll formulate questions if necessary and get answers (3 min).
I’ll pause and think of a direction to take (few min, don’t be afraid to stay silent for a while).
I will propose initial solutions and get feedback from the interviewers (5 min).
I will pause again and choose a solution (2 min).
I will write pseudocode (5 min)
I will test my pseudocode (5 min)
I’ll finish by transforming the pseudocode into actual code. (until necessary)

In around 30 min I will have solved the problem in a enjoyable and ordinated way.

Conclusion

Thanks for reading

And Thanks Adam Mackintosh and Josh Comeau for proof-reading this :)

Hello, my name is Albino Tonnina, I’m a frontend engineer who does bad whiteboard interviews at the moment and works in London, you can find me on Twitter or Github or Instagram or around the city.

You're going out of scope, again.

Albino Tonnina — Thu, 03 May 2018 10:47:40 +0000

Hello,
I'm a front end developer, I work in a Saas company.
Various apps/projects, agile approach, Jira tickets, git, teams. That is the gist of it.

I have one problem. A technical one, maybe behavioural, maybe moral:
when I get assigned a new story I struggle to stay in scope.

I'll go with an example:

An app with not more than 3 dozens React components, a fairly complex Redux store and a few API calls. It's not a massive app.

My story is to add, conditionally, a new level of nesting in a list: now some items have subitems, need to change the UI, probably mess a bit with the state/store.

The code app in my opinion is hard to read, eg. every react component is HOC'ed with a redux wrapper. Or state has too much derived data in it.
Or the file structure is wrong, components have long names, they are organised by type, not by feature and there's a lot of them now.
Or there is no strategy in regards of code formatting, I want no semi, my colleague does. Etc.

I'm not blaming someone else, I was part of the team that made the app like that, months and months and months ago, at the beginning of our React journey.

During this time I obviously improved so that code, that I feel responsible for, I just cannot accept it. Actually it became so complex that I'm struggling to reason with it!

Assume I'm the only one working on the front end of this app at this moment.

I'm about to go over time because I started to send PR with refactors: prettier on pre-commit to keep it consistent on git, organize the files in the area around my story by feature, remove nested redux HOCs and just pass props 1, max 2 level down and other small refactors. I'm also coding the actual story I was originally assigned but this is obviously taking more time.

I could have proposed the changes, worked at my story and maybe later, in the future, implement those changes following the process.

Making this 'big' changes, not strictly related to the assigned story is not right.
It may ruin other people plans. It's just not really good. But I kinda forced my stakeholders into taking those changes.

Although now the code is already in a much better state and I can finally work with it effectively.

What should I've done?

Introducing mmarkdown

Albino Tonnina — Mon, 23 Apr 2018 01:02:15 +0000

Markdown on caffeine.

Have you ever wanted a bit more from your markdown files?

Introducing Markdown.

Mmarkdown takes a plain markdown file and generates a copy of it.

It starts to be less boring when you add fenced code blocks with the language identifier set to mmd.

For example:

will output:

Hello Jessie

How it works

Everything that is returned (as a string) from the code in a block will be interpreted and replaced to the block in the output file.

It's full async, which is cool, lots of awaits are waiting for you there but soon enough you will face a problem: too much code to write in a markdown file! Terrible experience!

The solution in mmarkdown is in the scripts option.
You can pass the path of a javascript module in your app to the mmarkdown command.
The module that the scripts file returns will be passed to the context of the fenced block, eg:

This block:

//scripts is passed

const array = [1, 3, 5]

const something = await scripts.processMyArray(array)

const myFinalString = something.map(item => '#### ' + item.name)
  .join('\n\n')

return myFinalString

and this script file:


module.exports = {
  processMyArray: async array =>
    new Promise(resolve => {
      setTimeout(() => {
        resolve(
          array.map(item => ({
            name: item + ' async'
          }))
        )
      }, 1000)
    })
}

will output:

1 async

3 async

5 async

(The setTimeout is there just for demo purposes)

Backup

The backup option, false by default, will make a copy of the current output file, postfix it with a timestamp and move it into backupPath.

Can you imagine an use for this?

Share it in the comments!

Thanks for reading!

Don't forget to add me on Twitter ok? :)

TDD, all the time?

Albino Tonnina — Thu, 29 Mar 2018 16:38:27 +0000

You actually do TDD all the time? Sometimes? When fixing bugs? When doing APIs, when doing UIs, when?
Or you do DDT, development driven testing?
Ok, I just made up the last one.

I find it an amazing approach, I rarely do it. When I know exactly what I'm gonna code yes it just works.
Most of the time though I reiterate so much on my code that it just does not feel right. I prefer to finish my code and then add tests to them.
This obviously need some forward thinking.

So I'd say: I think in TDD, I don't do TDD.

What about you people?

GraphQL, pronunciation

Albino Tonnina — Wed, 28 Mar 2018 11:31:34 +0000

I'm starting to like graphQL so I wanna get this right :)
Is it 'graph-cue-el' or 'graph-cool'?
I hear both, what are your thoughts?

Speaking of web layouts. Introducing the Magic Hat technique 🎩✨

Albino Tonnina — Mon, 26 Mar 2018 14:23:04 +0000

Can you think of one of the apps you're working on and imagine the following technique applied to parts of it? Then, would you use it?
The reading should take around 5 minutes.
Thanks, Albino.

[Original post on medium.com]

Once upon a time (few weeks ago) I’ve been asked to work on a new product. “Start solo withUI & FE, it’s greenfield, feel free to experiment.”
I guess that my response, something like “all right”, was a bit underplayed.

Sadly, a couple of long long weeks later I didn’t have a clue about how to build an interface for this application.

I said ok, think, we’re gonna need a header, we’re gonna need a footer and we’re gonna need a sidebar, that’s all I know. We will then start making pages and we will put the importantstuff in the remaining white space, you know, the app, the , the core, the juice, the whatever the user should be playing with.

Something like the next picture here, right?

This is my canonical idea of a web app

I said to myself: No! Wrong! I already put myself in a cage and I’m barely prototyping! These flows are too complicated to be packed into these A4/Letter frozen frames, I said. I’m gonna spend ages figuring out the user flows here. Let’s change perspective. Let’s go all the way holistic on this! I said it out loud this time (I’ve got a bit dramatic at that point)

I wanted to make something complex look very simple. I wanted to give the user a strong feeling of control. I wanted a smart app and I’m not sure I’m doing the right thing here.

Procrastination to the rescue!

I was obviously looking into my phone to enjoy a totally deserved break after these intense brainstorming sessions between me and myself.
You know it, mobile UIs look so clear compared to the ones I build for web apps. The UX there is just right, the cognitive load is low, the motions are just yummy.

That and React, that’s where this idea of the Magic Hat technique comes from. And lots of energy drinks.
The declarative, functional, reactive sides of React, mostly, and the modularity.

🖼 The MUV

I’ve got this image of a Minimum Usable View, a piece of UI that would do just one thing, in isolation, almost pure, like we do in code. Something the user could center with, concentrate on, work with. Something like React components! Smart bricks in a bucket that do one thing that you, or the user I say, can put together.

Wait!

Two MUVs could be better than one actually, if they somehow complement each other. Not three, definitely not four, that would be a lot to process for my brain.

Two MUV (Minimum Usable Views), totally made up acronym by the way.

Looks like a one window drill-down UI pattern but with two, ahem, MUVs. 😎

When everything’s on one screen or window, the options at each stage are clear, and the user knows they don’t need to focus their attention anywhere else.
Pattron

Quite good for user’s cognitive load: there is not much going on inside the screen, justwhat you want the user to focus on.

Each MUV can and should be designed in almost complete isolation, like a black box: things get in, the data, and things get out, something like declarative intentions: the user expects to do that on the next frame.

Yes, because, like a Singly Linked list, each MUV sets what goes next.

A Singly Linked List is a linear collection of data elements, called nodes pointing to thenext node by means of pointer. It is a data structure consisting of a group of nodes which together represent a sequence. Under the simplest form, each node is composed of data and a reference (in other words, a link) to the next node in the sequence.
Wikipedia

The thing is that at any given point the screen is showing you only two related pieces of UI.

The right view is something the user wanted to happen in the left view, which is the right view of a previous left view, which is the right view of a previous left v…
[…]
[…]
..ich is the right view of the first view.

The motions

Naturally, a technique like this really depends on motion.
The UX in Motion Manifesto is a must read article.
Of the 12 principles it describes, I think the one that apply the most are:

3) Parenting: Creates spatial and temporal hierarchical relationships when interacting with multiple objects.

6) Masking: Creates continuity in an interface object or object group when utility is determined by which part of the object or group is revealed or concealed.

By the way why this name, the Magic Hat technique?

So I can use these two emojis together 🎩✨ and well, it’s like that: in a view the user canpick the next thing to put on screen. It’s pretty much it.

🏖 The code sandbox

First, a basic basic demo in React to show the mechanics.

🎡 The actual demo

The following one is a little app I put together. I hope it gives you the idea.
From a technical point of view each MUV is naturally independent so building an app likethis is quite trivial, since you build each UI in isolation. The piping in the UI is done by the implementation of this technique (I did one in React)
The views get the space they want by the way and they can be styled anyway you like. I like to have mine flex. I love flex. And React Portal.

🎩 https://albinotonnina.github.io/demo-magic-hat/

Advantages?

Imagine how scalable this could be. Adding a feature (one or more MUVs) would not break any layout. You just pipe in new MUVs and add links so to open them from any other MUV.

For the user this should be kinda natural if you think about it. It’s not different from thebrowser experience with the back and forward buttons. It actually works the same way. It’s the user that create his own path.
This path would be the list of MUVs that the user choose to open, a list ready to be persisted or tracked, also.

🛠 The React library

This is something I would never dream to do without a UI framework such as React, or Vue, orthe next one probably.

Introducing react-magic-hat 🎩✨

Features

⚡🚀 Blazing fast. 60+ FPS hardware-accelerated CSS transforms, using the FLIP technique. Fluid and performant.

🎈Extra light, only 6.5kb and no dependencies.

🧘‍‍Flexible, stateful or stateless (you get both components) and UI-less, you do the layoutingand styling.

🎛 Highly configurable, hope you like the API!

Conclusion

This is a technique with the purpose of reducing the the total amount of mental effort thatis required to complete a task involving processing of information, in short cognitive load, by limiting the amount of UI on the screen in favour of a runtime-like linked list ofsequential independent UIs called MUVs (Minimum Usable Views)

I don’t know how much of an app you can do using this technique, or if the previous sentencemakes any sense to you, but so far I’ve been satisfied every time I did experiments with it.

We sure should never stop experimenting and pulling things out of out magic geeky hats 🎩✨

My name is Albino Tonnina, I’m a developer in Workshare, London.
I owe a lot to this company, I learned there that I have a lot to learn, always.

You can find me on Twitter or on GitHub or you can check my website.