[ALG] Navigatie ontwerp bij een CMS

[Reveller]

Zoals velen hier maak ik momenteel mijn eigen CMS'je. Opzich heb ik genoeg ideeen over de manier waarop ik eea wil programmeren, welke functionaliteit ik erin wil hebben, etc. Over 1 punt blijf ik echter twijfelen, en ik hoop dat jullie je ervaringen / ideeen hierover willen delen.

Introductie
Voordat ik begin aan mijn eigen systeem, heb ik eerst een groot aantal cms'jes van anderen bekeken. Ik was vooral gecharmeerd van Userland Manila (proefsite te nemen via http://www.manilasites.com) en Drupal. Manila vanwege zijn gebruiksvriendelijkheid, Drupal vanwege de - naar mijn mening - schitterende manier van coden.

Nette url's
Beide producten hebben de navigatie losgekoppeld van het aanmaken van content. Als ik in drupal een nieuw artikel aanmaak, kan ik deze bereiken via de url site.com/node/view/18. Dezelfde pagina zou binnen Manila te bereiken zijn via site.com/stories/storyReader$18. Beide systemen geven vervolgens de mogelijkheid een url-alias aan het artikel toe te kennen: zo kan ik de alias site.com/fruit/appels laten doorverwijzen naar eerder gegeven url's.

Navigatie
Nog steeds heeft de site geen navigatie. Op een aparte pagina moet ik een menu item aanmaken ("Appels") en deze koppelen aan een url ("stories/storyReader$18" of "node/view/18"). Bij Drupal moet ik de node vervolgens toekennen aan een parent (als ik die al gedefinieerd had), om zo een navigatie met meerdere lagen te kunnen krijgen. Manila ondersteunt alleen navigatie-items op 1 niveau, maar dat terzijde.

Voordelen
De voordelen van een dergelijke manier van werken zijn:

• minder handelingen voor de gebruiker op het moment dat hij content aanmaakt
• flexibiliteit in de navigatie: ik kan een item naar een artikel, weblog comment, etc. laten verwijzen

Nadelen
Daar tegenover staan naar mijn mening genoeg nadelen:

• 9 van de 10 keer zal de gebruiker een pagina aanmaken en deze meteen aan de navigatie toegevoegd willen hebben. Daar moet hij nu voor naar een andere pagina binnen de admin
• er worden hele url's toegekend aan elke pagina: als node/view/18 (met als url-alias fruit/appels) en node/view/77 (alias: fruit/peren) verplaatst moeten worden van "fruit" naar bijvoorbeeld "groenten", moet ik alle aliassen stuk-voor-stuk gaan hernoemen (groenten/appels, groenten/peren).
• stel dat ik een artikel "rode peren" heb getypt, maar deze niet aan de navigatie heb toegevoegd, dan staat dit artikel tot geen enkel ander artikel in hierarchisch verband: als ik naar node/view/34 (het artikel) surf, zou de cookie crumb trail iets als "Home > fruit > peren > rode peren" moeten aangeven, maar omdat het artikel nog niet in de hierarchie is opgenomen, zul je zoiets als "Home > rode peren" krijgen. Helemaal raar is als je al wel een alias hebt aangemaakt voor het artikel, maar hem nog niet aan de navigatie hebt toegevoegd: je surft dan naar site.com/fruit/peren/rood, en de crumb trail zegt dan "Home > rode peren"...

Wat ik tot nu toe had
Tot nu toe moest de gebruiker bij mij als hij een artikel aanmaakte, een arl-alias van 1 woord kiezen ("appels") en aanklikken tot welke parent-artikel deze behoorde. Database:

code:

+----+-----+-----------+-------+--------------------------+
| id | pid | url-alias | titel | tekst                    |
+----+-----+-----------+-------+--------------------------+
|  1 |   0 |           | Home  | Welkom op mijn website.. |
+----+-----+-----------+-------+--------------------------+
|  2 |   1 | fruit     | Fruit | Gezond voor jong en oud, |
+----+-----+-----------+-------+--------------------------+
|  3 |   1 | groenten  | Groen | Niet altijd even lekker, |
+----+-----+-----------+-------+--------------------------+
|  4 |   2 | appels    | Appel | Vele soorten: elstar, ro |
+----+-----+-----------+-------+--------------------------+
|  5 |   2 | peren     | Peer  | Erg lekker voor op het ..|
+----+-----+-----------+-------+--------------------------+

