Når vi lager digitale tjenester må vi sikre at de kan oppfattes av alle! Det innebærer at vi gir tekst til blant annet bilder, lyd, inputelementer, knapper. Her dechiffrerer vi WCAG 1.1.1, slik at du slipper å tolke regelverket selv!

WCAG 1.1.1 sier "Gi brukeren et tekstlig alternativ for alt innhold som ikke er tekst!*"

Dette betyr at bilder må ha en beskrivende alternativ tekst, lyd må tekstes, inputelementer og knapper må ha beskrivende navn, og til og med CAPTCHAS trenger å ha tekst som identifiserer innholdet og beskriver formålet - og har du forresten tenkt på at du må ha alternativer til CAPTCHA som fungerer for alle? 

For de som bruker skjermleser, talestyring eller har tregt nettverk kan dette være viktig! Her er det noen situasjoner du kan ende opp i, og eksempler på hvordan man løser dette:

En beskrivelse gjør samme nytte som det ikke-tekstlige innholdet:

En illustrasjon av hvordan man strikker en maske, med en tilsvarende tekstlig beskrivelse på hvordan man gjør det samme.

En graf med salgsdata for oktober, med en kort beskrivelse av typen “Salgsdata for oktober”, og en lang beskrivelse som gir informasjonen som ligger i grafen.

Det er en knapp eller inputfelt:

En knapp med pil eller annet ikon må ha en tekst eller alternativ tekst som forklarer hva ikonet gjør

Inputfelt må ha tilknyttet tekst (holder ikke med placeholder-tekst, den forsvinner!)

Det er en test for å unngå spam-roboter:

En CAPTCHA som krever at man hører lyd og skriver vil ikke fungere dersom man er døv, derfor legger vi på tekst som forklarer testen og beskriver formålet, i tillegg til at vi legger inn en alternativ CAPTCHA som f.eks. viser bilder og lar deg bli testet på den måten i stedet.

Innholdet er en sanseopplevelse som ikke lar seg gjenskape i tekst:

Et musikk- eller kunststykke - vi legger på en tekst som identifiserer hva innholdet er.

Kart? Jeg har nettopp begynt på prosjekt i Kartverket, og der har vi interaktive kart der man skal kunne tegne opp grenser. Jeg lurer på om det går under her, men vet ikke. Hva tror du?


Det finnes en tekst som gir fullgod beskrivelse:

I tilfeller der tekstlig innhold er tilgjengelig er det unødvendig eller potensielt feil å bruke aria-label. For eksempel, en knapp med tekst trenger ingen ekstra aria-label, det kan føre til dobbelopplesing eller ulike tekster for seende og ikke-seende.

Til sist; det finnes ingen regel uten unntak. Se full liste av unntak fra regelen her: https://www.uutilsynet.no/wcag-standarden/111-ikke-tekstlig-innhold-niva/87

Gi et tekstlig alternativ for alt innhold!

DMARC er eit av dei beste våpena me har mot spoofing. Det viser seg at norske aktørar må skjerpe seg. Sjå kor gode dei er på dmarcstatus.no.

E-post har eksistert i over 50 år og SMTP, protokollen bak, er grunnleggjande usikker. Det er lett å forfalske kven avsendaren er og dermed drive med svindelforsøk. På 70- og 80-talet var alle menneske snille og gode, så det var ikkje eit problem. Men i dag er spoofing (å late som ein sender e-post frå nokon andre) og phishing (prøve å folk til å trykke på lenker og til slutt svindle dei) store samfunnsproblem.

E-post fungerer nemleg slik at alle kan sende e-post frå kva for ei helst adresse. Det høyrest rart ut, men slik er det. Det finst heldigvis gode tiltak alle bør gjere for å hindre at domenet sitt vert brukt av andre. Denne artikkelen handlar om DMARC, som baserer seg på to andre mekanismar – SPF og DKIM – for å gi eit godt vern mot spoofing.

Bakgrunn

La oss gå fort gjennom kva SPF, DKIM og DMARC er.

Sender Policy Framework (SPF) er ein enkel mekanisme du kan bruke for å seie kva for nokre IP-adresser du sender dine e-postar frå. Dette spesifiserer du i ein DNS-record av typen TXT som du legg på ditt domene. E-postserverar som mottar e-post frå ditt domene kan slå opp denne DNS-recorden og sjekke om IPen til avsendar-serveren er blant desse.

