Custom CMS za veliki katalog ili direktorijum: model podataka i filteri

Kod velikog kataloga ili direktorijuma najvažnija odluka nije kako izgleda jedna kartica, već kako su podaci međusobno povezani. Ako su kategorije, lokacije, atributi, statusi i odnosi između zapisa loše modelovani, svaki novi filter postaje ručna dorada, a svaka promena taksonomije rizikuje netačne rezultate.

Zato custom CMS za katalog ili direktorijum treba posmatrati kao sistem za upravljanje strukturisanim podacima, a ne samo kao administrativni panel za unos sadržaja. Dobar model odvaja ono što je entitet od njegovih osobina, omogućava kontrolisano filtriranje i jasno definiše koje stranice, URL-ovi i kombinacije filtera uopšte treba da postoje.

Šta katalog ili direktorijum čini tehnički zahtevnim

Mali katalog može da funkcioniše sa nekoliko kategorija i jednostavnom pretragom. Veliki sistem obično ima više tipova zapisa, veliki broj vrednosti atributa, različite odnose između entiteta i pravila koja zavise od konteksta. Primer može biti direktorijum firmi, dobavljača, stručnjaka, lokacija, proizvoda ili usluga.

Jedan zapis može istovremeno pripadati:

• jednoj ili više kategorija,
• jednom gradu, regionu ili hijerarhiji lokacija,
• više grupa atributa,
• određenom statusu ili tipu članstva,
• jednom ili više povezanih zapisa.

Problem nastaje kada se sve ove informacije čuvaju kao slobodan tekst ili kao niz nepovezanih polja. Tada nazivi nisu ujednačeni, filteri daju nepotpune rezultate, a urednik nema jasna pravila za unos. Model podataka treba da uvede strukturu pre nego što se naprave korisnički interfejs i vizuelne komponente.

Osnovni model podataka: entiteti, atributi i odnosi

1. Glavni entitet mora imati jasnu granicu

Prvi korak je definisanje glavnog zapisa. U direktorijumu firmi to može biti organizacija, u katalogu nekretnina oglas ili objekat, a u stručnom direktorijumu profil stručnjaka. Glavni entitet ne treba mešati sa svim informacijama koje se prikazuju na stranici.

Na primer, zapis „firma“ može imati naziv, opis, kontakt, status i datum izmene, dok su lokacija, industrija, sertifikati i usluge povezani podaci ili kontrolisane vrednosti. Ovakvo razdvajanje olakšava promenu dizajna, ponovnu upotrebu podataka i izradu različitih prikaza istog zapisa.

2. Razlikujte fiksna polja od taksonomija

Fiksno polje je vrednost koja pripada svakom zapisu i ima stabilno značenje, na primer naziv, osnovni opis ili status objave. Taksonomija predstavlja uređenu grupu pojmova koji se mogu koristiti za klasifikaciju: kategorije, tipovi usluga, industrije ili lokacije.

Taksonomije treba da imaju sopstveni identitet, naziv, slug, roditeljski pojam kada postoji hijerarhija i pravila za prikaz. Nemojte čuvati „Beograd, Novi Sad“ kao jedan tekstualni niz ako će korisnik po tim gradovima filtrirati rezultate. Svaka vrednost koju korisnik bira, grupiše ili pretražuje najčešće zaslužuje strukturisano polje ili povezani entitet.

3. Predvidite odnose između zapisa

Direktorijumi često nisu skup izolovanih profila. Firma može imati više lokacija, proizvod može pripadati brendu, lekar može biti povezan sa ustanovom, a usluga sa više kategorija. Ovi odnosi treba da budu eksplicitni.

• Jedan-prema-jedan: jedan zapis ima jednu specifičnu povezanu vrednost.
• Jedan-prema-više: jedna organizacija ima više lokacija ili poslovnica.
• Više-prema-više: jedan zapis pripada većem broju kategorija ili nudi više usluga.
• Hijerarhijski odnos: region sadrži gradove, a kategorija podkategorije.

Jasno definisani odnosi sprečavaju dupliranje podataka. Ako se naziv grada promeni, bolje je izmeniti jedno mesto u taksonomiji nego tražiti sve tekstualne varijante kroz stotine zapisa.

Kako projektovati filtere koji daju očekivane rezultate

