yannisabel.com

Development of a portfolio website

This is the website you are currently on and it's developed with React.

Look backward

Since I work I have a portfolio. When I was Graphic Designer I had an online portfolio on behance and a book with my main work printed on glossy paper.
When I started working on the web area it was obvious for me to create my own portfolio. It was the first website I developed during my first web training.
I really like to take screenshots of my old projects. When I look backward I realize what I have accomplished. It's very important for me to do that because it helps me to see my progression.

Here is a little preview of the evolution of my portfolio over the years

Preview of graphyzart.fr my first website online
graphyzart.fr was my first website online. It was in 2013
second portfolio on yannisabel.com to separate it from my blog graphyzart.fr
graphyzart.fr became a blog on visual art and I created a new one for my portfolio in 2015 on yannisabel.com

Note: graphyzart.fr doesn't exist anymore. After several years I took the decision to shut it down to have more time for my personal hobbies (music, drawing, writing...).

The thing that makes me laugh is my color scheme. Since I started working on my personal website I always kept my blue and orange colors. Currently I know the hexadecimal code by heart.
The first website was in between skeuomorphism and flat design and the second totally flat (even the shadows).
Both used only HTML, CSS and jQuery.

The current website

First of all I asked myself why I wanted a portfolio. What will be the purpose of it?

I just wanted to share my experiences, my work and introduce myself. As simple as that. So just few pages with my portfolio on the homepage.

Orchestra Design System

Because it's my personal website I created a methodology to create my Design System with more flexibility. I'm a musician since I was a kid so it was natural for me to think about a music correlation. There is a certain hierarchy in music that can be similar to an interface.

Inspired by the Atomic Design methodology, I started working on Orchestra a brand new Design System that bring all I needed for my interface.

The first thing was to divide my components in a new hierarchy following music convention naming :

  • instruments: Gathered all components properties tools needed to create the interface
  • symbols: Gathered all the smallest components that cannot be splitted in multiple parts without loosing their functionnality
  • scores: Gathered some symbols to create a more complex component
  • masterpieces: This is the result of all elements working together (similar to the final pages)

In music the instruments are the tools we need to play music. But an instrument had no purpose if it doesn't play notes with rules like rythm, tempo, harmony and so on. However those rules means nothing without instruments to translate them into sound.
That's why in Orchestra instruments are useless without symbols, and all symbols are played by instruments.
The scores are symbols assembled together to create a melody (generaly noted on scores). Without symbols all scores would be unreadable.
Scores together create the masterpiece that the orchestra can play.

There are different type of orchestra depending on the masterpiece itself. The type and the number of musicians will adapt to the masterpiece. For instance, sometimes there is a choir section and sometimes there is not. Same for each section of the orchestra.

This kind of adaptation and modularity was exactly what I wanted for the creation of my Design System so I call it Orchestra.

I already used Atomic Design on some projects and sometimes it feels like we have to tweak it a bit.
In his book about the Atomic Design Brad Frost says:

“Atomic design” as a buzzword encapsulates the concepts of modular design and development, which becomes a useful shorthand for convincing stakeholders and talking with colleagues. But atomic design is not rigid dogma. Ultimately, whatever taxonomy you choose to work with should help you and your organization communicate more effectively in order to craft an amazing UI design system.

— Brad Frost, Atomic Design, chapter 2 Atomic Design Methodology

Exactly what I always thought about modular design, thanks Brad to be such an inspiration!

My design was already there I just needed to put name on things and, even if I work alone on my own website, that showed me some mistakes I made on my interface. I never used the same spaces everywhere, I was not using elements the right way or at the right place and so on.

After that I recreated some of my components to make them more reusable with variations.

Some of my symbols can take multiple modifiers to adapt themselves to their environment or their purpose.
The modifiers are: the model, the state and the color

This part was largely inspired by Emma Bostian's work on a React button.

Adapted to a button component, here is what it looks like:

Button.tsx
// Naming convention
// ${name-of-the-component}-${first-letter-of-the-type-of-modifier}--${name-of-the-modifier}

// example of classes generated inside the button component with the modifier passed as props
getButtonClasses() {
    const { model, state, color } = this.props
    const buttonClasses = [
        'button',               // general class for the element
        `button-m--${model}`,   // class with model modifier
        `button-s--${state}`,   // class with state modifier
        `button-c--${color}`,   // class with color modifier
    ]

    return buttonClasses.join(' ')
}

I will probably wrote something more complete on Orchestra Design System soon.

Start creating

After naming things I created wireframes for all my pages on Figma following my own guidelines.

On the design side, big fan of the Material Design I was strongly inspired by it, but because it's my own design and my own website I didn't follow their guidelines.

For example the choice to raise a button on click is not logical for me. So I reversed the impact of the click or touch (for touch devices). My raised buttons seems to be pushed when pressed and go back when released.
More natural in my opinion and it creates a better interaction with the user.

Here is an example:

Click on each button to see the interaction on
button-s--raised

Technical part

yannisabel.com was written with React, a javascript library that helps to create interfaces with ease with a logic of components that can be updated independantly. In the old way it was difficult to update certain element at a certain moment and sometimes it was not really interactive because we had to refresh a page to update a component.

With all the new javascript frameworks and libraries (it's been a while now) it's common now to have a lot of interaction and a lot of updated components without any refresh. Pretty cool and it comes with increased speed rendering. The only problem is the fact that all the html is generated by javascript. So the accessibility and the referencing are put in the trash.
Fortunately, some frameworks was created to handle that by generating static websites from javascript applications. For React, one of the most famous is Gatsby, but to be more flexible I turned to Next.

One of the things that I like with my current website is that all my portfolio pages (like this one) are written in mdx. It let me import my own react components inside markdown syntax so I can keep interface consistency and write with simplicity.

Also since my last job at Payfit I code with typescript and don't really know how I did before without it. It's also very suitable for tokens and so for Design Systems.

Conclusion

Now my portfolio seems to be related to me personaly and I think it's the best way to think about a product. It has to be related to its purpose.
It's also pretty optimised for the web, it's fast and beautiful.

My plan for this website is to add a blog section where I will post things about Design Systems and Frontend development.