Iterointi WordPressin hallintanäytön suunnittelussa

Ajatus "iteratiivisesta prosessista" ei ole mikään uusi ohjelmistokehityksessä, vaan se on läsnä useissa eri menetelmissä ja todennäköisesti siksi, että se toimii hyvin erityisesti asiakaspalautteen saamisessa.

Yksi paikoista, joista pidän sitä myös hyödyllisenä, on WordPress-laajennusten hallintaliittymien rakentaminen.

Selvyyden vuoksi totean, että en ole suunnittelija, joten front-end-töiden suhteen viittaan aina tyylioppaaseen ja suunnittelijan minulle toimittamiin malleihin projektin alusta lähtien. (Mainin tämän vain, koska mielestäni se on käytäntö, jonka jokaisen, joka ei ole suunnittelija, tulisi noudattaa, mutta minä poikkean).

Mutta kun on kyse WordPressin hallintanäytöistä tai taustanäyttöistä, noudatan tiukkaa sääntöä: Varmista, että se näyttää mahdollisimman luonnolliselta.

Miten iteratiivisella kehityksellä ja WordPress-hallintaruutujen käyttöliittymällä sitten on mitään tekemistä keskenään?

WordPress-hallinnan näytön suunnittelu

Tässä artikkelissa ei puhuta asioista, joita odotetaan tietojen tallentamiseksi. Eli oletan kaiken:

• desinfiointi,
• validointi,
• nonce shekkejä,
• lupien tarkastukset,

Ja vastaavat ymmärretään ja käsitellään.

Tätä viestiä varten aion pitää asian yksinkertaisena. Oletetaan, että haluamme:

• pari tekstikenttää,
• tallennuspainike,
• nollauspainike,
• ja ehkä jotain ylimääräistä lopussa.

Miten tämä voi toteutua iteratiivisen prosessin kautta sitä suunniteltaessa?

1 Sen luonnosteleminen

Oletetaan, että työskentelet jonkin asian parissa ja suunnittelet, miltä hallinnollinen näyttö tulee näyttämään. Ottaen huomioon sen, mitä meillä oli yllä, alkuperäinen luonnos voisi ehkä näyttää tältä:

Tarpeeksi helppoa, eikö? Se edustaa sitä, mitä projektin on ylläpidettävä, ja se näyttää kaiken, mitä tarvitsemme tähän hallintaruutuun.

2 Sen rakentaminen

Kun se on koottu, sen pitäisi näyttää mahdollisimman alkuperäiseltä. Ottaen huomioon WordPressissä saatavilla olevat tyylit, on suhteellisen helppoa rakentaa tämä saatavilla olevien API:iden ja merkintöjen avulla:

Ja mitä kukin kenttä ja painike tekevät?

3 Sen jalostaminen

Tässä tulee esiin toiminnallisuuden hiominen. Esimerkiksi:

• Mielestäni Tallenna – painiketta ei pitäisi ottaa käyttöön ennen kuin vaaditut kentät on täytetty,
• Mielestäni Reset – painikkeen pitäisi tyhjentää, mitä on,
• Virheilmoituksia pitäisi olla jonkin verran, jotka kaikki kertovat, mitä meidän on tehtävä, kun jokin epäonnistuu, kun jokin ei ehkä ole oikein tai jokin on täysin väärin.

On selvää, että on paljon helpompaa puhua tästä, kun se ei viittaa tiettyyn projektiin, mutta ehkä jotkut ideat ovat sovellettavissa missä tahansa, mitä sinulla on meneillään.

Asynkroniset parannukset?

Yksi asioista, joihin olemme tottuneet puhelimiemme ja tiettyjen käyttöjärjestelmien kaltaisten laitteiden kanssa, on se, että kun vaihdamme kytkintä tai teemme pienen muutoksen, tiedot tallentuvat.

Toisin sanoen mitään vahvistusta ei tarvita (muuta kuin jotain tuhoisaa, kuten tiedoston poistamista, tietysti). Tiedot yksinkertaisesti tallennetaan ja vaihtoehto toimii.

Näemme kuitenkin edelleen paljon Tallenna – painikkeita WordPressissä, eikö niin? Entä tulojen tallentaminen Ajaxin tai muun asynkronisen menetelmän kautta? Tämä on jotain, jota en ole vielä toteuttanut, mutta olen varmasti harkinnut sitä.