Forem: Jellene Khoh

Docker Alpine + ExpressJS + Angular

Jellene Khoh — Tue, 09 Apr 2019 13:58:05 +0000

This was for a project that I did recently that required a reporting dashboard app to be served from a docker image, and would live inside small low-powered linux devices.

The app had to fulfill these criterias:

It needs to be replicated quickly for many devices
It needs to be small, there isn't a lot of space
It needs to be able to connect to MariaDB database in the localhost network
Certain fields are configurable from a JSON database that is exposed outside the container.

Docker container containing an ExpressJS app that serves an Angular app

Docker

1. It needs to be replicated quickly for many devices

Docker has been around for a considerable time already, released on 2013, it aims to solve the problem of "But it works on my computer".

A popular use of docker is to pair it with kubernetes to spin up multiple microservices to handle large spikes of concurrent users, and then remove them after the spike to save resources. Each microservice is a tiny server on its own.

Since docker images are essentially like a backup copy of a tiny server, it will always run the same way without much configuration. Which makes it easy to copy the image to any new device, and spin up a new docker container running the app.

Architecture Solution

Use Docker to containerize the app
ExpressJS serves as a web server for the frontend Angular app.
ExpressJS uses lowdb to read/write configurations to a JSON file in a folder called data/.
ExpressJS uses knex.js to query SQL database.

The final work folder looks something like this –

    backend/
        |- src/...
        |- dist/
            |- server.min.js
    frontend/
        |- src/...
        |- dist/
            |- public/
                |- main.min.js
                |- vendor.min.js
                |- index.html
    docker/
        |- data/
            |- local-db.json
        |- server.min.js
        |- package.json
        |- public/
            |- main.min.js
            |- vendor.min.js
            |- index.html
        |- Dockerfile
        |- .dockerignore

Both frontend and backend is minimized to reduce space. The contents of the the minimized code is copied to the docker folder so that it is easier for me to pack it into a docker image.

Express server is serving the public folder (Angular app) under root route. While the rest of the API starts with /api/ prefix. This also means that Angular can use /api when calling http, so it'll always call something in the same domain.

    this.http.post('/api'+ reportUrl);

Package.json from the backend is included as well, because I need install the node_modules required for the ExpressJS app. It's probably possible to somehow bundle the dependencies using Webpack, but I was strapped for time and didn't investigate further how to do so.

    import * as FileAsync from 'lowdb/adapters/FileAsync';
    const low = require('lowdb');

    low(new FileAsync(path)).then(db => {
        db.defaults({
            maxEntries: MAXENTRIES,
            configs: []
        })
        .write();
    });

This will write a default JSON configuration to data/local-db.json.

Dockerfile

2. It needs to be small, there isn't a lot of space

A common practice during development is the throw all the source files into the docker container and run a full node.js server to serve your application. It's the easy, fast, painless.

But a full node.js on debian server is quite big - nearly 650MB from the start. After installing our ExpressJS app and Angular it went to about 1.3GB.

So we opted to go with the new barebone OS based on Alpine linux, which is a huge 50MB. With everything installed, it came up to about 300MB. Still much smaller than the full server image.

The full list of available node base images are here.

A barebone OS means that we need some extra files in order to install the node modules.

    FROM node:10.15.3-alpine

    ENV JWT_SECRET 512FF7B2EMCKAHG24C
    ENV BCRYPT_SALT 12
    ENV PORT 8080
    ENV TOKEN_EXPIRES_IN 24h

    WORKDIR /usr/src/app
    COPY . .
    RUN apk --no-cache add --virtual native-deps \
        bash g++ gcc libgcc libstdc++ linux-headers make python && \
        npm install --quiet node-gyp forever -g &&\
        npm install --production --quiet
    EXPOSE 8080
    CMD forever server.min.js 8080

There is a very detailed documentation on how to write a Dockerfile, but essentially a docker file is similar to a bash script that runs commands in sequence and finally serve the app.

