Hoe is dat dan afgelopen met die database?
Wel, eum. Ik was aangezet met iets te weinig informatie 🙂
Ik had begrepen dat die interface maar door een man of twee zou gebruikt worden om occasioneel data in te voeren.
Blijkt dat het een heel team is dat weken aan een stuk er heel de dag mee zou gaan werken. Arhem. Niet zo goed. Niet dat het niet zou mogelijk zijn, maar ervaring leert me dat het niet realistisch is om te verwachten dat dat goed afloopt. Mensen denken nu eenmaal niet in dergelijke structuren, en eer je doorhebt hoe Access werkt, laat staan visceraal begrijpt wat er allemaal gebeurt als je in een sub-sub-sub-sub-formulier iets typt, zijn we toch weer een hele tijd verder.
Ik heb helaas uit scha en schande geleerd (sorry Jan!) wat er gebeurt als je een dergelijk ingewikkelde database even in een simpel interfacetje gaat proberen steken: de interface wordt alsmaar ingewikkelder en ingewikkelder, en voor je het weet zit je weken en maanden bezig aan iets dat làng niet zo moeilijk had moeten zijn.
‘t Is natuurlijk geen verloren werk wat ik gedaan heb: het blijft een werkbare interface voor beheer later van de gecreëerde databank. Maar de data input zelf zal via Excel-files gebeuren. Die ik dan via een scriptje zal in de juiste tabellen pleuren.
Het alternatief zou geweest zijn om nog zeker een week tijd te verliezen aan het foolproof maken van de applicatie, de opleidingen, de bugfixen, de heropleidingen en het nog foolproofer maken. Not to mention het checken van de ingevoerde data (het “tiens, honderddrieënveertig contactpersonen met een link naar organisaties zonder verdere gegevens”-syndroom).
Zo’n Excel-ding is veel gemakkelijker te bevatten voor niet-IT-minded mensen. Akkoord, niet alles zit erin (max. 3 contactpersonen, één adres, geen deaftel en zo), maar bon, dat is dan de blutsen met de builen. De uitzonderingen schrijven we wel op en doen we manueel.
Reacties
4 reacties op “Database update”
‘is maar een tip hoor, en misschien maakt het uw excel veel te ingewikkeld, maar: zou het niet beter zijn naam- en adresgegevens zoveel mogelijk op te splitsen, met het oog op later gebruik in allerlei contexten? De ene persoon zal in het kotje “name” “Marc Vuijlsteke” zetten, de andere “Dr. Marc Vuijlsteke”, en een derde “Vuijlsteke Marc”. Idem met straten, huisnummers en postcodes. ‘t hangt natuurlijk ook een beetje af van de grootte van de database, maar achteraf opkuisen en standaardiseren kan een lastig werkje zijn.
‘k Weet het, maar helaas: that way madness lies. Als je dat gaat beginnen doen, moet je haast gaan opsplitsen in straat / nummer / postcode / stad (en dan zit je met problemen in bijvoorbeel angelsaksische landen). En de namen, idemditto: aanspreektitel / prefix / voorna(a)m(en) / achterna(a)m(en) / suffix / letters.
…en voor je ‘t weet zit je met een compleet ongebruiksvriendelijk iets waar je geen copy-paste meer kan doen, en waarmee een mail merge zeer lastig wordt.
Ik weet dat er allemaal omwegen rond zijn (views en queries en dingen voor dat laatste bijvoorbeeld), maar het blijft toch lastig werken. En ik stel mij ook de vraag *waarom* het absoluut nodig zou zijn dat we huisnummers bijvoorbeeld in een apart veld zouden steken.
Voor nu zal het een kwestie zijn van (a) op voorhand duidelijke richtlijnen te geven voor formattering van namen en adressen en dergelijke, en (b) na de eerste paar dagen alle excels bij elkaar te rapen en die met een kritisch oog te bekijken en bij te sturen waar nodig.
Als we het allemaal in het echt gaan doen (dit *blijft* voorlopig en voorbereidend werk), dan zal het wellicht beter zitten. Met een naam, sorteernaam, (misschien) meer indelingen in de adressen, etc.
Maar nu niet 😀
Psst. Designing The User Interface van Shneiderman
En uiteraard de tekstjes van Jakob Nielsen…
@koen: euh, ja? 🙂