There is a point in the growth of a puzzle app where adding more games stops being the most urgent task. The catalogue can still expand, but the main product questions move elsewhere. What happens between one game and the next? What happens if you close the page halfway through a puzzle? How much of a phone screen does the application itself consume while you are trying to play? How should somebody learn an unfamiliar mechanic? And if Blupoli is installed as a PWA, should moving from the main site into Puzzles suddenly feel like leaving the app?
Over the last several iterations, Blupoli Puzzles has been working directly on those questions. Some of the changes are immediately visible, such as the new compact navigation or the disappearance of global chrome while a game is active on mobile. Others are deliberately quiet: restoring a board exactly where it was left, keeping a completed board visible without counting the result twice, or making sure a tutorial cannot accidentally affect real progress. Together, they create a larger change than any one feature on its own. Puzzles is beginning to behave like a continuous application rather than a set of pages that happen to share a visual system.
This update brings together work shipped across 24 and 25 September 2026, including the second mobile product-hierarchy pass that now prioritizes Continue, Today, Favorites, recommendations and discovery. A deeper Statistics and Records redesign remains a separate work stream; this article stays with changes that have already landed in the current product.
Mobile is no longer just desktop squeezed smaller
The most obvious difference appears as soon as Blupoli Puzzles is opened on a compact screen. The previous experience carried too many desktop assumptions into a phone layout: a global header occupied the top edge, navigation competed with content, and game screens had to fit around elements that were not useful while a puzzle was actually being solved.
The new structure begins with a different premise: vertical space on mobile is part of the product. It is not enough for every component to technically fit. Every permanent strip reduces the board, forces controls to shrink or creates scrolling that interrupts the mechanic. Compact Puzzles therefore removes the global top bar and reserves the bottom edge for five stable destinations: Home, Today, Explore, Progress and More.
More is not a random overflow drawer. It keeps important destinations available—Achievements, Streaks, Blupoli ecosystem links, theme and language—without requiring all of them to occupy permanent navigation space. The goal is not to hide features. It is to distinguish the destinations used constantly from the tools that should remain easy to reach without taking part of every play session hostage.
Once a game starts, the application gets out of the way
The difference becomes stronger when a puzzle opens. On compact screens the global bottom navigation disappears too. The game receives a small local header containing Back, game identity and contextual actions such as Help or Favorite. The rest of the viewport belongs to the board and the controls that matter for that specific attempt.
This fixes a conflict that had appeared across many engines. A board could end up sharing the same viewport with global navigation, a large discovery title, permanent help, indicators and action bars. Every element had a reasonable explanation in isolation; together they turned a phone into a stack of UI strips before the player even reached the puzzle. The new hierarchy prioritizes the activity the player has already chosen.
That does not mean every puzzle is forced to fit into one screen without scrolling. Some mechanics and board sizes are naturally taller than the available space. In those cases, the game content can scroll inside the application shell. The more useful rule is not to crop the board or invent an artificial height just so a screenshot looks tidy. Peripheral controls are compacted first, then the puzzle keeps the size it needs to remain playable.
Secondary actions stop competing with primary ones
A small screen also forces a decision about which actions deserve to remain visible. In some games, the action bar had grown until horizontal scrolling became part of the interface. It technically worked, but an important control could sit out of sight and a sideways gesture could move the toolbar instead of interacting with the board.
The shared convention now keeps high-priority actions visible and groups secondary ones under More when space is tight. The action DOM remains stable for accessibility, logic and tests; only the presentation adapts. Responsive behavior therefore does not need a duplicated game toolbar or a second mobile-only implementation.
Key touch targets have also been normalized to a practical 44-pixel minimum across shared controls such as navigation and streak-calendar interactions. This is not dramatic in a screenshot, but it is easy to feel with a thumb. It reduces missed taps and prevents dense layouts from demanding mouse-level precision.
Leaving a game should not mean losing it
The other major improvement does not take up any screen space, yet it changes the relationship with the product. Blupoli Puzzles now has a shared resumable-snapshot contract. Published engines save and restore game state through one platform capability instead of each inventing a private storage key and a private definition of what “save” means.
For a player, the effect is simple: leave a game halfway through and return later without expecting the board to restart. For the platform, the requirement is deeper. Saving a game is not just serializing a matrix of cells. The system must preserve the right configuration, the attempt that owns the board, elapsed time, difficulty, seed or variant where generation is deterministic, and the exact state the player has changed.
The shared host owns session identity and time. Engines receive a deliberately small capability to load, save and clear their own scoped state. That keeps individual puzzles away from browser-storage details and prevents them from creating a second authoritative timer or session lifecycle.
Saving less can be more reliable
Deterministic games do not need to duplicate information that can be reconstructed. If a board comes from a stable seed and configuration, its snapshot can keep those identifiers plus the player's changing state rather than serializing every generated structure. Snapshots stay smaller, and there is less risk that two representations of the same puzzle drift apart.
Other engines genuinely need richer geometry. The common contract does not force every game to persist the same payload. It requires that the payload lives inside a versioned envelope and that storage access goes through the platform. That distinction matters. Standardization should not erase the needs of a mechanic; it should define the part that must be common before the system can make dependable guarantees.
As this coverage was expanded, engines that still lacked shared loading and saving paths were migrated. The current platform rule is that a published game should not lose continuity simply because its historical implementation predates the common state system.
A completed game also needs to restore correctly
Persistence revealed a less obvious edge case: what should happen to a game that has already been completed? Clearing the snapshot immediately sounds reasonable because there is nothing left to resume. But it also makes the solved board disappear as soon as the player navigates away or reloads. Keeping it without distinguishing its state creates a worse problem: restoring it could reopen an active statistical session or record the same completion again.
The solution is to retain completed snapshots with an explicit completed flag. Returning to one restores the board read-only and does not restart a statistical session. Play again is the action that creates a genuinely new attempt and clears the old completed context. A player can inspect the solved board without a simple revisit becoming a second win.
This work also fixed concrete regressions in the Fifteen Puzzle and exposed a naming collision that could cause the first move to trigger solved behavior. Cases like that are why cross-platform features need validation against real engines. Shared contracts are useful when they uncover meaningful differences, not when they merely paper over them.
The timer becomes a platform responsibility
Game continuity would still be inconsistent if every engine measured time on its own. The visible timer and the duration stored in results now share the same temporal source in the host. A session starts with the first meaningful interaction, resumes with its snapshot and freezes when the game ends.
That decision also makes duplicated local timers unnecessary. A player should not see two clocks for one attempt, and the code should not have to decide later which one was the real one. The platform owns lifecycle; the engine reports moves, meaningful actions and completion.
This is the kind of change that simplifies both UI and implementation. The more the shared shell and host can do consistently, the fewer exceptions each puzzle has to maintain and the easier it becomes for future fixes to reach the whole catalogue.
Learning now happens inside the real game
The third major piece of this stage is onboarding. A tutorial can explain a mechanic using a simulated board, but simulations age independently. An interaction shown in the tutorial can drift away from the real game, an animation can behave differently, or a control can end up following a separate rule.
The redesigned onboarding uses real engines. Practice runs in an isolated instance of the game, separate from a normal session. The player therefore learns through a genuine interaction governed by the same rules they will encounter in a real puzzle, while the practice session is prevented from writing progress, achievements, streaks or ordinary statistics.
Compatible mechanics are grouped into reusable families so we do not build an entirely separate teaching system for every game that shares the same basic interaction. At the same time, every published game must have an explicit mapping. That combination is intentional: reuse where a relationship truly exists, plus verifiable coverage so a future release cannot quietly appear without onboarding.
Close, skip and complete no longer mean the same thing
The semantics of learning have been tightened too. Closing a guide can preserve the ability to return; skipping expresses a different intent; completing the practice means the player actually worked through the proposed interaction. These differences sound minor until onboarding becomes a platform feature that must support many mechanics rather than a one-off modal.
When an engine supports the shared snapshot system, the exact state of the practice attempt can be retained as well. Because tutorial state is isolated through session-scoped storage, it does not suddenly reappear as a pending real game later.
The result is less theatrical and more useful. The goal is not to front-load every rule before play begins. It is to lower the first barrier: teach the interaction that produces a meaningful response, then let the player carry that knowledge straight into the real game.
Puzzles now has its own stable PWA identity
The domain architecture created an important product decision. Blupoli lives at blupoli.com, while the puzzle product lives at puzzles.blupoli.com. We first explored keeping Puzzles inside the main Blupoli PWA through cross-origin association. That could recover vertical space in compatible flows, but the installed identity still depended on an app whose primary origin was somewhere else.
The final decision is simpler to explain and more robust as a product: Blupoli Puzzles now has its own stable PWA identity. It can be installed directly from https://puzzles.blupoli.com, appears as “Blupoli Puzzles” with the launcher short name “Puzzles,” and defines its own explicit id, root start_url, root scope and standalone display mode.
When launched from that installation, normal Puzzles navigation remains inside its own origin and scope. The technical separation between the main site and the product therefore no longer needs to surface as an external-site bar above the app. It is also a cleaner fit for future Android packaging: Puzzles can have a clear installable identity without pretending the whole Blupoli ecosystem is one application.
One application, six languages, one runtime
While reorganizing the shell, onboarding and shared surfaces, runtime localization was centralized too. Home, catalogue, progress, achievements, streaks, completion feedback, onboarding and the game host now consume canonical locale resources instead of carrying parallel translation helpers or replacing strings in the DOM after rendering.
This matters more as shared features expand. A new shell button should not require hunting through six independent implementations, nor should its language depend on which transformation script happened to run first. Translation belongs in the state of the interface from the beginning.
For the player, the best outcome is almost invisible. Changing language should update the product coherently rather than reveal which screen belongs to an older generation of the code and which one uses the newer architecture.
Game bars are becoming components rather than decoration
The same work has also consolidated common indicators and actions around boards. Some engines had their own HUD for difficulty, size, moves, best score or elapsed time while the platform displayed overlapping information elsewhere. Akari made the cost particularly obvious: two structures were trying to describe one attempt.
Reusable indicator controls now handle the information that truly belongs to the platform. Engines remain free to represent data that is specific to their rules. A puzzle no longer needs to reinvent responsive behavior, focus states, theme handling and typography simply to display a common metric.
The physical hierarchy is clearer as well: shared indicators sit above the board and the shared action dock sits below it. Avoiding overlays is not merely aesthetic. It reduces the chance that a control covers an interactive cell or region when space becomes tight.
Visual coherence no longer depends on handwritten colors
In parallel, the game color system has moved toward semantic tokens. A category can contribute identity, light and dark themes can adjust contrast, and components consume variables that describe function rather than assuming one fixed hexadecimal value.
This made it possible to remove local palettes and fallbacks from games that had grown with their own visual assumptions. When a board uses a surface, selection or control color, that color should express an intention the system can adapt. If each engine defines “dark background” independently, light mode inevitably turns into an expanding list of exceptions.
The player-facing benefit is consistency without erasing personality. Numberlink, Sudoku and Ataxx do not have to look the same. What they share is a compatible way of handling contrast, interaction states and category identity.
Continue now comes first in the Home hierarchy
The snapshot system stopped being only an engineering capability once Home could depend on it. The current mobile hierarchy prioritizes Continue → Today → Favorites → Recommendations → Discover. The sequence answers a simple product question: before offering something new, the app should remember whether the player was already doing something.
The catalogue now separates playable results more clearly from games that are upcoming or still in development. Playable content keeps the main discovery space, while future items are collapsed into a secondary section. A large catalogue should not let possible future games compete visually with things people can actually play now.
Progress and Streaks also use compact progressive disclosure: primary KPIs and visualizations remain visible while secondary detail can expand when needed. Game loading has gained a shared skeleton and a canonical loading, ready, completed and error state contract. Those details are related. They reduce layout jumps and give the platform a predictable state while an engine is entering the screen.
Continue is therefore no longer a decorative card trying to infer whether a saved game exists. It is backed by real platform state, which lets Home put continuity ahead of discovery without engine-specific checks.
A local-first app can feel continuous without demanding an account
Blupoli Puzzles remains local-first. None of these improvements requires signing in. Snapshots live in the browser just like current progress. The architecture is being prepared for future remote synchronization, but Firebase is not presented as an account-sync feature that already exists, because it does not.
That lets the product deliver value sooner. Resuming a game on the same device should not wait for authentication. Learning a mechanic does not require a backend. Neither does an immersive mobile shell. Each layer can improve now while avoiding decisions that would make later synchronization harder.
Local-first should not feel synonymous with temporary. It should mean the game works immediately, even without a network, and a future account expands that experience rather than unlocking the basics.
The platform/engine boundary is becoming more visible to us and less visible to players
Behind these changes is one repeated idea: the engine should know how to play; the platform should know how to present, remember and connect. Sudoku understands candidates, mistakes and solution rules. Numberlink understands paths. The shell understands navigation and space. The host understands lifecycle and snapshots. Onboarding understands isolated practice. Progress and achievements understand results.
When those responsibilities blur, every new puzzle has to recreate features that have nothing to do with its rules. When they stay separated, persistence, controls or localization can improve for many games without turning engines into giant dependency hubs.
Players should never need to care about the architecture. The sign that it works is the opposite: going back, switching games, resuming, opening help or rotating the device feels predictable even though the underlying engines can have very different structures.
Touch-target size is a small measurement with a large effect
The mobile audit has been a reminder that professionalizing an app rarely depends only on major redesigns. A 32-pixel icon can be visually elegant and still be a poor touch target. A toolbar can be perfectly aligned and still require horizontal scrolling to discover an action. A header can look compact while consuming the exact vertical strip a square board needs.
That is why this stage combines structural work with very concrete adjustments. Forty-four-pixel touch targets, deterministic SVG-based navigation icons and safe-area handling are the kind of details that prevent the product from behaving differently depending on font, browser or device.
They also prepare the same UI for native packaging through Capacitor. We do not want to build a web interface that is comfortable only with a pointer and discover later, once wrapped for Android, that it needs a second interaction model. Touch quality has to exist before packaging.
Compact navigation reduces decisions, not capabilities
Five persistent destinations can look like a reduction, but the real goal is hierarchy. Home and Today answer “what should I do now?” Explore answers “what can I play?” Progress answers “how am I doing?” More keeps tools and destinations available without making them compete in every moment.
On wider layouts, the left rail can expose more destinations directly because there is enough width. The semantics remain the same. We are not maintaining two applications, one for mobile and one for desktop. One navigation model adapts its presentation to available space.
This avoids a common failure mode in complex responsive products: the mobile layout becoming a separate functional branch. The more two structures diverge, the easier it is for a feature to arrive on desktop and be forgotten on mobile, or for an accessibility fix to reach only one version.
The shared experience is not trying to hide the fact that puzzles are different
A platform system can overreach and turn every game into the same template. That is not the intention here. Mechanics still determine the board. A placement puzzle, a path puzzle and a competitive game do not need identical density or identical game-specific actions.
Standardization happens around what genuinely repeats: back navigation, help, favorites, timing, saving, restoring, result recording, localization, theme and touch behavior. The better that perimeter becomes, the more freedom the center has to remain mechanically distinct.
That relationship matters. A puzzle's personality should come from its rules and representation, not from putting New Game somewhere unpredictable or ignoring light mode.
What returning players can notice today
Somebody coming back to Blupoli Puzzles now may encounter several changes at once. Mobile play has more usable space and less permanent chrome. Primary actions are easier to tap. An interrupted game is much more likely to continue exactly where it was left. A completed board can remain visible without recording statistics again. Onboarding practice uses the real mechanic. An installed PWA preserves the standalone feeling more effectively when entering the Puzzles subdomain.
The important part is that these are cross-cutting improvements. This is not a feature limited to one puzzle. The work has been deliberately pushed into shared contracts so published games inherit the same platform expectations. A host or shell fix can therefore improve many experiences at once.
Some surfaces will continue to evolve. Home has now received its second mobile hierarchy pass, while the deeper Statistics redesign and the separation of Records remain distinct work. We do not want to present those open lines as finished. The continuity described here is the foundation they can build on without reopening persistence, navigation or loading-state questions.
The most important improvement is that the product remembers context
An application does not feel coherent only because it has a design system. It feels coherent because it remembers what you were doing and adapts its interface to the current context. Browsing needs one hierarchy; playing needs another; learning a mechanic needs isolation; completing a puzzle needs to preserve the result without duplicating it.
This set of changes moves Blupoli Puzzles closer to that model. The shell knows when to get out of the way. The host knows which session belongs to a board. The snapshot knows what to restore. Onboarding knows that practice is not a normal game. The installed PWA knows that Puzzles belongs to the same product experience.
Different layers are solving one shared problem: continuity. That matters especially in a logic catalogue, where one session may last two minutes or stay open much longer while a deduction is still being worked through.
The next phase can focus more on hierarchy and less on repairing foundations
The value of closing these foundations is not limited to what changed today. Home can already prioritize Continue over discovery because shared state exists to feed it. If Statistics needs to distinguish an active session from a completed one, the lifecycle already does. And if Android uses Capacitor, the compact UI and the independent Puzzles PWA have already been treated as real touch and installable surfaces.
This does not mean the platform is finished. Important work remains around statistics, records, product hierarchy and the depth of individual engines. But the nature of that work can start to shift. More effort can go into how each surface is understood and enjoyed because shared infrastructure absorbs responsibilities that used to be scattered across many implementations.
That is the point of this update. We do not want Blupoli Puzzles to look like an app simply because the browser is hidden. We want it to behave like an application because it preserves state, respects context, reduces friction and lets people move through its parts without losing the thread.
Explore the new foundation
You can open Blupoli Puzzles and try the current experience directly on mobile or desktop. If you want the background to the earlier responsive work, From the announced catalogue to a usable platform explains the starting point. For the data semantics behind real game sessions, the Devlog entry Progress starts when you actually play explains why loading a board should not count as playing it.
For the engineering story behind this stage—how storage moved out of individual engines into ports, versioned events, common snapshots and a future sync boundary—we are publishing a companion Devlog: From scattered browser storage to a local-first architecture ready for sync.
The two articles look at the same shift from opposite sides. For players, the platform should fade behind a more natural experience. For the people building it, that natural behavior only becomes dependable when responsibilities stop living in exceptions and become contracts every game can share.