Web Designs Done Right!

Color is the first impression that never introduces itself. Visitors don't say, "Hmm, interesting contrast ratio on that call-to-action." They feel it. Warm or cold. Trustworthy or chaotic. Professional or "my cousin picked these in PowerPoint at 1 a.m." Your color scheme is either working for you or quietly sabotaging every paragraph you carefully wrote.

On this site I run an olive, maroon, parchment, and brass palette — flat colors, no gradients dressed up as personality. It's deliberate: earthy greens that feel steady, a maroon that carries weight without screaming, parchment that doesn't burn your retinas at midnight, and brass for the little moments that need a wink. GREAT color schemes have a reason for existing. Random ones have a reason for redesigns.

What "Great" Actually Looks Like

A great scheme isn't more colors. It's the right few colors doing clear jobs. Think roles, not rainbows:

• Primary — brand personality (header, key UI chrome)
• Accent — buttons, links, the thing you want people to click
• Background — the quiet stage your content stands on
• Text — dark enough to read without squinting; light enough for dark panels
• Support — borders, muted labels, hover states that feel intentional

If every element is shouting in a different hex code, nothing is heard. If everything is the same beige-grey mush, nothing is felt. Great schemes pick a lane: limited palette, clear hierarchy, contrast that works for actual human eyes — including eyes that aren't 20/20 and screens that aren't calibrated like a photography studio.

The Quick Reality Check

Ask yourself honestly:

• Can you name your three main colors without opening the CSS file?
• Do links look like links, or like decorative confetti?
• Does text pass a contrast sniff-test on phone screens outdoors?
• Would a color-blind visitor still understand what's clickable?
• Does the palette match the business, or the template default from 2019?

Free builders love bright gradients and seven shades of almost-the-same blue. Hand-coded sites can do better because you own the variables. On Arch Linux, in a real stylesheet, with names like --olive and --maroon, color stops being decoration and starts being architecture.

If your color scheme is great, people trust the page before they finish the first sentence. If it isn't, they bounce before they learn what you sell. Audit the palette. Name the roles. Cut the noise. Then let the content do the talking — in a voice your colors already introduced.

Photos in this post are from Unsplash (free to use).

Never say never. That includes me promising I won't redesign this site again. I've said it before — in 2004 I was already logging re-redesigns like they were weather reports. "New colors." "Re-redesign." "Re-re-redesign." Two decades later I still open the CSS file and hear the same quiet voice: what if the header breathed a little better on phones?

Will I redo the design? Probably. Not because I'm restless for novelty, but because the web moves, browsers change, and my own standards keep climbing. A site that felt sharp last year can feel slightly off after you've fixed enough contact modals and mobile navbars for clients. You develop taste. Taste is expensive. Taste keeps opening pull requests against your own homepage.

Redesign Isn't Failure — Stagnation Is

Business owners panic when designers talk redesign. They imagine throwing everything away and starting from a blank Figma board with a sad invoice attached. That's not always the job. Sometimes redesign means:

• Fixing the header that invades the navbar on small screens
• Replacing a palette that looks tired under modern displays
• Swapping desktop-first layout for mobile-first structure
• Cleaning markup so accessibility isn't an afterthought bolted on with guilt
• Dropping platform chrome that no longer earns its keep

The worst websites are the ones frozen in amber because someone said "we redesigned in 2018, we're good." The web isn't 2018. Phones aren't 2018. Your competitors aren't 2018. Never saying never means staying honest about when polish has become patchwork.

So… Will I?

Yes — when something stops earning its place. Maybe the olive-and-maroon story still sings for years. Maybe next year I want more whitespace, a quieter footer, or a type scale that respects long blog posts better. I won't redesign for sport. I will redesign when craft demands it.

That's the promise I can keep: not "never again," but "never casually." Hand-coded sites make that possible. You change a variable, ship a better header, FTP the files, and move on. No platform hostage situation. No template personality transplant. Just iterative craft — the same discipline that turned "re-redesign" from a joke title in 2004 into a professional habit in 2026.

Never say never about redesigning your website. Say never redesign without a reason. Then keep enough skill — and ownership of the code — that when the reason shows up, you can answer it without starting from zero or renting someone else's design forever.

Photos in this post are from Unsplash (free to use).

If coding feels like punishment, something is wrong with the setup — not with you. I'm not talking about fake hustle posters that say "grind until your eyes bleed." I mean actual fun: the kind where you lose track of time fixing a layout, laughing at a console error that was one missing semicolon, and high-fiving the dog when the contact form finally submits without throwing a 500.

Make coding fun on purpose. Fun is not the opposite of professional. Fun is how you stay good long enough to be professional. Burned-out builders ship copy-paste. People who still enjoy the craft ship sites that feel cared for.

How I Keep It Enjoyable

There's no single recipe, but here's what works in this corner of Arch Linux with a wolf wallpaper and a playlist that refuses to whisper:

• Own the tools — hand-coded HTML, CSS, and PHP beat mystery menus when you want real control
• Soundtrack optional, attitude required — Led Zeppelin, lo-fi, silence; pick energy that matches the task
• Ship small wins — one validated page beats a half-finished empire of tabs
• Make the environment nice — theme your editor, sit somewhere comfortable, pet the dog between deploys
• Learn in public (or on your own blog) — writing about what you fixed turns frustration into story
• Celebrate boring excellence — accessible markup, fast loads, clean FTP deploys are secretly thrilling

Fun is also boundaries. Turn off the fourteen Slack channels. Close the tab with the outrage of the hour. Give yourself one clear problem: make this modal close on Escape; make this color scheme stop fighting the text; make this mobile nav stop hiding Services like it's in witness protection.

Fun Scales Better Than Fear

Clients can feel the difference. A site built by someone who still likes coding has cleaner structure, better micro-decisions, and fewer "we'll fix it later" landmines. A site built under pure deadline dread often looks fine in the screenshot and falls apart the first time someone tries to use it on a phone in a parking lot.

So if you code for a living — or you're hiring someone who does — protect the fun. It's not childish. It's quality control with a grin. Put on the music. Open the real files. Fix one honest thing. Watch the browser obey you. That loop is why some of us have been doing this since the XHTML days and still show up on a Sunday evening ready to write another post.

