---

Halløj,

Jeg kan desværre ikke for fem øre JavaScript, men kender kun til
HTML og CSS. Derfor har min brug af JavaScript hidtil begrænset
sig til, hvad jeg kunne finde af færdige script rundt omkring...

Nu er mit problem, at jeg meget gerne vil lave en søgeformular,
der fra vores hjemmeside kan søge i databasen PubMed. Jeg tror,
at det vil kunne klares ved at anvende JavaScript i en formular.

Når man søger i denne PubMed-database, genereres en URL, hvor
alle søgekriterier indgår. Derfor drejer det sig blot om, at den
grundlæggende URL
(http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=PureSearch&db=
pubmed&details_term=) sendes afsted, samt at de af brugeren
valgte søgekriterier sættes på i enden.

Jeg forestiller mig, at kriterierne vælges ved at markere
relevante checkbokse og altså ikke via et fritekstfelt.
Kriterierne er på forhånde udvalgt af mig og kunne f.eks. være
"aids[sb]" eller "developing countries[mh]". Imellem disse skal
indsættes en boolsk operator, dog oftest "AND". En "færdig" URL
ville se således:
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=PureSearch&db=p
ubmed&details_term=aids[sb]+AND+developing+countries[mh]

Jeg har selv siddet og bøvlet med FORM-funktioner og prøvet at
tilrette nogle JavaScript-søgeformularer, men desværre rækker
mine evner altså ikke...

Er der nogen af jer, der måske kunne være behjælpelig med at få
denne søgefunktion til at virke? Evt. henvise til et script, som
jeg med min ringe formåen selv kan modifere.

Mange hilsner

- Ole

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Ole Nørgaard <ole@norgaard.dk> writes:

> Når man søger i denne PubMed-database, genereres en URL, hvor
> alle søgekriterier indgår. Derfor drejer det sig blot om, at den
> grundlæggende URL
> (http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=PureSearch&db=
> pubmed&details_term=) sendes afsted, samt at de af brugeren
> valgte søgekriterier sættes på i enden.

Det behøver du ikke Javascript til, det kan klares af en almindelig
form med et par skjulte felter:
---
<form action="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi">
<input type="hidden" name="cmd" value="PureSearch">
<input type="hidden" name="db" value="pubmed">
Søgekriterie: <input type="text" name="details_term">
<input type="submit" value="Søg!">
</form>
---

> Jeg forestiller mig, at kriterierne vælges ved at markere
> relevante checkbokse og altså ikke via et fritekstfelt.

Ah, damn! Ok, så behøver du Javascript.

> Kriterierne er på forhånde udvalgt af mig og kunne f.eks. være
> "aids[sb]" eller "developing countries[mh]". Imellem disse skal
> indsættes en boolsk operator, dog oftest "AND". En "færdig" URL
> ville se således:
> http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=PureSearch&db=p
> ubmed&details_term=aids[sb]+AND+developing+countries[mh]

Ok, lad os antage at der er nogle checkboxe og et par radioknapper
til at vælge operatoren. Jeg putter dem i en form for sig selv,
for at undgå at de bliver sendt med. Så bruger jeg en funktion til
at pille værdien ud af alle checkboxene der er valgt, og sætter
dem sammen med enten " AND " eller " OR ". Den sammensatte værdi
bliver så skrevet ind i den rigtige form inden den bliver submittet.
---
<!-- dette er en anden form, ikke den der skal submittes! -->
<form action="" id="inputForm" name="inputForm">
<p>Operator:
<input type="radio" name="operator" id="andOperator"
checked="checked">
<label for="andOperator">AND</label>
<input type="radio" name="operator" id="orOperator">
<label for="orOperator">OR</label>
</p>

<p>Søgekriterier:</p>
<p>
<input type="checkbox" name="krit" value="aids[sb]"> aids[sb]
</p>
<p>
<input type="checkbox" name="krit"
value="developing countries[mh]"> developing countries[mh]
</p>
</form>
<form action="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi"
onsubmit="populate(this)">
<input type="hidden" name="cmd" value="PureSearch">
<input type="hidden" name="db" value="pubmed">
<input type="hidden" name="details_term">

<input type="submit" value="Søg!">
</form>
<script type="text/javascript">
function populate(form) {
var subjects = [];
var inputElems = document.forms['inputForm'].elements;
for (var i=0; i<inputElems.length;i++) {
var elem = inputElems[i];
if (elem.type == "checkbox" && elem.checked) {
subjects[subjects.length] = elem.value;
}
}

var andOp = document.getElementById("andOperator").checked;
var operator = andOp ? " AND " : " OR ";
form.elements['details_term'].value =
subjects.join(operator);
}
</script>
---

Man kan så bare tilføje flere checkbox'e til den første form hvis man vil
have flere valgmuligheder.

Held og lykke.
/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

---

Lasse Reichstein Nielsen wrote in dk.edb.internet.webdesign.clientside:
> Ole Nørgaard <ole@norgaard.dk> writes:
>
> > Når man søger i denne PubMed-database, genereres en URL, hvor
> > alle søgekriterier indgår. Derfor drejer det sig blot om, at den
> > grundlæggende URL
> > (http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=PureSearch&db=
> > pubmed&details_term=) sendes afsted, samt at de af brugeren
> > valgte søgekriterier sættes på i enden.
>
> Det behøver du ikke Javascript til, det kan klares af en almindelig
> form med et par skjulte felter:
> ---
> <form action="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi">
> <input type="hidden" name="cmd" value="PureSearch">
> <input type="hidden" name="db" value="pubmed">
> Søgekriterie: <input type="text" name="details_term">
> <input type="submit" value="Søg!">
> </form>
> ---
>
> > Jeg forestiller mig, at kriterierne vælges ved at markere
> > relevante checkbokse og altså ikke via et fritekstfelt.
>
> Ah, damn! Ok, så behøver du Javascript.
Ja, det var også her, det gik op for mig
>
> > Kriterierne er på forhånde udvalgt af mig og kunne f.eks. være
> > "aids[sb]" eller "developing countries[mh]". Imellem disse skal
> > indsættes en boolsk operator, dog oftest "AND". En "færdig" URL
> > ville se således:
> > http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=PureSearch&db=p
> > ubmed&details_term=aids[sb]+AND+developing+countries[mh]
>
> Ok, lad os antage at der er nogle checkboxe og et par radioknapper
> til at vælge operatoren. Jeg putter dem i en form for sig selv,
> for at undgå at de bliver sendt med. Så bruger jeg en funktion til
> at pille værdien ud af alle checkboxene der er valgt, og sætter
> dem sammen med enten " AND " eller " OR ". Den sammensatte værdi
> bliver så skrevet ind i den rigtige form inden den bliver submittet.
> ---
> <!-- dette er en anden form, ikke den der skal submittes! -->
> <form action="" id="inputForm" name="inputForm">
> <p>Operator:
> <input type="radio" name="operator" id="andOperator"
> checked="checked">
> <label for="andOperator">AND</label>
> <input type="radio" name="operator" id="orOperator">
> <label for="orOperator">OR</label>
> </p>
>
> <p>Søgekriterier:</p>
> <p>
> <input type="checkbox" name="krit" value="aids[sb]"> aids[sb]
> </p>
> <p>
> <input type="checkbox" name="krit"
> value="developing countries[mh]"> developing countries[mh]
> </p>
> </form>
> <form action="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi"
> onsubmit="populate(this)">
> <input type="hidden" name="cmd" value="PureSearch">
> <input type="hidden" name="db" value="pubmed">
> <input type="hidden" name="details_term">
>
> <input type="submit" value="Søg!">
> </form>
> <script type="text/javascript">
> function populate(form) {
> var subjects = [];
> var inputElems = document.forms['inputForm'].elements;
> for (var i=0; i<inputElems.length;i++) {
> var elem = inputElems[i];
> if (elem.type == "checkbox" && elem.checked) {
> subjects[subjects.length] = elem.value;
> }
> }
>
> var andOp = document.getElementById("andOperator").checked;
> var operator = andOp ? " AND " : " OR ";
> form.elements['details_term'].value =
> subjects.join(operator);
> }
> </script>
> ---
>
> Man kan så bare tilføje flere checkbox'e til den første form hvis man vil
> have flere valgmuligheder.
>
> Held og lykke.
> /L
> --
> Lasse Reichstein Nielsen - lrn@hotpop.com

Kære Lasse,