FROM node:10.15.3-alpine is how I select the image as a base for the container.

I'm setting environment variables with the ENV command. Which can then be read in the ExpressJS app via process.env.

WORKDIR selects the current folder I want to use IN the container. If no directory exist, Docker creates them.

I include several installs (gcc, python etc) that is required for node to be built.

And then finally serving server.min.js with Forever.

Forever is a CLI tool that will run the node server as a daemon, and cannot be killed accidentally.

Docker Run

3. It needs to be able to connect to MariaDB database in the localhost network

Now comes the fun part – running the app. First we must build it.

    $ docker build --tag node-app:alpine .

Docker build reads the command from Dockerfile and builds an image.

--tag allows me to name the docker image, so that it's easier to find it later.

After building, docker images shows that I've indeed built an image

    $ docker images

    REPOSITORY     TAG          IMAGE ID         CREATED          SIZE
    node-app       alpine       f4ca2e0425a0     3 days ago       354MB

Now to run the docker image

    $ docker run \
        --name node-app \
        --network host \
        --restart 'unless-stopped' \ 
        --detach \
        node-app:alpine

--name lets me set a custom name. If it's not provided, docker will create a name for you like precious-grauss or similar.

--restart will make the running container run forever unless specifically stopped.

--detach will make it run in the background, freeing up my terminal for other things. If you don't use this, you'll need a 2nd terminal to stop your docker container.

--network is the key option here. One of the requirements is that the docker container should be able to connect to a database on localhost. And by using the option host, we can do so. There are other methods of creating docker networks and connecting containers together. You can read more here.

With this command, I am now able to see the app run on localhost:8080. And my app is able to connect to the database successfully. 🎉

Docker volume

4. Certain fields are configurable from a JSON database that is exposed outside the container.

The docker container should now be running smoothly, until, I find that the local-db json isn't really updated. And I'm not able to control the configuration from outside the container.

That's because I left out the --volume option during docker run that allows me to mount a folder unto docker, which can then be shared between host machine and the docker container. You can read more about data persistence in docker here.

    $ docker run \
        --name node-app \
        --volume $(pwd)/data:/usr/src/app/data \
        --network host \
        --restart 'unless-stopped' \ 
        --detach \
        node-app:alpine

$(pwd) will insert the current working directory into the command. If I were to call docker from a different folder, the pwd will be different.

Here the volume command mounts the data folder to the data folder that exists inside the docker container /usr/src/app/ folder. If the target folder does not exist, --volume will create it for me.

Run this, and now I can control the configs from outside.

Saving and Loading images

Now that I have the image up and running. I need to export the image into a format I can import into different devices and start up the same instance.

    $ docker save -o ./node-app-image.tar node-app:alpine

The save command exports the current image state into a tarball. I make sure that I have not added any custom configuration, because I don't want them saved into the image.

    $ docker load -i ./node-app-image.tar

I then run the load command after I have downloaded the tarball into the machine. Loading the image will include the image into docker images. And then I do the run command as before, and it should find the same node-app:alpine image I saved.

Thoughts

Docker is really quite powerful. It has let developers scale up apps instantly and confidently, because the environment will always be exactly the same.

That said, I think the docker documentation can be a little easier to deal with. There is just such a huge amount of configuration to learn, it is no wonder docker setup is a career on its own.

Regardless, learning docker is exciting. Let me know if there is a better way!

Resources

[1] https://github.com/nodejs/docker-node
[2] https://github.com/nodejs/docker-node/issues/282
[3] https://stackoverflow.com/questions/43316376/what-does-net-host-option-in-docker-command-really-do
[4] https://stackoverflow.com/questions/12701259/how-to-make-a-node-js-application-run-permanently

Fundamentals of UX

Jellene Khoh — Mon, 01 Apr 2019 19:06:56 +0000

Cover Photo by Hal Gatewood / Unsplash

