I am a big fan of F# It is very enjoyable to code in and I really like its domain modelling capabilities. You can use it for fullstack development and easily share code between the front and back end. Lets take a look at Fable remoting, a really interesting way of doing this.

This is how Fable remoting is described on its github page.

[...] it abstracts away Http and Json and lets you think of your client-server interactions only in terms of pure stateless functions that are statically checked at compile-time

Basicly what this means is that you don´t have to deal with HTTP calls, serializing or deserializing models, you just have to deal with functions.

I will assume some familiarity with F# and model-view-update (the Elm architecture). I will, however, add some great F# resources at the bottom of this article.

We will scaffold the project with SAFE-Stack. This will give us a fullstack project that has a nice and simple todo list set up with fable remoting, this todo list is what we will be editing.

Our project has an assortment of files. One of them shared.fs is where the code shared between client and server lives. Lets take a look at it.

The very first thing in this file is the record defining our todo type.

Nice and simple! We also have a module that lets us validate and create our todos.

Then there's the following, which is used to create the routes that Fable remoting will be using to perform requests for us.

And finally the interface defining our API.

As you can see the todo list supports two operations already.

getTodos which takes no arguments and returns a list of todos.

addTodo which takes a todo as input and returns the newly created todo.

Now lets take a look at how the frontend uses this.

Frontend

In Index.fs we have a todo API:

This creates the API so it is ready for the client to use. We can see the first example of how to use it in the init function.

This sets up the MVU model and asks the backend for all the todos. Once this async function is resolved the GotTodos command is executed. GotTodos is what stores the todos we get from the server in our model.

Performing requests with Fable remoting is that easy! No strings, no serialization, no deserialization, none of that boring stuff! It's just a function call and it is all type safe!

Time to look at the backend.

Backend

The server needs to implement the API-interface defined in the shared file. And we can find that implementation in Server.fs

In this is an implementation of the interface functions are declared within the type, but they could just as well be separate as long as they match the interface.

So before we head on lets do a quick recap:

We saw the model defining our todos.

There is a function that creates and handles the routes for us

We explored the interface defining what functions we can use to interact with the server

Saw the interface implementation on the server

Cool! Now that we are all caught up lets start editing this API and expanding it a little bit. Here we go... Lets delete a todo!

Deletion time

Lets start by adding a function definition to the interface in Shared.fs.

Our interface now supports deletion! All the functions we define in this interface have to return an async and we want to know if the delete succeeded. So we return the guid of the deleted todo item if it succeeds.

In order to make the backend delete todos we need to edit the storage class SAFE Stack provided for us. So we add this function right here. For more context on this class feel free to checkout the code on github.

Here we try to find a todo with the same GUID as we passed in. If we find one we try to remove it from our list. If it is removed wrap the Id into an Ok type and return. Otherwise we return an Error.

The only thing missing from having a finished API is implementing the delete function itself. All it has to do is call the call the delete method on the storage class. In reality this could be editing a database or whatever else you fancy.

Now we need to reflect these changes in the frontend. We need some new commands so we can call our function and delete a todo from the list. In Index.fs we change the Msg type

We now have 2 new commands to implement in the update function. They look like this.

Again we use the endpoint with the same pattern. We call the function, and when it resolves, perform a command.

Finally we need to have some way of actually calling this function and deleting todos from the view.

In the containerBox function we list each todo and we want to add a button there. Lets also add some inline styling (⚠️ viewer discretion is advised ).

And that's it. Here we have it. We added a delete route for our todos.

Heres a quick demo!

It is important to keep in mind that under the hood this is just normal HTTP requests going backwards and forwards. That means you can still test them using Postman and similar tools.

Finally another pretty cool thing we can do is document our api and get a nice overview of it - kind of like swagger. The following is a really simple documentation that can be accessed at localhost:8085/api/todos/docs

And thats it!

Let do a quick recap of what we did:

Scaffolded a project with SAFE stack. This gave us a project with a client and server.

We added a function definition to the API interface.

Added an implementation of said interface on our backend.

Added a button that called our new function on the frontend.

At no point did we create any extra create or write models, we just used the one domain model we defined.

While being a simple example of using Fable remoting. I think it is clear to see how you can communicate between client and server without having to worry about serialization, deserialization, misspelling your path name - or anything like that! It is simply defining and implementing a common interface and calling those functions, oh and did I mention that its all type safe? You can just focus on your domain models and doman logic. I find it really neat! Hopefully you found it interesting too!

If you did you can:

Check the source code for this github

If you want to read more about Fable Remoting you can check out its github.

The author of Fable Remoting has also written an excellent and free book about Elmish, If you want to learn more I suggest you go take a look!

Fable Remoting

Cloud environments quickly grow in size. There’s tons of services and we start utilizing SaaS solutions for different problems. Solving problems through infrastructure and SaaS is after all one of the main reasons we're in the cloud in the first place.

The problem

But everything that glitters isn't gold. With a lower bar for creating new resources we can easily end up with clutter. There are also limitations when using SaaS-solutions. The built-in functionality doesn’t fully cover our needs, so we add on to it, to work as needed. Storage is created to test different stuff, but developers forget to delete it afterwards. Maybe resources aren’t tagged correctly.

Personally we ended up writing a bunch of small scripts and cloud functions that was scattered all around. Maintaining it turned into a pain for various reasons. Sometimes it was hard figuring out if something similar was already running. Other times services was forgotten. The point being, keeping control of everything wasn't always easy.

Enter the janitor concept!