Det er simpelthen et fantastisk stykke kode, du der har lavet. Jeg har siddet
med det nogle timer i dag, hvor jeg også har kigget nærmere på, hvad PubMed
selv har af ekstra søgefunktioner
(http://www.ncbi.nlm.nih.gov/entrez/query.fcgi -> klik på "Limits"). Det er
blevet til dette: http://www.aidsnet.dk/Files/HTML/Aidsnet/PubMed.htm

Når man sådan roder med de forskelige felter, opstår der pludselig nye behov...

Som du kan se, har jeg inddelt søgekriterierne, der danner "term", i grupperne
"Regions", "Country status", "Target groups" og "Research type". Her opstår et
problem med de boolske operatorer, da man gerne skal kunne vælge, om man vil
sætte AND eller OR mellem kriterierne <i>inden for</i> de enkelte grupper, mens
der blot skal stå AND <i>mellem</i> de enkelte grupper. Den måde, som du lavede
det på, muliggør kun, at man vælger enten AND eller OR mellem <i>alle</i>
kriterer. Tror du, at det, jeg beskriver, kan lade sig gøre?

De resterende kriterier ("Language", "Age group" og "Gender") fungerer under
FORM, så der er ingen problemer; men hvordan kan jeg flytte dem andre steder
hen i formularen? Hvis jeg flytter dem ind i "inputForm"-formularen, bliver de
(naturligvis) ikke sendt med til http://www.ncbi.nlm.nih.gov/entrez/query.fcgi.

Og en sidste ting... Hvorden laver man en reset-knap? Type="reset" virker ikke.

Måske er du interesseret i at vide, hvad søgeformularen egentlig skal bruges
til...

Jeg er studentermedhjælp hos Aidsnet, der er et netværk for danske NGO'er og
enkelte forskningsinstitutioner, der beskæftiger sig med hiv/aids i
udviklingslande. Et af hovedmålene med netværket er, at NGO'erne skal blive
bedre til at bruge forskning i deres arbejde - det er desværre noget, der
halter i dag. En af grundene til denne manglende brug er, at de ansatte i
NGO'erne ikke kan overskue de enorme mængder information, der findes om
hiv/aids og udvikling - og resultatet er oftest, at de vælger ikke at søge
efter litteratur eller ikke ved, hvordan videnskabelig litteratur af høj
kvalitet identificeres.

En af de primære databaser på vores område er PubMed, men da måden at angive
korrekte søgekriterier på, kræver en del tid at sætte sig ind i, mente jeg, at
et "interface" via vores hjemmeside, www.aidsnet.dk, til søgninger i PubMed,
ville være en god idé. Det smarte er, at jeg eller andre, der har lidt mere
tjek på det med PubMed-søgekriterier, kan præ-definere søgningerne ved at
tilkoble søgestrenge til populære søgekriterier, såsom "Developing countries"
(det er f.eks. ikke tilstrækkeligt blot at søge på ordene "developing" og
"countries" - man bør i stedet bruge et MeSH term, som automatisk inkluderer
flere varianter, samt evt. selv tilknytte yderligere termer, f.eks. "lov*income
countr*").

Mit håb er, at et sådan interface vil lette adgangen til forskningen for de
ansatte i NGO'erne, og at de (forhåbentlig) vil føle, at antallet af de
målrettede søgeresultater er mere overskueligt.

Bliver det en success, vil vi opfordre vores medlemsorganisationer til at
anvende koden på deres egne hjemmesider, lissom denne mulighed naturligvis også
vil være interessant for vores partnere i udviklingslandene.

Dit navn kommer naturligvis til at stå i koden og på www.aidsnet.dk

Jeg håber virkelig, at du (og måske andre, der læser dette!) har lyst til at
kigge på de sidste tilretninger i koden, så den kan blive helt perfekt.

- Ole




--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Hmm, måske er Lasse taget på sommerferie...

Er der andre, der har tid og lyst til at give mig en hjælpende hånd?

- Ole

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Hej Ole Nørgaard

- det er muligt at Lasse begynder at synes at hans indsats er lovlig
stor i forhold til at det er dig der får løn som studentermedhjælp, og
grupperne nu engang (i hvert fald for mange af os) gerne skal være hjælp
til selvhjælp.

Anyway: jeg har egentlig ikke tid, men vil godt prøve at hjælpe lidt -
jeg er ikke super-haj til javascript, men jeg plejer at være god til at
støve metoder at gøre tingene på, op.

Jeg har ikke været med i dit projekt her fra starten, og vil helst ikke
bruge en _masse_ tid på at sætte mig ind i det (fordi den tid går fra
mit speciale og de arbejdstimer som jeg får løn for, så jeg kan leve
selvom jeg er bagud med det speciale :-/ ).

SÅ: hvis jeg forstår dig, og den kode du allerede har, rigtigt, så skal
du gerne kunne sammensætte en søgestreng med en række parametre, og
vælge om der skal være AND eller OR imellem undervejs for hver enkelt
parameter i stedet for konsekvent enten AND eller OR.

Basalt set kan vi gå to veje: vi kan lave en formular, og så kan vi
inden afsending sammensætte ud fra hvad der er krydset af i formularen,
ELLER vi kan lave en indsætningsmaskine som sammensætter en streng
løbende, ved at bruge noget i stil med
<http://www.astro.wisc.edu/~dolan/constants/calc.html>

Det du allerede har, bygger på førnævnte af de to koncepter, og det gør
at vi ikke får problemer med hvis brugeren ændrer sine beslutninger
undervejs, så det er muligvis klogt at holde sig til hvis vi kan finde
ud af det.

Jeg synes til en start at du skal smække labels på _alle_ checkbox/radio
inputs'ne.

Ole Nørgaard skrev:
> Det er simpelthen et fantastisk stykke kode, du der har lavet. Jeg har siddet
> med det nogle timer i dag, hvor jeg også har kigget nærmere på, hvad PubMed
> selv har af ekstra søgefunktioner
> (http://www.ncbi.nlm.nih.gov/entrez/query.fcgi -> klik på "Limits"). Det er
> blevet til dette: http://www.aidsnet.dk/Files/HTML/Aidsnet/PubMed.htm

Hvad er egl. grunden til at du fravælger deres "only items with
abstracts" - mulighed og ligeledes at du ikke vil give mulighed for at
indskrænke på dato + publikationstype?

> Når man sådan roder med de forskelige felter, opstår der pludselig nye behov...
>
> Som du kan se, har jeg inddelt søgekriterierne, der danner "term", i grupperne
> "Regions", "Country status", "Target groups" og "Research type". Her opstår et
> problem med de boolske operatorer, da man gerne skal kunne vælge, om man vil
> sætte AND eller OR mellem kriterierne <i>inden for</i> de enkelte grupper, mens
> der blot skal stå AND <i>mellem</i> de enkelte grupper. Den måde, som du lavede
> det på, muliggør kun, at man vælger enten AND eller OR mellem <i>alle</i>
> kriterer. Tror du, at det, jeg beskriver, kan lade sig gøre?

(Alt kan lade sig gøre - men - ) kan du ikke opsætte fieldsets på
hvor der skal kunne være AND, og hvor der skal kunne være AND/OR så det
bliver meget tydeligt hvad vi skal have gjort?

> De resterende kriterier ("Language", "Age group" og "Gender") fungerer under
> FORM, så der er ingen problemer; men hvordan kan jeg flytte dem andre steder
> hen i formularen? Hvis jeg flytter dem ind i "inputForm"-formularen, bliver de
> (naturligvis) ikke sendt med til http://www.ncbi.nlm.nih.gov/entrez/query.fcgi.

Prøv evt - gerne på en separat side så vi ikke ødelægger det vi har til
at fungere - at lave en opsætning som du gerne vil have det til at se
ud. Hvis du på nogen måde _kan_ holde de to forms adskildt, så gør det -
hvis ikke, må vi se på hvad der kan gøres alligevel.

> Og en sidste ting... Hvorden laver man en reset-knap? Type="reset" virker ikke.

nej, der skal vi have fat i en javascript, pubmed bruger
<input name="Clear" type="button" value="Clear"
onClick="this.form.term.value='';this.form.term.focus();"> - den skal
evt udvides til at omfatte flere felter eller hele formen. Hvis det er
mange felter skal du have en function til det, jeg har en liggende et
sted

> Jeg er studentermedhjælp hos Aidsnet, der er et netværk for danske NGO'er og
> enkelte forskningsinstitutioner, der beskæftiger sig med hiv/aids i
> udviklingslande. Et af hovedmålene med netværket er, at NGO'erne skal blive
> bedre til at bruge forskning i deres arbejde - det er desværre noget, der
> halter i dag. En af grundene til denne manglende brug er, at de ansatte i
> NGO'erne ikke kan overskue de enorme mængder information, der findes om
> hiv/aids og udvikling - og resultatet er oftest, at de vælger ikke at søge
> efter litteratur eller ikke ved, hvordan videnskabelig litteratur af høj
> kvalitet identificeres.

Jeg tror du skal overveje om der også er en sprogbarriere, så du evt
skal alliere dig med en fransk- og eller spansk-kyndig når du når til
videre-udbredelsesprocessen, men det er en anden sag som du tids nok når
til

mvh

Jesper Brunholm

---

Jesper Brunholm wrote in dk.edb.internet.webdesign.clientside:
> Hej Ole Nørgaard
>
> - det er muligt at Lasse begynder at synes at hans indsats er lovlig
> stor i forhold til at det er dig der får løn som studentermedhjælp, og
> grupperne nu engang (i hvert fald for mange af os) gerne skal være hjælp
> til selvhjælp.

Du har helt ret. Jeg tænkte skam også over, om det nu var for meget at spørge, når
jeg ikke selv kan bidrage med så meget. Men man får jo helt sikkert ikke noget ud
af /ikke/ at spørge Når det gælder JavaScript må jeg sande, at jeg er nødt til
at have en del hjælp, før selvhjælp kan komme på tale...

Mht. til at det er mig, der får løn som studentermedhjælp, så vil jeg da godt lige
indskyde, at jeg normalt ikke tager mig betalt for alle de timer, jeg bruger på
disse mere sekundære ting, hvor mine kompetencer ikke rækker...

> SÅ: hvis jeg forstår dig, og den kode du allerede har, rigtigt, så skal
> du gerne kunne sammensætte en søgestreng med en række parametre, og
> vælge om der skal være AND eller OR imellem undervejs for hver enkelt
> parameter i stedet for konsekvent enten AND eller OR.

Helt korrekt!

> Det du allerede har, bygger på førnævnte af de to koncepter, og det gør
> at vi ikke får problemer med hvis brugeren ændrer sine beslutninger
> undervejs, så det er muligvis klogt at holde sig til hvis vi kan finde
> ud af det.

Ja, lyder rimeligt.

> Hvad er egl. grunden til at du fravælger deres "only items with
> abstracts" - mulighed og ligeledes at du ikke vil give mulighed for at
> indskrænke på dato + publikationstype?

Disse muligheder er også med i den nye udgave. Første udgave var blot et udkast,
hvor der kunne kobles flere begræsninger på.

> > Når man sådan roder med de forskelige felter, opstår der pludselig nye
behov...
> >
> > Som du kan se, har jeg inddelt søgekriterierne, der danner "term", i grupperne
> > "Regions", "Country status", "Target groups" og "Research type". Her opstår et
> > problem med de boolske operatorer, da man gerne skal kunne vælge, om man vil
> > sætte AND eller OR mellem kriterierne <i>inden for</i> de enkelte grupper,
mens
> > der blot skal stå AND <i>mellem</i> de enkelte grupper. Den måde, som du
lavede
> > det på, muliggør kun, at man vælger enten AND eller OR mellem <i>alle</i>
> > kriterer. Tror du, at det, jeg beskriver, kan lade sig gøre?
>
> (Alt kan lade sig gøre - men - ) kan du ikke opsætte fieldsets på
> hvor der skal kunne være AND, og hvor der skal kunne være AND/OR så det
> bliver meget tydeligt hvad vi skal have gjort?
>
> > De resterende kriterier ("Language", "Age group" og "Gender") fungerer under
> > FORM, så der er ingen problemer; men hvordan kan jeg flytte dem andre steder
> > hen i formularen? Hvis jeg flytter dem ind i "inputForm"-formularen, bliver de
> > (naturligvis) ikke sendt med til
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi.
>
> Prøv evt - gerne på en separat side så vi ikke ødelægger det vi har til
> at fungere - at lave en opsætning som du gerne vil have det til at se
> ud. Hvis du på nogen måde _kan_ holde de to forms adskildt, så gør det -
> hvis ikke, må vi se på hvad der kan gøres alligevel.

Jeg prøvede først at sætte labels på alle checkbokse og radioinputs samt lave
fieldsets, som du beder om (jeg nåede hertil:
http://www.aidsnet.dk/Files/HTML/Aidsnet/SearchDB/PubMed2.htm men kom på andre
tanker, inden jeg blev helt færdig).

Det viste sig at blive noget værre rod, når jeg satte det op i den rækkefølge og
gruppering, som jeg forestiller mig skal være i den endelige formular. Derfor
ændrede jeg formularen til dette:
http://www.aidsnet.dk/Files/HTML/Aidsnet/SearchDB/PubMed4.htm, og det er denne
formular, som jeg synes, at vi skal tage udgangspunkt i.

Der mangler stadig en del layout, og radioknapperne o.s.v. vil naturligvis blive
markeret mere tydeligt. Men da det nok kræver nogle tabeller, venter jeg for
overskueligheden skyld med dette. Selve søgestrategierne er ligeledes langt fra
færdigudviklede.

Det vigtigste, som jeg har ændret i forhold til første udgave af søgeformularen
(http://www.aidsnet.dk/Files/HTML/Aidsnet/SearchDB/PubMed.htm), er at ændre på
funktionen, der indsætter AND eller OR mellem alle parametrene. I stedet har jeg
indsat "AND ", "OR " eller "NOT " foran alle parametre. Måske knapt så tjekket,
men det virker efter hensigten. Og dog... Det opstår et problem i forbindelse med
gruppen "Target groups", hvis parametre skal angives i parenteser, før det giver
mening. Derfor skal AND, OR eller NOT på en eller anden måde fjernes og erstattes
med "AND (" i det første parameter, der vælges i "Target groups". Gruppen skal
naturligvis afsluttes med ")". Er det måske en helt separat form, der skal bruges
her?

Skal den nuværende operatorfunktion evt. fjernes, da den jo nu ikke indsætter
nogen tegn? (jeg kunne ikke finde ud af at fjerne den!)

Jeg har JavaScriptet indsat "AIDS[sb]" som standard som det allerførste parameter
i alle søgninger, da det ikke er muligt at indlede med en boolsk operator. Jeg er
klar over, at jeg også har valgt at lade "pmfilter_Subsets" være lig med "AIDS",
hvilket giver samme resultat. Grunden er, at brugerne herved vil kunne se, at
AIDS-filteret er blevet brugt (angives i den gule line på PubMed, der indledes med
"Limits:"). At denne parameter angives to gange, har ikke indflydelse på
søgeresultatet.

> > Og en sidste ting... Hvorden laver man en reset-knap? Type="reset" virker
ikke.
>
> nej, der skal vi have fat i en javascript, pubmed bruger
> <input name="Clear" type="button" value="Clear"
> onClick="this.form.term.value='';this.form.term.focus();"> - den skal
> evt udvides til at omfatte flere felter eller hele formen. Hvis det er
> mange felter skal du have en function til det, jeg har en liggende et
> sted

Jeg tror, at der kun bliver brug for en reset-knap, der rydder hele formularen.
Det, du angiver, virker desværre ikke. Er det fordi, at den kun rydder
tekstfeltet, der hedder "term"?

> Jeg tror du skal overveje om der også er en sprogbarriere, så du evt
> skal alliere dig med en fransk- og eller spansk-kyndig når du når til
> videre-udbredelsesprocessen, men det er en anden sag som du tids nok når
> til

At kunne finde litteratur i PubMed kræves jo, at man kan engelsk, men du har ret
i, at det ville være en god service med forklaringer o.s.v. på f.eks. fransk og
spansk. Heldigvis vader vi i folk, der kan den slags

Jeg er virkelig glad for at du gider at hjælpe. Jeg er sikker på, at denne let
tilgængelige formular vil kunne hjælpe en masse folk til at anvende forskning i
deres hiv/aids-arbejde.

- Ole

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Ole Nørgaard wrote:

> Mht. til at det er mig, der får løn som studentermedhjælp, så vil jeg da godt lige
> indskyde, at jeg normalt ikke tager mig betalt for alle de timer, jeg bruger på
> disse mere sekundære ting, hvor mine kompetencer ikke rækker...

Det synes jeg sådan set ikke er den rigtige måde - du er lige så stor en
konkurrencefaktor for dem der skal have penge for tilsvarende arbejde,
så du bør tage noget for det, selv om du måske omregner til "udbytte for
arbejdsgiver"-timer

> Jeg prøvede først at sætte labels på alle checkbokse og radioinputs samt lave
> fieldsets, som du beder om (jeg nåede hertil:
> http://www.aidsnet.dk/Files/HTML/Aidsnet/SearchDB/PubMed2.htm men kom på andre
> tanker, inden jeg blev helt færdig).
>
> Det viste sig at blive noget værre rod, når jeg satte det op i den rækkefølge og
> gruppering, som jeg forestiller mig skal være i den endelige formular. Derfor
> ændrede jeg formularen til dette:
> http://www.aidsnet.dk/Files/HTML/Aidsnet/SearchDB/PubMed4.htm, og det er denne
> formular, som jeg synes, at vi skal tage udgangspunkt i.
>
> Der mangler stadig en del layout, og radioknapperne o.s.v. vil naturligvis blive
> markeret mere tydeligt. Men da det nok kræver nogle tabeller, venter jeg for
> overskueligheden skyld med dette. Selve søgestrategierne er ligeledes langt fra
> færdigudviklede.

Jeg har et par input (som du så må vurdere om du er enig i)
Når du lægger op til at vælge imellem:
UNCHOSEN AND OR NOT
() () () () Africa
() () () () Asia [osv...]

så gør du alt andet end at tydeliggøre at unchosen = 4xand. Det
pædagogiske ville set fra mit synspunkt være at gå ud fra 4x AND, og så
checker vi med javascript om det er tilfældet, hvorefter vi undlader at
sende parametrene videre...

Dette kan videreføres til en del andet af formularen.

Jeg synes vi skal have en doctype på, du kan læse mere om hvorfor her:
<http://html-faq.dk/1005.asp>, og et eksempel på hvordan her:
<http://www.garion.dk/webdesign/pubmed/> (hvor jeg også har ændret et
par ting i koden for at den validerer, jeg har valgt html4 transitional
fordi den er let at få til at validere - god at starte med

Jeg har sat labels på en hel del, men ikke ændret på de steder hvor du
bruger <font> osv til formattering - selv om jeg synes du bør bruge css
til at formattere med i stedet for.

> Det vigtigste, som jeg har ændret i forhold til første udgave af søgeformularen
> (http://www.aidsnet.dk/Files/HTML/Aidsnet/SearchDB/PubMed.htm), er at ændre på
> funktionen, der indsætter AND eller OR mellem alle parametrene. I stedet har jeg
> indsat "AND ", "OR " eller "NOT " foran alle parametre. Måske knapt så tjekket,
> men det virker efter hensigten. Og dog... Det opstår et problem i forbindelse med
> gruppen "Target groups", hvis parametre skal angives i parenteser, før det giver
> mening. Derfor skal AND, OR eller NOT på en eller anden måde fjernes og erstattes
> med "AND (" i det første parameter, der vælges i "Target groups". Gruppen skal
> naturligvis afsluttes med ")". Er det måske en helt separat form, der skal bruges
> her?
>
> Skal den nuværende operatorfunktion evt. fjernes, da den jo nu ikke indsætter
> nogen tegn? (jeg kunne ikke finde ud af at fjerne den!)
>
> Jeg har JavaScriptet indsat "AIDS[sb]" som standard som det allerførste parameter
> i alle søgninger, da det ikke er muligt at indlede med en boolsk operator. Jeg er
> klar over, at jeg også har valgt at lade "pmfilter_Subsets" være lig med "AIDS",
> hvilket giver samme resultat. Grunden er, at brugerne herved vil kunne se, at
> AIDS-filteret er blevet brugt (angives i den gule line på PubMed, der indledes med
> "Limits:"). At denne parameter angives to gange, har ikke indflydelse på
> søgeresultatet.

Det her er jeg nødt til at vende tilbage til i eftermiddag, jeg må løbe
nu

>>>Og en sidste ting... Hvorden laver man en reset-knap? Type="reset" virker

> Jeg tror, at der kun bliver brug for en reset-knap, der rydder hele formularen.
> Det, du angiver, virker desværre ikke. Er det fordi, at den kun rydder
> tekstfeltet, der hedder "term"?

jep - jeg har lagt en nulstiller ind, hvis den er for kraftig, må vi evt
lige modde den til at tage et form-id som parameter

mvh

Jesper

---

Jesper Brunholm wrote in dk.edb.internet.webdesign.clientside:
> Ole Nørgaard wrote:
>
> > Mht. til at det er mig, der får løn som studentermedhjælp, så vil jeg da godt lige
> > indskyde, at jeg normalt ikke tager mig betalt for alle de timer, jeg bruger på
> > disse mere sekundære ting, hvor mine kompetencer ikke rækker...
>
> Det synes jeg sådan set ikke er den rigtige måde - du er lige så stor en
> konkurrencefaktor for dem der skal have penge for tilsvarende arbejde,
> så du bør tage noget for det, selv om du måske omregner til "udbytte for
> arbejdsgiver"-timer

Njah, der ved jeg nu ikke, om jeg vil give dig helt ret. Hvis det ikke var muligt for
os at gøre det på denne måde, ville der aldrig blive lavet sådan nogle små smarte ting,
som en PubMed-søgeformular. Aidsnet er ikke en profitskabende virksomhed, og der er
utroligt mange mennesker med i beslutningsprocessen, hver gang der skal bevilges penge
til noget. At skulle overbevise en større gruppe "off-line"-mennesker om en
søgeformulars fortræffeligheder, før de faktisk kan se på en skærm, hvad det går ud på,
vurderer jeg som en ualmindelig svær opgave. Derfor ville der sandsynligvis aldrig
blive afsat penge udvikling af den slags IT-løsninger.

Kan vi derimod præsentere sådanne færdige ting, uden at de skal tage stilling til
noget, er de fremtidige chancer for, at der gives midler til lignende ting, langt
større. Aidsnet er mindre end ét år gammelt, så vi to ansatte skal stadig arbejde hårdt
på at overbevise dem, der bestemmer, om alle vores gode idéer .

Og så skal det også lige bemærkes, at jeg har en stor studiemæssig interesse i at bruge
de store sundhedsvidenskabelige databaser...
>
> Jeg har et par input (som du så må vurdere om du er enig i)
> Når du lægger op til at vælge imellem:
> UNCHOSEN AND OR NOT
> () () () () Africa
> () () () () Asia [osv...]
>
> så gør du alt andet end at tydeliggøre at unchosen = 4xand. Det
> pædagogiske ville set fra mit synspunkt være at gå ud fra 4x AND, og så
> checker vi med javascript om det er tilfældet, hvorefter vi undlader at
> sende parametrene videre...

Ved ikke, om jeg forstår dig ret. Det er /ikke/ meningen, at der som udgangspunkt skal
være AND mellem de 4 første parametre. Hvis man gør det, begrænses søgning alt for
meget (og er uhensigtmæssig). Derfor bør parametrene som standard give en blank værdi.
"Unchosen" er altså ikke = 4 x AND.

Den måde, du har byttet rundt på regionsnavnet og operatorerne, synes jeg ikke gør det
mere pædagogisik, da jeg tror, at det let vil forstås således, at man kan vælge, hvad
der skal angives /efter/ hvert parameter og ikke /før/.
>
> Dette kan videreføres til en del andet af formularen.
>
> Jeg synes vi skal have en doctype på, du kan læse mere om hvorfor her:
> <http://html-faq.dk/1005.asp>, og et eksempel på hvordan her:
> <http://www.garion.dk/webdesign/pubmed/> (hvor jeg også har ændret et
> par ting i koden for at den validerer, jeg har valgt html4 transitional
> fordi den er let at få til at validere - god at starte med

Det er jeg med på; men koden skal kunne indsættes på en eksisterende side via et CMS.
Derfor skal koden ikke indeholde doctype, <head>-sektion o.s.v. - det er allerede
angivet i den template, vi bruger.
>
> Jeg har sat labels på en hel del, men ikke ændret på de steder hvor du
> bruger <font> osv til formattering - selv om jeg synes du bør bruge css
> til at formattere med i stedet for.

Igen er det CMS'et, der sætter nogle begrænsninger. Alt CSS er defineret, før
formular-koden indsættes. Hvis jeg derefter har brug for særlige formatteringer, må jeg
ændre i det overordnede stylesheet.
>
> > Jeg har i JavaScriptet indsat "AIDS[sb]" som standard som det allerførste parameter
> > i alle søgninger, da det ikke er muligt at indlede med en boolsk operator. Jeg er
> > klar over, at jeg også har valgt at lade "pmfilter_Subsets" være lig med "AIDS",
> > hvilket giver samme resultat. Grunden er, at brugerne herved vil kunne se, at
> > AIDS-filteret er blevet brugt (angives i den gule line på PubMed, der indledes med
> > "Limits:"). At denne parameter angives to gange, har ikke indflydelse på
> > søgeresultatet.
>
> Det her er jeg nødt til at vende tilbage til i eftermiddag, jeg må løbe
> nu

OK - jeg vil glæde mig som et lille barn
>
> jep - jeg har lagt en nulstiller ind, hvis den er for kraftig, må vi evt
> lige modde den til at tage et form-id som parameter

Den er nok lige kraftig nok. Jeg tror, at det bedste ville være, om man blot kom
tilbage til udgangspunktet.

- Ole

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Ole Nørgaard wrote:

>>Jeg har et par input (som du så må vurdere om du er enig i)
>>Når du lægger op til at vælge imellem:
>>UNCHOSEN AND OR NOT
>>() () () () Africa
>>() () () () Asia [osv...]
>>
>>så gør du alt andet end at tydeliggøre at unchosen = 4xand. Det
>>pædagogiske ville set fra mit synspunkt være at gå ud fra 4x AND, og så
>>checker vi med javascript om det er tilfældet, hvorefter vi undlader at
>>sende parametrene videre...
>
>
> Ved ikke, om jeg forstår dig ret. Det er /ikke/ meningen, at der som udgangspunkt skal
> være AND mellem de 4 første parametre. Hvis man gør det, begrænses søgning alt for
> meget (og er uhensigtmæssig). Derfor bør parametrene som standard give en blank værdi.
> "Unchosen" er altså ikke = 4 x AND.

ok, så havde jeg misforstået noget, men så må udgangspunktet
(=unchecked) vel være at der er OR imellem de fire?

> Den måde, du har byttet rundt på regionsnavnet og operatorerne, synes jeg ikke gør det
> mere pædagogisik, da jeg tror, at det let vil forstås således, at man kan vælge, hvad
> der skal angives /efter/ hvert parameter og ikke /før/.

tjah - ok. Du har ret. Under alle omstændigheder vil du nok øge
anvendeligheden/udbyttet en del ved at lave et par velguidede
eksempelsøgninger

>>Jeg synes vi skal have en doctype på, du kan læse mere om hvorfor her:
>><http://html-faq.dk/1005.asp>, og et eksempel på hvordan her:
>><http://www.garion.dk/webdesign/pubmed/> (hvor jeg også har ændret et
>>par ting i koden for at den validerer, jeg har valgt html4 transitional
>>fordi den er let at få til at validere - god at starte med
>
> Det er jeg med på; men koden skal kunne indsættes på en eksisterende side via et CMS.
> Derfor skal koden ikke indeholde doctype, <head>-sektion o.s.v. - det er allerede
> angivet i den template, vi bruger.

ahh - ok. Jeg kan bare også godt lide at vide at den opfører sig
standard-kompliant når vi tester undervejs

>>Jeg har sat labels på en hel del, men ikke ændret på de steder hvor du
>>bruger <font> osv til formattering - selv om jeg synes du bør bruge css
>>til at formattere med i stedet for.
>
> Igen er det CMS'et, der sætter nogle begrænsninger. Alt CSS er defineret, før
> formular-koden indsættes. Hvis jeg derefter har brug for særlige formatteringer, må jeg
> ændre i det overordnede stylesheet.

ok - det er jo nok meget godt i virkeligheden. Så bliver det vel
effektløst med de font-tags som ligger i koden nu?

Kan du i øvrigt lægge class-definitioner ind i cms-css'en?

>>>Jeg har i JavaScriptet indsat "AIDS[sb]" som standard som det allerførste parameter
>>>i alle søgninger, da det ikke er muligt at indlede med en boolsk operator. Jeg er
>>>klar over, at jeg også har valgt at lade "pmfilter_Subsets" være lig med "AIDS",
>>>hvilket giver samme resultat. Grunden er, at brugerne herved vil kunne se, at
>>>AIDS-filteret er blevet brugt (angives i den gule line på PubMed, der indledes med
>>>"Limits:"). At denne parameter angives to gange, har ikke indflydelse på
>>>søgeresultatet.
>>
>>
>>Det her er jeg nødt til at vende tilbage til i eftermiddag, jeg må løbe
>>nu
>
>
> OK - jeg vil glæde mig som et lille barn

Det bliver først i morgen - jeg fik alt for travlt, men jeg skal nok!

>>jep - jeg har lagt en nulstiller ind, hvis den er for kraftig, må vi evt
>>lige modde den til at tage et form-id som parameter
>
> Den er nok lige kraftig nok. Jeg tror, at det bedste ville være, om man blot kom
> tilbage til udgangspunktet.

av, den var værre (fordi vi så skal definere status for hvert enkelt
inputfelt). Så er det næsten lettere at refreshe (eller reloade) siden?

mvh

Jesper Brunholm

--
Phønix - dansk folk-musik i front - <http://www.phonixfolk.dk/>
H.C. Andersen-Centret: <http://www.andersen.sdu.dk/>

---

- et par overvejelser senere...

Ole Nørgaard wrote:

>>Jeg har et par input (som du så må vurdere om du er enig i)
>>Når du lægger op til at vælge imellem:
>>UNCHOSEN AND OR NOT
>>() () () () Africa
>>() () () () Asia [osv...]
>>
>>så gør du alt andet end at tydeliggøre at unchosen = 4xand. Det
>>pædagogiske ville set fra mit synspunkt være at gå ud fra 4x AND, og så
>>checker vi med javascript om det er tilfældet, hvorefter vi undlader at
>>sende parametrene videre...
>
> Ved ikke, om jeg forstår dig ret. Det er /ikke/ meningen, at der som udgangspunkt skal
> være AND mellem de 4 første parametre. Hvis man gør det, begrænses søgning alt for
> meget (og er uhensigtmæssig). Derfor bør parametrene som standard give en blank værdi.
> "Unchosen" er altså ikke = 4 x AND.

For mig at se viser min misforståelse behovet for at øge tydeliggøre
funktionen/effekten af AND/OR -valgene. Fx kan "unchosen" let
misforståes til at regionen ikke er valgt som muligt søgeområde. Det kan
vist lettest overkommes ved at indlede med en
"Search Worldwide (*) Regionalise search ( )" (parenteser er radiobokses
- jeg har illustreret det på min side
<http://www.garion.dk/webdesign/pubmed/>)

Kan du følge mig i at det øger gennemskueligheden?

Hvad AND/OR-default-debatten angår, så er det ud fra opstillingen (for
mig at se) let at tro at man _tilvælger_ _muligheder_ med AND, så det
skal nok forklares, at alt det der AND'es _skal_ opfyldes som kriterie,
hvorfor den er begrænsende. Det ville for mig at se være godt at komme
ud over valget af AND/OR med noget i retning af
"Results..."
"- *must* match this region" | "- can also match this region" - for
henholdsvis AND og OR parameteren.

Når man gør det bliver det tydeligt at "- can match all of the world"
eller "unchosen" er et mærkeligt valg at have for den enkelte af
regionerne (fordi det virker absurd at kunne vælge at en region skal
matches i den ene linie, og at vælge at hele verden er en mulighed i næste.

Kan der være søgehits på tværs af regioner? (fordi, hvis der ikke kan,
så skal vi have regionerne som radio-alternativer til hinanden på
AND-faktoren, og som alternativ til det, checkboxe til OR (?) )

MEN - javascript-teknisk er vi for mig at se ved at nå til at vi enten
skal sende nogle parametre med som PubMed så ikke bruger til noget (det
sker der sådan set ikke noget ved, det er bare spild at båndbredde),
eller vi skal lade nogle javascripts modificere indholdet af forskellige
input-variabler afhængigt af nogle andre, eller vi kan dele ud i flere
forms (de facto næsten samme løsning som foregående) ELLER vi skal lave
et javascript som gennemgår formens id'er og sammensætter en søgestreng
løbende, med if og else osv...

Jeg kan godt se at jeg problematiserer og besværer projektet, men jeg er
bange for at du ikke opnår det du vil, at hjælpe folk som ikke kan bruge
det nuværende interface, hvis ikke du går det skridt som jeg har
skitseret ovenfor.

Du er så velkommen til at sige at det er mere end du vil lægge i det, så
tager jeg et par skyklapper på min reflektion, og så nøjes vi med at
lave en løsning på det javascript-problem som du stiller op

mvh

Jesper Brunholm

---

> For mig at se viser min misforståelse behovet for at øge tydeliggøre
> funktionen/effekten af AND/OR -valgene. Fx kan "unchosen" let
> misforståes til at regionen ikke er valgt som muligt søgeområde. Det kan
> vist lettest overkommes ved at indlede med en
> "Search Worldwide (*) Regionalise search ( )" (parenteser er radiobokses
> - jeg har illustreret det på min side
> <http://www.garion.dk/webdesign/pubmed/>)
>
> Kan du følge mig i at det øger gennemskueligheden?
>
> Hvad AND/OR-default-debatten angår, så er det ud fra opstillingen (for
> mig at se) let at tro at man _tilvælger_ _muligheder_ med AND, så det
> skal nok forklares, at alt det der AND'es _skal_ opfyldes som kriterie,
> hvorfor den er begrænsende. Det ville for mig at se være godt at komme
> ud over valget af AND/OR med noget i retning af
> "Results..."
> "- *must* match this region" "- can also match this region" - for
> henholdsvis AND og OR parameteren.

Rigtig god idé - det vil jeg få skrevet ind, når koden er færdig.

> Når man gør det bliver det tydeligt at "- can match all of the world"
> eller "unchosen" er et mærkeligt valg at have for den enkelte af
> regionerne (fordi det virker absurd at kunne vælge at en region skal
> matches i den ene linie, og at vælge at hele verden er en mulighed i næste.
>
> Kan der være søgehits på tværs af regioner? (fordi, hvis der ikke kan,
> så skal vi have regionerne som radio-alternativer til hinanden på
> AND-faktoren, og som alternativ til det, checkboxe til OR (?) )

Ja, man kunne godt forestille sig, at brugerne ønsker søgeresultater, der matcher flere
regioner i én gang. Derfor vil det ikke være en god idé med radioknapper.

> MEN - javascript-teknisk er vi for mig at se ved at nå til at vi enten
> skal sende nogle parametre med som PubMed så ikke bruger til noget (det
> sker der sådan set ikke noget ved, det er bare spild at båndbredde),
> eller vi skal lade nogle javascripts modificere indholdet af forskellige
> input-variabler afhængigt af nogle andre, eller vi kan dele ud i flere
> forms (de facto næsten samme løsning som foregående) ELLER vi skal lave
> et javascript som gennemgår formens id'er og sammensætter en søgestreng
> løbende, med if og else osv...

Jeg ved ikke helt, om jeg forstår, hvad du mener med, at man kan sende parametre til
PubMed, som ikke bruges til noget. Det eneste, som jeg kan se ikke betyder noget, er, hvis
man sender det samme parameter med flere gange.

Umiddelbart - med min ringe viden om det her - så tror jeg, at der skal laves en løsning,
hvor flere forms sættes ind i hinanden, jvf. vores tidligere kommunikation, hvor jeg
foreslår, at "Taget groups"-sektionen laves til en selvstændig form. Dog vil der også her
være brug for at lave en modificering af den samlede søgestreng, således at operatoren, der
indledes med, udskiftes med "AND (", og strengen aflsuttes med ")".

> Jeg kan godt se at jeg problematiserer og besværer projektet, men jeg er
> bange for at du ikke opnår det du vil, at hjælpe folk som ikke kan bruge
> det nuværende interface, hvis ikke du går det skridt som jeg har
> skitseret ovenfor.
>
> Du er så velkommen til at sige at det er mere end du vil lægge i det, så
> tager jeg et par skyklapper på min reflektion, og så nøjes vi med at
> lave en løsning på det javascript-problem som du stiller op

Det er alletiders, at du ser kritisk på det, men jeg tror, at vi bedre kan få lavet det
pædagoisk korrekt ved først at få lavet koden og derefter putte layout og uddybende
forklaringer på. Men naturligvis er det også vigtigt, at koden passer sammen med måden, som
kriterierne skal angives på... (historien med hønen og ægget, ikke).

Jeg prøver at fortsætte på nærværende diskussionsstreng og svarer her på nogle spørgsmål
fra en ovenliggende (i samme niveau):

* ok, så havde jeg misforstået noget, men så må udgangspunktet
(=unchecked) vel være at der er OR imellem de fire?
- Måske er du ikke længere i tvivl om dette, jvf. ovenstående, men der skal ikke som
standard være OR imellem de fire valgmuligheder. Det skal nemlig også være muligt /ikke/ at
begrænse sin søgning til bestemte regioner.

* ok - det er jo nok meget godt i virkeligheden. Så bliver det vel
effektløst med de font-tags som ligger i koden nu?
Kan du i øvrigt lægge class-definitioner ind i cms-css'en?
- De to font-tags, der ligger i koden i nuværende tidspunkt, beder blot om, at
fontstørrelsen bliver gjort en tand mindre ned den aktuelle. Jeg kan dog se, at værdien nok
skal ændres fra "-1" til "-2", før det kan ses. Jeg kan godt lægge class-definitioner ind i
et seperat stylesheet, men jo færre af den slags løsninger, jo nemmere bliver det for andre
at overtage arbejdet engang.

*av, den var værre (fordi vi så skal definere status for hvert enkelt
inputfelt). Så er det næsten lettere at refreshe (eller reloade) siden?
- Ja - det vel nemt at tilkoble den funktion til "Clear form"-knappen, ikke?

- Ole

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Ole Nørgaard wrote:

> Ja, man kunne godt forestille sig, at brugerne ønsker søgeresultater, der matcher flere
> regioner i én gang. Derfor vil det ikke være en god idé med radioknapper.

men hvad så i stedet - det gør stor forskel på hvordan javascriptet skal
laves :/

Vi er nødt til at have en formularstruktur til at ligge rimelig fast
inden vi laver javascriptet.

>>MEN - javascript-teknisk er vi for mig at se ved at nå til at vi enten
>>skal sende nogle parametre med som PubMed så ikke bruger til noget (det
>>sker der sådan set ikke noget ved, det er bare spild at båndbredde),
>>eller vi skal lade nogle javascripts modificere indholdet af forskellige
>>input-variabler afhængigt af nogle andre, eller vi kan dele ud i flere
>>forms (de facto næsten samme løsning som foregående) ELLER vi skal lave
>>et javascript som gennemgår formens id'er og sammensætter en søgestreng
>>løbende, med if og else osv...
>
>
> Jeg ved ikke helt, om jeg forstår, hvad du mener med, at man kan sende parametre til
> PubMed, som ikke bruges til noget.

Fx. den "search worldwide"-parameter - hvis vi bare gennemgår scriptet
for alle parametre som det ser ud hos mig lige nu så vil den komme med,
men vil ikke blive brugt til noget fordi deres script ikke tager hensyn
til parametre som er ukendte. Der er sikkert også ret ligeglade med om
vi lægger en "&Jesper=gummiand" ind i enden af Query-strengen

> Det eneste, som jeg kan se ikke betyder noget, er, hvis
> man sender det samme parameter med flere gange.

> Umiddelbart - med min ringe viden om det her - så tror jeg, at der skal laves en løsning,
> hvor flere forms sættes ind i hinanden, jvf. vores tidligere kommunikation, hvor jeg
> foreslår, at "Taget groups"-sektionen laves til en selvstændig form. Dog vil der også her
> være brug for at lave en modificering af den samlede søgestreng, således at operatoren, der
> indledes med, udskiftes med "AND (", og strengen aflsuttes med ")".

Jeg vil vist hellere holde dem hver for sig (altså)

|-- form 1 ---------------|
| en masse input |
|_________________________|

|-- form 2 ---------------|
|... osv

- for så er der ingen tvivl om hvilke data der kommer hvorfra, og så er
de lette at parse igennem jf form-ID's :)

Altså - den nuværende funktion til at hive data ud af 1 form:

var inputElems = document.forms['inputForm'].elements;
for (var i=0; i<inputElems.length;i++) {
var elem = inputElems[i];
if (elem.type == "radio" && elem.checked) {
subjects[subjects.length] = elem.value;
}
if (elem.type == "checkbox" && elem.checked) {
subjects[subjects.length] = elem.value;
}
}

kan let gentages idet man blot angiver et andet form-ID end 'inputForm'.


> * ok, så havde jeg misforstået noget, men så må udgangspunktet
> (=unchecked) vel være at der er OR imellem de fire?
> - Måske er du ikke længere i tvivl om dette, jvf. ovenstående, men der skal ikke som
> standard være OR imellem de fire valgmuligheder. Det skal nemlig også være muligt /ikke/ at
> begrænse sin søgning til bestemte regioner.

OK, men hvis vi har en "search worldwide" som er lig med 4x unchecked,
er den bredeste søgning derefter så ikke 4 x OR, og den bredeste
_derefter_ 1 x AND og 3x OR? I så fald vil jeg mene at det giver god
mening at

* fjerne "unchosen"
* tilføje "worldwide" / "limit to region(s)"....
* have default=4 x OR når der er trykket på "limit to regions", og at de
checkbokse automatisk er deaktiveret hvis der er valgt "worldwide".

> *av, den var værre (fordi vi så skal definere status for hvert enkelt
> inputfelt). Så er det næsten lettere at refreshe (eller reloade) siden?
> - Ja - det vel nemt at tilkoble den funktion til "Clear form"-knappen, ikke?

nu har jeg lavet et regulært link til samme side - det gør jobbet

Jeg har fået fjernet den unødvendige operator, men jeg er en smule blank
på hvor vi videre skal hen.

Jeg mangler en færdig formular hvor alt er som det skal se ud, og hvor
det med kommentarer er tydeligt hvad der skal AND's, parenteser osv osv
ind imellem under hvilke omstændigheder.

Hvis der er dele af min forklaring du ikke kan følge så vær ikke bange
for at sige til!

mvh

Jesper Brunholm

---

Jesper Brunholm wrote in dk.edb.internet.webdesign.clientside:
> Ole Nørgaard wrote:
>
> > Ja, man kunne godt forestille sig, at brugerne ønsker søgeresultater, der matcher flere
> > regioner i én gang. Derfor vil det ikke være en god idé med radioknapper.
>
> men hvad så i stedet - det gør stor forskel på hvordan javascriptet skal
> laves :/

Det bliver nok nødt til at være en mulighed for at undlade at sende værdier med overhovedet - se
længere nede.
>
> > Umiddelbart - med min ringe viden om det her - så tror jeg, at der skal laves en løsning,
> > hvor flere forms sættes ind i hinanden, jvf. vores tidligere kommunikation, hvor jeg
> > foreslår, at "Taget groups"-sektionen laves til en selvstændig form. Dog vil der også her
> > være brug for at lave en modificering af den samlede søgestreng, således at operatoren, der
> > indledes med, udskiftes med "AND (", og strengen aflsuttes med ")".
>
> Jeg vil vist hellere holde dem hver for sig (altså)
>
> -- form 1 ---------------
> en masse input
> _________________________
>
> -- form 2 ---------------
> ... osv
>
> - for så er der ingen tvivl om hvilke data der kommer hvorfra, og så er
> de lette at parse igennem jf form-ID's :)
>
> Altså - den nuværende funktion til at hive data ud af 1 form:
>
> var inputElems = document.forms['inputForm'].elements;
> for (var i=0; i<inputElems.length;i++) {
> var elem = inputElems[i];
> if (elem.type == "radio" && elem.checked) {
> subjects[subjects.length] = elem.value;
> }
> if (elem.type == "checkbox" && elem.checked) {
> subjects[subjects.length] = elem.value;
> }
> }
>
> kan let gentages idet man blot angiver et andet form-ID end 'inputForm'.

Lyder som måden at gøre det på.
>
>
> > * ok, så havde jeg misforstået noget, men så må udgangspunktet
> > (=unchecked) vel være at der er OR imellem de fire?
> > - Måske er du ikke længere i tvivl om dette, jvf. ovenstående, men der skal ikke som
> > standard være OR imellem de fire valgmuligheder. Det skal nemlig også være muligt /ikke/ at
> > begrænse sin søgning til bestemte regioner.
>
> OK, men hvis vi har en "search worldwide" som er lig med 4x unchecked,
> er den bredeste søgning derefter så ikke 4 x OR, og den bredeste
> _derefter_ 1 x AND og 3x OR? I så fald vil jeg mene at det giver god
> mening at
>
> * fjerne "unchosen"
> * tilføje "worldwide" / "limit to region(s)"....
> * have default=4 x OR når der er trykket på "limit to regions", og at de
> checkbokse automatisk er deaktiveret hvis der er valgt "worldwide".

Jeg tror, at der også vil opstå forvirring med det, du foreslår. Hvis man vælger "Limit to
region(s)", og man derefter f.eks. vælger at markere AND ud for "Asia" vil resultatet være, at
man søger på artikler, der omhandler "Africa" AND "Asia" OR "Eastern Europe" OR "South and
Central America" = atikler, hvor /både/ "Africa" /og/ "Asia" behandles i samme atikel, /eller/
artikler, hvor "Eastern Europe" behandles, /eller/ artikler, hvor "South and Central America"
behandles => Jeg tror ikke, at brugerne får den søgning, som de tror, de beder om.

Meningen er, at man ved at markere AND /kun/ skal sende den ene parameter af sted, f.eks. "AND
Africa[mh]". Derfor er der brug for, at nogle kriterier skal kunne markeres som "Unchosen".

Jeg kan heller ikke se, at man f.eks. kunne lade NOT være default, da man derved ville
frasortere de resultater, hvor /flere/ regioner behandles i artiklen.

Jeg tror, at vi ved at give en tydelig indledende forklaring om, at man ikke medtager de
kriterier, der er markeret som "Unchosen", i sin søgning, kan få de fleste brugere med. Derved
vil der heller ikke være brug for "Search worldwide"/"Limit to region(s)"-muligheden. Desuden
tror jeg, at det vil være pædagoisk smart, hvis måden at markere kriterier på er ens i
"Regions", "Country status" og "Target groups".
>
> > *av, den var værre (fordi vi så skal definere status for hvert enkelt
> > inputfelt). Så er det næsten lettere at refreshe (eller reloade) siden?
> > - Ja - det vel nemt at tilkoble den funktion til "Clear form"-knappen, ikke?
>
> nu har jeg lavet et regulært link til samme side - det gør jobbet

Hmnjæ, der sker ikke noget hos mig, når jeg klikker på knappen...
>
> Jeg har fået fjernet den unødvendige operator, men jeg er en smule blank
> på hvor vi videre skal hen.

Det prøvede jeg også et tidspunkt, men resultatet var, at det blev indsat et "on" lige efter
"AIDS[sb]". Det samme er vist sket for dig.

Dertil kommer, at der nu indsættes en masse kommaer - og det tolker PubMed som en fejl.

> Jeg mangler en færdig formular hvor alt er som det skal se ud, og hvor
> det med kommentarer er tydeligt hvad der skal AND's, parenteser osv osv
> ind imellem under hvilke omstændigheder.

Jeg vil hurtigst muligt få lavet en formular med tydelige angivelser, men vil dog inden gerne
lige have din kommentar på mit forslag om droppe "Search worldwide"/"Limit to
region(s)"-muligheden og i stedet angive en forklaring om, hvad det betyder, at markere
"Unchosen", "AND", "OR" eller "NOT".

- Ole

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Ole Nørgaard wrote:

> Det bliver nok nødt til at være en mulighed for at undlade at sende værdier med overhovedet - se
> længere nede.

Det er også overkommeligt hvis vi bruger flere-forms-med-ID-metoden :)

>>>* ok, så havde jeg misforstået noget, men så må udgangspunktet
>>>(=unchecked) vel være at der er OR imellem de fire?
>>>- Måske er du ikke længere i tvivl om dette, jvf. ovenstående, men der skal ikke som
>>>standard være OR imellem de fire valgmuligheder. Det skal nemlig også være muligt /ikke/ at
>>>begrænse sin søgning til bestemte regioner.
>>
>>OK, men hvis vi har en "search worldwide" som er lig med 4x unchecked,
>>er den bredeste søgning derefter så ikke 4 x OR, og den bredeste
>>_derefter_ 1 x AND og 3x OR? I så fald vil jeg mene at det giver god
>>mening at
>>
>>* fjerne "unchosen"
>>* tilføje "worldwide" / "limit to region(s)"....
>>* have default=4 x OR når der er trykket på "limit to regions", og at de
>>checkbokse automatisk er deaktiveret hvis der er valgt "worldwide".
>
>
> Jeg tror, at der også vil opstå forvirring med det, du foreslår. Hvis man vælger "Limit to
> region(s)", og man derefter f.eks. vælger at markere AND ud for "Asia" vil resultatet være, at
> man søger på artikler, der omhandler "Africa" AND "Asia" OR "Eastern Europe" OR "South and
> Central America" = atikler, hvor /både/ "Africa" /og/ "Asia" behandles i samme atikel, /eller/
> artikler, hvor "Eastern Europe" behandles, /eller/ artikler, hvor "South and Central America"
> behandles => Jeg tror ikke, at brugerne får den søgning, som de tror, de beder om.

Det var årsagen til min reformulering af AND + OR til i stedet at være
sætninger med "must" og "can be" - hvis du tænker de sætninger ind,
mener jeg faktisk at det vil hænge gennemskueligt sammen.

> Meningen er, at man ved at markere AND /kun/ skal sende den ene parameter af sted, f.eks. "AND
> Africa[mh]". Derfor er der brug for, at nogle kriterier skal kunne markeres som "Unchosen".

Det kan godt være, men så skal "unchosen" hedde noget andet, unchosen
tyder på at man ikke søger i den region, og betyder så vidt jeg har
forstået det modsatte :-/

Er effekten af Unchosen og OR ikke den samme?

> Jeg kan heller ikke se, at man f.eks. kunne lade NOT være default, da man derved ville
> frasortere de resultater, hvor /flere/ regioner behandles i artiklen.

Det er jeg helt med på.

> Jeg tror, at vi ved at give en tydelig indledende forklaring om, at man ikke medtager de
> kriterier, der er markeret som "Unchosen", i sin søgning, kan få de fleste brugere med.

Jeg svært ved at acceptere den omvendte logik, at man skal lade noget
være u-valgt for at det er et søgeområde. Det hjælper selvfølgelig hvis
man gør meget klart at det hele handler om at begrænse søgningen smart.
Det bringer mig til at foreslå "not limited" i stedet for unchosen, og i
kombination om en overskrift om at det handler om at "limit search
results intelligent" eller ligndende.

> Derved
> vil der heller ikke være brug for "Search worldwide"/"Limit to region(s)"-muligheden.

nej, men jeg mener at den sammen med ændret ordvalg på radioboksene kan
gøre det hele lettere at forstå og at bruge.

> Desuden
> tror jeg, at det vil være pædagoisk smart, hvis måden at markere kriterier på er ens i
> "Regions", "Country status" og "Target groups".

Det tror jeg egentlig ikke, det er så relativt forskellige
udvælgelsesområder så det er svært at oversætte logikken

[nulstilling af formularen]
>>nu har jeg lavet et regulært link til samme side - det gør jobbet
>
> Hmnjæ, der sker ikke noget hos mig, når jeg klikker på knappen...

(suk - det virkede hos mig, men jeg prøvede kun i 1 browser - virker
linket her bedre?)

>>Jeg har fået fjernet den unødvendige operator, men jeg er en smule blank
>>på hvor vi videre skal hen.
>
> Det prøvede jeg også et tidspunkt, men resultatet var, at det blev indsat et "on" lige efter
> "AIDS[sb]". Det samme er vist sket for dig.
>
> Dertil kommer, at der nu indsættes en masse kommaer - og det tolker PubMed som en fejl.

Jeg prøvede at søge, og den gav pæne resultater, så jeg troede at det
var underordnet, men jeg ser på noget alternativt.

>>Jeg mangler en færdig formular hvor alt er som det skal se ud, og hvor
>>det med kommentarer er tydeligt hvad der skal AND's, parenteser osv osv
>>ind imellem under hvilke omstændigheder.
>
> Jeg vil hurtigst muligt få lavet en formular med tydelige angivelser, men vil dog inden gerne
> lige have din kommentar på mit forslag om droppe "Search worldwide"/"Limit to
> region(s)"-muligheden og i stedet angive en forklaring om, hvad det betyder, at markere
> "Unchosen", "AND", "OR" eller "NOT".

Det kan jeg godt forstå, det er væsentligt.

mvh

Jesper Brunholm

---

Jesper Brunholm wrote:

> Det er også overkommeligt hvis vi bruger flere-forms-med-ID-metoden :)

- som jeg lige har udvidet understøttelsen af.

Jeg har vist også løst problemet med kommaerne som kom pga.
join-funktionen, og ON [ingenting] er så vidt jeg kan se ikke noget
problem (?)

mvh

Jesper Brunholm

---

Jesper Brunholm wrote in dk.edb.internet.webdesign.clientside:
> Jesper Brunholm wrote:
>
> > Det er også overkommeligt hvis vi bruger flere-forms-med-ID-metoden :)
>
> - som jeg lige har udvidet understøttelsen af.
>
> Jeg har vist også løst problemet med kommaerne som kom pga.
> join-funktionen, og ON [ingenting] er så vidt jeg kan se ikke noget
> problem (?)

Ja, kommaerne er væk, men i stedet medsendes parametrene adskillige gange,
hvis man vælge flere kriterier. Det er ikke helt ligegyldigt for
søgeresultatet, da rækkefølgen af parametrene nogle gange har betydning
(f.eks. ved anvendelse af OR).

At det står "on" nogle steder betyder god nok ikke noget for søgningen, men
det vil måske forvirre nogle brugere, som kigger nærmere på søgestrengen -
og det skal de helst kunne.


--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Jesper Brunholm wrote in dk.edb.internet.webdesign.clientside:

> > Jeg tror, at der også vil opstå forvirring med det, du foreslår. Hvis man vælger "Limit to
> > region(s)", og man derefter f.eks. vælger at markere AND ud for "Asia" vil resultatet være, at
> > man søger på artikler, der omhandler "Africa" AND "Asia" OR "Eastern Europe" OR "South and
> > Central America" = atikler, hvor /både/ "Africa" /og/ "Asia" behandles i samme atikel, /eller/
> > artikler, hvor "Eastern Europe" behandles, /eller/ artikler, hvor "South and Central America"
> > behandles => Jeg tror ikke, at brugerne får den søgning, som de tror, de beder om.
>
> Det var årsagen til min reformulering af AND + OR til i stedet at være
> sætninger med "must" og "can be" - hvis du tænker de sætninger ind,
> mener jeg faktisk at det vil hænge gennemskueligt sammen.

Ja, det lyder som en mulighed. Måske skulle man dog overveje, om det ikke ville være fornuftigt at
holde fast i de boolske operatorer, da de bruges af de fleste søgemaskiner. Brugeren kan på den måde
lære at anvende dem samt nemt læse søgeresultatet.

Når man anvender de store sundhedsvidenskabelige databaser i sin forskning er det normalt at angive
nøjagtigt, hvilken søgestrategi man har anvendt. Nu er vores søgeværktøj ikke ment som et redskab til
forskere, men vi bliver nok nødt at gå ud fra, at en garvet forsker skal kunne sige god for de
søgninger, som genereres af søgeværktøjet. Derfor tror jeg, at det er en god idé at lade begreberne,
der bruges i formularen, ligne dem, man bruger i "virkeligheden".
>
> > Meningen er, at man ved at markere AND /kun/ skal sende den ene parameter af sted, f.eks. "AND
> > Africa[mh]". Derfor er der brug for, at nogle kriterier skal kunne markeres som "Unchosen".
>
> Det kan godt være, men så skal "unchosen" hedde noget andet, unchosen
> tyder på at man ikke søger i den region, og betyder så vidt jeg har
> forstået det modsatte :-/
>
> Er effekten af Unchosen og OR ikke den samme?

Jeg tror, at du har "misforstået det rigtigt". Hvis man vælger "Unchosen" (eller hvad det nu skal
hedde), søger man /ikke/ i den pågældende region - det vil man gøre, hvis OR vælges.
>
> > Jeg tror, at vi ved at give en tydelig indledende forklaring om, at man ikke medtager de
> > kriterier, der er markeret som "Unchosen", i sin søgning, kan få de fleste brugere med.
>
> Jeg svært ved at acceptere den omvendte logik, at man skal lade noget
> være u-valgt for at det er et søgeområde. Det hjælper selvfølgelig hvis
> man gør meget klart at det hele handler om at begrænse søgningen smart.
> Det bringer mig til at foreslå "not limited" i stedet for unchosen, og i
> kombination om en overskrift om at det handler om at "limit search
> results intelligent" eller ligndende.

Har du ikke misforsået noget her, jvt. mit ovenstående svar? Hvis noget er u-valgt, er det /ikke/ et
søgeområde.

God idé med "Not limited".
>
> > Derved vil der heller ikke være brug for "Search worldwide"/"Limit to region(s)"-muligheden.
>
> nej, men jeg mener at den sammen med ændret ordvalg på radioboksene kan
> gøre det hele lettere at forstå og at bruge.

Ja, måske, men er det så meningen, at de to radioknapper ikke skal medsende nogen parametre, men blot
skal være der for et syns skyld? I bekræftende fald kunne en lille forklaring om, at man søger
"worldwide", hvis man ikke begrænser sin søgning til én eller flere regioner, måske være nok...
>
> > Desuden tror jeg, at det vil være pædagoisk smart, hvis måden at markere kriterier på er ens i
> > "Regions", "Country status" og "Target groups".
>
> Det tror jeg egentlig ikke, det er så relativt forskellige
> udvælgelsesområder så det er svært at oversætte logikken

Udvælgelsen baseres for alle områdernes vedkommende på MeSH-terms, så der er, for mig at se, ikke den
store forskel.
>
> [nulstilling af formularen]
> >>nu har jeg lavet et regulært link til samme side - det gør jobbet
> >
> > Hmnjæ, der sker ikke noget hos mig, når jeg klikker på knappen...
>
> (suk - det virkede hos mig, men jeg prøvede kun i 1 browser - virker
> linket her bedre?)

Ja, det regulære link virker fint.
>
> >>Jeg har fået fjernet den unødvendige operator, men jeg er en smule blank
> >>på hvor vi videre skal hen.
> >
> > Det prøvede jeg også et tidspunkt, men resultatet var, at det blev indsat et "on" lige efter
> > "AIDS[sb]". Det samme er vist sket for dig.
> >
> > Dertil kommer, at der nu indsættes en masse kommaer - og det tolker PubMed som en fejl.
>
> Jeg prøvede at søge, og den gav pæne resultater, så jeg troede at det
> var underordnet, men jeg ser på noget alternativt.
>
- Ole

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Ole Nørgaard wrote:

>>>Jeg tror, at der også vil opstå forvirring med det, du foreslår. Hvis man vælger "Limit to
>>>region(s)", og man derefter f.eks. vælger at markere AND ud for "Asia" vil resultatet være, at
>>>man søger på artikler, der omhandler "Africa" AND "Asia" OR "Eastern Europe" OR "South and
>>>Central America" = atikler, hvor /både/ "Africa" /og/ "Asia" behandles i samme atikel, /eller/
>>>artikler, hvor "Eastern Europe" behandles, /eller/ artikler, hvor "South and Central America"
>>>behandles => Jeg tror ikke, at brugerne får den søgning, som de tror, de beder om.
>>
>>
>>Det var årsagen til min reformulering af AND + OR til i stedet at være
>>sætninger med "must" og "can be" - hvis du tænker de sætninger ind,
>>mener jeg faktisk at det vil hænge gennemskueligt sammen.
>
> Ja, det lyder som en mulighed. Måske skulle man dog overveje, om det ikke ville være fornuftigt at
> holde fast i de boolske operatorer, da de bruges af de fleste søgemaskiner. Brugeren kan på den måde
> lære at anvende dem samt nemt læse søgeresultatet.

"Your choise" :) - jeg tror du går for mange ærinder på en gang, men
hvis AND, OR og NOT's alternative udverbaliseringer tages med i
forklaringen af systemet så er det meget muligt at det kan fungere. Jeg
tror bare det ville være _lettere_ med dem "inline".

> Når man anvender de store sundhedsvidenskabelige databaser i sin forskning er det normalt at angive
> nøjagtigt, hvilken søgestrategi man har anvendt. Nu er vores søgeværktøj ikke ment som et redskab til
> forskere, men vi bliver nok nødt at gå ud fra, at en garvet forsker skal kunne sige god for de
> søgninger, som genereres af søgeværktøjet. Derfor tror jeg, at det er en god idé at lade begreberne,
> der bruges i formularen, ligne dem, man bruger i "virkeligheden".

Den argumentation kan jeg ikke følge, den garvede forsker burde let
kunne sætte sig ind i den pædagogiske version, det modsatte gør sig ikke
nødvendigvis gældende.

>>>Meningen er, at man ved at markere AND /kun/ skal sende den ene parameter af sted, f.eks. "AND
>>>Africa[mh]". Derfor er der brug for, at nogle kriterier skal kunne markeres som "Unchosen".
>>
>>
>>Det kan godt være, men så skal "unchosen" hedde noget andet, unchosen
>>tyder på at man ikke søger i den region, og betyder så vidt jeg har
>>forstået det modsatte :-/
>>
>>Er effekten af Unchosen og OR ikke den samme?
>
>
> Jeg tror, at du har "misforstået det rigtigt". Hvis man vælger "Unchosen" (eller hvad det nu skal
> hedde), søger man /ikke/ i den pågældende region - det vil man gøre, hvis OR vælges.

Så har jeg ikke fattet en meter! Hvis det er rigtigt, er 4 x unchosen
(som er default) også lig med ikke at søge i noget som helst! Er det
virkelig rigtigt??

>>>Jeg tror, at vi ved at give en tydelig indledende forklaring om, at man ikke medtager de
>>>kriterier, der er markeret som "Unchosen", i sin søgning, kan få de fleste brugere med.
>>
>>
>>Jeg svært ved at acceptere den omvendte logik, at man skal lade noget
>>være u-valgt for at det er et søgeområde. Det hjælper selvfølgelig hvis
>>man gør meget klart at det hele handler om at begrænse søgningen smart.
>>Det bringer mig til at foreslå "not limited" i stedet for unchosen, og i
>>kombination om en overskrift om at det handler om at "limit search
>>results intelligent" eller ligndende.
>
> Har du ikke misforsået noget her, jvt. mit ovenstående svar? Hvis noget er u-valgt, er det /ikke/ et
> søgeområde.
>
> God idé med "Not limited".

Jeg tror ikke rigtigt vi forstår hinanden, når du kan bruge "not
limited" som alternativ til "unchosen", men ikke er enig i min
fortolkning af effekten.

>>>Derved vil der heller ikke være brug for "Search worldwide"/"Limit to region(s)"-muligheden.
>>
>>nej, men jeg mener at den sammen med ændret ordvalg på radioboksene kan
>>gøre det hele lettere at forstå og at bruge.
>
> Ja, måske, men er det så meningen, at de to radioknapper ikke skal medsende nogen parametre, men blot
> skal være der for et syns skyld? I bekræftende fald kunne en lille forklaring om, at man søger
> "worldwide", hvis man ikke begrænser sin søgning til én eller flere regioner, måske være nok...

Det var meningen at "Search Worldwide" skulle sørge for at medsende 4 x
"Unchosen", og "Limit to region(s)" skulle ikke medsende noget som helst.

>>>Desuden tror jeg, at det vil være pædagoisk smart, hvis måden at markere kriterier på er ens i
>>>"Regions", "Country status" og "Target groups".
>>
>>Det tror jeg egentlig ikke, det er så relativt forskellige
>>udvælgelsesområder så det er svært at oversætte logikken
>
> Udvælgelsen baseres for alle områdernes vedkommende på MeSH-terms, så der er, for mig at se, ikke den
> store forskel.

ok - så lad det være sådan :)

>>[nulstilling af formularen]

> Ja, det regulære link virker fint.

godt - så er det bare et spørgsmål om man gider style det til at ligne
en knap :)

mvh

Jesper Brunholm

---

Jesper Brunholm wrote in dk.edb.internet.webdesign.clientside:
>
> "Your choise" :) - jeg tror du går for mange ærinder på en gang, men
> hvis AND, OR og NOT's alternative udverbaliseringer tages med i
> forklaringen af systemet så er det meget muligt at det kan fungere. Jeg
> tror bare det ville være _lettere_ med dem "inline".

Jeg tror på, at det kan fungere med nogle gode forklaringer
>
> > Når man anvender de store sundhedsvidenskabelige databaser i sin forskning er det normalt at angive
> > nøjagtigt, hvilken søgestrategi man har anvendt. Nu er vores søgeværktøj ikke ment som et redskab til
> > forskere, men vi bliver nok nødt at gå ud fra, at en garvet forsker skal kunne sige god for de
> > søgninger, som genereres af søgeværktøjet. Derfor tror jeg, at det er en god idé at lade begreberne,
> > der bruges i formularen, ligne dem, man bruger i "virkeligheden".
>
> Den argumentation kan jeg ikke følge, den garvede forsker burde let
> kunne sætte sig ind i den pædagogiske version, det modsatte gør sig ikke
> nødvendigvis gældende.

Dét, som den garvede forsker måske ikke umiddelbart vil acceptere, er den søgestreng, der genereres, og
som vises i søgefeltet på PubMed-siden. Personligt ville jeg med det samme klikke på "Datails" på PubMed
for at finde ud af, hvordan søgningen er opbygget. Hvis der f.eks. angives ord i søgefeltet, som ikke
medtages (men som man lige skal teste, om har betydning), eller hvis parametrene angives i en
uigennemskuelig rækkefølge, ville jeg føle, at jeg var nødt til at teste søgningen selv (måske flere
gange!) - det var det, jeg mente med, at en garvet forsker skal kunne sige god for søgninger - d.v.s
gerne ved første øjekast.
>
> > Jeg tror, at du har "misforstået det rigtigt". Hvis man vælger "Unchosen" (eller hvad det nu skal
> > hedde), søger man /ikke/ i den pågældende region - det vil man gøre, hvis OR vælges.
>
> Så har jeg ikke fattet en meter! Hvis det er rigtigt, er 4 x unchosen
> (som er default) også lig med ikke at søge i noget som helst! Er det
> virkelig rigtigt??

Tja, man vælger i så fald ikke at blande de geografiske parametre ind i sin søgning. Man vil dog altid
som udgangspunkt søge på "AIDS[sb]" (der er et "subset", hvilket vil sige, at alle søgeresultater falder
inden for en prædefineret søgestrategi - se:
http://www.nlm.nih.gov/bsd/pubmed_subsets/aids_strategy.html) og "("human"[MeSH Terms] OR
"hominidae"[MeSH Terms])" (artikler om dyr frasorteres). Alt andet, der markeres i formularen, er
tilvalg, som begrænser søgningen yderligere.

> >>Jeg svært ved at acceptere den omvendte logik, at man skal lade noget
> >>være u-valgt for at det er et søgeområde. Det hjælper selvfølgelig hvis
> >>man gør meget klart at det hele handler om at begrænse søgningen smart.
> >>Det bringer mig til at foreslå "not limited" i stedet for unchosen, og i
> >>kombination om en overskrift om at det handler om at "limit search
> >>results intelligent" eller ligndende.
> >
> > Har du ikke misforsået noget her, jvt. mit ovenstående svar? Hvis noget er u-valgt, er det /ikke/ et
> > søgeområde.
> >
> > God idé med "Not limited".
>
> Jeg tror ikke rigtigt vi forstår hinanden, når du kan bruge "not
> limited" som alternativ til "unchosen", men ikke er enig i min
> fortolkning af effekten.

Er vi mere enige nu, efter at du har læst ovenstående?

> > Ja, måske, men er det så meningen, at de to radioknapper ikke skal medsende nogen parametre, men blot
> > skal være der for et syns skyld? I bekræftende fald kunne en lille forklaring om, at man søger
> > "worldwide", hvis man ikke begrænser sin søgning til én eller flere regioner, måske være nok...
>
> Det var meningen at "Search Worldwide" skulle sørge for at medsende 4 x
> "Unchosen", og "Limit to region(s)" skulle ikke medsende noget som helst.

Men hvis nu "Unchosen" ikke har nogen værdi...så medsendes der jo heller ikke noget, når "Search
Worldwide" vælges! "Search Worldwide" bliver altså det samme som "Limit to region(s)".

> >>[nulstilling af formularen]
>
> > Ja, det regulære link virker fint.
>
> godt - så er det bare et spørgsmål om man gider style det til at ligne
> en knap :)

- Ole

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Ole Nørgaard wrote:
>>Den argumentation kan jeg ikke følge, den garvede forsker burde let
>>kunne sætte sig ind i den pædagogiske version, det modsatte gør sig ikke
>>nødvendigvis gældende.
>
> Dét, som den garvede forsker måske ikke umiddelbart vil acceptere, er den søgestreng, der genereres, og
> som vises i søgefeltet på PubMed-siden. Personligt ville jeg med det samme klikke på "Datails" på PubMed
> for at finde ud af, hvordan søgningen er opbygget. Hvis der f.eks. angives ord i søgefeltet, som ikke
> medtages (men som man lige skal teste, om har betydning), eller hvis parametrene angives i en
> uigennemskuelig rækkefølge, ville jeg føle, at jeg var nødt til at teste søgningen selv (måske flere
> gange!) - det var det, jeg mente med, at en garvet forsker skal kunne sige god for søgninger - d.v.s
> gerne ved første øjekast.

Nååå - på den måde - men så kan du vel bare lave en lidt mere garvet del
af forklaringen af interfacet? - men det er selvfølgelig bedre hvis vi
bare kan få det til at gøre det rigtigt uden nogen ekstra gentagelser

>>>Jeg tror, at du har "misforstået det rigtigt". Hvis man vælger "Unchosen" (eller hvad det nu skal
>>>hedde), søger man /ikke/ i den pågældende region - det vil man gøre, hvis OR vælges.
>>
>>Så har jeg ikke fattet en meter! Hvis det er rigtigt, er 4 x unchosen
>>(som er default) også lig med ikke at søge i noget som helst! Er det
>>virkelig rigtigt??
>
> Tja, man vælger i så fald ikke at blande de geografiske parametre ind i sin søgning. Man vil dog altid
> som udgangspunkt søge på "AIDS[sb]" (der er et "subset", hvilket vil sige, at alle søgeresultater falder
> inden for en prædefineret søgestrategi - se:
> http://www.nlm.nih.gov/bsd/pubmed_subsets/aids_strategy.html) og "("human"[MeSH Terms] OR
> "hominidae"[MeSH Terms])" (artikler om dyr frasorteres). Alt andet, der markeres i formularen, er
> tilvalg, som begrænser søgningen yderligere.

OK - jeg snakker effekt, ikke teori. Hvis man sender 4 x unchosen vil
effekten på søgeresultaterne være den samme som at sende 4x OR så vidt
jeg kan se (?).

Det er det jeg gerne vil synliggøre, og det generer mig at have to
afkrydsninger der giver samme resultat, også fordi det vil genere logisk
tænkende brugere - man forventer ikke at to mulige valg giver samme effekt.

>>>God idé med "Not limited".
>>
>>
>>Jeg tror ikke rigtigt vi forstår hinanden, når du kan bruge "not
>>limited" som alternativ til "unchosen", men ikke er enig i min
>>fortolkning af effekten.
>
> Er vi mere enige nu, efter at du har læst ovenstående?

ja, meget. (Jeg synes din formulering "Jeg tror, at du har "misforstået
det rigtigt". Hvis man vælger "Unchosen" (eller hvad det nu skal
hedde), søger man /ikke/ i den pågældende region - det vil man gøre,
hvis OR vælges." er direkte forkert, man vil jo få søgeresultater fra
den pågældende region selv om den er unchosen).

