[CMS] Wat is gebruiksvriendelijk?

[Reveller]

Mijn CMS'je werkt met "nette URL's als volgt. Voor elke pagina die de gebruiker aanmaakt moet hij een "alias" opgeven. Bijvoorbeeld: gebruiker maakt de pagina met titel "Onze Kledinglijn" aan en geeft als alias "kleding". Daaronder hangt hij een pagina "Broeken en Shorts" met alias "broeken". De URL www.site.com/kleding/broeken verwijst nu naar de "Broeken en Shorts" pagina. Nu mijn probleem. Ga uit van de volgende boom, waarbij de aliassen van de pagina's tussen haakjes staan:

code:

Home
   Broeken en Shorts (broeken) **
      Lang (lang)
      Kort (kort)
   Schoenen (schoenen)
   Jassen (jassen)
      Lang (lang) *
      Kort (kort)

Het CMS heeft een mogelijkheid om pagina's te verplaatsen. Stel nu dat de gebruiker de pagina met * (lange jassen) wil verplaatsen als kind onder ** (broeken). Ik kom dan in de knoei, omdat er al een pagina met alias "lang" onder broeken hangt. Met andere woorden: welke pagina moet er op het scherm komen als iemand de URL www.site.com/broeken/lang opvraagt? De boom ziet er immers zo uit:

code:

Home
   Broeken en Shorts (broeken) **
      Lang (lang)
      Kort (kort)
      Lang (lang) *
   Schoenen (schoenen)
   Jassen (jassen)
      Kort (kort)

Dit voorbeeld is eenvoudig, maar het zou net zo goed kunnen dat iemand een pagina (inclusief kinderen van die pagina) verplaatst naar een andere pagina, en dat er 3 niveau's down een dubbele alias zit. Ik zit er nog over te denken hoe ik efficient op dubbele waardes ga controleren (waarschijnlijk door aan elke node in de tree een "level" mee te geven en dan per level te kijken of er al zo'n waarde bestaat), maar vraag me af wat gebruiksvriendelijk is in het geval ik dubbele waardes tegenkom. Het scheelt nogal in programmeerwerk, dus vandaar mijn vraag of ik in het geval van dubbele aliassen:

• de gebruiker moet waarschuwen dat er door de verplaatsing een dubbele alias zal ontstaan en daarom de verplaatsing niet door kan gaan voordat de alias hernoemd is
• zelf de dubbele aliassen moet hernoemen (in dit geval zou ik de * pagina een "lang2" alias ofzo geven)

Graag jullie mening hierover. Heeft iemand al ervaring met een dergerlijk systeem / aanpak?

[NMe]

De URLs laten aanpassen door je script (waar dit dus feitelijk op neerkomt) lijkt me niet zo handig. Buiten dat je zo mogelijk nogal vervelende URLs krijgt, behoort dit soort controle gewoon in handen van de gebruiker te liggen. Wellicht kun je een pagina maken die de gebruiker laat kiezen tussen een van de twee opties? Anders zou ik voor optie 1 gaan.

offtopic:
Volgens mij is je halve CMS al door tweakers verzonnen.

[Verwijderd]

Dit soort dingen wil je nooit. Ambiguïteit kun je niet met een computerprogramma oplossen, anders zou het geen ambiguïteit zijn.

De gebruiker moet maar accepteren dat hij een soort van `aan het programmeren' is (al is het dan heel simpel), en dus niet alles wat hij wil zomaar kan doen.

Ergo, zodra de gebruiker een sectie wil verplaatsen naar een ouder waar al een sectie met diezelfde naam bestaat hoort de gebruiker een harde fout voor zijn neus te krijgen met de sommering (eventueel een form in dezelfde pagina, voor het grootste gebruikersgemak) om de pagina een andere naam te geven die niet conflicteert.

Wat je als gebruiker in elk geval niet wil is dat dingen gebeuren `zonder dat je het weet'. Je wilt als gebruiker dus niet dat dingen hernoemd worden zonder dat je daarover gevraagd wordt. Automatisch hernoemen lijkt me dus niet de beste optie.

En het controleren is niet lastig; je hoeft alleen maar op het hoogste niveau (het niveau waarop verplaatst wordt) op een alias conflict te controleren. De lagere niveaus zijn namelijk gekwalificeerd met de naam van hun ouder en leveren daardoor geen conflict op in de hiërarchie.

[ Voor 33% gewijzigd door Verwijderd op 10-12-2004 03:46 ]

[Verwijderd]

