UKC

Our developers go into some of the technical aspects of how Rockfax Digital works under the hood.

Read more

Thanks for that Steve, all pretty amazing tbh - and that's only the 5% I understood!

Chris

youtube.com/watch?v=Z7_QQn_2McM&

Great stuff.  I look forwards to part 2.

Always nice to find someone else has hit the point where they decide it’s going to be easier to cast a load of points and see if any fall in the box, than to solve the intercept equations!  Very glad I’ve never had to do so in JS...

Cool article, interesting to peak behind the curtains! Very impressed with the amount of automation you've managed to build in to extracting info from the topos too; even for something like rf topos that appear fairly well structured I imagine there's a whole world of weird little edge cases and idiosyncrasies to take in to account.

Do you think rockfax will convert to being digital first at some point? i.e. will the database + interactive topos become the reference rather than the books? From my totally naive "wouldn't it be easier if you just..." point of view, I would have thought going from a structured database in to a book format would have be easier than doing things the other way round.

I'd also be interested to understand how you deal with changes in formatting between different books. I imagine the layout in the books has evolved through time, so is it tricky accounting for those changes when you're extracting the data?

Nice article, would it be possible for the menus to be given accordion menu actions e.g crags and routes on guide books and logbook on dates so saving on the endless scroll.

Plus I quite like the public voting of grade on UKC but not on the app, which might make a community of being involved in any possible grade change.

We've thought a lot about this. I'd love to remove some of the complexity, and this idea seems at first blush like it could do that. But every time I think through the implications, I come to the conclusion that it just wouldn't work that well for us. There's a few reasons for this:

A very large portion of the work in making a book is the layout. This can't be automated. So a DB-first system would, at best, spit out a load of topos and route descriptions that would then need laying out by a human. As soon as you have this half-automated system you end up with two "sources of truth". Imagine the situation where you've done the initial DB to InDesign export, then spent months working on the book, then you get corrections for some routes. You now have to put them into two places. If the DB-export was 100% automated you'd just put them in the DB and press the "generate book" button again, but it wouldn't be. We do have that the other way around though already; any changes to the book information can be extracted and inserted into the database in a few clicks.

Another big one is that we're beginning to act as a platform for third parties to publish their guides on (the SMC is the first publisher to get on board). Any back catalogue is going to be InDesign based, so a DB-first setup won't help there.

In the end, we've already got the system we've got, so making a new one that doesn't totally replace it, and remove all of the problems we face would just add to the size and complexity of it all.

This was a big deal in the beginning. We had all these books we wanted to put into rfdigital, some made that year and some made eight years before, so the variation was massive. And the variation in consistency of conventions was massive, that was the big problem. It was dealt with either by adding flexibility to the parser (which uses contextual information to do with the current page or object in InDesign and a collection of regular-expression patterns for breaking apart text), or sometimes by admitting that not everything needs to be automated and just fixing the broken bits in InDesign when I came across them.

Often in old books, somethings will have been done differently to now, but consistently at least, so it's way easier to write a throwaway script for InDesign to globally change these things than it is to add more rules to the parsing engine to account for them.

That makes a lot of sense with regards to whether to use the DB or indesign files as your source of truth. It sounds like you've either got the tricky problem of extracting route info etc. from indesign or the tricky problem of automatically laying out a book using info from the database. Better the devil you know!

Im very impressed your tooling is flexible enough to handle guides from other publishers!

interesting although I got lost in some of the technical stuff, I've some experience of producing documents (books & reports) from databases but have never considered how to go the other way.

But is 'architected' a word ?

It's not =]

Klang was designed to allow the parser element to be hot swappable, the idea being I'd write a new parser for each third party, but I've not done that in the end. Turns out that we rely on certain rockfaxy things, like grade-based colouring, left-to-right route layout, all routes must have a topo number etc. All these little things, combined with the value of having consistency in the style of the information mean that it's better to convert the indesign docs we receive from third parties to be rockfaxy, then feed these new docs into klang.

Of course, this means we've definitely got the problem of two sources for these documents =|

Possibly only amongst the IT crowd where it's not unusual. "Designed" mighty have been a better choice. Nathalie pulled me up on "munging" too, which is so deeply ingrained in my personal vocabulary I no longer realised it was a bit jargony, but we left it in there because I'd already used "wrangling" a few times and couldn't think of replacement.

This doesn't play well with the filters that we have on routes, and will have on crags at some point. There are features coming that will alleviate this issue though.

This is on the roadmap, but no date for it yet.

It is amongst those who design architectures...