Vizuális törésváltás a tervező rendszerekben

Tiszteletben tartjuk a kód API-kat. De mi a helyzet a színnel, a típussal és a térrel?

A Design Systems kiadó sorozat 4. és 6. száma:
Kimenetek | Cadence | Verziók | Törés | Függőségek | Folyamat

A tervező rendszerek létrehoznak egy alapvető vizuális stílust, amely alapvető függőség. Ezeket a választásokat - szín, tipográfia, tér és még sok más - erőteljesen meghatározták, és várhatóan stabilan, kiszámíthatóan megváltoztatják a kiadást kiadással. Amikor egy alkalmazó frissít, a tervezőrendszernek nem szabad váratlanul megtörnie cuccát.

Tehát kérdezd meg magadtól ...

Tudnak-e az örökbefogadók frissíteni egy kisebb verzióra, abban a helyzetben, hogy a felhasználói felület nem szakad meg a rendszer vizuális változásai miatt?

A szemantikus verziózás (SemVer) egyértelmű kritériumokat kínál a változások közlésére a kiadások között fő, kisebb és javító megjelölések felhasználásával. Minden tervezőrendszer, amelyben találkozom, SemVer programot használ, és figyelemmel kíséri a változásokat a csomag alkalmazás-programozási felületén vagy API-ján. Ez ismerős terület a fejlesztők számára, akik JavaScript-reszelőt és HTML-jelölést kódolnak. Törje le az API-t, és a következő verziónak meg kell növelnie a verziót a következő fő kiadásra, például 1.4.0-ról 2.0.0-ra.

A kompozitív vizuális stílus felületének meghatározása elkerül minket. Nagyon nehéz egyértelmű, egyszerű szabályokat meghatározni a stílusváltozások nyomon követésére. A rendszergyártók küzdenek arról, hogy mi vagy miért „ennek a stílusnak a megváltoztatása egy befogadó felhasználói felületét” versushoz viszonyítva: „Ennek a stílusnak a megváltoztatása nem teszi meg.” Kevés rendszercsapat dokumentálja ezeket a kritériumokat. Azt kérdezem: „Milyen típusú vizuális változások kiváltják az Ön fő verzióját?” Válaszuk: ¯ \ _ (ツ) _ / ¯.

Ebben a cikkben azt javaslom, hogy legalább a szín-, tipográfia- és űrkritérium-kritériumok meghatározzák a változást. Vannak más tulajdonságok is, amelyeket figyelembe kell venni. A tervezőrendszer meghatározhatja, dokumentálhatja és közli ezeket a kritériumokat, hogy az elfogadók bizalommal frissítsék a kiadást a kiadás útján.

Breaking Color

A legtöbb rendszercsoport biztonságban érzi magát az elsődleges gomb háttér színének hangolásakor. Talán motivációjuk az, hogy javítsák a kontrasztot egy általában fehér szövegcímkével szemben. "Tegyük sötétebbé a rágcsállat" - mondják. "Javítjuk a gombok elérhető színkontrasztját AA-ról AAA-ra."

Az elsődleges gomb háttér színének beállítása

Természetesen az örökbefogadó csoportok nem szabad felülbírálni a szokásos elsődleges gomb színkészletét. A rendszerválasztás felülbírálása megszakítja a kapcsolatot a rendszerrel. Ezen a ponton az örökbefogadó a sajátja. Ezért az elsődleges gomb háttér színének árnyalata biztonságos, és nem törő változás.

A színek másutt történő megváltoztatása azonban veszélyeztetheti az örökbefogadókat. Vegye figyelembe a következő forgatókönyveket.

Példa: Rendszerszöveg egyedi háttérrel

Képzeljen el egy rendszercsoport finomhangoló interaktív kék színét a színkontraszt javítása érdekében. A v1.4.0 interaktív kék verziója fehér alapon volt elérhető, de a faszén alapon nem sikerült.

Színes kontraszt ellenőrzése a kontraszt-grid.eightshapes.com webhelyen

