Üzleti igények begyűjtése

Az üzleti igények átbeszélése Webb & Flow és a megrendelő között történik.

Ennek előfeltétele, hogy az oldal típusnak minimum a drótváza (wireframe, UX terv) el van mindkét fél által fogadva, de a statikus verzió, és ezáltal a CMS-be építés specifikációja is kizárólag a grafikai terv teljes elfogadása után történhet meg.

Mit tekintünk grafikai tervnek?

Grafikai tervként több szint is elfogadható, azonban ezt a feladat elején tisztázni kell.

Drótváz

Ebben az esetben a drótvázat már kész tervnek tekintjük, és egy már meglévő weblapból, vagy másik, teljesen kész grafikai tervből indulunk ki.

A drótváz meghatározza magának az oldal típusnak is az elrendezését.

Az oldalon található elemek grafikáját valamilyen, etalonnak tekintett forrás határozza meg. Ez a forrás lehet:

• a weblap egy másik, már létező oldal típusa, és az az által meghatározott standard komponensek
• a weblap egy másik oldal típusához készített grafikai terv, és az az által meghatározott standard komponensek
• egy másik weblap, ami meghatározza, vagy javaslatot tesz az egyes komponensek kinézetére
  • ebben az esetben a szükséges szín eltéréseket a tervvel együtt egyeztetni kell, és meg kell határozni a használt színkódokat

Előnyök:

• grafikus nélkül, viszonylag könnyen össze lehet rakni a tervet

Hátrányok:

• mivel nincs kellő mértékben meghatározva az egyes elemek kinézete, így nagy az esélye, hogy több módosítást is kell végezni a statikus verzión, mire kialakul egy olyan kinézet, ami mindenkinek megfelel

Alapszintű grafikai terv

Ezen már ki van dolgozva minden standard komponens kinézete, de azokat nem kőbe vésett szabályként, hanem javaslatként kezeljük. A tervtől akkor lehet eltérés a kivitelezés során, ha:

• előre jelezve van, hogy valamit másképp kell csinálni, mint a terven szerepel
  • például a terven egy konkrét színárnyalat van használva, de végül egy másikat kell használni
• olyan eltérések vannak, amik miatt az alap Bootstrap által meghatározott térközöktől vagy méretektől el kell térni
  • például egy doboznak kisebb, vagy nagyobb valamelyik térköze, mint amit a Bootstrap meghatároz
• a DOD dokumentumban meghatározott támogatandó böngészők közül minimum egyben nem lehet SEO barátan megvalósítani a kért kinézetet vagy működést

Előnyök:

• mivel kellőképpen meg van határozva az egyes elemek kinézete, és a Bootstrap által meghatározott méretekkel dolgozunk, így viszonylag gyorsan elkészülhet egy olyan statikus verzió, ami akár módosítás nélkül is egyből megfelel mindenkinek

Hátrányok:

• szükséges egy grafikus a terv elkészítéséhez
  • kivéve, ha nem ez a weblap első terve, és már vannak kialakult standard komponensek, amikkel gyorsan össze lehet ollózni a tervet úgy, mintha egy drótváz lenne

Pixel pontos grafikai terv

Ebben az esetben a grafikai tervet pixel pontosan kell megvalósítani. Ennek feltétele, hogy a terven minden méret, térköz és szín konzekvensen szerepeljen (ne legyen az egyik doboznak 12, a következőnek pedig 13px a térköze, kizárólag akkor, ha kifejezetten ez a cél), és minden képernyő mérethez külön tervnek kell lennie.

Ebben az esetben nem csak az egyes méretek tesztelési méreteire, hanem a pontos töréspontokra is kellenek tervek, hogy lehessen látni, hogy hogyan változik az egyik méretről a másikra.

A terv készítése során már figyelembe kell venni a DOD dokumentumban meghatározott támogatandó böngészők korlátjait, és szükség esetén vagy a terven, vagy a böngésző listán kell módosítani.

Előnyök:

• teljesen úgy fog kinézni a weblap, ahogy a terven szerepel

Hátrányok:

• a tervet kizárólag grafikus tudja összerakni
• a pontosabb terv elkészítése több időt igényel a grafikus részéről
• mivel nem lehet ebben az esetben a Bootstrap megoldásait használni, ezért a statikus verzió elkészítése akár egy nagyságrenddel több időt is igényelhet a fejlesztőktől
• nem garantálható, hogy az elkészült weblap SEO barát lesz

Mik a szükséges reszponzív nézetek?

Amennyiben a weblapnak reszponzívnak kell lennie, minden elfogadott mérethez szükség van egy-egy tervre. Ezeken a terveken látszódnia kell, hogy:

• hogyan rendeződnek át az egyes komponensek egymáshoz képest (grid rendszer)
• hogyan törnek a szövegek
• hogyan változnak a méretek
  • térközök
  • betűméretek, sortávolságok
  • stb …
• hogyan változnak esetleg a színek

Amennyiben a SEO fontos, úgy mindenképpen reszponzívank kell lennie az oldalnak, és támogatnia kell a mobil és a desktop méreteket. Azonban mivel különböző méretű mobilok vannak, és léteznek a tabletek is, így a Bootstrap 5 összesen 6 (Bootstrap 4 esetén 5) alap méretet definiál, amivel általában már jól le lehet fedni a méret skálát.

A Webb & Flow ezeket az alap méreteket igény esetén még ki szokta egészíteni a nagyon kicsi mobil, illetve Bootstrap 4 esetén a nagyon nagy desktop méretekkel.

Fontos, hogy ha nem készül minden méretre terv, de támogatni kell a nagyon kicsi mobilokat, akkor arra a méretre mindenképpen készülnie kell külön tervnek, vagy azt kell mobil méretű tervként kezelni.

Mobil + Desktop terv

Ebben az esetben a legkisebb és a legnagyobb méretek terveiből kell kiindulni, és a köztes méreteket ezek alapján, a Bootstrap lehetőségeire hagyatkozva kell megvalósítani. Ehhez mindenképpen előre tisztázni kell, hogy a tablet nézet a mobil, vagy a desktop nézetre hasonlítson jobban.

Előnyök:

• a többitől gyorsabban megvannak a tervek

Hátrányok:

• nagy az esélye, hogy a tablet, és minden más köztes nézet csak többszöri módosítás után fog elkészülni úgy, hogy mindenkinek megfeleljen

Mobil + Tablet + Desktop terv

Ebben az esetben a legkisebb, a legnagyobb és a kettő közti átmenet tervéből indulunk ki, és minden más méret ezek alapján alakul ki

Előnyök:

• gyorsabban megvannak a tervek, mintha minden méretre külön elkészülne

Hátrányok:

• nagy az esélye, hogy a köztes nézetek, amikre nem készültek tervek, csak többszöri módosítás után fog elkészülni úgy, hogy mindenkinek megfeleljen

Minden méretre külön terv

Ebben az esetben az összes, előre elfogadott méretre elkészülnek a tervek.

Előnyök:

• egyből elkészülhet a tervek alapján a weblap úgy, hogy minden szükséges méreten megfelelően jelenik meg a tartalom

Hátrányok:

• több idő kell a tervek elkészítésére

Landing builder, vagy template?

Azt már a tervezés elején el kell dönteni, hogy az adott oldal típust a ConyCMS-ben végül a Landing Builder-el akarja a megrendelő szerkeszteni, vagy template-ként kell kialakítani.

Landing Builder esetében nem maga a weblap készül el, hanem a rajta található különböző komponensek. Az elrendezés, azaz a grid rendszer itt teljesen figyelmen kívül van hagyva, mivel azt egyedileg a Landing Builder-ben kell felépíteni.

A tartalmakat a Landing Builder-ben, az egyes komponensekben lehet szerkeszteni úgy, ahogy az az üzleti igényben le lett írva. Az elrendezést, az abba rakott komponenseket és azok tartalmait külön-külön, url-enként kell beállítani.

Template esetén az készül el, amit a grafikai terven látunk, beleértve a grid rendszert is. Csak akkor készülnek külön komponensek, ha az a tartalom szerkesztést megkönnyíti, ezt leszámítva minden a template-be kerül, és csak a módosítandó tartalmakat lehet külön-külön, url-enként szerkeszteni, magát az elrendezést nem.

Lehet a két módszert keverni is, ebben az esetben az oldal egy nagyobb része template-ként van elkészítve, és azon belül található egy szekció, amit Landing Builder-el szerkesztünk.

Mikor melyiket érdemes használni?

Azt, hogy melyiket érdemes használni, a szerkesztési igények, az oldal típus célja, de a drótváz bonyolultsága is meghatározza.

Eset	Mód	Példa
Egyedi landing oldalakat akarok készíteni, amikből nem lesz két azonos drótvázú	Landing Builder	Egyedi SEO landing oldalak, manuálisan szerkesztett lista oldalak
Sok azonos elrendezésű, de más-más tartalommal feltöltött oldalt szeretnék	Template	Blog posztok, automatán szerkesztett lista oldalak (kategória és tag oldalak)
Az oldal egymástól független, jól elkülöníthető, alap elemekből épül fel, amiket nem akarunk egymásba építeni	Landing Builder
Az oldal nagyon bonyolult, egymástól függő, vagy olyan elemekből áll össze, amiket szeretnék egymásba is ágyazni	Template