Als iemand naar site.com/fruit/appels surft, query ik de database of dat pad toch wel bestaat. In dit geval wel, en ik laat artikel nummer 4 zien. Voordeel is dat als ik fruit ineens onder groenten zou willen hangen (en dus groenten/fruit/appels als geldige url wil hebben), ik alleen de pid van "fruit" hoef te veranderen van "1" naar "3". Dat is anders dan bij genoemde systemen, waarbij de url-alias zelf een complete url is.

Beperkingen aan mijn manier
Ik loop tegen de lamp nu ik meer functionaliteit in mijn cms'je wil brengen: de gebruiker kiest een parent voor elk nieuw artikel, zodat de navigatie automatisch wordt aangemaakt. Maar wat nu als ik het cms lever met een gastenboek-module, en de gebruiker wil aan de navigatie een link "GastenBoek" toevoegen onder het parent-artikel "Contact"? Mijn artikelen en content-tree zijn in 1 tabel verweven, dus dat wordt lastig te bewerkstelligen.

Vragen

• wordt bij jullie cms de navigatie automatisch aangemaakt als er een nieuw artikel geschreven wordt?
• kunnen gebruikers in de navigatie ook links maken naar bijvoorbeeld een bepaalde weblog-post of het gastenboek?
• op welke manier gebeurt dat? Kun je wellicht een screenshot van de user-interface posten hoe nieuwe navigatie-links worden aangemaakt?

Ik hoop dat mijn probleem duidelijk is. Aangezien het de totale opzet van het cms beinvloed, hoop ik op een aantal positieve reakties en briljante ideeen

[ Voor 14% gewijzigd door Reveller op 19-01-2005 17:26 ]

[Michali]

Ik zou de hele tekst kolom loskoppelen van je pagina tabel. Je zou dan bijvoorbeeld kunnen gaan werken met pagina typen en aan de hand van wat in het pagina type is gedefineert is tekst of andere zaken ophalen, wat je nodig hebt. Je kunt dan nog extra waardes koppelen aan een pagina. Je zou zelfs collecties van items kunnen ondersteunen, voor bijvoorbeeld een gastenboek. Bij het opvragen van een pagina lees je dan uit wat voor type pagina het is en aan de hand daarvan kun je dan actie ondernemen, zowel aan de kant van de website als aan de kant van het CMS.

[ Voor 6% gewijzigd door Michali op 19-01-2005 19:16 ]

[Not Pingu]

Misschien heb ik niet goed gelezen, maar waarom zou je artikelen los van een pagina toegankelijk willen maken als je al pagina's definieert in je CMS? Ik heb ook net als jij strings in de url bij mijn CMS die dan verwijzen naar een pagina.

Een artikel is dan alleen te bereiken via een pagina (logisch ook, want een gebruiker maakt (bij mijn CMS iig) een artikel openbaar door het te publiceren op een pagina. als het artikel niet gepubliceerd is, hoe weet je dan dat een gebruiker echt wel wil dat dat artikel voor iedereen te zien is?

[Reveller]

@Michali - je beschrijft precies de manier waarop ik tot nu toe gewerkt heb. Ik lees de url uit, bepaal de node_id die erbij hoort. Als ik de goede node gevonden heb, kijk ik wat voor type het is. Is het type bijvoorbeeld 'story' en het id '23', dan haal ik story 23 op uit de story tabel. Mijn vraag gaat echter meer over de navigatie zelf. Als je in mijn cms een nieuwe pagina wil toevoegen, moet je als gebruiker 1) kiezen onder welke parent hij komt te hangen 2) bepalen wat voor type het is (story, guestbook, weblog, etc.). Afhankelijk daarvan krijg je een aantal invoervelden om de daadwerkelijke pagina in te vullen. Het probleem wat ik nu alleen heb is dat dit weinig flexibel is. Ik kan alleen maar navigatie-links aanmaken naar modules (guestbook, weblog) of artikelen (artikel 23, artikel 43). Ik verken de mogelijkheden om navigatie los te koppelen van de content om zo meer flexibiliteit te maken. Om de mogelijkheid te hebben een navigatie-link te maken naar cnn.com of site.com/weblog/2004/12/16 (alle weblog posts van 16 december).