>>>Ja, måske, men er det så meningen, at de to radioknapper ikke skal medsende nogen parametre, men blot
>>>skal være der for et syns skyld? I bekræftende fald kunne en lille forklaring om, at man søger
>>>"worldwide", hvis man ikke begrænser sin søgning til én eller flere regioner, måske være nok...
>>
>>
>>Det var meningen at "Search Worldwide" skulle sørge for at medsende 4 x
>>"Unchosen", og "Limit to region(s)" skulle ikke medsende noget som helst.
>
>
> Men hvis nu "Unchosen" ikke har nogen værdi...så medsendes der jo heller ikke noget, når "Search
> Worldwide" vælges! "Search Worldwide" bliver altså det samme som "Limit to region(s)".

ja, vi kan ikke forvælge for brugeren hvilken region det er bedst at
begrænse til, så i udgangspunktet er det det samme der sendes ved de to
valg, men "limit to regions" åbner så for en masse flere muligheder. Det
var netop i kombination med at fjerne unchosen at det overordnede valg
af "search worldwide" (som sender unchosen for alle 4 om du vil) eller
"limit to region(s)" (som ikke sender noget, det overlader den til de
enkelte regions-radio-selects) blev intelligent.

MEN - hvis du stadig ikke kan se min pointe med det overordnede valg af
om man vil begrænse til regioner eller ej, og den samtidige fjernelse af
Unchosen-muligheden for den enkelte region, så gider vi ikke debattere
den længere, for så er det nok fordi det var en for søgt pointe, og det
er jo sådan set noget andet, nemlig en teknisk løsning, vi er i den her
gruppe for .


