Forem: IBM iX

Meet Christian – Head of Frontend: Insights into his role at IBM iX

Katrin Lerm — Wed, 31 Aug 2022 09:46:39 +0000

In this interview, we introduce Christian, Head of Frontend at the IBM iX Studio Dusseldorf, and give you greater insight into his role and his daily work at IBM iX. To do so, our Content Marketing & Communication manager Patricia had a meeting with Christian. Christian has been with IBM iX since 2011 and has progressed from a PHP developer to a Head of Frontend.

Patricia: Hello Christian. Thank you for telling us more about your role as Head of Frontend at IBM iX. What are your current core tasks as Head of Frontend and what do you particularly like about working at IBM iX?

Christian: Hi Patricia. I work as Head of Frontend at IBM iX studio Dusseldorf and am responsible for a team of nine colleagues. In my role as Head of Frontend, it is part of my job to ensure everyone in my team feels comfortable and is appropriately supported. My main tasks not only include looking after my team but also constant communication with the Heads of Frontend at the other sites, e.g. in Austria or Croatia. However, since I still very much enjoy coding, I continue to work on projects as a Frontend Developer.

Patricia: You have been working at IBM iX for more than 10 years now. What makes it so attractive to work as a frontend developer here?

Christian: The Frontend Developer role at IBM iX is very diverse. We use a variety of technologies, for example, Linter for coding guidelines, webpack, SCSS/SASS, typescript, and various CMS systems and application frameworks such as React, Angular, and VUE. Atomic design and accessibility are also important issues, which bring further exciting challenges. I particularly like the continuing education offered at IBM iX. At the internal Academy, we can also complete training courses like as EcmaScript for beginners and Angular, but also seminars for personal development, such as employee leadership and conflict management. In addition, we can also share our own expertise and hold training courses for colleagues.

Patricia: It’s not very common for a Frontend Developer to stay with one company for so long, is it? How did that come about?

Christian: The opportunities for further development, the team, and, in particular, the opportunity to make a contribution are compelling. Here we can help shape our own career paths and develop further, not only in our own roles but also in completely different areas.

Patricia: And how has your role at IBM iX changed over the years?

Christian: I joined IBM iX as a PHP developer, then switched to the frontend area and progressed from a junior frontend developer role to a senior one. In the role of a Senior Frontend Developer, I often took the lead in projects and began to lead small teams. In 2016 I was offered the role of Head of Frontend. I had never imagined doing that before but, when I was offered the role, I had already gained a lot of experience in team leadership on projects. So I just plucked up the courage and accepted the new job.

Patricia: You said there are great opportunities to contribute at IBM iX and that the digital agency thrives on employees being able to implement their own ideas. Do you have a specific example?

Christian: I discovered SCSS around eight years ago. At that time there were fewer people and the process of trying new things was different. I worked on a project that wanted to issue multiple themes and it was necessary to generate a CSS for each of them. Maintaining and fixing multiple themes would have been a nightmare at that time. So I just tried it with SCSS and luckily everything worked out! Since then no project has been created without it.

Patricia: That sounds exciting. You mentioned your core tasks to us at the beginning. Perhaps you could give us some deeper insights into your daily work?

Christian: For me, there is very little routine in my daily work and every day is very different. I have regular 1:1 discussions with my team of course. Once a week we also have a team meeting, our ‘dev minutes’. I also still work as a project lead or technical architect on projects and regularly coordinate with my project team. As a Frontend Dev you have a lot of freedom for creativity in projects, e.g. for animations or optimisation proposals according to the design. Aside from that, as Head of Frontend, I deal with organisational matters and induct new employees.

Patricia: What else can you tell us about your work or the culture here?

Christian: At all IBM iX locations, the frontend area is agile and works according to the Scrum method. This makes the work a lot easier and structures the tasks. Our teams are international, so at work, I communicate 50% of the time in English and 50% in German. I also work from home occasionally, which is very convenient for me because of the distance to my workplace. And if something happens at home at short notice, people can usually work from home. My colleagues are also relaxed and always ready to have fun. It is important to me that not only is work enjoyable but also the interaction with my colleagues. If you need help or a second opinion it is always at hand, for example via Slack.