To group these tasks, we’re structuring them under the “janitor” concept.

There is, after all, always some general maintenance that needs doing. Tasks like sweeping, making sure the message board is updated, or shutting off the lights can easily be transferred to deleting unused logs, setting the correct tags for resources or scaling down services at night.

To try and make this fluffy subject a bit more tangible let’s look at some examples we use today in our AWS cloud.


The container registry janitor

We have a centralized container registry where we keep all our images. However we really don’t need to keep every build saved for eternity. We also want to make sure all images are accessible to all our accounts. This is mostly done at publication of a new image, but checking this routinely as well handles images pushed from non-standard sources.

Schedule: Once a day

Tasks:

Loop through the image repository and:

Delete any untagged images

Delete pre-release images older than X days (we’ve got a limit of 60 at the moment), but not our releases as we want to preserve these.

Make sure the images are accessible to other cloud accounts if wanted

The log cleaning janitor

While log retention is easy to set in most systems, there’s always the oddball out. It's can be beneficial to collect the log cleaning in one place. Removing unused logs reduces unnecessary cost as well.

Schedule: Daily or hourly, depending on needs Tasks:

Set retention rate on logs where it isn’t set.

Delete old logs!

The Pod janitor

We run a couple of janitors in our kubernetes cluster. One of these is the pod janitor. Today it’s running with a couple of tasks. Schedule: every 10 minutes Tasks:

Normalize and make sure the memory and cpu limits for our Docker containers follow the standard.

Look for a max_age tag on the pod. If the age of the pod exceeds this, delete it, given that all other replicas of the app are running and healthy.

Cluster Janitor

In an environment with multiple kubernetes clusters that morphs and changes a custodian can help keep things in order. One thing we’ve experienced is that setting “tags” on our resources is a great help. Tags are generally easy to access for interested parties, so we use these to describe different resources.

Schedule: frequently

Tasks:

Based on the load balancer version, set “tags” (annotations), that’s read by our deploy-scripts to know which type of ingress objects should be created.

Set tags on namespaces based on naming rules. These are used by deploy-scripts to determine which cluster to deploy to in a multi-cluster environment.

How to get started

Well, for us we ended up just creating a set of small FaaS python functions we run on a cron job schedule, since that was the easiest way to get going with our existing system. There is however a bunch of systems out there like the cloud custodian.

👋

Janitors are not a revolutionary change to how we work with cloud resources. However, if you’ve found ourselves in a situation where it’s getting harder to figure out how to organize your utility scripts, or maybe have a hard time getting started on creating them, I hope this has given you a small framework to work with!

Cloud Janitors

Even today, many people shy away from JavaScript because it is seen as unreliable or unpredictable. Without strong typing and compiling, unexpected problems can arise at runtime that nobody will see until it gets uncovered as an error in a production environment.

A transitional language

When I started a career in web development in 2011, JavaScript was in its comeback phase. There were still people who disabled JS in their browsers. When we wanted to do dynamic frontend work we relied upon frameworks like Razor as much as we could and did the lion's share of processing serverside. After all, people's home computers are slow and we should use our servers' processing power where possible, right?

A few years down the line, JavaScript started getting more traction. We had seen that you could do some neat things with it, and when you used jQuery it didn't seem so complicated. Whole frontend frameworks like Knockout, Backbone and Angular were becoming popular, but was shifting to processing in the front end a good idea? After all, JavaScript is still the wild west. Anything goes. A variable can be a bool one second, a string the next, then an integer (or, just a number, we don't even discriminate).

What can be done?

A cowboy language such as this surely cannot be used by an enterprise that prides itself on writing Clean Code™. After all, allowing something like this to run:

is crazy.

But what if we made JavaScript type-safe, and had a real compiler that would check?

It already exists:

TypeScript (typed JavaScript, get it?)

To revisit our absurd code sample from above, TypeScript would see it written something like this:

As you can see, now we can specify not only the type of our parameter, but also of our return value. Subsequently, calling our function like this:

will not work, and our compiler complains. In a decent IDE, you'd know this call won't work before you even try to run a compiler. It might even offer constructive criticism.

In addition to primitive types, Typescript also supports custom types and interfaces, enums, arrays and tuples.

Automatic Type Generation

But I have large chunks of json coming from API endpoints that I have written in C#, do I have to create typed interfaces for these objects on my frontend now? That seems like a huge waste of time.

Nope. Because we have NSwag.

In really short strokes, NSwag is a tool that runs when you compile your backend API code. It does two things: it creates an API documentation page for your API (like OpenAPI/Swagger) and it does all your automatic client generation (like AutoRest). In practice, what this means is that when you've written an API endpoint and the corresponding RequestModel and ResponseModel, NSwag produces interfaces and client code for you. Your OrganisationController is used to make an OrganisationClient, and your TypeScript frontend is all ready to consume the endpoint with no code written.

What if I change my endpoint, or add or remove properties to my models serverside?

NSwag does the corresponding changes on your frontend. And should any of the code you've already written now be wrong, the TS compiler will let you know. This has the potential to save a lot of time.

This article is really broad strokes, but hopefully it might make a type-purist give JavaScript another look.

Clean Code™ in JavaScript with TypeScript and Automatic Type Generation

Consider the following snippet of code:

The statements are four different ways of obtaining exactly the same string:

All I want for Christmas is $ 100.0!

