At most one email a week. Unfollow anytime with one click.
Transcript
The full narration of this video. The current sentence is highlighted while the video plays; click any sentence to jump there.
Show transcript
Introduction
Hi, and welcome back. The Sunset Coffee website is complete on the laptop. But almost all of Laras's customers open links on their phones. In this episode we check the phone layout, then ask Claude to tidy up the layout, buttons, form, photos, and menu so it's comfortable on a small screen.
Step 1: Checking the phone layout
The term we need to know is responsive. It means one page that adapts to the width of the screen. On a laptop it's wide; on a phone it stretches downward. We don't build two websites. Just one page with extra display rules for small screens, and Claude writes those rules. Why does the phone layout matter most? First, Sunset Coffee customers come from links on Instagram and WhatsApp, and both are opened on phones. Second, first impressions form within seconds. A page that's cut off or too small usually gets closed right away, and the customer moves on to another coffee shop. Third, our order flow ends in WhatsApp, which is also opened on a phone. So the customer's whole journey, from viewing the menu to ordering, happens on a small screen. Raka opens the page on the laptop, then turns on phone view mode in the browser's developer tools. How to open it can differ in each browser, so check its help menu. The first problem is obvious right away: the title and text are cut off on the right. Second, the page can be scrolled sideways. For phone visitors, this feels like a broken website. Third, the send button is too small to tap with a finger. Customers might tap the wrong thing, or even give up on ordering. Fourth, the form text is too small. On some phones, small input boxes also make the screen suddenly zoom in when tapped. Raka notes all four problems to use in the instruction.
Step 2: Asking for a responsive layout
Raka turns the notes into an instruction, naming the target screen width, then each problem with its expected result: cards in one column, no sideways scrolling, buttons easy to tap, and form text that's big enough. Then Raka adds a very important limit: don't change the laptop layout at all. Without this sentence, Claude might also change the layout Laras already approved. Claude explains how: by adding small-screen rules that only apply when the screen is narrower than six hundred pixels. So the laptop layout stays the same. Claude uses Edit on the style file. The note is important: twenty-two lines added, nothing removed. Here's the gist. The first line, media, opens the small-screen rules. Inside, the menu cards become one column, the page is locked so it can't move sideways, buttons become tall and as wide as the screen, and form text is sixteen pixels. All the lines are green, no red lines. That means no old rules were removed, just as promised: the laptop layout doesn't change. Raka chooses Yes.
Step 3: Seeing the result
Raka reloads the page in phone mode. The title, text, and menu cards now fit the screen, stacked in one column from top to bottom. The page can no longer be scrolled sideways. The only movement is scrolling down, like any website you'd normally open on a phone. The send order button is now as wide as the screen and tall enough for a thumb. The form text is easy to read, and the screen no longer zooms in by itself when an input box is tapped. Finally, Raka turns off phone mode. The laptop layout is exactly the same as before. All five notes now have a check mark. Let's compare. The menu cards that used to be cut off are now stacked in one column and fully visible. The page that used to scroll sideways is now locked, and can only be scrolled down. The send button that used to be small is now as wide as the screen and forty-eight pixels tall, a comfortable size for a finger. Raka also tries three different screen widths, because customers' phones come in different sizes. All three look tidy. Raka doesn't stop at the four problems already spotted, and asks Claude to check every section of the page: is anything still at risk of breaking on a three hundred sixty pixel screen? Report first; don't change anything. Claude reads the index file and the style file from start to finish. It turns out there's one risk nobody noticed: the testimonials box has a fixed width of seven hundred pixels. On a phone, that box will overflow the screen. We missed it because the testimonials are near the bottom. The suggested fix is one line. The fixed width becomes the full screen width, but no more than seven hundred pixels. So it stays the same on a laptop and adapts on a phone. Raka chooses Yes, then checks the testimonials section in phone mode. Now it's tidy. Asking Claude to check the whole page is a cheap way to find problems you missed.
Step 4: Lightweight photos
Besides the layout, there's a problem you can't see: photo weight. Raka asks Claude to check the size of each photo in the images folder. Claude checks the file sizes. The hero photo is almost five megabytes, and another photo is almost four megabytes. The logo is fairly light. Claude explains that photos that heavy make the page slow to open on a phone, especially if the customer's data plan is limited. The suggestion: make copies that are twelve hundred pixels wide, and keep the originals intact. Raka agrees, with a firm limit: don't overwrite the original photos. This runs a command, so a permission box appears. Raka reads it: shrinking two photos in the images folder, not in the materials folder. Raka chooses Yes. The result: the hero photo drops from four point eight megabytes to about three hundred kilobytes, more than ten times lighter. To the eye, the difference is barely visible.
Step 5: Hamburger menu and a phone checklist
One last problem: on a phone, the top menu with five links takes up two lines of the screen. Raka asks for a hamburger button on small screens only, the three-line icon we often see in apps. Claude changes three files: the button's spot in the index file, its look in the style file, and its open and close action in the script file. Raka approves them one by one. The summary: on a phone a hamburger button appears; tap once to open the menu list, tap again to close it. On a laptop, the menu shows as usual. Raka tries it in phone mode, and everything works. All the fixes pass the checks, so Raka saves a new version with the note: tidy phone layout, smaller photos, and hamburger menu. The permission box appears, and Raka chooses Yes. The project history now has four versions, from the first landing page to the phone layout. Keep this checklist for every new page. First, nothing is cut off, and the page can't be scrolled sideways. Second, buttons are easy to tap and text is easy to read without zooming in. Third, the form is comfortable to fill in with a thumb, from the name to the send button. Fourth, lightweight photos so the page opens fast, even with a weak signal. Fifth, checked at several screen widths, then on a real phone. Testing on a real phone can only happen after the website is live online, and that's the goal of the next episode. The screens in this video are simulations, but this checklist applies to any website.
Done!
The Sunset Coffee website is now responsive: one-column cards, no sideways scrolling, buttons and a form that are comfortable for fingers, lightweight photos, and a hamburger menu on phones. In the next episode, the last of this session, we publish the Sunset Coffee website for free so anyone can open it on their phone. See you there!
Practice exercises
Try these on your own after watching to lock in what you learned.
Open your page in phone mode in the browser's developer tools and note the problems
Ask Claude to tidy the small-screen layout without changing the laptop layout
Ask Claude to check photo sizes and shrink the ones that are too heavy
Ask the class material
Type a question or keyword; we find the part of this episode that explains it and jump the video there.
My notes
Notes are saved with the current video time and are only visible to you.
Questions & answers
Stuck on a step? Ask here; the instructor and other learners can answer.
No questions yet.
Your instructor
Cerdas Inovasi Digital Team
Software developers, BIM & 3D engineers, and AI practitioners
53 video classes1,282 episodes
We build software, BIM models, games and AI automations for clients every day, and turn that hands-on work into step-by-step classes: every step is shown on screen and comes with a PDF guide you can keep.
