My first post in this year's calendar on some improved functional aspects of C# was immediately met with some well deserved snark:

Well, no, but I still love C# more 😘

However, F# is a fun and well-designed language with a loyal following, OK tooling support from Microsoft and has one great advantage over other primarily functional languages: the entire .Net ecosystem is available to us! And this naturally includes Xamarin and the power to easily write modern mobile apps using your favorite language.

As a language F# has a couple of striking benefits over C#:

The concise syntax makes it easier to focus on what matters instead of boiler plate code

The really expressive type system makes domain modeling a breeze with more options than C# and with perhaps even more correctness

My beloved immutability has always been a staple of F#

And as a functional first language, all the nice functional patterns are available to us in a natural way

Mobile development with F#

Getting started is as easy as downloading Visual Studio and choosing F# as our language of choice in the New Project wizard.

With the tooling in place, what advantages will F# give us on mobile?

On the naive face of it, not much.

Take iOS for example, with its heavy use of MVC. Consider the following example of a ViewController containing a pristine green background with a simple heartfelt label:

One screen, one color, one label and TWO mutations.

A discourageable start, but there is hope.

All in with MVU

A year ago, I wrote about using the Fabulous framework and MVU pattern on this very blog, thus making mobile go fully functional.

As fabulous as Fabulous can be, this road requires commitment. From us, our team and preferably out organization too! The thinking behind MVU is markedly different from MVVM or MVC and needs to be understood for the pattern to be more effective and less error prone than its older friends.

MVU is best utilized in a green field setting or within logically self-contained parts of the app.

The .Net advantage

Since F# easily interfaces with other .Net languages, we don't need to go all in.

A safe introduction to mobile development with F# is to model the domain using F#, and use C# (and XAML) to describe and interact with the UI-layer. In MVVM and MVC both, the M might better be described by F#'s richer type system.

In addition, this approach is easier on our peers, since modeling in F# can be done piecemeal even in mature code bases. Should be an easy sell!

Conclusion

To summarize, both iOS' and Android's UI frameworks are naturally object oriented, same for Xamarin Forms. Thus, F# is not a natural drop-in replace for C# when writing mobile apps, but rather an excellent option for modeling our domain. Giving expressive power, ease of testing and clean code where it matters the most: the business rules and their data.

Unless off course we go Full Elmish.

Using F# in Xamarin Apps

I recently switched projects, and if you've ever started at or switched jobs to a mid- or large-size enterprise, you probably know the onboarding process can be both long and exhausting. Possibly sitting there weeks on end, without access to the services you need, and purely feeling like a bother because you have to ask one of your colleagues for help the 3027th time this week. Welp, I just shudder at the thought of it, and if you do too, I just might have the answer to all our boundary issues!

By Whom and What

As the cloud space has gotten bigger, so has the need for tools and products for provisioning, security and run-and-connect tools for cloud-computing infrastructure. So when Hashicorp, one of the leading companies in this commercial area decides to announce two new products(HashiConf 2020) for the first time in 5 years, it's worth taking a peek. One of these products is Waypoint, which in their words is a tool for consistent developer workflow to build, deploy, and release applications across any platform. That might be intriguing for some, but what really peaked my interest was Boundary, a cloud security framework for access control.

Boundary lets you access any system from anywhere based on user identity. Other providers for cloud infrastructure have started taking similar routes for access control, but unlike most of them Boundary is both cloud-agnostic and open-source. If that and the gruesome onboarding process I described earlier isn't enough to get you excited as well, I'll try and spark the interest by showing what else it's capable of.

Traditional Workflow

To understand why Boundary is good news we should probably take a look at a traditional workflow for securely connecting to applications and critical systems first. A depiction of a typical workflow is shown below

HashiConf2020 Boundary presentation

As you can see from the picture you need a VPN to connect to, which then lands you on a SSH Bastion or jump box. From which you need to SSH through a firewall before you finally get to your target machine.

If you honestly do not feel the complexity of that process should be reason enough to find something better, there are several other challenges(besides the complexity) coupled with this process as well. For one, once you've connected through the VPN, you are inside the network. This greatly increases the attack surface, and as many in InfoSec will tell you, having a small attack surface is one of the best ways to minimize cyberattack threats.

Typically to safeguard against this risk you would have to put up a firewall in front of the target hosts, operating on IP and port identities. A pretty fragile setup in dynamic environments like public clouds where IPs are ephemeral. Not only is it fragile, managing internal firewalls is also quite time consuming.

Another issue is the onboarding and offboarding process in regards to VPNs. I used to be part of the IT team for one of my school's student societies, where some of the student societies' services were only accessible from the internal network at school. Setting up these accesses could be quite a hassle, as you need to figure out the routing, access-lists and so on. The accesses were only issued for a limited term, usually expiring when the students were finished at university. So the offboarding process wasn't too hard. However, it is easily imaginable that in enterprises where access is not time-limited, that people can and probably have forgotten to actually remove the privileges from former employees and contractors.

Finally, the user needs to know the credentials of the end target host that they want to access. If the target is a database, then the user needs to know the username and password to that database. This is also a significant concern from a security point of view, because the credentials are exposed to the user. Meaning that is there's any malware on the home pc the credentials might be lost.

Another problem is also the issue of the user having to memorize all their usernames and passwords. Even if the application backend synchronizes logins, like a database or active directory, each user must login individually to the application. There’s a not-insignificant cognitive load on the user to manage all the different usernames and passwords assigned to them to all the different applications in an enterprise

Boundary Workflow

Now let's take a look at the Boundary workflow. A picture describing it can be seen below.

HashiConf2020 Boundary presentation