mvh

Jesper Brunholm

--
Phønix - dansk folk-musik i front - <http://www.phonixfolk.dk/>
H.C. Andersen-Centret: <http://www.andersen.sdu.dk/>

---

Jesper Brunholm wrote in dk.edb.internet.webdesign.clientside:
> Nååå - på den måde - men så kan du vel bare lave en lidt mere garvet del
> af forklaringen af interfacet? - men det er selvfølgelig bedre hvis vi
> bare kan få det til at gøre det rigtigt uden nogen ekstra gentagelser

Enig!

> > Tja, man vælger i så fald ikke at blande de geografiske parametre ind i sin søgning. Man vil dog altid
> > som udgangspunkt søge på "AIDS[sb]" (der er et "subset", hvilket vil sige, at alle søgeresultater falder
> > inden for en prædefineret søgestrategi - se:
> > http://www.nlm.nih.gov/bsd/pubmed_subsets/aids_strategy.html) og "("human"[MeSH Terms] OR
> > "hominidae"[MeSH Terms])" (artikler om dyr frasorteres). Alt andet, der markeres i formularen, er
> > tilvalg, som begrænser søgningen yderligere.
>
> OK - jeg snakker effekt, ikke teori. Hvis man sender 4 x unchosen vil
> effekten på søgeresultaterne være den samme som at sende 4x OR så vidt
> jeg kan se (?).
>
> Det er det jeg gerne vil synliggøre, og det generer mig at have to
> afkrydsninger der giver samme resultat, også fordi det vil genere logisk
> tænkende brugere - man forventer ikke at to mulige valg giver samme effekt.

Forudsat, at vi har forstået hinanden korrekt, vil jeg fastholde, at de to typer afkrydsninger /ikke/ giver
samme resultat. Det illustreres ved følgende eksempel, hvor man ønsker artikler, der omhandler både Africa
og Asia:

Søgestrengen:
("africa"[MeSH Terms] AND "asia"[MeSH Terms]) AND AIDS[sb] AND ("human"[MeSH Terms] OR "hominidae"[MeSH
Terms])
- d.v.s. "OR "europe, eastern"[MeSH Terms] OR ("south america"[MeSH Terms] OR "central america"[MeSH
Terms])" er udeladt = "Unchosen"

Link:
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=PureSearch&db=pubmed&details_term=%28%22africa%22%5BMeSH%2
0Terms%5D%20AND%20%22asia%22%5BMeSH%20Terms%5D%29%20AND%20AIDS%5Bsb%5D%20AND%20%28%22human%22%5BMeSH%20Terms
%5D%20OR%20%22hominidae%22%5BMeSH%20Terms%5D%29

Giver 409 hits (3. august 2004)

...mens

Søgestrengen:
("africa"[MeSH Terms] AND "asia"[MeSH Terms] OR "europe, eastern"[MeSH Terms] OR ("south america"[MeSH
Terms] OR "central america"[MeSH Terms])) AND AIDS[sb] AND ("human"[MeSH Terms] OR "hominidae"[MeSH Terms])
- d.v.s. hvor OR er default, og "OR "europe, eastern"[MeSH Terms] OR ("south america"[MeSH Terms] OR
"central america"[MeSH Terms])" derfor medsendes.

Link:
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=PureSearch&db=pubmed&details_term=%28%22africa%22%5BMeSH%2
0Terms%5D%20AND%20%22asia%22%5BMeSH%20Terms%5D%20OR%20%22europe%2C%20eastern%22%5BMeSH%20Terms%5D%20OR%20%28
%22south%20america%22%5BMeSH%20Terms%5D%20OR%20%22central%20america%22%5BMeSH%20Terms%5D%29%29%20AND%20AIDS%
5Bsb%5D%20AND%20%28%22human%22%5BMeSH%20Terms%5D%20OR%20%22hominidae%22%5BMeSH%20Terms%5D%29

Giver 3019 hits (3. august 2004)

> ja, meget. (Jeg synes din formulering "Jeg tror, at du har "misforstået
> det rigtigt". Hvis man vælger "Unchosen" (eller hvad det nu skal
> hedde), søger man /ikke/ i den pågældende region - det vil man gøre,
> hvis OR vælges." er direkte forkert, man vil jo få søgeresultater fra
> den pågældende region selv om den er unchosen).

Man får ikke søgeresultater fra den pågældende region, selv om den er "Unchosen", jvf. ovenstående.

> > Men hvis nu "Unchosen" ikke har nogen værdi...så medsendes der jo heller ikke noget, når "Search
> > Worldwide" vælges! "Search Worldwide" bliver altså det samme som "Limit to region(s)".
>
> ja, vi kan ikke forvælge for brugeren hvilken region det er bedst at
> begrænse til, så i udgangspunktet er det det samme der sendes ved de to
> valg, men "limit to regions" åbner så for en masse flere muligheder. Det
> var netop i kombination med at fjerne unchosen at det overordnede valg
> af "search worldwide" (som sender unchosen for alle 4 om du vil) eller
> "limit to region(s)" (som ikke sender noget, det overlader den til de
> enkelte regions-radio-selects) blev intelligent.
>
> MEN - hvis du stadig ikke kan se min pointe med det overordnede valg af
> om man vil begrænse til regioner eller ej, og den samtidige fjernelse af
> Unchosen-muligheden for den enkelte region, så gider vi ikke debattere
> den længere, for så er det nok fordi det var en for søgt pointe, og det
> er jo sådan set noget andet, nemlig en teknisk løsning, vi er i den her
> gruppe for .

Kan vi se hinandens pionter nu?

- Ole

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Ole Nørgaard wrote:

> Forudsat, at vi har forstået hinanden korrekt, vil jeg fastholde, at de to typer afkrydsninger /ikke/ giver
> samme resultat. Det illustreres ved følgende eksempel, hvor man ønsker artikler, der omhandler både Africa
> og Asia:
>
> Søgestrengen:
> ("africa"[MeSH Terms] AND "asia"[MeSH Terms]) AND AIDS[sb] AND ("human"[MeSH Terms] OR "hominidae"[MeSH
> Terms])
> - d.v.s. "OR "europe, eastern"[MeSH Terms] OR ("south america"[MeSH Terms] OR "central america"[MeSH
> Terms])" er udeladt = "Unchosen"
>
> Link:
> http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=PureSearch&db=pubmed&details_term=%28%22africa%22%5BMeSH%2
> 0Terms%5D%20AND%20%22asia%22%5BMeSH%20Terms%5D%29%20AND%20AIDS%5Bsb%5D%20AND%20%28%22human%22%5BMeSH%20Terms
> %5D%20OR%20%22hominidae%22%5BMeSH%20Terms%5D%29
>
> Giver 409 hits (3. august 2004)
>
> ..mens
>
> Søgestrengen:
> ("africa"[MeSH Terms] AND "asia"[MeSH Terms] OR "europe, eastern"[MeSH Terms] OR ("south america"[MeSH
> Terms] OR "central america"[MeSH Terms])) AND AIDS[sb] AND ("human"[MeSH Terms] OR "hominidae"[MeSH Terms])
> - d.v.s. hvor OR er default, og "OR "europe, eastern"[MeSH Terms] OR ("south america"[MeSH Terms] OR
> "central america"[MeSH Terms])" derfor medsendes.
>
> Link:
> http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=PureSearch&db=pubmed&details_term=%28%22africa%22%5BMeSH%2
> 0Terms%5D%20AND%20%22asia%22%5BMeSH%20Terms%5D%20OR%20%22europe%2C%20eastern%22%5BMeSH%20Terms%5D%20OR%20%28
> %22south%20america%22%5BMeSH%20Terms%5D%20OR%20%22central%20america%22%5BMeSH%20Terms%5D%29%29%20AND%20AIDS%
> 5Bsb%5D%20AND%20%28%22human%22%5BMeSH%20Terms%5D%20OR%20%22hominidae%22%5BMeSH%20Terms%5D%29
>
> Giver 3019 hits (3. august 2004)

Ja - det illustrerer faktisk meget godt min pointe i hvor farlig
unchosen er at bruge, og at skulle forklare:

Hvis du bruger 4x unchosen så er det lig med 4x OR, men det øjeblik du
ændrer 1 af dem til en AND, bliver de 3 andre regioners unchosen effekt
ændret til NOT.

Det mener jeg stadig bedst kan illustreres ved at lave en overordnet
skifteparameter så der kun er en mulighed som giver unchosen.

Jeg mener også at kunne huske at du har skrevet at default skal være en
så bred søgning som muligt. Det må så være med default=OR hvis jeg kan
tyde dit eksempel.

>>ja, meget. (Jeg synes din formulering "Jeg tror, at du har "misforstået
>>det rigtigt". Hvis man vælger "Unchosen" (eller hvad det nu skal
>>hedde), søger man /ikke/ i den pågældende region - det vil man gøre,
>>hvis OR vælges." er direkte forkert, man vil jo få søgeresultater fra
>>den pågældende region selv om den er unchosen).
>
> Man får ikke søgeresultater fra den pågældende region, selv om den er "Unchosen", jvf. ovenstående.

Nej - men det har du tidligere forklaret mig at man _gør_, og det havde
du for så vidt også _ret i_ - når bare de _alle sammen_ er unchosen på
en gang - så jeg vender tilbage til mit udsagn ovenfor.

>>MEN - hvis du stadig ikke kan se min pointe med det overordnede valg af
>>om man vil begrænse til regioner eller ej, og den samtidige fjernelse af
>>Unchosen-muligheden for den enkelte region, så gider vi ikke debattere
>>den længere, for så er det nok fordi det var en for søgt pointe, og det
>>er jo sådan set noget andet, nemlig en teknisk løsning, vi er i den her
>>gruppe for .
>
> Kan vi se hinandens pionter nu?

Det er et godt spørgsmål, jeg har lidt svært ved at få de pointer du
fremlægger til at danne et sammenhængende billede

Jeg synes der tegner sig et billede af at det ikke kun er Target Groups
der skal AND eller OR + parentes foran - overvej det lige...

Jeg har lavet en forenklet version på
<http://www.garion.dk/webdesign/pubmed/index.html>.
Så vidt jeg kan se tager den de parametre den skal ud af de to grupper,
og vha. de to forskellige funktioner sørger den for at gruppere Target
groups med AND-parentes foran, men ikke på første parameter.

(Jeg tror så i virkeligheden at du skal bruge den funktion til flere af
grupperne, men det er din overvejelse.)

Hvis du gerne vil have "Search worldwide/limit to regions..."
implementeret, så sig til, men ellers har du vist den
javascript-funktionalitet du skal bruge her.

mvh

Jesper Brunholm

---

Jesper Brunholm wrote in dk.edb.internet.webdesign.clientside:
>
> Ja - det illustrerer faktisk meget godt min pointe i hvor farlig
> unchosen er at bruge, og at skulle forklare:
>
> Hvis du bruger 4x unchosen så er det lig med 4x OR, men det øjeblik du
> ændrer 1 af dem til en AND, bliver de 3 andre regioners unchosen effekt
> ændret til NOT.
>
> Det mener jeg stadig bedst kan illustreres ved at lave en overordnet
> skifteparameter så der kun er en mulighed som giver unchosen.
>
> Jeg mener også at kunne huske at du har skrevet at default skal være en
> så bred søgning som muligt. Det må så være med default=OR hvis jeg kan
> tyde dit eksempel.

Stadig ikke enig med dig...

Se f.eks. følgende søgninger, først med "OR" som default, dernæst med
"Unchosen" som default:

Søgestreng:
("africa"[MeSH Terms] OR "asia"[MeSH Terms] OR "europe, eastern"[MeSH
Terms] OR ("south america"[MeSH Terms] OR "central america"[MeSH
Terms])) AND AIDS[sb] AND ("human"[MeSH Terms] OR "hominidae"[MeSH
Terms])

Link:
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=PureSearch&db=pubmed&details_term=%28%22africa%22%5BMeSH%20Terms%5D%20OR%20%22asia%22%5BMeSH%20Terms%5D%20OR%20%22europe%2C%20eastern%22%5BMeSH%20Terms%5D%20OR%20%28%22south%20america%22%5BMeSH%20Terms%5D%20OR%20%22central%20america%22%5BMeSH%20Terms%5D%29%29%20AND%20AIDS%5Bsb%5D%20AND%20%28%22human%22%5BMeSH%20Terms%5D%20OR%20%22hominidae%22%5BMeS
%20Terms%5D%29

Giver 16365 hits (5. august 2004)

mens...

Søgestreng:
AIDS[sb] AND ("human"[MeSH Terms] OR "hominidae"[MeSH Terms])

Link:
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=PureSearch&db=pubmed&details_term=AIDS%5Bsb%5D%20AND%20%28%22human%22%5BMeSH%20Terms%5D%20OR%20%22hominidae%22%5BMeSH%20Terms%5D%29

Giver 198215 hits (5. august 2004)

> > Kan vi se hinandens pionter nu?
>
> Det er et godt spørgsmål, jeg har lidt svært ved at få de pointer du
> fremlægger til at danne et sammenhængende billede

Hva' så nu?

> Jeg synes der tegner sig et billede af at det ikke kun er Target Groups
> der skal AND eller OR + parentes foran - overvej det lige...
>
> Jeg har lavet en forenklet version på
> <http://www.garion.dk/webdesign/pubmed/index.html>.
> Så vidt jeg kan se tager den de parametre den skal ud af de to grupper,
> og vha. de to forskellige funktioner sørger den for at gruppere Target
> groups med AND-parentes foran, men ikke på første parameter.
>
> (Jeg tror så i virkeligheden at du skal bruge den funktion til flere af
> grupperne, men det er din overvejelse.)
>
> Hvis du gerne vil have "Search worldwide/limit to regions..."
> implementeret, så sig til, men ellers har du vist den
> javascript-funktionalitet du skal bruge her.

Det ser jo bare skønt ud

Men som altid, når man ser resultatet af sådan noget, opstår der nye
erkendelser og "problemer":

* Du har ret i, at alle grupperne skal behandles på samme vis som
"Target groups", altså startes og afsluttes med en parentes. Det vil
give en korrekt søgning.
* Jeg ved godt, at jeg har angivet, at den operator, der stod foran
det første parameter i en gruppe, skulle erstattes med "AND (". Nu er
det dog gået op for mig, at dette ikke er tilstrækkeligt, hvis
søgningen i alle tilfælde skal svare til det, brugeren markerer.
Problemet er, at hvis man f.eks. markerer NOT ud for en øverste af de
(eller det) parametre, der vælges under "Target groups", vil søgning
ikke afspejle dette => da NOT udskiftes med "AND(", vil der sket det
modsatte, altså at der søge efter artikler, der bekræfter sig med det
pågældende parameter. Hvis søgningen skal blive rigtig, må
modifikationen derfor være:
- Hvis AND står foran det førstvalgte parameter, skal AND erstattes
med "AND (" (som nu).
- Hvis OR står foran det førstvalgte parameter, skal OR erstattes med
"AND (" (som nu).
- Hvis NOT står foran det førstvalgte parameter, skal et andet
parameter, der indeholder AND eller OR placeres foran dette parameter,
og AND eller OR skal derefter erstattes med "AND (".
--- Hvis der ikke er valgt andre parametre i den pågældende gruppe,
skal der ikke foretages noget - der skal altså ikke indsættes "AND",
"(" eller ")" - parametret medsendes, som den er.

Jeg kan desværre ikke selv gennemskue, hvordan koden skal ændres fra
det nuværende til at kunne håndtere disse modifikationer - jeg bliver
rigtig glad, hvis du er frisk på et se på det igen

- Ole

---

