Skip to content

SkiMobile · active brand and network standards guide.

Digital products

Interface templates

Web style based on the homepage: composition, illustration, background, motion and page templates.

Open the homepage — the web style reference

Purpose

Every screen starts with a guest task and ends with a clear action. Use the shared header, footer, settings and components. Local demonstration data does not change real rental terms.

The homepage is the web style reference

On 22 October 2026 the owner approved the visual direction of the SkiMobile homepage. It is the reference for new and updated pages: a distinctive mountain setting, prominent equipment and illustrations, clear typography, compact controls and an obvious next action.

Carry over the visual language and execution quality. Compose each page around its task: the homepage introduces and engages, the catalogue supports comparison, a form collects details and the account helps find a booking. Every screen does not need the same large banner or set of cards.

Composition and rhythm

Main sections use the full shared container width, responsive gutters and safe areas. Do not add centred 1200–1440 px wrappers. An individual paragraph may use a reading measure around 68ch; card grids fill the available width and gain columns on wide screens.

Alternate expressive scenes, quieter text, lists and cards according to their purpose. Keep related elements close and give distinct tasks more space. Illustrations must be large enough to inspect; an empty panel with a tiny picture is not a composition.

Typography and density

Use Manrope in both locales for headings, prose, prices and controls. Take sizes and roles from the shared scale. A short heading communicates one idea and supporting text develops it. Prices include their rate unit and aligned tabular numerals. Labels and terms remain readable when a section is made denser.

Achieve compactness through grids, grouping and spacing while keeping targets at least 44 px high. Do not shrink text to force a page into one height. Long translations and 200% text enlargement must wrap and reflow columns without clipping words, amounts or actions.

Background, colour and depth

Use the brand navy, sky accent and semantic surfaces of the chosen theme. Cool light gradients, snow contours and photographic surroundings connect a section to the mountains. Effects support its subject and guide attention to the content without competing with text or controls.

Light and dark themes are equally supported. Text, inputs, borders, focus and states use shared tokens. Build depth through tone, imagery and an appropriate soft shadow rather than adding glow, glass and multiple outlines to every card. Red retains its brand role in the logo and its error meaning in the interface.

Photography, illustration and branding

Show equipment prominently and in detail. Product previews and galleries use one portrait format: width to height 3:4, without letterboxing. Choose mountain photographs and architectural illustrations for each section composition; the product crop does not apply to every site image.

Location photographs and reviews need a verifiable source. Label interior concepts and service illustrations as illustrations; fictional scenes and people do not verify a real branch, employee or review. Retain the source, version and provenance of every prepared image.

Use the approved brandbook logo files. Within a scene it can become signage or equipment branding: preserve its artwork, colours and proportions while matching the surface perspective and lighting. Invented lettering and stretched stickers do not replace the brand mark. Check transparent illustrations in both themes.

Actions and states

Each section has one primary action that matches its task. Booking, service discovery or franchise terms should be immediately apparent; secondary links are quieter. Button labels explain the next step. Keep material terms and the price basis near the action.

Give empty, loading, error, unavailable, selected and success states the same attention as the main screen. Retain visible focus and accessible names, explain limitations and offer a way forward. Preserve the selected branch and guest-entered details across navigation.

Purposeful motion

Motion reinforces selection, transitions, image changes or the mountain setting. Use shared durations and smooth deceleration. Text and primary actions remain available in a static state; animation sequences must not delay using a form.

Background effects and autoplay run while their section and document are visible. Respect both system and site reduced-motion preferences. Homepage reviews use approved shuffled rotation without a player or count: reduced motion keeps content changes but removes transition animation. This is specific to that block, not a rule for every carousel.

Phones and short viewports

On phones, put the proposition and action before illustration and detail. Columns become one reading flow; a horizontal slider may remain within its section. The document must not need horizontal scrolling. Fixed headers, navigation and action bars account for safe areas without covering inputs, errors or focus.

For HD, check the actual viewport height with the header and bottom bars. An oversized gallery or introduction must not bury the primary action. Long text and expanded forms continue through normal scrolling; a one-screen requirement applies only when separately approved for that scenario.

