One of my goals when developing note-viewer is to try various experimental features. Note-viewer started as a replacement for user’s notes pages. I could have tried changing it in the osm website code but then I’d be constrained by other things. And I want to do some things that are definitely not going to be on the osm website, maybe for a good reason because some of them will turn out to be useless and I’ll throw them away later. In fact, I’ve already thrown away some. If you were using note-viewer before did you notice that round note status icons in the table used to work as radio buttons? They don’t anymore, that was a way to select the date, now you just click the date. What does this date selection do is another topic which we won’t go into here.
Links in comments
What we are going to look into is getting links to various things mentioned in note comments. Actually when the API returns note information it sends note comments in two formats: plaintext and html. However we won’t rely on this html output because users commenting notes enter plaintext and don’t set any links themselves and in the html output everything that looks like a url gets a link, no matter how dubious the site is. We only want links to sites we trust. Obviously one of them is openstreetmap.org. Another one is StreetComplete’s image hosting. Currently that’s all what note-viewer handles, but other sites may get added in the future.
The goal is to get the relevant information without leaving note-viewer. Normal link with a solid underline works as any html link does: when we click it, another webpage is opened. Links with a dotted underline are treated specially. They can be used as normal links with middle-click to open a new page in a new browser tab. Left-clicking them does something inside note-viewer. Clicking StreetComplete’s westnordost.de image links replaces the map view with the linked image. Of osm links those that point to notes, changesets and elements are recognized. Note links do the same thing as if we click a note marker: scroll both the table and the map to show the note. The likely problem here is that the note is not loaded because it’s not among the note query results. I haven’t decided what to do in this case so now it just reports that the note is not loaded. The link itself can still be opened by a middle-click. Links to changesets show their bounding boxes on the map. Links to nodes, ways and relations show these elements. They also open popups with tags and other information.
How does note-viewer detect links inside note comments? When the link is spelled out fully starting with https:// that’s obviously a link. If it matches any of the recognized types, note-viewer replaces the plaintext url with a dotted hyperlink. Such links are found in comments when users copy-paste osm webpage urls. Some apps like StreetComplete also add such links in notes about osm elements (and some like MAPS.ME and its derivatives don’t). But when users write comments manually that’s too long to type. They may write something like “fixed in changeset 123456”. We may want to see this changeset but there’s no link. Could note-viewer have detected it as a link? Since references like this are written in a natural language that may not even be English, we can see that such detection efforts may fail. But we still want to open the implied link and we don’t want to type it ourselves.
Loose link parser
Here’s the experimental feature: note-viewer will try to detect such implied links, but only if we tell it to do so. We can tell it by selecting the part of a comment that contains the necessary information. The information is the id represented by a number and the type represented by a keyword such as changeset. So in the example above we could have selected “changeset 123456” like we normally select text (press left mouse button, move mouse, release button) and note-viewer would have tried to detect a link there. In this case it’s obviously a reference to a changeset so that the detection would have succeeded. And it does.
The next step for note-viewer is to present the detected link to the user. One way to do that would have been inserting the link into the comment text. That’s not what note-viewer does. What if we made an incomplete selection that doesn’t have enough information to figure out the correct link? Maybe the word “changeset” wasn’t selected or, worse yet, we didn’t select all of the digits of the id. Then we’d have ended with a broken link inside the comment. We could have tried selecting the right thing again but the link may be in our way. Text selection works differently on links, pressing the mouse button and moving the pointer may result in dragging a link. Even if we succeed, note-viewer would have to clean up the old link intersecting with our selection. But what if it was a legit link put by note-viewer before we had made any selection? Should it be removed? That’s a messy process we don’t want to get into.
Instead of inserting a link, note-viewer shows a popup with it. Actually it’s a popup with several links, one for each possible osm item type plus the detected type. The detected type link is the largest and is displayed right under the mouse pointer. In the best case scenario we can click it right after selecting the text. If the detection went wrong we can select one of the other links below it that refer to other possible items with the same id. And we’ll have to do this if note-viewer failed to detect any type because there will be no default link.
There are some problems with this approach. The obvious one is that we don’t expect stuff popping up under our pointer when we select text, that could be annoying. The first thing note-viewer does to mitigate this problem is to not show a popup when no link is detected. When note-viewer fails to detect a type, the popup still shows up if there’s a number in the text selection. That number is treated as an id with the type manually selectable in the popup. However if there’s no number it’s impossible to come up with a link. Therefore text selections not containing a number don’t cause the appearance of a popup. Actually the current requirements for an id is stronger than that. The number is required to be the last thing in the selection, the only thing that can follow it is whitespace. This restriction makes sense for languages I know but maybe there are some where it’s customary to write a type after an id number, so maybe I’ll reconsider.
If our text selection doesn’t end with a number, the popup won’t bother us. What if there is a number and the unexpected popup shows up? The next problem is that it covers the selected text. And the easiest fix for that is to make the popup transparent. Not very transparent because we want to be able to read the popup itself. Currently it has an opacity of 90%. Another thing to do about the unwanted popup is to make it go away as soon as possible. The popup is opened right under the mouse pointer in order to let the user select the link faster. But there’s also another reason for this placement. The popup disappears as soon as the pointer leaves it. With the popup initially under the pointer it’s possible to close the popup by moving the pointer away in any direction. Had the popup appeared away from the pointer, it would have to be entered first, and without moving the pointer over the popup it could get stuck on the webpage.
Faster selection
With these steps to make the popup unobtrusive the text selection process looks like the following from a user’s perspective:
- the user selects some text
- if it wasn’t intended for note-viewer to find references, chances are that nothing pops up and the user can proceed as usual
- if the unwanted popup appeared, the user can move the mouse pointer away
- if the goal was to get links and the correct link is detected, the user can click it without moving the pointer
- if only the id is detected correctly, the user has to select the links by moving the pointer, taking care not to leave the popup; that shouldn’t be difficult because the popup is large enough, although there’s an area for improvement here
All of this was predicated on the user making the correct selection. The selection action itself is more complicated compared to a click. A shaky hand and a button released too soon may result in an incomplete number selection. Then the popup is useless because the id is wrong. The selection has to be performed again with the user spending time again on aiming at the beginning and the end of the phrase. The more time is spent the less advantageous this process is compared to constructing the link by copy-pasting together the id and other parts of the osm website url. If we could get by with just clicking, everything would be easier and faster. But there’s no link to click, that’s why we have to select the text instead.
However there’s a possibility to select text by clicking or, to be exact, by double-clicking. The browser selects a double-clicked word. Our primary goal is to select the id so we double-click the number. But then we don’t select any keyword that may indicate a type. Isn’t that a problem? Maybe, but note-viewer tries to get around it. In case of a double-click the entire comment text preceding the selection is also treated as selected. Isn’t it too much irrelevant text to process? Again maybe, but note-viewer looks for a keyword that is located closest to the number. If there’s a keyword near the number, it doesn’t matter how much stuff precedes it in the selected text. The problems are going to arise only if there’s no recognized keyword related to the number, but the comment has an unrelated keyword far away that we wouldn’t have selected. In this case we’re going to have a false positive with a likely incorrect type of a default link. This is not the biggest problem, we can just select the correct type manually. We probably were ready to do it before our double-click because we knew that there’s no keyword near the clicked number, so we won’t blindly click the default link in the popup.
Now our fastest way to get the link to some osm item with an id is to double-click the id. Note-viewer then looks at the comment text from the beginning up to the clicked id and gives us a bunch of links, maybe gives us the default link right under the pointer, and maybe this link is correct. If that is supposed to work fine why doesn’t note-viewer always looks at the text starting from the beginning of the comment, even when we select text by moving the mouse? The answer is that the user is expected to mainly do double-clicks selections because that’s faster and use mouse-move selections when double-clicks fail to tell note-viewer exactly where to look.
Unwanted focusing on markers
So double-clicks are great, we almost always want to use them. Unfortunately there is one conflict between them and previously implemented note-viewer behavior. Note-viewer shows notes both in a table and on a map. We want to know which map marker corresponds to a given table row and vice versa. When a marker is clicked, its table row is scrolled into view and highlighted. A similar thing happens when the row is clicked. Now we can see the problem: the entire table row of a note reacts to clicks to focus on its map marker. But clicks are also used to select ids. When we select an id by clicking it, the table may pan and zoom to the note location. Maybe we don’t want this. There are ways to deal with this but I haven’t yet decided which one to use and if any one of them is worth using.
One way is to stop focusing on markers when the note row is clicked and introduce some other method of doing it. Maybe put a button there saying “show note on map”, but that would clutter the table with another input element repeated as many times as there are notes. Introducing such elements made little sense early during the development when the comment column had no links in it. The comment column is usually the largest one, therefore clicking the note is usually clicking one of its comments. Even now the comments are mostly free of links, so it still makes sense to focus on notes by clicking them anywhere in the table.
Another way to deal with unwanted map movements is to try to differentiate between clicks. Notes focus on a single click. Text selects on a double click. Aren’t these different clicks that can be distinguished? Yes and no. These are different click events, but double-click event doesn’t replace single-click events, it happens after them. When we do a double-click, a single-click event happens, then after some time another single-click event and after it a double-click. When the first click event arrives, that some time hasn’t passed yet as we haven’t made a second click yet. But that single-click event is enough to activate the map movement. Of course we wouldn’t want to move the map had we knew that the second click is coming. We don’t know that however, knowing about the next click would require a time machine.
Since we don’t have a time machine, we may instead wait for some time for the second click. If after some time it doesn’t happen we’ll focus on the map marker, otherwise we’ll do the popup. But how long is this some time? We don’t know exactly, the specifications say it depends on the environment. Basically, there’s an UI setting somewhere for the user to set how fast they double-click. If we don’t know its value we can guess that it is somewhere around 200 milliseconds. So we could wait after the first click event for, say 300 milliseconds, and if by then a second click event doesn’t arrive, we’d focus on the marker. The problem with this plan is that 300ms is a noticeable delay. The user is going to see this delay between the click and the map movement and it would be annoying.
There are some possible fixes for this delay. Maybe we don’t need to delay everything. Maybe there are different degrees of annoyance between unwanted delay, unwanted pan and unwanted zoom. For example, if unwanted zoom is the most annoying of them and unwanted pan is the least annoying, we can do the panning as soon as the first click happens but delay the zooming. We can also check if some modifier key is pressed during the click. Holding the key may signal to move the map right away or, conversely, to delay it. Of course it’s not obvious which way is better and what key to hold. It couldn’t be Shift though because Shift affects the text selection. But maybe we don’t need to do anything about these unwanted map movements, maybe its ok for them to happen.
Final considerations
Whether this popup feature is useful depends on how well it can detect the references inside the text. This is language-dependent and I still haven’t done any language support other than English. It’s impossible to support every language but mainly it’s the number that needs to be detected, hopefully there will be no surprises with that. You can post some links to notes that you think note-viewer should be able to parse but doesn’t. Or those that incorrectly detected when it’s cleat that they shouldn’t. I probably will add negative keywords like “phone” so that phone numbers often met in onosm.org notes don’t get picked up as possible ids.
Another possible complication is that the references are not necessarily coming in keyword-number pairs. One keyword may refer to multiple id in a phrase like “nodes 123 and 456”. Since note-viewer doesn’t try to get all references and is looking for just one, there shouldn’t be any problems in this case. The number that is the last in the selection, or the only one in case of a double-click, is going to be the one included in the link. Just double-click 123 to get a link to node 123 or double-click 456 to get another node.
Do you find this feature useful or annoying? Maybe you like it so much that you want it on regular osm website pages? It’s possible to make a browser extension for this with a possibility to add links to the context menu.