Once again the user here needs to access a host or a set of hosts, The user now logs in with a trusted identity such as AWS SSO, Okta, GitHub, or Active Directory. The identity provider would be outside of Boundary, but integrate with it.

This makes the onboarding and offboarding problems risen earlier pretty easy to handle, since it’s now tied to a trusted identity provider. Once a user is no longer part of the company, you can take them out of whatever identity provider you wish and you’re good to go.

The next step is authorizing who gets to do what. This is achieved by using roles and logical services, making authorization robust in dynamic environments and removing the brittleness associated with static IP addresses.

The third step is that the user selects the application he wants to connect to from a catalog of different hosts and services they have been granted access to by Boundary. The user most importantly does not have access to the entire network because Boundary is brokering the connection, minimizing the attack surface in the process.

Finally, the user will have access to the target host. This can be done dynamically by creating short-lived credentials through Vault or assigning access via a security group. Boundary will then proxy the connection right through to the application, never exposing the credentials to the user. As a consequence the risk of losing a password to hostile actors is also gone. Integration with Vault and identity providers is however not yet available in the 0.1 release, but is on the roadmap.

A feature not mentioned in the workflow, but that shouldn't be glossed over is the ability to monitor and manage sessions across many applications. Boundary will allow you to view tokens

In closing...

As much as I've been gushing over Boundary in this post, I wouldn't recommend switching your infrastructure over just yet. Boundary is still in very early development and an official version isn't scheduled until sometime next year. The 0.1 release only supports TCP proxying right now, but higher level protocols like SSH, RDP and HTTP are planned. Boundary currently also has limited integration with other HashiCorp products and public cloud providers.

While this does sound like a buzzkill, Mitchell Hashimoto has a history of dreaming big and then executing on that dream. It because of that ability I would sincerely urge you keep an eye on Boundary while it matures.

And if you in the meanwhile want to try it while it matures(or want to contribute), you can find the github repo at: https://github.com/hashicorp/boundary

With an accompanying guide at: https://learn.hashicorp.com/boundary

Boundary and remote access based on trusted identity

Vipps er blitt allemannseie, men legger stadig til små og store nyvinninger. Som brukere kan vi nå pakke inn pengegaver i virtuelt gavepapir, vi kan betale regninger ved å ta bilde av dem og vi kan til og med få uknotete telefonabonnement fra Vipps.

Hvordan velger Vipps ut hvilke nye idéer de skal satse på?

Mats Knutsen-Valen, Jens Andreas Huseby og Moquan Chen tok en prat med Marit Andreassen, som er Head of Product Engineering i Vipps.

Hvordan velger Vipps hvilken idé som skal lages?

...whereas this article only emits 0.27grams CO2 per page view. But oh this one… 1.56grams CO2 for each view 😬

So what?

Well, I’m not particularly concerned about the environmental impact of these articles specifically. However, the internet consumes about 416.2TWh of electricity every year – that’s more than the entire United Kingdom. And with more people and devices getting connected to the web every day, the energy consumption is rapidly growing.

As digital product designers and developers, we make tiny decisions every day. Decisions that affect the amount of energy required by data centers, networks, and devices to run what we design and build. Some of us are designing websites with hundreds of thousands or even millions of page views every year. Or even more. This means we’re in a position to make a lot of harm if we’re unconscious about the consequences of these everyday decisions. On the other hand, it also means we can have a great impact if we’re doing it the right way!

By reading this article you’ll hopefully get a better understanding and become more conscious about the carbon footprint of websites and digital products. And fear not. It’s not all carbon shaming. I’ll also provide some tips to design and develop more sustainable products and websites. More often than not, these tweaks will also improve your user's experiences.

So what makes these articles so different?

Well, they run on the same technical setup, so I’m pretty sure it’s the content that explains the difference here. But just to be clear. What I refer to as the technical setup is the hosting service, code frameworks/templates, scripts, logos, fonts, and probably some other stuff. This technical rig requires 24 network requests to get access to the necessary (hopefully) information for the page to work and look as intended. This also affects energy consumption and thus the carbon footprint.

Anyway. Let’s look at the difference in content between those articles.

The article, "So you’ve opened Figma, now what?" (the Figma article from now on), Is a short and precise introduction to an awesome Figma tutorial carefully crafted to make you a Figma ninja in no time. Figma itself also has a (probably quite large) carbon footprint. But let’s focus only on the article for this case.

Secondly, the article, "What I Learned About UX Writing From a British Prog Drummer and David Lynch" (the UX writing article from now on), is a very interesting and well-written piece. It demonstrates how words are incredibly powerful and can improve the user experience of whatever you’re designing if used right.

Here is a breakdown of the content and how it affects the web page.

FigmaUX writingWords4412021Images18Network requests25 (24 + 1 image)32 (24 + 8 images)Total page size474 kb2600 kbAvg load time0.26 s (from the UK)1.46 s (from the UK)g CO2 / page view0.271.56Compared to average sites81 % cleaner68 % dirtier

As you can see, there's quite a large difference in both words and images in these articles. From checking the network tab in the browser developer we can see that the images make the main difference between these articles. Actually, one of the images in the UX writing article is 1.2MB and makes up half the total page size of the. I don’t think the author was aware of this image’s size. And I don’t think he’s alone in not being aware of the size of images, videos, and other files that get added to the web.

Plain markup and text hosted on the same server as the rest of the page require minimal amounts of additional energy needed to load the page. Whereas media, custom font files, javascript packages, and scripts that are hosted outside can quickly add up and make your page large and thus require a lot of energy to load slowly to the user.

So what about the consequences?

Imagine these articles getting attention from the UX scene in various scales and parts of the world which brings the following page views and CO2 emissions.

