A Wiki page has to work on both PC and mobile: first split the navigation into three sets
When a single Wiki needs to serve PC, mobile, and SEO at the same time, the hard part is often not the articles themselves, but how navigation, sections, and the footer scroll. Designer Kubai Ken Design shares a concrete approach, plus a prompt that only changes layout.
First, look at a real page
When a product becomes more complex, or the official site starts piling up SEO articles, a Wiki gets brought in. It has to answer users' questions and also be readable by search engines and AI. Once pages multiply, layout problems can't hide.
This is the help page for Lumno. Designer Kubai Ken Design broke down its Wiki framework on X, discussing mobile section switching, sidebars extending beyond the screen, end-of-article guidance, footer height, and navigation structure. Later, they also provided a prompt that can be dropped straight into an AI to change the layout.
On mobile, don't cram all sections at the top
Phone screens are narrow. If you put a horizontally scrolling tab bar at the top, it's hard for users to tap, and as sections increase, it becomes crowded.
This approach uses a persistent bottom menu bar. When opened, it shows a full-screen menu with one section per row. It's easy to tap with a finger, and the titles are clear.
Let the sidebar scroll on its own, and use the edges to tell users there's more
On PC, the section list and the body content scroll separately. The sidebar uses its own height, and overflow is clipped at the top and bottom. Add gradient masks at the clipped edges, plus a centered arrow button, so users know there are more items above or below.
The details also include: hiding the sidebar scrollbar, scrolling the current page into view on load, and remembering the scroll position with sessionStorage. If there is a search box, pressing / focuses it directly.
A commenter added a common pitfall: a sticky navigation bar can cover anchor headings. Add scroll-margin-top to headings, with a value equal to the nav bar height, so users don't have to scroll back up after jumping.
At the end of the article, first help users solve their problem, then offer the next step
Don't just put previous/next page links at the bottom of the article. First use a card to ask: Still not solved? Then give one or two real channels, such as issues, community, or contact information.
After that come the previous/next page links, each with the page title. The first page can link back to the homepage.
The author also mentions that putting community and social media buttons at the end of the article counts as a conversion entry point for both people and AI. The card style should match the body components and look like part of the content. This is essentially serving a contextual ad for the conversion goal.
A footer taller than half the screen sounds counterintuitive
A common footer only contains copyright and a few links, occupying a narrow strip. This approach uses an attractive background image to make the footer taller, encouraging users to scroll to the bottom and stay.
Height is only superficial. The footer needs to contain enough useful information that genuinely helps users solve problems; otherwise it easily annoys people.
Put only three things in the navigation bar
The LOGO returns to the official website, key pages go into a dropdown menu, and there is one core CTA button. Keep it sticky while scrolling.
Safari tints the address bar based on the navigation bar color, so the nav bar background color should coordinate with the brand. This detail doesn't affect functionality, but it affects whether the page looks complete.
On narrow screens, merge the two tables of contents into one bottom bar
Hide the outline on tablets and the page list on phones. Put both into a fixed bottom bar, with the page list on the left half and the outline on the right half.
The right half shows the name of the section currently being read, determined by the line at 20% of the viewport; if too long, it is truncated. Tapping either half opens a sheet from the bottom. Open it with showModal(), slide it up 24px and fade it in, with no dark overlay behind it.
The current item must be marked and scrolled into view by calling scrollIntoView({ block: "center" }). It can be closed by tapping an item, the close button, the outside area, or Esc. Section links then scroll to the corresponding heading. On mobile, tap targets should be one size larger than the desktop list.
The value of this prompt lies in its constraints
The prompt attached by the author doesn't ask AI to redo the visuals. It explicitly requires preserving content, copy, colors, and fonts, and only changing layout, scrolling, and responsiveness. Technically, it limits things to CSS plus a small amount of vanilla JS, with no scrolling or animation libraries.
The page is split into three layers: the body and footer scroll with the page, the page list and outline use sticky, and the top navigation becomes fixed after the first-screen banner leaves. Enter animation 320ms, exit 120ms. When the user enables reduced motion, turn off smooth scrolling and navigation enter/exit animations.
Finally, it also asks to list the changed files and selectors, check four states: top, middle, bottom, and mobile width, and take screenshots. This acceptance criterion is more useful than saying "make it look good."
Original post also gives Lumno's Wiki prototype: https://lumno.kubai.design/en/help/what-is-lumno/ , and X source: https://x.com/Kubai087/status/2116911391437443471 .
发布时间: 2026-11-02 18:03