Monsterlijke case study

Eind januari lanceerden we de nieuwe webshop voor de babyspeciaalzaak Monsters With An Attitude. Deze webshop is, net zoals alle andere webshops & projecten die we afleveren, “tailor made” naar de noden en wensen van de klant.

Zowel de look&feel als de functionaliteit werden vastgelegd na enkele rondes feedback en aanpassingen samen met de klant. Een goed inlevingsvermogen in de business en werkwijze van de klant laat toe om het aantal iteraties tot een minimum te houden terwijl we naar een maximum aan klantentevredenheid streven.

Wie de vorige posts op deze blog gelezen heeft weet dat we bepaalde ontwikkelings- en functionaliteitsprincipes hanteren. We kunnen ze gerust “web industry best practices” noemen. Wat nu volgt is een mix van een case study en whitepaper voor een webshop.

Analyse: analyse this

PrototypingEerst en vooral hebben we de analysefase. De eerste sessies met de klant zijn eerder brainstormsessies. Alle mogelijke functionaliteiten, inclusief de toeters en bellen, die relevant kunnen zijn voor dit type project worden uitvoerig besproken. Op het einde van de analysefase leggen we samen met de klant vast wat er zal worden uitgewerkt, hoeveel dat zal kosten en hoe lang dat zal duren. Vaak wordt er op dit ogenblik beslist om bepaalde opties al dan niet meteen te nemen of te verschuiven naar een volgende fase. Dankzij deze gefaseerde aanpak kan een project geleidelijk groeien.

Heel belangrijk is dat, naast de functionaliteit, ook de business processes van de klant mee onder de loupe worden genomen.  In overleg worden scenario’s opgesteld voor de verschillende types van gebruikers (doelpubliek) die de website gaan gebruiken. Een gebruikerscenario identificeert handelingen met stappen en acties die moeten gebeuren om bepaalde doelen te kunnen bereiken.
Tijdens de analysefase staan deze gebruikerscenario’s centraal. Enerzijds bepalen ze de functionaliteit en logica. Anderzijds kunnen ze worden gebruikt ter controle of alle afgesproken functionaliteiten zijn verwerkt, maar ook of de website gebruiksvriendelijk en logisch is opgebouwd.
Uit de hele analyse vloeit uiteindelijke een prototype. Vincent had enkele posts terug over dit punt al een interessante uiteenzetting online geplaatst.

Design: het uithangbord

Tijdens de analysefase kan ook al aandacht worden besteed aan de look&feel van de webshop. Onderschat het belang hiervan niet. Een shop moet niet alleen functioneel goed werken, het moet er ook professioneel uitzien en vertrouwen wekken. Bovendien wordt de webshop het uithangbord voor de winkel. Een reden te meer om een knap en origineel design af te leveren. De klant weet op dit vlak meestal wel heel duidelijk waar hij naartoe wil. Onze designer Gert wist, zoals altijd, enkele verbluffende, toepasselijke designs uit zijn mouw te schudden.

mwaa-design-2mwaa-design-3
mwaa-design-4

Ontwikkeling: goede afspraken

Na deze eerste fases, die meestal wel parallel verlopen, start de technische ontwikkeling van de webshop. Tijdens de interne, technische kick-off meeting worden heel wat zaken besproken. We spreken goed af hoe de zaken technisch geïmplementeerd zullen worden. Doorgaans volgen nu 3 grote brokken in de ontwikkeling:

  • Back-end development: dit houdt in dat de functionaliteit en bedrijfsprocessen die eigen zijn aan de webshop in code worden vertaald. Daarbij moet er ook communicatie naar een databank of externe systemen zijn.
  • Front-end development: de design templates worden opgeknipt en vertaald naar XHTML, CSS en Javascript. Onderschat het belang van deze taak niet want hier leggen we de basis voor de Search Engine Optimalization (SEO).
  • De laatste brok is de integratie van de back-end-ontwikkeling met de front-end-ontwikkeling.

Fasering, iteratie en klantfeedback

De ontwikkeling wordt opgedeeld in fases op basis van functionaliteit. Iedere fase wordt ontwikkeld en getest voor men naar de volgende fase overstapt. Veelal steunt een latere fase op eerder ontwikkelde fases dus is het van extreem belang dat men iedere fase goed test. Unit testing is hierbij een grote hulp.