UX (user experience) is the answer to the question of "why" and "how". Why should we have this feature? Why is the button red? How do I look at my settings? Why is it so slow?

Most of the time we associate UX to UI (user interface). But UI is only a small part of the larger picture. The user can also be a programmer, or a customer of a physical device. The main goal of UX design is to create a frictionless experience for the user[7].

The UX designer is usually an integral part of the agile development cycle between design and development, connecting good design, software development, and business goals into a wholesome and focused package. Software developers backend or frontend can benefit from UX knowledge.

Designers are the bridge between business and users, being this characteristic one of our strength. — Diego Mazo [2]

The folks at UX Collective asked the community what skills are needed as a UX designer. These are the 5 skills[1] they think are required to be an expert in UX design:

Visual Design: Do you know the fundamentals design patterns and Gestalt principles?
Business alignment skills: Can you communicate the business value of your design work and tie it into the overall goals of the company?
Research: Can you collect actionable insights from customers and users through strategic (are you solving the right problems) & tactical research (are your designing the right solutions)?
Organization & Communication: Are you able efficiently convey your message both in terms of information architecture and content?
Technical: Can you code whatever you had visually designed? Make a simple prototype?

Today we're going to look at the visual part (or UI) of UX design. These are a few laws and principles that we as software developers can follow to increase usability of our app.

Gestalt's Theory
‌User's tendency to visually categorize by scanning, not reading
Jakob's Law‌
‌User prefer websites that work the same way
Fitts's Law‌
‌Increase size of important action buttons
Hick's Law‌
‌Less option is better
Miller's Law‌
‌We can only effectively remember up to 7 elements at once
Endowed Progress Effect
‌Progress bar make users finish the task
Doherty's Threshold‌
‌Things need to happen <400ms to keep attention span
Hand gesture design‌
‌Mobile first design

‌

Gestalt's Theory

Gestalt's Theory is a pyschological concept from 1890s that explores the way how people perceives information and using them to build good navigation, digestible copy, and effective color choice that has a great impact on the usability of the product[3].

Modern UX patterns uses principles of Gestalt's Theory one way or the other. By knowing the factors influencing visual perception, you can design the UI as to lower the level of misunderstandings users could perceive from the software. [3]

‌

#1: Figure-ground Principle

The figure-ground principle states that if the visual field is homogeneous throughout, and there is a figure of a different color, there is a tendency to see the figure as positioned in front.

This is most apparent in the "card" system design whereby we insert important fields in white boxes to bring it to the front. Generally we do not want to go beyond 2-3 layers of foreground-background, or else it gets too "tall".

“White space is to be regarded as an active element, not a passive background.” _— Jan Tschichold_ [8]

^{White cards make it standout from the background. Source}

I would also say that having a separate color for call-to-action (CTA) buttons also brings it out to the foreground. It projects a more positive action. This effect is also called the The Von Restorff effect.

^{The accept button is usually colored to make it stand out. Source}

‌

#2: Similarity Principle

The principle of similarity states that we tend to group things together when they look similar.

^{When items have the same color, we tend to group that together. Source}

We can use that in chat boxes to separate who is talking. Using colors to separate ownership is an easy way to utilize this principle.

^{You can clearly see the blue speech are your own. Source}

‌

#3: Proximity Principle

The principle of proximity states that things that are close together appear as forming a group.

^{We instinctively group them by how close the group are to each other. Source}

^{The distance between the elements group them into separate items. Source}

Whitespace between elements are very powerful. It's like a table with invisible lines, but much cleaner than using lines to separate elements in a grid format.

‌

#4: Common Fate Principle

The principle of common fate states that when objects act or move the same way, we perceive them as being grouped together.

^{via GIPHY}

Using animation we can indicate a new page, or pop over menu. It's a good way to introduce new UI elements if you move them into the page together.

‌

#5: Continuity Principle

The principle of continuity states that elements that are arranged on a line are perceived to be more related than elements that are not.

^{We group items based on alignment. Source}