TOTAL KILOGRAMS OF CO2ReachPage viewsFigmaUX writingColleagues 🙋‍♀️🙋‍♂️500.01350.078Norway 🇳🇴10000.271.56Scandinavia 🇳🇴🇩🇰🇸🇪5000013.578Europe 🌍10000027156Global 🌍🌎🌏550000148.5858Compared to average sites81 % cleaner68 % dirtier

If these articles went completely viral across the globe with 550 000 pageviews each it would roughly add up to 1 ton of emitted CO2. One ton of CO2 compares to producing 250 hamburgers or flying one passenger about 4500 km – that’s roughly Oslo - Sardinia roundtrip. Considering these emissions are just for 2 pages below average size and quite few page views compared to other websites, you can see how this quickly adds up.

And by the way. The total time people (if they were in the UK) would wait to access these articles would be 21.9 days. Better make that content worth it!

All right, I get it. I’ll remove all images from our website... 😟

No, that’s not the point. Images, videos, and visualizations can be great to transform complex information into easily digestible content for our users. And without a doubt help to build strong and unique brands.

This quote is from the UX-writing article:\ “What I’m saying is being creative for creativity’s sake is not enough. It has to add meaning or value.”

And guess what, it doesn’t just apply to creativity. It applies to content and media too. What is the best way we can communicate what we want and need the people interacting with our product to deliver a valuable user experience? Cause that’s the ultimate goal, right?

I have added many images and videos to make web pages look beautiful and pretty. For the sake of looking beautiful and pretty (which can be right sometimes). Without blinking. Or considering the file size. If you have done so too, you’re not alone and I don’t blame you.

That’s exactly why I’m writing this – to shed some light on how awareness of these tiny decisions and the things we talk about can make a difference. Both for your product, the people using your product, and the environment.

Soo.. What can we do?

There are a lot of ways to contribute. No one can do everything. But we all have to take responsibility and do our part. As product designers, we often work closely with developers, copywriters, marketers, and decision-makers. This means we are in a great position to spread the message and impact different parts of the product. But we don't have to do all the work ourselves. So here are some tips to get you started on the journey to design more sustainable digital products and websites (and better user experiences):

Speed test and optimize your website

Neither the people using your product or the globe like slow websites. Google’s page speed insights and Pingdom speed test analyzes your site and suggests actions you can take to optimize and make it load faster. Google also satisfies this and will rank your site higher in search results as a reward 🥇

Make sure all content adds value to your users

How much of the internet’s content is outdated? I have no idea, but I bet it’s a fair share. This content also needs to live somewhere, and this somewhere also uses energy. Probably not renewable. So make sure your content is easy to find and add value to your users.

Focus on SEO

It may not seem obvious, but by improving your SEO, users will find what they were looking for quicker, with fewer clicks, which in turn means less time spent on the internet in general. Bonus! You will also get more users to your site and product.

Choose media for communication wisely

Again... Do you need that image or video? Maybe you can deliver the same or even a better and more accessible user experience with clear and concise language, or with an SVG illustration. If you do need an image or video, make sure to scale and optimize it properly before shipping it. I use Imageoptim and the Tinyimage plugin for Figma

Use emails sparingly

Guess what. Emails also have carbon footprints. Ask yourself if your users need that status update email right away. Maybe they can wait and get a summary of status updates tomorrow? Only use email notifications if you have to, and the user will benefit from getting the information immediately. And yes, you should also unsubscribe all those newsletters you never read anyway 🚮

Spread the word and raise awareness

Just talk about it. Tell developers, colleagues, and clients. Yes! Even friends, moms, granddads and everyone else needs should be aware of this. Websites, streaming services, and the internet in general has a real CO2 footprint and requires huge amounts of electricity through transfer networks, data centers, and devices.

Choose a green hosting service

Use a green hosting service when starting a new project. The location of the data centers and their energy sources will have a huge impact on the CO2 emissions from your site/product. You can check what energy source your current hosting service uses on websitecarbon.com and see if you should switch.

By the way, Kristofer Selbekk you don’t have to check. I already did. It doesn’t look good. Since you use every occasion to brag about how much traffic these calendars drive, I think it’s time we do our part and use green hosting for these calendars right away 😉 Hope you’re up for the challenge! In this article, you can learn about how to choose a green hosting provider.

There are sooo many other things you and your team can do. If you’re interested, Wholegrain Digital takes this topic seriously and provides many additional tips for developing greener websites.

Let’s make the world wide web green again 🌱

Some nice (and green) websites and resources for you to check out:

· Y Oslo - Turn on green mode - Shoutout to Netlife for spreading the word!

· Sustainable web manifesto - Sign if you agree

· Wholegrain digital - The creators of Website carbon

· Dot York



Sources:

https://www.custommade.com/blog/carbon-footprint-of-internet/

https://www.websitecarbon.com/

https://www.wholegraindigital.com/blog/website-energy-efficiency/

https://www.datacenterknowledge.com/industry-perspectives/data-center-dilemma-our-data-destroying-environment

Designing for Sustainability by Tim Frick

This article emits 0.28g of CO2 every time it’s viewed...

What if your elm program needs to communicate with the JavaScript enclosing your application? Maybe you need some kind of messages flowing into the elm lifecycle and need to act on such events? To receive messages from JavaScript we can make use of inbound ports🌈

If we are in need of communication with the JavaScript, outside of our elm code inbound ports are designed to do just that.

There are various ways to define the entry to our elm app. We can do this both through an `index.js` file, and an `index.html`. We'll use the `index.html` for this example. Our `index.html` file can be seen below

