CMS for produsentnettsider: velg hvordan teamet skal publisere

Et CMS for produsentnettsider skal la de rette personene oppdatere informasjon korrekt, gjennomgå resultatet og publisere uten å bygge siden på nytt hver gang. Valget er en del av nettsideutviklingen: Det avgjør hva teamet kan vedlikeholde etter lansering og hvilke endringer som fortsatt trenger en utvikler.

Begynn med arbeidet, ikke en liste over plattformlogoer. En virksomhet som oppdaterer tre tjenestesider to ganger i året, har andre behov enn en leverandør med hundrevis av produktoppføringer på flere språk. Veiledningen forklarer hvordan forskjellene blir til et praktisk valggrunnlag. Den antar ikke at alle nettsteder trenger et avansert administrasjonssystem.

List opp endringene folk faktisk vil gjøre

Be salg, teknisk personell og markedsføring nevne nylige endringer som burde vært synlige på nettstedet. Eksempler er et nytt datablad, en utgått variant, et nytt bruksbilde eller en endret mottaker av forespørsler. Registrer hvem som oppdager endringen, hvem som legger den inn og hvem som godkjenner.

Skill rutinemessig redigering fra utvikling. Å bytte et produktbilde kan være redaktørens oppgave, mens et nytt sammenligningsverktøy kan kreve design og kode. Avtal skillet før systemer sammenlignes. Ellers kan «enkelt å oppdatere» bety svært forskjellige ting for kjøper og utvikler.

Bruk først planleggingsveiledningen til å fastsette sider og kjøperreiser. CMS-valget skal støtte strukturen, ikke tvinge nettstedet inn i det en tilfeldig demonstrasjon viser.

Modeller gjentakende informasjon før redaktørverktøyet velges

Avgjør hvilken informasjon som trenger en gjenbrukbar oppføring. Et produkt kan ha referanse, bruksområde, materiale, dimensjoner, bilde og gjeldende dokument. En tjenesteside kan trenge andre felt. Ha én autoritativ verdi når flere sider bruker samme faktum, med klare regler for eventuelle unntak.

Strukturerte felt kan hjelpe redaktører med å holde informasjon konsekvent, men bare når modellen passer virksomheten. Et obligatorisk tallfelt hjelper lite når en egenskap trenger et intervall eller en betingelse. Sanitys skjemadokumentasjon gir et eksempel på definisjon av dokumenttyper og felt.

Informasjon	Redigeringskrav	Demonstrasjon dere bør be om
Produktreferanse og spesifikasjoner	Navngitte felt med egnede formater	Registrere intervall, enhet og betinget merknad
Datablad brukt på flere sider	Tydelig administrert dokumentreferanse	Bytte filen og kontrollere alle berørte sider
Bruksbilde	Bilde, beskrivelse og sammenheng	Forhåndsvise ny beskjæring på telefon og datamaskin
Utgått produkt	Avtalt prosess for tilbaketrekking	Kontrollere lister, gamle lenker og erstatningsinformasjon

Produktkatalogveiledningen dekker kategorier og produktforhold slik kjøperen ser dem. Her er spørsmålet om redigeringssystemet kan vedlikeholde informasjonen uten gjentatte manuelle endringer.

Definer rettigheter for kontroll og publisering

Skriv ned hvem som kan lage utkast, kontrollere og publisere. I et lite team kan én person ha flere oppgaver, men det må fortsatt være tydelig. En teknisk kontrollør skal kunne undersøke en endring uten å forventes å konfigurere nettstedet.

Be leverandøren vise hvordan ansvaret fungerer i det faktiske oppsettet. Er kontrolltilstandene håndhevet eller bare etiketter? Kan en redaktør publisere uten godkjenning? Kan tilgangen begrenses til relevant innhold? Muligheter og begrensninger varierer med implementering og abonnement. Registrer det som er inkludert, i stedet for å anta at plattformnavnet garanterer det.

Systemet kan ikke avgjøre om en produksjonspåstand er sann. Prosessen for innholdsforberedelse og godkjenning er fortsatt ansvarlig for dokumentasjonen. CMS-et bør gjøre prosessen praktisk, med synlig ansvarlig og en måte å se hva som er endret.

