| Ik denk dat de tekst 'verklaart geen lid te zijn', wat erg kort door de bocht is.
Dat moet een compleet statement zijn, waarmee men zich akkoord verklaart.
Daarom is het misschien handiger, als er geen checkbox is, maar de verklaring
als tekst met dan daaronder een knop 'ik accepteer' of zoiets.
Hierna zou je dan op het registreer-formulier moeten komen. Maar dit stuit direct
op moeilijkheden in de procedure. Dit zou niet gewoon een knop met een link
kunnen zijn, want dan kan elke jan doedel even op die knop klikken en wat met de
registratie gaan zitten klooien. Er moet hier een hindernis ingebouwd worden.
Hierbij zat ik te denken, dat er ook ergens in dit traject de registrator een
eigen ID en PW moet krijgen, om later toegang te hebben tot de eigen velden in
de database. Dit kan op twee manieren : Ze dat zelf in laten vullen, of de strings
met een routine te laten genereren. Dat tweede geval lijkt me handiger, omdat
1) het wordt gegenereerd aan de OX-kant, dus het kan meteen opgeborgen
worden als een unieke, reeds uitgereikte, code.
2) het kan meteen worden gekoppeld aan de registrator.
Voor dat laatste heb je dus mailverkeer nodig. En dit komt goed uit voor die hindernis :
Stel, dat checkbox, knop, whatever, niet meteen naar de registratie-formulieren
leidt, maar naar de aanvraag om te kunnen registreren . .
Dus naar een 'mailto' o.i.d. (Ok, dan moeten ze nog even geduld hebben, never mind)
Dit geeft wel meteen de gelegenheid in dat verkeer, om dat id/pw te regelen.
Het zou ook mooi zijn, als die hele statement in dat verkeer erbij geplaatst is.
Om het verkeer zo kort mogelijk te houden, moet het in 1 keer heen en weer
geregeld zijn. Vanwege het statement, kan de registrator dan niet als eerste
mailen, want die heeft die tekst niet. Die moet natuurlijk wel op de OX-pagina
staan, maar dat garandeert niet geheel.. (Ik weet niet of het mogelijk is, dat
bij een 'mailto' er ook alvast een tekst bij gegenereerd kan zijn)
Het is denk ik simpeler, als er eerst een mail door OX wordt verstuurd.
Dat betekent, dat OX iemands adres moet hebben. Dat kan door het in te vullen,
maar dan heb je toch ook een knop nodig, om de procedure te activeren.
Dus dan zou het ook net zo goed kunnen via een 'mailto' knop. Daar hoeft op zich
niks in te staan (misschien met voorgebakken header, als dat kan).
Men zou dan meteen gewoon op 'send' kunnen drukken.
Het bezwaar hiervan is, dat dit 3 ipv. 2 mails verkeer oplevert. Het moet immers,
als het even kan, zo zijn, dat de laatste mail van de aanvrager komt. Omdat in
die mail ook het statement moet staan, zodat die mail ook een krachtig bewijs is
van : 'gelezen hebbende en geaccepteerd'.
Dus : het invullen van het mailadres en knop voor starten van procedure is het
effficientst. Dit zou er zo kunnen uitzien :
1) Tekst van statement
2) Invullen van mailadres
3) Knop - "Ik vraag registratie aan"
- Vervolgens stuurt OX een mail naar de aanvrager, met daarin nogmaals het statement,
plus de gegenereerde id/pw.
- Pas als OX een reply heeft gekregen, met, als quote, het statement weer, wordt de
toegestuurde id/pw "valid" en zal de aanvrager kunnen inloggen voor het invullen
van het registratie-formulier met de persoonlijke gegevens.
- Wanneer dat is ingevuld, en opgeslagen in de database, kan ook de edit-optie van
die database "valid" worden, om de nieuwe deelnemer gegevens over het werk te
kunnen laten invullen.
- Daarna nog zou, als luxe, de deelnemer een mail kunnen krijgen van OX, met daarin
alle ingevulde gegevens op een rijtje. Maar dat hoeft niet perse in dit aanvraag-verkeer
plaats te vinden, het kan later ook nog, of alleen als iemand daarom vraagt.
Het lijkt me het handigst, als de toegang naar registratie en database op zich
gescheiden is op de site. Dwz. naast elkaar op hetzelfde keuze-level, naar de
verschillende secties. Ook omdat bezoekers de database moeten kunnen raadplegen
en ze dan niet via die registratie-pagina zouden moeten gaan.
De deelnemers kunnen natuurlijk via die reg-pagina alsnog evengoed in hun edit-ruimte
van de database komen, maar dat zal alleen de eerste keer zijn. Willen ze later nog
werk toevoegen, of iets veranderen, dan moeten ze direct kunnen inloggen in de database,
niet meer via die reg-pagina.
Later zou met een evt. forum dezelfde constructie kunnen :
Bezoekers kunnen de boel lezen, maar alleen deelnemers kunnen berichten toevoegen.
De read-only hierarchie.
|