DomainKeys Identified Mail (DKIM) lar mottakande e-postserverar sjekke om innhaldet i e-posten har vorte tukla med på vegen frå avsendar til mottakar. E-posten er signert med ein privat nøkkel som avsendaren har. Denne signaturen vert lagt på e-posten som ein header. Den offentlege nøkkelen ligg som ein DNS-record på domenet ditt. Mottakande e-postserverar kan då bruke den offentlege nøkkelen til å verifisere at innhaldet stemmer med signaturen.

Domain-based Message Authentication, Reporting and Conformance (DMARC) lar deg spesifisere kva du vil skal skje med e-postar som feiler både SPF og DKIM. For om du har både SPF og DKIM sett opp, men ikkje DMARC, så er det opp til dei mottakande e-postserverane å velje kva som skal skje. Ofte vil det nok berre gå gjennom til mottakaren. DMARC set du òg opp som ein DNS-record.

DMARC gir deg òg moglegheita til å få rapportar frå mottakande e-postserverar om e-postar sendt frå ditt domene. Desse rapportane inneheld informasjon om e-postane har passert DKIM, SPF og DMARC, og kva for ei kjelde dei kom frå. Det finst mange gode tenester som let deg analysere desse rapportane og følgje med på kor mange som misbruker domenet ditt.

Jo strengare, jo betre

Det viktigaste i DMARC-oppsettet ditt er kva for ein policy du går for. Det finst tre val: none, quarantine og reject. Jo strengare policy du vel, jo betre sikring mot spoofing oppnår du.

None betyr at du ikkje ber mottakande serverar gjere noko spesielt med e-postar som feilar DMARC-sjekkane. I praksis vil dei nok kome fram til innboksen til mottakaren som vanleg. Dette gir ingen sikring mot spoofing, men det er fint å begynne med dette mens du samlar inn rapportar og set opp SPF og DKIM. Det kan nemleg vere vanskeleg å vite kor mange reelle e-postserverar og -IP-adresser du sender frå, om domenet er for eksempel brukt i eit stort konsern. Ein vil ikkje at legitim e-post skal verte forkasta! None er derfor ein fin policy mens ein kartlegg dette og får gradvis sett opp SPF og DKIM riktig. 

Quarantine er den nest strengaste policyen. Då vil e-postar som feilar DMARC-sjekken kome fram til mottakar, men vere markert som spam. Så det hamnar truleg i søppelposten. Absolutt betre enn «none», men ikkje optimalt.

Reject er det strengaste policyen, og det du ønskjer å oppnå til slutt. Då vil mottakande e-postserverar som støttar DMARC forkaste e-postar som feiler DMARC-sjekken, og mottakaren vil ikkje få dei i det heile tatt.

Eit grunnleggjande tiltak

DMARC er eit grunnleggjande tiltak for sikring av e-post, noko Nasjonal sikkerheitsmyndigheit (NSM) skriv meir om på ei eiga side om DMARC, nemleg https://dmarc.no. Alle domene bør ha definert ein DMARC-policy, og jo strengare, jo betre.

Vil du sjekke DMARC for ditt eige domene? DMARC er publisert som ein DNS-record av typen TXT som må vere på på subdomenet _dmarc  (f.eks. _dmarc.example.com). Så det er enkelt å sjekke frå kommandolinja med kommandoen dig _dmarc.example.com txt. Det finst òg mange gratis-tenester på internett som kan analysere DMARC-oppsettet ditt, og burde vere enkelt å søke opp.

Sjølv om du ikkje sender e-post frå domenet ditt, bør du setje opp DMARC (og SPF) til å forkaste all e-post. Om ikkje du sender e-post frå domenet ditt, så vil du vel ikkje at nokon andre skal gjere det heller? Då kan du setje opp desse to DNS-innslaga (bytt ut example.com med ditt domene):

TXT   example.com  v=spf1; -all 

TXT   _dmarc.example.com   v=DMARC1; p=reject 

Om du derimot bruker domenet ditt til e-post og ønskjer å kome i gang med SPF, DKIM og DMARC, så rår eg deg til å sjekke e-postleverandøren din sin dokumentasjon på dette. Det burde ikkje vere for vanskeleg å finne det du må kopiere for å setje opp SPF og DKIM. Deretter kan du setje opp din eigen DMARC-record på _dmarc.ditt-domene.no .