Between the script html tags is where we will write our JavaScript code and initialise our elm app through initialising our Main.elm file. Also notice the script tags on line 7, this loads our compiled elm code and is required. This enables the possibility to call a `Elm.Main.init()` function in JavaScript, which initialises our application.

We'll start by initialising our application with the `Elm.Main.init()` function inside the script tags in index.html where our JavaScript code resides.

Next we'll finally the code required on the JavaScript side to be able to send messages into our elm lifecycle.

We will now have to write the code that will be receiving whatever JavaScript wants to tell us, inside our elm program. Part of initialising our elm program inside Main.elm is telling it where it will find the view, update, the init function and so on. Here you will also find where you supply the subscriptions function, which describes to elm which ports exists.

We define our port, helloFromJS, and our subscriptions. Next step is to tap into the elm lifecycle. You can see that we started a little bit already, by telling the subscription function that it should send the HelloFromJSMsg when it receives a message from the helloFromJS port. Every time JavaScript sends a message to elm, the port helloFromJS will receive it, and the update function will be called with the HelloFromJS message.

From here we will be able to add it to our Model, or proceed to perform a side effect (Cmd Msg), or anything else we might would want to do with the information received from JavaScript.

Inbound ports

Documenting stuff is important, folks! Where would Santa be without his naughty and nice list? Let's spend a few minutes learning how you can improve the user experience of your components by adding a slash and a couple of stars in front of it!

If writing good code is hard, understanding somebody else's code, and how to use it, is often bordering on impossible. Even your own code a few weeks down the road is often a weird blend of naming conventions and different ways to do the same thing.

It's not really the developer's fault either - there's a lot of research, thinking and just general context that was present when the code was written, that just isn't available anymore when you write that git commit command and move on.

That's why it's imperative that we document the code that we write. We need to include some of that context into our code somehow, while not
clobbering our code with verbosity that'll just be made obsolete by the next commit anyhow.

Another thing about documentation, is that it needs to be readily available when you need it. Nothing will ruin your flow state like trying to google some obscure component name to figure out how it's used.

Luckily, there's a solution that makes all of this possible, and it's built into your favorite editors: JSDoc.

Before we dive into why JSDoc is the bees knees though, let's look at how a component documented with JSDoc looks like when it's used:

Looks sweet, right? Here's another example of the same with component props:

Getting documentation to show up like this is incredibly useful. You can provide all the context in the world, and it will only show up when it's useful.

My favorite example from "the wild" is Firebase's JavaScript SDK - they have tons of useful documentation that show up right in the editor!

How to JSDoc

So how do you make this magic text to show up whenever people use your code? It's as easy as /**/.

Let's start with an example React component:

To document this fancy component (or any function, really), start a block comment with two consecutive stars, and start writing:

If you ever use your MessageBox component, that text will show up right when you need it - that is, when you're using it.

Note that this block has full support for markdown, so you can add formatting like code highlighting, links, tables, text formatting and even images if you want.

Next, let's document those props! It uses the same slash and double star syntax, and supports the same Markdown:

I'm a huge fan of using TypeScript, so the following example uses that - but you can use the same technique on propTypes if that's your preference.

And like that, you have incredibly useful component documentation embedded in your codebase. If you ever need to update a prop, the documentation is co-located, so it'll be easier to remember to update the documentation as well. If you delete a component, the documentation is deleted with it.

Fancy tags

If you want to be all fancy about your JSDoc, there are some special tags you can use to provide even more meaning to your code:

If you want to stop people from using a particular prop, component or function, you can mark it as @deprecated. In VS Code, any usages will receive ~strikethrough~ text styling, and it will show up on hover as well.

Another great tip is to provide examples of usages. You can do that with the @example tag!

You can even give it a heading with the <caption> tag:

There are tons of other tags as well, but this will (in combination with the Markdown support) definitely make your code more readable

Go document

Santa has a pretty cool gig. Once he gets going, he doesn't stop to google who gets presents, and who gets lumps of coal. He just glances over at his naughty or nice list, and instantly knows what to do. He did the work before the work began, and if he gets sick, Mrs Clause can fill his shoes without asking Santa for a ton of context first.

Be like Santa. Write your list and use JSDoc to do it. Thanks for reading 🎅

/** Make the nice list with JSDoc */

We discussed elliptic curves earlier this month. Today, we look at how to use those to make the internet a bit more user friendly.

Privacy Pass was introduced in 2018 by Alex Davidson, Ian Goldberg, Nick Sullivan, George Tankersley, and Filippo Valsorda in order to reduce the number of CAPTCHA challenges human users would meet online. The basic idea is to allow the user to submit a number of tokens to a server ahead of time. The server will sign these, equivalent to issuing notes with the text "The holder of this token should be considered human, not a bot.". Every time the user visits a website that would have asked for a CAPTCHA, the browser can hand over one of the tokens instead, hence not bothering the user with reading garbled letters or clicking on images of road signs.

To avoid token replication and reuse by bots, one can assign these tokens serial numbers; however, these serial numbers could violate privacy by tracking users across the internet. The authors of Privacy Pass have an elegant solution to this.

By using the Privacy Pass browser extension users can be both authenticated and remain anonymous. Usability is also improved when existing CAPTCHA solutions can be replaced, as the user is already authenticated and doesn't need another verification challenge.

How it works

The Privacy Pass protocol works the following way:

First, the server side generates an elliptic curve E with a distinguished point G, secret key k and a public key K = kG.

The browser chooses a random number t, and generates a point T on the curve from t using a hash function. It then creates a masked point P = rT, which it submits to the token issuer.

The token issuer signs the token by computing a new point Q = kP. It also provides a Chaum-Pedersen zero-knowledge proof to prove that it was indeed k what was used to sign P, but without revealing k.

