Visuaalinen muutos suunnittelujärjestelmissä

Kunnioitamme koodisovellusliittymiä. Entä väri, tyyppi ja avaruus?

Nro 4/6 vapauttavista suunnittelusarjoista:
Tulokset | Poljinnopeus | Versiot | Breaking | Riippuvuudet | Prosessi

Suunnittelujärjestelmät luovat perustason visuaalisen tyylin, joka on olennainen riippuvuus. Nämä valinnat - väri, typografia, avaruus ja muut - on määritelty vahvasti, ja niiden odotetaan muuttavan vapautumisen ennustettavasti ennustettavasti. Kun omaksija päivittää, suunnittelujärjestelmän ei pitäisi rikkoa tavaroitaan odottamatta.

Joten kysy itseltäsi ...

Voivatko käyttöönottajat päivittää pienimuotoiseen julkaisuun luottaen siihen, että heidän käyttöliittymänsä ei hajoa järjestelmän visuaalisten muutosten vuoksi?

Semanttinen versiointi (SemVer) tarjoaa selkeät kriteerit kommunikoinnin muutosten ilmoittamiseksi pääversioiden välillä käyttämällä tärkeimpiä, pienempiä ja korjaustunnuksia. Jokainen suunnittelujärjestelmä käyttää SemVer-ohjelmaa ja tarkkailee muutosta pakettien sovellusohjelmointirajapinnassa tai sovellusliittymässä. Tämä on tuttu alue kehittäjille, jotka koodaavat JavaScript-rekvisiitta ja HTML-merkintöjä. Katkaise sovellusliittymäsi, ja seuraavan version on lisättävä versio seuraavaan pääversioon, kuten 1.4.0 - 2.0.0.

Liittymän määrittäminen koostumukselliseen visuaaliseen tyyliin välttää meidät. On vaikea määritellä selkeitä, yksinkertaisia ​​sääntöjä tyylimuutosten seuraamiseksi. Järjestelmänvalmistajat pyrkivät ilmaisemaan, mitä tai miksi ”Tämän tyylin muuttaminen rikkoa adoption käyttäjän käyttöliittymän” verrattuna ”Tämän tyylin muuttaminen ei ole”. Harva järjestelmäryhmä dokumentoi tällaiset kriteerit. Kysyn ”Millaiset visuaaliset muutokset laukaisevat sinulle suurimman version?” Heidän vastauksensa: ¯ \ _ (ツ) _ / ¯.

Ehdotan tässä artikkelissa vähintään väri-, typografia- ja avaruusperusteita, jotka muodostavat muutoksen rikkomisen. Myös muita ominaisuuksia on harkittava. Suunnittelujärjestelmä voi määritellä, dokumentoida ja kommunikoida nämä kriteerit, jotta käyttöönottajat voivat päivittää julkaisun julkaisemalla varmuudella.

Breaking Color

Useimmat järjestelmätiimit tuntevat olonsa turvalliseksi pääpainikkeen taustavärin virittämisessä. Ehkä heidän motivaationsa on parantaa kontrastia yleensä valkoiseen tekstitarraan. "Tummennetaan sinivihreä hieman", he sanovat. "Parannamme nappien saavutettavissa olevaa värikontrastia AA: sta AAA: seen."

Ensisijaisen painikkeen taustavärin säätäminen

Tietysti adoptointitiimit eivät saisi ohittaa standardin mukaisen ensisijaisen painikkeen värisarjaa. Järjestelmävalinnan ohittaminen katkaisee yhteyden järjestelmään. Siinä vaiheessa adoptio on yksin. Siksi ensisijaisen painikkeen taustavärin säätäminen on turvallista, eikä se ole rikkova muutos.

Värien muuttaminen muualla saattaa kuitenkin asettaa adoptoijat vaaraan. Mieti seuraavia tilanteita.

Esimerkki: Järjestelmäteksti mukautetuilla taustoilla

Kuvittele järjestelmäryhmä, joka hienosäätää interaktiivista sinistä parantaaksesi värien kontrastia. V1.4.0: n interaktiivinen-sininen oli saatavilla valkoisella taustalla, mutta epäonnistui hiilitaustalla.

Värikontrastien tarkistaminen kontrasti-grid.eightshapes.com-sivustolla

Joten v1.5.0: lle, joukkue sääti interaktiivisen sinisen vaaleampaan, tyydyttävämpään sävyyn, joka toimi sekä valkoisella että hiilellä.

Haamanäppäimen tarran tekstin värin säätäminen ennakoimattomissa olosuhteissa

Hyväksyjä oli kuitenkin käyttänyt Ghost-painiketta kyseisestä väristä riippuen vaalean harmaalla taustalla. Järjestelmämuutoksen jälkeen tarran tekstin väri kontrastia ei voi käyttää. Järjestelmäsi rikkoi tuotteen.

Esimerkki: Järjestelmätaustat mukautetulla päällekkäisellä tekstillä

Samoin kuvittele, että järjestelmä tummentaa korttikomponentin taustaväriä. Kortin sisältöalue sisältää "turvallisen" sisältösäiliövyöhykkeen, johon omaksuttajat lisäävät mitä tahansa sisältöä ja merkintöjä.

Kortin taustavärin säätäminen, joka sallii mukautetun sisällön

Siihen oletettavasti turvalliselle vyöhykkeelle omaksija lisäsi toissijaisen tekstin, joka, vaikkakin hienovarainen kohtalaisen harmaa, läpäisi värikontrastikokeen. Järjestelmämuutoksen jälkeen värikontrasti ei ole enää käytettävissä. Järjestelmäsi rikkoi tuotteen.