Tehát a v1.5.0 esetében a csapat az interaktív kék színét világosabb, telítebb hangszínre állította be, amely fehérre és faszénre egyaránt működött.

A szellemgomb címkéjének szöveges színének beállítása kiszámíthatatlan háttérrel

Azonban az örökbefogadó a Szellem gombot az adott színtől függően, világosszürke háttérrel használja. A rendszerváltás után a címke szöveges színkontrasztja elérhetetlen. A rendszer elrontotta a terméket.

Példa: Rendszer hátterek egyedi átfedéssel

Hasonlóképpen, képzelje el, hogy egy rendszer elsötétíti a kártya alkotóeleme háttérének színét. A Kártya tartalmi területe tartalmaz egy "biztonságos" tartalomtartály-zónát, ahol az elfogadók beilleszthetnek bármilyen tartalmat és jelölést.

A kártya háttérszínének módosítása, amely lehetővé teszi a tartalmazott egyedi tartalmat

A vélhetően biztonságos zónában az elfogadó másodlagos szöveget adott hozzá, amely, bár finoman mérsékelt szürke, színes színkontraszt-teszttel ment le. A rendszerváltás után a színkontraszt már nem érhető el. A rendszer elrontotta a terméket.

Képzelje el, hogy a rendszer kisebb kiadása tartalmazza ezeket a kiigazításokat. Kompatibilis, mondtad? Nincs kockázat a frissítés során, bíznak benne? Dehogy! A rendszer elrontotta a terméket!

Ezért értékelje a megváltozott színek tulajdonságait annak meghatározása érdekében, hogy megváltozott-e egy rendszer, például:

  • Szöveg színe, amely megjelenhet az örökbefogadó háttérszíne, képe vagy egyéb textúrája fölött.
  • háttér szín, amelyen az örökbefogadó szöveges színe átfedésben van.
  • háttér szín, szegélyszín, szöveg színe, doboz-árnyék vagy más tulajdonság, amely egy másik elem szélének vagy tartalmának mellé, fölé vagy alá kerül összeállítva az elemek közötti kontraszt csökkentése érdekében.

Az akadálymentesség vezette ezeket a példákat. Esztétikai kockázat is fennáll, mivel a jó szándékú rendszerváltozások megzavarhatják a termék-tervező által elért színes harmóniát. A színes interakciók száma a felhasználói felületen rengeteg, amit a rendszer tervező nem ellenőriz vagy ellenőriz.

Elvihető: kezdje megszakítani a beszélgetést a színkritériumok alapján. Könnyebb a kockázatot közvetíteni, objektíven mérhető, és megközelíthetőséghez kötődik, amely elragadja a szenvedélyeket. Néhány kritériummal felfegyverkezve tovább léphet más aggályok elé.

Breaking Typography (csomagolással)

A tipográfia minden vizuális stílus központi eleme. A csapatok azt akarják, hogy ez rendben legyen. És olyan sok tárcsát kell beállítani: betűkészlet-család, betűméret, betűméret, szöveg-átalakítás, sormagasság, betűköz és még sok más.

Nem minden tapasztalat kockáztatja megtörését, ha egy rendszer módosítja a tipográfiát. A nehéz tartalmakhoz képest minden elem tartalma kiszámíthatatlan, hosszúságú lehet, és a nézetablak szélességében bekövetkező változásokra való reagálás céljából kialakítható.

Sűrűbb interfészek esetén a tipográfia pontosnak kell lennie. A tervezők órák óta finomítják a tipográfia finomhangolását, és úgy rendezik el a címkéket, hogy illeszkedjenek a kompakt területekhez. Ha módosítja a rendszer tipográfiáját, azok elemei váratlan módon beborulhatnak vagy levághatnak.

Példa: A csomagoló lapok félelmesek

Képzelje el, hogy a rendszer beállítja a fülek labelfont súlyát normálról félkövérre.

Kisebb verziófrissítés után a nem reagáló lapok beborulnak. Nem jó.

Egy bevezető frissít. A meglévő nem reagáló lapok meghaladják a kiosztott helyet, tehát becsomagolódnak. Kísérteties! A rendszer elrontotta a terméket.

