Terug naar de blog

Eén woord zoeken in een lokale documentatie van 3.000 pagina's, op iPad

Je hebt de map. Hij staat in Bestanden, hij opent, de pagina's volgen elkaar netjes op. En je zoekt een zin waarvan je weet dat hij erin staat: een aanhaalmoment, een contra-indicatie, de alinea die uitlegt wat je moet doen als de module niet wil starten.

Op een computer zou je de map in een editor openen en in drie seconden door alle bestanden zoeken. Op een iPad bestaat daar geen equivalent van. Hier is waarom, en wat je eruit helpt.

Waarom iOS niet in je map zoekt

Het zoeken van de app Bestanden zoekt naar bestandsnamen, niet naar de inhoud ervan. Spotlight indexeert wat apps hem aanreiken, en een HTML-map die in een opslagruimte is gezet reikt hem niets bruikbaars aan: geen inhoudsopgave, geen koppen, geen tekst.

Safari opent op zijn beurt geen lokale map. En zelfs als het een losse pagina opent, kijkt zijn "Zoek op pagina" alleen naar die pagina. Bij documentatie van drieduizend pagina's komt dat neer op een zin zoeken in een boek terwijl je maar één pagina tegelijk mag bekijken. Ben je nog niet zover, begin dan bij een HTML-bestand openen op de iPhone.

Wat "in documentatie zoeken" echt betekent

Wie in een technisch corpus zoekt, zoekt geen voorkomen. Hij zoekt een plek. Drie dingen tellen, en ze komen zelden samen voor:

Het geval van gescande PDF's

Een flink deel van de oudere documentatie is gescand. Een gescande PDF is geen tekst: het is een afbeelding van tekst. Geen enkele zoekfunctie kan er iets in vinden zolang niemand de afbeelding heeft gelezen.

Dat kan op het apparaat, zonder ergens iets naartoe te sturen. Twee punten maken in de praktijk het verschil: dat het op verzoek gebeurt (honderden PDF's automatisch herkennen zou de batterij voor niets leegtrekken), en dat tabellen tabellen blijven. Op een productblad of een bijsluiter maakt een tabelrij die in woordenbrij verandert het resultaat onbruikbaar, en dat is nu net waar de gezochte waarden staan.

Wanneer je de woorden niet meer weet

Het echte obstakel is vaak niet technisch. Je weet wat je zoekt, maar niet de term van degene die de handleiding schreef: die schreef "circuit ontluchten", jij zoekt "remmen aftappen".

De vraag in gewone taal stellen lost dat op, op één voorwaarde: dat het antwoord het document blijft. Bij technische documentatie is een geschreven antwoord een gereconstrueerd antwoord. Het mengt graag twee naburige procedures en houdt een waarde vast die bij het andere model hoorde, met dezelfde stelligheid. Bij een aanhaalmoment of een dosering valt dat niet meer terug te draaien.

Wat je wil is de passage: het document, het hoofdstuk, de pagina's. En de oorspronkelijke tekst, in zijn context, om te zien wat eromheen staat.

En waarom dit allemaal offline moet gebeuren

Kijk waar deze documentatie werkelijk gelezen wordt. Onder een motorkap, in een werkplaats in de kelder. Op een ziekenhuisafdeling waar het netwerk bij de deur ophoudt. Aan boord, in de lucht, op zee. In de trein.

Een zoekfunctie die je zoekopdracht naar een server moet sturen, werkt op geen van die plekken. En bedrijfsdocumentatie, een patiëntendossier of een technische handleiding onder contract horen sowieso niet op de server van iemand anders. Een zoekfunctie die volledig op het apparaat draait, regelt beide kwesties tegelijk: ze werkt zonder netwerk, en er valt niets af te vragen over wat er vertrokken is.

In de praktijk

Dat is wat Pagira doet sinds versie 2.0. Je opent de map, je typt je woorden, en het doorzoekt alle pagina's en alle PDF's tegelijk. De resultaten komen gegroepeerd per document terug, er een openen brengt je naar de juiste pagina met je woorden gemarkeerd, en het tabblad ernaast neemt een vraag in je eigen woorden aan wanneer de exacte term je ontglipt. Gescande PDF's maak je op verzoek doorzoekbaar. Alles gebeurt op de iPhone of iPad, zonder account en zonder verbinding.

Download in de App Store

Meer uit de blog