The latter two are using the string template construct of Kotlin, in an escaped string and a raw string, respectively. The $ symbol indicates the start of a template, and if you need a '$' symbol in your text it needs to be handled separately, in an escaped string by escaping (what else) the character, or by doing a little bit of Christmas magic in a raw string. Other than the '$' character, a raw string preserves everything, including whitespace. Often an editor will format the code by adding extra indentation, which will affect a raw string, too. trimMargin fixes this problem by removing the whitespace up to and including the '|' from the start of the line, like so:

In the examples the string template is simple, with the $ immediately followed by the variable. In more complex cases the expression needs to be put in curly brackets, for example:

The contents of the string template would typically be an expression or a block returning a String. You're allowed use any expression in string templates without compliation errors, but calling a function without a return value isn't normally very useful.

Performance-wise the first statement using String.format is by far the slowest, since it is a thin layer on top of Java’s string.format, which in turns parses the string for arguments on each invocation. Of curse, it offers advanced formatting options for things like numbers, currencies and dates. String templates do no such thing. In fact, string concatenation using '+' and string templates compile to exactly the same Kotlin bytecode:

As we can see, under the hood Kotlin uses the Java StringBuilder. The main argument for using string templates over ‘+’ is that they read better.

String templates are evaluated when the statement executes. In some cases you want the string building to happen as late as possible. An example of this is logging, where a typical log statement using string templates would look like something like.

If the log level is higher than DEBUG, the expression would be evaluated and the string assembled even though the logger would not write anything to the appender. Most log frameworks has functions similar to String.format:

which ensures the string assembly happens only if the log level is DEBUG. However, like for String.format, it could come with a performance penalty when string building actually occurs.

In conclusion, string templates make embedding expressions in strings easier and more readable than other techniques. But it boils down to string building ye olde way, and in some cases, as for logging, it may be more efficient to delay the work till it is actually needed.

String templates

We wrote about "Safe travels for the road warrior" last year. This year we offer one more trick, and expand our list for staying safe and secure on the road.

Watch out for shoulder surfers, and protect your equipment if you have to leave it in for example your hotel room.

PANDEMIC WARNING: Stay at home if you can. A virus has for the better part of 2020 attacked physical infrastructure (people). We have no patch or hotfix, so while that is being worked out, we advice you to travel as little as possible.

Shoulder surfers:

Be aware of your surroundings and reduce the risk of shoulder surfers. A shoulder surfer is someone who is peaking over your shoulder to get information. We can spot people prone to this type of social engineering attack all the time. When people are visiting a cafee, are on public transport, or on air planes they will use their laptop for work stuff. And they don’t notice, or care if someone is looking.

To protect your information, you can, and should invest in a privacy shield for you screen. They cost next to nothing, but reduce/limit the viewing angle of your display.

Reduce the number of apps visible on your computer. On a Mac I recommend that you use Bartender, but there are Windows and *Nix options as well. The point of this application is that it hides all the running apps from the menu bar, so that it looks like this:

rather than this abomination of a menu bar:

The reason for hiding this information from shoulder surfers is that it reveals many of your attack vector. If someone knows what applications you are running, they know a lot about you. Developer tools, Automator scripts, and a password manager? You presumably work in IT. Bluetooth enabled, an old version of Outlook and a TorrentClient? The bad guys already have tools for these applications.

Mikado security

The other tip is to not leave your computer laying around. This may seem obvious, but there are times when this is impossible. There will be events where you have super secret stuff on your computer, and must step away for a period of time. For instance in a hotel room while you are away for an hour, or go to a resturant.

If an adversary has physical access to your device, they can do all sort of damage. A poker player had this happen to him, where someone broke into his hotel room to install malware on his laptop. This is only one of the cases, but we suspect there are many more based on the fact that hotel room locks are ridiculously insecure, and easy to bypass.\ So to combat this problem, we have devised a nice little trick to help you stay safe if you have to leave your device behind.

Mikado by Balazs Koren, on Flickr

Mikado (also known as “pick-up sticks game”) is a game where players drop a bundle of sticks as a loose bunch onto a table top. Each player in turn tries to remove a stick from the pile without disturbing any of the others.

MikadoSecurity is where you spread the sticks over the object that you want to protect. You then take a picture of it, and when you return, you can verify that no one has tampered with your device. In the event that the sticks are not as you left them, you can escalate the problem. Either to do forensics, or discard the computer if you need to.

This trick relies on the same principles as we rely on for computer security. Prime number factoring, traveling salesman problem and SAT are hard to solve if P != NP, but easy to verify. An example of this is a sudoku board. It is hard for both humans and computers to solve, but if I hand you a board, it is easy for you to verify if I did it correct.

Handy tips for staying secure on the go

Hvordan beskytter man seg når innovasjon skjer i åpen dialog med kunder, partnere og omverdenen?

Pia Solheim, Fredrik Matheson og Jens Andreas Huseby i samtale med Joakim Marstrander som jobber med IPR og innovasjon som partner i EY

Beskytt verdiene du skaper! Hva er IPR?

Du har kanskje hørt ordtaket «Love the problem, not the solution»?

Virksomheter lever av å løse kundens problemer. Men det er ikke så enkelt som det høres ut som. Vi har sett storslåtte selskaper gå dukken som følge av at de har forelsket seg i sin løsning på kundens problemer og blitt forbigått av konkurrenter som har forelsket seg i selve problemet, og dermed i større grad evnet å innovere rundt løsningen. BlackBerry og deres «fulltastaturtelefon» er et ofte brukt eksempel på dette. For å drive med kontinuerlig forbedring og innovasjon rundt et problem, er det helt sentralt å forstå brukerens virkelige behov og problemer. Altså å jobbe brukersentrisk. Gjennom mine første måneder i Bekk har jeg gjort meg opp noen refleksjoner rundt brukersentrisk tilnærming, og hvorfor det er fånyttes dersom problem- og behovsdefinisjonene er feilformulert.