The original point T is now masked by both r and k. The browser can remove r, so that it is left with the token W = kT.

In order to redeem the token, the browser can submit (t, W) to the website the user wants to visit. The website generates T from t, computes kT, and verifies that it equals W. The seed t is stored in order to prevent the token being used twice.

Image courtesy of Cloudflare, Inc. (1.)

Security of Privacy Pass

We give some intuition-based arguments for why this protocol achieves its goals:

In order to manufacture tokens that could be used more than once, the browser would need to generate values t, t' such that they both generated the point T. Hence, the hash function needs to be collision resistant and second preimage resistant. The SHA2 family of hash functions is believed to satisfy these requirements.

Since r is chosen uniformly at random, the point P = rT carries no meaningful information. Likewise, if the discrete log problem is hard on the chosen elliptic curve, then it is infeasible to extract the secret key k from the point kT. The Chaum-Pedersen proof guarantees that Q is well-formed. The browser is therefore none the wiser regarding generating tokens.

Since the points P and Q are masked with r, and W is independent of these points, the issuing service and the verification service will not be able to trace when a specific token was used, and so the anonymity of the user is guaranteed

Content delivery networks such as Cloudflare or Akamai may record misbehaving IP-addresses to mitigate attacks. However, if you use anonymity tools such as onion routing, your visible IP address may be shared with less honest users, which will in turn make you have to go through the hassle of responding to frequent CAPTCHA requests. Privacy Pass enables you to avoid those without compromising your anonymity.

Tomorrow, we will look at a seemingly different way of using the exact same cryptography, which may also benefit you in 2021.

(1.) "The orange cloud logo is a registered trademark of Cloudflare, Inc. This blog post is not sponsored by or affiliated with Cloudflare, Inc."

Privacy Pass: Anonymous Tokens on the Web

Functional interfaces was introduced in Kotlin 1.4 and is a way of giving lambdas proper types which can make our code more readable and make the intent clearer.

Let's start with a simple lambda. A lambda can typically be written as follows:

If you need a refresher on lambdas check out last year's post about lambdas. To make our code easier to understand we can replace the lambda type signatures with a typealias:

Typealiases are just syntactic sugar that will be rewritten to the underlying type at compilation, this means that the typealias Uppercase will be replaced with (String) ->String when we compile. The issue with using typealiases is that it doesn’t ensure we pass a function with the corresponding typealias, we can pass any function that matches the signature of the typealias. Typealiases still work wonders to make complex types easier to read, but we get no guarantee that the function we pass actually uses the type alias.

As we see in the example sending both functions are valid, even though only one uses the typealias. My suggestion is to be careful when using typealiases and make them private so the false abstraction doesn’t leak into our codebase. Now for functional interfaces. A functional interface, or a single abstract method (SAM), is an interface with a single abstract method. It can have multiple methods but only a single abstract one. Let's start with an example of a functional interface where we want to add a suffix to a string.

Here we define an interface for our function and we can create a function based on that interface. The syntax for creating a function when using functional interfaces is Interface { body }, and in our case we use the Suffix interface to create a function body that returns an exclaimed string. Now we actually have a type for our function meaning that we can use that to restrict what another function will accept as a parameter.

One thing we can see from the example is that we need to invoke the function we defined in our interface, e.g suffixFn.excliam. A neat trick to get around this is to use the invoke operator.

Now we can simply call the prefixFn without an additional namespace.

As with regular lambdas we can also return functions from functional interfaces. This might help us break down complex function signatures to more manageable types.

In simple cases using the type signature is good enough and we can get away without using typealiases or function interfaces. When our types get more complex we probably want to introduce something to help us with that, and functional interfaces is the way to go. They give us proper type safety that we won’t get with typealiases!

Functional Interfaces

You probably came here to read about something cutting edge in JavaScript, but today we’re going to do a deep dive into one of the fundamental operators of JavaScript, new.

I struggled with how the new operator fit into JavaScript when I first started out many years ago. Coming from object-oriented languages such as Java, it was strange to be able to use objects (and functions for that matter) before they were somehow instantiated (with new - although this is not really the case). Objects, in the object-oriented way, made a bit more sense to me when classes were introduced in ES5. Classes are really just syntactic sugar for creating objects in JavaScript, but unlike objects, classes will throw a TypeError if you attempt to use them without calling new. So today let's do a deep dive into how the new operator really works and try to demystify some of it's secrets.

Objects

Objects in JavaScript are just key/value pairs, which make up the properties of the objects. Values can be primitive, array, functions or any other object. Functions are called "methods" when they are used in objects. The easiest, and most common way to create an object in JavaScript is by using the literal notation known as "object initializer".

Under the hood, the equivalent of using the literal notation is creating a new object and setting properties on that object. So even though you’ve never really explicitly created objects with new, it’s been done for you.

Functions

So what about functions? What happens when you don’t use the new operator on functions? Functions in JavaScript are also objects, they are instances of the Function object.

Unlike the constructor of Object (new Object), calling the constructor of Function (new Function), is not the same as using function declarations (function () {}). You can read more to get a deeper understanding of the differences at MDN.

A function is defined in MDN as "a set of statements that performs a task or calculates a value", also called a procedure. Furthermore to qualify as a function, the procedure should return an output which has some relationship to the input of the function.

Unless a function has an explicit return, a default value is returned from the function. And here is where the new operator comes into play. The default return value of a function is undefined if the function is not a constructor function. A function is a constructor if it is called with the new operator. For a constructor function the default value is this. So for functions that are not called with the new operator. The statements of the function are executed and the explicit return value or undefined is returned. By using the new operator the function will return a newly created object which is bound to this.