@Gunp01nt - dus als ik het goed begrijp moet in jouw cms ook een content type worden toegekend aan een pagina. En een voorbeeld van een type is een artikel? Kan ik ook een link maken in jouw navigatie dat verwijst naar het guestbook? Of persbericht 20 (aangenomen dat "persbericht" een content type is) in plaats van alleen naar de persberichten-indexpagina?

[Not Pingu]

Reveller schreef op woensdag 19 januari 2005 @ 20:23:
@Gunp01nt - dus als ik het goed begrijp moet in jouw cms ook een content type worden toegekend aan een pagina. En een voorbeeld van een type is een artikel?

Mijn CMS werkt dan toch iets anders. Bij mij is een pagina een verzameling pageitems die op bepaalde plaatsen (panelen gedefinieerd in templates) staan. Een pageitem kan van het type artikel zijn, maar ook een guestbook, een flash-filmpje, een foto-gallery, of een weergave van de menustructuur. Je kunt dus meerdere soorten content op 1 pagina hebben. Ik heb even dat manila bekeken en daar kun je dus idd maar 1 soort content op een pagina laten weergeven.

[JHS]

Persoonlijk zou ik het / pak ik het denk ik meer als Gunp01nt aan .

Een pagina wordt behandeld als een item. Aan dat item kunnen verschillende dingen worden gehangen zoals een extra stylesheet, of een parent. Via een losstaande parents tabel wordt vervolgens de hierarchie bepaalt. (een item kan overigens ook automatisch de eigenschappen van de parent krijgen (behalve wat de parent is natuurlijk ), zodra dat werkt tenminste ) .

Deze hierarchie wordt vervolgens omgezet naar een treevieuw / list, waar nu een menu uit moet gaan komen.

Dit levert dus zoiets op:

code:

-Index (parent)
--Appels (parent)
---Alle appels van de wereld (item)
---Granny's (parent)
----Eigenschappen (item)
----Vindplaatsen (item)
---Smith's (parent)
----Eigenschappen (item)
----Groeigebieden (item)

Bij het aanmaken van een item word overigens gelijk gevraagd naar een verkorte titel wat ook gelijk de alias aanmaakt. Deze is te bezoeken op meerdere manieren. Stel, alleapels is de alias van Alle appels van de wereld, en heeft id 5.
Deze kan bezocht worden via www.pagina.nl/name/alleappels/ of www.pagina.nl/id/5/ , maar ook via www.pagina.nl/appels/ of www.pagina.nl/appels/alleappels/ .
Stel dat eigenschappen de alias is van de beide Eigenschappen items is, dan komt www.pagina.nl/name/eigenschappen uit op een pagina waar beide pagina's aan te klikken zijn, met een inleiding.

Eén item kan overigens ook meerdere parents hebben. Aangezien alle interne verwijzingen toch naar het id zijn en de tree gewoon steeds wordt afgezocht, maakt dat ook niet echt uit .

De realisatie van de tree naar de navigatie is nog niet helemaal uitgedacht / gelukt, omdat ik ermee zit dat het teveel lagen diep kan worden. Om dat te voorkomen wil ik de gebruiker nog kunnen laten instellen welke lagen wanneer gepresenteerd worden, maar dat, en ook een deel van wat ik hierboven beschreven heb, wil nog niet echt lukken .

Maar om je vragen te beantwoorden:
Ja, de navigatie wordt automatisch aangemaakt, gezien het feit dat elk artikel een parent moet hebben (meestal gewoon (sub)catagorie genoemt) . Ik zie het nadeel hier niet van, zeker gezien het feit dat een item in meerdere catagorien kan staan. (Een parent trouwens ook).

Ja, ze kunnen dus ook een link maken naar een bepaald item. Gewoon door ook die als parent op te geven. Het is aan de gebruiker om te zorgen dat er een duidelijke structuur over blijft.

