Regnskap for alle aspekter av et nytt nettsted er ikke lett, spesielt i siste øyeblikk.

Problemene er ikke detaljene selv, men prosessen med å sørge for at tilsynelatende mindre detaljer ikke legger opp til slurvet arbeid.

Den beste løsningen er å skrive det hele ned .

Den verste løsningen er å ikke ta en sjekkliste før lanseringen så alvorlig som selve planleggingsfasen.

Med de hundrevis av detaljer som går inn i å bygge eller omforme et nettsted, er det enkelt å se på mindre punkter, spesielt som tidsfrister loom-or pass. Men manglende detaljer forringer kvaliteten på et nettsted.

Kaller det kvalitetskontroll eller dekker din rumpe, men hvert prosjekt har bestemte oppgaver som må oppnås før det lanseres. Å bestemme hva som er "godt nok", er ikke noe du bør tenke på i siste øyeblikk.

En sjekkliste før lanseringen innebærer en systematisk tilnærming for å sikre at viktige detaljer tas opp før lansering eller gjenoppletting av et nettsted .

De fleste av elementene i listen over liste vil være vanlige for alle nettsteder, inkludert registrering av et domenenavn og fjerning av dummyinnhold. Ved å følge samme liste opprettes en rutine som forhåpentligvis kan forbedres med hvert prosjekt.

Ved å følge en settliste, er både designeren og klienten sikret at det ikke var noe som var viktig å antas å bli gjort, men virkelig glemt.

Hvis ikke annet, er pre-lanseringslister detaljerte versjoner av spørsmålet, "Jeg tror vi er nesten ferdige. Hva annet trenger vi å gjøre? "

Ansvarlighet, ikke sjekker

Her er et scenario. En designer er klar til å lansere et nettsted. Klienten venter på at den skal gå live. Fristen er på 30 minutter. Gjemmer seg bak "domenet har ikke forplantet" unnskyldning vil ikke vare evig, så designeren skynder seg ned i sjekklisten. Han ser ut til å huske å ha gjort disse tingene i forrige uke ... til klienten oppdager noe annet.

Ansvarlighet er heller ikke fingerpekende eller en tankeløs kontroll av ting, men heller er en bevisst påstand. Å ta deg tid til å sjekke og dobbeltsjekke at en oppgave er utført, kan være like viktig som å gjøre oppgaven i utgangspunktet.

En førsteklasses liste med industriell styrke gjør mer enn bare å minne deg om kritiske detaljer. Det holder folk ansvarlige. Det sier ikke bare at en oppgave har blitt gjort; det forteller deg hvem som fullførte det og på hvilken dato.

Det er derfor, for seriøse pre-lanseringslister, enkle kontroller er for enkle. Hvert element skal ha fire felt:

  • Oppgaven;
  • Personens initialer fullførte det;
  • Datoen den ble fullført;
  • Kommentarer.

Oppgaven beskriver hva som må gjøres, for eksempel "Kjør stavekontroll", "Tilfeldig administrasjonspassordet" eller "Registrer nettadressen med Google." Begynnelsen og datoen håndhever ansvar.

Men ikke alle oppgaver er enten komplette eller ufullstendige. Opprette en informativ 404 feilside er en ting; Å legge nyttige lenker til det er en annen. Feltet "kommentarer" gir plass for en person til å si at et element er ferdig, men kan forbedres.

Sett inn initialene dine ved siden av en oppgave som er tilstrekkelig for lanseringen, selv om den kan forbedres senere.

En vares verdi er proporsjonal med hvor mye varen brukes

Det kommer et poeng når tidsfrister, budsjetter eller andre faktorer tvinger et lag til å erklære et nettsted "godt nok".

Men hvis nettsidens kvalitet kan måles, kan det være summen av detaljoppmerksomheten og omfanget av oppgaver som ble fulgt gjennom.

Verdien av et enkelt element på en sjekkliste før lanseringen varierer. Jo nærmere tidsfristen er, desto mer trivial synes det, spesielt fordi ingen enkelt gjenstand er kritisk for prosjektets suksess eller fiasko.