Kor gode er norske aktørar?

Eg har prøvd å finne ut kor gode norske aktørar er på DMARC, og oversikta finn du på dmarcstatus.no. Sida listar ut kva for ein DMARC-policy dei største og viktigaste institusjonane, organisasjonane og verksemdene i Noreg nyttar. Manglar det nokon? Sida har open kjeldekode, så lag eit issue eller ein pull request på https://github.com/draperunner/dmarc-status.

Målet med denne sida er å opplyse om DMARC og å oppmode aktørane til å forbetre DMARC-reglane sine, slik at nordmenn forhåpentlegvis opplever færre phishing-åtak i framtida. Det er juletider og phishing-sesong, så dette er høgaktuelt.

Er det ein sikkerheitsrisiko å publisere ei slik liste over domene med manglande eller dårlege DMARC-policies? Nei, det vil eg ikkje seie. DMARC for eit domene er publisert via ein DNS-record som må vere på på subdomenet _dmarc  (f.eks. _dmarc.example.com) og dermed lett tilgjengeleg, offentleg informasjon. Og som sagt, DMARC er eit grunnleggjande tiltak. Om ein prøver seg på halvvegs seriøs spoofing, så veit ein å sjekke DMARC først. Det tar uansett mykje lengre tid og meir innsats å forfatte ein truverdig, falsk e-post.

DMARC er ikkje ei vasstett løysing på spoofing- og phishing-problema, men det er eit av våre beste verkemiddel. Jobbar du i ei av verksemdene med mindre god DMARC-policy? Gi beskjed og få det fiksa i dag!

Norsk DMARC-status

Dagens designtips er en artikkelserie hvor forskjellige designere fra Bekk forteller om jobben de gjør, hvilke utfordringer de møter på, og kanskje kommer med et lite tips!

Hvem er jeg?

Markus

28 år gammel

Fra Oslo

Studerte design på Arkitektur og Designhøgskolen i Oslo

Jobbet som designer i 1,5 år


Hvorfor ble jeg designer? Jeg trodde egentlig jeg skulle bli arkitekt, men kom heller inn på designstudier. Etter et par uker, så var jeg sikker på at dette var et heldig tilfelle og sjeleglad for at jeg ikke studerte arkitektur. Til å begynne med, så ville jeg jobbe som industridesigner, men følte at jeg hadde større muligheter til å gjøre menneskers hverdag enklere gjennom interaksjon- og tjenestedesign og spesialiserte meg til det i stedet.


Hva gjør jeg (og hvordan)?

Det siste året har jeg jobbet med online booking av verkstedtjenester hos Møller Digital. I teamet prøver vi å gjøre det enklest mulig for kunden å få bestilt en verkstedtime for det de trenger hjelp med. Samtidig som vi ønsker at verkstedene skal få den informasjonen de trenger for å jobbe effektivt. Og tenke både brukerperspektivet for både kunden og verkstedet er utfordrende og deres behov er ikke alltid sammenfallende.


Hvilket tips ville jeg gitt meg selv i starten av prosjektet?

Få de rette folka med på laget. Det er ikke alltid de tekniske begrensningene som setter en stopper for gode løsninger. Med de rette personene med i prosessen til rett tid, så kan man få løst ganske mye.

Dagens designtips



I was tasked with a seemingly small feature request in an application; send an email notification when an event is changed. The challenge began when we should report changes in event time/dates. An event might be scheduled for “tuesday 10:00”, “tuesday 10:00-12:00” or “tuesday 10:00 to wednedsay 12:00”. When an event is changes, we might change the start date, start time, end date, end time, or any combination of these. And when parts isn’t changes, we shouldn’t include it to avoid a wall of text where it’s difficult to spot what is actually changed.

Needless to say, there’s a lot of edge-cases here. I started by diffing parts, seeing if they have been changed, and if I should include them. But this turned into a if-else spaghetti where I needed to look at unrelated parts – for instance when the date has changed, it makes sense to include the end time even though that didn’t change.

I took a step back to design a more maintainable algorithm. While the resulting algorithm only is mildly interesting, the process of looking at the data and designing it is probably useful for other problems.