Dat gebeurt dus door het toekennen van een parent. Screenshot heb ik niet, aangezien het momenteel een beetje buggy is ( ) . Maar het is een kwestie van aanklikken: extra parent of ik dat anders ga noemen weet ik nog niet . Dan verschijnt er een extra dropdown menutje met daarin de treeview, waarbij de parent kan worden aangeklikt.

---

Over de verschillende type pagina's: Elke pagina wordt door de gebruiker met dezelfde mogelijkheden opgebouwd. Type's vond ik te inflexibel. Mischien voeg ik dat nog toe als optie. Met inhereting vind er overigens ook een soort van type selectie plaats, (er wordt geinheret van de eerste parent), maar wel een stuk flexibeler.

---

Stel dat de gebruiker een link naar CNN wil aanmaken...
Dat was ik even vergeten .
Ik denk dat ik dat oplos door de mogelijkheid te bieden om een item aan te maken die via header(); redirect .

[ Voor 11% gewijzigd door JHS op 19-01-2005 21:14 ]

[Reveller]

@JHS, @iedereen - als ik samenvat wat ik tot nu toe in de reakties gelezen heb, zou je kunnen zeggen dat jullie min of meer op dezelfde manier werken. De gebruiker:

• maakt een nieuwe pagina aan
• kiest een (url)alias
• selecteert (in een selectbox?) een of meerdere content-items > een artikel, formulier etc.

Elke pagina wordt dus meteen op een positie binnen een content-tree gezet. Het is dus nooit zo dat er een pagina is die geen positie binnen de content-tree is (zoals beschreven in mijn openingspost)?

[ Voor 3% gewijzigd door Reveller op 19-01-2005 21:27 ]

[JHS]

Reveller schreef op woensdag 19 januari 2005 @ 21:26:
Het is dus nooit zo dat er een pagina is die geen positie binnen de content-tree is (zoals beschreven in mijn openingspost)?

Nee, wordt lijkt me moeilijk om naartoe te navigeren. Je zou het eventueel wel mogelijk kunnen maken, zodat mensen er in de templates naartoe kunnen linken, maar dat lijkt me niet nodig / wenselijk .

[Reveller]

JHS schreef op woensdag 19 januari 2005 @ 21:28:
[...]
Nee, wordt lijkt me moeilijk om naartoe te navigeren. [...] dat lijkt me niet nodig / wenselijk

Dat ben ik met je eens. Mijn vraag is alleen: waarom maken gerenommeerde software producten als Manila en Drupal (zie openingspost) zo'n duidelijk onderscheid tussen content en navigatie. Bij beide producten is het mogelijk om pagina's aan te maken die niet in de navigatie verschijnen - er dus helemaal buiten vallen. Ik vraag me daarom af of ik iets over het hoofd zie...

Maar misschien komt het wel omdat beide producten van oorsprong weblog software zijn; niet puur gebouwd om als website-cms te fungeren.

[Michali]

Het is inderdaad wel handig om pagina's aan te kunnen maken die niet in het menu verschijnen. Verder is het beter om je navigatie van je content te scheiden omdat dit het inderdaad een stuk flexibeler maakt. Je vertelt wel dat de methode die ik uitlegde precies is wat je doet, maar aan de tabel te zien doe je toch heel wat anders. Of heeft die tabel een andere functie?

Je zou eens moeten uitzoeken wat er allemaal overeen komt in de modules en de artikelen. Wat hebben ze allemaal en hoe zou ik iets kunnen maken zodat 1 soort pagina alles 'kan' ondersteunen. Zo los ik het op namelijk. In het CMS wat ik aan het maken ben (ook al ) kan ik gemakkelijk functionaliteit voor een pagina definieeren zodat het als weblog of gastenboek fungeert.

[ Voor 37% gewijzigd door Michali op 20-01-2005 10:55 ]

[Verwijderd]

Je moet twee zaken onderscheiden, structuur en content. Bij mij wordt de navigatie aangemaakt op basis van structuur. En deze structuur bepaal je door pagina's toe te voegen.

Je kunt vervolgens aan pagina's aliases hangen, permissies, etc. wat je maar nodig denkt te hebben.

Vervolgens hang je aan een pagina's content. En die content is verzameld in een bibliotheek voor content items. Je legt puur een relatie tussen pagina en content. Dat is alles. Niet moeilijk gaan doen, niet van alles gaan vastleggen, probeer een generieke aanpak gewoon goed te gebruiken, daar hebben de meeste CM systemen nog steeds erg veel last van.