Filter nije samo element interfejsa. On je poslovno pravilo koje mora da odgovara modelu podataka, upitu nad bazom i načinu na koji korisnik razume katalog.

Filteri moraju imati definisano značenje

Pre izrade filtera napišite šta svaki od njih radi. Ako korisnik izabere „Beograd“ i „konsalting“, da li rezultat mora da zadovolji oba uslova ili je dovoljno da zadovolji jedan? Uobičajen obrazac je da se vrednosti iz različitih grupa kombinuju logikom AND, dok se više izabranih vrednosti unutar iste grupe kombinuje logikom OR. Ipak, to nije univerzalno pravilo i mora biti potvrđeno prema konkretnom katalogu.

Primer:

• Lokacija: Beograd AND kategorija: pravne usluge
• Kategorija: knjigovodstvo OR poresko savetovanje
• Jezik: srpski AND status: aktivan

Ovo treba testirati na stvarnim kombinacijama, uključujući slučaj kada nema rezultata. Poruka „Nema rezultata“ korisnija je ako korisniku ponudi da ukloni poslednji filter ili prikaže sličnu širu kategoriju.

Izaberite tip filtera prema prirodi podatka

Ne treba svako polje pretvoriti u filter. Ako se vrednost pojavljuje samo kod malog broja zapisa, ako nije dovoljno pouzdana ili korisnik ne razmišlja u tom terminu, filter može da napravi više zabune nego koristi.

Kontrolisane vrednosti su važnije od slobodnog unosa

Polje za slobodan unos omogućava varijante poput „IT“, „IT sektor“, „informacione tehnologije“ i „tehnologija“. Za prikaz ili pretragu takvih podataka bolji su unapred definisani pojmovi, uz mogućnost da administrator njima upravlja.

Slobodan tekst i dalje ima svoje mesto: opis profila, dodatne napomene i sadržaj koji se pretražuje punim tekstom. Međutim, vrednosti koje upravljaju filtriranjem, grupisanjem ili URL strukturom treba standardizovati.

Filteri, URL-ovi i indeksiranje stranica

Veliki broj kombinacija filtera može da proizvede veliki broj URL-ova. To nije razlog da svaka kombinacija automatski postane posebna indeksabilna stranica. Pre implementacije treba razdvojiti tri slučaja:

1. Interaktivno filtriranje: korisnik sužava rezultate na jednoj stranici, bez potrebe da ta kombinacija bude posebna odredišna stranica.
2. Stabilna kategorijska stranica: važna kombinacija ima sopstveni sadržaj, naslov, opis i uređenu listu rezultata.
3. Privremena ili nepoželjna kombinacija: rezultat je koristan u interfejsu, ali ne treba da bude deo javne informacione arhitekture.

Odluka o indeksiranju treba da zavisi od uredničke vrednosti i stabilnosti skupa rezultata, a ne od toga koliko lako CMS može da generiše URL. Ako se za svaku kombinaciju automatski stvaraju stranice bez dovoljno jedinstvenog sadržaja, nastaje nepregledna struktura i rizik od stranica male vrednosti.

Za detaljniji pristup skaliranju takvih stranica pogledajte vodič Programmatic SEO u custom CMS-u: kako skalirati stranice bez thin content-a. Njegov fokus je upravo na kriterijumima za izbor stranica koje imaju smisla kao zasebne destinacije.

Administracija velikog kataloga: unos, izmene i kontrola kvaliteta

Model koji izgleda uredno na papiru može biti težak za svakodnevni rad. Administratoru treba omogućiti da razume koje podatke unosi, šta je obavezno, koje vrednosti su dozvoljene i kako će zapis biti prikazan nakon objave.

Korisne kontrole uključuju:

• obavezna polja samo tamo gde su zaista neophodna,
• validaciju formata telefona, e-mail adrese, URL-a i numeričkih vrednosti,
• pretragu postojećih taksonomija umesto ručnog upisivanja,
• upozorenje na moguće duplikate,
• status zapisa: nacrt, u proveri, objavljen ili arhiviran,
• datum poslednje izmene i informaciju o odgovornom uredniku,
• grupisanje polja prema logici rada, a ne prema tehničkoj strukturi baze.

