S.P.A.R.K. with AI — Development Dialog

The Font Awesome Chat Log

How the Font Awesome tutorial was built — the real conversation,
annotated so you can see the S.P.A.R.K. method in action.

For Students — How to Read This Page

What you are about to read is the real, unedited conversation that produced the Font Awesome tutorial. Nothing was scripted in advance. The teacher typed prompts; Copilot responded; pages got built.

Watch for the coloured S.P.A.R.K. banners that appear between messages. They label each stage of the method so you can see why a particular prompt was asked at a particular moment.

Also notice that Copilot plays two roles at once in this session: developer (writing code and files) and trainer (explaining design decisions and trade-offs). A well-crafted prompt can pull both modes simultaneously — that is a skill worth practicing.

Exchange 1 of 4

🎯

S — Set Goal The teacher arrives with a clearly formed goal: build a training document for novices on Font Awesome, link it to the S.P.A.R.K. section of the site, and get an explanation of why the tool was chosen in the first place. Notice there are actually three goals bundled in one prompt — a build task, a linking task, and a “why” question. This is efficient when you already have clear intent.

💬

P — Prompt The prompt below is effective for several reasons: it provides context (“in the older TNT area I used Noun Project”), names the target audience (novices), specifies the deliverable (an HTML/CSS/Bootstrap page), names the exact location it should be linked to (S.P.A.R.K. section of explore.html), and ends with a direct accountability question: “Why did you use it by the way?” That last sentence is crucial — it forces the AI to justify its choices rather than just deliver output.

klp (Teacher / Developer)

In the older TNT area, I supplied artwork from ‘The Noun Project’ and was pleased with those results. In our upgrade, you use those types of files but also use icons from ‘Font Awesome’. Both are referenced in our resources page. I know Font Awesome has free and icons for a charge type artwork. Can you create a document, howToUseFontAwesome.html using HTML/CSS/Bootstrap5 and JS if necessary, and link it to our ‘S.P.A.R.K’ area in the explore.html page? I’d like to train novices how to use FA, search for ‘free’ icons so they can utilize that resource effectively. Why did you use it by the way?

🔍

A — Analyze Response Copilot’s response had two parts: it silently acted (built the tutorial file and linked it) and then explained (answered the “why” question). When analyzing a Copilot response, ask yourself:

Did it do what I asked? (yes — built the file, updated explore.html)
Did it explain its reasoning? (yes — defended FA vs Noun Project)
Are the trade-offs honest? (yes — acknowledged Noun Project is still used for artwork)
Is there anything missing or wrong? (check the file yourself before publishing)

GitHub Copilot

[Built FontAwesomeTNT2026-06-12-Stg1/howToUseFontAwesome.html — a 10-section tutorial covering CDN loading, free vs Pro tiers, searching for free icons, the <i> tag pattern, sizing, coloring, in-context usage, an interactive live demo, and a quick-reference card — then added the page to the S.P.A.R.K. card and offcanvas panel in explore.html.]

Why Font Awesome?

The Noun Project is excellent for unique, illustration-quality artwork — TNT still uses it for hero images and mascots. But for interface icons (buttons, nav labels, status indicators), it has real friction:

One HTTP request per file (slows page load)
PNG icons blur when scaled up
Recoloring requires editing the file or writing complex CSS filters
Managing dozens of image files is tedious

Font Awesome solves all of that in one CDN link. Every icon is vector-sharp at any size, recolors with a single color: declaration, and integrates naturally with Bootstrap’s utility classes. It’s also the industry standard novices will encounter on almost every professional site they study — so learning it here is directly transferable.

Both tools have a place: use Font Awesome for UI elements, use Noun Project when you need specific illustration or custom artwork.

Exchange 2 of 4

🔄

R — Refine After getting a working tutorial, the teacher zooms out and asks a pedagogical question: how should this be used to teach the S.P.A.R.K. method itself? This is a refinement prompt — not fixing something broken, but expanding the value of what was already built. Good refinement prompts often start with “How should we…” or “What do you suggest for…” rather than “Fix this.”

klp (Teacher / Developer)

This is a ‘S.P.A.R.K’ app, so as such, I like to use it to train novices how to use AI well in CS. In the past, I’ve attached a ‘chatlog’ to these apps so students can see our dialog modeled, and learn how to do this ‘vibe code’ development themselves. What do you suggest for integrating our chat about Font Awesome into this app, for training purposes?

GitHub Copilot

There are a few approaches, each with trade-offs:

Option A — Separate faChatlog.html page (recommended)
A dedicated page linked from the tutorial with a prominent button. The chatlog shows the actual conversation formatted as styled message bubbles (User / Copilot), with S.P.A.R.K. annotation labels at key moments.

Option B — Collapsible section at the bottom of the tutorial
Lower friction (one file), but less visual impact and harder to reference on its own.

Option C — Side-by-side tab layout
Two tabs: “Tutorial” and “Chat Log.” Clean, but Bootstrap tabs on a long page get confusing on mobile.