It is important to note that this does not apply to arrow functions (const fun = () => {}). Arrow functions cannot be used as a constructor function and will yiled a TypeError when used in conjunction with new. One of the reasons is how arrow functions handle this, which will be bound to the scope where the arrow function is used. Therefore we cannot create new instances of arrow functions since the new operator will bind this of the function to the instance. You can read more about arrow functions and this at MDN.

Prototypes

The last thing we need to discuss are prototypes. JavaScript inheritance works by prototype chaining. I’m not going to reiterate all the properties of how prototypes and prototype chaining works. You can read more about it over at MDN.

In broad strokes an objects in JavaScript (almost) always inherits from the Object.prototype. Objects created with "object initializer" or new Object is no exception. Neither are objects created using constructor functions. But unlike "object initializer" and new Object, the constructor functions links the prototype of the returned object to the constructor as it’s parent prototype. The created object still inherits from the Object.prototype, but not as it’s parent prototype.

Back to our example of the Person constructor function, objects created with this function will first inherit from Person.prototype, then Object.prototype (and lastly null). When invoking a property on the object, JavaScript will walk this path to find the property. If it was not defined on the Person object, it would look at Object, and so on. This makes it easier for us to extend Person objects with new methods, which will apply to all instances of Person.

Summary

I hope this gives you a better understanding of how the new operator works, in a nutshell. We have only scratched the surface of "the secret life of Objects" in JavaScript. And if you want to know more, I recommend you dive deeper into the documentation on MDN, read Eloquent JavaScript, or YDKJS series. To summarize, as documented on MDN, the new-operator:



Creates a blank, plain JavaScript object;

Links (sets the constructor of) the newly created object to another object by setting the other object as its parent prototype;

Passes the newly created object from Step 1 as the this context;

Returns this if the function doesn't return an object.

The new Operator

Det er 2009. Du jobber som markedsdirektør i den amerikanske dagligvaregiganten Walmart, og er særs godt fornøyd. Det strategiske prosjektet ditt har endelig blitt realisert. Butikkene har aldri sett bedre ut. De rotete pallene med billige varer midt i butikken har blitt erstattet med oversiktlige hyller som bugner av tiltalende produkter. KTI-tallene har skutt i været, kundene har aldri vært mer fornøyde.

Nå gjenstår det bare å legge den siste biten i puslespillet. Beviset på at konkurrentene er knust en gang for alle. Du finner frem den finansielle rapporten du har mottatt og gleder deg til å se resultatene. I det du begynner å bla i dokumentet merker du hvordan smilet gradvis stivner. Tallene er blodrøde. Markedsandelen har ikke falt så mye på over 30 år.

Customer is king! Eller?

Kundesentrert strategi er i vinden som aldri før. Moderne strategiutvikling tar ofte utgangspunkt i en grundig forståelse av kundens behov og atferd. Og strategiprosessen skal aller helst være smidig, med hyppig involvering av kunden underveis. Som et resultat av dette har tankesett og verktøy fra tjenesteinnovasjon, tjenestedesign og digital produktutvikling gradvis smeltet sammen med strategifaget, noe vi i Bekk også har jobbet mye med de siste årene.

Med dette som bakteppe er det vanlig, og kanskje også intuitivt, å anta at høyere kundetilfredshet og bedre kundeopplevelse er bra for business. Dette underbygges av at toppledelsen ofte har kundelojalitet og kundeopplevelse høyt oppe på sin prioriteringsliste. I en amerikansk undersøkelse fra 2014 oppga 70 prosent av markedsdirektørene at kundelojalitet var en topp tre strategisk prioritering, mens hele 93 prosent hadde det på sin topp fem-liste.

Som et resultat av dette bruker selskaper milliarder av kroner hvert eneste år på å forbedre opplevelsen for sine kunder. Det er også vanlig å bruke aggregerte målinger av kundetilfredshet (KTI) og Net Presenter Score (NPS) til å evaluere hvordan det står til med forretningen. For når kundene våre totalt sett blir mer fornøyde tjener vi mer penger, ikke sant?

Nei, det er faktisk ikke slik. I boka «The Wallet Allocation Rule» fra 2015 presenterer forfatterne en omfattende studie som viser at kundeopplevelse i seg selv ikke har noe positiv påvirkning på lønnsomheten. I mange tilfeller kan effekten til og med være negativ. For å forklare hvordan det kan ha seg må vi først ta ett skritt tilbake og se litt på hva lønnsomhet egentlig handler om.

Hva driver et selskaps lønnsomhet?

Kommersielle selskaper er vanligvis besatt av å oppnå to ting, nemlig profitt og vekst. Over tid er det imidlertid vekst som regnes å være den viktigste indikatoren på et selskaps finansielle suksess. Det er tross alt vekst som skaper økonomisk verdi for aksjonærene og som legger grunnlaget for den langsiktige verdien av selskapet.

Vekst kan måles på en rekke ulike måter, avhengig av hvilket selskap og marked man befinner seg i. For selskaper som befinner seg i et modent marked, med et relativt oversiktlig konkurrentlandskap, handler dette som oftest om å øke selskapets markedsandel. Markedsandelen defineres da typisk som Selskapets salgsinntekter/ Totalt salg i markedet. En økning i markedsandel krever dermed at selskapet tilegner seg en større andel av markedets totale omsetning. Et klassisk eksempel er hvordan de ulike dagligvarekjedene hver dag kjemper om kundenes matbudsjett. Handler du middagen din på Rema 1000, Kiwi eller Coop i dag? Eller blir det Jacobs siden det snart er jul?

Det virker derfor rimelig å bruke markedsandel som en indikator på vekst og langsiktig lønnsomhet. Med dette som utgangspunkt kan vi se nærmere på forholdet til kundeopplevelse.

