DEV Community: Niklas Kiefer

use-spinner - Show loading spinners for your asynchronous calls

Niklas Kiefer — Sat, 03 Apr 2021 08:41:55 +0000

Hello community 👋

Sometimes calls can take longer, so showing a loading spinner becomes an option to fill the gap. I was tired of configuring such spinners times and times again.

Yesterday I built a tiny Javascript library called use-spinner that simply wraps asynchronous calls into a new function adding a loading spinner to the DOM.

Simply install the module



$ npm install --save use-spinner

and embed it in your Node.js styled application.



import useSpinner from 'use-spinner';

import 'use-spinner/assets/use-spinner.css';

const mySlowCall = async () => {
  return await fetch(/*...*/);
}

const spinned = useSpinner(mySlowCall);

await spinned();

Of course, it is rather rudimentary right now and the spinner itself is hardly customizable. However, I like the easiness of integration to existing functions without much configuration.

Enjoy ❤️

use-spinner

Add a simple loading spinner to your async JS calls - built for the browser.

Installation

$ npm install --save use-spinner

Usage

import useSpinner from 'use-spinner';

import 'use-spinner/assets/use-spinner.css';

const fn = async () => {
  await new Promise(resolve => setTimeout(() => {
    console.log('done.');
    resolve();
  }, 2000));
};

// wrap your asynchronous function
const spinnedFn = useSpinner(fn, {
  container: 'body'
});

// execute with a loading spinner
await spinnedFn();

Options

The API accepts a second argument configuring the wrapped function. This defaults to:

{
  container: 'body'
}

container: a selector or a DOM element that appends the loading spinner.

License

MIT

View on GitHub

New version of postit-js got published

Niklas Kiefer — Fri, 12 Mar 2021 14:56:33 +0000

Hi folks 👋🏻

today I just released a new version of postit-js, an embeddable Javascript library to create simple Brainstorming boards.

The APIs are now exposing Promises, a proper test infrastructure was established, and on top, the bundle size got reduced decently.

Simply create your Modeler instance

import 'postit-js-core/assets/postit-js.css';

import PostItModeler from 'postit-js-core/lib/Modeler';

const XML = `
<?xml version="1.0" encoding="UTF-8"?>
<postit:Definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" id="sample-diagram">
  <postit:PostitBoard id="Board_1">
    <postit:SquarePostit name="A new idea" id="Postit_1" color="#7EC845" />
  </postit:PostitBoard>
  <postitDi:PostitRootBoard id="RootBoard_1">
    <postitDi:PostitPlane id="PositPlane_1" boardElement="Board_1">
      <postitDi:PostitShape id="Postit_1_di" boardElement="Postit_1">
        <dc:Bounds x="300" y="200" width="150" height="150" />
      </postitDi:PostitShape>
    </postitDi:PostitPlane>
  </postitDi:PostitRootBoard>
</postit:Definitions>`;

const modeler = new PostItModeler({
  container: '#canvas',
  keyboard: {
    bindTo: window,
  }
});

await modeler.importXML(XML);

and go on brainstorming

Check out the demo or the project on GitHub.

Thinking Backward - or: searching for the Big Why

Niklas Kiefer — Sat, 30 Jan 2021 13:02:35 +0000

Where to start? Every product work begins with questions like that, no matter if it's ideating a completely new product idea, creating a simple feature enhancement, or fixing a crucial bug.

I once wrote another blog post about prototyping and how to use it to tackle uncertain problems.

Creating the unknown - What and what not to build in efficient prototypes

Niklas Kiefer ・ Apr 14 '20

#webdev #ux #prototyping

At Camunda we follow the mindset to keep our work focused. One thing at a time, but doing this one right. That's great, but how do you know what this one thing is?

One principle my team more or less actively used in the past is to work backward. You might say it sounds like guessing the right solution. Let me explain.

Working Backwards © Amazon

The idea of working backward isn't new, Amazon "introduced" it a while ago. At the very beginning while developing new products, the product manager, or even better the team, writes an internal press release about the finished product. Before creating a single user story, without writing a single line of code.