Patricia: Would you like to tell us another ‘fun fact’ about yourself? What are you known for in your team?

Christian: I am an avid Coca-Cola fan! It is essential to every day and my colleagues know that. But only from noon, I draw the line at breakfast! If I don’t have one to hand at lunchtime everyone immediately worries whether there’s something wrong with me. I’m also known for being passionate about photographing landscapes with my camera or drone. One of my pictures hangs in my office at home.

Patricia: Thank you Christian for this great interview and these exciting insights.

From Internship and Master Thesis Co-Mentorship to a Permanent Position at IBM IX

Jurica Migač — Fri, 27 May 2022 12:10:48 +0000

<h2>Hello world</h2>

I'm Jurica Migač, an Java Web Developer working as Adobe Experience Manager at IBM iX. I would like to share my experience of getting a full-time job at IBM iX after graduating from the Faculty of Organisation and Informatics. Through the excellent collaboration between the company and university, I was able to link both my internship and master thesis topic with the company onboarding.

Every student faces a struggle to find an organization that will provide them with an accommodating and friendly environment to begin their professional career in the ICT sector. IBM iX was my first choice of employers to apply to for the backend developer internship position. Passing the technical interview is the main task required to grab an offer for a full-time developer position at IBM iX. Going through an interview was an amazing experience. In the first part of the interview, the interviewer checks your technical competences. However, in a really relaxed and friendly atmosphere. Besides that, we talked about my previous experience and related project work. The interviewers also gave me a great intro to the technology stack I would be working within IBM iX.

After starting my internship, I was offered a list of research topics I could use for my master thesis. The master thesis was proposed to the faculty by IBM iX. There is a well-defined process for the internship and master thesis, where each student gets an additional technical mentor from the company. The master thesis is also a benefit for the company in gathering and increasing internal knowledge. "GraphQL and RESTful web services in Spring and Adobe Experience Manager" was the research topic that I selected for my master thesis. This defined the stack in which I would like to expand my knowledge and specialise further. GraphQL and Adobe Experience Manager were terms that represented something new and unknown to me. Learning about these and presenting my research (master thesis) within IBM iX and to the Faculty wouldn't have been possible without the great support from my iX technical mentor. IBM iX has an excellent process for supporting new joiners with the necessary guidelines, knowledge transfer and mentorship from a senior colleague. Being a participant in this pilot project of undertaking a master thesis in the company resulted in an excellent grade for my master thesis. Having such collaboration with a local faculty gave me the opportunity to present my master thesis at the CASE 2022 conference. It was a great surprise for me as a fresh graduate to be called to present my research at a scientific conference.

All in all, IBM iX has given me an amazing opportunity to be part of a diverse organisation. The additional opportunities which the company offers, changed my way of thinking, and solidified my approaches to certain things in my professional life. To all of you searching for challenges or new technologies to specialise in, look no further. No matter how hard the process can be, without taking any risks you would never be able to seize the opportunity which is just around the corner.

IBM iX @ WeAreDevelopers World Congress 2022

Katrin Lerm — Tue, 24 May 2022 09:41:56 +0000

It’s finally time again: The global developer community with the world’s greatest minds in tech meets once again in Berlin to share recent insights on software development, best practices and future tech trends. And IBM iX is in! With a century of human-centred IBM tech expertise in our DNA, we’re building bridges between humans and machines. Connect with us on site in area A, booth A.2.6, or check out our program to level up your skills. We’re looking forward to two days full of insights, a great speaker line-up, hands-on workshops, and fun!

➡️ Join our IBM iX workshops, listen to our expert talk or meet us at our booth on site and enjoy a good chat with our people from IBM iX! Find out more: https://lnkd.in/eWprhyD9