Een belangrijk voordeel van fasering is dat men op het einde van iedere fase feedback kan vragen van de klant. Zo vermijdt je eventuele “verrassingen” op het einde van de complete ontwikkelingscyclus. Betrek je klant zo snel mogelijk bij de ontwikkeling. Iedere fase waarbij men binnen een korte periode een bepaalde functionaliteit ontwikkelt, test en ter goedkeuring voorlegt aan de klant noemt men een sprint.

Best practices

Er zijn een aantal best-practices die we in de kijker willen zetten:

  • CSS sprites: we voegen een aantal afbeeldingen samen tot één afbeelding. (voorbeeld)
  • Custom fonts door gebruik te maken van Adobe Flash.
  • Search Engine Optimized (SEO) url’s & content.
  • Gebruik van Ajaxvoor het winkelmandje met als doel een betere user experience.
  • Meertaligheid. Je kunt argumenteren dat dit een functionaliteit is en geen “best practice”. Je kunt je echter geen Europese webshop inbeelden zonder. Meertaligheid is een “must”. Momenteel is de webshop van Monsters With An Attitude beschikbaar in één taal. De shop is zo ontwikkeld dat het toevoegen van extra talen slechts een administratieve kwestie is. Het leuke aan de meertaligheidsfunctie is dat wanneer men van taal verandert men op dezelfde pagina in de andere taal terecht komt. De meeste sites gaan bij het switchen van taal naar de hoofdpagina waardoor men de gebruiker verplicht om opnieuw een product of pagina te zoeken. Bij good practices hoeft dit niet. “It’s what separates the men from the boys”

Beheermodule: geen dubbel werk

Als laatste willen we je ook even laten meekijken achter de schermen want de publieke webshop is slecht de helft van de webapplicatie.

Deze beheersmodule laat toe de gegevens van klanten, producten, bestellingen en stock te beheren. Daarnaast is er ook nog volledige synchronisatie voorzien tussen de database voor de webapplicatie en de Filemaker-software in de winkel zodat de klant geen dubbel beheer moet doen voor de fysische winkel en de webshop.

De beheersmodule laat o.a. de volgende zaken toe:

  • Beheer klanten, producten, bestellingen en stockindicatie;
  • Printen BTW-listings, verkooplijsten;
  • Printen van facturen, inhoudsdocumenten, plakbonnen & transportdocumenten;
  • Printbare facturen en creditnota’s zijn PDF-documenten die dynamisch worden gegenereerd.
  • Verzenden van betalingsherinneringen.

Beheersmodule

Oh ja, de ontwikkeling gebeurde in ASP.NET. Maar dit is slechts een triviaal gegeven.

Verdere informatie over dit project kan je terugvinden op de projectpagina

E-commerce deel 2: online betalen

In een vorige blogpost rond e-commerce zagen we onder andere dat de creatie van een webshop als uitbreiding van een fysieke winkel extra uitdagingen met zich meebrengt. Vooral de synchronisatie van de stock tussen fysieke winkel en webshop was hierbij cruciaal. In deze post willen we het hebben over online betalen en het beheer van bestellingen.

online betalen

Het onveiligheidsgevoel voorbij

Hoewel online shoppen ook in België sterk in de lift zit, zijn heel wat surfers nog steeds wantrouwig om hun betaalkaart te gebruiken op het internet. Noem het een ‘onveiligheidsgevoel’, een angst voor misbruik van de kredietkaartgegevens. Online payment providers zoals Ogone garanderen de shopper een veilige transactie. De stap in de check-outprocedure waar men de kredietkaartgegevens moet ingeven, gebeurt op een beveiligde pagina van de payment provider. Bovendien is ook de beheerder van de shop zeker van de betaling. De integratie van een betaaldienst biedt dus garanties aan zowel de koper als de verkoper. Diensten als Ogone werken met maandelijkse abonnementen en een bedrag per transactie, afhankelijk van het gekozen abonnement.
Naast een abonnement bij een online payment provider moet je ook, afhankelijk van de gewenste ondersteuning, contracten afsluiten met de desbetreffende bankinstellingen of kaartsystemen zoals VISA en Mastercard.

Overschrijving