Kuvittele järjestelmän pienehkö julkaisu sisältävän nämä säädöt. Taaksepäin yhteensopiva, sanoit? Ei ole riski päivittää, he luottavat? Ehei! Järjestelmäsi rikkoi tuotteensa!

Siksi arvioi muuttuneet väriominaisuudet selvittääksesi onko järjestelmä muuttunut, kuten:

  • Tekstin väri, joka saattaa esiintyä omaisijan taustavärin, kuvan tai muun tekstuurin yläpuolella.
  • taustaväri, jolle adoption tekstin väri on päällekkäin.
  • taustaväri, reunusväri, tekstin väri, ruutuvarjo tai muu ominaisuus, joka on muodostettu toisen komponentin reunan tai sisällön viereen, yläpuolelle tai alapuolelle, jotta elementtien välinen kontrasti vähenee.

Saavutettavuus veti näitä esimerkkejä. Esteettinen riski on myös siinä, että hyvää tarkoittavat järjestelmämuutokset voivat häiritä tuotesuunnittelijan saavuttamaa värikkäää harmoniaa. Värivaiheita on runsaasti käyttöliittymässä, jota järjestelmän suunnittelija ei hallitse tai jolla ei ole näkyvyyttä.

Takeaway: Aloita vaihtaminen keskusteluun värikriteerien avulla. On helpompi välittää riski, se on objektiivisesti mitattavissa ja se on sidoksissa intoa herättävään saavutettavuuteen. Muutamilla kriteereillä varustettuna voit siirtyä muihin huolenaiheisiin.

Breaking typografia (käärittämällä)

Typografia on minkä tahansa visuaalisen tyylin ydin. Joukkueet haluavat sen oikein. Ja viritettäviä valitsimia on niin paljon: kirjasinperhe, kirjasimen paino, fontin koko, tekstin muuntaminen, rivikorkeus, kirjainväli ja paljon muuta.

Kaikki kokemukset eivät vaarannu, jos järjestelmä mukauttaa typografiaa. Sisältöraskaiden kokemusten suhteen jokaisen elementin sisältö voi olla arvaamaton, eripituinen ja suunniteltu kääritmään ja reagoimaan näkymäkentän leveyden muutoksiin.

Tiheämmille rajapinnoille typografian on oltava tarkkaa. Suunnittelijat jauhavat tuntikausia hienosäätöistä typografiaa järjestämällä tarrat sopimaan pienille alueille. Jos säädät järjestelmän typografiaa, niiden elementit voivat kääntyä tai rajautua odottamattomilla tavoilla.

Esimerkki: Käärevälilehdet ovat kauheita

Kuvittele, että järjestelmäsi säätää välilehden labelfontin painoa normaalista lihavoituun.

Pienen version päivityksen jälkeen välilehdet eivät reagoi. Ei hyvä.

Laadija päivittää. Heidän nykyiset reagoimattomat välilehdet ylittävät varatun tilan, joten ne kääritään. Kamala! Järjestelmäsi rikkoi tuotteen.

Esimerkki: Kirjeväli Mayhem

Tuotemerkkiohjeet kehittyvät, mikä antaa uuden otsikkohierarkian ja tyylin. Siksi järjestelmäsi mukautuu lisäämällä kunkin otsikon kirjainväliä.

Laadija päivittää heidän tiheän, yhden sivun säteilysovelluksen, joka on käännetty 14 kielelle. Se koostuu lukemattomista ohjauspaneeleista, joista jokainen on täynnä lomakeelementtejä ja otsikoita. Ne päivitetään, ja käyttöliittymä on täynnä otsikoita, joita on ennakoimattomasti rajattu. He kutsuvat kriisikokousta. He kutsuvat taustatietojen suunnittelijoita hyvyyden vuoksi! Järjestelmäsi rikkoi tuotteensa!

Järjestelmätyyppien säätäminen voi olla vaarallista. Teille se on virkistävä typografinen kehitys, joka on levitetty vaivattomasti kirjaston yli. Heille teksti alkaa käyttäytymättömästi. He syyttävät sinua. Ehkä he liekkivät sinut # järjestelmäsuunnittelun Slack-kanavalla. Kukaan ei tarvitse sitä.

Takeaway: Ennen 1.0.0, työskentele ahkerasti kokeilemaan, tarkentaa ja viimeistellä asiakkaan monimuotoisuudelle sopivia tyyppejä. Kun 1.0.0 on kulunut, ylläpitä vakaa pohja ja harkitse muutosta varovaisesti. Harkitse vaarallisten vuorojen varaamista seuraavalle suurelle julkaisulle. Siihen asti lisää asteittain sisältämiä ominaisuuksia, kuten Pitkän muotoinen teksti-komponentti vain artikkelikopion muotoiluun.

Rajatila ja koko

Ainakin näet värin ja typografian. Tila ja koko? Niitä on vaikeampi määritellä konkreettisesti uudelleenkäytettäviksi, puhumattakaan muutosten rikkomisesta.

Kun muutat HTML-muodossa komponentin laatikkomallin ominaisuuksia - pehmustetta, reunusta, leveyttä, korkeutta, näyttöä, laatikkokoon, sijaintia, vasenta, oikeaa, ylhäältä ja alhaalta -, olet vaarassa vaikuttaa asettelukoostumukseen, joka järjestää kyseisen komponentin muiden sivuelementtien kanssa.

Esimerkki 1: Pystysuunnan etäisyyden poistaminen

Järjestelmätiimisi päättää poistaa pystysuoraan välilyöntiin sovellettavat lomakesäätimet reunan reunan muodossa. Tämä vaikuttaa ,