GUI HTML Editors and Mobile Websites

Lesson purpose

Lesson 9 shifts from hand-coding to tools and delivery. Students use a GUI (WYSIWYG) HTML editor to build a résumé page, judge the code it produces against HTML5 and accessibility standards, validate it, and learn how professionals preview, test, and publish a site with FTP. The second half turns to mobile users: designing and testing for small screens, choosing between mobile apps, dedicated mobile sites, and responsive design, and recognizing the Web technologies — Ajax, cloud-delivered applications, third-party gadgets, feeds, podcasts, and streaming — that make the browser an application platform.

Big idea for the day: a GUI editor speeds up the work, but the developer is still responsible for the code. Knowing HTML is what lets you fix, validate, and modernize what the tool generates.

Learning objectives

By the end of the lesson, students should be able to:

CIW 2.1.9: Add third-party applications to a Webpage (for example, gadgets).
CIW 2.1.10: Identify how a Web browser can become an application delivery platform, including its strengths and weaknesses.
CIW 2.7.7: Identify the challenges of designing Websites for mobile devices (smartphones, tablets, game consoles).
CIW 2.11.1: Evaluate a GUI HTML editor using the W3C Authoring Tool Accessibility Guidelines.
CIW 2.11.2: Validate HTML code.
CIW 2.11.3: Use font and page appearance options in a GUI HTML editor.
CIW 2.11.4: View source code and preview pages in a browser.
CIW 2.11.5: Create HTML tables using a GUI HTML editor.
CIW 2.11.6: Publish (upload) pages and sites to a Web server.
CIW 2.11.7: Evaluate HTML editors that can edit files on mobile devices and cloud services.
CIW 2.11.8: Distinguish between mobile apps and mobile Websites.
CIW 2.17.2: Define Web server technologies, including Ajax.
CIW 2.21.5: Identify ways to create pages for traditional and mobile browsers (valid code, appropriate resolutions, supported interpreters, extensive user testing).

1. What a GUI HTML editor is

A GUI HTML editor, also called a WYSIWYG (“What You See Is What You Get,” pronounced wiz-ee-wig) editor, lets you design a page by clicking and typing much as in a word processor while the program writes the HTML. Instructor note: make sure students understand that a WYSIWYG editor provides a click-and-select interface and generates code automatically.

Past popular WYSIWYG editors include Adobe Dreamweaver, Microsoft Expression Web, and KompoZer. The book notes that only Dreamweaver still receives updates; Expression Web and KompoZer still run but have not been updated in years.
The labs use KompoZer, a free editor designed to follow W3C standards and simpler than commercial tools. Even so, always check an editor’s output with the W3C Markup Validation Service.

The GUI HTML Editors video previews the lesson: what WYSIWYG means, common features, the Authoring Tool Accessibility Guidelines, advantages and disadvantages, validation and the <!DOCTYPE>, publishing with FTP, and testing on a staging server first.

2. Types of GUI editors

Page editors — create individual pages with a mouse and toolbar; the book lists Mozilla SeaMonkey (Composer) along with Visual Studio Code, NetBeans, Eclipse, and IntelliJ IDEA.
Site management editors — create pages and manage an entire site, letting teams design, build, and maintain sites and Internet applications together, with task automation and integration with other programs. Examples: Adobe Dreamweaver, Microsoft Expression Web, KompoZer.
Content management systems — the book also groups WordPress and Drupal here: installed on a server (often in one click from a host), they let people build full sites with predefined styles, e-commerce, and navigation in hours without coding.

Clarification for students: VS Code, NetBeans, Eclipse, and IntelliJ are really code editors/IDEs — they show and edit source code (often with a live preview) rather than offering true WYSIWYG design. Instructor note from the book: Dreamweaver is similar to Expression Web but more advanced.

3. Common GUI editor features

Names differ by product, but most GUI editors offer:

Templates and wizards — build custom pages quickly from a series of choices.
Text style options — fonts, sizes, colors, alignment, bold, italics. Caution: visitors may not have every font installed, so choose fonts carefully.
Icon bars — graphic buttons for menu functions.
Image features — insert images easily.
Hyperlink features — link to pages and files on your site or the Web.
Import HTML pages — open pages from the Web and, when permitted, save them and their images locally.
Table creation — insert tables to arrange data.
Spelling check — useful, but it cannot ensure the page sends the right message; content still needs a knowledgeable editor.
Publish features — copy files from the local drive to the Web server with a click.

4. W3C Authoring Tool Accessibility Guidelines (ATAG)

ATAG judges whether an editor is usable by developers with disabilities and whether it helps produce accessible pages. It serves two overlapping groups: authors with disabilities (the tool’s interface must be accessible) and end users with disabilities (the tool must guide authors toward accessible content that meets WCAG). The book’s Table 9-1 summarizes the current recommendation (ATAG 2.0), which has two parts:

Part A — Make the authoring tool’s user interface accessible

A.1 Follow applicable accessibility guidelines.
A.2 Editing views must be perceivable (for example, alternative content and larger fonts).
A.3 Editing views must be operable (for example, full keyboard access).
A.4 Editing views must be understandable (help authors avoid and correct mistakes; document the interface).

Part B — Support the production of accessible content

B.1 Fully automatic processes must produce accessible content.
B.2 Authors must be supported in producing accessible content (pre-authored content, accessibility tools, forums, FAQs).
B.3 Authors must be supported in improving existing content.
B.4 Tools must promote and integrate their accessibility features.

(The book’s text refers to “seven points,” which comes from the older ATAG 1.0; the table shows the current two-part structure.)

Keep in mind when designing: some users cannot use a mouse, so make sure every link can be reached with the Tab key; some users need larger text.

5. Building a page with a GUI editor

Instructor note: GUI editors have been slow to adopt HTML5 and CSS3 — for example, deciding automatically how to name and apply CSS classes is hard. Discuss whether that could be automated.

The labs build a résumé page for an internship with a technology training company, using KompoZer and an HTML5 template. Features practiced: headings, alignment, bold, font and background color, horizontal rules, bulleted and numbered lists, external links, images with alternative text, and a table. Undo with Ctrl+Z and redo with Ctrl+Y; always save before previewing.

Discussion prompts from the labs:

What color combinations best suit a résumé? Would you change the look for different employers or positions?
Graphics should be used sparingly; a horizontal rule adds subtle emphasis.
What information fits a numbered list, and what fits bullets?
Link only to professional, reputable, relevant sites.
Claim only skills and credentials you actually have.

Instructor note: because open-source HTML5 GUI editors are scarce, the course uses an HTML 4.01-era editor and then upgrades its output to HTML5.

6. Text editors vs. GUI editors

Most developers use both: a GUI editor to build most of a site quickly and a text editor (many GUI editors include one) for scripts and fine control. Instructor note: students who enjoy hand-coding may enjoy programming careers — JavaScript is a good next step.

	Text editors (Notepad++, WordPad, Vi, Emacs)	GUI editors (KompoZer, SeaMonkey Composer, Dreamweaver, Expression Web)
Advantages	Required for learning scripting and useful for forms; lets you fix or improve any editor’s code; teaches HTML fundamentals and lets you update to the latest standards; you can add comments; no extra tags, so pages are cleaner and download faster	Easy to use with no special technical background; writes code for you so pages are built quickly; most allow manual code editing; lets you focus on appearance
Drawbacks	Typing code is time-consuming, especially keeping up with W3C changes; manual entry may be hard for some people with disabilities; more effort than a simple page needs	May change or ignore code you type by hand; many have not kept up with HTML, so you must upgrade to use newer tags; often generate bloated code that slows downloads; may not prompt for `alt` text or proper headings, hurting accessibility and SEO

Warning from the book: GUI editors may fail to load or may damage code with newer tags. Back up pages first, then test each change.

7. Previewing and validating