I wrote down all permutations of possible cases I could print. D is date, T is time. The table is a bit cryptic, but when writing the last form, I found a way to redesign the algorithm.

The last row is the canonical form, e.g. from Tue @ 10:00-10:00 to Tue @ 10:00-10:00. I had previously designed the algorithm by trying to see what parts I should include, but a better design is to start at the canonical form and see what parts I can hide.

We have four data points:

start date

start time

end date

end time

At two distinct times:

old

new

With two different diff states:

unchanged : old and new value is the same

changed : old and new value differ

This leaves us with 4*2*2*2=16 different cases, as is reported in the table above.

Looking at the table, we can also see that we have three different states for rendering:

Hide : We don’t need to show this

Single : Only need to show the old value

Interval : Need to show the entire interval

We group the data points in intervals such that we have (start, end) pairs in order to see if we need to render an interval or can just render a single value. If the start and end is the same, we can render just a single value, but might need to render both if they differ.

We run this check for all parts:

old (start date, end date)

old (start time, end time)

new (start date, end date)

new (start time, end time)

But if both the corresponding old and new is the same, we can Hide the entire field.

At this point, we have both checked how we might want to render it, and we have diffed the old and new parts.

Looking at the table, we see we want to group our fields by date and time. Now it’s time to format the “from” and “to” columns from the table. This function will look at the ShowField of the date and time combined, giving 3*3=9 cases to handle, and a quite maintainable lookup table for these.

By flipping the design from “how can I show” to “what can I hide from the canonical form”, we transitioned from a maintenance nightmare to a quite elegant algorithm.

Here is the complete code.

A simple diff for date/time duration changes

As a designer, you should know what boundary objects are. Not necessarily to make you a better designer, but because a large portion of what you're already doing as a designer is probably to make boundary objects. At least this applies to me as an interaction designer working in a product team.

The first time I heard about boundary objects was at the Oslo School of Architecture and Design. Bridgeable, a Canadian service design consultancy, was invited to talk about their work with the New York City Transit. One of the things that got stuck with me was their view of a designer as a diplomat. Especially this quote:

As design diplomats... Our aim isn't to eliminate conflict, but understand it, channeling it into creative and productive action. Conflict is a necessary precursor of change.



I have somehow always strived to avoid conflict, thinking that conflicts are bad for collaboration. That it's a show-stopper for innovation and efficiency. To look at conflict as a necessary precursor for change was an eye-opener for me.
But what can a designer bring to this conflicted table?
You probably guessed it, boundary objects!





What is a boundary object?

Boundary objects were first introduced by Susan Leigh Star and James Griesemer in 1989, writing an article analyzing the formation of the Museum of Vertebrate Zoology in Berkeley. A project where various actors had to cooperate, despite having different and often conflicting interests. The museum director, its primary patron, university administrators, and amateur collectors. Everyone with different concerns about the museum. It is here Star and Griesmer found that certain objects helped in the collaboration despite the differences. Star and Griesmer initially defined boundary objects as:


"Objects which are both plastic enough to adapt to local needs and constraints of the several parties employing them, yet robust enough to maintain a common identity across sites...They have different meanings in different social worlds but their structure is common enough to more than one world to make them recognizable, a means of translation. The creation and management of boundary objects is a key in developing and maintaining coherence across intersecting social worlds."*




Yep.. classic academic language…but what does it mean?

I'm going to explain my understanding of boundary objects, but it might help to have some common boundary objects for designers in mind before reading the next part. E.g. user journey maps, prototypes, flow charts, blueprints, giga-maps, or whatever design you have presented outside your team.





It has to be an object

A boundary object needs to exist outside your, or other people's head. A map of Oslo is a boundary object. It exists and functions on its own, it's not someone's personal opinion. A conversation, on the other hand, is not a boundary object. It is something that exists inside the heads of the people conversing. There is no guarantee that they have the same conception or that they are imagining the same thing.




Plastic enough to adapt

It's something each actor involved can use according to their needs. A tourist will use the map of Oslo to find sights, a taxi driver will use it to find the best road from a to b. An architect will use it to plan the next opera house.




Robust enough to maintain a common identity

It's something people can’t argue with. It is based on facts or accepted truths. It should be looked at as logical and realistic. The tourist and the taxi driver can disagree about the best way to get from a to b. But the map as a boundary object is the same for both of them. A tool to understand each other even though they are disagreeing.