Szerkesztési igények

El kell dönteni, hogy az egyes elemeket hogyan akarom szerkeszteni. Ezeket Landing Builder és Template esetén is el kell dönteni, azonban van olyan eset, ahol az egyik automatikusan meghatározza a választ, mivel csak egy módon lehet az adott elemet szerkeszteni.

Képek

Landing Builder

Egyszerűen kell egy kép komponenst készíteni, amit be lehet rakni oda, ahova akarjuk, és meg lehet adni a paramétereit (src, alt, title, stb).

Template

Vannak a tartalomban ( a folyó szöveg részében ) fix helyen képek, amik más elemek előtt, vagy után szerepelnek minden esetben?

• Csak a tartalom elején és / vagy végén, de ott minden esetben
  • egyszerűen fel kell venni egy vagy két PIC típusú External Data mezőt, amiben ezt meg lehet adni
• Tartalom elején mindig, de előtte van egy bevezető szöveg
  • a bevezető szövegnek fel kell venni egy külön TEXT típusú External Data mezőt
• A tartalom közepén is
  • a folyó szöveg közepén levő képeket vagy egyszerűen be kell építeni Markdown, vagy HTML kóddal, vagy ha egy bonyolultabb HTML struktúrát kell köré építeni (pl keret, plusz magyarázó szöveg, forrás, stb), akkor komponensként (HTML Sablon) fel kell venni, és a komponens beépítő kóddal kell a képet a tartalomba szúrni.

Dobozok

Landing Builder

Ebben az esetben minden doboz automatikusan komponens, így oda kerül, ahova akarjuk.

Template

• A doboz minden esetben ott van fix helyen (nem a folyószövegben), csak a tartalma változik
  • a dobozban található minden elemnek, amit tudni kell szerkeszteni, fel kell venni a megfelelő típusú External Data mezőt
• A dobozt a folyó szövegbe kell tudni felvenni
  • amennyiben teljesen statikus a tartalma, script-ként létre lehet hozni, és csak a script behívó kódot kell beírni a folyó szövegbe
  • amennyiben van változó tartalma, de egy oldalon csak egyszer szerepel (vagy többször, de azokban ugyanaz a tartalom), és nem akarjuk más oldal típusoknál használni, script-ként létre lehet hozni, és az abban szereplő változókhoz fel kell venni a megfelelő típusú External Data mezőket
    • ebben az esetben fontos, hogy ezeket a script-eket kizárólag olyan tartalmaknál lehet használni, amiknél ezek a mezők fel vannak véve, azaz kompatibilitási kérdések merülhetnek fel
  • amennyiben van változó tartalma, és egy oldalon többször is használni szeretnénk különböző tartalmakkal, vagy több különböző oldal típusnál is használni szeretnénk, komponensként (HTML Sablonként) kell felvenni, és a tartalomba a sablon behívó kódot kell elhelyezni

Komponensbe ágyazott komponens

Amennyiben egy komponensen belül szeretnénk egy másik komponenst rakni. Előfordulhat, hogy egy adott komponensbe nem lehet egy másikat berakni, de ez ritka abban az esetben, ha a komponensek úgy készültek el, hogy egymástól teljesen függetlenek legyenek.

Landing Builder

A Landing Builder nem támogatja a komponensekbe épített komponenseket, azonban ezt meg lehet kerülni a következő módon:

1. létrehozzuk a beágyazandó komponenst akár script-ként, akár tényleges komponensként (HTML Sablonként)
2. annak a komponensnek, amibe be szeretnénk ágyazni, felveszünk egy TEXT típusú paramétert, amit plusz tartalomként kezelünk (feltéve, hogy még nincs ilyen)
3. ebbe a mezőbe a megfelelő behívó kóddal építhetjük be a beágyazandó komponenst

Template

Mivel egyedi HTML kód készül, így bárhogy kombinálhatók a komponensek (a megadott határokon belül). Akár hard code-olt kóddal, akár a Dobozok-nál leírt módon definiált elemekkel és azok behívásával meg lehet oldani.

Automatikusan generált tartalom listák

Ezeknél a tartalom listákat valamilyen keresési feltétel szerint, tipikusan egy kategóriára, vagy tag-re szűrve, de szükség esetén bonyolultabb feltétel szerint a ConyCMS automatikusan hozza létre egy meghatározott Item Sablon szerint. A tartalomba építésre több lehetőség is van.