Most GUI editors make it easy to preview a page in one or more browsers, view the source code, and validate — with a built-in validator or the W3C Markup Validation Service. Preview in several browsers, not just one.

The `<!DOCTYPE>` and validation

A validator reads the <!DOCTYPE> first and checks the page against that standard. So the same code can pass under one DOCTYPE and fail under another. Example: a page written and validated as HTML 4.01 Transitional will likely fail after a teammate changes its DOCTYPE to HTML5. The fix is either to update the code to HTML5 or to restore the old DOCTYPE — changing the declaration alone does not upgrade the page.

<!DOCTYPE html>

The short HTML5 DOCTYPE is the one students should use.

Some GUI editors include accessibility-checking features in addition to validation.

8. Publishing a site

Publishing is the final step. Options include an editor’s Publish feature or an FTP client such as FileZilla. FTP (File Transfer Protocol) transfers files of any size between computers without corruption or alteration; it needs an FTP client to send and an FTP server to receive. A Web server can receive files by FTP only if it is also running FTP. First decide where the site will be hosted — a local ISP, a large hosting company, or a cloud provider.

Security note: plain FTP sends usernames and passwords unencrypted. Use FTPS (FTP over TLS, as the optional lab does) or SFTP.

Test (staging) servers

Professionals publish to a test server (also called a staging server) before the live production server to:

Confirm the server can process CGI and database requests.
Find and fix dead links.
Let the team and stakeholders preview the site — expect changes before the “final” code is ready.

The test server should match production as closely as possible: the same operating system version, the same Web server software and version (Apache 2.2 is not a true test for Apache 2.4), and the same server-side interpreter version (for example, the same PHP version).

Publishing with FileZilla

KompoZer’s lab workflow uses FileZilla: open File → Site Manager, enter the server name (or IP address), login credentials, and the folder on the remote server where files belong, then connect and transfer.

9. Designing for mobile devices

Mobile use dominates browsing. The book cites that by 2019 about 96% of Americans used a mobile phone (86% smartphones), 72% of U.S. browsing in 2018 happened on mobile devices, and 72% of global Internet users were expected to be mobile-only by 2025. Current figures change quickly; the takeaway is that most visitors may be on phones.

Three priorities:

Keep pages simple and uncluttered — small screens and possibly slower connections; use white space.
Prioritize content — mobile users usually want something specific, such as the nearest store.
Optimize for smaller screens — make the site readable for most mobile users.

Development guidelines:

Use clean, valid markup and CSS3 to separate presentation from content.
Always use alt text; images may be hard to see or disabled, and pages without it fail HTML5 validation.
Label form fields clearly.
Use <h1> through <h4> to structure the page; smaller headings are hard to read on phones.
Reduce margins and padding to gain usable space.
Provide easy navigation and readable text.

The Designing Pages for Mobile Devices video reviews these points and introduces the app-versus-mobile-site question.

Optimizing for mobile viewing

The book names three elements: compatibility, design, and size. If many users are mobile, consider designing mobile-first.

Compatibility — content must work on the devices people use; test on many. Outdated technology such as Flash will not work.
Design — size elements in percentages rather than fixed pixels (width: 90% instead of width: 400px). Users tap with fingers, so links and buttons must be large enough to hit.
Size — keep pages and media small; compress, and consider serving more compressed media to mobile users.

Modern essentials to add: every responsive page needs the viewport meta tag, and CSS media queries adjust the layout for different widths.

<meta name="viewport" content="width=device-width, initial-scale=1">

Testing a mobile site

Test on as many real devices as possible and validate to HTML5, which was designed partly to support mobile devices. The book lists W3C mobileOK Checker, Ready.mobi, Responsinator, and Google’s Mobile-Friendly Test. Currency note: the W3C and Google tools have been retired; today use the browser’s device mode in its developer tools and Lighthouse audits, along with real phones and tablets.

10. Mobile apps vs. dedicated mobile sites vs. responsive design