Markedsandel og kundeopplevelse er negativt korrelert

I et marked som består av kunder med ulike behov og preferanser må et selskap posisjonere seg med én hovedmålgruppe i tankene. En aktør i dagligvaremarkedet må for eksempel bestemme om det primært er lavprissegmentet de skal rette seg mot eller om de i stedet skal tilby varer med høyere kvalitet og pris.

Selskaper med stor markedsandel (typisk massemarked) må per definisjon nå ut til flere kunder i markedet, og dermed forsøke å tilfredsstille et bredere utvalg av behov og preferanser. Dette betyr igjen at de betjener flere kunder som ikke er innenfor selskapets hovedmålgruppe. Selskaper med mindre markedsandel, såkalte nisjeaktører, kan imidlertid konsentrere seg om behov og preferanser i sin hovedmålgruppe, som illustrert i figuren under (Kilde: The wallet allocation rule: Winning the battle for share, T. Keiningham et al, 2015):

Dersom selskapene med høy markedsandel i mindre grad tilfredsstiller enkelte kunders behov og preferanser innebærer det at den totale kundeopplevelsen blir dårligere. Nisjeselskapene, med relativt liten markedsandel, vil imidlertid kunne levere en veldig god kundeopplevelse til nesten alle sine kunder. Fra dette kan man trekke slutningen at markedsandeler og kundetilfredshet ser ut til å være negativt korrelert. Det vil si at en økning av kundeopplevelsen faktisk vil medføre at markedsandelen går ned - og motsatt.

Og er ikke det egentlig ganske logisk når du tenker deg om? Du er sikkert glad i den nisjebutikken på hjørnet der du bor, mens de store butikkjedene på kjøpesenteret ikke akkurat får blodet ditt til å bruse. Men gjett hvem av dem som tjener mest penger?

Så er spørsmålet hvordan det likevel kan ha seg at mange studier viser en signifikant positiv sammenheng mellom tilfredshet og kjøpsatferd. Dette skyldes helt enkelt at de fleste studier benytter kundemålinger som er analysert og tolket på aggregert nivå, og som ignorerer det faktum at kundene varierer mye i preferanser, atferdsmønster og lønnsomhet. Ved å benytte gjennomsnittlig kundeopplevelse som utgangspunkt for tolkning vil ytterpunktene i tillegg kansellere hverandre ut og gi inntrykk av at tallene er mer korrellert enn de faktisk er. Vi må altså slutte å behandle alle kundene våre som om de skulle vært helt like.

Med nyvunnet kunnskap om at kundeopplevelse ikke driver vekst, og at bruk av aggregerte data ofte kan gi inntrykk av det motsatte, blir dermed spørsmålet: Hvordan bør du heller gå frem for å sikre lønnsom vekst fra dine kunder?

Tiltak 1: Segmenter kundene dine basert på lønnsomhetspotensial

Første løsning på problemet handler om hvordan kundene segmenteres. Som vi var innom i forrige avsnitt må vi slutte å behandle kundene våre som om de skulle vært helt like. Kundetilfredshet og NPS gjør imidlertid en dårlig jobb med å forklare vekst og lønnsomhet, og er derfor lite egnet som segmenteringsvariabel. Vi trenger derfor en annen måte å segmentere kunder på.

Svaret er egentlig ganske logisk: Du må basere segmenteringen på en forståelse av hvor pengene dine kommer fra. Eller enda bedre: Hvor pengene kan komme fra i fremtiden.

En tommelfingerregel, illustrert av den såkalte Stobachoff-kurven nedenfor, sier at 20% av kundene din bidrar til at du tjener penger, 60% av kundene går i null og 20% bidrar til å redusere lønnsomheten din. Sagt på en annen måte er det bare en femtedel av kundene dine som bidrar til overskuddet ditt, mens en annen femtedel faktisk reduserer det.

En slik oversikt er sentral for å forstå lønnsomheten av kundebasen din, og bør være utgangspunktet for segmentering av kundene. Men det betyr ikke nødvendigvis at ulønnsomme kunder er uinteressante. For hva om noen av disse kundene som er lite lønnsom i dag har det største økonomiske potensialet for fremtiden?

Konklusjon: Kunder har ulikt lønnsomhet og bør segmenteres deretter. Økt lønnsomhet oppnås ved å målrette forbedringer og tiltak mot kunder med det største økonomiske potensialet.

Tiltak 2: Forstå hva som faktisk driver markedsandelen og bruk ressursene dine deretter

Tidligere i teksten besluttet vi å bruke markedsandel som en proxy på vekst, og definerte det som Selskapets salgsinntekter/ Totalt salg i markedet. Men denne definisjonen sier lite om hva man kan gjøre for å påvirke markedsandelen eller hva som faktisk driver den. Det er derfor mer interessant å bryte opp markedsandel ved hjelp av følgende formel:

Markedsandel = Penetrasjonsrate × Forbruksindeks × Share of wallet

Penetrasjonsraten er andelen kunder i markedet som har kjøpt ditt produkt minst én gang i en gitt tidsperiode, og som dermed kan regnes som en del av din eksisterende kundebase. Penetrasjonsraten øker du ved å skaffe deg nye kunder.

Forbruksindeksen handler om hvor stort forbruk kundene har av produkt ditt sammenlignet med det gjennomsnittlige forbruket i markedet. En økning av forbruksindeksen krever gjerne en endring i hvordan produktet er utformet eller hvordan det konsumeres. Et klassisk eksempel er vaskemidler som blir puttet i flasker med større åpning for at kunden skal bruke mer vaskemiddel hver gang de gjør rent.