Å forstå problemet

Produkt- og tjenesteutvikling handler om å forstå kunden. Vi bør identifisere hvem de er, hvilke problemer de har og hvilke behov problemene er knyttet til. Basert på observasjoner og erfaring bygger vi noen hypoteser om dette, før vi tester det ut mot reelle kunder eller brukere. Ved å orientere oss rundt mennesket og innhente reell informasjon fra faktiske brukere kan vi tilegne oss essensiell innsikt inn mot produkt- og tjenesteutviklingsfasen. Dette fagfeltet er beskrevet i et lass av bøker og utallige rammeverk, men spesielt ett tema erfarte jeg at var krevende å sette fingeren på; Hva er egentlig forskjellen på et problem og et behov, og hvordan skal de formuleres?

En metode for å uttrykke at man skaper reell verdi og møter et behov er å lage brukerhistorier. I en brukerhistorie tar man et skritt tilbake og ser helheten i hvordan et produkt eller en tjeneste skaper verdi for kunden. Ved å ha et bevisst forhold til brukerhistorien sikrer vi at all funksjonalitet i det vi leverer er verdiskapende.

Et fint utgangspunkt for å lage brukerhistorier er setningen «Som en <'kunde/bruker'> ønsker jeg å <'løse et problem'> slik at <'behov tilfredsstilles'>». Ved å fylle ut de blanke områdene belyser vi hvem kunden er, hva de ønsker å løse (problemet), og hvilket behov vi tilfredsstiller. Denne måten å jobbe på synes jeg både er spennende og overførbar til problemløsning på alle nivå i en organisasjon. Tankesettet hjelper oss med å ha et bevisst forhold til problemet vi løser. Vet vi at problemet er knyttet til mange eller viktige behov hos en stor nok gruppe mennesker, så er det et problem verdt å løse. Klarer vi å ha selve problemet i fokus, og å skape produkter og tjenester som løser det, med kontinuerlig forbedring og innovasjon, da vil vi lykkes.

Så kommer utfordringen jeg har opplevd; hvordan sikre at man har forstått problemet? Jeg mener det kan gå ordentlig galt dersom problemet defineres feil. Jeg vil vise dette med et eksempel. La oss ta utgangspunkt i salg og distribusjon av musikk som et overordnet tema, skru tiden tilbake til 90-tallet da CD’er fortsatt gjaldt. Ha brukerhistorien som bakteppe («Som en <'kunde/bruker'> ønsker jeg å <'løse et problem'> slik at <'behov tilfredsstilles'>»), så skal jeg videre snakke om noen regler jeg har laget for meg selv for å bruke dette til å fremme innovasjon og nytenkning!

Som en kunde..

Hvem er det vi ønsker å treffe med våre produkter og tjenester, eller å danne hypoteser om? Jo mer datadrevet vi blir, jo bedre informasjon har vi om mennesker. Adferdsdata tilknyttet preferanser, ferdigheter, personlighet m.m. er tettere relatert til kunders behov enn demografiske faktorer. Hvem har likest behov tilknyttet musikk av to tilfeldige menn i 40-årsalderen og to personer som er musikkinteresserte? Mest sannsynlig de to personene som har musikkinteresse. Derfor er det helt nødvendig å danne kundegrupper basert på kundens adferd fremfor demografiske faktorer som alder og kjønn.

Ønsker jeg å løse et problem..

Hva er det kunden ønsker å gjøre noe med, hva er oppgaven som skal løses? I dette steget er det fort gjort å låse hodet fast i eksisterende løsninger. Hvis utgangspunktet er salg og distribusjon av musikk på 90-tallet, så er det vel naturlig å tenke at kundene ønsker CD’er? Her mener jeg at den største fallgruven ligger. Hvis jeg begrenser problemet til å dreie seg om CD’er, så er løsningen allerede skissert. Tar jeg i stedet et steg tilbake og gjør konseptet av CD’er abstrakt, så åpner det seg helt andre dører. Hva er det en CD eller en CD-samling er? La oss kalle det tilgang på musikk. Hvis vi heller snakker om at problemet er tilgang til musikk, så er vi ikke begrenset til konseptet av en CD som medium.

Dersom vi prøver å løse problemet at kundene ønsker mange CD’er, så kommer vi til å prøve å lage verdens beste CD-produkt og løsninger for å distribuere disse. Tar man steget tilbake til konseptet om tilgang til musikk, så kan løsningen på problemet også inkludere det man gjorde før CD’en; vinyl, kassett m.m., og samtidig la dørene stå åpne for fremtidens løsning; mp3, Spotify osv.

Slik at behov tilfredsstilles..

Jeg opplever at vi har forskjellige oppfatninger av hva behov er, og hvordan vi snakker om det. Samtidig ser jeg at vi er ofte enige hvis vi graver dypt nok. Man kan spille «Hvorfor det?»-spillet til man blir grønn, og det er ofte en nyttig øvelse! Hvorfor ønsker den musikkinteresserte personen tilgang til musikk? Dette høres banalt ut, men det er viktig. Et svar på dette kan være behovet for å dyrke sin musikkinteresse, eller det kan være at man ønsker å bygge identitet. I begge disse eksemplene på behov er vi kommet svært langt ned i «Hvorfor det?»-spillet. Å fortsette med å spørre hvorfor man ønsker å dyrke en interesse eller å bygge identitet begynner å bli lite hensiktsmessig. Derfor mener jeg at eksemplene over er gode behovsdefinisjoner på et riktig nivå. I noen tilfeller ender man helt nederst i Mazlows behovspyramide, men det er ikke målet med øvelsen. Forsøk å tenke ut den sanne effekten på personen som får problemet løst, rettet mot underliggende behov og følelser.