The press release should be customer focussed, stating why current solutions are failing and why users will be amazed by the new product. Having this as a "solution sketch" they start iterating, keep on improving it. The key here: "Iterating on a press release is a lot less expensive than iterating on the product itself (and quicker!)" (Ian McAllister).

I never wrote such a press release as the working backward method requires. What's important to me here are the principles that are behind. That's why I'd rather call it Thinking Backward. It does not start with a press release, an MVP, a mockup, or a prototype. It starts with thinking.

It's all about shaping

Basecamp did tremendous work in the past to define what shaping of tasks means for successful product development. You could argue it's not feasible for any organization to do those 6 weeks of focused working sprints where the team is absolutely autonomous without any surrounding noise.

Shape up phases by Basecamp, source: https://basecamp.com/shapeup/4.1-appendix-02

What's even more important is the shaping part at the beginning. Avoiding circles in the development phase is a key part of my personal approach to software development.

In the end, it's a matter of avoiding waste. Taking more time to really understand the problem and identify the core need will produce waste as well. That's okay if you compare the potential waste and problems of redefining requirements and refactoring huge parts of your code at the very end of the development lifecycle.

The Shape Up "manifesto" from Basecamp itself has this nice sentence: "If we don't make trade-offs upfront by shaping, the universe will force us to make trade-offs later in a mad rush".

Of course, there will be cases where you feel spending more and more time shaping a topic will cause more effort than needed. Don't come to an end, if taking the bad parts, could even cause mental problems. What's really important in this phase is to gather learnings and create focus on the most relevant aspects.

Afterward, it will be much easier to simply get the stuff done, without getting lost in circles. Build the one thing which matters and do it right. And get this thing done. Which does not mean that circles in the implementation phase are bad. But that's another topic.

Begin with the problem - jump back if necessary

Shaping comes along with thinking about the problem in a deeper manner. I tend to start with the following question: what is the main problem we want to tackle and why will users be amazed by it? That's not easy for sure and depends on a lot of prerequisites and hypotheses you still have to find out.

The Double Diamond of creating solutions, source: https://www.smashingmagazine.com/2020/05/research-study-double-diamond-model

With this saying, the double diamond is worth to be mentioned. Despite this model might have some weaknesses, it shows a very relevant aspect: all the research, all the shaping you do in regards to find a solution, it all aims to find the main problem and to deliver a focus.

The problem: sometimes it feels like a waterfall. Defining the problem, then defining the requirements, then creating the solution. That's indeed not ideal. The solution space is always re-opening the space of the problem. Therefore it's recommended to take steps back, evaluate the problem, and re-shape it. You may name those problems to be "wicked", Horst Rittel did a lot of ground keeping work in this regard.

By the way: if you also love those diagrams about the double diamond and design thinking, give this website a try: https://designfuckingthinking.tumblr.com/.

Find the Big Why

"Users have to be amazed by the product", that's the spirit of Amazon's working backward method. That's far from being easy. This requires a lot of research to get the real needs of a user. That's not a high-level exercise, it really goes into the psychology of users while working with our products.

Thinking backward about the product which aims to be build creates new perspectives. We ask: what makes our users happy? Is there a particular need our product needs to serve?

I don't want to go too much into detail. What's important is that we can directly influence the way users adopt new products and features by building them in the way they deal with basic psychological needs.

Don't understand me wrong, it's absolutely not about creating an interface that "looks nice" and the user enjoys from a visual perspective. It's about functionality.

That's the "Big Why". Hassenzahl and Diefenbach did a lot of known worth research on this topic.

It does not have to be a press release

It can be anything that is not a technical prototype nor a design sketch. To give some inspirations

write a letter from a user
write a product review from a user
create a promotion video
create a user onboarding
create a getting started guide

An imaginary letter from a user I recently created in a UX Thinking training (German). The project scope was an application for shared traveling.

At Camunda we recently did the last thing. One project was about creating an embeddable library that our customers can easily integrate into their existing Javascript applications.