Web page acceptance

  1. Compare with the homepage reference: clear hierarchy, subject-led imagery, a considered background, appropriate density and an obvious action. Review neighbouring sections as well as the isolated block.
  2. Check RU/EN, both themes, 320 and 390 px, tablet, wide desktop and short HD. Also check 200% text, keyboard access, focus, contrast, reduced motion and all control states. Record desktop/mobile captures for a new page.
  3. Reuse tokens and FSD public exports: data and pure rules in entities, flows in features, composition in widgets and pages, and source wiring in _app. Check TypeScript, ESLint/FSD, formatting, a production build and affected browser scenarios.

Screen rules

Home: promise, services, handover and contact. Catalogue: categories, filters, availability and price. Detail: image, specifications, size, terms and action. Branch selection: name, address, hours and handover method.

Order: items → period → handover → total cost → contact. Service: outcome, provider, terms and appointment. Account: history, details and next step. Notification: what happened and what to do. Check scenarios on mobile, in RU/EN and both themes.

Template checks

Layouts use approved components and tokens, explain the next step and document states. Data remains demonstrative without unverified commercial promises.

Ski catalogue and branch offers

A card represents one model and its lengths. The detail page places a compact portrait gallery on the left, variants and model information in the centre, and prices, terms and the booking action on the right. Reviews and recommendations follow below. Dates, rider profiles, the estimate and exact return time are checked in the complete-order form. Hour limits, checkout time and timezone come from branch and resort data. A price belongs to a branch offer, not the shared model.

In the first stage, ski offers exist only for Laplandia. Other branches show a clear catalogue-population state. Links preserve branch and filters; branch carts are kept separately on the device. Availability on dates is confirmed by staff. History preserves the original estimate; the server validates the offer and length against its own data.

Eight screen contracts

Eight screen contracts
ScreenRequired dataPrimary action
HomePromise, services, branches, kit terms and contact.Start fitting or choose handover.
CatalogueCategory, filters, cards and availability state.Open a suitable item; reset an empty search.
Item detailActual item, sizes, period, cost and included services.Choose an item and check fit.
BranchesName, address, entrance, hours, contact and handover method.Choose a branch; map remains an additional option.
BookingItems → period → handover → charges → total → contact.Review the total and confirm deliberately.
ServiceOutcome, provider, parameters, cost and timing.Enquire or book while retaining input.
AccountOrders, details, status, handover, return and contact.Open an order and continue its journey.
NotificationEvent, specific order, next step and contact.Open context without losing the selected locale.

States and mobile composition

Each screen has normal, loading, empty, error and offline states as needed. Orders retain entered context between steps; charges appear before confirmation and included delivery is tied to kit rental.

Mobile order is content, terms, action. Wider areas may place the summary in a second column while DOM order remains logical. Home, catalogue, booking, service and account compositions are available in Layout and grids and standalone Layout 1.0 HTML.

Goggles · frame, lens and joint fitting

Laplandia has four reference goggle models: two adult and two junior. One card groups frame fits and lenses; 16 SKUs have their own photos, specifications, manual rates and usage history. Photos use 3:4 portraits with data-driven variant captions.

Fitting screens face width, age, OTG and glasses dimensions, lighting and the S1–S3 / VLT filter. Matching dimensions do not confirm helmet compatibility: try both together and check the nose, brow, ventilation and strap. Junior fitting uses junior helmets and includes a parent or guardian.

Each variant includes one fitted lens, with no spare lens promised. Staff-fitting acknowledgement cannot bypass a known mismatch. Booking preserves the branch, offer and SKU or staff-fitting request; the server repeats validation and catalogue pricing. The typed snapshot and asynchronous repository are ready for an API. Mock and image provenance: docs/goggles.md.

Clothing · size, colour and fit

Laplandia clothing is organised into jackets, pants, snowsuits and gloves/mittens, with two models per subcategory. Each model has two colours and three sizes, totalling 48 explicitly offered SKUs. Gloves are clothing; wrist guards remain separate protective equipment. Size and colour are selected together, update the image and travel into booking in one link.

