Iterating to a solution
Sometimes it takes a few attempts to get something right.
Changing IDsβ³
When edits to section heading, their IDs can change. So what happens to link to it?
The problem
Some elements, like sections and glossary entries, have an ID that allows them to be a target of a link. The IDs are derived from the master locale heading text, so changing that usually means that their ID changes. If any links point to them, those links would now be broken. Leaving it up to the site owner to fix broken links could mean a lot of work for them. This article details the journey from this situation to the final solution.
- 1.List the dependencies
This provides a visual indication of the extent of dependencies and what would have to be manually corrected by editing the links within the current article and in other articles.
All the links are listed in theLinked from section of the article'sArticle head page, but that is not the same as having only the relevant ones in a list at the element itself. Seems silly to not update the links in the current article, especially since it is open. - 2.Fix internal links
This was not too difficult. I kept thinking that the way I constructed the product would make it too difficult to update all the other articles or that it could not be done reliably.
The problem is that all the dependencies disappear when the ID is changed, requiring writing them down beforehand. - 3.Remember the current dependencies
An attribute on the element looked like a good candidate, and then using that to add to the list, reducing with each article updated.
That brought up a lot of issues around where that status showed up in the element block and on theHistory page, in addition to removing completed ones from the attribute. This just made it all too messy and definitely not elegant. The real issue was that even a moderate number of dependencies meant a lot of editing sessions over multiple articles. Fully automated updating is mandatory from a user perspective, and it must be possible. - 4.Remember the current dependencies V2
The way I avoided messy editing of multi-item information elsewhere in the product was to put each discrete item of information in its own filename, allowing simple deletion without having to worry about the integrity of a holding structure with possible simultaneous updates.
The next issue was where and when to process the files. I was getting myself mixed up with trying to work out what files had to be updated, what routing was best to process the files, and when in the sequence to process them. - 5.Update the latest releases
All dependencies are kept in the element metadata XML file, but those dependencies are only listing links to releases, not WIPs or drafts, so only a new release version of the latest release of each article with links has to be created. The changed IDs cannot be targeted by any link until the article is released, except within the article being edited.
Once I was clear about what had to be edited, it was then clear when the process had to be done, and what would do the processing. For some confusing reason, I was thinking that the process would involve several routines in a multi-phase approach. - 6.Process at release time
This only required one new routine, using an existing routine to do the cleaning up, to which I added an additional parameter to make it only regenerate the metadata links listing for an article, rather than also processing its files and fragments lists as is done when releasing an article after editing.
This resulted in an elegant solution that only touches what it has to, and does not have timing dependencies that might have let some changes get missed.
This took a couple of days, but that is so tiny compared to the humongous effort that countless people would have had to have done to do it all manually. Of course, such things should be done automatically, so I was wondering why I ever thought that it was OK to not include it.
There is one situation that will still let links not be updated, and that is when any of those articles linking to the current article are being edited at the same time as it is being released. Only the latest release versions of those articles will be automatically updated, but any drafts or WIPs after that will not. Any links in those articles being edited will need to be updated manually before their release. Those links will show Κ?Κ for their text, so search for that in them.
Accessibilityβ³
Working out what is required is an ongoing process.
The default HTML styling for links is blue with underlines, but too many of them can make pages look cluttered, which is why I removed the underlines and toned down the colour in the product, fitting in with the design aesthetic of not giving people a reason to go somewhere else. However, those with visual difficulties may have trouble distinguishing such links from the surrounding text, so in accessibility mode, all links and jumps got the underlines.
Not having visual issues, it took a while to get enough time with the management pages in accessibility mode to notice that the underlines made them far too cluttered. Unlike with public-facing pages, where visitors will likely not be familiar with the interface and where links might be, the management pages are full of links which are in specific places, so users should quickly get used to where they are. There are no underlines in the management pages now.
After a while though, it struck me that home, navigation and category pages had enough prominent links to make them look cluttered when underlined. Their position made it obvious that they were going to be links, so they really didn't need underlines. The other obvious places were navigations bars, related links, the β³ links to parent elements, and of course the big block at the bottom of pages called
When really looking at it, the only place on the pages where a new visitor may not be sure about links is in the body of the articles themselves, so I limited the underline CSS to links in them. However, the product uses links for list items, table numbering columns and glossary headings to target the first letter of their introduction. Having those underlined made them look cluttered, and since those links only really benefit keyboard navigators, who would quickly find that they were links because they had to tab through them, their underlines were blotted out as well.
There are some subtleties as to which optional links to underline. Figures might have an owner link under them, so they should be underlined. But cards can as well, but a blanket underline veto on navigation elements would prohibit them. One exception added. Galleries might have some images with owner links, but they are also navigations. Another exception added. I think that has the accessibility underline situation handled, for the moment!