Mobile app — a stand-alone application downloaded from a store (Apple’s App Store, Google Play) and built for a specific mobile operating system; it can run faster and needs no browser.
Dedicated mobile Website — a separate, usually stripped-down version of the regular site, often at its own address.
Responsive design Website — one site that adapts to every screen size and resolution.

Advantages of mobile and responsive sites over apps: cross-platform — they work on nearly any device and browser with no download or install. Responsive design also has an SEO advantage: separate mobile and desktop sites can split traffic and rank lower than one responsive site.

The uCorp site in the book’s iPad and iPhone simulators is responsive: the same URL shows key text without supplementary pictures and switches to touch-friendly navigation.

Conclusion from the book: apps and Websites will coexist, and many companies offer both; responsive design is the modern approach and is gradually replacing separate mobile sites. With HTML5, CSS3, and JavaScript now used to build apps too, the line between them is fading.

Instructor note: have students load sites in an online simulator or browser device mode. Do mobile versions appear automatically at the normal address, or do they need a separate mobile address? How does a site detect a mobile browser?

Introduction to mobile app development

Building apps differs from building pages: apps use full programming languages and an Integrated Development Environment (IDE). The two major platforms are iOS (iPhone, iPad) and Android. The book says iOS apps are written in Objective-C with the Cocoa frameworks in Xcode, and Android apps mostly in Java with the Android SDK in Eclipse or NetBeans. Currency note: today Apple’s main language is Swift (still in Xcode), and Android development centers on Kotlin in Android Studio. Apple Developer and Android Developers provide free resources.

11. Modern Web technologies

The Web has shifted from static pages that users simply read to an open, collaborative platform where users create, share, and update content — social networks, video sharing, wikis, blogs, feeds, and podcasts. This shift is often called Web 2.0.

Ajax

Ajax (Asynchronous JavaScript and XML) lets Web applications behave like desktop applications by exchanging data with the server in the background and updating part of a page without reloading the whole page. It combines (X)HTML, CSS, the DOM, JavaScript, and the XMLHttpRequest API. Today the data is usually JSON rather than XML, and the newer fetch() API is common, but the idea is the same.

The browser as an application delivery platform

Cloud computing and Software as a Service (SaaS) deliver applications through the browser — the only local software needed. From the Working with Web 2.0 video:

Advantages: flexibility (one person can run a sophisticated business), scalability (the provider adds capacity as you grow), and cost reduction (fewer employees and less hardware).
Disadvantages: connectivity (no Internet, no service), speed (a slow connection slows everything), and lockout (the provider can limit access to your remotely stored data).

This connects to objective 2.11.7: many HTML editors now run in the browser or on tablets and phones, storing files in cloud services — convenient, but subject to the same connectivity and lockout risks.

Third-party applications

Third-party applications (widgets or gadgets) add features without writing them yourself, but they can slow pages and are easy to overuse. The book uses iGoogle Portal and Google Gadgets (mini-applications built with HTML and JavaScript). Currency note: Google shut down the original iGoogle in 2013; the lab’s iGoogle Portal is a separate current service, and today similar features come from embeddable widgets such as maps, calendars, and social media feeds.

Web feeds, podcasts, and streaming

Web feed — a format for delivering frequently updated content (blog posts, headlines). Users subscribe with a feed reader (aggregator) and see updates without visiting each site.
- RSS (Really Simple Syndication, also RDF Site Summary or Rich Site Summary) — version 2.0, the original and most widely accepted format.
- Atom — version 1.0, newer and more feature-rich, including metadata about each item: its name, creator, creation date, and location.
Podcast — syndicated audio or video files that subscribers download automatically through a feed; creators record MP3, Ogg Vorbis, or WAV files, publish them, and index them for RSS readers. Unlike streaming, podcasts are downloaded.
Streaming — media plays while it is transmitted and is not stored permanently, saving space and enabling live streaming to large audiences. Examples include Netflix, Hulu, YouTube, and Twitch. Streaming became practical with high-speed Internet.

Classroom application

