Back to the blog

Searching a 3,000-page local documentation set for one word, on iPad

You have the folder. It is in Files, it opens, the pages follow one another properly. And you are after a sentence you know is in there: a torque figure, a contraindication, the paragraph explaining what to do when the module refuses to start.

On a computer you would open the folder in an editor and search across every file in three seconds. On an iPad there is no equivalent. Here is why, and what gets you out of it.

Why iOS does not search inside your folder

The Files app's search looks for file names, not their content. Spotlight indexes what apps hand it, and an HTML folder dropped into a storage space hands it nothing usable: no table of contents, no headings, no text.

As for Safari, it does not open a local folder. And even when it opens a single page, its "Find on page" only looks at that page. On documentation running to three thousand pages, that is like searching a book for a sentence while only being allowed to look at one page at a time. If you are not there yet, start with how to open an HTML file on iPhone.

What "searching documentation" really means

When you search a technical corpus, you are not looking for an occurrence. You are looking for a place. Three things matter, and they are rarely all present:

The case of scanned PDFs

A good part of older documentation is scanned. A scanned PDF is not text: it is an image of text. No search can find anything in it until someone has read the image.

That can be done on the device, sending nothing anywhere. Two points make the difference in practice: that it is on demand (recognising hundreds of PDFs automatically would drain the battery for nothing), and that tables stay tables. On a product sheet or an instruction leaflet, a table row turned into word soup makes the result unusable, and that is precisely where the figures you are after live.

When you cannot remember the words

The real obstacle is often not technical. You know what you are looking for, but not the term used by whoever wrote the manual: they wrote "circuit bleeding", you are searching for "brake flush".

Asking the question in everyday language solves that, on one condition: that the answer stays the document. On technical documentation, a written answer is a reconstructed answer. It readily mixes two neighbouring procedures and keeps a figure that belonged to the other model, with the same confidence. On a torque figure or a dosage, that cannot be walked back.

What you want is the passage: the document, the chapter, the pages. And the original text, in its context, so you can see what is around it.

And why all of this has to happen offline

Look at where this documentation is actually read. Under a bonnet, in a basement workshop. On a hospital ward where the network stops at the door. On board, in flight, at sea. On a train.

A search that needs to send your query to a server works in none of those places. And company documentation, a patient file or a technical manual under contract have no business on somebody else's server anyway. A search that runs entirely on the device settles both questions at once: it works with no network, and there is nothing to wonder about regarding what left.

In practice

That is what Pagira does from version 2.0. You open the folder, you type your words, and it searches every page and every PDF at once. Results come back grouped by document, opening one takes you to the right page with your words highlighted, and the tab next door takes a question asked in your own words when the exact term escapes you. Scanned PDFs can be made searchable on demand. Everything happens on the iPhone or iPad, with no account and no connection.

Download on the App Store

More from the blog