Russian shows the variant's explicit RU size alongside S/M/L; English uses international S/M/L. Handwear has its own size chart. Fitting checks height and relevant body circumferences, inseam, or hand circumference and length. Body windows are separate from finished garment measurements: size is never derived from weight or a universal formula. Layers are recorded separately; fit over protection and snowsuit torso length are checked in person.

Manufacturer facts, SkiMobile fitting rules and branch offers are separate records. Each SKU has a manually entered tariff. Fabric specifications and inventory values are currently mocks, without certification or guaranteed temperature claims. Complete orders preserve the selected SKU, measurements, layers and original quote; the server rechecks branch, variant, duration and tariff. An asynchronous repository can replace the source with an API.

144 portrait 3:4 frames derive from 16 ImageGen product illustrations. Each colour has its own master; sizes within a colour share that illustrative master with separate URIs and live annotations, without implying photographs of specific inventory units. Close-ups stay clean. Origin, exact prompts and SHA-256 are retained; reviews start at zero and can be saved locally until an API is connected.

Junior equipment · fitted to the child

Each of Laplandia's five categories adds two junior models with three explicitly offered sizes: ten new models and 30 SKUs. Existing equipment remains. Every size joins its own images, fitting criteria and manually entered branch rate.

Fitting uses the child's current height, weight, experience and measured feet, without growing room. A parent or guardian completes and confirms the profile; our team checks fit and readiness for the lesson before pickup.

Russian uses RU; English uses the actual variant's US Kids (C) or US Youth (Y) chart. Hawx Kids 2 includes US C 12, US C 13 and US Y 1. These scales are never merged into a numeric range or converted using a universal formula.

Alpine ISO 5355 C soles and BSL are checked against the installed binding. Snowboard XS/S bindings check the two-strap interface, regional chart and boot outsole length independently of measured foot length. Unknown facts require review; a review acknowledgement cannot hide incompatibility.

Snowboard boots · foot fit and bindings

Six Laplandia models contain 22 explicit size/colour combinations. RU is primary in Russian; the model's US Men, Women, Kids or Youth scale is primary in English. Selection updates the photo, facts, manual rate and link together; missing size/colour combinations are never invented.

Manufacturer facts are separate from rental fitting rules. Fitting checks age, weight, experience, foot length, width and instep. Regional shoe size remains a guide. Boot outsole length is separate from foot length and alpine BSL. A binding pair is checked by interface, size range and outsole length; rider-to-board fitting is an additional check.

Boots and a board for the same participant are checked together before checkout. Rented boots override an older own-boot preference; the server rejects foreign SKUs and incompatible bindings even with a review acknowledgement. Cart and history retain the complete order. Size charts, measurements, tariffs, example reviews and product illustrations are typed mocks with provenance. The async repository is ready for an API source. Contract: docs/snowboard-boots.md.

Snowboards · board, geometry and bindings

Four Laplandia models combine 12 offered length, width and binding combinations in four cards. Each SKU has its own 3:4 gallery, geometry and manually authored branch tariff. Selection updates the image, facts, price and URL together; impossible combinations are not offered.

Weight and experience are checked separately from length. Regional shoe size, snowboard boot outsole length and mounted binding size are independent fields. RU/US is never converted into outsole length, and alpine BSL is not reused for snowboard fitting. Step On and hard boots are incompatible with these mock strap bindings.

Fitting, filters and booking share one typed catalogue. The cart stores a complete order with participants and selected SKU; the server repeats offer, fitting and tariff checks. Current inventory values and illustrations are mocks with provenance; the API replaces the async source. Other branches have no published snowboard offers yet. Contract: docs/snowboards.md.

Boot sizes · RU and US

Russian pages use RU; English pages use US Men / Women / Youth. Each SKU records regionalSizes with provenance, ready for the API adapter. These are selection hints, never a formula for Mondo, foot length or BSL. Measurement-based fitting and staff checks still apply.