It helped a lot to get an understanding of what the end-users will see at the very first. What would they expect? What are the actual steps they need to do to integrate our library? We took this sketch of a getting started guide, reflect & iterate on it with customers, and came closer to real requirements, step by step.

This perspective helped in focussing on the most important aspects: What should the user be able to achieve and how can we provide it in the easiest way. Remember: the user has to be amazed.

Summary

If you get one thing about the words above, then it should be to keep your work focused. Don't waste your time with features your users don't care about. Take the time to really understand the problem, find out what your users will enjoy the most, and simply get these things done.

Creating the unknown - What and what not to build in efficient prototypes

Niklas Kiefer — Tue, 14 Apr 2020 06:00:20 +0000

In the last couple of quarters, I did a lot of work in improving the overall modeling experience for the dmn-js toolkit. We decided on an approach that would rather go with building prototypes instead of real features.

This allowed us experimenting, elaborating, and iterating a lot with the tremendous amount of decision modeling ideas we had at the beginning. Along this road, I learned a lot, so I decided to write down my thoughts about the overall process and what, from my experience, makes a prototype efficient.

Background: Agile Prototyping

Generally saying we moved along an Agile Prototyping process while creating our prototypes. I won't go too much into detail about that topic, this blog post explains it quite good.

What we keen to do all the time was to improve our prototypes with each iteration. Beginning with the most important or most obvious feature, we tried to add more and more to the actual demo, until we were sure the original feature fits our users needs. This included a couple of user tests to verify our assumptions, or to improve the demo with our findings.

Starting with a demo instead of a real implementation gave us enough flexibility to try out multiple things for a specific problem. We were simply not coupled to internal conventions dmn-js would have given us.

Once we have to tackle a bigger problem, about which we do not know much yet, it makes total sense to start with that approach. Take the time to experiment and learn about the problem before you actually start solving it. The next chapters should explain about some learning I've made during this time.

Know the use case

Before creating a demo showcase, it's necessary to know a particular use case you want to test. Not every scenario is suitable for creating a prototype for it. Most bug fixes and feature requests are quite trivial in the end. Once you don't know how the feature would look in the end, maybe because there wasn't built something like that before or there are a bunch of possible solutions, it's a perfect starting point to think about creating a prototype.

There will be a dedicated chapter for that point, but: Don't start with too many scenarios. Try to think about the basic user story you want to solve. Is there a particular problem your users face multiple times? Is there a specific request your application should serve. Before you begin, try to create a basic user journey. After you created that one, try to think about variable routes the journey could take. Once you know the basic scenario, it will be easier to define a specific interaction for the prototype.

I can recommend this blog post for first guidance on how to create pleasant user journeys.

It's about Innovation + Inspiration

It's okay not always to create entirely new functionality. Although the problem would be huge and uncertain in its possible solutions, most stuff was already solved out there. Inspiration is not cheating. The users are often used in certain ways of solving different problems.

That's why it makes total sense to take solutions from other applications and check whether you can bring it inside your prototype. In some cases, there might be standards that give a basic guideline on how to solve problems. Doing such a pre-research often helped me before getting started with the ideation step.

Also, you have to deal that your prototype solutions follow the design guidelines of your application. It depends on the use case, but creating a sidebar control panel when you only use popup modals in the current state might not be a good idea.

This should not hold from bringing the innovation into your work. Creating prototypes is the perfect time to go crazy. Whenever it's suitable, think about unusual solutions. Whether they are ideal in the end, you'll find it out in the user testing.

Start with a pen

Don't start coding! As it is best practice to not fixing the bug right away, but first shaping the problem, you should do the same with your prototype. Depending on how big the problem is, start with sketches or low-fidelity prototypes. So, pen and paper!

Try to take some time and illustrate as many solutions as possible. Also, try not to doing it alone. Spreading and sharing ideas helps to create synergies. As one of the dozen possible methods to drive the sketching and ideation phase, I can recommend to try out Design Studio.