Svake behovsdefinisjoner er typisk formulert som et problem eller inneholder antakelser om løsninger. At kunden for eksempel skulle ha behov for «å bytte CD ofte» er både mer et problem enn det er et behov, og det inneholder en antakelse om at CD er mediet. Det kan skape problemer fordi vi trolig kunne fått innsikt om at mange kunder ønsker å «bytte CD ofte». Og da hadde vi etablert denne sannheten, jobbet ut ifra det, og forsterket utfordringen med å ikke låse seg til konseptet CD som en del av løsningen. Vi må huske at kunden ofte ikke vet hvilken løsning de ønsker før de plutselig får den presentert.

Å knytte problem til behov anser jeg som en virkelighetssjekk; er det viktige behov vi knytter til problemet? Og i hvor stor grad vil vi kunne tilfredsstille behovene til brukeren gjennom å tilby vår løsning til deres problem? Hvis vi ikke vet hvilke behov vi forsøker å tilfredsstille, så er det veldig vanskelig å måle effekten. Er vi i et team enige om hvilke behov kunden har, som vi søker etter å tilfredsstille, vil vi ha en tydeligere felles vei mot målet og snakke samme språk. Vi kan innhente kundeinnsikt, og i neste fase designe produkter og tjenester, målrettet.

Hvordan dette kan hjelpe oss på veien videre

Når vi har gjort øvelsen gjennom stegene, gjerne for flere kundegrupper og identifisert mange potensielle behov, så må vi teste usikkerheter mot bruker. Jeg har opplevd at testing er uendelig mye lettere dersom vi har gode problem- og behovsdefinisjoner. Er det viktigst for brukeren å kunne dyrke musikkinteresse generelt? Da er det kanskje hensiktsmessig å fokusere på en løsning som lar brukeren utforske. Er det å bygge identitet som er viktigst? Da bør vi kanskje legge til rette for at brukeren kan vise andre mennesker hva man lytter til. Dette var tilfeldige eksempler på hvordan vi kan ta i bruk tankesettet. Finner vi ut hvilke behov som er viktigst for kunden, kan vi prioritere funksjonalitet som løser problemet inn i produkt- og tjenestedesign.

Problemer forblir problemer

Bedrifter som «forelsker seg i problemet, og ikke løsningen» sies å være vinnerne. Jeg håper denne artikkelen bidrar til å se viktigheten av å forstå og definere problemet man jobber med, samt hvordan man knytter dette opp mot underliggende behov hos brukeren.

Behov og problemer er ofte vedvarende, mens brukernes krav til løsninger endrer seg kontinuerlig. Definerer man problemer rundt abstrakte konsepter tilknyttet dype behov, har man et utgangspunkt som er åpent for innovasjon, og først da mener jeg at man kan «forelske seg i problemet».

Hvorfor er riktig problemdefinisjon viktig for nyskaping?

There are so many brilliantly written articles about UX Writing out there so I decided to take a look at it from a more personal point of view.

“I mean it like it is, like it sounds.”

Most fans of Twin Peaks will probably remember this line, even though it is overshadowed by a significant number of other quotes from TP. If you have not not seen it yet, go stream that masterpiece right now. #spoilers

Why is this particular line so important? Because it is part of the keychain needed to unlock the many abstract concepts Lynch and Mark Frost presents to us, the viewers. The line is from the episode where Mike enters the dream of agent Cooper, revealing clues about Laura Palmers killer. What I find interesting about this line is its deceptive yet clear intention. The viewer is told what to pay attention to, but the dreamy context suggest we might be deceived.

But some things are just what it is, how it sounds.

The mind is a detective

Intuition guides us, one screen at the time.

For 10 years, I was writing for various advertising companies. My job was to craft words to lure the reader into whatever brand-context I was working on at that time, often with the help of abstractions of concepts, allegories, and other creative tools. It taught me a lot about perception and how I could, very subtly, plant hints for the viewer to decipher the brand message. But most importantly, it made me understand how the brain systematically create mental concepts to percieve and understand the world around it. Words play a crucial part in this process. An incredible 50 % of all words we hear cannot be understood out of context (when presented in isolation). By using concepts, the brain learns to categorize and make sense of all this variable noisy flow of information.

How ironic, you might think, that I found clarity in one of the most surreal dreamscapes ever to air on TV in our lifetime. To me, that’s the beauty of inspiration. It rises to our consciousness like wild salmon jumping upstream a river, striving to get a foothold in our mind amidst all the noise.

Like Lynch and Frost, I left the keys in plain sight for the audience to discover and interpret. Creative advertising requires just that, an idea we, the creators, code, and then let the audience decode. But UX Writing very often requires quite the opposite. You must write it like it is.

The sound of clarity

It has always been a beautiful mystery to me, how clarity has the power to shape us. How it informs us simply by being less intrusive or more truthful.\ To me clarity is not the equivalent of writing short and efficient sentences. It can be about that, but not just that. Clarity is about finding the true essence of whatever you’re trying to convey. It’s what will make your followers believe you or not and go where you’re guiding them. Or not.

