admin
d5f00b7115
Recorded in CONTEXT.md as a dated ruling and at the top of the comparison. Nothing deleted: /preview/, /preview/m1/ and /preview/m2/ all stay up, hidden, so the next direction can be compared against them. Nothing built: SHARED-DESIGN.md recommended the canonical-stylesheet-plus-gate mechanism only once a direction exists, and none does, so it stays unbuilt. The measured case for a mechanism rather than a convention survives the ruling and is kept in the audit folder: a component copy between the repos silently dropped a bare body rule and broke the phone layout in four measurable ways.
5.5 KiB
Three directions for the website, side by side
OPERATOR RULING, 2026-10-11: none of the three. A new direction, M3, will be briefed separately. All three below stay up, hidden, so M3 can be compared against them. Nothing was deleted, nothing was built, and the shared-design mechanism stays unbuilt (
SHARED-DESIGN.md§3 recommended building it only once a direction exists).
Built 2026-10-11. Nothing here is live. All three are hidden under /preview/, carry
noindex, are blocked by robots.txt, are in no sitemap and are linked from no live page.
| address | |
|---|---|
| A — the current redesign | https://felhom.eu/preview/ |
| M1 — the site is the dashboard | https://felhom.eu/preview/m1/ |
| M2 — hybrid | https://felhom.eu/preview/m2/ |
Screenshots: shots/. Desktop at 1440 px, phone at 390 px, all from the deployed pages.
Measured, same method for all three
| A, current preview | M1, dashboard | M2, hybrid | |
|---|---|---|---|
| Requests, first load | 12 | 68 | 16 |
| Weight, first load | 270 KB | 1 012 KB | 150 KB |
| HTML document alone | 26 KB | 134 KB | 13 KB |
| Front page height, 1440 px | 6 385 px | 1 660 px | 1 853 px |
| Front page height, 390 px | 10 145 px | 6 563 px | 3 057 px |
| Third-party hosts | 0 | 0 | 0 |
| Horizontal overflow at 390 px | none | none | none |
M1's catalogue page (alkalmazasok.html) is 26 410 px tall on a phone — 58 cards in one column.
That is its worst measured number and it is not easily fixable while the page's job is "show the
whole catalogue".
M1 — the site is the dashboard
What it does well. A visitor sees the actual product in the first second, with 58 real apps, real logos, real Hungarian taglines and a real screenshot behind every tile. Nothing on the page is a promise about the product; the page is the product. It also makes the apps page genuinely useful rather than a wall of names: every tile opens what that app does for a family and how to start it.
What can go wrong. A non-technical visitor can read a full-screen dashboard as somebody else's account and look for a login — the brief's own worry, and I think it is the real risk. The welcome card is the only thing saying "this is a demonstration, look around", and one card is thin defence. The second risk is weight: 1 MB and 68 requests on a site that compresses nothing (R-931), four times the current preview, because the front page is 58 logos. The third is SEO: the front page's text is a welcome card and 58 app names; the sentences Google currently ranks would have to live somewhere else.
What it would cost to finish. The largest of the three. Six pages exist as studies and all six
need real design passes; the English twin set does not exist at all and this is the layout where
twinning is most work (every app panel doubles). The catalogue page needs a different phone answer.
The shared-design mechanism in SHARED-DESIGN.md §3(a) stops being optional. Call it several
sessions, and it changes what the website is, so the SEO baseline needs deliberate re-planning
rather than preservation.
M2 — hybrid
What it does well. It is the lightest of the three by a clear margin — 150 KB over 16 requests, and the shortest phone page at 3 057 px — while still showing the real dashboard in the first screen, inside a window frame that reads unmistakably as "a picture of an application" rather than "you are logged in". It keeps the website's own voice and structure, so the SEO work already done survives, and it needs no new twin pattern.
What can go wrong. The window is a smaller promise than M1's: four tiles, not the real thing, so it shows the product without quite letting a visitor use it. It is also the least distinctive of the three — a hero beside a product shot is a normal landing page, which is exactly the charge the current home page was redesigned to escape. And the window risks reading as a static image unless the "click a tile" invitation is obvious.
What it would cost to finish. The smallest. It is one page plus its English twin, built out of components that now exist, and it can borrow the current preview's lower sections nearly as they are. One session, maybe two with the twin.
A — the current redesign, for reference
Already written up in audits/redesign-2026-10-10/. It is the safest of the three, keeps every SEO
string, and is the only one with its "Ki áll mögötte" question already settled. Its weakness is the
one that started this: it still reads as a website about a product rather than the product.
What I would say if asked
M2 is the better bet, and M1 is the better idea. M2 costs least, risks least, and keeps everything already decided. M1 is the only one of the three that answers the original complaint completely — but it is a different website, with a different SEO story, four times the weight, and a real chance a visitor mistakes it for a login page.
If the appeal of M1 is "show the real thing immediately", M2 already delivers most of that for a fifth of the cost, and the honest way to find out whether M1's risk is real is to put M1 in front of two or three people who are not Viktor and watch whether they look for a password field.
The register
Nothing here is filed yet. If a direction is chosen, the work to build it becomes rows; if M1 is
rejected, website/preview/m1/, website/preview/m2/, website/preview/mockup.css and the
MOCKUPS set in scripts/site_gates.py are deleted together.