Make coding fun, and the craft stays yours. Lose the fun, and you're just renting hours to problems you no longer care about solving well. I choose fun. The validator, the dog, and the deploy log all seem to agree.

Photos in this post are from Unsplash (free to use).

People assume web design is either a spreadsheet chore or a drag-and-drop fever dream. Neither is true when you're hand-coding on Arch Linux at 5:18 p.m. with a contact modal open, a wolf howling at the moon on your wallpaper, and the quiet satisfaction of watching valid markup do exactly what you told it to do. That's not work. That's craft with syntax highlighting.

Web designing is fun because it's part puzzle, part art project, and part "why is this three-pixel gap judging my entire life?" The moment you fix that gap, you feel like you invented gravity. The moment your modal finally slides in without trapping focus in the footer, you feel like a civilized adult who understands software. Both feelings are valid. Both are addictive.

The Joy Hits Different When You Build It Yourself

Free builders give you convenience. Hand-coding gives you agency. You decide the HTML structure. You choose the breakpoints. You write the CSS that makes a navbar behave on a phone instead of staging a hostage situation behind a hamburger icon. When something breaks, you know where it lives — usually in a file you can open, not a settings panel buried under three upsells and a tutorial hosted by a stranger.

• You see an idea become a real page in minutes, not "after the template loads its personality"
• Small wins stack up: semantic landmarks, working forms, a header that stops invading the navbar like an overfriendly houseguest
• You learn constantly — browsers, accessibility, performance, and the eternal adventure of PHP 7.4 vs PHP 8 on production
• You build something a business owner can point to and say, "That's mine," not "That's my platform subscription"

Is every day sunshine and perfectly aligned flexbox? No. Some days Apache throws a 403 because your DocumentRoot still believes in a folder you deleted two weeks ago. But even those days have entertainment value, which is more than most office jobs can claim.

Fun Doesn't Mean Frivolous

Enjoying the work makes you better at it. You proofread twice. You run the validator. You test the contact slideout on every page because you're mildly obsessed with things working correctly — not because a client is breathing down your neck, but because broken markup offends your sense of order like a crooked picture frame in an otherwise nice room.

If you're thinking about hiring someone to build your site, ask whether they still like doing this. Burned-out builders ship templates. People who still find the craft fun ship sites that load, make sense, and don't embarrass you on a phone screen.

Web design is fun when it's yours — your code, your standards, your layout decisions, your victory dance when the modal closes on Escape like a well-mannered guest. I recommend the victory dance. My dog endorses it too.

Desk photo is mine. Additional photo from Unsplash (free to use).

Yes, it's Led Zeppelin. No, I will not spell it "Zepplin" on the title tag. I will, however, defend the sacred pairing of British rock thunder and hand-coded HTML on a Saturday afternoon. You've got your Arch Linux desktop, your wolf wallpaper contemplating the moon like a dramatic roommate, and John Bonham doing drum things on the TV behind you like a productivity coach who refuses to whisper.

Coding in silence is fine if you're debugging a production outage at 2 a.m. Coding with Zeppelin is for the creative stretch — the part where you refactor a navbar, tame a stubborn modal, or finally convince a flex layout to stop behaving like it's personally offended by your existence.

Rock and Markup Share the Same Energy

Think about it. A great song has structure: intro, verse, chorus, bridge, outro. A great webpage has structure: header, nav, main, sections, footer. Both fall apart when you throw everything in at once with no hierarchy and call it done. Led Zeppelin didn't become legendary by stacking fourteen guitar solos and hoping for the best. Neither should your homepage.

• "Whole Lotta Love" — for bold hero sections that know what they want
• "Ramble On" — for long blog posts you swear you'll edit tomorrow
• "Kashmir" — for CSS that builds slowly, then suddenly becomes epic
• "When the Levee Breaks" — for the moment your local site works but production PHP 7.4 says no

The drums help especially. There's something about a steady groove that keeps your typing rhythm honest. You stop overthinking. You commit to the markup. You ship the fix. Then you realize you forgot to close a <div> and the validator gives you that look — the same look your spouse gives you when you said you'd be done "in five minutes" two hours ago.

Headphones Optional, Attitude Required

I'm not saying Zeppelin is the official soundtrack of web standards compliance. I'm saying energy matters. If you're building a business site — clean, accessible, fast, professional — you're still allowed to enjoy the process. Put on music that makes you feel like the layout will obey you. Work like the footer isn't going to wander into the header unless you invite it.

And if your coding playlist is yacht rock, death metal, or lo-fi beats to validate HTML to, good. The point is momentum. The point is showing up at the keyboard with a little swagger and a lot of semantic intent.

Code like Bonham drums: confident, deliberate, and loud enough to scare bad markup into behaving. Then pet your dog, save your files, and for heaven's sake run the validator before you FTP anything.

Desk photo is mine. Additional photo from Unsplash (free to use).

Short answer: yes. Longer answer: also yes, but with a plan. When I say "stop building for the internet," I don't mean burn your router and move to a cabin. I mean stop pretending the desktop browser is the default customer experience. Most people find your business on a phone — in a parking lot, on a couch, in line at the grocery store, squinting through screen glare like they're decoding ancient hieroglyphs.

"The internet" in web-design brain usually means wide layouts, hover states, giant hero banners, and navigation with enough dropdowns to qualify as a filing system. That world still exists. It's just not where your customers live anymore. Building desktop-first in 2026 is like printing a beautiful full-page newspaper ad and then wondering why nobody reads it while they're walking the dog.

The Phone Is the Front Door Now

Mobile traffic isn't a trend line on a chart you check once a quarter. It's the front door. If your site only feels good on a 27-inch monitor, you've built a lovely waiting room that most visitors never enter. They hit your homepage on a five-inch screen and immediately know whether you respect their time.

• Tap targets big enough for actual human thumbs, not pencil erasers
• Text that reads without pinch-zoom archaeology
• Navigation that works one-handed — not a hamburger menu hiding a desktop menu that was never designed for touch
• Pages that load before your visitor's patience files for divorce
• Contact info and calls-to-action where thumbs naturally reach