Session 1: 14 June, 12 AM – 1 PM
Automated Code Quality Checks with Custom SonarQube Rules
Daniel Strmečki, Martin Gluhak

Workshop 1: 14 June, 12.45 AM – 2:45 PM
Unit vs. Integration Testing in Spring Boot
Dajana Jeđud, Ivan Foro

Workshop 2:15 June, 11.45 AM – 1.45 PM
Implementing GrahQL with plain Java
Josip Primorac, Josip Mlakar

🎁 Take your chance to get a free event ticket & a surprise onsite and check out our speakers & sessions: https://lnkd.in/eWprhyD9

ibmix #WeAreDevelopers #wearedevs #wearedevs22

Importance of Code reviews

Matija Kovaček — Wed, 12 Jan 2022 19:00:00 +0000

Inspired by some of the last few projects, I have noticed that still a lot of people don't consider Code Review seriously.

From extreme cases where code review doesn't exist at all or where pull/merge requests are approved in a few seconds after being opened. Over the cases where the minority of team members care and perform code reviews, and the rest of the team members ignore them. The funny thing is when they are explicitly asked to check it, they consider them as "punishment".

Luckily, one of my first projects had a really good code review process where all team members were very active and performed strict but fair code reviews. On that project, I learned a lot, learned why this process is so important and gained really good habits on how to perform code reviews.

That's probably one of the reasons why I'm writing this today.

Recently I was preparing guidelines and best practices about code reviews so I decided to share them with you as well.

The things you will see here are not only my statements, they are inspired by other people, teams, and companies. But with those statements, I totally agree and I stand behind them.

1. So what is code review?

A code review is a process where someone other than the author(s) of a piece of code examines that code. Code review should be used to maintain the quality of our code and products.

2. Process Flow

Once you're satisfied and proud with your implementation and the tests, you create a pull request. With a pull request, you are requesting the merge of your local branch into the main source branch.

All dev team members (including Leads / Architects) should be default reviewers of the pull request. The reviewer's job is to check if all requested functionalities are properly implemented and tested. She/He can suggest code improvements like using some library instead of reinventing the wheel, better naming for components and variables, and any other improvement that she/he can suggest.

It is important that you shouldn't be disappointed if you receive a lot of comments on your pull requests. You will learn from the feedback and the solution will be better.