Detaljer er som dollar: Hvis en favicon er verdt en krone, hvem bryr seg om å slippe den hvis du knytter $ 20 i knyttneve?

diagram som viser hvordan den virkelige betydningen av en oppgave blir tydelig som lanseringsmetoder

Nær en tidsfrist løser ukompliserte oppgaver oppmerksomhet. Diagrammet ovenfor illustrerer hvordan en oppgave sanne betydning blir tydelig: tiden klemmer ut mindre viktige elementer.

For eksempel kan validert HTML virke viktig først, men hvordan sammenligner det med å fikse siste øyeblikkdatabasefeil? Når en oppgave er ansett som "mindre viktig" innen fristen, har den en tendens til å forbli den måten.

Faren for ikke å ha kvalitetskontroll er å avvise noe som ubetydelig. Det er sant at en detalj blant mange ikke er en bekymring. Men det er ikke poenget. Poenget er prosessen med å sjekke detaljer , ikke nit-plukking om hvilke er viktige.

Å finne ut hva som er "godt nok" handler ikke om å bestemme det nøyaktige antall ting du kan gjøre uten, men heller om å forstå hvor mye du har ofret for å starte nettstedet. Hvor mye er du villig til å ofre? Hvilke detaljer er ikke viktige? Hva er bra nok?

Akkurat som sikkerhetsinspeksjoner ikke bygger hus, fyller ikke sjekklister før lanseringen nettsteder. Jo strengere de implementeres, desto bedre blir resultatet.

Elementene som er oppført nedenfor, ble valgt for deres betydning og enkel gjennomføring. Hvor godt de er utført, hvis i det hele tatt, vil gjenspeile hvor alvorlig prosjektet blir tatt.

Bygg din egen sjekkliste

Vi har gitt et eksemplar under, men den beste forhåndslanseringen sjekklisten er en som du har tilpasset deg selv.

  1. Først skriver du en liste over alt du vanligvis gjør for å forberede et nettsted, spesielt ting du gjør i siste øyeblikk, eller som du husker å gjøre etter lanseringen. Hvis du jobber med andre, gi dem tilgang til denne listen.
  2. Sett til side uavbrutt tid for å se gjennom listen. Hvis du er på et lag, ta med alle.
  3. Samle alle lister. Hver liste skal dekke en annen fase i prosjektet, fra oppfattelse til polering. For eksempel bør hosting trolig bli kjøpt mer enn en uke før lansering, men favicon kan vente.
  4. Til slutt, bruk lister. Behandle dem som hellige dokumenter. Selv om ikke alle detaljer er ferdige i tide, vil prosessen med å bruke en pre-launch-liste forbedre kvaliteten på arbeidet ditt.
tidslinje for utvikling av nettsider

Tidslinjen over er en generalisering. Den dekker grunnleggende, men ikke alle lag vil følge denne prosessen.