Labs 9-1 through 9-7: Building a résumé page in KompoZer

Lab 9-1 — Create the page. Make a Promo folder on the Desktop, copy the Lesson09 files, and install KompoZer. Open Lab_9-1/html5_template.html, Save As with a page title (your name followed by “— Internet Certified”) and the file name default.html in Promo. Add your name as a centered Heading 1, then “Internet Certified and Ready to Succeed!” in bold, centered body text. Preview with the Browse button (text can be pasted from GUI_HTML_editor.txt).
Lab 9-2 — Colors. Select text and change its background color and text color (Format → Text Color); notice only the selected area changes. Save, preview, then revert to white and black. Discuss: are these commands easy to use for someone with a disability? Open the Source tab — is the code HTML 4.01, XHTML, or HTML5?
Lab 9-3 — Horizontal line. Add two blank lines and Insert → Horizontal Line, then set width 100% of window and height 1.
Lab 9-4 — Lists. Type Certifications (bold italic) and four CIW certifications as a bulleted list; then Internet Skills and five skills as a numbered list. (Instructor note: passing the first three CIW exams earns the CIW Web Foundations Associate certification.)
Lab 9-5 — External links. Link each certification to https://www.CIWcertified.com, set to open in a new window, and test the links.
Lab 9-6 — Image. Add a horizontal line, copy CIWlogo.gif into Promo, Insert → Image, enter the alternate text CIW Logo, and center it.
Lab 9-7 — Table. Insert a 2×2 table at 100% width with spacing, padding, and border of 2; make the first row header cells; place the Certifications and Internet Skills headings in the top row and the two lists in the bottom row; equalize the column widths; remove stray blank lines; and check the page in at least two browsers.

Teaching point on Lab 9-7: the table here is used to lay the page out in two columns, which contradicts Lesson 5’s rule that tables are for tabular data. Use it as a discussion: how would you rebuild this layout with CSS (for example, two <section> elements side by side with flexbox or grid)? Instructor note from the book: review how each step would be coded by hand, since students upgrade the tables to HTML5 next.

Lab 9-8: Validating GUI-generated code

Exit KompoZer and validate default.html with the W3C Markup Validation Service. Expect errors, mostly HTML 4.01 presentational attributes on the table (such as border, width, cellpadding, cellspacing) that HTML5 moves into CSS. List each error with a solution — most are fixed by moving styles to an external or inline CSS3 style sheet. Discuss what changes the code needs, how long the upgrade would take, and the benefits and drawbacks of using the GUI editor. (Instructor note: have students follow the lab steps closely so their pages, and errors, are similar.)

Lab 9-9: Personalizing a page with third-party gadgets

In iGoogle Portal, sign in or create an account, explore the default gadgets (stock market, weather, Wikipedia, Google links), add gadgets and apply a theme, set the Weather gadget to your city, and open Google Maps from the Links gadget to try search, Traffic, Satellite, dragging, and zooming. Privacy reminder: creating accounts shares personal data; students may use an existing Google account or skip sign-in if uncomfortable.

Optional Lab 9-1: Publishing to a remote server

Install FileZilla Client (the book’s first step says “FileZilla Server,” but the client is what uploads files). In Site Manager, create a new site: protocol FTP, the host from the instructor, encryption Require explicit FTP over TLS, logon type Normal, the username and password provided, and Passive transfer mode. Connect, open the server’s /public_html/ folder, drag files from Local Site to Remote Site, and view the page at its domain and path.

In-book exercises

Exercise 9-1: Reviewing the key features of a GUI editor — after Section 4.
Exercise 9-2: Developing Webpages for viewing on mobile devices — after Section 9.
Exercise 9-3: Advanced Web technologies — after Section 11.

Case study: The Best GUI Editor

Patrick needs a site for his new small company quickly. He wants WYSIWYG drag-and-drop editing (he does not know HTML or CSS), reliable, browser-compatible code, and support for both Mac and Windows. He compares four vendors on compliance, accessibility, and flexibility and chooses KompoZer — free, open source, donation-supported, with more features than he needs. It lacks built-in validation, so he plans to use free third-party validators.

