Replies: 9 comments 22 replies
-
|
Godt initiativ! Synes forslaget til @Slaine2 virker bra. Liker også navngivingen. Jeg vet bredde på nettleseren ikke alltid er lik full bredde på skjerm (en desktop kan vise "mobile"), men jeg synes det er mye lettere å ha en mental modell av "mobile" og "mobile landscape" enn "2xs-device" og "xs-device" når det kommer til breakpoints 😄 |
Beta Was this translation helpful? Give feedback.
-
|
Jeg er egentlig motstander av å navngi skjermstørrelser etter enheter, men jeg er veldig enig i at det er en navnestandard som kan bli lite leselig og intuitiv. |
Beta Was this translation helpful? Give feedback.
-
|
Hva om vi klarer å holde oss til 5 forskjellige? Føler at i mange tilfeller så er 3 nok for vår løsning, men av og til mangler det et breakpoint mellom small og medium |
Beta Was this translation helpful? Give feedback.
-
Dette tenker jeg er et fint og konkret eksempel på at det er viktig å dele tidlig og dele ofte. Noen design skalerer fint ned på mobil "av seg selv" eller med etablerte regler, mens andre kan møte på problemer det ikke nødvendigvis er så lett å se om en ikke er i "modus" for det. Vi kan gjerne lage en sjekkliste for design, typ
Men jeg tviler på at det noen gang blir sånn at vi får "enveis handover" som hovedregel, hvor skisser svarer på alle spørsmål en utvikler måtte ha. Så det blir vel prinsippet da: del tidlig, del ofte. Involver en frontendutvikler, gjerne litt før du synes du er klar 😜 |
Beta Was this translation helpful? Give feedback.
-
StatistikktrådTall fra Mixpanel BM: |
Beta Was this translation helpful? Give feedback.
-
Det er verdt å tenke på at tallene her er oppløsning på skjermen, ikke på nettleservinduet. Det er nok mer relevant for laptop/desktop, men selv på iPad kan du splitte skjerm og derfor få smalere vindu. Ellers enig med @wkillerud i at både skala og navngiving ser bra ut! Edit: @joms, er statistikken deres viewport eller skjermstørrelse? Edit 2: Tror jeg misforsto forslaget litt. Hvis det er verdiene til høyre som er forslaget, tror jeg at jeg kanskje ville slått sammen de to første til et som ligger rundt 500 et sted? Oppløsingen på en iPhone 12/13 er 390px, 428px for max-variantene. Det føles litt rart å ha et breakpoint midt inni rangen av vanlige mobiloppløsninger. Hvis verdiene til høyre er ment som bredder man kan bruke som utgangspunkt for designskisser er jeg enig i dem, men breakpoints burde jo heller ligge mellom disse enn å bytte ved vanlige oppløsninger. Verdiene til venstre i forslaget er jo heller ikke en kontinuerlig skala, så jeg sliter litt med å se hva som evt. er tiltenkt som de faktiske breakpoints ut fra dem. |
Beta Was this translation helpful? Give feedback.
-
|
Ja, screen resolution er jo noe helt annet enn viewport, så den statistikken blir fort ubrukelig i dette tilfellet. Enig at løsningen var litt rar, skjønte ikke den helt selv. 320px : Mobile Har noen erfaring med å bruke responsive verdier som em/rem vs px for breakpoints? |
Beta Was this translation helpful? Give feedback.
-
|
Er det ikke litt rart å ha cutoff på 320 dersom iPhone er det? Dersom du har mobil som har mer enn 325 så vil den jo plutselig bruke 568 breakpointet. Helt enig med Pio om at vi bør ha første på 500 ish for å få med de fleste mobiler. Kommenterte lenger oppe om at jeg synes 4 eller 5 breakpoints burde holde. |
Beta Was this translation helpful? Give feedback.
-
|
Jeg skjønte ikke helt hva du mente med cutoff på 320, man kan spesifisere min 320 og max 568 for enheter mellom 320 og 568px. Jeg synes i hvertfall de 4-5 første er de viktigste, så vi kunne f.eks fjernet Desktop og evt justert verdien på Laptop. Synes de 4 første har gode verdier. |
Beta Was this translation helpful? Give feedback.
-
|
@piofinn Det er skjermstørrelsen. Det er i hvert fall sånn jeg tolker mixpanel sin dokumentasjon
|
Beta Was this translation helpful? Give feedback.
-
|
@Mikaila94 Jeg er enig med @kennidenni at det 320px-breakpointet virker litt unødvendig. Vi skal vel ikke lage løsninger for skjermer med under 320px bredde? Synes ellers at de andre virker ganske fornuftige. |
Beta Was this translation helpful? Give feedback.
-
|
NYTT FORSLAG: Løsningen til Lou var ikke det mest intutitve, så jeg har laget et forslag: 320px : Mobile (Iphone 5s) Disse representerer da breakpoints-verdiene, så for mobiltelefoner eksempelvis så kan man lage Og har noen erfaring med responsive verdier som em i breakpoints? em vs rem vs px? |
Beta Was this translation helpful? Give feedback.
-
|
Tror det er dårlig kommunikasjon som gjør dette vanskelig. Vi setter jo ikke en nedre grense, men vi vil sette en grense der den går over til neste layout når skjermen blir større. Jeg mener derfor at det skal holde med 4 eller 5 størrelser fordi den minste er alltid der dersom vi ikke spesifiserer noe størrelse. Jeg har ikke noe godt forslag på størrelser, men synes at vi bør få med de fleste mobiler, til og med nyeste iPhone 12/13 Max som har 428px inn på den minste (som Pio skrev over). Jeg føler at jeg kommer til å bruke |
Beta Was this translation helpful? Give feedback.
-
|
Jeg zooma inn i de lavere oppløsningene våre: Merk at dette er en bedriftsløsning hvor de færreste bruker mobil. Jeg tror det er lurt å ha et minstemål på hva vi skal designe for, og at dette bør være ganske lavt. Å si at om det funker på 375 så funker det på 320 mener jeg er er bakvendt. Det er mye større sjanse for at 320 funker på 375 med tanke på overflow og wrapping av innhold. |
Beta Was this translation helpful? Give feedback.
-
|
Hopper inn for å understreke (som flere andre) at vi ikke trenger å sette en nedre grense for minste layout-regime som et breakpoint. Vi trenger altså ikke et breakpoint på Ellers synes jeg nok kanskje at Edit: Legger ved en fin oversikt over iOS-oppløsninger. Men vi må huske å se på andre typer mye brukte devices også. |
Beta Was this translation helpful? Give feedback.
-
|
Tenker egentlig at disse tre breakpointsene (1024px: Tablet Landscape (Ipad mini), 1280px: Laptop, 1440px: Desktop) ligger litt tett på hverandre og at man godt kan fjerne én av dem og eventuelt legge til en større. Selv om statistikken på BM viser skjermstørrelse tenker jeg at det er et potensialet i å utnytte de større skjermstørrelsene bedre enn at 1440 er toppen. |
Beta Was this translation helpful? Give feedback.
-
|
Litt uavhengig av hvilke verdier vi lander på her, kan dette være et interessant verktøy for designerne? @Murstam @onordbo @Slaine2 https://www.figma.com/community/plugin/732240841094697441/Viewports |
Beta Was this translation helpful? Give feedback.
-
Deadline fra Forum: Vi blir enige innen fredag 10/12, deretter starter utvikling. |
Beta Was this translation helpful? Give feedback.
-
|
I en perfekt verden finnes det et enkelt svar som funker for alle scenarier hvor denne utfordringen oppstår, dessverre er det sjelden slik. I mitt hode handler dette om mer enn bare brekkpunkter. Vi må se på hvordan vi samarbeider om å lage nye ting helhetlig. Fra skissa tegnes opp, og helt frem til den er ferdigtestet og implementert. Gode forutsetninger for å skape responsive løsningerRotårsaken til dette innlegget—såvidt jeg ser det, løses ikke utelukkende ved å oppdatere et par brekkpunkter. At slike “skviste” komponenter og uheldige layouts oppstår, er ofte et resultat av mangel på kommunikasjon og enighet om design-intensjon. For å unngå dette må man sjekke skissene sine tidligere enn man er vant til, på flere størrelser enn man vanligvis gjør, som @Mikaila94 nevner—og dele tidlig og ofte med andre, som @wkillerud nevner. Når det er sagt så er det viktig at vi oppleves nogenlunde konsekvent på tvers av løsninger, men det burde være et resultat av at vi som lager løsningene har en god felles forståelse for hva en bra “fremtindsk”-brukeropplevelse skal være. For å unngå å støte på rotårsaken, må vi stille krav til hverandre på tvers av fagdisipliner. Jeg har et par tanker om hva det kan innebære, så får dere ta det med en klype salt hvis dere synes det er for polariserende: Jeg tar det for gitt at designere lager skisser på alle brekkpunktene løsningen bruker, eller er avhengig av. Hvis vi dropper dette steget, oppstår det fort unødvendige overraskelser og misforståelser i utvikling og test. Jeg tar det også for gitt utviklerne deler versjoner av implementeringen tidlig, så designere (og andre) har tid til og kan selv sjekke at design-intensjonen blir etterlevd, og kan komme med justeringer ved behov. Man kan ikke skisse opp alle tenkbare scenarier av en løsningen til enhver tid før man begynner, da hadde vi aldri fått lansert noe som helst. Og hel til slutt tar jeg det også for gitt at alle som jobber med løsningen skal ha mulighet til å teste implementeringen underveis, uavhengig av hva slags rolle man har i teamet. Ingen skal kunne slippe hendene fra rattet etter at de har laget skissen sin, skrevet koden sin, eller gjennomført testen sin. Vi lager løsninger sammen som et team, felles ansvarlighet trumfer individuelle bidrag (og forutsetter godt samarbeid og kommunikasjon). «Ekte»-responsivitet vs optimalisering for populære enheterVed å låse oss til statistikk om hva som er mye brukt nå, vingeklipper vi oss for fremtiden og skaper unødvendig forvaltning. Vi har ikke kontroll over hva slags enhet eller skjermstørrelse brukerne våre sitter på, hverken nå eller senere. Løsningene våre burde skalere uavhengig av skjermtrender. (Og basert på hva jeg leser i diskusjonen her, så virker det som datakvaliteten fra målinger om populære skjermstørrelser er ganske tvilsom å forholde seg til uansett.) Brekkpunkter (aka layout-shuffling)Når det er sagt så er det nok fortsatt greit å ha noen felles verdier å forholde seg til, ellers kan det fort oppstå forvirring rundt hvordan vi skal lage ting. Jeg er ganske usikker på hvor detaljert vi skal gå til verks her, og hvor mye Jøkul burde diktere hvordan leveranseteamene setter sammen skissene og layoutene sine, da dette som nevnt kan variere mye fra team til team. Jeg er heller ikke godt nok kjent med den tekniske siden av komponentene i Jøkul, til å kunne mene veldig mye om dette rent praktisk. I mitt hode, så har vi på et overordnet nivå helst færre brekkpunkter, enn flere. Antall brekkpunkter burde diktere hvilke skisser som skal foreligge, ellers må utviklerne gjette seg frem til hva design-intensjonen er. Definisjonen av brekkpunktene burde handle om når selve layouten skal skiftes drastisk, og jeg er tvilsom til at det er behov for mer enn fem brekkpunkter. Det høres allerede mye ut fra et designer-ståsted. Holder det ikke med tre? Small, medium og large (uavhengig av hva slags pikselverdi vi blir enige om) burde holde til å spesifisere nok spredning i layout til å dekke de fleste skjermstørrelsene. (Kanskje extra-large hvis man har sjukt store skjermer involvert i brukergruppa si?). TOO LONG DIDN’T READ 🙄Føler’n. Her er noen kulepunkter.
|
Beta Was this translation helpful? Give feedback.
-
|
Mye fornuftig her 😄 Enig i at dette også handler vel så mye om hvordan vi jobber sammen. Der har jeg inntrykk at vi for det meste er veldig flinke, men at det kanskje "glipper" av og til. Så diskusjonen her har vært en fin påminnelse, både om design, utvikling og test (*host* staging #2278 *host*). Også et godt poeng det du nevner med at vi ikke bør henge oss altfor mye opp i målinger og modeller av dings, siden de er av variabel kvalitet og endres støtt. Er vel litt det @piofinn også er inne på, med å gi oss litt slingringsmonn i de konkrete verdiene. Det er også et poeng det med å holde antall brekkpunkter lavt. Om det uansett aldri designes løsninger med ulik layout mellom en "mobil i landskapsmodus"- og en "tablet i portrett"-størrelse viewport trenger vi ikke bruke tid på å definere brekkpunkter for begge. |
Beta Was this translation helpful? Give feedback.
-
|
Hvis jeg skulle foreslå noe som helst av pikselverdier basert på litt generell synsing for når det begynner å bli luftig nok til at man kan justere layouten:
Bonus-punkt:
|
Beta Was this translation helpful? Give feedback.
-
|
Da har vi hatt en diskusjon på Teams og blitt enige. Det vi ender opp med er å justere litt på de forskjellige spennene mellom brekkpunkter, men holder oss til samme antall.
Teknisk sett betyr det en diff på konstantene i - $breakpoint--small: 768px;
- $breakpoint--medium: 992px;
- $breakpoint--large: 1200px;
- $breakpoint--xl: 1600px;
+ $breakpoint--small: 680px;
+ $breakpoint--medium: 1200px;
+ $breakpoint--large: 1600px;Hjelperene i @mixin small-device {
@media (min-width: 0) and (max-width: 679px) {
@content;
}
}
@mixin medium-device {
@media (min-width: 680px) and (max-width: 1199px) {
@content;
}
}
@mixin from-medium-device {
@media (min-width: 680px) {
@content;
}
}
@mixin large-device {
@media (min-width: 1200px) and (max-width: 1599px) {
@content;
}
}
@mixin from-large-device {
@media (min-width: 1200px) {
@content;
}
}
@mixin xl-device {
@media (min-width: 1600px) {
@content;
}
} |
Beta Was this translation helpful? Give feedback.
-
|
Bør vi tenke motsatt på variabelnavnene siden vi alltid starter på 0 og jobber oss oppover?
|
Beta Was this translation helpful? Give feedback.
-
|
Breaking into, liker det 🥷 |
Beta Was this translation helpful? Give feedback.
-
|
Går ut fra at mixin-eksemplene er for å illustrere, og at de blir implementert vha variablene? 😉 Altså: @mixin medium-device {
@media (min-width: $breakpoint--medium) and (max-width: calc($breakpoint--large - 1px)) {
@content;
}
}
@mixin from-medium-device {
@media (min-width: $breakpoint--medium) {
@content;
}
} |
Beta Was this translation helpful? Give feedback.
-
|
Det var kun illustrasjon ja :) |
Beta Was this translation helpful? Give feedback.
-
|
Glenn kom inn med en kommentar her fra sidelinjen som er verdt å ha i tankene, og det går i prinsippet på at alle står fritt til å bruke de metodene som trengs for å få layouten til å fungere godt på alle bredder. Dere er ikke låst til å bruke breakpoints fra Jøkul. Jøkul bruker dem for typografi og spacing innad i komponenter. Det er ikke en regel at dere må bruke dem (og bare dem) for å plassere komponenter og innhold på siden. Klart, det er fint om dere har et forhold til dem og naturlig at noe layout endres i takt med typografien, men om dere sliter med at en tokolonnes layout blir for trang om dere bruker Jøkul-breakpointsene, så lag noen egne som dekker behovet dere har på de enkelte sidene. |
Beta Was this translation helpful? Give feedback.
-
For utviklere som jobber med responsiv design, så er det viktig at man har breakpoints der løsningene kan bedre tilpasses til ulike skjermstørrelser. Breakpoints i dagens løsning er veldig utdatert og representerer ikke typiske skjermstørrelser som man bruker til daglig. Her er litt statistikk av ulike skjermstørrelser som brukes:
Norge: https://gs.statcounter.com/screen-resolution-stats/all/norway
Worldwide: https://gs.statcounter.com/screen-resolution-stats/mobile/worldwide
DAGENS LØSNING: Under ser der breakpoints-verdiene fra kodebasen:
Den minste breakpointen er på 768px, noe som er mye større enn en typisk mobiltelefon som f.eks iPhone 5 (320px).
NY LØSNING: @Slaine2 har laget et forslag til nye breakpoints. Kom gjerne med innspill.
Problemer med responsiv design kan oppstå så tidlig som i design-fasen. Et eksempel er løsningen på bildet under der en tabell er plassert på samme rad som teksten til høyre. Jo mindre skjermestørrelse, jo mer sannsynlig er det at den tabellen ikke kommer til å se bra ut på mobil og tablet skjermstørrelser. Dette er ikke nødvendigvis en feil og man kan sørge for at den spesifikke løsningen blir håndtert slik at visningen omorganiseres tidligere (altså før skjermbredden rekker å bli for små) ved bruk av breakpoints. Men det er i hvert fall noe både designere og utviklere burde ha i bakhodet. Jeg skjønte det slik at man kan bruke auto-layout på Figma for å se hvordan skissene ser ut, kanskje det kan hjelpe for designere. Men uansett så tenker jeg vi kan prøve å diskutere oss frem til noe lurt. Evt etablere noen prinsipper og slikt.
EDIT: Løsningen til Lou var ikke det mest intutitve, så jeg har laget et forslag:
320px : Mobile (Iphone 5s)
568px: Mobile Landscape (Iphone 5s)
768px: Tablet (Ipad mini)
1024px: Tablet Landscape (Ipad mini)
1280px: Laptop
1440px: Desktop
Disse representerer da breakpoints-verdiene, så for mobiltelefoner eksempelvis så kan man lage
en hjelpeklasse som sier min 320px og max 568px.
Og har noen erfaring med responsive verdier som em i breakpoints? em vs rem vs px?
Hva synes dere?
Beta Was this translation helpful? Give feedback.
All reactions