Starting with a sketch helps to express and change ideas more frequently. Since you're just at the beginning, don't be coupled to technical solutions. It also enabled us to have first user test scenarios with some sketches itself to get the earliest feedback as possible.

After several iterations and once we were confident we found the right solution, we went into creating paper prototypes or quickly starting with the actual demo, depending on your needs. Sketches have a lack of illustrating interactions. Combining sketches to a paper prototype enables the chance to bring the idea to life.

Btw., for creating sketches, I can really recommend trying out Excalidraw. Of course, starting with a pen as a first step is indispensable. But then converting more shaped ideas into a virtual sketch helps to illustrate some aspects more deeply.

It's not a feature branch

I mentioned it a couple of times before, but do not stuck on your codebase. Try to create demos from scratch. Why? Because oftentimes, your codebase gives you restrictions on what and how to build stuff.

Prototyping is a phase of the development cycle where you want to try out crazy ideas. Creating your demo on a blank HTML page helps to create whatever you want, without dealing with technical limitations. Do not overengineer stuff. You know the use case of the demo, so build the demo application right for that purpose. There will be time to think about the final implementation later on.

I lately wrote a blog article about creating demos with Svelte.

Keep it simple

That one should be clear now. Once you know the user story of your prototype, try to keep it in that scope. Furthermore, don't intend to reinvent the wheel. You need an autocomplete input? Try to integrate a working library for that. Modals, icons, drag and drop functionality? Try not to build it yourself. Of course, there will be cases where you have to create something from scratch again so that these components fit your needs. Most of the cases, it's okay to re-use certain stuff.

Additionally, do not implement all edge cases inside your prototype. Focus on the problem your demo should solve. Do not get stuck on extra cases that might affect you in the future. The primary purpose should be to verify your idea with the user. Make sure you give your testing person a scenario to click through.

That's the most crucial stuff which should work smoothly. Any extra stuff is a bonus. Often the case, crazy other functionality might also distract the testing user from the main focus, which would have a negative effect as well.

Build fast, fail faster

Since you want to be agile in your prototyping phase, plan multiple iterations. You won't find the best solution at the beginning, that won't work. Take user testing sessions to verify your ideas. Does the user like it? Keep it. It was confusing, or the user had problems to solve your problem? Think about alternatives and improve the demo.

Step by step, you will find the best or at least a very good solution that fits your needs. I often heard that prototyping might be a waste of time, especially when you throw it away at the end. It's okay to throw stuff away. The main goal of this phase should be to make learnings. Get to know the problem, try out different solutions, and learn.

Think about variations

When you're doing the user testings, try to think about variations of your solutions. Because then, you will have a side-by-side comparison inside the demo. The user faces multiple ways of solving the same problem and can directly express what he likes the most. Often, in the end, the solution will be a mixture.

When creating variants, make sure they only differ in specific aspects. The rest should be exactly designed the same. Why? If one option might have, for example, another color, other dimensions, or simply nice looking icons, the user might feel one solution to be the best for the wrong reason. You want to know which way of solving is the best, interactionwise. So the user should not be distracted from surrounding things.

For us, it was also a good idea to implement variant toggles inside the demo application. It gave us the flexibility to quickly jump from one variant to another, e.g., via clicking a badge on the right upper corner or via keyboard shortcut. Also, we sometimes had remote user tests, so the user had to control the application entirely itself. Having such a simple variant toggle implemented was the easiest way to test all variants after each other without wasting time between them.

Keep the best

The first goal should be to make learning, as I described before. After you did some user tests, went over several iterations, you might have a solution in which you're confident it will solve your problem in the final application. Will you implement all features of your demo? No, of course, not.

After the concept phase, it's time to reflect. Pick the best aspects and think about how to bring them into your real application. Scope your findings and start with the low-hanging fruits. As the prototyping phase was a time of iterations, the implementation phase should follow the same guideline.

Summary

To summarize, I made the following lessons learned while creating the DMN prototypes:

Know the use case
It's about Innovation + Inspiration
Start with a pen
It's not a feature branch
Keep it simple
Build fast, fail faster
Think about variations
Keep the best