When the minimum required number of reviewers have approved the pull request you can merge it. Don’t forget to delete your source (feature/bugfix) branch and move the ticket that is ready for QA (after it's deployed).

3. Author of the pull request

Goal : Learn, improve your code quality, morale, and your working relationships.

3.1. REVIEW your own code first

Before sending code to your teammate, read it yourself and check the things that you would check as a code reviewer

3.2. Be UP TO DATE with the develop branch state

The recommendation is always to be up to date with the latest state from develop branch. This means that during the day you should pull changes several times and merge it to your local feature branch

Before creating a pull request make sure that your feature/bugfix branch is up to date

3.3. Pull request should be DESCRIPTIVE

Branch Name
- Source branch name should consist of branch type (feature, bugfix, hotfix), Jira ticket number, and Jira ticket title
- e.g feature/ticket123-some-ticket-title
Commit messages
- Commit early, commit often with a descriptive message what you did
Pull request description
- Add an additional summary of what is being done if it’s not clear from the pull request title
- Point out not so obvious/logical decisions and agreements
Comment your decisions
- Comment yourself (inline in code) for not so obvious/logical decisions, so that reviewers can easily understand it

3.4 Prefer SMALLER pull requests

Try to make your pull request small as possible.

Smaller pull requests:

easier to review and understand
faster to review
less chance to miss something
less chance to create a bug

3.5. Respond graciously to feedback and LEARN from it

Don’t take personally a code review feedback. Treat your reviewer’s notes as an objective discussion about the code.

3.6. Be PATIENT when your reviewer is wrong

From time to time, reviewers are wrong. Just as you can accidentally write buggy code, your reviewer can misunderstand the correct code.

3.7. COMMUNICATE your responses explicitly

For every comment that requires action, respond explicitly to confirm that you’ve addressed it. Some code review tools allow you to mark comments as resolved. Otherwise, follow a simple convention, like, "Done", for each note. If you disagree with the note, politely explain why you declined to take action.

Don’t directly ask/chat with the reviewer about every comment. Commenting and discussing directly in the pull request is useful for other reviewers as well.

3.8. MINIMIZE lag between rounds of review

Once you create a pull request, driving the review to completion should be your highest priority. Delays on your end, will waste time for your reviewer, and increase complexity for your whole team.

3.9. RESOLVE Conflicts

In case of:

disagreements
totally wrongly implemented features
too many mistakes
doubts, unclear things, or comments

schedule 1 on 1 call with the reviewer to resolve all doubts and unclear things. Make sure that you comment back agreements directly in a pull request for other reviewers.

4. Code reviewers

Goal: Mentor, educate and improve your working relationships.

4.1. What do Code Reviewers look for

Design
- Is the code well-designed and appropriate for your system?
Functionality
- Does the code behave as the author likely intended?
- Is the way the code behaves good for its users (end-users and developers)?
Complexity
- Could the code be made simpler?
- Would another developer be able to easily understand and use this code when they come across it in the future?
Tests
- Does the code have correct and well-designed tests?
- Do the tests cover requirements?
Naming
- Did the developer choose clear names for variables, classes, methods?
Comments
- Are the comments clear and useful?
Style
- Does the code follow the company style guide?
Documentation
- Did the developer update relevant documentation?

4.2. Don’t criticize, MENTOR and EDUCATE

Code review is a chance for developers to mentor and teach others.

When you comment on someone's pull request:

be kind
instead of criticizing, ask why decisions were made like that
suggest improvements
explain your reasoning
balance giving explicit directions with just pointing out problems and letting the developer decide

4.3. PRAISE good code

Remember to praise good code and decisions. Don't only point out problems and suggestions.

4.4. Don’t ignore pull requests

Don’t ignore pull requests and think someone instead of you will do the review.

Make a habit of doing code reviews like in the morning before daily, around lunchtime, before the end of the working day.

If you are in the middle of a focused task, such as writing code, don’t interrupt yourself to do a code review. Instead, wait for a breakpoint in your work before you respond to a request for review.

4.5. Less experienced team members don’t be shy

Your opinion is important and expected here as well. More experienced team members don't know everything and they also make mistakes.

5. Speed of Code Reviews

The speed of individual development is important, but not as important as the speed of the entire team.

The speed of the team as a whole will be decreased if the individuals don’t respond to the pull requests, do the review, and push other work (task) in the done direction.

If you are not in the middle of a focused task, you should do a code review shortly after it comes in.

6. Code Review Improvements Over Time

If you follow these guidelines and you are strict with your code reviews, you should find that the entire code review process tends to go faster and faster over time.

Developers will learn what is required for healthy code, and when you create a pull request that is great from the start, it will require less and less review time.

Reviewers will learn to respond quickly and not add unnecessary latency into the review process.

But don’t compromise on the code review standards or quality for an imagined improvement in velocity—it’s not actually going to make anything happen more quickly, in the long run.

References:

Career kickstart: IBM iX recruits new colleagues with bootcamp

Katrin Lerm — Thu, 23 Dec 2021 08:22:46 +0000

Digitalisation affects almost all industries, and programmers are among the most sought-after professions. That’s why more and more career changers are opting for a career in the IT sector. With its new bootcamp format, IBM iX shows that it is possible to get started as a programmer in four (intensive!) months. From 14 June to 30 September, ten participants had the opportunity to immerse themselves in the world of front-end development as part of a challenging and supportive remote training course.

HTML, CSS, JavaScript – at the beginning of the bootcamp these were still foreign languages for some participants. And that is entirely intentional. Precisely because IT and digitalisation are relevant in almost every industry, programmers with different backgrounds are needed. People from outside the field who have switched to programming often think “outside the box” due to their experience and thus develop particularly successful approaches to solutions. Among the large number of applicants, 60 candidates with and without previous experience had the chance to convince in their interview. Because for IBM iX, motivation is one of the decisive factors: only those who were prepared to commit themselves fully to the bootcamp had a chance of winning one of ten places.

Eat, sleep, code –repeat

Although many workshops suggest that you can become a programmer on a long weekend, it’s not quite that simple. For its bootcamp, IBM iX therefore placed great emphasis on teaching the basics. Frontend development is a broad field, and going directly into specific frameworks would narrow the focus too much for beginners. So the participants spent eight hours a day, for four months, intensively learning the programming languages HTML, CSS, and JavaScript and laid the foundation for successful frontend development.

In addition to guided sessions with experienced mentors from IBM iX and a series of exciting guest lectures, the participants also had plenty of time to apply and deepen their newly acquired knowledge, independently and in group work. “I particularly enjoyed the practical tasks and lectures”, said participant Filip Rubes. “Our mentors were extremely committed and made the material clear to us with many practical examples. Just as important for me, however, were the scheduled time slots in which I was able to independently apply and internalise the material.” His fellow student Marija Susko agreed: “Of course it was hard. But our mentors were extremely motivating, and it was great for me to get such an opportunity and to see how much I’ve achieved in just four months.”

Mentors make the difference

The fact that the bootcamp has been such a success is also due to the mentors from IBM iX. With experience from previous training courses, such as the Apprenticeship Program, as well as a lot of heart and soul, they have developed a challenging program. The interplay of predefined content and flexible adjustments “on the fly” has made it possible to address individual participants’ questions and tasks and to motivate and challenge them every day anew.

At the end of the boot camp, the participants were able to demonstrate their skills in a final exam and set the course for their future careers. Nine of the ten participants started working at IBM iX after a more than deserved two-week break. Seven of them were able to join ongoing projects directly, while two completed a further one or two months of advanced training before they too were involved in active projects. “Although many of us originally come from other backgrounds, most have passed their exams. I am proud to have worked my way into IBM iX and to be part of a group of colleagues who encourage me and support me in further developing my knowledge,” said Marija Susko.

The next bootcamp is getting ready to start
If you are thinking “I want that too!”, then we already have the next chance for you at the beginning of 2022. Starting on 28 February 2022, our next bootcamp in Varaždin will be all about programming in Java.

The Agile Truth – How to start a podcast

Katrin Lerm — Thu, 16 Dec 2021 11:56:51 +0000

Ever wondered how podcasters create their stories? Or have you ever wanted to start a podcast yourself? Our IBM iX colleagues share their story behind “The Agile Truth” – an IBM iX podcast with weekly insights straight from the world of agile working.

https://anchor.fm/the-agile-truth-podcast

In June 2021, IBM iX launched “The Agile Truth” – a podcast with weekly 5-minute episodes about honest agile hands-on experiences made with real customers and projects in a digital agency setting. After successfully publishing the first season, we want to share our making-of with you.

Spoiler alert: Good ideas don’t just fall into your lap. It needs talent, creativity, a great team – and agile ways of working.

Let’s find out why…

“What about doing an IBM iX podcast?”
Our colleagues and agile experts Katja Piepel (Scrum Master), Thierry Baudez (Scrum Master), and Gábor Bedőcs (Product Owner) have carried the idea of creating a podcast from the first minute onwards. It all started with a casual chat and the questions: “Why not let others benefit from the experiences of our agile experts at IBM iX? Sharing is caring. So, what about doing a podcast?”

Thierry had already tried his wings in the podcast world and brought valuable knowledge into the project. As an experienced Scrum Master, he knows that great stories don’t start with planning – but with doing. He set up a team to discuss which topics would be interesting for the agile universe and software development community.

The first workshop started with brainstorming and collecting ideas in Mural:

What topics shall we cover?
How long should an episode be?
What about the title of our podcast?
And our branding?

Tricky questions to answer.

Agile style: from the idea to the story

After gathering the first ideas and subjects, the newly formed editorial team started to group them: “Which of the suggestions fit the IBM iX philosophy best?” We decided to go with a short 5-minute interview format that should feature a new guest every week. Each interview would tell a real-life story that changed the way we think about agility or proves that our methods are working.

True to the motto of our podcast, we have worked in an agile way to bring the idea to life:

We tried things and kept what was working.
We improved on what needed to be improved.
We threw away what was not the focus.
Recording interviews under Covid restrictions was a big challenge. Instead of lengthy discussions about how to do it, the podcast team just used our Cisco Webex tool and started to record the first episode.
They tried a few setups and ta-da: there was the first recording in raw format!

With the help of our Marketing & Communications Manager Alexandra, the audio file of the first recording was cut. Together we chose the publishing platform, the intro sound, and a logo. A marketing plan was created to make sure the launch of the podcast did not go unnoticed.

Creating a social network of agile stories

The IBM iX marketing team as well as the editorial team found a way of working efficiently in parallel. While the editorial team took care of coordinating and producing the recordings, the marketing team handled the editing, publishing, and promotion of every new episode. WebEx was found to be sufficient for recordings. The only thing we had to improve on was the microphones. We experienced issues with wireless headsets and therefore started to prefer wired microphones. However, that was the easiest issue to tackle in getting recordings done. The bigger issue was the lack of interviewees. Lucky us: once we started interviewing our first experienced colleagues, they suggested who to interview next and on which subject. Again, a very agile part of the editorial work. Once you start talking to people, you find yourself in a storyline that is even more interesting than the original idea and which the interviewee is also more passionate about. It felt like we were building a social network of agile stories, that can now be experienced in “The Agile Truth” on all major podcast platforms.

Curious? Listen in!

This is how the podcast “The Agile Truth” was born and realised. Do our 5-minute chunks of honest agile experiences sound interesting to you?
Listen in! https://anchor.fm/the-agile-truth-podcast

Already finished season 1? Look forward to season 2 – available soon here. And shhh: season 3 is already in the making. Happy listening!

About the podcast “The Agile Truth”:
“The Agile Truth” is your weekly 5-minute chunk of honest agile experiences created by our digital experts at IBM iX. Every episode of our podcast deals with a different agile topic, but the mission stays the same: to provide you with the most valuable insights for your work as an agilist.

About our podcast team:

Gábor Bedőcs

Gábor works at IBM iX as senior Product Owner. As a PO he is a member of the scrum team, supporting them in defining stories and prioritising the team backlog to streamline the execution of programme priorities. Before he was hired at IBM IX, he worked as a software developer and development team lead in Budapest creating tailored software for banking. In 2012 he started as an agile software developer in Austria in one of the leading companies of Styria and switched to the PO role in 2015. Through experiencing several project methodologies and managing styles, he developed his motto: “Agile is not a noun.”

Thierry Baudez

Thierry has been a Senior Scrum Master at IBM iX since 2019. He helps teams deliver the digital manifestation of their clients’ strategies across industries. Before that, he freelanced in Siberia, ran a communications and time management consultancy in Belgium, set up a communications department in an international bank and, while based in the Netherlands, co-engineered the agilisation of 5,000 global employees. Only then did he find his true calling in 2019 as a Scrum Master in the IBM iX family, where he started the podcast about digital projects in an agile agency setting.

Katja Piepel

Katja started her journey as a media designer. Driven by her interest in people and relationships she decided to get trained as a systemic coach with a focus on team development. Through the training, she discovered the power of self-organised work and experienced that Agile can help to increase people’s motivation, joy of work, and effectiveness. Encouraged by this realisation, Katja changed her course and became a Scrum Master. At IBM iX, her focus is on building successful teams with strong self-organising and cross-functional skills and the pursuit of continuous improvement.

Alexandra Bauer

Alexandra has been a marketer since the very beginning. After joining the IBM iX DACH marketing & communications team in 2019 for a student internship, she gathered practical experience as a Marketing Manager in a start-up and returned to IBM iX in 2020. Since then, she has taken care of the internal and external communication channels as well as promoting the IBM iX content in form of text, audio, and video. She is convinced that a wide range of formats is necessary to properly address the wide range of personalities within the audience.

Hands on Web Share API

Nika Dev — Thu, 19 Aug 2021 13:26:48 +0000

Hello world, welcome to my first post!
In this one, I will explain what the Web Share API is and what you can do with it. If you didn't work it yet, maybe you give it a try in your current or next project.

What is the Web Share API?

Let's say, you want to share some page specific data from your website to some social media platforms and maybe messengers.
The Web Share API give web developers the power to use the native share mechanisms, that we all know from native applications (e.g. if you click the share button in Safari on the bottom center). It's one of these cool new APIs, that give the web more capability and push the keyword "Progressive Web App" a little more. If you haven't got any idea what the hell I'm talking about, here is a picture for you:

Web Share API - native dialog on iOS after clicking the button

Why should I use the Web Share API?

You may ask yourself why you should use this API, because you already have enough share possibilities like WhatsApp, Facebook, Twitter, LinkedIn etc. within your application. That's fine, but think about the Web Share API as the cool new kid on the block, which also makes it much easier for you to implement these share possibilities.

Without the Web Share API

In this case, we should have to provide a link/button for every social media/messenger platform. That means, we have to take care of each link separately. That also implies to maintain these links, because they could change in the future.

With the Web Share API

In this case, we will just have one button to click on. After clicking this button, the native dialog will be shown. One advantage of this native feature is, that it is known by the users. Another advantage (I think a bigger one) is, that if there is a new social media platform or native share feature (in the OS) it's directly implemented! All done by the native mechanism! Yeah! 🎉

How can I use the Web Share API?

Like any other new cool Browser API out there, it's asynchronous. That means we have to work with Promises (if you are not familiar with Promises, I'm sure you will find a good article out there). In this case, we will call our navigator.share() function, which will return a promise:

const sharePromise = navigator.share(shareData);

Okay, maybe we need some more context to have a good example.

Let's start with the share() function, that will take the data object (shareData) as a parameter. The result of this call, will be the native share dialog with some share targets, depending on the data that was thrown in. A share target is a possible option, that is displayed to the user in the dialog. This could be a contact (via WhatsApp, Telegram etc.), native applications or built-in service (e.g. "Copy to clipboard"). To make it clear here, you can't decide which share targets should be shown to the user, they were provided by the user agent.

So let's start with the most secret part ... the shareData. Honestly, it's just an object that can contain the following members:

title
text
url
files

In the future there could be some more members, but this is the current state. It's important that not all data members have to be provided, but at least one member should be inside.

The user agent will take care of the shareData and converts these in a suitable format for the different targets. This could include merging or discarding some members. But this magic is done behind the scene, we can just take a drink and enjoy the beautiful interface. 🍹
The share targets that you will see on the native dialog depends on the shareData payload. Anyway, let's dive into the different members of the shareData object.

Title member

This member is a string and contains the title of the document that is shared. In my tests, I couldn't find it anyway. So in most cases, this member is not being displayed or used on most targets.

Url member

The url member is just a simple pure string URL that refers to a resource that should be shared. This could be an absolute or relative URL. If you provide a relative URL it will automatically update the url like a href attribute.