This isn't radical. It's manners. You're greeting guests at the entrance they actually use.

Desktop Isn't Dead — It's Just Not in Charge

Stopping desktop-first design doesn't mean abandoning desktop. It means flipping the order. Design for the phone first. Make it excellent. Then ask what larger screens can add without wrecking the clarity you earned. Desktop gets bonus real estate — use it for richer visuals and breathing room, not for dumping every link you've ever considered into one horizontal navbar.

I reworked my own site header because the title kept invading the navbar on small screens like an overfriendly houseguest. That's what phone-first thinking looks like in practice: you notice the friction, you fix the layout, you test on a real device instead of resizing a browser window and calling it responsive.

What to Do About Your Current Site

If your site was built desktop-first — especially on a free builder that "auto-resizes" for mobile — you're probably serving a shrunken version of a layout that was never meant to be held. Retrofitting mobile usability onto that is like adding a ramp by rearranging the stairs. Possible. Expensive. Full of compromises.

Start fresh with mobile as the blueprint, or hire someone who will. Ask how they handle phone layouts. If they say "it adapts automatically," ask follow-up questions with detective energy. Auto-adapting is not a strategy. Intentional mobile design is.

Build for the device in your customer's hand, not the monitor in your office. The internet isn't going away — but it's mostly arriving through a phone screen, and your website should act like it knows that.

Photos in this post are from Unsplash (free to use).

Every few years, someone declares dropdown menus dead. Usually right after they've fought a broken mega-menu built by a platform that treats navigation like a junk drawer. Then they pivot to hamburger icons on everything — including desktop sites — and wonder why users can't find the "Services" page without a treasure map and a spirit of adventure.

I'm here to defend the humble CSS dropdown. Not every dropdown. Not the ones that require hover precision worthy of a surgical robot. But a clean, semantic, hand-coded dropdown? Still one of the most useful tools in a desktop navigation toolkit. Yes, I said desktop. We'll get to mobile in a minute.

Why CSS Dropdowns Still Earn Their Keep

On a wide screen, dropdown menus solve a real problem: too many destinations, not enough horizontal space to shout about all of them at once. A well-built dropdown groups related links, keeps the navbar scannable, and lets users drill into subsections without a page reload. That's not laziness. That's information architecture.

• Hover and focus support — desktop users still use mice and keyboards; :hover and :focus-within are valid interaction models
• Semantic HTML — a <ul> inside a <li> is exactly what lists are for
• No JavaScript required — pure CSS dropdowns are fast, resilient, and don't break when a script fails to load
• Predictable behavior — users have seen dropdowns for decades; familiarity is a feature, not a flaw
• Clean visual hierarchy — top-level categories stay visible; details tuck underneath like a well-organized filing cabinet

The problem was never dropdowns. The problem was dropdowns implemented badly — tiny hit areas, no keyboard access, menus that vanish the millisecond your cursor twitches, and fourteen nested levels because someone confused "comprehensive" with "hostile."

What a Good Dropdown Looks Like in 2026

A modern CSS dropdown should be boring in the best way. It opens on hover and keyboard focus. It stays open long enough for a human being to move their pointer. It doesn't cover the entire viewport like a pop-up with commitment issues. And on mobile? It shouldn't be a hover menu at all — it should collapse into an accordion or a tap-to-expand pattern that respects touch.

That's the part people miss when they bury the whole nav behind a hamburger on desktop: you're hiding navigation that was already working. Dropdowns aren't the enemy of mobile-first design. They're the desktop enhancement you earn after the phone layout is solid. Different devices, different patterns, same goal — get people where they need to go without friction.

When to Drop the Dropdown (Pun Intended)

Skip dropdowns when you only have four links total. Skip them when the submenu is one item — just link directly. Skip hover-only menus with zero keyboard support, because that's not a dropdown, that's an accessibility violation wearing a bow tie. And definitely skip builder-generated menus you can't style or debug when they inevitably start pointing at pages that don't exist.

But if you have a real site with real sections — services, resources, about, portfolio categories — a hand-coded CSS dropdown is still a professional, lightweight, standards-friendly solution. I'd rather write twenty lines of clean CSS than bolt on a JavaScript menu library that needs three polyfills and a prayer.

Don't drop dropdowns because they're unfashionable. Drop the bad ones. Keep the good ones. And for heaven's sake, test them with a keyboard before declaring your navigation finished.

Photos in this post are from Unsplash (free to use).

Let's be honest about free website makers. They promise you a gorgeous business site in an afternoon, no coding required, just drag, drop, and become a digital entrepreneur before your coffee gets cold. It sounds amazing. It also sounds like Ikea instructions that end with "and somehow you now own seven extra bolts and a wobbly bookshelf that leans like it's eavesdropping."

I'm not saying those platforms are useless for everyone. If you need a quick placeholder page for a bake sale, go forth and drag your blocks. But if you're building a real business presence — one that loads fast, ranks in search, survives a phone screen, and doesn't break when you sneeze near the settings panel — free builders are a starter kit, not a finished house.

What You're Actually Buying (Even When It's "Free")

Free website makers sell convenience. What they often deliver is a template wearing your logo like a borrowed jacket. You get limited layouts, bloated page weight, generic markup, and branding that whispers "I was assembled at 11 p.m. from a dropdown menu." Search engines notice. Customers notice. You notice when your contact form sends messages into the void like a message in a bottle with no ocean.

• Cookie-cutter structure that looks like every competitor on the same platform
• Code you don't control — and can't fix when something breaks
• Features that mysteriously require a paid plan the moment you need them
• SEO tools that are mostly stickers on a broken windshield

A professional builds your site like a carpenter builds a cabinet: measured, intentional, and meant to last longer than the trend cycle. A free builder gives you pre-cut panels and hopes you don't notice the missing back wall until tax season.

Why Professionals Still Win

I hand-code websites. Yes, I'm biased. I'm also the person clients call after the free-builder experiment develops "personality" — which is code for random layout shifts, broken mobile menus, and contact forms that work only on Tuesdays. A pro handles hosting setup, error correction, semantic HTML, accessibility, and the boring technical stuff that makes a site work instead of merely exist.

Save the DIY energy for painting your guest room. Let someone who dreams in valid markup build the thing customers judge you by in the first three seconds.

