Boekhouding voor elk aspect van een nieuwe website is niet gemakkelijk, vooral op het laatste moment.
De problemen zijn niet de details zelf, maar eerder het proces om ervoor te zorgen dat ogenschijnlijk kleine details niets toevoegen aan slordig werk.
De beste oplossing is om alles op te schrijven .
De slechtste oplossing is om een pre-launch checklist niet even serieus te nemen als de planningsfase zelf.
Met de honderden details die nodig zijn om een website te bouwen of opnieuw te ontwerpen, is het bekijken van ondergeschikte punten eenvoudig, vooral omdat deadlines opdoemen of voorbijgaan. Maar ontbrekende gegevens doen afbreuk aan de kwaliteit van een website.
Noem het kwaliteitscontrole of bedek je kont, maar elk project heeft bepaalde taken die moeten worden volbracht voordat het wordt gelanceerd. Beslissen wat goed genoeg is, is niet iets waar je op het laatste moment aan moet denken.
Een pre-lanceringscontrolelijst omvat een systematische aanpak om ervoor te zorgen dat belangrijke details worden geadresseerd voordat een website wordt gestart of opnieuw wordt opgestart .
De meeste items op de lijst met lijsten zijn voor alle websites hetzelfde, inclusief het registreren van een domeinnaam en het verwijderen van dummy-inhoud. Het volgen van dezelfde lijst creëert een routine die hopelijk met elk project kan worden verbeterd.
Door vast te houden aan een vaste lijst, zijn zowel de ontwerper als de klant ervan verzekerd dat niets van vitaal belang geacht werd te zijn gedaan, maar echt vergeten.
Als er niets anders is, zijn pre-lanceringslijsten gedetailleerde versies van de vraag: "Ik denk dat we bijna klaar zijn. Wat moeten we nog meer doen? "
Dit is een scenario. Een ontwerper is klaar om een website te lanceren. De klant wacht tot het live gaat. De deadline is over 30 minuten. Verbergen achter het 'niet-gepropageerde' domein zal niet voor altijd duren, dus de ontwerper haast zich naar beneden in zijn checklist. Hij lijkt zich te herinneren dat hij deze dingen vorige week gedaan heeft ... totdat de klant iets anders ontdekt.
Verantwoording is niet wijzen op de vinger noch een zinloze controle van items, maar is eerder een bewuste bewering. De tijd nemen om te controleren en te controleren of een taak is voltooid, kan net zo belangrijk zijn als het uitvoeren van de taak in de eerste plaats.
Een pre-lanceringslijst met industriële sterkte doet meer dan alleen herinneren aan kritieke details. Het houdt mensen verantwoordelijk. Er staat niet alleen dat een taak is uitgevoerd; het vertelt je wie het voltooid heeft en op welke datum.
Daarom zijn eenvoudige vinkjes voor serieuze pre-lanceringslijsten te gemakkelijk. Elk item zou vier velden moeten hebben:
De taak beschrijft wat moet worden gedaan, zoals "Spellingcontrole uitvoeren", "Het beheerderswachtwoord willekeurig maken" of "Registreer de URL bij Google." De initialen en datum dwingen de verantwoordelijkheid af.
Maar niet elke taak is compleet of onvolledig. Het creëren van een informatieve 404-foutpagina is één ding; er nuttige links aan toevoegen is een andere. Het veld "opmerkingen" biedt ruimte voor een persoon om te zeggen dat een item is voltooid maar kan worden verbeterd.
Zet uw initialen naast een taak die voldoende is voor de lancering, zelfs als deze later zou kunnen worden verbeterd.
Er komt een moment dat deadlines, budgetten of andere factoren een team dwingen om een website 'goed genoeg' te verklaren.
Maar als de kwaliteit van de website kan worden gemeten, kan dit de optelsom zijn van de aandacht voor detail en de mate waarin taken zijn uitgevoerd.
De waarde van een enkel item in een pre-lanceringscontrolelijst varieert. Hoe dichterbij de deadline, hoe trivaler het lijkt, vooral omdat geen enkel item van cruciaal belang is voor het succes of falen van het project.
Details zijn als dollars: als een favicon de moeite waard is, wie geeft er dan om om hem te laten vallen als je $ 20 in je vuist grijpt?
In de buurt van een deadline dringen onafgemaakte taken om aandacht. Het bovenstaande schema illustreert hoe het werkelijke belang van een taak duidelijk wordt: de tijd drukt minder belangrijke items weg.
In eerste instantie lijkt gevalideerde HTML misschien belangrijk, maar hoe verhoudt deze zich tot het oplossen van last-minute databasefouten? Als een taak op de deadline als "minder belangrijk" wordt beschouwd, is dat meestal zo.
Het gevaar van het niet hebben van kwaliteitscontrole is door alle details als onbelangrijk te verwerpen. Toegegeven, een detail van vele is geen zorg. Maar dat is niet waar het om gaat. Het gaat om het controleren van details , niet om het picken van spullen die belangrijk zijn.
Uitzoeken wat 'goed genoeg' is, gaat niet over het bepalen van het exacte aantal dingen dat je kunt doen, maar meer over het begrijpen hoeveel je hebt opgeofferd om de website te lanceren. Hoeveel wil je offeren? Welke details zijn niet belangrijk? Wat is goed genoeg?
Net zoals veiligheidsinspecties geen huizen bouwen, maken checklists vóór het starten geen complete websites. Hoe strenger ze worden geïmplementeerd, hoe beter het resultaat.
De onderstaande items zijn geselecteerd vanwege hun belang en het gemak van voltooiing. Hoe goed ze worden uitgevoerd, of helemaal niet, zal uitwijzen hoe serieus het project wordt genomen.
We hebben hieronder een voorbeeld gegeven, maar de beste pre-lanceringscontrolelijst is er een die u zelf hebt aangepast.
De tijdlijn hierboven is een generalisatie. Het behandelt de basis, maar niet elk team zal dit proces volgen.
U zou dus vijf verschillende lijsten hebben voor een enkel project:
De onderstaande pre-lanceringscontrolelijsten garanderen nauwkeurigheid en aansprakelijkheid door namen en datums te vereisen , niet alleen vinkjes.
Datums geven ook aan welke elementen opnieuw moeten worden gecontroleerd als er wijzigingen zijn aangebracht. Dit zou vertrouwen moeten wekken dat er niets is gemist.
De items in elke lijst kunnen in elke volgorde worden voltooid, maar de lijsten zelf zijn chronologisch ingedeeld: vóór, onmiddellijk na en lang na de lancering. Niet elk item kan geschikt zijn.
Een website heeft bijvoorbeeld mogelijk geen database of analyse nodig. De ontwerper is verantwoordelijk voor het bepalen welke items relevant zijn voor het project.
Notes | Taak | Afgemaakt door | Datum | Comments |
---|---|---|---|---|
Stel uiterlijke taken, zoals het opzetten van de domeinnaam en het hostingpakket, tot het laatste moment niet uit. | Koop de domeinnaam (s). | _____ | _____ | _____ |
Hosting instellen. | _____ | _____ | _____ | |
Stuur sitename.com door naar www.sitename.com (of omgekeerd) voor SEO | _____ | _____ | _____ | |
Maak het gewenste e-mailadres (sen). | _____ | _____ | _____ | |
Stel de database in. | _____ | _____ | _____ | |
Stel een testomgeving in. | _____ | _____ | _____ |
Notes | Taak | Afgemaakt door | Datum | Comments |
---|---|---|---|---|
Controleer de startpagina, contactpagina en pagina's met verschillende sjablonen. Update browsers en versies indien nodig. Het controleren van elke browser op elk platform is een aparte taak omdat niet elke browser representatief voor de doelgroep kan zijn. Zoek naar renderfouten in verschillende browserlay-outmotoren. | Gecko-browser: Firefox 3.x voor Mac | _____ | _____ | _____ |
Gekko-browser: Firefox 3.x voor Windows | _____ | _____ | _____ | |
Internet Explorer 7 | _____ | _____ | _____ | |
Internet Explorer 8 | _____ | _____ | _____ | |
Webkit: Chrome voor Mac | _____ | _____ | _____ | |
Webkit: Chrome voor Windows | _____ | _____ | _____ | |
Webkit: Safari voor Mac | _____ | _____ | _____ | |
Webkit: iPhone | _____ | _____ | _____ | |
Presto: Opera voor Windows | _____ | _____ | _____ | |
Het uiterlijk van een website wordt beïnvloed door de grootte van de monitor waarop het wordt bekeken. Zelfs als de lay-out van een website een vaste breedte heeft, zeg 960 pixels, kan deze er op verschillende resoluties heel anders uitzien. Test de website op deze verschillende resoluties. | 800 × 600 | _____ | _____ | _____ |
1024 × 788 | _____ | _____ | _____ | |
1280 × 1024 | _____ | _____ | _____ | |
1920 × 1200 | _____ | _____ | _____ | |
320 × 480 (voor mobiele apparaten) | _____ | _____ | _____ | |
Het verbergen van foto's, afbeeldingen, achtergronden en styling laat zien hoe zoekmachines en schermlezers uw website zien. Om te zien hoe bruikbaar de website is (of niet), hernoem je de afbeeldingenmap en het CSS-bestand. | Test bruikbaarheid zonder CSS of afbeeldingen | _____ | _____ | _____ |
Favoriete pictogrammen of "favicons" verschijnen naast de URL in de meeste browservensters en bladwijzers. Hoewel sommige browsers PNG-bestanden accepteren, hebben andere browsers ICO-afbeeldingen nodig. Bezoek De ConvertIcon-service van Punk Labs of FavIcon-generator van DynamicDrive om ze te maken. | Maak een favicon. | _____ | _____ | _____ |
Ga er niet automatisch van uit dat de inhoud van uw website uniek is. Controleer of de naam en onderscheidende frases nog niet zijn gemaakt in de Patent- en Merkenbureau van de Verenigde Staten . | Controleer op handelsmerkovertredingen. | _____ | _____ | _____ |
Voeg een auteursrechtverklaring toe aan de voettekst of de pagina 'Over'. | _____ | _____ | _____ | |
Spellingcontrole van alle inhoud. | _____ | _____ | _____ |
Notes | Taak | Afgemaakt door | Datum | Comments |
---|---|---|---|---|
Een handige 404-pagina vertelt mensen dat ze een ongeldige URL hebben ingevoerd en biedt alternatieve links. Het kan een zoekhulpmiddel bevatten waarmee ze kunnen vinden waarnaar ze op zoek zijn, en het kan de eigenaar van de website automatisch laten weten dat iemand een probleem heeft ondervonden. Gebruik indien nodig Google's aangepaste 404-zoekwidget . | Maak een nuttige 404-pagina. | _____ | _____ | _____ |
Zorg ervoor dat het contactformulier werkt en dat het domein niet op de zwarte lijst staat. | Stuur een testbericht via het formulier van de contactpagina. | _____ | _____ | _____ |
Het doel van de website kan voor de hand liggen voor de mensen die betrokken waren bij het maken van de website. Ga er niet vanuit dat het voor nieuwkomers vanzelfsprekend is. | Zorg ervoor dat de homepage duidelijk vermeldt (in de inhoud, de missie of de slogan) van de doelen van de website en wat bezoekers kunnen verwachten te behalen. | _____ | _____ | _____ |
Notes | Taak | Afgemaakt door | Datum | Comments |
---|---|---|---|---|
E-mail is geweldig als het werkt en waardeloos als het dat niet doet. Zorg ervoor dat berichten worden afgeleverd. | Stuur een testbericht naar het e-mailadres dat is gekoppeld aan het domein. | _____ | _____ | _____ |
Reageer op het testbericht. Zorg ervoor dat deze is ontvangen. | _____ | _____ | _____ | |
Als u niet wilt dat zoekmachines bepaalde mappen indexeren, zoals de CMS-, cgi-bin- of ledengedeelte, voegt u ze vervolgens toe aan het robots.txt- bestand. Bezoek Webrobots of lees over hoe Google respecteert robots.txt . | Maak een robots.txt- bestand. | _____ | _____ | _____ |
Notes | Taak | Afgemaakt door | Datum | Comments |
---|---|---|---|---|
Zorg ervoor dat uw website geen dode of ongeldige links bevat met behulp van de W3C-link checker . | Controleer alle links. | _____ | _____ | _____ |
Zoek naar HTML-fouten dat kan schermproblemen veroorzaken in verschillende browsers. | Valideer de HTML. | _____ | _____ | _____ |
Zoek en verwijder alle Griekse tekst- en testgegevens. | _____ | _____ | _____ | |
Spellingcontrole opnieuw. | _____ | _____ | _____ | |
Zorg ervoor dat elke pagina een duidelijk doel heeft. | _____ | _____ | _____ | |
Geef elke pagina een geschikte HTML-titel en metabeschrijving. | _____ | _____ | _____ | |
Toevoegen alt attributen voor alle afbeeldingen. | _____ | _____ | _____ | |
Maak het CMS-wachtwoord moeilijk te raden. | _____ | _____ | _____ |
Notes | Taak | Afgemaakt door | Datum | Comments |
---|---|---|---|---|
Webmasterhulpprogramma's van Google helpt u te zien hoe Google uw website wel of niet indexeert en biedt informatie over welke zoektermen werden gebruikt om uw website te ontdekken. | Meld u aan voor de Webmasterhulpprogramma's van Google. | _____ | _____ | _____ |
Als u bang bent dat uw hostingprovider problemen zal ondervinden, meldt u zich aan voor Zijn mijn sites actief? en ontvang een melding wanneer er zich problemen voordoen. | Meld u aan voor bewaking van uptime. | _____ | _____ | _____ |
Houd bij wie uw website bezoekt en hoe en wanneer ze het doen Google Analytics , Clicky , Yahoo Analytics of Munt . | Installeer een analyseprogramma. | _____ | _____ | _____ |
U hoeft niet te wachten op zoekmachines om uw website te ontdekken. Vertel ze erover. | Registreer de website bij Google . | _____ | _____ | _____ |
Registreer de website bij Yahoo . | _____ | _____ | _____ | |
Registreer de website bij Bing . | _____ | _____ | _____ | |
Zorg ervoor dat de XML-sitekaart is actueel . | _____ | _____ | _____ | |
Dien de XML-sitekaart in bij Google . | _____ | _____ | _____ |
Notes | Taak | Afgemaakt door | Datum | Comments |
---|---|---|---|---|
Heeft iedereen die vermeld staat op de pagina "Over" of "Personeel" nog steeds werk? Zijn het telefoonnummer, faxnummer, e-mailadres of postadres gewijzigd? | Zorg ervoor dat contactgegevens correct zijn. | _____ | _____ | _____ |
Wijzig het CMS-wachtwoord. | _____ | _____ | _____ | |
Als u nog geen back-up van de website hebt gemaakt, doe het dan nu. | _____ | _____ | _____ | |
Controleer op spam verzonden door formulieren. | _____ | _____ | _____ | |
Vraag of de website nog steeds aan alle behoeften van zijn bezoekers voldoet. Is de inhoud nog steeds relevant? | _____ | _____ | _____ | |
Welke functies van de website worden niet gebruikt? Wat kan worden verwijderd? | _____ | _____ | _____ | |
Controleer de analyse van de website: welke browsers gebruiken de meeste bezoekers? Ze zijn misschien niet wat je verwacht. | Controleer de website op de meest gebruikte browser en besturingssysteem. | _____ | _____ | _____ |
Exclusief geschreven voor Webdesigner Depot door Ben Gremillion . Ben is een freelance webdesigner die is gespecialiseerd in het oplossen van communicatieproblemen met design.
Volg je een checklist voordat je een nieuwe website start? Deel alstublieft uw proces hieronder ...