Landing Builder

Bármelyik komponens TEXT típusú paraméterébe be lehet írni a tartalom listázás függvényét, így itt helyben lehet szerkeszteni a keresési feltételeket, és megadni, hogy melyik Item Sablon szerint legyenek az elemek szerkesztve.

Amennyiben nem szeretnénk egy komponensen belülre rakni a listát, nem szeretnénk a beépítő kódot szerkeszteni, vagy több helyen ugyanazt fel szeretnénk használni, egy komponenst lehet csinálni, amibe ez a kód van elhelyezve, szükség esetén egyes feltételeit pedig fel lehet paraméterezni, hogy a Landing Builder-ben szerkeszthető legyen, például a limit, vagy offset paraméterek.

Template

A lehetőségek azonosak, mint a Landing Builder esetén, de itt még azt is el lehet dönteni, hogy ezt a listát magába a Template-be akarjuk hardcode-olva beépíteni, vagy az adott tartalom folyó szövegében szeretnénk elhelyezni akár a függvényt, akár annak a komponensnek a behívását, amibe kiszerveztük.

Manuálisan szerkesztett tartalom listák

Amennyiben manuálisan szeretnénk szerkeszteni egy tartalom listát, a következő lehetőségeink vannak:

Speciális tag megadása a tartalomnál

Ebben az esetben felveszünk egy speciális tag-et, amivel jelezzük, hogy azok a tartalmak, amiknél ez be van jelölve, meg kell, hogy jelenjenek egy konkrét listán. Ezután a szerkesztés és beépítés azonos az Automatikusan generált tartalom listákkal.

Tartalom beépítése az oldalba Item Sablonnal

Amennyiben helyben szeretnénk a listát építeni, be lehet automatikusan építeni egy tartalmat a megfelelő ConyCMS függvénnyel, egy meghatározott Item Sablont felhasználva. Ezt a Landing Builder és a Template esetén is ki lehet egy komponens-be szervezni, ami paraméterként megkapja a beépítendő tartalom azonosítóját. Ennek a megoldásnak az előnye, hogy ha megváltozik az adott tartalomnak bármelyik olyan mezeje, amit az adott Item Sablon használ, akkor nem kell manuálisan itt is átírni, csak újra kell generálni a listát és a ConyCMS automatikusan módosítja a szövegeket és/vagy képeket.

Ez a megoldás csak akkor működik, ha létező, az adott oldalon belüli tartalmat szeretnénk linkelni, se külső hivatkozásokra, se virtuális url-ekre nem használható.

Tartalom linkelése bármilyen url mezővel

Amennyiben mindenképpen manuálisan szeretnénk megadni az url-t, és a link többi adatát, akkor létrehozhatunk egy komponenst, ami paraméterben megkapja a link adatait, és ezt behívhatjuk a megfelelő ConyCMS függvénnyel, vagy Landing Builder esetén egyből komponensként beépíthetjük, amennyiben nem egy másik komponensen belül szeretnénk rakni.

Előnye, hogy akár külső, vagy a ConyCMS által nem kezelt url-eket is lehet vele linkelni, hátránya, hogy manuálisan kell minden paramétert módosítani, ha az megváltozik.

Ismétlődő elemek

Bármilyen ismétlődő elemet beépíthetünk egy oldalba, akár egy folyamatábrát, vagy letölthető dokumentum listát is fel lehet építeni.

Elemek tartalomként kezelése

Ez az eset azonos a Manuálisan szerkesztett tartalom lista / Speciális tag megadása a tartalomnál megoldással. Amennyiben ezeknek a lista tartalmaknak nem kell külön oldalt generálni, Listable tartalomként érdemes kezelni azokat.

Akkor érdemes használni, ha egy konkrét elemnek sok paramétere lehet, vagy hosszú, folyó szövege (például egy GYIK lista, ahol az egyes elemek lenyithatók, és nem külön oldalra visznek), vagy nem szeretnénk semmilyen beépítő kódot sem szerkeszteni. Szintén ezt érdemes használni, ha ugyanazt a listát több helyen is használni szeretnénk, vagy a Landing Builder-el szerkesztjük az oldalt, de nem lehet már sehogy a struktúrába berakni egyesével a linkeket.

Elemek beépítése komponensként

Ez az eset azonos a Manuálisan szerkesztett tartalom lista / Tartalom linkelése bármilyen url mezővel megoldással.

Akkor érdemes használni, ha nem akarjuk az egyes elemeket külön tartalomként kezelni, mert kellően egyszerűek ahhoz, hogy így átláthatóbb legyen a weblap logikája.