Photos in this post are from Unsplash (free to use).

So you decided to host your own website. Brave. Romantic, even. You pictured yourself as the captain of your digital ship, steering through calm seas of bandwidth while your business logo glows heroically in the moonlight. Then you met Apache. Or Nginx. Or a hosting control panel that looks friendly until you click the wrong toggle and your site starts speaking HTTP 500 like it's possessed.

DIY hosting isn't impossible. Plenty of smart people do it. But "possible" and "wise use of a business owner's Tuesday" are different categories. When your site goes down at 9 p.m. and you're the only IT department, you become customer support, sysadmin, and emotional support animal for yourself.

The Greatest Hits of Self-Hosted Panic

I've lived this on Arch Linux, which means I chose difficulty mode with a smile. Your hosting adventure may include:

• DNS records that point nowhere, like a GPS with commitment issues
• SSL certificates that expire quietly and take your trust badge with them
• File permissions that turn a simple upload into a philosophical crisis
• PHP version mismatches where localhost is PHP 8 and production is PHP 7.4 and nothing is fine
• Error logs that read like passive-aggressive poetry

Professionals set up hosting so it's monitored, backed up, and recoverable. You set up hosting and then Google "why is my website blank" with the desperation of someone who can hear their phone ringing with client calls.

Let Someone Else Carry the Uptime

Your business website should sell your services, not teach you the emotional range of server administration. Hire someone who knows how to configure hosting, fix errors before you notice them, and deploy updates without accidentally uploading your entire site into the contact/ folder. Ask me how I know that last one is possible.

Your job is your business. My job is making sure the internet shows up when people look for you.

Photos in this post are from Unsplash (free to use).

Free website platforms are like sample trays at the warehouse store. Delicious at first. Encouraging. Then suddenly you're walking out with a forklift pallet of premium widgets you didn't know existed, plus a membership fee, plus an ad campaign upsell, plus the vague feeling you were upsold by a chatbot wearing a smile.

You start on the free plan. You pick a template. You add your logo. Then you need a custom domain. Then you need to remove their branding. Then you need forms that actually email you. Then you need SEO tools that do more than whisper encouragement. Each step is a small toll booth on the road to a "professional" site that still isn't as professional as one built correctly from the start.

The Hidden Invoice Nobody Reads at 2 a.m.

DIY platforms love offering coupons for Google Ads when what you actually need is clean HTML, fast loading pages, and a site structure search engines can understand without deciphering a JavaScript jungle. So you pay monthly for the builder and you pay for ads to compensate for weak organic visibility. Congratulations — you now have recurring billing and a hobby.

• Monthly platform fees that never quite end
• Paid add-ons for basics like forms, analytics, or removing ads
• Migration pain if you ever want to leave
• Time — the most expensive line item, always omitted from the brochure

Hiring a professional often costs more upfront and less forever. You get a site you own, code that isn't held hostage, and a human who answers questions without making you watch a tutorial hosted by a cheerful stranger.

Do the Math Like a Grown-Up Business

If your hourly rate is worth anything, multiply the hours you'll spend fighting templates by that number. Add platform fees for a year. Add the ad spend you'll need because your pages load like they're carrying emotional baggage. Compare that to a hand-coded site built for your audience, your goals, and your sanity.

Free is a marketing word. Professional is a results word. Choose accordingly before your "simple website project" becomes a part-time job you didn't apply for.

Photos in this post are from Unsplash (free to use).

Designing for desktop first in 2026 is like opening a drive-through and then acting surprised that people keep walking up to the window. Most of your visitors are on phones. They are not carrying mice. They are carrying thumbs — wonderful, clumsy, opinionated thumbs that will not delicately hover over your tiny navigation links like a museum curator.

Mobile-first design means you plan for the small screen first, then expand gracefully for larger ones. Not the reverse. Not "shrink the desktop site until the menu catches fire." You build for real human hands, real glare on screens, and real impatience.

What Mobile-First Actually Looks Like

Mobile-first is not one CSS trick. It's a mindset:

• Navigation that works with one thumb, not a full-hand yoga pose
• Text that reads without pinch-zoom archaeology
• Buttons large enough to tap confidently, not accidentally summon the footer
• Images that load quickly instead of staging a bandwidth protest
• Content hierarchy that makes sense when the screen is taller than it is wide

I reworked my own site header because the title kept invading the navbar like an overfriendly houseguest. Balance matters on mobile. So does humility — your giant desktop hero image does not get to bully the rest of the layout on a phone.

Design for the Device People Actually Use

If you hire someone to build your website, ask how they handle mobile. If they say "it auto-resizes," ask follow-up questions with the intensity of a detective who just found suspicious footprints. Auto-resizing is not a strategy. Intentional mobile design is.

Your customers are not sitting at desks waiting to admire your hover effects. They're on couches, in parking lots, and in line at the grocery store. Meet them where their thumbs are.

Photos in this post are from Unsplash (free to use).

Some businesses should think phone-only from the jump. Food trucks, personal trainers, mobile groomers, emergency plumbers — if your customer is likely to find you while squinting at a screen between errands, your website is a phone tool first and a desktop experience second. Maybe third. Maybe "we'll get to it after lunch."

Phone-exclusive design doesn't mean you ignore desktop. It means you stop treating mobile like the kid's table at Thanksgiving. You design for the thumb zone — the area at the bottom of the screen where human thumbs naturally camp out — and you build navigation that respects one-handed reality.

The Thumb Zone Is Real Estate, Not Decoration

Put the important stuff where thumbs can reach it:

• Call buttons — obvious, tappable, not hidden behind a philosophical hamburger menu
• Contact actions near the bottom or within easy thumb arc
• Short paragraphs and scannable headings — nobody reads a novel on a bus
• Forms with big inputs and sane autofill support
• Fast load times, because mobile networks love to humble us

Desktop can still look beautiful. But if the phone experience is an afterthought, you're essentially hanging your business sign at the wrong end of the building and wondering why foot traffic is low.

Mobile-Exclusive Thinking Saves Money Later