Just do it



I have a dream



Fire, walk with me

But clarity is also this

The real challenge is to fuse the two worlds into one. For that to happen you’ll need to sit down, relax, focus, open your mind and just…

…listen

In an interview with Vanity Fair, Jony Ive, former Chief Design Officer of Apple, said that Steve Jobs had an amazing ability to focus. He managed to eliminate the inevitable noise surrounding any world-changing project and devote all his attention to making it the next big thing.

Regardless of age, title and which floor you work on, there is a valuable lesson to be learned from this, Focus is needed to build great stuff, but it also essential for knowing when your brand needs to speak up. Or when to shut up.

Understanding when to do what requires the ability to listen. I will listen to what the customer says about their experience. Pay attention to what the designers have to say about their intentions and challenges. Concentrate as programmers show me the project’s specifics and possibilities.

Jobs did this and was not afraid to change his mind should it benefit his creative singularity. It takes a great amount of willpower to let go of your own ideas.

Enough about Jobs, tell us about the drummer

In an interview with Drumeo, drummer Gavin Harrison, known for his musicality and passion for rhythmic design, shared his tips and methods for coming up with tasteful drum parts, improving your creativity, and your general mindset when playing the drums. While talking about his references from his younger days, he begins talking about drummers who play with time.

“You’ve probably heard this expression before, but everybody’s job in the band is to play in time, but it’s the drummer’s job to make the time interesting. So, you don’t have to just play, say, if the first verse just needs two and four on the hi-hat, you don’t have to just sit there going… …what I would do is listen to the vocalist and look for spaces to do small musical embellishments. Put it in the right place, and it’s beautiful. Do it every bar, and it’s horrible.”

This is precisely what UX Writers should do (among many other important things). Listen to the project as a whole, look for spaces in between code, design, text, menus, forms — literally every point of interaction — to create something that elevates the project, and therefore the brand. Band. You know what I mean. And yes, I consider UX Writing to be an essential part of building and/or maintaining a brand.

Words are like ghost notes providing subtle dynamics to the sonic scenery. They will make people feel something.

Be part of their feelings

Humans like to be liked. Brands too. Therefore we make and effort to portray ourselves, man and brand, in a way that will serve as purposeful and friendly for our peers. From a brand point of view we would very much like people to feel what we want them to feel about us. This is usually where marketing says “we got this”. And they probably do. Persuasion is needed to increase awareness and market shares. But what happens after we get their attention?

This is where guidance and clarity is provided and needed, not juicy headlines and rethorical tropes. Now it’s time to go with (and steer) the flow.

Some people understand this process intuitively and how to utilize it in many different ways. In a talk at Design Matters 2019, Senior Product Writer at Slack Andrew Schmidt shared insight from Slacks early days on how language could be a tool for identifying “bad” design, and how they discovered when to inject brand personality and how to do it. They came up with a very simple and interesting rule:

Never try to make the user feelInstead, look for the feelings they’re already having.\ And just be part of those.

👇🏻

The delicate sound of raging customers

I believe Slack is on the right path when it comes to how they percieve UX Writing. They have chosen a much less intrusive approach in a world where our minds are bombarded with emotional hooks ready to be reeled in. But for enhancing your UX Writing, I think being subtle and aware (but don’t forget to surprise once in a while) will take you far.

Is your brands presence needed for solving this particular task?\ Or is it better to get out of the way for a bit?\ Treat words in the same way designers treat white space.

The invisible rudder

My family owns a summer cabin near the ocean. In my younger days, I would cruise around in our family’s tiny motorboat. That was when I learned the concept of a rudder, a gentle device for navigating smoothly across the sea. This information suddenly reappeared a few years ago when I was writing about ergonomic seating. The company I wrote for had designed a new office chair that kept the person in it slightly moving while sitting down. One of them sat in the chair and used their feet to move around. Seeing this, I suggested to the designers that the feet act as a rudder to navigate the body. According to them, this was a perfect description of what they had accomplished.

I looked. I listened. And I found the embellishment I was looking for.

In this ocean of information we’re slowly drowning in, I like to think of microcopy as an invisible rudder for our intuition. It’s there to guide you through interactive waters, shallow or deep, without you seeing it. If you can see the rudder, you’ve probably hit bottom, and then you have to slow down to understand the situation. When designing interactivity, people crave fluidity. Like in a musical piece that captivates us or in a movie that enthralls us with great dialogue and scenery. Or even a game like Red Dead Redemption 2 whose job is to help us navigate 60+ hours of content while keeping us immersed in their universe. Well played.

Creativity, meet functionality

Our understanding of the world is layered in mental concepts. Everything can be stripped down to its very basic components. Even what we know to be basic components has its own basic components. By understanding this, one becomes humble when faced with the task of understanding complex matters. Or answering complicated questions.

Whenever I write, my goal is always to find the simplest version of the truth intended. By truth, I mean the pieces of information I relay to people who desire an outcome of some sort, typically in an app or landing page. Sometimes I need to let function dictate what I write; other times, it feels like a good time to sparkle with some creativity.

Bill Bernbach, a legendary copywriter responsible for the famous Think Small ads for Volkswagen, once said that creativity is the intangible thing that makes the difference. It’s just something that feels right. Right? But at the same time, creativity is an extra layer for people to decode and make sense of. What I’m saying is being creative for creativity’s sake is not enough. It has to add meaning or value.

