Land cover colours and camera-trap videos

The colour a land cover class is drawn with on the map could not be changed: it was assigned when the class entered your map and stayed that way for good. The problem showed up whenever two different categories ended up with colours that were too similar, or even identical: the map became hard to read at exactly the point where you wanted to tell an arable field from a permanent meadow, and there was no way to fix it from inside the platform. Now, next to every class in the land cover list on the left, the little coloured square has become a button: click it and a palette of suggested colours opens right there, so you can pick one without opening any window or entering the editor. The suggestions are not a fixed swatch book — they are computed each time on your own site: the platform rules out the colours already used by the other categories on your map, keeps a minimum visual distance from each of them, and stays well clear of the colours reserved for the catalogue classes, so a category you add in the future will not clash with the one you are colouring now. The palette deliberately spans the whole range — vivid, pastel, deep, dark and muted shades — and is ordered like a rainbow, with the light versions before the dark ones, so if you already have "a darker green" in mind you will spot it at first glance. The same picker is also available inside the manual editor, on the swatch of the area you are editing, so you can fix a colour while drawing without interrupting your session. Every colour change creates a new version of the land cover, exactly like a change to the drawing: the previous version is not overwritten and you can always go back to it. Redrawing the map and every view derived from it now happens on our side and finishes in a few seconds, without your computer having to reprocess the image. If something does not go through you get a message explaining why, and the list of versions realigns on its own instead of staying stuck on outdated information. The feature appears for anyone with editing rights on the site, on desktop, and you will find it under XNatura → Monitoring → Site → Land use, by clicking a class's colour square.

The Overview opens with a full-width cover: the image that welcomes anyone visiting your platform, together with the project's title and description. Its height, though, was decided once and for all and was the same for everybody: on some platforms it took up too much room and pushed the important content below the first screenful, while on others it was so short that the chosen photograph was barely visible. Now the height is yours to set: inside the "Edit cover" window there is a slider called "Section height", with an explanation of what it controls, and you drag it until you find the proportion you prefer. As you move it the cover changes height behind the window, in real time, so you see the result before saving instead of having to close, look and reopen. The value is bounded by a minimum and a maximum, so the title and description always stay readable and the page keeps its balance, and the starting value is the one the platform used until yesterday: if you touch nothing, nothing changes. The setting is saved on your platform and applies to visitors too, not only to you while you are editing. On the same occasion we renamed the command to "Edit cover", because it opens a window where you do not just change the image but also adjust how the section looks, and "Edit" is the same word we use for the other content you can personalise. The height of the storytelling cover remains a separate setting with its own slider: the two covers are measured in different ways, and adjusting them separately avoids having to pick a compromise that suits neither. You will find the new slider under XNatura → Overview → Edit cover, and it is visible to anyone with platform administration rights.

Every time the camera trap detects movement it records two things: a photograph of the trigger and a short clip of whatever moved in front of the lens. In the sensor's gallery, however, only the photographs were visible: the clips were silently discarded, with no warning at all, and anyone browsing the collection had no way of knowing they existed. On a sensor with a few dozen detections that meant half of the collected material was invisible in the platform even though it had been stored correctly and was available: it was never a storage or an upload problem, only a display one. Now the clips appear in the gallery alongside the photos, with a small "Video" label that tells them apart at a glance, and their preview is loaded lightly so that opening the collection does not become slower. Clicking a clip opens it full screen and it starts on its own, looping and without sound, with the playback controls available so you can pause it or scrub to the point you need. Photographs keep behaving exactly as before, so nothing changes in the way you browse the stills. We also made sure every clip is always requested over a secure connection: some addresses arrived in a form that the browser refuses to open inside a protected page, and that alone was enough to prevent playback even when the video was perfectly intact. The detection count and the rest of the sensor card do not change: all that is added is the material that used to stay hidden. You will find the gallery under XNatura → Monitoring → Census → Sensors, by opening a camera trap's card.

When you bulk-upload the observations of a census you can optionally state which support or device they refer to, choosing it from a list with a search field at the top. That field, though, only kept a single letter: every key you pressed replaced the previous one, so typing a sensor's name was impossible and the only route left was scrolling through the whole list by hand. The flaw was identical in the multiple-upload window and in the one that pulls files from your online archive, because the two used separate copies of the same picker. Now you can type the complete word: results narrow down as you type, matching the sequence of letters anywhere in the name, and the arrow keys plus Enter select the highlighted entry just as you would expect. The rows of the list no longer reorder under your fingers while you type, so the entry you were aiming at stays where you saw it. We also fixed a more insidious behaviour: the "No device" row, which exists so you can attach no support at all, stayed visible while you were filtering and ended up highlighted first, so an Enter pressed in haste could silently wipe the reference support of an entire upload. That row now appears only when the search field is empty, which is when it really is a choice rather than an accident. Finally, the picker has become a single component shared by both windows, so from now on they behave the same way and future fixes automatically apply to both. You will find it under XNatura → Monitoring → Census → Multiple upload, in the support picker.