Recommendation: Option A. The tutorial teaches how to use FA. The chatlog teaches how to work with AI. These are two distinct learning goals — mixing them in one page competes for the student’s attention. A separate page keeps both documents focused, and the chatlog can be linked directly from the explore.html offcanvas panel as a second entry alongside the tutorial.

Exchange 3 of 4

🔄

R — Refine (continued) — The Decision The teacher evaluates the options and makes a clear decision: build Option A, use the full conversation, and include one extra instruction (“use this comment in the chatlog”). Notice how the prompt is short and decisive. At this stage, long prompts are unnecessary — the context has already been established in the prior exchanges. The AI carries that context forward automatically.

klp (Teacher / Developer)

Let’s build it and use our entire dialog about Font Awesome: my prompt, your defense of why using it, the works. I want students to see how you can act as a developer and as a trainer. Use this comment in the chatlog as well.

📚

K — Know Copilot’s response: this page. The cycle closes here. Let’s name what was learned in this session:

Tool knowledge: Font Awesome vs Noun Project — when to use each, how FA works technically
Workflow knowledge: How a real S.P.A.R.K. session unfolds — goal setting, prompting, analyzing, refining
AI literacy: Copilot can play developer and trainer simultaneously when prompted for both
Design decision knowledge: Why CDN over local files, why vector over raster, why separation of concerns in the page architecture
Meta-knowledge: The chatlog itself is a learning artifact — the process of building is as valuable as the product

GitHub Copilot

[Built this page — faChatlog.html — formatting the full conversation as annotated S.P.A.R.K. chat bubbles, then linked it from howToUseFontAwesome.html and the S.P.A.R.K. offcanvas in explore.html.]

The teacher’s note — “I want students to see how you can act as a developer and as a trainer” — is itself a teachable prompt strategy. It explicitly names the two roles expected of the AI, which produces a richer response than asking for code alone. When you prompt an AI to explain while it builds, you get a collaborator instead of a vending machine.

Exchange 4 of 4

🔍

A — Analyze (Review) — Catching What AI Missed This exchange happens after the pages were built and reviewed. The teacher compared the new FA pages against the rest of the site and noticed a discrepancy: the navbars were shorter than the standard. This is exactly what the Analyze step is for — not just reading the AI’s response, but testing it against reality. No AI output should go live without a human review pass.

klp (Teacher / Developer)

The two pages about Font Awesome have incomplete navbar items, compared to the explore page. Was there a reason for that? An oversight? Please advise and perhaps we need changes. I think this entry deserves to be included in the chatlog too. Your opinion?

🔄

R — Refine — Correcting the Oversight Notice the structure of the AI’s response: it admits the error clearly (no hedging), explains the likely cause, gives an opinion on the chatlog question, and then acts — fixing all three affected files simultaneously. A good refinement exchange is efficient: one prompt resolves the issue and advances the project.

GitHub Copilot

Was there a reason? No — it was an oversight. When scaffolding new sub-pages quickly, I wrote trimmed navbars instead of copying the full standard TNT navbar. There is no design justification for the difference; every page on the 2026 TNT site should carry the same complete navbar so visitors can always reach any section from anywhere.

Should it be in the chatlog? Emphatically yes — and it’s arguably the most valuable teaching moment of the whole session. It demonstrates the Analyze step catching something the AI missed, and shows students that AI output must be reviewed, not just accepted. The chatlog would be incomplete without it.

[Fixed both navbars to the full 10-item TNT standard (Home, About Us, News, Explore!, Movies, JS Apps, Processing, PHP, Styl’n, Resources) with correct ../ relative paths, and added this exchange as Exchange 4 in the chatlog.]

📚

K — Know — What This Exchange Teaches

AI makes mistakes. Not dramatic ones — quiet, easy-to-miss inconsistencies like a shortened navbar.
Always compare new pages against your site’s standards. A design system is only useful if it’s applied consistently.
The Analyze step is not optional. Reading a response is not the same as verifying it. Open the page. Click around. Compare it to what already works.
Catching an error is not a failure — it’s the system working. S.P.A.R.K. has an Analyze step for exactly this reason.
Meta-lesson: The chatlog that documents AI’s good work also documents AI’s mistakes. Both are equally worth showing students.

Reflect: what made these prompts effective?

What worked well

Context was given upfront (Noun Project history)
Target audience was named (novices)
Deliverable was specific (HTML/CSS/Bootstrap/JS, with a link)
Accountability was built in (“Why did you use it?”)
Follow-up refined purpose, not just output
Decisions were made clearly, not left open-ended

Try it yourself

Pick a resource from the TNT Resources page
Write a prompt asking Copilot to build a tutorial and explain why the tool matters
After you get a response, ask one refining question
Then ask Copilot to summarize what you both learned
Compare your chatlog to this one — what’s different?

Back to FA Tutorial Back to Explore