Roadmap 2023
We have started the year strong by rewriting most of the tools which are visible on the map. These are already available in the oskari-frontend in version 2.10. This has also given us the opportunity to improve theming support in Oskari. Now the colors and rounding of the buttons on the map (and popups which they open) can be modified by using theming. This is an especially strong feature for the publisher functionality. We have also improved styling tools on the publisher functionality to make it easier for end-users to match styling of the controls on the map with the page the map will be used on. You can see these changes already in https://demo.oskari.org.
There are also other major changes that have happened “in the engine room”, such as overhauling the HTML/DOM structure that Oskari builds on (also available on Oskari 2.10). This enables us to better serve users with small screen sizes and/or mobile devices and makes it easier to customize the page around Oskari functionalities for a more personalized geoportal. We have added a new example on our sample-application to demonstrate this. This is an important milestone towards mobile friendliness for the geoportal. It doesn’t mean that we have completed our goals, or even started really for mobile users, but it is an awesome starting point for what we can now start building on.
The embedded maps have been mobile friendly for years already, but we have made some changes to those as well. Previously we used something that we called “a mobile toolbar”. This meant that tools on the map would move to a toolbar on top of the map when there’s limited screen space available. In consequence, even with a single button (or two) on the map, we reserved a full button row of screen space for the “mobile toolbar”. We realized this makes the toolbar take up more space from the map instead of saving it in most cases. In addition, the toolbar was problematic for styling around on the embedding page.
For these reasons we have removed the concept of “mobile toolbar”. Instead, the buttons/controls on map can now adapt to smaller screen size. The zoombar, for example, removes the “bar” and only keeps the buttons etc.
In the future we can do even more to improve these. We could, for example, make the buttons collapse into a menu depending on the screen space that is available. This change applies to the geoportal as well as it is essentially the same kind of application as embedded maps, but with more functionalities and an added navigation bar.
Upcoming changes
With the improvements and “standardization” of the controls on the map, we have started working on improving the developer experience for the map plugins. This means streamlining the API and making it clearer what the extension points are and how the plugins interact with and are updated by the map module/bundle. This also affects how map plugins work with the publisher functionality.
As we are migrating more and more functionalities from jQuery to React, we have also implemented few of the tools (in Oskari 2.11) for publisher functionality using React.js. This has also allowed us to spend some time on figuring out improvements for the API for publisher tools. The tools in publisher now handle the plugins in the same way as they are started on embedded maps. This makes it easier to detect possible errors and has allowed us to remove duplicated code regarding the publisher functionality. For example, in the upcoming 2.11 Oskari release, the map plugins no longer need to care about the drag-n-drop functionality in the publisher. It is handled completely by the publisher, making the code on the plugins cleaner and adding a publisher tool for a plugin is now a breeze.
Note that application specific bundles have “always” had the opportunity to add more options for the user that are shown on the publisher UI and these might need some updating to make them compatible with the next release (docs link). The same applies for map plugins. The deprecated “mobile toolbar” concept used the plugin function redrawUI() and most bundles should be ok by renaming it to refresh() (this is an existing function in the plugin API) and possibly adding a _startPluginImpl() function that generates the UI if redrawUI was used before for that:
Finally, some things that actual users might recognize for the next release: the map layers panel on publisher has been rewritten. It now uses existing functionality to handle layer operations and most of the tools regarding map layers have been moved from the generic tools panel to the map layers panel. In short, it looks nicer and hopefully is more user friendly as well. You can see these changes already in https://dev.oskari.org.
Another upcoming change for end users is the ability to save map layer styling for vector layers! Previously end-users could add a style for vector layer at runtime, but the styling was lost on page reload. This also meant that the styles could not be used in embedded maps. As the default style looks… well, by definition “default”, it looks the same for all of the vector layers where the admin has not specifically generated a style for the layer. This makes it hard for users to use vector layers as they all look the same and are not easily recognizable from each other.
A smaller detail is that the SearchPlugin that can be added to embedded maps have been improved by adding functionality to it to match or even exceed the default search UI on geoportal. This makes it just plain better for users of embedded maps, but it now is a viable option to replace the current search user interface with the search field that is shown on top of the map. You can see this demonstrated in https://dev.oskari.org.
Last thing in this segment is throwing in some more love for developers and I’m pleased to say you can now use NodeJS 16 with Oskari. Using a more recent NodeJS is currently blocked by our dependency for node-sass. As we are currently using styled-components for any new styling we are slowly migrating away from SCSS files and node-sass. But for now (in Oskari 2.11) you can safely use NodeJS 16.
Going forward
Let’s start this off by saying that our current single largest development target for Q3/Q4 2023 is working towards merging the myplaces and userlayer (and possibly analysis) functionalities. This would mean that end-users could edit features that have been imported from a file to the geoportal and/or import “myplaces” from a file (as these would be the same thing). This could also mean that users can edit what the feature properties are for these layers (not just the values/currently myplaces is a fixed set of properties). Additionally, it gets rid of the concept of multiple user generated content sources that can sometimes be confusing to end-users (why can I edit this feature, but not this other one etc). This also allows us to look at performance for the user generated content. We are likely to move away from bundling the GeoServer application with the Oskari sample application and just query the database directly for these.
We also continue improving the mobile experience for the geoportal. The first task is to make the “flyout windows” in Oskari respect the screen size. This means that they wouldn’t open outside the browser viewport and should be movable by touch events. Another thing for advancing this is solving how the navigation bar should behave with limited screen space. One option is a toggle that could be used minimize the navigation bar. We have some concept images how this could work.
For developers/maintainers, Oskari pretty much needs to be compiled using Java 8 currently. While it compiles with newer Java versions, some things don’t work properly. The runtime can be a newer version, but we want to upgrade it for compiling as well. We are likely to drop support for Java 8 and are looking into having the minimum version for compiling Oskari to be either Java 11 or 17.
That’s all for now, thanks for reading!
Sami / zakarfin @ GitHub