Rider profiles persist the number with shoeSizeSystem. Changing the system clears the number; older records without a system retain EU. Validation, filters, orders and notifications respect the scale. A familiar shoe number alone never establishes fit without measurements.

Laplandia · rider-fitting data

Twelve models and 36 explicit ski, boot and pole SKUs. Ski geometry and height/weight criteria belong to the chosen length. Boots independently record Mondo, shell, sole, BSL and authored foot-length/width/instep windows. A telescopic pole’s mechanical range does not replace a height-specific setting. Each SKU uses its own portrait 3:4 media.

Fitting shows actual branch variants and explains when measurements or staff review are needed. Skis are checked against the same participant’s selected rental boots or markings on their own boots; EU and Mondo are never converted into BSL. Unknown installed binding ranges require review, and known incompatibility blocks checkout. The server repeats fitting, version and tariff checks; profiles and complete orders persist locally.

Manufacturer information, geometry, SkiMobile criteria and branch tariffs remain separate typed data. Current inventory values carry mock provenance and do not establish physical inspection. A future API replaces the async adapter. Criteria versions: ski-fit-2.0, boots-1.1, poles-1.1. The full contract and methodological sources are in docs/laplandia-fitting.md.

Alpine poles · length, components and pair

Four Laplandia models demonstrate two fixed adult, one telescopic and one junior construction: eleven explicit variants. Manufacturer facts describe material, grip, strap and construction. Length/range, installed basket, colourway and imagery belong to the variant; tariff and seasons of use belong to the branch offer. The rental unit is always a pair of two poles.

Length and price filters match the same SKU. Selection updates its own annotated 3:4 frame, facts, manual tariff and URL. Tabs cover description, grouped specifications, height-based fitting with a geometric length-check diagram and reviews. Height windows are SkiMobile criteria, not a manufacturer guarantee. Length is checked in boots, grip with gloves and junior pole use with the instructor.

Only a complete order with participant profiles reaches the cart. The pair SKU, range, optional telescopic length setting and original quote are retained. The server repeats branch, size, range and tariff checks. Thirty-three frames from four ImageGen masters are product illustrations with embedded prompt metadata; inventory values and fictional reviews remain mocks. Asynchronous repositories can replace them, and example reviews never enter SEO ratings.

Alpine boots · model, size and bindings

Four Laplandia models have twelve explicit Mondo variants. Flex and construction belong to the model; size, shared shell, actual sole, BSL and imagery belong to the variant. Branch offers hold manual prices and seasons in use. BSL is not calculated from EU/Mondo, and age does not determine sole type. Foot length and width are checked against separate SkiMobile criteria; manufacturer last width is not foot width.

Tabs separate description, specifications, fit/bindings and reviews. The foot outline reflects measurements; sole and BSL are compared with the branch's ski bindings. Matching records do not replace in-person fitting and staff checks; DIN is not calculated. Only a complete guest order reaches the cart, preserving Mondo and the original BSL label. The server repeats interface and tariff validation.

Thirty-six 3:4 frames derive from four product illustrations: each variant has its own crop and two detail views. Live RU/EN annotations use data, while close-ups stay clean. Illustrations and inventory measurements are mocks with origin, prompts and SHA-256 retained. Example reviews are labelled and excluded from SEO ratings. The asynchronous repository can switch to API data without embedding inventory in components.

Product photography · portrait 3:4

Every product photograph is portrait, width:height 3:4: catalogue covers, close-ups, thumbnails and detail-page views. The photograph fills its frame without added padding, bars or distortion. Covers show the whole item with a 5–7% safety margin. Detail crops keep the same format, colour and lighting.

Use a consistent quiet cool studio background, soft light and natural contact shadows across the series. Raster files contain no text, prices, badges or watermarks. A live RU/EN layer on the first card and detail frame shows the model, purpose, level, selected length or actual range and included bindings from the same data. Equivalent facts remain available as ordinary text outside the photograph. Close-ups and enlargement stay clean. Ski covers show both skis and their bindings; preserve their shape, graphics and construction.