Retrofitting mobile usability onto a desktop-first site is like adding a wheelchair ramp by rearranging the stairs. Possible. Expensive. Full of compromises. Start with the phone, expand upward, and you'll spend less time fixing layouts that break every time someone rotates their screen.

Design for thumbs. Test on real phones. Assume your visitor is standing in bright sunlight with 14% battery and zero patience. If it works there, it works everywhere.

Photos in this post are from Unsplash (free to use).

Have you ever opened a website on your phone and immediately felt tired? Like the menu expected you to perform a ceremonial swipe sequence before revealing the phone number? That's desktop-last design wearing a mobile disguise. It looks responsive. It feels punitive.

Desktop-last happens when someone builds a sprawling horizontal layout with twelve navigation items, four dropdowns, and a hero banner the size of a billboard, then "fixes" mobile by hiding everything behind a hamburger icon and hoping for the best. The hamburger is not a strategy. It's a junk drawer.

Signs Your Site Was Desktop's Favorite Child

• Tiny tap targets packed tighter than seats on a budget airline
• Horizontal scrolling — the UX equivalent of a haunted hallway
• Pop-ups that cover the entire screen and refuse to leave politely
• Text over images with contrast so low it qualifies as abstract art
• Contact forms that zoom the page when you tap a field because font sizes were an afterthought

Mobile users don't want the desktop experience in miniature. They want the right experience for the device they're holding. That usually means fewer choices up front, clearer calls to action, and content that loads before their coffee cools.

Flip the Priority Order

Build mobile layout first. Test it. Make it excellent. Then ask what desktop can add without ruining the clarity you earned. Desktop gets bonus space — use it for richer visuals, not for dumping every link you've ever thought of into one navbar.

A professional designs for the phone in your customer's hand, not the monitor in your office. The giant menu can stay on desktop if it behaves. On mobile, simplicity is not minimalism — it's respect.

Photos in this post are from Unsplash (free to use).

People love asking me for SEO like it's a spray you mist over a finished website. Poof, rankings! In reality, SEO starts while the HTML is being written — not after the site is already a tangled ball of divs, inline styles, and JavaScript that needs three wishes and a sacrifice to load.

Search engines are trying to understand your content and serve relevant results. They are not impressed by a plugin badge if the underlying markup is nonsense. Clean structure helps crawlers. Clear headings help relevance. Fast pages help everyone, including the human beings who were allegedly the point.

What Search Engines Actually Read First

Before backlinks, before keyword campaigns, before you name your blog posts like a courtroom drama, get the foundation right:

• One clear <h1> per page that says what the page is about
• Logical heading hierarchy — not three <h2>s because they looked big
• Descriptive title and meta description tags written for humans, not robots cosplaying as humans
• Semantic elements so crawlers know what's navigation, what's main content, and what's footer
• Clean URLs and internal links that make sense without a treasure map

Free website builders often bury your actual content under layers of generated markup. Hand-coded sites can give search engines exactly what they need — which is why I keep preaching standards even when it's more work upfront.

Plugins Don't Fix Spaghetti

If your site code is a mess, an SEO plugin is like putting a air freshener in a car that's on fire. It smells like progress. It is not progress. Hire someone who builds SEO into the structure from day one, and you'll spend less time chasing rankings and more time answering leads.

Good SEO is good coding with business goals. Wild concept, I know.

Photos in this post are from Unsplash (free to use).

Search engines don't fall in love with your font choices. They fall for structure. Semantic HTML is how you tell crawlers, browsers, and assistive technology what your content means, not just what it looks like. It's the difference between a labeled filing cabinet and a cardboard box labeled "stuff."

When I fixed my own site, I replaced misused ARIA roles and div fortresses with actual landmarks: <header>, <nav>, <main>, <footer>. Search engines eat that up because they can find your content without wading through hundreds of lines of framework noise.

Semantic HTML Is SEO Infrastructure

• <article> for self-contained content like blog posts — hello, this page
• <section> for grouped topics within a page
• <nav> for navigation, not every list of links on earth
• Real text in headings, not images pretending to be headlines
• Alt text on images that describes the image, not keyword stuffing

Machine-generated sites from free builders often output markup that looks like it was assembled by a blender. You get divs with classes named after internal IDs that mean nothing to Google. Hand-coded semantic pages give crawlers a straight path to your words — which is kind of the whole point of having a business website.

Standards Are a Ranking Advantage, Not Homework

Will semantic HTML alone put you at #1 for every keyword? No. SEO is still a buffet of content quality, relevance, performance, and backlinks. But standards-compliant markup removes self-inflicted obstacles. You stop making search engines guess. You stop hiding your best content behind code they struggle to parse.

Speak the search engine's love language: clear structure, honest headings, and HTML that means what it says.

Photos in this post are from Unsplash (free to use).

SERPs — Search Engine Results Pages — are where your website either gets invited to the party or left home with a broken layout and a 404 excuse. You can't buy your way into credibility with ads alone if your organic foundation is wobbly. Web standards coding is how you make sure search engines can read, index, and trust your pages without sending a crawler on a three-day expedition through JavaScript soup.

I've seen sites where the visible text is fine and the underlying code is a horror novel. Search engines see both. So do accessibility tools. So do I, when a client asks why their "free website" isn't showing up for anything except the business name spelled wrong.

How Standards Affect Real Search Performance

• Indexability: valid, semantic markup helps crawlers find and understand your content
• Performance: lean HTML/CSS loads faster — and speed influences rankings and human patience
• Accessibility: overlaps with SEO more than people think; clear structure helps everyone
• Mobile usability: a standards-aware responsive site beats a broken shrink-to-fit layout
• Maintainability: clean code makes SEO updates possible without rewriting the whole site

When I ran validators on my own pages and cleaned up over a hundred errors, I wasn't just checking boxes. I was making the site easier for search engines, browsers, and future me to live with. That's the professional difference: we build for results, not just screenshots.

Your Competitor's Secret Weapon Might Be Valid HTML

Wild idea: what if the business ranking above you simply has a faster, cleaner, more intelligible website? No magic. No keyword stuffing. Just standards, solid content, and markup that doesn't require a search engine to solve a puzzle before reading your phone number.

Stop making Google work overtime. Build it right, structure it honestly, and let your content show up where your customers are already looking.

