admin
7413e0dfab
documentation/audits/mockups-2026-10-11/
COMPARE.md the three directions side by side, measured the same way:
A current preview 12 req / 270 KB
M1 dashboard 68 req / 1012 KB (front page 1 660 px)
M2 hybrid 16 req / 150 KB (phone 3 057 px, the shortest)
plus three sentences each (good / risk / cost) and the risk I
think is real: a non-technical visitor may read M1 as somebody
else's account and look for a login.
SHARED-DESIGN.md REPORT ONLY, nothing built. M1 needed 260 CSS rules: 188 (72%)
copied from the controller UNCHANGED, 8 adapted, 64 new. It used
188 of the controller's 826 rules (23%). The 18 tokens are
already identical - verified by parsing both :root blocks, zero
differing values.
Recommends (a) a canonical felhom-ui.css plus a copy-drift gate,
over (b) serving the controller's stylesheet to the website -
and recommends NOT building it until a direction is chosen.
shots/ desktop and phone captures of all three, from the deployed pages
The finding that outranks the percentage, and the reason for the recommendation: a
component-level copy silently drops the element-level rules those components depend
on. The extractor copied every .sidebar/.content/.mobile-topbar rule and missed
"@media(max-width:768px){ body { flex-direction: column } }". Everything LOOKED
copied; the phone layout was broken in four measurable ways. Invisible to a diff,
invisible to review. A second instance the same evening: the drawer is gated on a
'js' class set by an inline script that was not copied either.
Register 129 -> 129 (one closed, one opened):
R-929 CLOSED - NOT A DEFECT. Measured from the catalog: 60 templates, minus
plant-it (abandoned) and wger (hidden) = 58 offered, exactly what the prose
says; the page's 59th card is FileBrowser carrying the single "Beepitett"
badge. Set difference both ways is empty. The premise was wrong on BOTH
halves. Rule kept: before filing a count disagreement, check whether the
counts are counting the same set.
R-932 OPEN - 8 catalog strings across 5 apps carry an em dash, and they render in
the controller's app page on every real box. Found because the mockups are
the first thing to show catalog copy on a website page. Lives in a repo this
session did not have in scope, so it is a row, not a fix.
5.1 KiB
Three directions for the website, side by side
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.