AltoTrail Explorer can now show job listings on a map for countries, regions, sub-regions, and individual listings.
AltoTrail Explorer now has a map view for job listings.
Users can open a map from country, region, sub-region, and individual job listing views. This makes it easier to understand where jobs are located and to move between geographic exploration and listing details.
The map can use already cached listing data when available, but it can also load current listing data when the cache does not have what is needed. That means the map is no longer limited to scopes that were already prepared in the background.
The map can also be expanded into a larger overlay. This gives users more room to inspect job locations, especially on smaller screens or when there are many markers.
There is one important limitation. Many EURES listings do not provide exact workplace coordinates. In those cases, AltoTrail places the marker using the best available geographic level, often a region or sub-region centroid. This means the map should be read as a geographic overview, not as exact street-level location data.
The practical result is simple: Explorer now gives users a clearer visual overview of job availability across Europe, while staying honest about the precision of the underlying location data.
Current focus:
Make job exploration more visual while clearly communicating that many map positions are approximate.
AltoTrail Explorer can now save occupations as favorites, making it easier to return to the roles a user explores most often.
AltoTrail Explorer now has occupation favorites.
Users can save an occupation from the detail panel and later return to it from a small favorites shelf above the tree. This makes Explorer faster to use when a person often explores the same role, checks job availability across countries or regions, and returns to related listings over time.
Favorites are occupation-based, not listing-based. That means a favorite points back to the underlying occupation in the Explorer tree, even if it was saved while viewing a related role or a job listing.
Clicking a favorite now moves the tree back to that occupation, clears any active filter, expands the path, and scrolls the selected node into view. On mobile, the user stays in the tree so it is clear where the saved occupation belongs.
This keeps the feature simple and predictable. Explorer favorites are separate from Assistant saved listings, but they use a familiar visual pattern so the product feels consistent.
The practical result is simple: Explorer is now easier to use as a recurring workspace for the occupations a user cares about most.
Current focus:
Keep Explorer useful as a recurring work surface while preserving a simple occupation-level favorite model.
AltoTrail Explorer can now create CV and cover letter from a locally saved role profile, while continuing to reuse the ordinary document generation flow.
AltoTrail has now taken a small but important step in Explorer Documents.
Users can now save a reusable role profile locally in the browser and use it to create CV and cover letter from a selected job listing inside Explorer. This keeps the workflow lightweight and avoids turning Explorer into a separate document system.
The implementation continues to reuse AltoTrail’s ordinary document generation flow instead of introducing a second generation engine inside Explorer. That keeps the architecture simpler and makes the behavior more consistent across the product.
Generated documents are now also written into AltoTrail’s user-owned case storage. This is an important internal step because it creates a more stable foundation for later document reopening and reuse.
One limitation still remains. Explorer does not yet reopen those previously generated documents automatically when the user returns to the same listing. That behavior is still under investigation.
The practical result is simple: Explorer is now better at turning a saved role profile into usable application documents, while the next step is to make document reopening more stable and predictable.
Current focus:
Keep Explorer simple as a thin document launcher and verify later whether already generated documents should be reopened instead of recreated.
AltoTrail now shows a small source status signal, making it easier to see whether EURES and JobTech appear to be working normally.
AltoTrail now has a small source status feature.
The purpose is simple: when something looks wrong, users should have a clearer idea of whether the issue is likely inside AltoTrail or connected to an external job source.
The first version monitors EURES and JobTech. The start page shows a compact status signal, and a separate source status page gives a little more detail about the latest observed source health.
This is not a full uptime system and it does not change how AltoTrail searches for jobs. It is only a small transparency layer that reports what AltoTrail can currently observe.
The status is now refreshed automatically in production. That means the public signal should stay more current without manual updates.
The practical result is simple: AltoTrail is a little easier to trust and easier to understand when external job sources have temporary problems.
Current focus:
Keep the status simple and truthful while avoiding unnecessary incident-management complexity.
AltoTrail Explorer can now find and open more job titles through related roles, making occupation search feel broader and more natural.
AltoTrail has now improved how occupation search works inside Explorer.
Explorer can now expose more related job titles in the tree and make them searchable in a more useful way. This means users can often find the right path even when they start from a different but familiar job title.
In practice, this makes Explorer feel much broader. The underlying occupation structure has not been replaced, but AltoTrail now provides many more natural entry points into it.
That matters because people do not always search with the same formal job title. A user may look for one wording and still expect to reach the same real job market underneath.
The practical result is simple: Explorer now feels richer, easier to search, and better at connecting related job titles to real job availability.
Current focus:
Keep improving Explorer as a practical discovery tool by exposing more useful entry points into the same job availability.
AltoTrail favorites are now more stable in practice, and saved favorites can currently recreate CV and cover letter more than once when needed.
AltoTrail has now improved how favorites behave after they have been saved.
The most important result is stability. Favorites are now less dependent on the exact state of the original run, which makes saved listings feel more reliable when you return to them later.
There is also a temporary but useful behavior difference compared with ordinary listings. For regular search results, document generation is still tied to the normal one-run flow. For favorites, AltoTrail currently allows CV and cover letter to be recreated when needed.
This is intentional for now. A saved favorite is meant to behave more like a stable saved listing than a one-time result inside a single run.
The current direction is still conservative. AltoTrail is not turning favorites into a separate permanent document archive. Instead, the product now uses favorites as a more reliable starting point for creating documents again when needed.
The practical result is simple: favorites now feel more dependable, and saved jobs are easier to return to and use again.
Current focus:
Keep favorites reliable as a saved-listing feature while continuing to separate favorites from the ordinary one-run document flow.
AltoTrail Explorer can now show ESCO tree labels in both English and Swedish, and filtering follows the active tree language.
AltoTrail has now taken the first real step toward a multilingual Explorer tree.
Explorer previously showed the occupation tree in English only. That meant Swedish users could still use the page, but the tree itself did not yet follow the selected language in a meaningful way.
Explorer can now load the tree in English or Swedish, and filtering now follows the active tree language as well. In practice, this means a Swedish user can explore Swedish ESCO labels and search with Swedish words in the tree.
This is an important improvement because occupation exploration should feel natural in the user’s own language, not only in the surrounding interface.
At the same time, this is intentionally only a first step. The current baseline focuses on ESCO-native language data for English and Swedish. Some AltoTrail-owned helper nodes in the lower part of the tree still remain in English for now, and broader multilingual support will need to be added carefully in later steps.
The main result is simple: Explorer is no longer English-only at the tree level, and the product now has a clear baseline for multilingual occupation exploration.
Current focus:
Use this as the first step toward a broader multilingual Explorer model without mixing ESCO data with AltoTrail’s normal UI translation layer.
AltoTrail now saves favorites in a more durable way, so they are no longer tied only to the current session.
AltoTrail has now improved how saved favorites are stored.
Previously, favorites were tied to the current session. That meant they could disappear when an older session was cleaned up. Favorites are now moving to a user-based storage model instead, so they can survive across sessions for the same user.
This is a small change in the interface, but an important improvement in behavior. A favorite is usually a signal that something should be kept, not just hidden for the moment.
At the same time, hidden listings still remain session-based. That is intentional. Hiding something often means “do not show this right now,” while a favorite means “keep this for later.”
This makes the behavior easier to understand and gives AltoTrail a calmer and more reliable saved-list model without adding account complexity yet.
Current focus:
Verify the new behavior outside DEV and keep the model simple while hidden listings remain session-based.
FAQ and Project Updates now keep users on the same page when switching between English and Swedish.
AltoTrail has now improved language switching for the public document pages.
FAQ and Project Updates now have their own English and Swedish routes. This means the language switcher keeps users on the same kind of page instead of sending them back to the start page.
If no language is selected, AltoTrail now starts from the user’s own language settings. That makes the document pages feel more natural from the start.
This is a small change, but an important one. Language switching should feel predictable and calm.
There is one clear exception for now. The legal pages remain English-only. Because of that, the normal language switcher is hidden there instead of pretending that a Swedish legal page already exists.
That keeps the behavior honest and easier to understand.
Current focus:
Keep the document routes simple and consistent, and review later whether legal pages should also get their own language routes.
AltoTrail Explorer now shows a simpler tree and gives clearer feedback while loading job availability.
Recent work has focused on making the Explorer tree easier to read.
Some labels in the tree previously showed counts that represented structure, such as how many countries, regions, or nearby labels were available. Explorer now puts more emphasis on the numbers that matter most to a job seeker: actual job availability.
Explorer also now gives clearer visual feedback when new parts of the tree are loading. This makes it easier to understand that the system is working, especially when live availability takes a moment to appear.
This is a small improvement, but an important one. Explorer should feel calm and understandable, not technical or ambiguous.
Current focus:
Keep improving Explorer step by step so job availability is easier to understand without making the interface more technical.
AltoTrail has made the multilingual route structure clearer across the main public pages.
Recent work has focused on making the public route setup more consistent across the root page, Assistant, and Explorer.
The main idea is unchanged. Language-specific routes are still the primary public pages, while the original non-prefixed routes remain in place as more neutral entry points.
This matters because AltoTrail is gradually becoming a clearer public product. The route structure is now easier to understand and more consistent across the main page families.
This was not a new feature in the usual sense. It was a cleanup and clarification step that makes the existing multilingual setup feel more intentional.
Current focus:
Follow how the updated routes behave in Search Console and keep using the same structure for future public pages.
AltoTrail added a first working compare workspace in AltoTrail Explorer, making it possible to inspect URI-based and term-based EURES results side by side.
Recent AltoTrail work has turned earlier EURES verification into a working implementation inside Explorer.
The new slice adds a server-side compare path and a first report-style workspace in the right panel. This makes it possible to inspect URI-based occupation retrieval and term-based title retrieval in a more direct and visual way.
This matters because the two search modes do not behave the same. They can produce different totals, different country distributions, and different region patterns. Instead of treating those differences as abstract theory, AltoTrail can now study them in a working tool.
The first version is intentionally technical. It focuses on summary, compare, and raw report views so the retrieval model can be understood before more user-facing views such as maps, listing presentations, or broader search workflows are built.
Current focus:
Use the new compare workspace to study how concept-based and title-based search differ before deciding how future explorer behavior should work.
AltoTrail is preparing a new public updates page built from English markdown, with translated cached versions for other languages.
AltoTrail is moving toward a more transparent public product. The goal is to make it easier to follow what is being built without asking visitors to read internal architecture documents.
This work is not about creating a blog or a news system. It is about adding a calm and readable timeline that explains important development steps in plain language.
The first version is intentionally simple: one long scrollable page with the newest updates first.
Current focus:
Define the content format, parsing model, translation flow, and cache structure.
Recent verification work has focused on how EURES behaves in practice and what that means for reliable role retrieval.
Recent AltoTrail work has focused on verifying how EURES behaves at the API level and where the real behavior differs from earlier expectations.
This matters because AltoTrail depends on external job sources, and a trustworthy product needs to reflect how those sources actually behave. Verified observations are more useful than assumptions when the goal is stable job search behavior.
The result is a more careful and reality-based approach to query design and provider handling.
Current focus:
Keep retrieval behavior explicit, inspectable, and grounded in verified observations rather than assumptions.
AltoTrail Explorer has moved from local prototype status toward a visible AltoTrail tool with published routes and shared navigation support.
AltoTrail Explorer is no longer only an internal prototype. It now has a clearer place in AltoTrail’s public product.
This step matters because occupation exploration is becoming a visible part of the product rather than a separate experiment. It also helps AltoTrail grow from a single assistant into a broader set of tools.
The work has been kept deliberately conservative. Publication and navigation improvements were separated from deeper runtime and domain-data questions.
Current focus:
Continue improving the current technical navigator surface without mixing publication work with deeper runtime changes.
Explorer now has a first live country-count slice and a clearer split between exploration and results behavior.
Explorer can now show live country-count discovery for occupation nodes. This creates a more concrete link between occupation exploration and real job availability.
The main purpose of this step was clarity. AltoTrail now keeps a more explicit split between inspecting an occupation and opening a results-focused workspace.
That makes Explorer easier to understand and prepares it for future growth without expanding the core runtime contract too early.
Current focus:
Extend country-group behavior under alternative occupation labels.
The Explorer frontend has been split into clearer modules and prepared for future publication-aware and multilingual work.
As Explorer grew, it became important to separate responsibilities in the frontend instead of letting a few files become too large.
This step was mainly about maintainability. A cleaner structure makes later work safer, easier to test, and easier to understand.
At the same time, AltoTrail also prepared the ground for future UI translation work in Explorer without mixing that with ESCO domain-data translation.
Current focus:
Keep the frontend structure small and understandable while new features are added.
AltoTrail introduced a stronger multilingual publication model for root and assistant pages, with language-specific HTML served directly by the web server.
This was an important product and SEO step. Instead of relying only on client-side updates, AltoTrail now serves language-aware publication HTML directly for published routes.
That improves clarity for users, gives search engines a better public result, and reduces the gap between visible content and route identity.
The key idea was to keep published content deterministic and repo-controlled, while leaving runtime UI translation as a secondary layer rather than the source of truth for public pages.
Current focus:
Extend the same clean publication model to more public-facing content surfaces.
AltoTrail introduced a multilingual FAQ page with English canonical content, server-side rendering, and cached translated versions.
The FAQ page was created to answer common product questions without making the Assistant interface heavier or more crowded.
This also became an important architectural milestone. AltoTrail now has a validated pattern for content translation: English source content, model-routed translation, structured cache storage, and safe fallback to English.
That pattern is now useful beyond FAQ and is directly relevant to the new Project Updates page.
Current focus:
Reuse the same translation and cache principles for other structured public content.
AltoTrail established its first staging-capable VPS deployment model with Git-based updates and documented service structure.
This step moved AltoTrail further away from a local lab-only setup and closer to a real deployed product.
The main purpose was not feature growth, but operational clarity. A product becomes easier to trust when deployment, restart behavior, and service layout are explicit and repeatable.
That infrastructure work created a stronger foundation for testing public-facing changes in a realistic environment.
Current focus:
Keep deployment reproducible and close to production behavior.
AltoTrail introduced a more stable canonical architecture for listings and geographic data.
This was one of the more important structural steps in AltoTrail. The purpose was to reduce duplication, improve identity stability, and create a cleaner foundation for listings, location data, and later map-related behavior.
Even though this work is deeply architectural, the reason behind it is simple: users should not lose coherence just because data is processed through repeated runs.
The long-term effect is a more stable product foundation with less hidden duplication and clearer responsibility boundaries.
Current focus:
Preserve stable identity and reusable data without changing the user-facing workflow more than necessary.
AltoTrail introduced baseline runtime guardrails to make the product safer and more stable without changing pipeline semantics.
As AltoTrail moved closer to a public-facing product, it became necessary to add lightweight runtime guardrails around requests, concurrency, and generation behavior.
This step was about practical safety rather than feature work. The goal was to reduce avoidable misuse, control cost exposure, and make system behavior more predictable.
The important design choice was to do this without changing the meaning of the pipeline itself.
Current focus:
Keep the product operationally safe while preserving deterministic behavior.
The project transitioned from an internal lab-style surface into a clearer public product identity under the AltoTrail name.
This was a presentation-layer shift, but an important one. A product needs a clear identity before it can feel trustworthy and intentional.
The purpose of this step was to move away from internal or experimental language and toward a clearer public product.
That change helped connect architecture work, UI refinement, and product direction into a more coherent whole.
Current focus:
Continue turning technical progress into a more coherent and understandable product.