Bill Bernbach also said that "advertising is fundamentally persuasion, and persuasion happens to be not a science but an art". This is also something I hold to be true. Although much progress has been made in science since this quote was published, I believe it is just as accurate today. What’s new is that originality is being copied much faster. And mediocrity shines like never before, radiating in front of the good stuff.

So, don’t feel bad about procrastinating when you need to write. Humans put the whole thing of for a couple of hundred thousand years. By a conservative estimate, we’ve had writing for 4 % of the time we’ve been humans. Chatting is easy, writing is an arduous chore.



— Erika Hall, Conversational Design

Where does this leave us?

This post is by no means an answer to anything. That is for you to decide. Whatever I write stems from a place of truth and many late night solo ventures into the self. If it somehow resonates with someone in some way, I’m happy.

One thing I do know from watching David Lynch’s work, is that I come to the same conclusion, time and time again, and that is that closure is never what we really want. For better or worse, life is just more interesting when everything is ever-changing.

So, stay curious. Embrace clarity. Worship creativity.

Through the darkness of future’s past,

The magician longs to see.

One chants out between two worlds…

“Fire… walk with me.”

We lived among the people.

I think you say, convenience store.

We lived above it.

I mean it like it is… like it sounds.

Sources

How Emotions Are Made, by Lisa Feldman Barrett

Andrew Schmidt, Senior Product Writer for Slack

Twin Peaks Season 1, Created by David Lynch and Mark Frost

And everything else my senses absorb when I’m not aware 🧠

What I Learned About UX Writing From a British Prog Drummer and David Lynch

Do you feel compelled to manually test your React frontend after each deploy, because it’s not tested as well as your backend? Or perhaps you already have frontend tests, but you feel that they only serve as a hindrance, slowing down your development speed? Perhaps it’s time to give frontend testing another go, with the React Testing Library!

The React Testing Library (RTL) lets you test your React components in their natural habitat, that is, in the DOM. The goal is to test your components in a way that most closely resembles how the user will interact with them. That means fully rendered components in a browser-like environment, and assertions that test the contents of the document. As the library’s author, Kent C. Dodds, puts it:

The more your tests resemble the way your software is used, the more confidence they can give you.

Great, show me a minimal example

Let’s start off simple. Here’s a Jest test that uses RTL to assert that a CustomButton component is rendered with the correct label as defined by its label prop.

Fairly straight forward, huh? Let’s break it down a bit anyway. RTL provides a render function that lets us, well, render our component. Specifically, it renders it into the document body that the tests operate on. The second import, screen, then lets us query the contents of the document, here by searching for any element with the given text. Lastly, we expect such an element to be in the document. The latter is an argument matcher from @testing-library/jest-dom which gives us declarative assertions. The test is dead simple and only tests what the user cares about: how the component appears on the screen.

Avoid testing implementation details

RTL tries to encourage writing tests that do not depend on how the components work internally. One example we’ve seen already is the way we query the document for an element — by its text content. The tests should approach the component like the end user would; they should only care that the button be present and that it have the correct label. The alternative of querying an element by its CSS selector (a widespread approach) is thus discouraged.

One reason you may have felt that frontend tests hinder you in the past could be due to what Dodds refers to as the test user. The essence is that your components normally have two users: the end user and the developer. For each user, you have to maintain the interface through which they access the component. The end user cares about the UX interface on his screen, while the developer cares about the component’s API. However, if your tests depend on the implementation details of your component, you’ve added another (informal) interface that you need to maintain — you’ve introduced the test user. Now you might find that any future changes or internal refactoring break the tests unnecessarily, and you’re slowed down. Oof.

So let’s avoid that! RTL does a good job at providing an API that uses your components in the same way that they’re used in your production code, and interacts with it like the end user would.

Querying by role

Let’s return to our example for a second. Searching for the button by its text content is nice and simple. But what happens if you’re testing a more complex component (or a whole page) and there are multiple matches? After all, getByText matches any text node. We can do a bit better by using the getByRole query:

This is no doubt a more specific query, and it also has an additional advantage: it forces us to think about accessibility. The “role” refers to the accessible role of the element (e.g. button, input, link, search, etc.), and the “name” is its semantic name, which a screen reader would use to narrate the element. Now, if your tests can find the button with the provided text, a screen reader would too! Tests that behave the same way as your end users are the tests that keep giving. Dodds recommends using the “by role” queries most of the time.

User interaction and asynchronicity

Let’s say that when our button is clicked, it triggers the loading of some data, which is then rendered somehow. We can test this scenario using the user-event utility and asynchronous queries. We’ll find the button, click it and then assert that the content eventually shows up. Let’s assume that the component MyComponent includes a button with the label "Load Data" and that the loaded content has the header "Your Data".

For a bit of extra robustness, I replaced the strings here with case-insensitive regex expressions (no need for the tests to break if the capitalisation changes). We first assert that the button is present, so that we get a better indication of what’s wrong if the test fails. Then, userEvent handles the button click action in a realistic way, meaning it generates all the appropriate events. Lastly, we use the findByRole query in place of getByRole. The former is asynchronous, and waits a maximum of 4500 ms for the content to appear before the test fails. Usually, it proceeds almost immediately, especially if the fetch call is mocked out. This is extremely useful and ensures our tests never wait longer than they have to.

What about global state stores, like Redux?

You can still test your components with RTL, even when they utilize a state store, context or router. Although pure components are easier to test (just as for pure functions), you can override the render method to render the components within a wrapper where you set up all your providers. For state stores, you can then either let all your tests use the initial state, or override parts of the state on a test-by-test basis. The docs offer some excellent examples for this.