Wherever you have to state which crop or land cover class an area corresponds to, the choice is made from a list with a search field. On opening, though, the list already came up full: it showed the first page of the catalogue in alphabetical order, which — given how the catalogue is built — is a group of forest associations and does not contain a single agricultural crop. The effect was misleading in the worst possible way: agronomists read that first page, concluded the platform did not have crops at all and gave up looking, in some cases saving an approximate class in their place over areas that were anything but small. Now the list no longer tries to guess: on opening it invites you to type at least two letters, with a sentence that says so explicitly instead of a page of irrelevant results, and the real matches appear as soon as you start typing. The same fix applies in all three places where a class is chosen — the land cover editor and the two editors that work on the map files you upload — because they used the same list and suffered from the same flaw. We also sorted out two details that were immediately noticeable around this: the loading spinner no longer appears before you have typed anything, and when a search finds nothing it tells you so in a sentence instead of leaving you in front of an empty box. The hint is also connected to the field for people navigating with a screen reader, who hear it read out together with the search field as soon as it receives focus. Clearing what you typed brings the list back to its initial message, without leaving the previous search's results on show. You will find the pickers under XNatura → Monitoring → Site → Land use, by opening a class's editor.

In the WebGIS, when you delete a layer, the platform asks you to confirm before proceeding. The confirmation button, however, became clickable again halfway through: as soon as the layer was deleted the button woke up, while the window stayed open for another moment to refresh the list. Within that window of time a second click — even just a double click out of habit — sent a second deletion request for a layer that no longer existed. The result was disconcerting: a success message and an error message appeared together, and it was unclear whether the layer had been removed or something had gone wrong. In reality the layer had always been deleted correctly on the first click: it was only the second attempt, inevitably pointless, that produced the error. The button now stays busy for the whole operation, refreshing the list included, and only comes back to life once everything is finished. On top of that, if a click does manage to get through, it is ignored instead of firing a second request. So you will see a single message, the one that genuinely describes the outcome of what you asked for. Nothing changes in the way layers are deleted or in how the confirmation window looks: all that changes is that you can no longer do it twice by mistake. You will find it under XNatura → Monitoring → Site → WebGIS, in the layers panel.

In the Regeneration section of the Overview, two cards describe the effect of the plants that have been put in the ground: the CO2 absorbed and the nectar produced. The species-by-species breakdown, however, existed only on the first one, and it held three columns: the plant, the CO2 and — out of place — the nectar too. The nectar card, the one those figures belong to, had no breakdown at all, so the nectar values were read under the wrong headline, and it was reported to us as a source of confusion. Now each card carries exactly the metric it is about: the CO2 card lists plant and CO2, the nectar card lists plant and nectar, each with its own expandable panel. Each list is also sorted by its own metric, a detail that matters more than it seems: by reusing the CO2 order, the nectar panel could have opened with a species worth a few hundred grams at the top and the most generous one a few rows below. Every species stays listed on both cards, zeros included, so the number in brackets on the toggle always matches the rows underneath it: hiding the zero rows would have meant making real data disappear. The note about flowering months has moved to the nectar card, which is where it is genuinely useful. The nectar breakdown, it is worth remembering, decomposes the value shown at the bottom of the card — the selected year's potential — and not the big number at the top, which instead adds up the nectar produced across every year of the project: the note under the panel says so explicitly, so the two numbers do not look like a contradiction. Both panels are built from the same information already used for the CO2 card, so the page makes no extra requests and does not get slower, and either one disappears by itself if its metric has no data. You will find the two cards under XNatura → Overview → Regeneration.

In recent days we started delivering the platform's videos as direct files, without an external player frame to load first and without temporary addresses destined to expire, and we mentioned that a few particularly long videos would be moved over the following days. That transition is now complete: every video you come across in the platform, the longest ones included, is delivered with the new system, so it starts sooner and responds better when you scrub back and forth along the progress bar. Uploading the project video in the storytelling has been brought in line with the new system, so a video you upload today is published and played back with no intermediate steps. We also repaired the tab where you paste the address of a video already published elsewhere, which after the transition worked in neither direction: a new address was refused by the form before being sent, while an old one was accepted by the form and then rejected on saving, so in practice no address could work at all. The form's check now recognises valid addresses and is the same one used behind the scenes. Another fix concerns the videos' cover images: the platform could no longer retrieve the official one and fell back every time on a still frame grabbed by the browser, which is less sharp and requires downloading a chunk of video before it appears. The correct cover is now requested and shown again, so previews look better and appear straight away. Finally, we updated our pages' security settings so that the new video delivery is always authorised: without that step the browser would, in some cases, have blocked playback even though everything was in order. You do not have to do anything and nothing changes in appearance: the same videos, in the same places, simply readier. You will find them under XNatura → Overview → Storytelling and in the other sections where video content appears.

The banner that asks for cookie consent is the first thing you see when opening the platform from a new device, and it was not up to the standard of the rest of the pages. On a wide monitor it was a strip running from one edge of the screen to the other, with the text pushed all the way left and the buttons all the way right, separated by an enormous gap that made it hard even to work out which choices were available. On some pages, moreover, it appeared without its intended styling: no rounded corners and no shadow, like a rectangle pasted on top of the content. On a phone it floated a couple of centimetres above the bottom edge, leaving a strip of page visible underneath that made it look like a misplaced element. Now, on desktop, it is a compact card centred just above the bottom edge, so the distance between text and buttons no longer depends on how wide your window is; on a phone it is a panel resting against the edge with rounded top corners, which respects the space newer phones reserve at the bottom of the screen. Accept and decline have the same size and the same visual weight, as consent rules require, and "Customise" wraps onto a row of its own only when space is genuinely tight. We moved the colours onto the platform's own palette and put dark text on the yellow, where before there was white text that was practically illegible. The outline that marks the active button now appears only to people navigating with the keyboard, and animations tone themselves down if you have asked your system to limit them. The preferences window has been rebuilt with the same buttons too: the categories are a simple list separated by dividers instead of four nested boxes, and the header and footer stay put while only the list scrolls. The available choices and what they mean do not change: all that changes is how easily you can make them.