|
Velen van jullie hebben coole productlandingspagina’s gezien waar de telefoon draait, inzoomt en de paginacode niet eerst de frontend laat vervelen, en daarna de laptopprocessor. Om zo’n site te maken, heb je een taak en een goed ontwikkeld team nodig. Meestal bestellen we sites van een ander type: een bedrijfssite, een jaarverslag of een landingspagina voor een dienst. En er zijn geen fysieke objecten, niets om te laten zien. Dus dit zou allemaal in de plannen blijven, maar toen kwamen de sterren samen. Eerst hebben we een set bedacht die we zelf leuk vinden. Dit is het perfecte product voor een site als deze. En toen kwam quarantaine, lopende projecten vertraagd, de lancering van nieuwe werd voor onbepaalde tijd uitgesteld. Er is een gratis team verschenen. We hebben twee maanden gewerkt en een promosite gemaakt. Waarom is alles zo ingewikkeld? Of wie heeft er een landingspagina zoals die van Apple nodig als je geen Apple bent? We zijn dit project voor onszelf begonnen om de technologie uit te werken. Tijdens het werk dacht ik na over wat voor soort bedrijf het nodig zou kunnen hebben. Zo’n site is perfect als u een batch product heeft dat in één keer en veel moet worden verkocht. Vooral als het product complex is, moet u gebruikers van tevoren vertrouwd maken met de functies, het ontwerp laten zien. In het formaat van zo’n site weet de gebruiker van tevoren bijna evenveel over het product als de verkoper. Hij bekeek het product van alle kanten en raakte het bijna aan. Als u een technisch complex product heeft, kunt u dit ter plaatse demonteren en monteren. U kunt het ontwerp van een limited edition sneaker of het productieproces laten zien. Het is ideaal om van tevoren te lanceren, een releasedatum vast te stellen en marketingtools te gebruiken om biedingen te verzamelen. Tegen de tijd dat het product wordt vrijgegeven, kan de hele batch binnen een paar minuten worden verkocht. Het is beter om van tevoren te beginnen, omdat de ontwikkeling van een dergelijke bestemmingspagina een periode van drie maanden of langer zou moeten duren. Hoe heb je het gedaan? De moeilijkheid van dergelijk werk is de combinatie van verschillende technologieën. Scripting, 3D-graphics, animatie, bewerking en complexe frontend. En dit alles moet met twee worden vermenigvuldigd, omdat de desktop- en mobiele versies erg verschillen. Daarom hebben we besloten dat we het resultaat zo snel mogelijk in de browser moeten zien om te begrijpen of we daar naartoe gaan of niet. Slijp niet alles opeenvolgend – eerst het model, materialen, belichting, texturen, animatieposities, CSS, JS, etc., maar doe alles snel in conceptvorm en verfijn het dan. Het voordeel van deze methode is dat je snel de werkfasen ziet die maximale aandacht vereisen, het is onmogelijk om een week aan iets te werken dat later niet zal worden gebruikt. De keerzijde is dat het hele project eruitziet als een stel krukken, er is niet één onderdeel waar je van kunt genieten, alles is ergens fout en niet goed. Is het mogelijk in meer detail? We hebben een ruw model en animaties gemaakt in Cinema 4D en vervolgens een prototype van de site in After Effects samengesteld. AE is een video-effectenprogramma, het bouwen van een website daar is ongebruikelijk, maar het blijkt geen saai prototype te zijn, maar een gaaf videoverhaal. Eerst wilden we een lay-out in Webflow maken. Maar we realiseerden ons al snel dat zelfs als we zo’n site met een heleboel grafische afbeeldingen zouden samenstellen, we deze zeker niet naar behoefte zouden configureren en overschakelden op handmatige ontwikkeling. Er waren twee technisch moeilijke momenten – binden aan de scroll en het laden van grote afbeeldingen. Elke pagina van de site wordt opeenvolgend door de browser uitgevoerd, van boven naar beneden. Zodat bij het scrollen de site niet vastloopt en de browser complexe grafische afbeeldingen berekent, wordt de verwerking van signalen van de scroll verplaatst naar een afzonderlijke datastroom. Het bleek dat de animatie op de pagina te snel naar het einde kon worden gescrold. En we hoefden alleen de scrolsnelheid voor onze animatie aan te passen, dus de scrollcontroller van het systeem was hier niet geschikt voor. We schreven onze eigen scroll-signaal-handler en lanceerden deze met de vereiste snelheid. Met veel graphics helpen de preloader in het begin en de krachtige instellingen voor de picture tag om ermee om te gaan. Terwijl u aan het begin de labels leest, downloadt de browser alle animaties. En om niet in elk geval een grote afbeelding weer te geven, controleert de browser de schermgrootte en resolutie voordat deze wordt geladen. En het haalt de geoptimaliseerde afbeeldingen van de vereiste grootte tevoorschijn vanwege de afbeeldingstag, waarin de standaard img is verpakt. Niet zomaar img, zoals gewoonlijk. Terwijl het skelet van de site werd voorbereid, was het nodig om de definitieve grafische weergave voor te bereiden. Hier werd een significant nadeel van de startup-benadering van het werk onthuld. We werkten aan het kevermodel en de materialen in één bioscoopbestand, en de animatie werd opgesplitst in verschillende bestanden. Dat wil zeggen dat na uitwerking alle materialen, belichting en texturen moesten worden overgebracht naar tien verschillende bestanden. We vergaten natuurlijk meerdere keren materiaal of lichtbron over te zetten en moesten het opnieuw lezen. Een laatste frame met schaduwen en goede verlichting op een laptop werd ongeveer 10 minuten weergegeven, in totaal waren er ongeveer 1000 frames op de site. Dat wil zeggen, alle animatie op één computer zou ongeveer een week duren, rekening houdend met de instellingen. We hebben dit probleem zo opgelost. We zijn gestopt met het tellen van alles op onze computers en hebben scènes voor weergave naar een cloud-renderfarm gestuurd. Ja, dit zijn extra kosten, maar de tijd was duurder. De kosten van de fout zijn aanzienlijk gedaald, het werd mogelijk om te experimenteren met de instellingen voor materialen en verlichting. Toen we de graphics hadden uitgezocht en de laatste sequenties hadden voorbereid, begonnen we ons bezig te houden met de lay-out. Om de lay-out gemakkelijker te maken, hebben we de schermen natuurlijk verplaatst van AE naar Figma. Maar bij de eerste versie van de site zagen we problemen met aanpassingsvermogen, we moesten terug naar Webflow, daar schermen inrichten, aanpassingsvermogen controleren en het in de vorm van code aan de programmeur geven. Om aan dit project te werken, hebben we een maand hard gewerkt met een team van drie mensen. Niet slecht voor een project.
Neem contact met ons op en we bespreken verschillende mogelijkheden. E-mail: info@webdevelopmentapp.com |
| https://webdevelopmentapp.com/nl/prices.html |