Pro Tip: If you just provide an empty string as url, then it will automatically reffers to the current page.

Text member

The text member is also a string option, that allows you to provide a body of the message for the shared data. This member is often use by the share targets (e.g. email body text).

Everything in action

You might think, why didn't we cover the files member. Please keep cool and take a breath, we will cover it in a couple of minutes. But I think now it's time for some code. Finally 🎉

Let's say we have a fancy button on our page, where we just want to share some data related to the current page. The JS code would look something like this:

// our share button in the markup
const shareButton = document.getElementById('share');

// create share data object
const shareData = {
  title: 'Web Share API',
  text: 'The best way to share your data.',
  url: '' // reffers to the current page
};

// click event handler is necessary to call navigator.share()
shareButton.addEventListener('click', async () => {
  // does the browser supports the feature?
  if(navigator.share) {
    try {
      await navigator.share(shareData);
      console.log('🥳 Shared via API.');
    } catch(error) {
      console.log(`😢 ${error}`);
    }
  } else {
    // you could do a fallback solution here ... 
    console.log('😢 Your browser does not support the web share api.')
  }
})

Now let's go through the code step by step. At first, we create an object and add some members to it, in this case title, text and url. Then we add an event listener to our shareButton. In the event handler, we check for navigator.share, because we want to check if the browser supports the Web Share API. If not, it will return undefined and the else branch will be executed. There could be a fallback solution for all browsers that are not supporting this functionality. At least this would be the best, if we think about progressive enhancement. But in this post we want to concentrate on the if branch.