You might not implement all stuff from your demo, although the user liked them a lot, due to technical or time limitations. That's okay, and you won't throw them away, keep them for coming releases. The prototyping phase shows you many aspects you didn't think about before. If there's one suitable solution, in the end, it was highly worth it.

For me, it was the first time dealing with prototyping and creating demos in a more extended period. It came out the field of Usability Engineering as something very valuable during the development cycle, especially when the problems got bigger with a higher amount of uncertainty.

I tried to link some other interesting blog posts inside my writings. If you have any other thoughts, opinions, or questions, feel free to reach out!

Creating Demos with Svelte - Lessons Learned

Niklas Kiefer — Wed, 18 Mar 2020 09:51:36 +0000

Note: The Content was previously created inside these slides.

We're currently creating a lot of demos and prototypes to improve the overall DMN modeling experience inside our bpmn.io toolkit. After designing the first demos with jQuery, because of having the ability to create UI stuff quickly, and experiencing some silly things related to reactivity and state management, I wanted to give Svelte the first try.

I heard about it a couple of times before, and the possibilities and vision behind it sound quite pleasant to me. I can recommend this article to get a first glance about it.

So I went to create the next DMN demo with Svelte and get away from jQuery. The general feeling was excellent. In comparison to the last demos, the speed of creating view switching and simple interactions was halved in working time, at least.

That's why I decided to take some time and to reflect on it. The result was a quick lightning talk, which I discussed with my team. Next, I also want to share the main thoughts about it in this article.

The Reactivity is 🔥

To compare, in the jQuery demos, it took a lot of boilerplate code to input something like reactivity into my application.

Svelte is designed for exactly that use case. As an example, binding variables to a component template makes it way easier to react to changes in the state and switch to different views.

<script>
    export let view;
    export let activeView;
</script>