Photos in this post are from Unsplash (free to use).

Let's talk about web standards. Not the boring conference-room kind where someone reads forty slides about W3C governance while the audience dreams of lunch. I mean the practical stuff: semantic HTML, accessible forms, valid markup, and not treating your homepage like a MySpace page from 2007 that learned React and developed confidence issues.

I sell websites for a living. I preach standards on my services page. Then I ran a validator on my own site and nearly spilled coffee on my keyboard — which, given my header background, would have been a weirdly on-brand disaster. The point stands: standards matter even when you think you're the exception. Especially then.

Semantic HTML Is Not Decoration

A <div> is a perfectly fine element. I have nothing against divs. But when your entire page is seventeen nested divs and a prayer, you haven't built a website — you've built a cardboard fort. Screen readers, search engines, and future-you-at-2-a.m. all need real landmarks: <header>, <nav>, <main>, <footer>.

I once found a page using role="contentinfo" on the main content area. That's like putting a "EXIT" sign on the front door of a restaurant. Technically a door. Semantically a cry for help. Standards exist so machines and humans can agree what things are, not just what color you made them in CSS.

Accessibility: Not Just for "Those Users"

"Nobody uses keyboard navigation." Incorrect. I do. Your privacy-conscious cousin does. Your client with repetitive strain injury does. The judge reviewing a discrimination complaint might not tab through your site personally, but they will care whether you planned for people who don't interact with a mouse the way a hyperactive squirrel does.

• Visible focus styles — so tabbing doesn't feel like navigating by sonar
• Real label elements tied to inputs — placeholders are hints, not identities
• Buttons that are <button>s, not divs wearing a fake mustache
• Dialogs that trap focus and close with Escape — like civilized software

Accessibility isn't charity. It's quality control. Also, it keeps you from accidentally building a contact form that only works if you click one exact pixel while the moon is in Aquarius.

Validators Exist Because Hubris Is Free

Browsers are famously forgiving. You can serve HTML that looks like it was typed by a cat walking across a keyboard, and Chrome will still render something. Usually. Maybe. On Tuesdays. That tolerance is a trap. It trains developers to believe their code is fine because nothing exploded in their face immediately.

Run a validator. Run Lighthouse. Run an accessibility checker. Yes, you will get feedback. Some of it will sting. I went from 111 errors to zero on my main pages, and the experience was humbling in the way stepping on a bathroom scale after the holidays is humbling — informative, necessary, and slightly personal.

Standards-compliant markup ages better. It survives CMS changes, redesigns, and that intern who "just tweaks one thing" and accidentally rewrites the footer in Comic Sans inline styles.

Mobile Is Not a Cute Little Extra Screen

Over half your visitors are probably on phones. If your layout only sings on a 27-inch monitor, congratulations — you've built a desktop screensaver with SEO ambitions. Responsive design isn't "make it narrower until it fits." It's structure, typography, touch targets, and not making people pinch-zoom to read a sentence that should wrap like a normal paragraph.

I recently reworked my own mobile header because the title was either invading the navbar like an overfriendly houseguest or shrinking to microscopic size like it owed the layout money. Balance matters. Standards matter there too: readable text, usable navigation, content that doesn't require archaeological skills to find.

Why This Still Matters in 2026

AI can generate a website in seconds now. Great. It can also generate a beautiful, standards-violating pile of div soup with the confidence of a golden retriever holding a live grenade. Tools get faster; fundamentals stay the same. Browsers change. Frameworks come and go. Semantic, accessible, valid markup is still how you build sites that work for real people on real devices in the real world.

If you hire someone to build your business site, ask what standards they follow. If they stare blankly and say "it looks fine on my laptop," slowly back away while maintaining eye contact. Then call someone who knows what a <main> element is for.

I'm off to validate another page and pretend I'm doing it for fun, not because I have standards now and they have me. My dog approves of this lifestyle. My validator does not approve of typos, which is why I proofread twice.

Photos in this post are from Unsplash (free to use).

So I finally sat down to make my own website practice what it preaches. Accessibility, semantic HTML, SEO-friendly markup — I talk about all of that on my services page. But when I actually ran a standards check on my local Apache setup? Oh boy. It was like hiring a building inspector for a house you built yourself and hearing them tap the walls going, "Hmm. Interesting choices."

The good news: my PHP include setup — header.php, navbar.php, content.php, footer.php — is a solid pattern. One shell, swap the middle. Very "reusable template files," very hand-coded, very me. The bad news: the HTML inside those includes had issues. Wrong ARIA roles, duplicate <h1> tags, inline styles everywhere, and a contact modal that only worked on the homepage because the JavaScript lived in one file instead of a shared script. Classic spaghetti — except the noodles were spread across four PHP files.

Apache Had Its Own Opinion

Before I could even validate anything, Apache decided to throw a 403 at me. Why? Because my DocumentRoot still pointed at a testing/ folder I had already deleted. So localhost was basically serving an error page while my real site sat in /srv/http like a patient dog waiting to be let inside.

Arch Linux, as always, was helpful in the most unhelpful way: technically correct, emotionally devastating. One line in httpd.conf, one systemctl reload httpd, and suddenly the site loaded. I celebrated for approximately eleven seconds before the HTML validator reported 111 errors.

Fixing the Markup (Without Crying)

We cleaned up a lot. Swapped a misused role="contentinfo" for a proper <main> landmark. Moved inline styles into styles.css. Fixed form fields to use type="email" and type="tel" instead of plain text inputs pretending to be fancy. Pulled the contact slideout into its own contact-modal.php include and shared the open/close logic in scripts.js so the nav "contact us" link works on every page.

• Semantic landmarks: <header>, <nav>, <main>, <footer>
• Keyboard focus styles for people who tab through links (like civilized humans)
• A shared contact modal with role="dialog" and Escape-to-close
• Zero validator errors across the main pages when we were done locally

I also set up restic backups and a sync workflow between ~/Websites and /srv/http, because I have learned — painfully — that "I'll remember where everything is" is not a backup strategy.

FileZilla: My Other Arch Nemesis