Kortom een een tabel met objecten, een tabel met properties, een tabel met instanties, een tabel met content, en een tabel met relaties. Dan heb je de basis al staan. Als je geen many to many relationships wilt aanleggen laat je de tabel met relaties weg.

[ Voor 37% gewijzigd door Verwijderd op 20-01-2005 11:48 ]

[JHS]

Reveller schreef op woensdag 19 januari 2005 @ 21:39:
[...] Bij beide producten is het mogelijk om pagina's aan te maken die niet in de navigatie verschijnen - er dus helemaal buiten vallen. Ik vraag me daarom af of ik iets over het hoofd zie...

Ik bedenk me net dat je af en toe best wel eens een pagina wil aanmaken waar alleen maar naar gelinkt wordt vanuit een item. Wat in mijn opzet nog best zou kunnen door hem geen parent te geven, of een parent die zelf geen parent heeft .

[Torrac]

Heb je trouwens ook de MCS Websitebaker bekeken??

Het is een redelijk nieuwe cms die er leuk en goed uit ziet.

www.websitebaker.org

[JHS]

Torrac schreef op donderdag 20 januari 2005 @ 17:16:
Heb je trouwens ook de MCS Websitebaker bekeken?? Het is een redelijk nieuwe cms die er leuk en goed uit ziet. www.websitebaker.org

Dat ziet er inderdaad best leuk uit. Heeft overigens best eenzelfde opzet als waar ik aan werk Hoewel dat voor een deel natuurlijk ook wel logisch is . .

[ Voor 10% gewijzigd door JHS op 20-01-2005 18:22 ]

[Anders]

Reveller schreef op woensdag 19 januari 2005 @ 21:39:
Dat ben ik met je eens. Mijn vraag is alleen: waarom maken gerenommeerde software producten als Manila en Drupal (zie openingspost) zo'n duidelijk onderscheid tussen content en navigatie. Bij beide producten is het mogelijk om pagina's aan te maken die niet in de navigatie verschijnen - er dus helemaal buiten vallen. Ik vraag me daarom af of ik iets over het hoofd zie...

Je ziet over het hoofd dat algemene site-navigatie niet het ei van Columbus is. Bezoekers scannen de content, niet de navigatie.

Zie het volgende uitstekende artikel:

Navigation blindness
How to deal with the fact that people tend to ignore navigation tools

.. en realiseer je dat het heel goed mogelijk is om bezoekers te (willen) leiden naar pagina's die niet per sé in de navigatie voorkomen. Of pagina's die je juist op verschillende plekken in de navigatie wilt laten voorkomen. Het gaat er niet om of je navigatie logisch is, maar of de bezoeker kan vinden wat hij wil. Soms is een onlogische navigatie daar beter in.

[Verwijderd]

Anders schreef op donderdag 20 januari 2005 @ 20:07:
. en realiseer je dat het heel goed mogelijk is om bezoekers te (willen) leiden naar pagina's die niet per sé in de navigatie voorkomen. Of pagina's die je juist op verschillende plekken in de navigatie wilt laten voorkomen. Het gaat er niet om of je navigatie logisch is, maar of de bezoeker kan vinden wat hij wil. Soms is een onlogische navigatie daar beter in.

Het hangen van een behavior aan een pagina kun je ook doen als je al in een structuur zit

Ik heb bij klanten altijd het gevoel gehad dat ze erg prijs stelden op werken van een structuur, waar je dan inhoud aan hangt. Als je dan bepaalde zaken uit de structuur weg wilt laten in je navigatie kun je dit doen door attributen aan een pagina.

Ik heb persoonlijk ook maar weinig systemen meegemaakt die alles los lieten, en daarbij overzichtelijk en prettig in gebruik waren. Ook de grotere systemen werken op basis van Taxonomy (hippe woord van de dag betekend niets anders als structuur).

Dat gebruikers puur op content browsen klopt inderdaad, maar ook hierbij is het afhankelijk van het design.

[ Voor 6% gewijzigd door Verwijderd op 20-01-2005 20:35 ]