First, we will open the try block and call the navigator.share(shareData) inside. Now the native dialog will open up with all possible share targets. With await we will wait until the promise is fulfilled. That means, until the user cancel the sharing or chose a share target. On cancel, the code above will run the catch block. If the user finally shares the data via a share target, then the promise will be resolved. Then we successfully shared some data with the Web Share API 🎉

ℹ️ Important note: Even if the sharing was successful, we didn't get any detailed information. The promise itself will just return undefined. There is no way to get the chosen share target of the user. I know that's a bit disappointing, but there is a good reason.

There is a requirement to not allow the website to learn which apps are installed, or which app was chosen from share(), because this information could be used for fingerprinting, as well as leaking details about the user's device. https://www.w3.org/TR/web-share/

Files member

Now it's time to talk about the files member. This one contains all shared files as an array. By adding this member to you shareData, we have to handle binary data and the code gets a little more complex. But don't be afraid, we will go through it together.

So time for some imagination 💭 again...
Imagine you want to share a super cool looking image, if the user clicks on our share button. We need to load the file like this:

const image = await fetch('./super-cool-looking.jpeg');
const blob = await image.blob();
const file = new File([blob], 'image.jpg', { type: 'image/jpeg' });
const filesArray = [file];

// add it to the shareData
shareData.files = filesArray;