A means of translation between intersecting social worlds

Intersecting social worlds could for instance be the IT departments world and the law departments world. Two worlds with very different perspectives on problem-solving. In the case of a boundary object, people from both these worlds should be able to understand the object without a lot of explanation or reading pages of documentation.




A boundary object that failed

I got this from a colleague on Slack the other day.

"I had an a-ha moment about boundary objects last week when doing a workshop with a neighboring team. We are trying to collaborate with them, but have struggled for a while to understand each other. Then it suddenly hit me! They don't have any boundary objects. They have a very beautiful prototype with a lot of interesting new functionality, but the developers don't understand what to do with it. The product owner can't find a logical connection with the available data at hand..."

In this case, they have what seems to be a boundary object, a prototype. The problem here seems to be that the prototype is not robust enough to qualify as a boundary object. It's not based on "accepted truths" since the product owner does not find a logical connection with the data at hand. It's not convincing enough to be used as a base for collaboration.

If the taxi driver was given a map with roads that did not exist, he or she would never accept it as a tool to decide the best way to get from a to b.



Finishing notes

This is the first time I write about my understanding of boundary objects, and I'm no expert. If you have any comments I would love to get feedback.

Some key takeaways:

Conflict is a necessary precursor of change. Our aim is not to eliminate conflict, but to understand it, channeling it into creative and productive action.

If you use boundary objects to collaborate, make sure that they qualify as boundary objects. Especially if you feel that they're not working as expected.





-----------------

Sources and further reading: 

* Star, Susan; Griesemer, James (1989). "Institutional Ecology, 'Translations' and Boundary Objects: Amateurs and Professionals in Berkeley's Museum of Vertebrate Zoology, 1907-39" (PDF). Social Studies of Science. 19 (3): 387–420.

A field guide to boundary objects 

Prototyping and Boundary Objects by Matt Cooper-Wright










Boundary objects - Design for Collaboration

Animations in app development is something that, when done right, could elevate the user experience to another level. In this article I hope to give you the tools you need to create animations in your React Native app, all while keeping the Christmas spirit alive 🎅

To present these tools, I will exemplify the four most common methods for writing animations in React Native, and give you an understanding of when to use which method. In true Christmas spirit, we will create a wish list to Santa, and hope that the animations will get his attention and we get what we wish for!

If you want to follow along, I have created an example app using expo that implements all the animations I talk about in this article. Check it out here. The starting point of the example can bee seen below.

As you can see from the GIF, we have to wait some seconds before our wish list is fetched from the server. The app only shows a blank page in the mean time, leaving Santa confused whether he did something wrong. Let us fix that now!

1. Lottie

We can present Santa with a nice loading animation to give him some context of why the list is not showing up at once. To do so we can use Lottie, which is branded as a lightweight, scalable animations package that works with most platforms (web, app, email, ads, etc.). 

Using this package for loading static, vector based animations will make the loading time more fun and acceptable for Santa. All we have to do is to install and import the package, import a json formatted Lottie animation file, and conditionally render it while we are waiting for our data. The Lottie json files can either be created by yourself, or it could be downloaded for free from their website.

Using Lottie animations is also perfect to indicate successful (or unsuccessful) completion of tasks. Had our simple wish list app included a way to add new items to the list, a confetti animation to celebrate this action would be very enjoyable!

Combining Lottie with the React Native Animated API (described in 3.) also unlocks new possibilities like programmatically setting the frames of the animation. With this combination you could intertwine the loading and success animation into one smooth experience, by looping the loading frames until the action is complete, and then seamlessly finish with the success frames of the animation.

2. LayoutAnimation

Looking at the results from adding Lottie it certanly improves the experience for Santa. However, there is still an abrupt change between the loading animation and the appearance of the items in our wish list. We do not want to scare Santa with our long list, but rather make a smooth transition for him once the items are done loading. To make such an animation, we could fade the items in by using LayoutAnimation which is directly built into React Native. This can be achieved by simply adding this one-liner:

LayoutAnimation.configureNext(LayoutAnimation.Presets.easeInEaseOut);

right before we store the fetched wish list to our state. The configureNext function works by automatically animating views to their new positions when the next layout/re-render happens.