Példa: Levélközű súlyos testi sértés

A márkanév iránymutatások fejlődnek, új címsor hierarchiát és stílust eredményezve. Így a rendszer úgy adaptálódik, hogy megnöveli az egyes címsorok betűközét.

Egy bevezető frissíti a sűrű, egyoldalas, 14 nyelvre lefordított radiológiai alkalmazást, amely számtalan vezérlőpanelből áll, mindegyik kitöltve űrlapelemekkel és címsorokkal. Frissülnek, és a felhasználói felület elürül, és a fejléceket előre nem látható módon vágják le. Válsághelyzetet hívnak. A jóság kedvéért meghívják a háttér-mérnököket! A rendszer elrontotta a terméket!

A rendszer tipográfia beállítása veszélyes lehet. Neked ez egy frissítő tipográfiai fejlődés, amelyet könnyedén telepíthetnek egy könyvtárban. Nekik a szöveg rosszul viselkedik. Hibáztatnak téged. Lehet, hogy lángolnak a # rendszer-tervező Slack csatornán. Senkinek nincs szüksége erre.

Elvihető: Az 1.0.0 előtt gondosan végezzen kísérleteket, finomítsa és véglegesítse az ügyfél változatosságának megfelelő típusú stílusokat. Miután az 1.0.0 elhaladt, tartsa fenn a stabil alapot, és óvatosan fontolja meg a változást. Fontolja meg a veszélyes műszakok fenntartását a következő nagyobb kiadáshoz. Addig fokozatosan adjon hozzá tartalmazott funkciókat, mint például a Long Form Text összetevő a cikk másolatának stílusához.

Hely és méret megsemmisítése

Legalább látható a szín és a tipográfia. Hely és méret? Ezeket nehezebb meghatározni konkrétan újrafelhasználhatónak, nem is beszélve a változások megfigyeléséről.

A HTML-ben, ha megváltoztatja az összetevő dobozmodell tulajdonságait - párnázat, margó, szélesség, magasság, megjelenítés, dobozméret, helyzet, bal, jobb, felső, alsó -, akkor kockáztathatja, hogy befolyásolja az elrendezés összetételét, amely az összetevőt más oldal elemekkel rendezi.

1. példa: A függőleges távolság eltávolítása

Rendszercsoportja úgy dönt, hogy eltávolítja a függőleges távolságra alkalmazott űrlapavezérlőket a margó alján. Ez befolyásolja a , , , a mikrokópia és egyéb elemeket.

Az eredetileg beépített függőleges távolsággal beállított rendszer eltávolítja a margókat. És így a formák simultak.

Az örökbefogadó 38 különféle formát fektetett le, támaszkodva erre a távolságra. A rendszerváltás után minden formájuk nem függőlegesen válik szét egymástól. A rendszer elrontotta a terméket.

2. példa: Egyedi méret a feltételezett távolság alapján

A tervező közösséggel folytatott széles körű vita után a rendszer beleegyezik abba, hogy kibővítse a Kártya tartalomblokkjának kitöltését.

Az egyedi ikon eszköztár a párnázás megváltoztatása után kerül becsomagolásra. Ewww.

Egy örökbefogadó elrendezte és méretezte a kártyákat az ügyfelek hardverbeállításainak alapján. Az alsó sorba csak ikont tartalmazó eszköztárat is hozzáadtak. A rendszerváltás után az ikonok két sorba vonódnak. A rendszer elrontotta a terméket.

Elvihető: Először kerülje a térbeli szabályokat (általában margót) az alkotóelem határain kívül. Másodszor, nagyon, nagyon óvatosan végezzen térbeli kiigazításokat. Az örökbefogadó elrendezésének romlása egy biztos módszer a súrlódás létrehozására, a bizalom csökkentésére, és igazolható rossz PR-hez vezetni egy közösségben.

Tartalmazott, nem feltörő térbeli változás