In these lines of code we fetch the image, convert the raw data to BLOB (binary large object) and create a new File with the File interface. Then we just put it into an array. Of course, it's possible for you to add their more than one file.
In the end, we just add the files property to the shareData object and initialize it with the filesArray.

Now you can share images via the Web Share API, but be aware that this feature is not supported in all browsers. There is also an opportunity to check, if file sharing is possible in the browser. You can use the navigator.canShare() function for this. It could look like this for our example:

if(navigator.canShare && navigator.canShare({files: filesArray})) {
  await navigator.share(shareData);
} else {
  console.log('File sharing is not supported.');
}

The function has one parameter like the share() function and will return true or false, if the browser can share the object (shareData) you put in.
But there is a big disadvantage for this approach, because this functionality is experimental and is not supported everywhere. Sadly, file sharing isn't that easy to handle on every device and browser. But as always, do it progressive (like above) and support modern browsers.

When to use?

One important note, the navigator.share() function will just work on a user interaction (e.g. click event handler). That means, you can not run the code on page load. Which is good, because otherwise we would have the next stupid thing like cookie banners or push notification permission request.

Which Browsers support the Web Share API?

I don't want to talk about it in detail, because it could be outdated. So here is the link to Web Share API support.

Conclusion

As shown above, the modern way of sharing data in JS makes the code quiet easy and understandable. Also it's easy to maintain the code and we get the native share mechanism, which will also support future social platforms automatically. I'm a real fan of this approach and would recommend to give it a try in your next project. If you already made some experiences with this API, please share your thoughts in the comment section below. 👇

My sources