Suunnittelumallit ovat yleisiä ratkaisuja yhteisiin ongelmiin. Kun lisäät liukusäätimen etusivulle, käytät suunnittelumallia. Kun joku kysyy: "Miksi keksimään pyörän?" He kannattavat suunnittelukuvion hyväksymistä.
Verkossa termi "suunnittelumallit" viittaa useimmiten ohjelmointitekniikoihin, mutta suunnittelumallit ovat myös visuaalisen suunnittelun piirissä. Ja samaan ratkaisuun liittyvän toistuvan koodausongelman ratkaiseminen on tehokas lähestymistapa, visuaalisen suunnittelun uudelleenkäyttö ei ole toivottavaa.
Suunnittelumallit ovat huomattavasti harvinaisempia tulostussuunnittelussa kuin Webissä, huolimatta siitä, että tulostusmallilla on ollut paljon kauemmin suunnitella ne. Syynä tähän on se, että web-suunnittelua ovat voimakkaasti vaikuttaneet mm. Tietorakenteet, koodaus ja käytettävyys; jotka kaikki käsittävät suunnittelumallien käytön.
Ohjelmoijat eivät arvosta omaperäisyyttä, he arvostavat tehokkaita ja tyylikkäitä ratkaisuja. Jos olet koskaan kirjoittanut PHP-tiedostossa, tiedät, että tietokannasta saatavat tiedot ovat saatavilla lukuisilla tavoilla, mutta useimmilla PHP-koodereilla on yksi koodinpätkä, jota he käyttävät kerta toisensa jälkeen. Jos olet kirjoittanut JavaScriptin, tiedät, että silmukoilla on monenlaisia tapoja, mutta yksi niistä on tehokkaampaa ja yleensä suositeltavaa. Itse asiassa useimmilla koodin toimittajilla on katkelmat toimivat juuri siksi, että ohjelmoijat käyttävät uudelleen ratkaisuja.
Suunnittelijat puolestaan arvostavat omaperäisyyttä, ja vaikka onkin totta, että jotkut suunnittelijat käyttävät suunnittelumalleja, koska heillä ei ole mielikuvitusta (tai rohkeutta) tekemään muuten, useimmat suunnittelijat yksinkertaisesti hyväksyvät kaavan, jonka on osoittautunut saavan aikaan tuloksia.
Kuitenkin suunnittelumallin käyttäminen ei ole luonnollista suunnitteluprosessille, ja siksi löydät ilmeisimpiä suunnittelumalleja, joissa koodauksella on suurempi vaikutus. Vertaa verkkosivustoja, jotka on suunniteltu mobiilisovelluksille, useimmiten näet, että ne käyttävät samoja suunnittelumalleja uudestaan: sovellus näkyy puhelimessa vasemmalle tai oikealle; puhelimen vieressä on tekstiviiva ja toimintapyyntö; tausta on näennäinen valokuva yleensä kahvilassa.
Suunnittelumallit näyttävät varmasti toimivan. Ne ovat yleissopimuksia, jotka kehittyvät ajan myötä, ja on äärimmäisen harvinaista, että suunnittelumalli on uskollinen yhdelle yksilölle. Kulttuurisen darwinismin tavoin ne mallit, jotka selviävät siihen pisteeseen, että ne ovat tunnistettavissa kuvioina, täytyy onnistua.
Suunnittelumallit ovat todennäköisesti myös yksinkertaisin menestystarina web-suunnittelija. Ne tarjoavat todistettuja ratkaisuja, että satojen, jos ei tuhannen, asiakkaat ovat jo allekirjoittaneet. Lisäksi suunnittelumalleja ei tarvitse testata beta-testejä, ne eivät tarvitse A / B-testausta, et ehkä tarvitse edes tarvitse äitiä kokeilemaan niitä, koska suunnittelumallit testataan koko verkossa päivittäin ja vain ne, jotka työskentelevät hengissä.
Suunnittelukuvion käyttäminen on luova vastine maalauksesta numeroiden mukaan.
Mutta kun suunnittelumallit (näyttävät) toimivan asiakkaille, ne eivät toimi suunnittelijoille. Suunnittelukuvion käyttäminen on luova vastine maalauksesta numeroiden mukaan. Ja jos olemme rehellisiä itsellemme, olemme tässä enemmän kuin palkkaturva. Kyllä, sinulla on vastuu asiakkaallesi parhaiden mahdollisten tulosten saavuttamiseksi, mutta sinulla on myös itsellesi vastuu. Jos et ole luova, on helpompi maksaa vuokra.
Suunnittelumallien kannattajat väittävät, että he lisäävät sitoutumista tarjoamalla loppukäyttäjälle yhteistä käyttöliittymää, jota he tuntevat, ja varmistaa, että mallilla on matala oppimiskäyrä. Se on kuitenkin vanhentunut ajattelutapa. Toki, jos luot monimutkaisen sovelluksen, jotkut yleissopimukset auttavat käyttäjiä löytämään tavan, mutta on erittäin epätodennäköistä, että suunnittelet verkkosivuja väestörakenteelle, jolla ei ole kokemusta verkosta.
Takaisin, kun Web oli uusi, oli järkevää tehdä jokainen linkki siniseksi. Se auttoi ihmisiä löytämään tavan. Yhteisten kielten yhteistä kieltä ei kuitenkaan enää tarvita, koska ymmärrämme, mistä löydämme linkkejä. Kuten todistaa se, että sinisen linkin suunnittelukuvio ei ole enää läsnä.
Suunnittelumalleja koskeva ongelma on se, että vaikka ne näyttävät toimivan lyhyellä aikavälillä, niillä on myös parasta ennen päivämäärää; ja kukaan ei tiedä mitä se on.
Suunnittelumallit kehittyvät kuten kasvisto ja eläimistö, parhaat tai ehkä kaikkein sopeutuvat ajatukset menestyvät ja lisääntyvät. Mutta kuten dinosaurukset, jotka eivät koskaan nähneet, että meteoriitti tulee, suunnittelumallit kohtaavat sukupuuttoon liittyviä tapahtumia.
Uhanalaisuuden tason tapahtuma on niin nopea muutos, että evoluutio ei ole riittävän nopea sopeutua muutokseen. T-Rex on voinut hallita köynnöksen metsiä, mutta se ei kyennyt selviytymään muutaman asteen lämpötilan muutoksesta, samoin kuin pienestä, nälkäisestä nisäkkäästä, joka kauhistui ohi sen huomaamatta.
Monien suunnittelumallien kohdalla reagoiva muotoilu oli sukupuuttoon liittyvä tapahtuma.
Mobiilisuunnittelun räjähtämiseen asti yksi käytetyimmistä kuvioista oli pyhä graalin asettelu (niin kutsuttu siksi, että sitä pidettiin ihanteellisena, mutta vaikeaa saavuttaa sillä hetkellä käytettävissä olevan CSS: n kanssa). Kun mobiilisovellus esitteli tarvetta reagoivan suunnittelun tarpeisiin, pyhä graalin asettelu hylättiin, koska vaikka ne toimivat edelleen työpöydällä, ne eivät helposti sopeudu mobiiliverkkoihin.
Ongelmia, joita suunnittelijoiden on ratkaistava, ei ole tyhjiössä. Web on jatkuvasti muuttuva ekosysteemi, jolla on ulkoisia vaikutuksia, sisäisiä paineita sekä näennäisesti satunnaisia muutoksia. Kun käytämme suunnittelumallia, ratkaisemme eilisen ongelman, jossa on eilinen ratkaisu; ja jätämme tämän päivän ongelman vastaamatta.
Ensimmäiset periaatteet ovat looginen ajattelutapa, joka vähentää jokaisen ongelman alas sellaisiin ideoihin, joita ei voida johtaa toisistaan.
Parafraasi Wikipedian ylivoimainen esimerkki: Kaikki selaimet ovat vikasietoisia; Safari on selain; Safari on buginen. Kolmas lausunto on tarpeeton, koska se voidaan päätellä kahdesta ensimmäisestä lausunnosta.
Elon Musk on ensimmäisten periaatteiden ajattelu. Viime viikko, VentureBeat raportoi että Muskin Company, SpaceX, rakensi avaruusraketin noin 2 prosenttiin tavanomaisista kustannuksista yksinkertaisesti soveltamalla ensimmäisiä periaatteita.
Kun luotat suunnittelukuvioon, jossa olet tekemässä ongelmaa, et välttämättä tarvitse ratkaista.
Ensimmäisten periaatteiden ajattelutapa on analoginen ajattelu; Suunnittelumallit ovat analoginen ajattelu. Kun luotat suunnittelukuvioon, jossa olet tekemässä ongelmaa, et välttämättä tarvitse ratkaista. Jos tyylit kaikki linkit sinisenä, ratkaiset käytettävyysongelman vuodesta 2000, mutta se on ongelma, joka tuskin on vuonna 2015.
Hyväksyessämme ensimmäisen periaatteen lähestymistavan, keskitymme asiakkaamme todellisuudessa oleviin ongelmiin ilman, että perimättäisiin toisiinsa liittyviä ongelmia, jotka muilla ihmisten suunnittelupäätöksillä ratkaistaan.
Suunnittelumallit tarjoavat tehokkaita lyhytaikaisia ratkaisuja yhteisiin ongelmiin. Kuitenkin sitä yleisempiä suunnittelumallia, sitä enemmän on olemassa, ja sitä todennäköisempää on, että se lähestyy sukupuuttoon liittyvää tapahtumaa.
Sen sijaan, että verrataan ratkaisuja ja saadaan vastauksia muiden ihmisten vastauksista, meidän on keskityttävä asiakkaidemme nykyisiin ongelmiin.
Verkko muuttuu jatkuvasti ympärillämme, ja muotoilu kehittyy edelleen. Hyväksymällä ensimmäiset periaatteet, voimme tuottaa työtä, joka on riittävän vahva selviytyä verkosta. Kuka tietää? Saatat jopa saada olla luova.