Egyes térbeli változások nem befolyásolják a szomszédos elemeket vagy az oldal összetételét. Például a beillesztés vagy a halmozott margó szűkítése vagy kibővítése a menüpontok között nem lenne törésváltás, mivel ezek a kiigazítások egy olyan blokkban vannak, amelyet a rendszer teljesen megad, nem tartalmaz más testreszabható elemeket, és rétegzett módon ami egyébként nem befolyásolja az oldal elrendezését nyitva és bezárva.

Melyik más képes megtörni a vizuális stílust?

A vizuális stílus változása általában a CSS tulajdonságainak változásaként határozható meg, amelyek tartományát a Salesforce Lightning, a Morningstar, a REI és az Open Table design tokengyűjteményei szemléltetik.

Milyen további tulajdonságokat lehet a fentiekben leírt szín, tipográfia, tér és méret tulajdonságain kívül megfigyelni? Az elrendezés harmadik, rétegelt dimenziójában az összetevők középpontjában a z-index, például a Popovers, Dialogs, Modals és Tooltips, alkalmazandó. a félig átlátszó rétegekben (például egy modál alatt) széles körben alkalmazott átlátszatlanság szintén erős jelöltnek tűnik. Még az olyan finom változások is, mint a határ menti fenék, hatással vannak.

Egy komponens szegélyének színei az egyéb alkatrészek közelében elrendezve
  • A rendszer átláthatóvá teszi a függőleges lista utolsó elemének szegélyét. Egy örökbefogadó helyesen helyezte el a listát egy másik blokk fölé, és a vonalra támaszkodva kontrasztot hozott létre. A rendszerváltás után a blokk fejléce összekeveredik a lista utolsó elemének címkéjével oly módon, hogy ne lehessen különbséget tenni.
    Ha igen, akkor a rendszer elrontotta a terméket.

De mi lenne a doboz-árnyék beállításával? Vagy a határ-sugár finomhangolása? Dákótervező ambivalencia. Nehéz meggyőzni arról, hogy ezek a kiigazítások megsemmisítik az örökbefogadó tapasztalatait.

Elvihető: Tekintse át a CSS-tulajdonságok hatalmas gyűjteményét, és beszélje meg csapatával a jelölt tulajdonságok következményeit. A munkamenet eredményesen feltárja a csoport toleranciáját az örökbefogadók védelme iránt, és arra törekszik, hogy dokumentálja, milyen messzire megy.

Szóval, mi a vizuális törésváltás?

Ezen a ponton gondolkodik: tényleg számít ez? Nem kellene a rendszerünkkel ellenőriznünk a vizuális nyelvünket? Az örökbefogadók valóban ápolják?

A mérnökök érdekelhetnek. A tervezők VÉGLEGES gondozása. Órákat töltenek az elrendezések finomhangolásakor, kommentálva és kommunikálva a részletekkel az együttműködő fejlesztők számára. Ezért egy tervezőrendszernek leírnia kell, hogyan változik. És minden alkalommal megváltozik, ha olyan változás lesz, amely rontja a kialakításukat.

A tervezőrendszer kollégáival folytatott beszélgetések során az érzelmek a következők:

"Valahogy tudjuk, mi a vizuális törésváltás."
"A vizuális törés megváltoztatásáról akkor beszélünk, amikor valaki ösztöne azt sugallja."
"Egyetértek azzal, hogy ez egy dolog, nem tennénk szigorúan, és ez fontos."

A Morningstar Design System munkáján dokumentáltuk, hogy mely változásokat tekintjük jelentõsnek, kisebb jelentõségûnek és javításnak. Csapatunk bizalmasan állítja ki véleményét a kritikával kapcsolatos megbeszélések során, a pull kérésekkel kapcsolatos megjegyzésekkel, valamint az örökbefogadó és továbbfejlesztő csapatokkal folytatott megbeszéléseink során.

Terepünk alkalmazkodni fog a verziózáshoz, mivel gyakorlatunkban mélyen beágyazódik. Megteszünk minden tőlünk telhetőt, hogy jól kommunikáljunk és védjük az örökbefogadóinkat.

# 3. Verzió ← Előző | Következő → # 5. Dependencies