Ondanks de garanties die een online payment provider biedt, blijft betalen met een kredietkaart voor heel wat mensen nog steeds een drempel. Voor deze groep gebruikers is er toch een oplossing. Naast een online betaling met bankkaart kan een webshop immers ook aanbieden om te betalen met een overschrijving. Dit betekent dat de eigenlijke betaling van de bestelling achteraf gebeurt. De shophouder moet dus zijn uittreksels in de gaten houden om na te gaan of een klant zijn bestelling heeft betaald. De bestelde artikelen worden ondertussen wel gereserveerd voor de klant en de stock wordt navenant aangepast.

Kortingscodes/cadeaubonnen

Heel wat shops werken met kortingscodes en cadeaubonnen. Cadeaubonnen gaan altijd uit van een vast bedrag, terwijl kortingscodes zowel een vast bedrag als een percentage kunnen zijn. Beiden moeten een unieke ID hebben voor een goede werking van het systeem. Wanneer een shopper een cadeaubon gebruikt, moet het systeem achter de schermen bijhouden hoeveel deze bon waard is en hoeveel van dat bedrag overblijft na het gebruik. Bij een kortingscode wordt de korting pas zichtbaar en actief na het invoeren van de code.

In een volgende blogpost gaan we dieper in op het online beheer van bestellingen.

Enkele van onze realisaties:
- De Kleine Zebra
- Codima
- Tele Atlas
- Monsters With An Attitude

E-commerce deel 1: shop in a box?

Kort na de lancering van de webshop ‘de Kleine Zebra’, in april 2007, kregen we regelmatig een vraag binnen om een gelijkaardige shop te maken. Aangezien ‘Ik wil een shop,” een nogal vage omschrijving is, toetsen we eerst een aantal zaken af.

Fysiek en online, één shop

Om te beginnen vragen we eerst of de prospect al een winkel heeft. Een positief antwoord betekent dat men al ervaring heeft met het inkopen van producten, aanleggen en bijhouden van een stock, boekhouding enz. Dat is een enorm voordeel want voor het opstarten van een webshop zijn deze zaken vanzelfsprekend ook noodzakelijk. Het betekent ook dat wij als webbouwers onze ontwikkeling moeten afstemmen op en integreren in de bestaande businessprocessen en -software. Vooral de synchronisatie van de stock is uitermate belangrijk. De webshop kan anders nooit zekerheid bieden rond de beschikbaarheid van een product.  Zo kan iemand in de winkel een product kopen dat net online ook werd besteld. De synchronisatie met bestaande software en de integratie van de webshop in de gebruikelijke werkwijze van de uitbater vereisen een ontwikkeling op maat.

We stellen ook de vraag of de prospect de bestellingen online beheren wil via de webinterface. Het lijkt een retorische vraag, maar dat is het niet. In een sterk vereenvoudigde vorm zou je ook iedere bestelling per mail kunnen laten binnenkomen en de afhandeling offline laten gebeuren. Doorgaans kiest men voor de integratie van een online betaaldienst waardoor men de bestellingen online moet beheren. In een volgende blogpost gaan we hier dieper op in.

Magic box

Magix boxVaak leeft het idee dat een webfirma wel ergens een doos met een kant-en-klare webshop op het schap heeft. Uitpakken, installeren, ander kleurtje tegenaan gooien en klaar. Het klopt dat er standaardpakketten bestaan die toelaten om snel ‘een’ webshop online te hebben. Het prijskaartje valt meestal goed mee. De poppen gaan echter aan het dansen wanneer men het pakket wil aanpassen of uitbreiden om beter tegemoet te komen aan de eigen noden en werkwijze. Dan botst men op de onverzettelijke beperkingen van het standaardpakket. Men kan vervolgens kiezen tussen een dure modificatie of helemaal opnieuw beginnen.

Bij Marlon geloven we in de aanpak op maat. Het laat toe om een shop te ontwikkelen die volledig aansluit bij het product, de werkwijze en de andere activiteiten van de klant. We houden er ook aan om een toepassing te ontwikkelen die op ieder moment kan worden uitgebreid of aangepast. Het project kan bovendien groeien door een gefaseerde ontwikkeling.

In een volgende blogpost rond e-commerce gaan we dieper in op online betalen van bestellingen.

Enkele van onze realisaties: