I left Japan on the evening of September 4.
To reflect on the development work in Linz, I need to start about a week before departure. I was preparing the app for use there, and that work continued after I arrived.
timespace ZINE turns photos taken around a city into stories about those places. In Linz, we were also putting generated articles into printed ZINE booklets.
This is a look back at what I prepared, what I changed on-site, and the decisions I made along the way.
A Week Before Departure, I Was Still Working on the Foundations
A week before leaving, I was finishing multilingual support.
That meant more than translating the interface. Articles needed to be generated, translated, saved, and made available in each language. If processing stopped halfway through, the system also needed to be able to resume.
By the end of August, I had reached a milestone on that work and moved on to connecting our research database to article generation. The aim was to use the photo’s location and camera direction to select relevant information, then turn it into an article.
But having the code in place didn’t mean it would work immediately in the deployed environment. Testing revealed configuration mismatches and startup processes that took too long. Each issue meant another fix and another check.
On September 3, I was still making adjustments after 4 a.m. Japan time. On the day of departure, I was still fixing startup behavior and article storage.
Then I left Japan. There was still work to test and refine on-site.
The Adjustments Continued in Linz
Things didn’t go as smoothly as I’d hoped after arriving.
I was checking that the app passed the correct location when a photo was taken, that interrupted generation could recover, and that everything still worked through to saving the article after an update.
Even when I wanted to focus on the writing, I first needed to make sure we could reliably generate and read the results. I kept moving back and forth between improving the articles and fixing the system that produced them.
For four consecutive days in Linz, I slept about four hours a night.
Making a fix was only part of the job. I had to deploy it, run it, and check the result. If something failed, I investigated and tried again. That cycle left too little time for rest.
The development work I had started before departure was still going, while I was also trying to improve the articles for the printed ZINE.
For the Booklet, I Chose to Prioritize Quality
One decision I had to make was how to balance quality and speed.
In an app used while walking around a city, articles should come back quickly. A long wait can interrupt the moment that made someone take the photo in the first place.
But we were also making a printed booklet.
What reaches someone holding that booklet is the writing on the page, not the time it took to generate. For this purpose, I decided to shift the balance toward quality.
We introduced a step to select the information for an article before writing it. We also revised the writing instructions to bring out more specific stories and discoveries about each place.
Adding a step meant paying attention to the extra waiting time. Still, at that point, I wanted to get the content to a level we would want to put in print.
An article delivered on a phone and one handed over on paper can use the same generation system, but they call for different priorities. I was making those decisions as we built and used it in Linz.
The Articles Improved. The Titles Didn’t Keep Up.
As we refined the process, the body text got better.
Then the titles started to bother me. There was an interesting story in the article, but the title wasn’t conveying it.
There was something to discover once you read it. Before reading, though, you couldn’t tell.
Improving the body text didn’t automatically improve the title. Reading through the articles made it clear that the titles needed their own attention.
I wanted each title to contain something distinctive about its article: a short, natural phrase that made someone want to keep reading. I changed the instructions to remove metaphors, modifiers, and abstract language that added no meaning.
What was interesting about this particular article? Which part belonged in the title? Making the wording shorter still required looking closely at the story.
I would read the generated text, identify what felt wrong, revise the instructions, and generate again. Alongside developing the system, I was doing something much closer to editing its output.
Next: Delivering This Quality Faster
Before departure, I was working on making articles available across languages, from generation through to storage and reading. In Linz, I was fixing that system while refining the body text and titles for print.
Some work carried over from before the trip. Other issues only became clear when we used the app on-site. With several nights of too little sleep, it wasn’t a comfortable way to work.
But having something concrete to deliver made the next changes clearer. I wanted the articles to be more interesting, and the titles to communicate what made them worth reading. For the booklet, that meant choosing to prioritize quality.
The next task is to preserve those gains while reducing the wait for someone using the app on the street.
I want to return an article they want to read while the curiosity that prompted the photo is still there. That’s the experience I want to build on the work we did in Linz.