Share of wallet betegner den andelen av en kundens forbruk i en gitt produktkategori som tilfaller deg. Altså hvor stor andel av kundens «produktlommebok» som brukes på dine produkter. Share of wallet økes ved å få kundene til å bruke flere penger hos deg som de i dag bruker hos dine konkurrenter.

Av disse tre er det den sistnevnte som er den klart enkleste og mest kostnadseffektive driveren å påvirke. Det er også den av de tre komponentene som henger mest sammen med kundeopplevelse. Det virker derfor logisk å rette innsatsen for økt markedsandel inn mot hvordan vi kan øke kundens share of wallet.

Som svar på dette kommer overnevnte bok med en formel som forsøker å forklare hva som påvirker share of wallet, og kaller den The Wallet Allocation Rule:

Det er mye som kan sies om denne formelen og bakgrunnen for at den er bygget opp som den er. Denne kalenderposten er imidlertid lang nok som den er allerede. Det som imidlertid er verdt å merke seg er at det er kundenes relative vurdering av kundeopplevelsen hos ulike selskaper som betyr noe, og ikke kundeopplevelsen hos ditt selskap isolert sett. Måling av kundeopplevelse kan dermed fortsatt være relevant, men du må også forstå hvordan kunden vurderer opplevelsen av dine konkurrenter.

Kombinerer vi denne formelen med kundesegmentering basert på økonomisk potensial begynner vi se konturene av hvordan vi kan jobbe aktivt med å skape vekst: (1) Identifiser først kundesegmentet/ -segmentene med størst økonomisk potensial (2) Bruk Wallet Allocation Rule til å finne ut hvordan disse kundene rangerer deg opp mot dine konkurrenter. Det er årsaken bak denne rangeringen som bør være utgangspunktet for forbedringsarbeid og innovasjon.

Gjort riktig vil dette kunne medføre økt share of wallet fra kundene, økt markedsandel og til syvende og sist fremtidig lønnsomhet for ditt selskap. Så enkelt og så vanskelig.

Historien om Walmart og «Project impact»

Tilbake i 2009 hadde den amerikanske dagligvaregiganten Walmart kommet seg gjennom finanskrisen med mye bedre økonomiske resultater enn sine konkurrenter. Flere av konkurrentene kunne imidlertid vise til bedre resultater på kundetilfredshetsmålinger, noe ledelsen i Walmart bestemte seg for å gjøre noe med.

På bakgrunn av dette satte konsernledelsen i gang «Project impact» som hadde som mål å øke tilfredsheten blant selskapets kunder. Nye hyller ble satt opp, mindre rotete butikker ble designet og en bedre kjøpsopplevelse ble skapt. Dette førte til at KTI-resultatene skjøt i taket. Samtidig endte selskapet opp med å miste dramatisk store markedsandeler, som vist i grafen under (Kilde: The wallet allocation rule: Winning the battle for share, T. Keiningham et al, 2015):

Så hva var det egentlig som skjedde? Walmart gjennomførte sine forbedringstiltak uten en tydelig forståelse for hvor inntektene deres kom fra. Selv om mange kunder ble mer fornøyde hadde ikke disse kundene nødvendigvis mer penger å bruke i butikkene. Andre kunder så ikke lenger poenget med å dra på Walmart når de billige varene og tilbudstorgene ikke lenger var der. Da kunne de vel likså greit bruke pengene et annet sted?

Project Impact viser faren ved å fokusere på å forbedre kundeopplevelsen uten en klar kobling til kundens forbruk og kjøpsmønster. CEO i Walmart William S. Simon, oppsummerte dette på en fin måte:

“They loved the experience. They just bought less. And that generally is not a good long-term strategy.”

Lyst på mer informasjon? Du kan lese mer om dette temaet i denne HBR-artikkelen eller i boka som denne artikkelen er basert på.

Kan gode kundeopplevelser true lønnsomheten din?

In this previous post I wrote about how I came across a few visualization techniques to manage my own fear. Today I am going to share the next one. I call it The Charlie Chaplin movie.

The Charlie Chaplin movie 🎞️

I am always most nervous in the beginning of a talk. This technique is all about disrupting that pattern and create some new emotions to relate to during the start.

Close your eyes and try this one out.

Watch the movie

Watch a movie where you are the main character.

In this movie picture yourself standing up, walk up on stage and start your presentation. Feel the anxiety in the beginning.

Watch yourself finish the presentation in the movie, soak in the applause and hold on to that feeling of relief.

In that moment, freeze the picture of you on stage.

Tamper with the movie

Remove the colours and make that picture black and white.

Remove the sound :mute:

Then rewind :rewind: the movie quickly back to the start of the presentation, when you felt really nervous.

Fast forward :fast_forward: from the start to the end. Then play it backwards again, really fast. Do this back and forth a couple of times.

Add some funny music to this black and white movie. Something comedic, carnival-like. Keep playing it quickly forward and backward several times. I always envision something like a Charlie Chaplin movie.

Notice how the picture of anxiety and the picture of relief now are so close to each other, like two scenes in a movie appearing sequentially.

The effect

Experiencing the two opposite feelings side by side felt comforting and in a way safe for me. Two opposite emotions, but somehow also so close. You can feel uncomfortable in one moment, but this can all change in the next one.

The black and white movie with the fast pace and the quirky music really made me smile. Picturing myself in a Charlie Chaplin movie, walking awkwardly up and down numerous times to give a presentation — how hilarious! This made me not take this all too seriously.

All this helps me disrupt the anxiety I feel in the beginning. I am still nervous, but I also remember that I have seen this movie before, and I know the ending very well. It is a happy one!

21-Dec

Today's posts