Verwijderd schreef op vrijdag 10 december 2004 @ 03:42:
...
De gebruiker moet maar accepteren dat hij een soort van `aan het programmeren' is (al is het dan heel simpel), en dus niet alles wat hij wil zomaar kan doen.
...
Wat je als gebruiker in elk geval niet wil is dat dingen gebeuren `zonder dat je het weet'. Je wilt als gebruiker dus niet dat dingen hernoemd worden zonder dat je daarover gevraagd wordt. Automatisch hernoemen lijkt me dus niet de beste optie.
...

Het is natuurlijk helemaal de vraag of de gebruiker van het CMS aan het 'programmeren' is, of dat hij in plaats daarvan gebruik maakt van een kant-en-klare GUI om z'n website te bouwen. In het laatste geval ben je geen programmeur, en je kunt je voorstellen dat je de gebruiker juist zo min mogelijk lastigvalt met foutmeldingen. In Software Development wordt het om de haverklap presenteren van errors, messageboxen e.d. waar de gebruiker een keuze wordt voorgelegd niet echt gezien al gebruikersvriendelijk (userfriendlyness anyone )

Als ik me de doelgroep probeer voor te stellen, moet je dus vooral proberen zoveel mogelijk achter de schermen je conflict op te lossen. Misschien dat je default dus gewoon het alias lang2 maakt, maar een Advanced Mode ofzo inbouwt, waarmee de gevorderde gebruiker dit recht kan breien (dus dat hij dit alias naar een ander, vriendelijker, kan hernoemen. Is dat wat?

[Reveller]

Verwijderd schreef op vrijdag 10 december 2004 @ 03:42:
[...] En het controleren is niet lastig; je hoeft alleen maar op het hoogste niveau (het niveau waarop verplaatst wordt) op een alias conflict te controleren. De lagere niveaus zijn namelijk gekwalificeerd met de naam van hun ouder en leveren daardoor geen conflict op in de hiërarchie.

Nu je het zo stelt besef ik dat ook. Ik was al bang (noiuja...) dat ik langs de hele tree moest traveren van de tak die verplaatst wordt

Gezien de reakties tot nu toe is het waarschijnlijk geen goed idee om alleen te kiezen voor het automatisch hernoemen van aliassen. Sikko2go heeft echter wel een punt met

...of dat hij in plaats daarvan gebruik maakt van een kant-en-klare GUI om z'n website te bouwen

Mijn doelgroep is toch klein MKB, en die vinden het wellicht alleen maar handig als pagina's hernoemd worden in plaats van dat ze een foutmelding krijgen. Wel ga ik een keuze inbouwen: meer geavnaceerde gebruikers krijgen wel die foutmelding, met een form om de alias aan te passen en het opniew te proberen. Overigens is het automatisch hernoemen van aliassen een tijdelijk iets: de gebruiker kan te allen tijde alias2 hernoemen naar een fatsoenlijke, szelf gekozen naam.

Al iemand nog zijn visie wil delen, hoor lees ik dat graag

[Skaah]

Je kan ook foceren dat de alias altijd uniek moet zijn, door in je database een UNIQUE constraint op te nemen.

[thomaske]

Skaah schreef op vrijdag 10 december 2004 @ 10:17:
Je kan ook foceren dat de alias altijd uniek moet zijn, door in je database een UNIQUE constraint op te nemen.

Maar dan moet je het alsnog in je applicatie afvangen. Of je moet de gebruiker confronteren met een mooie SQL error.

[bigbeng]

Je kunt ook een tussenscherm tonen met de melding dat het alias al bestaat en een textbox waarin de gebruiker een nieuwe alias kan intyppen, al dan niet met een suggestie. Vervolgens de actie alsnog uitvoeren met de nieuw gekozen alias naam.
Gebruikers zijn natuurlijk per definitie dom , maar als je aangeeft waarom de verplaatsing (nog) niet door kan gaan, met de mogelijkheid voor de gebruiker om de alias gelijk te herstellen, dan hou je hem/haar natuurlijk wel te vriend

[djluc]

Je opzet is wat betreft zoekmachines e.d. sowieso te betwijfelen. Op W3 staat wel een leuk stukje daarover. Vaak is het dan nog beter om gewoon een id te gebruiken die altijd hetzelfde blijft dan een url die veranderd.

http://www.w3.org/Provider/Style/URI

Je zou eigenlijk eerst eens moeten kijken of je structuur zoals je deze nu voorstelt wel helemaal de juiste is welke eigenlijk nooit meer veranderd hoeft te worden.

[ Voor 33% gewijzigd door djluc op 10-12-2004 14:19 ]

[Harm]

thomaske schreef op vrijdag 10 december 2004 @ 10:47:
[...]

Maar dan moet je het alsnog in je applicatie afvangen. Of je moet de gebruiker confronteren met een mooie SQL error.

SQL-errors kun je afvangen en er een nette en nuttige foutmelding, desnoods met zut om de fout ook direct weer op te lossen, voor in de plaats zetten.