Gallery layout: a vertical thumbnail rail on the left, the main portrait on the right, with its caption and counter below. On wide screens it aligns with the left page gutter and fits an HD viewport; variants and concise facts occupy the centre, with prices, terms and booking on the right. Four ski content tabs span the width below the overview, followed by recommendations. On phones booking follows the photo and variants, before information. Support buttons, keyboard and swipe without autoplay. Enlargement shows original pixels with scrolling and no upscaling. Data carries the frame and dimensions. The four Laplandia models have 13 concrete variants, each with its own opaque master and two crops from it: 39 portrait 3:4 frames. These are mock catalogue illustrations with prompts, references and SHA-256 retained. A future API preserves SKU-to-media links. Photo-relative graphics remain a local treatment; the gallery reserve separates the lower annotation from the enlargement control at 200% text.

Skis · description, facts, fitting and reviews

Each of the four models has its own RU/EN description, riding character and selection context. Four left-aligned tabs use the width below the overview: description, specifications, fitting and reviews. A grouped table separates model facts, geometry, selected SKU and rental information. Photo, length, design, bindings and seasons of use follow the variant; model season never stands in for the pair’s age.

The contour figure links height, weight and shoes to accessible inputs. The preliminary result uses checkEquipmentFit and the same manually authored SkiMobile criteria as booking: empty, invalid, match, staff review or a different model. Unknown shoe limits are explicit. The widget does not calculate DIN, ski length or date availability and does not replace full rider fitting.

Review examples are separate typed model-and-branch mocks with explicit fictional labels. Stars, rating distribution, filters, ordering, more results and team replies work. The form validates rating, name and text. Reviews and votes update only after successful storage on this device; storage errors preserve the draft. An asynchronous adapter can be replaced by an API separately. Examples and local records never enter SEO aggregateRating or receive a verified-rental badge.

Installed ski bindings and boot compatibility

A ski variant references its installed binding configuration: brand, model, equipment reference, supported sole interfaces and a known BSL range. The detail summary shows the name and main facts; specifications carry the full information. One setup uses a summary; multiple setups use a choice. The same canonical name appears in booking and the original request snapshot.

BSL is the external sole length in millimetres marked on the boot shell. It is never calculated from EU or Mondo. Adult and junior Alpine / GripWalk interfaces are separate; Touring, WTR and pin interfaces are not interchangeable. Matching uses explicit installed-binding data; unknown soles or mounting require staff review. Heel adjustment travel is not an absolute BSL range. A data match never replaces physical inspection and staff setup; release settings are not calculated automatically.

The four Laplandia installations are mock records, not an inventory of the physical rental fleet. Manufacturer references describe example bindings; product illustrations do not establish equipment identity. An API will replace records and the ranges of actual installations. The future boot catalogue supplies each boot variant’s actual sole interface and BSL to the same compatibility calculation.

Fitting and complete orders

One card groups a model and its explicit variants by length, cosmetic design and installed compatible bindings. Combinations are never generated automatically. Selection changes the SKU’s own photograph, facts and manual branch tariff; unavailable combinations have a textual explanation. One binding setup uses a summary; several real setups use a choice. By default Select & book starts staff fitting in the header branch. A filtered card keeps its photo, lengths, price and action consistent with the same SKU set. Do not invent ratings, discounts, official colourways or date availability.

The form has three stages: dates and guest count, participant profiles and selection, then contact and order review. Rentals require age, height, weight, shoe size, skill, discipline and desired class. Manufacturer facts are separate from manually entered SkiMobile fitting criteria. Matches use explicit ranges; our team confirms length and bindings. Skill, height or weight mismatches require an explicit fitting review; incompatible age or discipline is never accepted as a match.

The cart holds complete rental, lesson or workshop orders only. Each has its own contact, fulfillment, consent and contents; the badge counts orders. Drafts persist per branch, and later variant edits survive reloading the original link. Old loose items remain unfinished selections. Optional ski variant, design and binding IDs stay compatible with legacy length-only records. Client and server validate the SKU, length, preferences and fitting rules; the server recalculates the manual tariff. History retains the original price, variant label and photograph alongside channel receipts; the return form uses the saved quote and label from the original order.