Discussion prompts and target answers:

Most important features? Quality of output code, ease of use, a wide set of editing tools, support for all HTML elements, and advanced features such as forms, themes, and styles.
Paid vs. free editors? Licensed products usually include technical support contracts and scheduled updates with bug fixes and features. Open-source tools rely on community forums, may update more or less often, and sometimes accept fixes from the community.

Critical-thinking follow-up: given the book’s own note that KompoZer is no longer updated, is it still a good choice for “reliable content” today? What current tools meet Patrick’s needs?

Application project

How could a GUI editor help expand your organization’s intranet or public site, and could employees with little HTML experience contribute?
View your résumé page in two different browsers (the book names Firefox and Internet Explorer; use two current browsers). Does the table look the same? How would you change the code so it does?
When time permits, build a complete résumé page and, after earning your certification, post it to a job site or your own site.

Common misconceptions

“WYSIWYG means I don’t need to know HTML.” You need HTML to fix, validate, and modernize what the editor writes.
“Code from a GUI editor is automatically valid.” Many editors produce outdated or bloated code; always validate.
“Changing the DOCTYPE upgrades the page.” The validator judges the code against the declared standard; the code itself must change.
“The test server can be any server.” It must match production’s operating system, server software, and interpreter versions.
“FTP is secure.” Plain FTP sends passwords in cleartext; use FTPS or SFTP.
“Mobile users just need smaller images.” Mobile design means simplified content, touch-friendly targets, percentage-based layouts, and testing on real devices.
“A mobile site and a mobile app are the same.” An app is installed for one platform; a mobile or responsive site runs in any browser.
“Ajax reloads the page faster.” Ajax avoids reloading the page by updating only part of it.
“Streaming and podcasts are the same.” Podcasts are downloaded through feeds; streaming plays while transmitting.

Key terms

WYSIWYG — an editing view that shows a page as it will appear in the browser.
GUI HTML editor — a program that generates HTML from a graphical interface; page editors vs. site management editors.
ATAG — the W3C Authoring Tool Accessibility Guidelines for accessible editors and accessible output.
Inline image — an image rendered in a Webpage.
FTP — the protocol for transferring files between computers without corruption or alteration.
Test (staging) server — a server that mirrors production for checking a site before launch.
Responsive design — one site that adapts to all screen sizes.
Mobile app — a stand-alone application for a specific mobile operating system.
Web 2.0 — the trend toward information sharing and collaboration on the Web.
Ajax / XMLHttpRequest — techniques and the API for exchanging data with a server without reloading the page.
Web feed (RSS, Atom) — a format for delivering frequently updated content to subscribers.
Podcast — audio or video files distributed through Web feeds.
Streaming — media that plays as it is transmitted.

Lesson summary

GUI (WYSIWYG) editors write HTML for you through templates, text styles, icon bars, images, links, tables, spell-checking, and publishing tools; site management editors and CMSs add whole-site management.
Evaluate editors with ATAG: an accessible interface (perceivable, operable, understandable) and support for producing accessible content.
Text editors give control and clean code; GUI editors give speed — use both, and always validate. The <!DOCTYPE> tells the validator which standard to apply.
Publish with an editor’s publishing tool or an FTP client, using encrypted FTPS/SFTP, and test first on a staging server that matches production.
Design for mobile with simple, prioritized content, percentage-based sizing, touch-friendly targets, small media, the viewport meta tag, and testing on many devices.
Mobile apps, dedicated mobile sites, and responsive sites coexist; responsive design is cross-platform and better for SEO.
The browser is now an application platform (cloud/SaaS, Ajax), with trade-offs in connectivity, speed, and lockout; gadgets, feeds, podcasts, and streaming extend what pages deliver.

Next lesson: Website Development for Business — branding, e-commerce, Internet marketing and SEO, accessibility standards, and back-end considerations.