Kada više ljudi radi sa katalogom, treba definisati ko unosi podatke, ko ih proverava i ko može da objavi izmene. Više o tome možete pročitati u tekstu Uloge i dozvole u CMS-u: kako organizovati editor, reviewer i administrator pristup.

Za kataloge sa formalnim procesom odobravanja koristan je i editorial workflow: draft, review i approval u custom CMS-u. Važno je da status u administraciji bude povezan sa pravilima prikaza na javnom delu: zapis u proveri ne treba slučajno da bude vidljiv kao objavljen.

Performanse: šta treba planirati pre rasta baze

Performanse se ne rešavaju samo dodavanjem jačeg servera. Potrebno je razumeti koje upite sistem najčešće izvršava: filtriranje po lokaciji, kombinovanje više atributa, sortiranje po datumu ili relevantnosti, pretraga naziva i učitavanje paginiranih rezultata.

Na osnovu toga se planiraju odgovarajući indeksi, način paginacije i granice upita. Indeks može ubrzati čitanje, ali zauzima prostor i može povećati cenu izmena podataka. Zato nije dobro indeksirati svako polje bez analize stvarnih upita. Zvanična PostgreSQL dokumentacija objašnjava svrhu indeksa i kompromise koje oni uvode u radu sa bazom podataka.

Za korisničko iskustvo posebno su važne sledeće odluke:

• rezultati se učitavaju paginirano ili kroz kontrolisano učitavanje više zapisa,
• broj rezultata je jasno prikazan kada je to moguće,
• sortiranje ima objašnjivo pravilo,
• prazna i spora stanja imaju korisnu povratnu informaciju,
• pretraga i filteri ne gube izabrane vrednosti pri navigaciji.

Ako se katalog uvodi kao deo šireg projekta, model podataka treba povezati sa odlukama o arhitekturi, sadržaju i javnim stranicama. Zbog toga je korisno pogledati i proces izrade sajta kada katalog predstavlja samo jedan deo većeg digitalnog proizvoda, a ne izolovanu funkciju.

Kako proceniti da li je model spreman za razvoj

Pre slanja specifikacije development timu proverite model kroz realne primere, ne samo kroz listu funkcionalnosti. Uzmite nekoliko tipičnih i problematičnih zapisa i pokušajte da odgovorite na sledeća pitanja:

1. Može li jedan zapis pripadati svim potrebnim kategorijama bez dupliranja?
2. Šta se dešava kada se naziv kategorije ili lokacije promeni?
3. Da li se može razlikovati prazan podatak od vrednosti „nije primenljivo“?
4. Koje kombinacije filtera korisnik najčešće očekuje?
5. Kako se prikazuje rezultat bez pogodaka?
6. Koji zapisi imaju rok važenja ili status arhiviranja?
7. Da li je jasno koje filtrirane stranice treba čuvati, deliti ili indeksirati?
8. Može li urednik da ispravi podatke bez pomoći developera?

Za sistematičnu pripremu zahteva može poslužiti custom CMS checklista pre slanja development ponude. Ona pomaže da se otvorena pitanja uoče pre procene i da se obim ne zasniva na pretpostavkama.

Praktičan redosled odluka

Najstabilniji pristup je da se razvoj ne počne od svih mogućih filtera, već od jezgra sistema:

1. definišite glavni entitet i njegove poslovne statuse;
2. popišite taksonomije, hijerarhije i odnose;
3. odvojite podatke za prikaz od podataka za filtriranje;
4. napišite pravila kombinovanja filtera;
5. odredite koje URL-ove korisnik može da deli, a koje ne treba indeksirati;
6. isprobajte model sa stvarnim primerima i graničnim slučajevima;
7. tek zatim definišite komponente interfejsa, dozvole i tehničku implementaciju.

Ovakav redosled čuva katalog od čestog problema: vizuelno gotovog interfejsa koji ne može pouzdano da podrži nove kategorije, dodatne lokacije ili složenije upite. Sledeći korak je da se za konkretan projekat napravi mapa entiteta i filtera, zajedno sa nekoliko reprezentativnih korisničkih scenarija. Na osnovu toga se može preciznije odlučiti šta pripada custom CMS-u, šta ostaje urednička odluka, a šta je samo privremeno filtriranje u interfejsu.