Header data and architecture

The network snapshot contains resorts, branches, company and branch contacts, navigation and brand asset URLs. The current source is typed local mocks supplied through one provider. Branch, collection, cart and appearance preferences persist on the device. Connecting an API replaces the snapshot source.

The header composes separate navigation components. Contact presentation and current branch resolution belong to the network entity; the count belongs to the cart entity. Selection, search and appearance flows live in features. Logo data selects its motion profile; an unknown profile uses the static logo from the same snapshot.

Resort and rental location selection

Selection starts with the resort: the header and dialog show Sheregesh, its region and the branch name. The dialog lists locations at the selected resort. As the network expands, the resort selector is populated from data using the same components. Branch and collection preferences persist on the device.

Laplandia, Laska and Malka use original vector facade illustrations based on photographs from the hotels' official sites. They help guests recognise the buildings. The location at 22 Snezhnaya Street uses an address marker; its pavilion illustration will be based on the owner's photograph. Reference sources and the verification date accompany the SVGs.

Resorts, locations, addresses, phone numbers, messengers, navigation and brand asset URLs come from typed mocks. A branch inherits company contacts unless its own contacts are provided. A future API replaces the data source through the repository contract. Components do not maintain separate location lists or phone numbers.

Selecting a branch closes the dialog and restores focus. Maps have a separate action; nearest-location detection runs only when Near me is activated. The standard layout fits HD and phone screens; enlarged text retains legibility and accessible scrolling. Small illustrations and contact glyphs remain available offline after the first visit.

Header and navigation

Desktop uses two rows. The utility row places collection method, branch and address on the left; offers, delivery, corporate orders, careers and franchise in the center; and the shared phone and messengers on the right. Additional links move into More when space is limited. Enlarged text moves navigation to its own centered row. The main row contains a logo matching search height, categories and search with filters, booking, cart, account and a settings gear. Enlarged text gives search its own row. The main row remains sticky while scrolling. At standard text size it is approximately 62 px tall, with controls of at least 44 px. Thin gradient transitions soften the row and page boundaries; high contrast and forced colors restore explicit lines.

The logo enters once on the first visit in the current tab, then continuously plays its original six-second snowboarder loop. Reloading starts directly with the loop. The booking outline travels around its perimeter; accent icon details have small connected movements with rests and respond to hover or focus. Animations pause offscreen and in hidden tabs. Reduced motion shows a static logo and disables decorative loops. No sound plays.

The mobile dock always contains five actions: Menu, Search, Book, Cart, Account. Search opens a dedicated screen. No action disappears at 320 px; safe areas and the measured dock height are included in content and notifications.

The utility row uses compact collection controls with targets of at least 44 px. WhatsApp, Telegram and MAX use static monochrome 3D glyphs in graphite with soft silver edges and transparent backgrounds. The displayed size is 24 px, with 256 × 256 WebP exports; dark themes brighten the material. Names remain accessible to screen readers. WhatsApp and Telegram open directly with no intermediate menu. MAX uses the network's actual profile or invitation URL in NEXT_PUBLIC_MAX_CHAT_URL; changes require rebuilding. Until configured, the MAX mark gives the shared number in its tooltip and does not simulate a chat link. The branch pin appears gently on arrival and location changes; its accent detail responds to hover, focus and dialog opening. Motion is finite and respects reduced-motion preferences. The branch dialog shows four locations in a desktop grid or compact phone list, alongside addresses, maps and shared contacts.

Cart, request and history

The cart combines complete rental, lesson and workshop orders. Each order retains its dates, contact, collection details and contents; unfinished selections stay separate. Kits use daily rates; hourly rental is available only for individual equipment with a catalogue hourly rate. Lessons and workshop work use their own service options.

No registration required. Your request is saved on this device. Check its delivery status before expecting a reply from the team. Your cart, profile and history are stored in this browser. They will not appear on other devices.

Saving on a device, handing a request to the team and a staff confirmation are separate events. The interface shows actual email and Telegram delivery results. Offline requests can be saved and explicitly sent later.