Dermed ville du ha fem forskjellige lister for et enkelt prosjekt:

    • Set-up , som inkluderer å kjøpe domenet og hosting plass;
    • Pre-launch hendelser , for eksempel å fjerne testdata og sikre at lagerbilder er blitt kjøpt;
    • Etter oppstartsoppgaver , som å legge til analyse og sende pressemeldinger;
    • Første og andre vurderinger , når laget tar sikkerhetskopier, endrer passord og vurderer om nettstedet fortsatt oppfyller sine mål.

      Et praktisk eksempel

      Tjeklister under forhåndsvisning sikrer nøyaktighet og ansvar ved å kreve navn og datoer , ikke bare sjekker.

      Datoer angir også hvilke elementer som må kontrolleres om endringer er gjort. Dette burde innkalle tillit til at ingenting har blitt savnet.

      Elementene i hver liste kan fullføres i hvilken som helst rekkefølge, men listerne selv er organisert kronologisk: før, straks etter og lenge etter lanseringen. Ikke alle elementer kan være aktuelle.

      For eksempel kan det hende at et nettsted ikke trenger en database eller analyse. Designeren er ansvarlig for å avgjøre hvilke elementer som er relevante for prosjektet.

      Begynner prosjektet

      Merknader Oppgave Fullført av Dato kommentarer
      Ikke kast opp åpenbare oppgaver, for eksempel å sette opp domenenavnet og hostingpakken, til siste minutt. Kjøp domenenavnet (e). _____ _____ _____
      Sett opp hosting. _____ _____ _____
      Omdirigere sitename.com til www.sitename.com (eller omvendt) for SEO _____ _____ _____
      Opprett den nødvendige e-postadressen (e). _____ _____ _____
      Sett opp databasen. _____ _____ _____
      Sett opp et testmiljø. _____ _____ _____

      Mer enn en uke før lansering

      Site-wide

      Merknader Oppgave Fullført av Dato kommentarer
      Sjekk hjemmesiden, kontaktsiden og alle sider med forskjellige maler. Oppdater nettlesere og versjoner etter behov. Å sjekke hver nettleser på hver plattform er en egen oppgave, fordi ikke alle nettlesere kan være representative for målgruppen. Se etter gjengivelsesfeil i forskjellige nettleserlayoutmotorer. Gecko-nettleser: Firefox 3.x for Mac _____ _____ _____
      Gecko-nettleser: Firefox 3.x for Windows _____ _____ _____
      Internet Explorer 7 _____ _____ _____
      Internet Explorer 8 _____ _____ _____
      Webkit: Chrome for Mac _____ _____ _____
      Webkit: Chrome for Windows _____ _____ _____
      Webkit: Safari for Mac _____ _____ _____
      Webkit: iPhone _____ _____ _____
      Presto: Opera for Windows _____ _____ _____
      Et nettsteds utseende påvirkes av størrelsen på skjermen den vises på. Selv om et nettsteds layout har en fast bredde, si 960 piksler, kan det se veldig annerledes ut på forskjellige oppløsninger. Test nettsiden på disse ulike resolusjonene. 800 x 600 _____ _____ _____
      1024 x 788 _____ _____ _____
      1280 x 1024 _____ _____ _____
      1920 x 1200 _____ _____ _____
      320 × 480 (for mobile enheter) _____ _____ _____
      Skjul bilder, grafikk, bakgrunner og styling viser hvordan søkemotorer og skjermlesere ser nettstedet ditt. For å se hvor brukbart nettstedet er (eller ikke), endre navn på bildekatalogen og CSS-filen. Test brukervennlighet uten CSS eller bilder _____ _____ _____
      Favorittikoner eller "favikoner" vises ved siden av nettadressen i de fleste nettleservinduer og bokmerker. Selv om noen nettlesere godtar PNG-filer, krever andre ICO-grafikk. Besøk Punk Labs 'ConvertIcon-tjeneste eller DynamicDrive's FavIcon Generator å lage dem. Lag et favicon. _____ _____ _____
      Ikke automatisk anta at innholdet på nettstedet ditt er unikt. Kontroller at navn og skillesetninger ikke allerede er tatt på US Patent and Trademark Office . Sjekk etter brudd på varemerker. _____ _____ _____
      Legg til en opphavsrettserklæring til sidefoten eller "Om" -siden. _____ _____ _____
      Stavekontroller alt innhold. _____ _____ _____


      Spesifikke sider

      Merknader Oppgave Fullført av Dato kommentarer
      En nyttig 404-side forteller at folk har angitt en ugyldig nettadresse og tilbyr alternative linker. Det kan inneholde et søkeverktøy for å hjelpe dem med å finne det de leter etter, og det kan automatisk varsle nettstedseieren om at noen har oppstått et problem. Om nødvendig, bruk Googles tilpassede 404 søke widget . Lag en nyttig 404-side. _____ _____ _____
      Kontroller at kontaktskjemaet fungerer, og at domenet ikke har blitt svartelistet. Send en testmelding via kontaktskjemaets skjema. _____ _____ _____
      Nettstedets formål kan være åpenbart for folk som var involvert i å skape nettsiden. Ikke anta at det er åpenbart for nykommere. Sørg for at hjemmesiden tydelig angir (enten i innholdet, oppgaveoppgaven eller tagline) nettstedets mål og hva besøkende kan forvente å få. _____ _____ _____

      48 timer før lansering

      Site-wide

      Merknader Oppgave Fullført av Dato kommentarer
      E-post er bra når det fungerer og elendig når det ikke gjør det. Sørg for at meldingene blir levert. Send en testmelding til e-postadressen (e) som er knyttet til domenet. _____ _____ _____
      Svar på testmeldingen. Kontroller at den er mottatt. _____ _____ _____
      Hvis du ikke vil at søkemotorer skal indeksere bestemte kataloger, for eksempel CMS, CGI-bin eller medlemmer-eneste seksjoner, legger du dem til robots.txt- filen. Besøk Web Roboter eller les om hvordan Google respekterer robots.txt . Lag en robots.txt- fil. _____ _____ _____


      For hver side

      Merknader Oppgave Fullført av Dato kommentarer
      Sørg for at nettstedet ditt ikke inneholder noen døde eller ugyldige lenker ved hjelp av W3C linkkontroll . Sjekk alle koblinger. _____ _____ _____
      Se etter HTML-feil Det kan forårsake visning av hikke i forskjellige nettlesere. Valider HTML-koden. _____ _____ _____
      Søk etter og fjern all gresk tekst og testdata. _____ _____ _____
      Stavekontroll igjen. _____ _____ _____
      Sørg for at hver side har et klart formål. _____ _____ _____
      Gi hver side en passende HTML-tittel og metabeskrivelse. _____ _____ _____
      Legg til alt attributter til alle bilder. _____ _____ _____
      Gjør CMS-passordet vanskelig å gjette. _____ _____ _____

      Umiddelbart etter lanseringen

      Merknader Oppgave Fullført av Dato kommentarer
      Googles verktøy for nettredaktører hjelper deg med å se hvordan Google er eller indekserer ikke nettstedet ditt, og gir informasjon om hvilke søkeord som ble brukt til å oppdage nettstedet ditt. Registrer deg for Googles verktøy for nettredaktører. _____ _____ _____
      Hvis du er bekymret for at nettleverandøren din støter på problemer, melde du på Er mine nettsteder oppe? og bli varslet når problemer oppstår. Registrer deg for oppetidskontroll. _____ _____ _____
      Spor hvem som besøker nettstedet ditt og hvordan og når de gjør det med Google Analytics , Clicky , Yahoo Analytics eller Mint . Installer et analyseprogram. _____ _____ _____
      Du trenger ikke å vente på søkemotorer for å oppdage nettstedet ditt. Fortell dem om det. Registrer nettstedet med Google . _____ _____ _____
      Registrer nettsiden med Yahoo . _____ _____ _____
      Registrer nettsiden med Bing . _____ _____ _____
      Pass på at XML nettstedskart er nåværende . _____ _____ _____
      Send inn XML-nettstedskartet til Google . _____ _____ _____

      Seks måneder etter lanseringen

      Merknader Oppgave Fullført av Dato kommentarer
      Fungerer alle som er oppført på siden "Om" eller "Stab" fortsatt der? Har telefonnummer, faksnummer, e-postadresse eller postadresse blitt endret? Kontroller at kontaktinformasjon er nøyaktige. _____ _____ _____
      Endre CMS-passordet. _____ _____ _____
      Hvis du ikke har sikkerhetskopiert nettstedet, gjør det nå. _____ _____ _____
      Sjekk etter spam sendt via skjemaer. _____ _____ _____
      Spør om nettstedet fortsatt serverer alle sine besøkende behov. Er innholdet fortsatt relevant? _____ _____ _____
      Hvilke funksjoner på nettstedet blir ikke brukt? Hva kan fjernes? _____ _____ _____
      Sjekk nettstedets analytics: hvilke nettlesere bruker de fleste besøkende? De kan ikke være det du forventer. Sjekk nettsiden på den mest brukte nettleseren og OS. _____ _____ _____


      Skrevet utelukkende for Webdesigner Depot by Ben Gremillion . Ben er en freelance webdesigner som spesialiserer seg på å løse kommunikasjonsproblemer med design.

      Følger du en sjekkliste før du starter et nytt nettsted? Vennligst del prosessen din under ...