Share
Als een front-end ontwikkelaar die het grootste deel van de tijd werkt met vooraf gedefinieerde ontwerpbestanden die door een ontwerper aan mij zijn overhandigd, word ik vaak geconfronteerd met de taak om uit te leggen wat effectief kan vertalen van Photoshop naar het web. Dit is zeker geen gemakkelijke taak, aangezien de nuances van het web steeds groter worden en het krijgen van een intuïtie voor deze mogelijkheden evenzeer in moeilijkheid groeit..
Ik vind het belangrijk om dit op tafel te leggen voor alle managers, ingenieurs en anderen die zich zorgen maken over de implementatiezijde van creativiteit: het is tijd om ontwerpers onmogelijke dingen te laten bouwen. Het wordt tijd dat we onze ontwerpers buiten de boxen (en doosmodellen) duwen die we voor hen hebben gebouwd, en dit is waarom.
Creativiteit gedijt binnen de juiste soorten grenzen; met name gedijt creativiteit binnen begripsmatige grenzen stilzwijgend vorm het creatieve artefact.
"We richten ons op mensen die van onafhankelijke films houden en in suburbane gebieden wonen" is een heel andere reeks beperkingen dan "we kunnen slechts vier grote achtergrondafbeeldingen op elke pagina gebruiken".
Terwijl de eerste de boodschap en de impact van het creatieve artefact zal vormen, vormt de tweede het artefact zelf. Als we met goede ontwerpers werken, zullen de impliciete grenzen (in plaats van de expliciete grenzen) richting geven in plaats van hinder voor het creatieve proces..
Het web van vandaag is heel anders dan het web van een maand geleden, laat staan het web van de vroege jaren 2000. Een belangrijke kracht achter deze snelle verandering is het feit dat de evolutie van webtechnologie wordt aangedreven door concurrentie om te voldoen aan de behoeften van ontwikkelaars en gebruikers.
Wat dit in de praktijk betekent, is eenvoudig: ontwikkelaars en gebruikers geven constant input aan de teams achter de ontwikkeling van browserlay-out- en rendering-engines. De belangrijkste spelers in deze arena zijn WebKit (Chrome, Safari en nu Opera), Gecko (Firefox) en Trident (IE). De eerste twee engines zijn open-source, dus verschillende varianten hiervan vinden hun weg naar de browsers die we dagelijks gebruiken. De Trident van Microsoft is closed-source. Traditioneel gezien hebben de open-source engines een snellere doorloop van feature-implementatie en meer flexibiliteit met experimentele functies, en naarmate deze functies gestandaardiseerd zijn, vinden ze hun weg naar IE.
Functiestandaardisatie wordt geïmplementeerd door middel van een "spec" en die spec wordt vaak gemaakt op basis van feedback van de community en iteratie. In feite kunt u deel uitmaken van de groepen die deze functies standaardiseren door deel te nemen aan de W3C-mailinglijsten (World-Wide Web Consortium). Door ontwerpers toe te staan dingen te verzinnen die momenteel onmogelijk zijn met webbrowsertechnologie, zullen we onvervulde behoeften in de browser van vandaag realiseren en innovatie voor morgen pushen. Die mailinglijsten zijn toegankelijk voor de gemeenschap, en zaken als doosschaduwen en Geolocation API's worden in deze threads geboren. Zonder feedback van de gemeenschap en de behoefte aan nieuwe, onmogelijke dingen, zou het web nog steeds vol geanimeerde GIF's en selectiekaders zitten. Yikes.
Het punt van goed ontworpen webartefacten is niet alleen om de ingebouwde mogelijkheden van de webbrowser te beschrijven, maar in plaats daarvan om een boodschap voldoende over te brengen en een actie aan te zetten. Waarom zou het begin van een project dan worden beperkt door iets dat niet relevant is voor het bericht of de gewenste gebruikersactie? Laat in plaats daarvan creativiteit en best practices toe om het beste scenario te definiëren - als iets was mogelijk, wat zou het beste zijn? Nadat dit is gedefinieerd, kan de engineer die het artefact van creatieve verkenning naar een bruikbare interface brengt, de onmogelijke of minder praktische functies reduceren en het beste scenario aanpassen aan de beste mogelijk scenario.
Dit kan de grenzen van het front-end ontwikkelingsproces verlengen en het is misschien geen "natuurlijk" ontwikkelingsproces. Met deze methode kan het bericht echter de baas blijven over het proces en creatieve verkenning om meer te dicteren dan een natuurlijk saaie functionaliteit.
Natuurlijk, zoals elke andere oefening, is het nodig om balans te oefenen. Als alle functies van een bepaald webartefact buiten het bereik van de mogelijkheid zijn ontworpen, zou een reductie tot iets geloofwaardig voor het web een nachtmerrie voor een ingenieur zijn. De kunst van het ontwerpen is uiteindelijk de balans van communicatie via mogelijke middelen op nieuwe en effectieve manieren.
Om een omgeving te creëren waarin de mogelijkheden op het juiste moment in het creatieve proces worden gecommuniceerd, volgt u deze eenvoudige richtlijnen.
Ontwerpers moeten altijd in iteraties werken, in open communicatie met de ontwikkelaar die aan dat project zal werken. Het is de taak van de ontwikkelaar om vragen te stellen om het plan van de ontwerper te begrijpen en om vragen over de uitvoerbaarheid te beantwoorden. Er moet op de ontwikkelaar worden benadrukt dat een moeilijk werk is geen onmogelijke baan, en dat onbekende kenmerken zijn niet onhaalbare attributen.
Wat dit in de praktijk betekent, is dat ontwikkelaars optimistisch moeten blijven over het maken van de ogenschijnlijk onmogelijke dingen die mogelijk zijn, en zich moeten onthouden van het plaatsen van beperkingen op de ideeën van de ontwerper in elke iteratie. Ze moeten echter ook bruikbare feedback kunnen geven aan ontwerpers over problemen en haalbaarheid wanneer deze bekend is. Neem de volgende voorbeelden, bijvoorbeeld:
Joe Designer:
"Ik zou graag een interface willen maken die de achtergrond dynamisch van een afbeelding van een gebruikersprofiel verwijdert en deze door een dinosaurus vervangt, zodat onze gebruikers avocado's met een dino-id hebben! En dat zou geweldig zijn."
Bob Developer:
Joe, je hebt gelijk. Het zou geweldig zijn. Natuurlijk is dit een "mogelijkheid", maar de moeilijkheid om zoiets te doen is waarschijnlijk enigszins hoog; is het de investering waard om een dino-ifier te maken, of kunnen we dino's naast hun foto laten toevoegen (wat een vergelijkbaar doel bereikt, met veel minder inspanning)?
Dit is een voorbeeld van samenwerking op het werk, en het wijst op ons volgende onderwerp.
Het balanceren van "benodigde inspanning" met "potentiële voordelen" is een belangrijke taak, vaak overgelaten aan hogere ups in bedrijven. In een snelle high-iteratieomgeving moet dit soort besluitvorming echter veel vaker gebeuren dan kan worden gedelegeerd. Het bereiken van hetzelfde doel met een parallelle oplossing die minder investeringen met zich meebrengt, is een dynamische maar belangrijke nuance die elke ontwikkelaar en ontwerper in overweging moeten nemen bij het werken aan een project.
Om dit mogelijk te maken, moeten ontwerpers en ontwikkelaars in staat worden gesteld om beslissingen te nemen, en de waarden van het project moeten volledig worden gecommuniceerd om die beslissingen goed en in volledig vertrouwen te kunnen nemen. Met andere woorden, voor Bob Developer om te weten dat de achtergrond van de Dino de ontwikkelingsinvestering niet waard is, moet hij een intuïtie hebben opgedaan voor de waarden die in het project zijn ingebed. Op dezelfde manier moet Joe Designer die waarde ook meteen kunnen begrijpen.
Met de voorgaande kennis in de hand, kunnen we vaststellen dat open communicatie een standaard moet zijn, op alle niveaus van een bepaald project. Als de ontwerper een vraag heeft of verduidelijking nodig heeft van een onderdeel van de onderliggende boodschap van een artefact, moeten deze toegang hebben tot de bronnen die nodig zijn om die vraag te beantwoorden.
Ontwerpers moeten de vrijheid en de macht hebben om enorm innovatieve beslissingen te nemen en ontwikkelaars moeten de mogelijkheid hebben om aanpassing aan projecten aan te sturen. Het cultiveren van een cultuur van creativiteit - eerst empowerment en adaptieve innovatie levert uiteindelijk meer intuïtieve teams op die effectievere webartefacten bouwen.
Accentsconagua