Portaler

The challenge was to turn an extensive specification into an application for working with a shared map. The client defined the features and product rules, explaining some ideas through sketches in FigJam and Paint.

I developed the page structure, layouts and visual design from scratch, discussing decisions with the client. The brief covered both desktop and mobile.

Portaler is a tool for communities in the online game Albion Online. It helps map the Roads of Avalon: locations connected by portals. Guilds and alliances record discovered portals, chests, resources and dungeons, then use the shared map for pathfinding.

I worked on the application at NIITSURU. We had collaborated with this client before: I had previously designed their landing page.

On-screen data and names are illustrative.

A server brings together several maps and community settings. I organised them into one workspace: map status can be checked before opening the network of locations, while access management and Discord integration belong to the server as a whole.

This was my first time designing this kind of map. Nodes represent locations, and lines represent discovered portals. The network, location information and editing tools had to share one canvas.

Viewing, editing and pathfinding were part of the original product model. In edit mode, I placed actions beside the nodes and grouped shared tools (connection creation, undo and layout options) in a bottom toolbar. This separates actions on an individual location from work on the whole network.

The client specified the palette and connection outlines. These were constraints I worked within when designing the map.

Pathfinding needs a clear distinction between the selected route and the other connections. The route is highlighted while the rest of the network is dimmed. Start and end locations remain visible while working with the map, and recently visited locations are available in search.

Permissions apply at two levels: the server and individual maps. A role can have defaults and an override for a specific map. These levels need to be distinguishable when editing access.

I separated server and map settings into two sections. The role selection determines whose permissions are being edited; the map selection determines where the override applies.

A person can have an individual plan and private-map subscriptions with different payment states. I separated these subscription types and displayed the status on each card. A delayed payment for one map is shown separately from the state of the other subscriptions.

The map was the hardest part to adapt. On a phone, controls and the network of locations compete for a small working area. In the current design, the main controls sit above the map, with the start and end locations below it.

This arrangement leaves less room for the map. If I returned to the project, this is the flow I would revisit first.

Most revisions were discussed directly in Figma comments. We used Telegram and a few calls for other questions.

In around a month and a half, I completed the application design for desktop and mobile. The work covered the shared map and pathfinding, server workspaces, access management and subscriptions.

The design is complete. Implementation is on the client’s side.