Test forhåndsvisning med uferdig og vanskelig innhold

En forhåndsvisning er nyttig når den viser siden besøkende vil se. Be om en demonstrasjon med en upublisert endring, et langt produktnavn, et manglende valgfritt bilde og en spesifikasjonstabell. Undersøk smale og brede oppsett, ikke bare redaktørens skjemafelt.

Kontroller hvordan forhåndsvisningen åpnes, om det kreves en konto og om utkast holdes utenfor offentlige sider og søkeoppføringer. Tilgang til forhåndsvisning og publiseringsregler må konfigureres og testes. En «utkast»-etikett beviser ikke alene at innholdet er privat.

Spør også hva som skjer når publisering mislykkes. Kan redaktøren se om den offentlige siden ble endret? Hvem undersøker en feilet bygging eller en utdatert side? En nyttig overlevering forklarer veien fra lagring av en oppføring til den godkjente oppdateringen vises på nett.

Gjør vedlikehold av oversettelser synlig

For et flerspråklig nettsted bør én endring i kildespråket testes mot oversettelsene. Teamet skal kunne identifisere utgaver som trenger gjennomgang og unngå å erstatte oversettelser med kildetekst ved et uhell. Avtal hvilke felt som er felles, som produktreferanser, og hvilke som krever selvstendig ordlyd.

Spør om språkutgaver publiseres sammen eller separat, og hva besøkende ser mens en oversettelse venter. Dette er beslutninger om nettstedets oppførsel, ikke bare flere tekstfelt. Veiledningen om flerspråklige nettsteder dekker markedsvalg og lokalisert sidestruktur. CMS-beskrivelsen bør omsette planen til daglige redigeringsoppgaver.

Kontroller eierskap, eksport og løpende ansvar

Bekreft hvem som eier kontoen, betaler gjentakende kostnader og kan gi eller fjerne tilgang. Dokumenter ansvar for programvareoppdateringer, integrasjoner, sikkerhetskopier og gjenoppretting. En driftet tjeneste og en selvadministrert installasjon kan fordele arbeidet ulikt. Be om den faktiske fordelingen i tilbudet.

Be om et eksempel på innholdseksport. Kontroller om oppføringer, relasjoner og mediereferanser følger med i et brukbart format, og om originalfilene kan hentes ut. Eksport av innhold gjenskaper ikke automatisk nettstedets design eller funksjoner et annet sted. Registrer hva en fremtidig flytting vil kreve.

Skill førstegangsoppsett fra løpende arbeid i kostnadsvurderingen. Opplæring, ekstra redaktørtilgang, oversettelsesflyt og vedlikehold må beskrives tydelig når de påvirker avtalt omfang.

Vurder en reell produktendring

Bruk samme korte scenario for hver kandidat. I et tenkt utstyrssortiment får et produkt et revidert datablad og et nytt bruksbilde, mens en eldre variant trekkes tilbake. En redaktør forbereder endringene, en teknisk kollega gjennomgår dem, og godkjent innhold publiseres på nødvendige språk.

Kontroller under demonstrasjonen at teamet kan:

• Finne riktig oppføring uten å gjette hvilken side som inneholder originalinformasjonen.
• Se alle sider og oversettelser som berøres.
• Gjennomgå det ferdig viste resultatet før publisering.
• Forklare hvem som kan publisere og hvordan en feil ville blitt rettet.
• Bekrefte at oppdateringen er offentlig og at gammelt dokument håndteres som avtalt.
• Utføre rutineoppgavene med de foreslåtte redaktørkontoene og inkluderte funksjonene.

Velg systemet som støtter disse oppgavene med en håndterbar overlevering. Tilnærmingen vår til industrinettsteder begynner med informasjonen kjøpere trenger. Redigeringsflyten skal holde denne informasjonen pålitelig. Når dere diskuterer nettsideutvikling, ta med en eksempeloppføring, personene som skal vedlikeholde den og én faktisk oppdatering de må gjøre.