^{Horizontal alignment also indicate that the plus button is for adding the blog somewhere. Source}

Aside from indicating groups, aligning elements in the page together helps give the sense of togetherness. As humans, we find symmetry and orderliness pleasing, even on a subconscious level.

‌

#6: Closure Principle

The principle of closure states that we can fill in the missing information when elements in a composition are aligned in such a way that the viewer perceives that "the information could be connected."

^{Notification badges implies that we have number of items associated with the link. Source}

^{We can guess that the action buttons below relates to Property Taxes, and not Rent. Source}

Icons and badges are good examples where users generally can connect what the icon means, to a function that it might trigger.

‌

#7: Simplicity principle

This principle implies that as individuals perceive the world, they eliminate complexity and unfamiliarity so they can observe a reality in its most simplistic form.[4][5]

I take this to mean general composition of the elements in the page. When users scan the page, they see large chunks of sections so that they can navigate with ease.

^{Ember's landing page separated to several parts. Source}

We can see here in Ember's landing page that there are clearly separated parts in the page. Each part has its own principle to tie it together, but on a larger scale, they also connect to each other.

‌

#8 Past experience principle

This principle implies that elements tend to be grouped together if they were often together in the past.

Using green to indicate positive, and red to indicate negative, is one way to immediately project association to the action.

^{Red usually means irreversible damage. Source}

This can also be explained with Germane Cognitive Load: whereby it’s easier for the users to recognize and learn something new if they can discern it into a pattern from something they already understand. [6]

^{Expandable content indicated by the arrow. Source}

From the chevron arrows, we recognize that it seems to be a box that can be toggled to expand. We can reuse patterns like these so that users immediately know how to use the app. This is very similar to the next point - Jakob's Law.

‌

Jakob's Law

Jakob's Law is coined by Jakob Nielson. It states that users prefer your site to work the same way as all the other sites they already know. [11]

^{Input for Whatsapp, Telegram, and Facebook messenger}

We are all familiar with chat apps. And users expect that their chat app will be a box in the bottom, with a text box, and some option for inserting emojis. It can be in a totally different language, and still users know where to find it.

‌

Fitts's Law

Fitts's law is the amount of time required for a person to move a pointer to the desired button (e.g. CTA) decreases with larger size and shorter distance[9].

In other words, the action button should be made larger, and the distance between a user’s task/attention area and the task-related button should be kept as short as possible.

^{User eye movement heatmap. Source}

Research has established that the user scans the website in an "F" pattern, starting from the top left, and forms an opinion about the website within 50 ms[10].

^{Everything is on the top left. Compose being the largest button. Source}

Google made this work by placing the most prominent feature of Gmail on the top left in a big white button. And to the right is the email list. Immediately the user finds the most important feature gmail has to offer. Also, many of the filtering buttons are close to each other.

‌

Hick's Law

Hick's Law is the time it takes for a person to make a decision decreases as a result of the lesser possible choices they have.

^{Amazon Web Services UI improves by reducing options per page. Source}

We can see how Amazon greatly improved their UI by grouping their services by smaller groups, thus having less options to choose per page.

Another business related use of this concept is in pricing. When given too many pricing option, users are left confused and unable to make a decision. Having lesser options increases the time to make a decision.

^{Firebase has only 3 tier pricing for their services. Source}

‌

Miller's Law

Miller's Law states that people can remember up to 7 different elements in their working memory, anything more will increase the percentage of errors.

^{Google Calendar shows approximately 7 items on the page at one time.}

We can reduce the amount of item on the page to roughly 7. If it's too little, try breaking it up into smaller chunks of 7 or less. Subheadings, layers, borders, are some of the way to section your information.

It's also a good idea to limit authentication code to less than 7 characters.

^{Steam Guard code}

I imagine it would be quite annoying if you had to fill in 20 character authentication code in 3 seconds.

‌

Endowed Progress Effect

Researcher Joseph C. Nunes documents the effect whereby people provided with artificial advancement toward a goal exhibit greater persistence toward reaching the goal. [13]

^{The classic windows progress bar. Source}

I'm sure everybody knows about the progress bar. But did you know many apps had to insert a fake progress bar, so that users feel better? [14]

Actual progress bars are probably harder to replicate in an async function, but there is a place where progress bars can help a lot — wizards.

^{Salesforce forms uses progress bar to guide users. Source}

Wizards break up the mundane process of data entry, it also gives users a sense of progress so that it feels like they're moving forward.

‌

Doherty's Threshold

In the age of fast internet, the worst sin is to have a slow app. Walter J. Doherty published a research paper in 1982 that set the requirement for computer response time is <400ms. [15] Any slower than that, the system is considered slow.

Aside from the obvious optimization of the system, we can also employ a few tactics to slow the user down.

We explored progress bars previously, it can help immensely to provide an immediate feedback.

Another way is to run processes in the background. For example deleting an email might remove the item from the screen immediately, but the actual DELETE call can be run in the background so that users perceive it as fast.

^{via GIPHY}

‌

Hand Gesture Design

There are nearly 5 billion phone users in 2019 [16], that's nearly 70% of the world use mobile phones. All the newest web apps have responsive design to fit the mobile screen. But are we designing it with mobile in mind?

Here are a few ways to make it easier for phone users:

Assume users will use their thumbs, not a stylus
Have important buttons at the bottom of the screen
Allow swiping to do actions
Large buttons for fat fingers
Optimize for right hands (sorry left-handers, you're only 10% of the population)
Allow toggle-show password, typos are very common on phones
Make sure input field is visible when keyboard is up.

^{Photo by Georgia de Lotz / Unsplash}

‌

Honorable Mentions

Tesler's Law - for any system there is a certain amount of complexity which cannot be reduced. [12]
Zeigarnik Effect - people tend to remember about an objective that was once pursued and left incomplete. [17]

‌

How can I apply this to software development?

With all these information about user behavior, it only works if we implement and use it in our development. How can we do so?

Be consistent with your use of color in buttons
Reserve strong colors for important elements, everything else can be muted
Split your information into a hierarchy of smaller things
Give immediate visual feedback
Have max of 7 items for every section
Position important items on the top left for desktop, and bottom right for mobile
Follow other website's behavior liberally
Keep everything aligned
Use the software you develop

What about software for developers? Developers are users too. They react in similar ways.

Use consistent APIs
Expose high level functions, not every low level function in the file
Split your library into smaller modules
Give instant and human readable error messages
Include documentation on the top of the library file
Follow similar behavior as other popular libraries
Use the library you develop

Now, break all the rules that you've just learned because design is never set in stone. Happy UX Designing!

‌References

[1] https://uxdesign.cc/what-does-it-take-to-become-an-experience-design-expert-eba0e0d588eb‌

‌[2] https://medium.com/strategic-design-lab/what-a-strategic-designer-does-b942f295379‌

‌[3] https://tubikstudio.com/gestalt-theory-for-efficient-ux-principle-of-similarity/‌

‌[4] https://en.wikipedia.org/wiki/Gestalt_psychology‌

‌[5] http://vanseodesign.com/web-design/gestalt-principles-of-perception/‌

‌[6] https://blog.marvelapp.com/psychology-principles-every-uiux-designer-needs-know/‌

‌[7] https://www.belatrixsf.com/blog/why-ux-design-is-so-important-in-agile-software-development/‌

‌[8] https://www.smashingmagazine.com/2014/05/design-principles-space-figure-ground-relationship/‌

‌[9] https://www.interaction-design.org/literature/topics/fitts-law‌

‌[10] https://www.researchgate.net/figure/The-F-Pattern-heat-map-in-reading-webpages-Nielsen-2006b_fig1_321859889‌

‌[11] https://lawsofux.com/jakobs-law‌

‌[12] https://lawsofux.com/teslers-law‌

‌[13] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.545.2322&rep=rep1&type=pdf‌

‌[14] https://news.ycombinator.com/item?id=16289380‌

‌[15] https://lawsofux.com/doherty-threshold‌

‌[16] https://www.statista.com/statistics/274774/forecast-of-mobile-phone-users-worldwide/‌

‌[17] https://medium.com/coffee-and-junk/design-psychology-zeigarnik-effect-a53688b7f6d1

Using Plotly.js Charts for Dashboards

Jellene Khoh — Sun, 24 Mar 2019 12:38:33 +0000

Today we're going to look at a really powerful charting library that is really easy to use and set up. Plotly Open Source Graphing Library supports several programming languages, including Python, Matlab, R, and most importantly Javascript!

I've had to build a few dashboards for IoT companies, and charts are definitely one of the biggest elements in the view. Need I say more about the significance of charts to business related reporting such as sales, network monitoring, stocks etc.

Plotly offers many kinds of charts and maps, but the most common ones I use are:

Line charts
Bar charts
Step charts

Below I'll walk through the basics on how I use plotly.js in an actual project.

Installation

Very similar to other charting libraries, you can get them via CDN or npm packages. More detailed guide is in their github page.

CDN

Insert the script in the head of index.html

    <head>
        <script src="https://cdn.plot.ly/plotly-latest.min.js"></script>
    </head>

NPM

To install with npm simply do

    $ npm install plotly.js-dist

Note that it is plotly.js-dist and not plotly.js

Import

Now to import it into your project do

    import Plotly from 'plotly.js-dist'

    ...

    Plotly.newPlot('div-id', data, layout, options);

In the html you'll need a div with the id you want to point to.

    <div id="div-id"></div>

Really easy stuff!

Plotting a basic chart

Now let do a basic line chart.

@Codepen Basic Line Chart

The javascript for this small chart is simple, we want to break down some of the important flags you need.

    var trace1 = {
      name: 'Energy consumption',
      x: ['1-3-2019', '2-3-2019', '3-3-2019', '4-3-2019', '5-3-2019', '6-3-2019', '7-3-2019'],
      y: [10, 15, 13, 17, 19, 10, 11, 13],
      type: 'line',
      line: {
        color: '#45B5C6'
      }
    };

    var trace2 = {
      name: 'Cold water consumption',
      x: ['1-3-2019', '2-3-2019', '3-3-2019', '4-3-2019', '5-3-2019', '6-3-2019', '7-3-2019'],
      y: [16, 5, 11, 9, 0, 4, 0],
      type: 'line'
    };

    var data = [trace1, trace2];

    layout = {
        showlegend: false
    }

    Plotly.newPlot('myDiv', data, layout, { 
      responsive: true,
      displaylogo: false
    });

trace

Each series in the chart is referred to as a trace. The xaxis is usually the time range, and the yaxis is the value. Here, I purposely use string for my xaxis because I want to be able to parse it into different localized format, e.g. Feb 2, 2019 in US, vs 2.2.2019 in Finland. Or even into quarters e.g. Q1/2018.

     @note: Plotly has locale config, but I wanted more control.

If you treat each xaxis item as a category, then everything will work fine. If xaxis is an array of Date\ items, Plotly will automatically parse it into a timeseries chart.

You can specify the line color of the each trace. If you leave it out, Plotly will provide a color based on the index. To change the color, add an entry

    line: { 
        color: '#fff' 
    }

Notice that data requires an Array of object. This is a little bit different from other charting libraries like Google Charts or Highcharts.

layout

Layout is the general settings for Plotly. Here we're hiding the legends by adding this in the object.

    showlegend: false

Legends allow you to show / hide each trace, which is pretty handy, but I've decided to turn it off. In my app, I have other buttons outside the chart for me to control showing and hiding of each data, so I don't need the legends.

Other configurations that I usually use for layout are font, autosize, margin, to make the chart fit your container.

Full documentation here: https://plot.ly/javascript/reference/#layout

configuration

These configurations are extra options for other functions around the chart, such as:

Allowing Scroll and Zoom
Modebar show / hide

Useful ones for me are

    {
        responsive: true, 
        displaylogo: false
    }

This should be pretty self explanatory - the configuration allows the chart to change width according to the window, and also remove Plotly's logo from the modebar.

Full documentation here: https://plot.ly/javascript/configuration-options/

Multiple axes

We now explore how to use different chart types in the same plot.

@Codepen Multiline Chart

    var trace1 = {
      name: "Energy consumption",
      x: [
        "1.3.2019 00:00",
        "1.3.2019 03:00",
        "1.3.2019 06:00",
        "1.3.2019 09:00",
        "1.3.2019 12:00",
        "1.3.2019 15:00",
        "1.3.2019 18:00",
        "1.3.2019 21:00"
      ],
      y: [20, 50, 92, 82, 14, 20, 50, 62],
      text: ['20 kw/H', '50 kw/H', '92 kw/H', '82 kw/H', '14 kw/H', '20 kw/H', '50 kw/H', '62 kw/H'],
      hoverinfo: 'x+text+name',
      type: "bar",
      marker: {
        color: '#270657'
      }
    };

    var trace2 = {
      name: "Air pressure",
      x: [
        "1.3.2019 00:00",
        "1.3.2019 03:00",
        "1.3.2019 06:00",
        "1.3.2019 09:00",
        "1.3.2019 12:00",
        "1.3.2019 15:00",
        "1.3.2019 18:00",
        "1.3.2019 21:00"
      ],
      y: [81.32, 72.1, 121.41, 71.31, 40.98, 30.96, 51.2, 71.92],
      text: ['81.32 Pa', '72.1 Pa', '121.41 Pa', '71.31 Pa', '40.98 Pa', '30.96 Pa', '51.2 Pa', '71.92 Pa'],
      hoverinfo: 'x+text+name',
      type: "line",
    };

    var trace3 = {
      name: "Lights",
      x: [
        "1.3.2019 00:00",
        "1.3.2019 03:00",
        "1.3.2019 06:00",
        "1.3.2019 09:00",
        "1.3.2019 12:00",
        "1.3.2019 15:00",
        "1.3.2019 18:00",
        "1.3.2019 21:00"
      ],
      y: ["off", "on", "on", "on", "off", "off", "on", "on"],
      type: "line",
      line: {
        shape: "hv",
        color: '#45b5c6'
      },
      yaxis: "y2"
    };

    var data = [trace1, trace2, trace3];

    layout = {
      showlegend: false,
      yaxis2: {
        type: "category",
        side: "right",
        overlaying: "y"
      }
    };

    Plotly.newPlot("myDiv", data, layout, {
      responsive: true,
      displaylogo: false
    });

Chart types

Here we have 3 basic chart types - line, step, and bar charts. You can configure them for each trace

    type: "line"

    ...

    type: "bar"

    ...

    // step chart
    type: "line",
    line: {
        shape: "hv",
    },

also notice that by setting the second yaxis2, we're able set a second yaxis on the right side of the chart for text based categories.

    {
        ...
        text: ['81.32 Pa', '72.1 Pa', '121.41 Pa', '71.31 Pa', '40.98 Pa', '30.96 Pa', '51.2 Pa', '71.92 Pa'],
        hoverinfo: 'x+text+name',
        ...
    }

Custom text can be used to insert unit to the values. hoverinfo allows you to customize what you want to show when the mouse is hovering over the value. If we use the text instead of y then we can have the unit shown.

Putting it together

Demo iot dashboard

Here is a real life example of an iot dashboard for showing value changes of live sensor data.

Hopefully with this you can use Plotly in your future projects with ease.

View more examples of plotly here in the feed: https://plot.ly/feed/#/

Other charting libraries

Also published in my blog jellenekhoh.io