When you’re writing tests that operate heavily on local or global state, you may be tempted to assert that parts of the state have correct values after performing an action. In this case, the more idiomatic approach is to verify the state through how the component is rendered, in line with avoiding testing implementation details. This ensures you’ll be able to freely move parts of the state from global to component level and vice versa in the future. If necessary, you can always supplement the RTL tests with additional Jest unit tests to verify the correctness of your reducers.

Final thoughts

The React Testing Library makes it possible to write quick, concise, powerful and maintainable frontend tests. It’s pretty easy to get started, so why don’t you give it a shot? The next step can be to check out the docs. There’s also quite a few nice articles about the library on Dodd’s blog.

React Testing Library

Custom types are powerful data structures that might seem somewhat complicated to work with, at least if they are nested. Let's take a look at how we can deal with nested custom types in a simple way! 🍊

Custom types in Elm are used when defining data types that can have different possible variants. We can think of this data structure as a tree, with each branch representing one variant of the data type. Each variant, or branch, can itself contain a new custom type, resulting in a nested tree structure. We call this a nested custom type.

Let's look at an example. Say we have a, very simplified, custom type Fruit:

The Fruit type contains different variants of a fruit, with one of them being Citrus. Citrus itself contains another custom type, namely CitrusFruit, which makes Fruit an example of a nested custom type.

What if we want to write a function that returns a png-image of a given fruit? Then we would have to destructure the fruit using a case..of expression. This could be done like this:

As you can see, this way of unwrapping the Fruit requires two case..of expressions. The resulting code is not very readable and can, in fact, be written in a much simpler way! We can simply destructure the whole Fruit in one case..of expression like this:

See how much easier this function is to scan? 🧐 This little "trick" is something people new to Elm often don't know about, which is a pity as it makes the code both easier to write and more readable. It is especially helpful in the update function if you have a nested Msg. Try it out the next time you climb trees!

Climbing trees

When creating a presentation it's good to have your own style, adding your own touch. Over the years creating different presentations for conferences or for a demo, I have developed my own approach when creating the slides. I want to present it for you, and I hope you like it!

There are several ways to design your slides when creating a presentation. Do you have content-rich slides and few pages, or do you have 40 views for a 10 minute talk? The last one is me. I prefer to create slides with minimal texts, a lot of images or illustrations, and where I have to press the Enter button several times a minute (almost).

Disclaimer: This is my point of view. I'm not saying that other ways of creating presentations is wrong, but this is they way I prefer to make presentations.

Remove the wall-of-text

It is hard to remember everything you need to say in a long presentation, especially if it is an in-depth talk and you need to get all your facts right. However, when I’m having a lot of text on my slides, it feels like I’m loosing the connection with the audience. The listeners will focus on the slide and read the text simultaneously as to listening to what I’m currently saying to them. I also throw myself off guard more easily if I forgot to say something that's in the pile of text.

I have found it liberating to shorten the text on my slides to the minimum. I use short sentences, bullet list, even only single words sometimes. Choose the most important words to present to the listeners. You can use them as reminder of what you are going to tell without it sounding like you are reading from a manuscript. If you forget some of the sentences you had written down before, maybe it wasn't an important part of your talk.

Use informative pictures and illustrations

I find it more successful to use pictures or illustration in my presentation to catch the attention of the listeners. I often try to find screenshots, pictures or even gifs to illustrate the things I want to explain (you can easily make a gif from a video you record 🤓). Sometimes I dedicate an entire page of my presentation for an emoji, as long as it makes sense of what I'm going to say. By adding these "creative" slides, I think it will more successfully capture the listeners attention. At least for me, I’m definitely paying more attention then!

Take a moment to think about the information you want to convey to other, and think "How can I convert it to something other than text". You want to show your working method in your team? Take a picture of the post-its. You want to show the structure of your system, make a drawing with arrows to show the flow. Draw something by hand, or go to Google Drawings. There are many possibilities!

Multiple slides and frequent switches

So we have gotten rid of the text-heavy pages, and added the informative pictures to our slides instead. How are we now supposed to remember all we want to say? I'm using each change of slide as a reminder of the things I'm going to say. If there is a part that I keep forgetting to mention when I'm practicing, I add a new page for that specific part that reminds me of it. It's almost (with a little exaggeration) that for every new sentence, I go to the next slide.

Often I want to present as little information as possible to the user, I only present the information I want they to focus on. When adding a bullet list, I only show the first item, and then press enter to show the next, etc. Another example is when I'm showing a code snippet I break it down to the part I especially want them to focus on, and keep adding the next part when I begin to talk about it. The attention span for most people is short, make it easier for the users to focus.

Disadvantages with this method

As I said in the introduction, this is a way I have discovered along the way of creating presentations that works for me. It doesn't suit everyone. First of all, you need to use a lot of time creating the slides, adjusting the text and what you want to illustrate. It will require some tweaking. You also rely on that you are close to your computer or a "clicker" for being able to change slides often, preventing you from running across the stage every time you need to show a new slide. Finally, it requires that you have time to practice on your presentation multiple times to know where you need to add a slide or two, if you are a spontaneous person this may not be the way for you.

Voilà!

We have talked about removing the wall of text, enriching the slides with illustrations and pictures, and using every change of slide as a reminder of what you are going to talk about next. This is the way I am creating textless presentations, which are helping me become more free of my presentation notes and more calm when I'm talking.

This was a little introduction to how I make my presentations. Hope you liked it!

6-Dec

Today's posts