Feeling confident, I opened FileZilla to upload the fixed files to my live host. Everything went great until I realized I had accidentally moved the entire site into the contact/ folder. Not a contact page. Not the contact form. The whole dang website, nested like a matryoshka doll that nobody asked for.

Locally, /srv/http/ was empty except for a contact/ directory containing... well, everything. index.php, blog/, css/, the works. It was like putting your entire house inside the mailbox and wondering why mail stopped arriving.

A quick restore from ~/Websites, an FTP deploy script, and we were back in business. Moral of the story: left pane is local, right pane is remote, and the FTP root is / — not /contact/. Write that on a sticky note. Tattoo it on your arm. Whatever it takes.

The PHP 7.4 Plot Twist

Localhost worked beautifully. The contact slideout slid. The form appeared. Life was good. Then I checked the live site and — button only. No overlay. No form. Just a button staring back at me like a prop on a movie set with no wall behind it.

The culprit? I used str_starts_with() in contact-modal.php to skip the modal on the contact and services pages. That function exists in PHP 8+. My live host runs PHP 7.4. So the footer include fatally errored, the modal HTML never rendered, and the button had nothing to open.

One line change — strpos($requestUri, '/contact') === 0 — and it worked everywhere. Local dev on PHP 8.5, production on PHP 7.4. Same files, different universe. I now respect the phrase "works on my machine" on a spiritual level.

What I'm Taking Away From This

The PHP include pattern is staying. It's simple, maintainable, and very much in the spirit of hand-coded sites. But standards compliance is not a one-time chore — it's part of the craft. And deploying to a live server adds a whole other layer: PHP version differences, FTP paths, and the eternal question of "wait, which folder am I in?"

Next time I'll test the live site immediately after upload, keep my working copy in ~/Websites for FTP convenience, and maybe — maybe — double-check the remote directory before clicking upload. But where's the fun in that?

Now if you'll excuse me, I'm going to go pet my dog and pretend I never saw a validator report with triple-digit errors. The site works. The modal slides. The backups run. That's a Tuesday well spent on Arch Linux.

Photos in this post are from Unsplash (free to use).

Ah, the thrill of web development on Arch Linux. It's like running a marathon in a maze, blindfolded, and occasionally being chased by a bear. And that bear is Apache Web Server.

When I first installed Arch Linux, I knew I was signing up for a bit of a challenge. But hey, it’s Arch! It’s lightweight, fast, and endlessly customizable! That’s what I kept telling myself as I dove into the deep end of the Linux pool. Little did I know that getting a web development environment running on this thing would be like trying to teach a cat to swim.

Step 1: Installing Apache – Piece of Cake, Right?

Arch Linux: You want to install Apache? No problem, just run sudo pacman -S apache.

Me: "Wow, this is going so smoothly. I wonder why people say Arch is hard?"

Five minutes later...

Apache: "Ah, you installed me? Good. Now spend the next two hours configuring me."

Step 2: Configuring Apache – The Real Fun Begins

Now, if you thought the installation was easy, you're in for a treat! The real "joy" starts when you try to configure Apache. Oh, you want to change the default document root to your project folder? Of course, it's just a simple change in the /etc/httpd/conf/httpd.conf file. Except...

• You miss one semicolon, and Apache throws a tantrum.
• You change one directory path, and suddenly it refuses to start.
• You forget to enable the service at boot, and it plays hide-and-seek after every restart.

It’s like a highly temperamental artist – "You don’t understand my vision!" – while you just want to serve some HTML.

Step 3: Permissions – Welcome to Your New Nightmare

Ah, permissions. If there’s one thing I’ve learned, it’s that Arch Linux and Apache are both very particular about who’s allowed to do what. After setting up my development environment, I quickly realized that getting permissions right is more confusing than trying to explain recursion to a toddler.

"Why can’t Apache read my files?"

"Oh, because they’re in a folder owned by root? Sure, let me just—oh, wait, now nobody can read them."

At this point, I've chanted sudo chown so many times that I feel like I'm summoning some kind of permissions demon. And then there's chmod, which I'm pretty sure is short for "Choose How Much Of Despair."

Step 4: The Firewall – Apache's Bouncer

Let’s not forget the firewall. Arch Linux is very protective. You’ll try to load your site in the browser, only to be greeted by a very polite error message: "This site can't be reached."

Apache is running, I’ve configured it, I’ve set up my virtual hosts – but the firewall is like, "Nope, not on my watch!" It’s like Apache is the VIP guest, but the firewall forgot to check the list. So, after a good hour of opening ports, reloading services, and running ufw allow 80/tcp, I finally get it working.

Only to realize I blocked all my other services. Good job, me.

Step 5: Virtual Hosts – Let’s Make This Interesting

By the time I got to virtual hosts, I thought I was a pro. "How hard can it be?"

Since redirecting my SEO tips pages to the new sub domain (see previous post…), I was having problems with the redirection. I even asked the PHP/Apache forum I belong to for help. Members there, one in particular, helped me with the Apache .htaccess code.

After several attempts to make the redirection work, it seems that we all were stumped! Nothing did the trick! Well, thanks to my great new web host, it was determined that the .htaccess file was being edited at the new sub domain root, and not the original sub domain root!

I've moved all my blogging of SEO tips and news to my newest site, search engine optimization tips. Funny thing about that is, I did have a PR3 on that sub-domain, but since my move to a new web host, the sub domain has lost its PR!

Well, it's not the web host's fault, and it's not the actual move of the content to a new server either… Let me put it this way, I've had to create an Apache redirect 301 from the old site to the new SEO site. Why? Well…

Here I go thinking again!

I've targeted "search engine optimization tips" as my anchor text. But, my original URL was not search-engine-optimization-tips, but search-engine-optimization. Notice the keyword tips? Google (and other SEs) will hold a result for any keyword or keyphrase found in an actual URL higher in importance than results found in simple anchor text. So I wanted to capitalize on my unlimited sub-domain account with my new hosting provider.

So, even with the 301 redirect, my site drops its PR3 due to it being a "new" site in Google's eyes.

My site ranks in 27th place in SERPs for allintitle, while I'm at 6th and 7th for allintitle for the keyphrase web design standards.