While easy to implement, LayoutAnimations have some drawbacks. Since the animation does not refer to a specific element on the screen, LayoutAnimations could have some weird side effects when not having complete control of when your re-renders happens. Therefore I would refrain from putting them inside useEffects with complicated dependency arrays, or inside components with many props that could trigger re-renders. Unless, of course, if you know what you are doing 🤷‍♂️

3. Animated

Even though this fade-in animation helps to ease Santas mind when looking at our large and expensive wish list, it is still kind of boring. Another drawback with LayoutAnimation is that you could only define one type of animation for the elements at a time. After all, it is just ment to automatically animate views to their new positions when the next layout happens, and not to do any super fancy stuff. And to impress Santa, we want to be a little fancy 💁‍♂️ 

If you want more control over your animations, the next step is to try Animated, which also is built into React Native. It lets you compose a set of animations that change animation values, which you attach to your components with the transform value in the style prop.

In our wish list we want to take advantage of the composability of Animated by introducing each item after one another, so that all the items is not shown at once. To make the animation more fun for Santa, we want to move the item in from the top while scaling it from zero to one. To give the animation one last touch, we want it to wiggle the item once the scaling is done. We first create one animation value each for translation, scaling and wiggle, like so:

We want to initiate the animation once the items load, so our animation composition will be placed in an useEffect, and started right away:

Our animation composition starts off with an Animated.sequence([...]), which starts its list of animations sequently, one after the other. Next we have an Animated.delay() that holds the animation still 200ms longer for each item down in our wish list. The Animated.parallel([...]) executes both the Animated.spring() and Animated.timing() simultaneously, which again scales the size of the item from 0 to 1 in 1000ms and moves its y-position from -1000 to its place. Lastly, the shake animation value is linearly driven from 0 to 1 in 1000ms.

The last step is to attach our animations values to our components with the transform value in the style prop. Both the scale and translateY are ready to be used, however the shake value needs one last adjustment. We need to transform the change in value from 0 to 1, into a change in z-rotation degrees. This is where interpolation comes in handy, as it solves this problem exactly:

Finally, all three animation values can be put into work:

You could argue that being this fancy might be to overdo it, however I think Santa will appreciate it over the simple fade-in animation 😊

4. Reanimated

In the last example, we take a look at the react-native-reanimated package. This package can do everything that Animated can, and even more, while still being notably more performant, even on low-end android devices.  

Both Animated and Reanimated are written in a declarative manner, however, Reanimated also handles interactions/interruptions in the animations directly on the ui-thread instead of having to translate over to the JS-thread. If you want to add interactions to your animations with Animated, you either have to resets the animation, or wait until the animation is finished.

To showcase the intractability of Reanimated, I have one last example in our wish list. It could often be hard to prioritize which gift you wish the most for, so in the last example we add a button that lets you rearrange the list at random by changing each items order prop-value. 

As you can see, it works in a very similar way to Animated, by declaring an animation value, declaratively changing the value (here with the withSpring method), and then creating the transform-style object to be injected to the Animated.View.

Pressing the button changes the order prop-value, which again animates the list as we expected! The beautiful thing about Reanimated is that we can interrupt the animation by pressing the button and changing the order again halfway into the animation. The library will then automatically start to animate to the new position, while keeping the items current speed in mind, so that the animation changes smoothly. Spamming the "Mix it up!" button show the items dancing around in a smooth manner, something which would not have been possible with Animated.

One last mention about Reanimated is that it couples extremely well with the react-native-gesture-handling package. Combining these two allows you too smoothly animate your components across the screen and still react to changes in gestures, like when they start or stop, or even running fine-tuned logic when the position or momentum changes.

What have we learned?

To finish this article, here is a summary of when to use each different type of animation method:

Use Lottie for static loading animations or as a fun way to indicate success (or failure)

Use LayoutAnimation to easily add simple animations to components where you know you have control over your re-renders

Use Animated to compose your own set of animations that are ment for some specific components only

Use Reanimated when your animations can be interrupted midway by the user, or if the animation is dependent on gesture handling

Now it is time for you to impress Santa with your animated wish list! 🎅

21-Dec

Today's posts

Gi et tekstlig alternativ for alt innhold!

Norsk DMARC-status

Dagens designtips

A simple diff for date/time duration changes

Boundary objects - Design for Collaboration

How to animate stuff in React Native 💫