<div
    class="wrapper"
    style="display: {view === activeView ? 'block' : 'none'}">
        {#if view === activeView}
            <slot/>
        {/if}
</div>

Furthermore, it allows me to react to user selections, for example, when the user changes the hit policy inside a DMN decision table quickly.

<script>
    export let tableData = {};

    const HIT_POLICIES = [ /* ... */ ];

    $: explanation =
        find(
            HIT_POLICIES, 
            hp => hp.name === tableData.hitPolicy
        ).explanation;

    function changeHitPolicy(event) {
        const {
            target: { value }
        } = event;

        tableData.hitPolicy = value;
    }
</script>

<select on:change={changeHitPolicy}>
    {#each HIT_POLICIES as { name }}
        <option selected={name === tableData.hitPolicy}>{name}</option>
    {/each}
</select>
<p class="hp-explanation">{explanation}</p>

Imagine doing that with jQuery, it would take me some actions to rerender the explanation p node. Svelte, by design, is doing that for you.

Component Templating

When creating my jQuery demos, I also tend to develop modules for different UI components. But even here, the boilerplate code to render this stuff was just pain.

Creating Svelte components is more comfortable than that

<script>
    import Table from '../../../decision-table-layout/src/components/Table.svelte';
    import ArrowExpandSvg from '../../resources/arrow-expand.svg';

    import './NavigationTable.scss';

    const noop = () => {};

    export let onViewSwitch = noop;
    export let tableData;
</script>

<div class="navigation-table">
    <div class="buttons">
        <span class="arrow-expand btn btn-sticky" on:click={() => onViewSwitch('split-screen')}>
            {@html ArrowExpandSvg}
        </span>
        <button class="edit-drd btn" on:click={() => onViewSwitch('drd')}>
            Edit DRD
        </button>
    </div>
    <Table { tableData } />
</div>

It also allowed me to do particular re-use components, like the Table component, in other parts very smoothly.

Global State

Managing state can also be rough, and you tend to use specific state management libraries for that, like Redux in React. I was not forced to do something like that in my demo, but it was nice to get the overall data from one entry point and re-use that in all of my components.

So, whenever something of my table data changes, the different parts of my UI would be re-rendered due to those changes. There is no virtual DOM included, which makes it a bit faster. Svelte itself explained briefly, why this approach solves some problems.

<script>
    import data from '../resources/data.js';
    let currentTable = data['Decision_03absfl'];
    let view = 'drd';
</script>

<Wrapper view="drd" activeView={view}>
    <DRD decision={currentTable.id} />
</Wrapper>

<Wrapper view="split-screen" activeView={view}>
    <SplitScreen tableData={currentTable} />
</Wrapper>

Summary

Honestly saying, I just started to use Svelte for my demo applications, and there are lots of more aspects to learn. The reason I did not switch to React, which I used a lot of times before, was simply that I wanted to give Svelte a chance.

The general expression was very good. The development speed and experience was unexpectedly good. To be clear, it just felt very good to create this demo.

In comparison to jQuery, it makes things way easier, like reactivity and state management. I can recommend to try it out.

A Lightweight React Library for creating clickable Prototypes

Niklas Kiefer — Thu, 19 Dec 2019 15:49:14 +0000

As a little Holiday project, and as a follow-up of the DMN Innovation Week we had at Camunda, I created a small React components library to quickly create clickable prototypes.

Inside Innovation Week, we created multiple small prototypes to test various ideas on how to improve the DMN experience in bpmn-io. Inside that, I used jquery to create a click-prototype and use it inside user tests. The results can be seen in this GitHub repository.

Yes, jquery is not the best solution to save the application state, like to save the actually visible view. Therefore I wanted to have a simple library that managed the interaction between different screens/views and where I only have to declare the click points which should direct to the next view.

I've chosen React and created the clickable-prototype project. It offers different components to declare your clickable prototype. A simple React Application using that would like that

import React, { Component } from 'react'

import { View, HitBox, ViewContainer } from 'clickable-prototype'

import view1 from './views/view1.png'
import view2 from './views/view2.png'

export default class App extends Component {
  render () {
    return (
      <div>
        <h1><span>clickable-prototype</span> Demo</h1>
        <ViewContainer defaultView='view1' className='container'>
          <View
            key='view1'
            className='custom-view'
            screen={view1}
            width='1220px'
            height='630px'>
            <HitBox
              position={{y: 380, x: 477, width: 280, height: 60}}
              to='view2' />
          </View>
          <View
            key='view2'
            className='custom-view'
            screen={view2}
            width='1220px'
            height='630px'>
            <HitBox
              position={{y: 490, x: 477, width: 280, height: 60}}
              to='view1' />
          </View>
        </ViewContainer>
      </div>
    )
  }
}

This will result in the following prototype

It's a very early stage of the library but it helps me a lot to quickly create clickable prototypes without any extra fancy stuff as you'd have in applications like InVision.

I would really appreciate if you give it a try and give some feedback!

Building a honkify extension for bpmn-js

Niklas Kiefer — Thu, 03 Oct 2019 09:48:56 +0000

Something for the fun department: Yesterday I found this amazing project, which replaces any link on a page with a duck "honk": honkify.js. This inspired me to build a simple bpmn-js extension which adds this honk on several modeling operations, e.g. adding, moving or removing BPMN shapes from the canvas:

/// Honk.js

import CommandInterceptor from 'diagram-js/lib/command/CommandInterceptor';

import inherits from 'inherits';

import showToast from 'show-toast';

export default function Honk(injector) {

  injector.invoke(CommandInterceptor, this);

  const audio = new Audio(
    'https://res.cloudinary.com/jlengstorf/video/upload/q_auto/v1569957993/honk-sound.mp3',
  );

  function _honk(context) {

    console.log('honk fired.', context);

    // honk
    audio.play();

    // show toast
    showToast({
      str: 'Honk 🦆🦆🦆!',
      time: 500,
      position: 'top'
    });
    return false;
  }

  this.execute([
    'shape.create',
    'shape.move',
    'shape.delete'
  ], _honk);
}

Honk.$inject = [
  'injector'
];

inherits(Honk, CommandInterceptor);

I put the results in a small GitHub project, which everyone can simply install via npm and directly integrate into their bpmn-io application.

This fun example showcases how easy it is to build extensions for the bpmn-io toolkit. Also, have a look at the bpmn-js-nyan-cat for another little example of how to bring joy in your modeling application.

Enjoy!

VS Code Extension - Render Process Diagrams with bpmn.io

Niklas Kiefer — Mon, 30 Sep 2019 12:35:17 +0000

As another exciting pet project, we created a Visual Studio Code extension for rendering BPMN 2.0 process diagrams. It is built on top of the amazing modeling toolkit bpmn-io and can be found on GitHub.

You can directly download it from VS Code Marketplace or follow the setup instructions to get it running locally.

With this extension, it is possible to display a preview for your BPMN 2.0 diagrams. It also refreshes the preview whenever you re-focus it, to adapt made changes in the XML content.

As a next step, we plan to also add a modeling functionality to enable the powerful BPMN diagram editing capabilities of bpmn-io. This will help to easily create BPMN process diagrams in Visual Studio Code without writing one line of XML.

Feel free to try out the extension and leave some feedback or a star for our work!

render-bpmn: Upload and Display BPMN | CMMN | DMN Diagrams on Github

Niklas Kiefer — Thu, 22 Aug 2019 14:40:36 +0000

The 2019 Camunda Summer Hackdays was a good place to work on long-time planned projects which I had no time for the last months. After three days we built a good working prototype on how to render BPMN diagrams on GitHub. Checkout and leave some feedback or a star out there ⭐️.

General Problem

It's currently hard to display BPMN files on GitHub. In the case of images, the application offers post-processing of the uploaded files in order to quickly display them. Unfortunately, this does not work for process diagrams. This kind of diagrams can be really helpful to outline feature requirements or bug root analysis. Right now, it requires to open these BPMN files in an external tool, as bpmn.io, to properly display them or to convert the files to images.

Hacking Prototypes

In the 2019 Camunda Hackdays we wanted to create several prototypes in order to automatically render BPMN files in GitHub repositories. In the resulted repository we provide these solutions. It solves the problem in two ways:

Automatically render BPMN files in Issues and Pull Requests

The self-hosted probot application offers an auto-rendering of uploaded BPMN files via bpmn.io.

Automatically render BPMN, CMMN and DMN diagrams in repository file tree via hover

You can easily include the resulted userscript via Tampermonkey or use the adapted Chrome extension.

Conclusion

The resulting project offers an easy way to quickly display your beloved BPMN, CMMN or DMN files in your GitHub repository. We plan to increase the feature set soon, as long we find time for that. Feel free to try out the solutions, we'd love to hear some feedback ❤️ and receive some 🌟 on GitHub.

DEV Community: Niklas Kiefer

use-spinner - Show loading spinners for your asynchronous calls

pinussilvestrus / use-spinner

Add a simple loading spinner to your async JS calls - built for the browser.

use-spinner

Installation

Usage

Options

License

New version of postit-js got published

pinussilvestrus / postit-js

Create post-it boards - built with diagram-js

Thinking Backward - or: searching for the Big Why

Creating the unknown - What and what not to build in efficient prototypes

Niklas Kiefer ・ Apr 14 '20

Working Backwards © Amazon

It's all about shaping

Begin with the problem - jump back if necessary

Find the Big Why

It does not have to be a press release

Summary

Creating the unknown - What and what not to build in efficient prototypes

Background: Agile Prototyping

Know the use case

It's about Innovation + Inspiration

Start with a pen

It's not a feature branch

Keep it simple

Build fast, fail faster

Think about variations

Keep the best

Summary

Creating Demos with Svelte - Lessons Learned

The Reactivity is 🔥

Component Templating

Global State

Summary

A Lightweight React Library for creating clickable Prototypes

Building a honkify extension for bpmn-js

VS Code Extension - Render Process Diagrams with bpmn.io

render-bpmn: Upload and Display BPMN | CMMN | DMN Diagrams on Github

General Problem

Hacking Prototypes

Conclusion