There has been a lot of talk regarding SERPs and off-page SEO. It seems that Google has changed their algorithm to thwart "black-hat" techniques — this is nothing new — but there's a difference. Now, sites are being penalized for linking/being linked from "link-farm" type of sites.

A few things have changed since my last entry. I've completely redone the SEO page. To fully utilize SEO skills, I've created a sub domain for search engine optimization. By doing this, I'm using the keyword-in-domain-name technique.

I've also added a few tips to the web accessibility pages. And yes, I've updated my sitemap to reflect the additional pages.

Hurricane Katrina

On a sober note, let's pray for the victims of the devastating hurricane that hit our Southern States! I pray that people will open up to God, and will accept Jesus into their hearts…

Wow, it's been a long time since I posted here! I've made some recent changes. One change I have made is to gear this site away from selling my web design services (of which I have made no money from) and my tech support services. It is now totally geared to Web Standards, and Accessibility. Why, you ask? Well, since I was not charging anyway for my services, I wanted to (re)direct the theme to web tech stuff.

On a sad note, I had to give up my dogs this week! The picture I have of Star (bottom dog) will stay! Yes, my landlord decided that I had too many. Well, I did end up with 5 dogs! Three of them were puppies. I came upon them as, "Wow, you mean I can rescue it?"

So, I had two Boxer/Rottweiler puppies, and one (my favorite!!!!!) German Shepherd.

Well, I bit the bullet and setup Dean Edwards' IE7 fix on my web host's Apache server. Now, IE behaves like standards-compliant browsers like Firefox, Mozilla 1.7.5, and Opera. There were a few bugs that had to be ironed out, but Dean put a lot of work into them, and so far, so good!

On a side note, I have officially titled myself "Standards Evangelist". So, not only am I an Evangelist for Christ, I also try to spread the word on web standards and accessibility.

Oh yeah, one more thing. I have decided to reveal the "skipper" menu. This "skipper", or "jump to" menu allows users who have CSS turned off (many reasons!), or people who have a sight impairment of some degree, and use screen readers to surf the web, the ability to skip to the areas they prefer to read — or hear.

The technique I was using to hide the skipper div was pretty simple:

• I use an unordered list to contain the links.
• I then used my external CSS file to "hide" it: #skipper {width: 0; height: 0; overflow: hidden; text-indent: -9000px;}
• Now, this is what I am doing: #skipper {position: absolute; top: 1px; left: 1px; font-size: .7em; margin: 0; padding: 0;}

Big news! This weblog is now served as XHTML 1.1. If you're viewing this site with IE, then you'll get XHTML 1.0. But, if you're using a good browser, such as Mozilla Firefox, or Opera, you'll get the benefits of XHTML 1.1.

And guess what? The entry titled "Google, where are you?" on December 29th, '04, is dynamically placed within the XHTML of this page with PHP.

Really Simple Syndication, or RSS as it is acronymically known, is a hot tool to use on any website. I will be experimenting with it on this site very soon!

FIR

I have decided to add the updated FIR technique to this site. This will allow me to add some cool graphical headings, without sacrificing accessibility. I am very excited about that.

Google, Where Are You — Revisited — Way to Go MSN!

Google still has my site within its "sandbox"! I cannot wait for my site to break out of it. MSN, however has formally released its beta search engine. It is now the default engine for msn.com.

The great news about this is simple… I rank at the top (3rd place/4th place!) of MSN for "web design standards" and "small business web site design".

Update: MSN has implemented their beta search engine! My site ranks 3rd for the highly competitive key phrase "web design standards" and 4th for "small business web site design".

I just cannot get over Google and its "sandbox"! Let me explain… Google seems — and this is just not theory anymore, but tested and confirmed — hides a new site, with a new domain name, from its SERPs for quite a few months.

Seem too strange to believe? I thought so too. Then, as I have been working on this site, I have noticed my SERPs dropping drastically! I had a top 5 position on Google for "web design standards" before I acquired my FQDN. Now, I do not even rank for that phrase in Google's top 500!

Now for the good news! I do have the top 3 position on MSN's beta search engine, as well as 4th place, for my keywords:

• web design standards — top 3 on MSN beta
• small business website design — top 4 position on MSN beta

Hopefully you will like the new color scheme I have chosen for this site. I also changed the masthead logo. I used to have a close-up of a German Shepherd's face, but decided to go with a cleaner look.

Christmas is almost here! I cannot wait to celebrate the birth of Jesus Christ!

I have moved the website templates that I have created into a templates sub-folder. I will be adding an index page to the folder, and branch out the templates from that page. Right now, my sales.html page is the starting point for them.

I have had a great Thanksgiving holiday! Speaking of re-design (ok, not making sense, but…) I have redone my Web Design Tips Tricks page. I have split the page itself into one main page, with three sub, or support, pages. They are the accessibility, SEO, and XHTML/CSS pages.

The theory behind this is called the Search Engine Optimization Pyramid.

Re-redesign — is that even a word? I guess it is now… I have redesigned most of the CSS for this site. I have kept the color scheme, but have added #9a440c. I have taken out the sidebar navigation borders, which added a button look to the links. I want a more minimalist look, and believe this is a start.

With the help of dyer85, I am going to use PHP to serve my pages in XHTML 1.1 — and 1.0 Strict for non-compliant browsers (MS IE). I'll keep a running log of the process.

A bit of other news, my site has the following Google PageRank:

• web design standards (index) — PR3
• Small Business Support (/support/) — PR2
• Portfolio / Sales — PR3
• Weblog — N/A
• Web Design Tips Tricks — PR2
• Anti-Virus tips and Info — PR2
• News Articles — PR1
• GAWDs launch — PR2

My anniversary is at the end of this month. I cannot believe it has been 5 years since I got married to my beautiful wife!

After some good advice-links from my good friend Bill Creswell, I have redone, well, torn apart is more like it, the homepage to this site. It now features "everyday talk" — kind of like these blog entries. I want to convey a more personal touch to my web design, and give some info in the process.

My second attempt at PHP! I built a simple contact form to test form handling — name, email, URL, subject, and message fields. It was my first real step into server-side scripting on FierceStreet Networks, and it opened the door to everything that came after: dynamic includes, content negotiation for XHTML 1.1, and eventually this very site.