Our method

How we read a portal.

A transparent, repeatable and reviewable process applied to every published review.

01 — Scoring criteria

Six criteria, fixed weights, published in advance

Every review uses the same grid. Because the weights are public, any final figure can be taken apart and checked against the notes it came from.

Scale
0 – 5.0
Devices per review
3 minimum
Second reader
Always
  • 01

    Access and performance

    20%

    How quickly the portal loads on a standard Canadian connection, whether registration is required before seeing content, and how stable sessions are over longer play.

    Recorded: Load time, sign-up requirements, session stability

  • 02

    Mobile behaviour

    20%

    Whether the mobile build carries the same content as desktop, how the layout adapts on smaller screens, and whether progress follows the account across devices.

    Recorded: Layout scaling, feature parity, cross-device progress

  • 03

    Content volume

    20%

    How much there is to do beyond the first session: number of modes, depth of progression systems, and how often the portal publishes new content or events.

    Recorded: Modes, progression depth, update frequency

  • 04

    Interface and presentation

    15%

    Clarity of navigation, readability of menus and tooltips, and whether the visual style stays legible once several systems are unlocked at the same time.

    Recorded: Navigation, readability, onboarding clarity

  • 05

    Transparency

    15%

    Whether the publisher is named, terms and privacy documents are reachable, and support channels exist and answer. Undocumented operators score low here.

    Recorded: Publisher identity, legal pages, support response

  • 06

    Community and support material

    10%

    Presence of official forums, patch notes, guides or moderated channels, and whether questions asked by players are visibly answered.

    Recorded: Official channels, patch notes, guides

03 — Editorial process

From the queue to a published review

The sequence is fixed, so nothing about the order of publication depends on anything other than the queue.

  1. Day 1Step 01

    Selection

    A portal enters the queue when it is publicly accessible, names its publisher and documents what it offers. Reader suggestions join the same queue with no priority attached.

    OutputEntry brief
  2. Day 2–5Step 02

    Hands-on session

    Editors run structured sessions on desktop, tablet and phone, logging load times, interface behaviour and how far the content carries the first few hours.

    OutputSession notes
  3. Day 6–9Step 03

    Scoring & write-up

    Notes are mapped onto the six weighted pillars. The review is drafted with strengths, limitations and the type of reader the portal actually suits.

    OutputPublished review
  4. Every 6 monthsStep 04

    Revision cycle

    Every published entry is revisited on a rolling six-month schedule, and sooner when a portal changes materially. Updates carry a dated note.

    OutputDated update
Average review time
9 working days
Devices per review
3 minimum
Revision window
Every 6 months