Ole N?rgaard wrote:
> Jesper Brunholm wrote in dk.edb.internet.webdesign.clientside:
>
>>
>>Ja - det illustrerer faktisk meget godt min pointe i hvor farlig
>>unchosen er at bruge, og at skulle forklare:
>>
>>Hvis du bruger 4x unchosen så er det lig med 4x OR, men det øjeblik du
>>ændrer 1 af dem til en AND, bliver de 3 andre regioners unchosen effekt
>>ændret til NOT.
>>
>>Det mener jeg stadig bedst kan illustreres ved at lave en overordnet
>>skifteparameter så der kun er en mulighed som giver unchosen.
>>
>>Jeg mener også at kunne huske at du har skrevet at default skal være en
>>så bred søgning som muligt. Det må så være med default=OR hvis jeg kan
>>tyde dit eksempel.
>
> Stadig ikke enig med dig...

ok, og det kan jeg godt se på resultatet - men hvad er dit alternativ
så? (eftersom du vel også mener at unchosen har forskellig effekt
afhængig af de øvrige afkrydsninger, og eftersom du vel er enig i at det
handler om, som udgangspunkt at give så bred en søgning som muligt)

> Men som altid, når man ser resultatet af sådan noget, opstår der nye
> erkendelser og "problemer":
>
> * Du har ret i, at alle grupperne skal behandles på samme vis som
> "Target groups", altså startes og afsluttes med en parentes. Det vil
> give en korrekt søgning.

ok - det er let (vi skal bare skifte funktionskald)

> * Jeg ved godt, at jeg har angivet, at den operator, der stod foran
> det første parameter i en gruppe, skulle erstattes med "AND (". Nu er
> det dog gået op for mig, at dette ikke er tilstrækkeligt, hvis
> søgningen i alle tilfælde skal svare til det, brugeren markerer.

Jeg frygtede det...

> Problemet er, at hvis man f.eks. markerer NOT ud for en øverste af de
> (eller det) parametre, der vælges under "Target groups", vil søgning
> ikke afspejle dette => da NOT udskiftes med "AND(", vil der sket det
> modsatte, altså at der søge efter artikler, der bekræfter sig med det
> pågældende parameter. Hvis søgningen skal blive rigtig, må
> modifikationen derfor være:
> - Hvis AND står foran det førstvalgte parameter, skal AND erstattes
> med "AND (" (som nu).
> - Hvis OR står foran det førstvalgte parameter, skal OR erstattes med
> "AND (" (som nu).
> - Hvis NOT står foran det førstvalgte parameter, skal et andet
> parameter, der indeholder AND eller OR placeres foran dette parameter,
> og AND eller OR skal derefter erstattes med "AND (".
> --- Hvis der ikke er valgt andre parametre i den pågældende gruppe,
> skal der ikke foretages noget - der skal altså ikke indsættes "AND",
> "(" eller ")" - parametret medsendes, som den er.
>
> Jeg kan desværre ikke selv gennemskue, hvordan koden skal ændres fra
> det nuværende til at kunne håndtere disse modifikationer - jeg bliver
> rigtig glad, hvis du er frisk på et se på det igen

Jeg må lige vende tilbage senere på dagen - lige nu forstår jeg ikke
hvad der skal gøres :(

mvh

Jesper Brunholm

--
Phønix - dansk folk-musik - alive! - <http://www.phonixfolk.dk/>

---

Ole N?rgaard wrote:

> Jesper Brunholm wrote in dk.edb.internet.webdesign.clientside:
>>Ja - det illustrerer faktisk meget godt min pointe i hvor farlig
>>unchosen er at bruge, og at skulle forklare:
>>
>>Hvis du bruger 4x unchosen så er det lig med 4x OR, men det øjeblik du
>>ændrer 1 af dem til en AND, bliver de 3 andre regioners unchosen effekt
>>ændret til NOT.
>>
>>Det mener jeg stadig bedst kan illustreres ved at lave en overordnet
>>skifteparameter så der kun er en mulighed som giver unchosen.
>>
>>Jeg mener også at kunne huske at du har skrevet at default skal være en
>>så bred søgning som muligt. Det må så være med default=OR hvis jeg kan
>>tyde dit eksempel.
>
>
> Stadig ikke enig med dig...

Jeg er nødt til at spørge hvad det er du ikke er enig i?

Mit scenario er at _hvis_ (og kun da) der er et alternativ som
overordnet sætter 4x unchosen ("search worldwide"), så skal der være en
default når man åbner for at vælge regioner ud (med "limit to regions").
Denne default skal som udgangspunkt give en så bred søgning som muligt.
Derfor mener jeg det skal være OR.

Hvis der derimod fortsat er unchosen som mulighed på hver række, så har
du for mig at se en meget stor pædagogisk forklaringsopgave, i at
forklare at samme afkrydsning af en given række har meget forskellige
konsekvenser, afhængigt af hvad der er afkrydset i de andre rækker.

Jeg må give dig ret i, ud fra dine søgeeksempler, at der tilsyneladende
ikke er nogen af de tre (AND/OR/NOT) som svarer til unchosen når der er
fire styks af dem valgt.

> Hva' så nu?

det er muligt - jeg tror du svarede på noget jeg ikke mente

> Det ser jo bare skønt ud
>
> Men som altid, når man ser resultatet af sådan noget, opstår der nye
> erkendelser og "problemer":

> * Jeg ved godt, at jeg har angivet, at den operator, der stod foran
> det første parameter i en gruppe, skulle erstattes med "AND (". Nu er
> det dog gået op for mig, at dette ikke er tilstrækkeligt, hvis
> søgningen i alle tilfælde skal svare til det, brugeren markerer.

> Problemet er, at hvis man f.eks. markerer NOT ud for en øverste af de
> (eller det) parametre, der vælges under "Target groups", vil søgning
> ikke afspejle dette => da NOT udskiftes med "AND(", vil der sket det
> modsatte, altså at der søge efter artikler, der bekræfter sig med det
> pågældende parameter. Hvis søgningen skal blive rigtig, må
> modifikationen derfor være:
> - Hvis AND står foran det førstvalgte parameter, skal AND erstattes
> med "AND (" (som nu).
> - Hvis OR står foran det førstvalgte parameter, skal OR erstattes med
> "AND (" (som nu).

- men i så fald må der ikke vælges "AND" ved parameter to, for så bliver
det igen ikke det brugeren har bedt om (altså: hvis vi "retter"
{OR europe AND africa} til
{AND(europe AND africa)},
så går det galt - ikke?).

> - Hvis NOT står foran det førstvalgte parameter, skal et andet
> parameter, der indeholder AND eller OR placeres foran dette parameter,
> og AND eller OR skal derefter erstattes med "AND (".

Nu begynder det at blive rigtigt grimt - det dér kommer til at tage lang
tid at lave for mig, og det skal nok laves ved at lægge AND/OR/NOT
valget selvstændigt i et array som sættes sammen med den parameter som
det omhandler, men jeg står af her - der er for meget arbejde i det, og
det skal gøres af en som er dygtigere end mig, så man ikke hele tiden
skal researche på js samtidig .

> --- Hvis der ikke er valgt andre parametre i den pågældende gruppe,
> skal der ikke foretages noget - der skal altså ikke indsættes "AND",
> "(" eller ")" - parametret medsendes, som den er.

Det giver ikke flere forbehold, men ovenstående er for meget til mig -
beklager, jeg kan ikke lægge så mange flere timer i det her.

Alternativt kan du lave noget med en række knapper (med parametre, AND,
OR, parenteser osv) som man kan trykke på for interaktivt at udvikle en
søgestreng som man så kan submitte til sidst. Hvis du laver tilhørende
forklaringer så er det meget muligt at du kan øge brugbarheden af
databasen med det.

mvh og *pøj pøj*

Jesper Brunholm

---

Jesper Brunholm wrote in dk.edb.internet.webdesign.clientside:
>
> Ja - det illustrerer faktisk meget godt min pointe i hvor farlig
> unchosen er at bruge, og at skulle forklare:
>
> Hvis du bruger 4x unchosen så er det lig med 4x OR, men det øjeblik du
> ændrer 1 af dem til en AND, bliver de 3 andre regioners unchosen effekt
> ændret til NOT.
>
> Det mener jeg stadig bedst kan illustreres ved at lave en overordnet
> skifteparameter så der kun er en mulighed som giver unchosen.
>
> Jeg mener også at kunne huske at du har skrevet at default skal være en
> så bred søgning som muligt. Det må så være med default=OR hvis jeg kan
> tyde dit eksempel.

Stadig ikke enig med dig...

Se f.eks. følgende søgninger, først med "OR" som default, dernæst med "Unchosen" som default:

Søgestreng:
("africa"[MeSH Terms] OR "asia"[MeSH Terms] OR "europe, eastern"[MeSH Terms] OR ("south america"[MeSH Terms] OR
"central america"[MeSH Terms])) AND AIDS[sb] AND ("human"[MeSH Terms] OR "hominidae"[MeSH Terms])

Link:
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=PureSearch&db=pubmed&details_term=%28%22africa%22%5BMeSH%20Ter
ms%5D%20OR%20%22asia%22%5BMeSH%20Terms%5D%20OR%20%22europe%2C%20eastern%22%5BMeSH%20Terms%5D%20OR%20%28%22south%
20america%22%5BMeSH%20Terms%5D%20OR%20%22central%20america%22%5BMeSH%20Terms%5D%29%29%20AND%20AIDS%5Bsb%5D%20AND
%20%28%22human%22%5BMeSH%20Terms%5D%20OR%20%22hominidae%22%5BMeSH%20Terms%5D%29

Giver 16365 hits (5. august 2004)

mens...

Søgestreng:
AIDS[sb] AND ("human"[MeSH Terms] OR "hominidae"[MeSH Terms])

Link:
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=PureSearch&db=pubmed&details_term=AIDS%5Bsb%5D%20AND%20%28%22h
uman%22%5BMeSH%20Terms%5D%20OR%20%22hominidae%22%5BMeSH%20Terms%5D%29

Giver 198215 hits (5. august 2004)

> > Kan vi se hinandens pionter nu?
>
> Det er et godt spørgsmål, jeg har lidt svært ved at få de pointer du
> fremlægger til at danne et sammenhængende billede

Hva' så nu?

> Jeg synes der tegner sig et billede af at det ikke kun er Target Groups
> der skal AND eller OR + parentes foran - overvej det lige...
>
> Jeg har lavet en forenklet version på
> <http://www.garion.dk/webdesign/pubmed/index.html>.
> Så vidt jeg kan se tager den de parametre den skal ud af de to grupper,
> og vha. de to forskellige funktioner sørger den for at gruppere Target
> groups med AND-parentes foran, men ikke på første parameter.
>
> (Jeg tror så i virkeligheden at du skal bruge den funktion til flere af
> grupperne, men det er din overvejelse.)
>
> Hvis du gerne vil have "Search worldwide/limit to regions..."
> implementeret, så sig til, men ellers har du vist den
> javascript-funktionalitet du skal bruge her.

Det ser jo bare skønt ud

Men som altid, når man ser resultatet af sådan noget, opstår der nye erkendelser og "problemer":

* Du har ret i, at alle grupperne skal behandles på samme vis som "Target groups", altså startes og afsluttes
med en parentes. Det vil give en korrekt søgning.
* Jeg ved godt, at jeg har angivet, at den operator, der stod foran det første parameter i en gruppe, skulle
erstattes med "AND (". Nu er det dog gået op for mig, at dette ikke er tilstrækkeligt, hvis søgningen i alle
tilfælde skal svare til det, brugeren markerer. Problemet er, at hvis man f.eks. markerer NOT ud for en øverste
af de (eller det) parametre, der vælges under "Target groups", vil søgning ikke afspejle dette => da NOT
udskiftes med "AND(", vil der sket det modsatte, altså at der søge efter artikler, der bekræfter sig med det
pågældende parameter. Hvis søgningen skal blive rigtig, må modifikationen derfor være:
- Hvis AND står foran det førstvalgte parameter, skal AND erstattes med "AND (" (som nu).
- Hvis OR står foran det førstvalgte parameter, skal OR erstattes med "AND (" (som nu).
- Hvis NOT står foran det førstvalgte parameter, skal et andet parameter, der indeholder AND eller OR placeres
foran dette parameter, og AND eller OR skal derefter erstattes med "AND (".
--- Hvis der ikke er valgt andre parametre i den pågældende gruppe, skal der ikke foretages noget - der skal
altså ikke indsættes "AND", "(" eller ")" - parametret medsendes, som den er.

Jeg kan desværre ikke selv gennemskue, hvordan koden skal ændres fra det nuværende til at kunne håndtere disse
modifikationer - jeg bliver rigtig glad, hvis du er frisk på et se på det igen

- Ole


--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Ole Nørgaard wrote:

> Der mangler stadig en del layout, og radioknapperne o.s.v. vil naturligvis blive
> markeret mere tydeligt. Men da det nok kræver nogle tabeller, venter jeg for
> overskueligheden skyld med dette. Selve søgestrategierne er ligeledes langt fra
> færdigudviklede.

Jeg har lige sat tabeller på øverste sæt radiobuttons

mvh

Jesper

---

Ole Nørgaard wrote:


Lige et spm Ole! Hvorfor sidder du og håndkoder det hele selv? Du har jo
mulighed for at lave formularer i CMS'et, jeg er sikker på der er en fin
hjælp i manualen, til hvordan man laver formularer. Det er en af de gode
ting ved de fleste CMS'er (større) de tager altså noget af pinen ud af
at lave formularer.

Claus

---

Claus Jacobsen wrote in dk.edb.internet.webdesign.clientside:
> Ole Nørgaard wrote:
>
>
> Lige et spm Ole! Hvorfor sidder du og håndkoder det hele selv? Du har jo
> mulighed for at lave formularer i CMS'et, jeg er sikker på der er en fin
> hjælp i manualen, til hvordan man laver formularer. Det er en af de gode
> ting ved de fleste CMS'er (større) de tager altså noget af pinen ud af
> at lave formularer.

De muligheder, som findes i vores CMS' formularmodul tillader kun, at man
genererer e-mail eller sender data til en database. Desuden er der i dette
tilfælde tale om, at vi skal have sammensat en lidt kompleks søgestreng - og
det kan jeg ikke forestille mig kan gøres uden brug JavaScript.

- Ole

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials