lee/hpr-knowledge-base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit: HPR Knowledge Base MCP Server

Browse Source 
- MCP server with stdio transport for local use
- Search episodes, transcripts, hosts, and series
- 4,511 episodes with metadata and transcripts
- Data loader with in-memory JSON storage

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Lee Hanken
2025-10-26 10:54:13 +00:00
commit 7c8efd2228
4494 changed files with 1705541 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

345
hpr_transcripts/hpr1073.txt Normal file
View File

@@ -0,0 +1,345 @@
Episode: 1073
Title: HPR1073: Separate Presentation from Content - 1 The Web
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1073/hpr1073.mp3
Transcribed: 2025-10-17 18:30:29
---
Hello, this is a hookah, and welcome to another episode of Hacker Public Radio.
And I want to do something that again is maybe just a little bit different from what I've
done in the past.
I think we're going to be able to build on this in some interesting ways that you might
not anticipate.
But to start with, I want to talk about something that has been around for a while, and that
is the separation of presentation from content on the worldwide web.
I got into this a few years back actually during the 1990s.
I managed a website for an educational institution, it was a rather small college university, whatever
you want to call it here in the United States.
And I ended up with managing the website because I knew more about web technology than anyone
else there, which is as good a reason as any, I suppose.
So I stepped forward when they were looking for volunteers and said, yeah, let me take
a look at this.
Now managing a website for an educational institution, you do have a number of different concerns.
Many of them are the ones that you would have in general for any website.
You want to have good design.
We did get a good design.
I was able to work with a very talented web designer, who is a graphic designer really,
but you know, he developed a pretty good sense of how the web ought to work and gave me
some good stuff to work with.
Then the other part, of course, is gathering and presenting all the information that is
needed by all of your audiences.
We have a number of audiences in a situation like that.
You have students, faculty, parents, potential students.
Yeah, there's a lot of different people that are going to be using that website and they
have different needs.
So figuring out how we're going to reconcile all of that was interesting.
So one thing that some people may not always think about, though, is accessibility.
In the United States, there's a lot called the Americans with Disabilities Act.
And that says any organization that receives federal funds must make its facilities accessible.
That's my layman's interpretation of that.
If you want to know more, I'm sure there are attorneys that could give you a much more
nuanced and detailed, but that's the basis of it.
If you get federal funds, you have to make your facilities accessible.
Now this has been applied for years in a number of contexts.
So you might have restaurants that are being sued because they're not handicapped accessible.
You can't enter with a wheelchair or something like that because it's up on the second floor.
There's no elevator, things like that.
So that's one way it's been applied, but on a website, there are applications of this.
And I was aware of that.
Now I would want to make my website accessible anyway.
You didn't need to pass a law to make me think that this was something that was worth doing.
I have a number of friends who have various issues, including a couple who are good friends
of mine who are blind since birth, and I'm aware of the issues.
It does however help to have a law when you're dealing with executive leadership.
And the executive leadership does not necessarily put a priority on stuff like this.
From their perspective, it's like, well, that's nice to have as long as we don't have to
spend any money or go to any particular effort.
Well, I wasn't really spending a lot of money other than the time, and you can argue that
time is money, but there were certain things that people wanted to do on the website that
I said, you can't do that because it breaks accessibility.
And because I could point to the law, I had a certain amount of negotiating strength
on those kinds of arguments.
So I started digging into what does accessibility mean, and it's a large and complicated
thing, and I'm not going to get into all of that now.
But the thing that I want to talk about that came out of that, and it's one of the more
profound things that I learned in the course of this, and I discovered it has much broader
applicability, and this will probably turn into several podcasts where I start exploring
the implications of all of this.
And so the idea of separation of presentation from content, what does that mean?
Well, that means that the information you present should be independent of the way you
present it.
So in take a simple case, you write a poem.
Does it matter whether the poem is typed or handwritten?
Does that make any difference to the meaning of the poem?
And when I put it that way, I think a lot of people would say, well, yeah, sure.
What difference does that make?
But it turns out there can be an issue here.
And anyone who's trained in graphic design would probably see it right away.
And that is that we use visual cues all the time to signal something about what we mean
in a piece of text.
For instance, I'm reading a book right now.
The book is called Wiccanomics by Don Tapscott.
It's a very interesting book.
It's all about how peer production in the web are changing all sorts of things in the
economy.
As I'm reading it, there are certain things that I start noticing.
For instance, like a lot of books, this particular book has chapters.
Okay?
Well, what is a chapter and how do I know I'm looking at one?
Well, there are certain clues that give it away.
One clue, for instance, is when a chapter is ending.
What's the clue that a chapter is ending?
The clue is a page of text that does not fill the page.
Now, you might once in a great while, strictly by accident, happen to have a chapter where
the last page does fill the entire page.
But most of the time, that's a hint right away, a visual cue that says, that's the end
of the chapter.
Now, we can confirm that by taking a look at the following page and seeing if a new chapter
begins.
And well, how do we know there's a new chapter there?
Well, again, it's going to be cues.
Typically, the chapter would have a title.
And that title is a line of text that is separated from the rest of the text.
It's at the top of the page, usually in a larger font, usually bold.
There may be other cues that are going to tell me that.
But all of those are cues that say, starting a new chapter here, right, separate line at
the top, larger font, bold, all of these things are part of a visual language that says
a new chapter is beginning.
Now in this particular book, this is a nonfiction book.
And within the chapters, there are subsections, actually several levels of them.
And if you take a look at the subsections, how do you know you have a subsection?
Well, again, there are visual cues about all of that.
There are subsection headings.
It's a line of text separated from what comes before and after, generally in a somewhat
larger font, not as big as the font for the chapter title, but larger than the font
used for the body of text.
And again, that tends to be bold.
And within this particular book, I can see that even the subsections have subsections.
And again, those subsections have a line of text separated from everything else, just
a teensy bit larger, but again bold.
So it's like there's this hierarchy of size that is going from the chapter title to the
main sections to the main subsections and so on.
So all of this is an example of a visual language that is communicating information that
is not contained in the raw text.
So if you were using just a plain text editor that didn't have all of that stuff available,
you would not have this information.
Now another example, italics.
We use italics in text to communicate something that is important, that we want to call out
in some way.
We want to emphasize.
My teaching days, I used to point this out and say italics were an author's way of saying,
pay attention, this is important.
The italics are very often used that way.
This is another part of our visual language.
And it's communicating information that is not actually part of the raw text.
We're using the visual appearance of the text to communicate some additional information.
And that's what we call presentation.
Now in the world of print, I think this works pretty well.
There are a lot of talented graphic designers out there and please do not listen to anything
I'm talking about as an attack on graphic design for this thing from my mind.
I am married to an artist.
So I do understand and I have the greatest respect for people who have that particular
talent because I'll tell you I don't.
I really have no talent for graphic design and I know my limitations.
So in the world of print, this language has built up and it really probably goes back
to all this minutious in the 16th century Italy and all of that.
Back when print was just getting started.
So we've built up this language.
And yet the World Wide Web Consortium, and this is generally abbreviated W3C, says this
visual language should not be used that way.
It seems to say that and why is that?
Well the first instance is there is an accessibility issue.
If you are using the visual appearance of text to communicate information, you are by
definition leaving out anyone who cannot see that visual presentation.
They're not going to get that information that they will not get.
Okay so that's the example.
This is what first led me into it was taking a look at this, but as I dug into it more
and spent some time learning about how to put together websites appropriately, I discovered
it's a much deeper issue than that.
Web content needs to be interpreted and displayed in a variety of ways.
And this is one of the things that differentiates web content from print.
If you're a graphic designer working on a magazine, you can lay out the page and you
can know that every single person who looks at that magazine is going to see that page
laid out exactly the way the graphic designer laid it out.
Because you have control of that in print.
You're creating this physical artifact and you control what it looks like.
But in web content, you might be looking at a web page with a large monitor, like my
25 inch desktop monitor, or you might be looking at it on a 12 inch laptop screen, or maybe
a 7 inch tablet or a 4 inch telephone.
This poses a problem now.
You don't have that complete control.
And that's inherent in the way the web works, is that you don't.
Now you could try, theoretically, to design a different web page for every possible monitor.
And you quickly realize that that's just impossible.
You can't do that because you don't know how big the screen is.
You don't know what resolution it's at, there are just so many variables.
It really becomes impossible.
And that's why web designers, the best ones, you know, people like Seven Apart, started
to say, hey, you know, we need to design differently.
We need to develop a different approach to this.
Now that's not all.
There's another issue that I think is very important.
People are not the only ones that need to access and understand the data.
I'm going to bet that every single person listening to this podcast uses a search engine of
some kind.
I tend to use Google to find web pages.
And how does Google find web pages?
Well, they have software that goes out and reads the page.
And then abstract from that some ideas about what the page is about.
So this is an example of what could be a more general case of machine reading.
You're using software to try and figure out what's the substance of this particular
piece of text.
You have to do that in order to then be able to say to someone doing a web search, ah,
this is the page that you're looking for or this page has the information that you're
looking for.
Another example, software that turns text to speech.
Now that was originally developed to assist people who were visually impaired, but it's
now becoming even more broadly applicable.
We're starting to use software to take electronic texts and turn it into the spoken word for
people who have no visual issues, but who maybe want to listen to a book that they have
while driving, doing housework, what have you.
You may know that the Amazon Kindle has that capability built in, unfortunately, because
the publishers have a cranial rectal insertion problem, the capability is frequently turned
off.
So, there's a good article, and I've got a few websites that I want to refer to that
I've put in the show notes.
It's an article on a site called Universal Usability that gets into some of this stuff that I
think is kind of interesting.
Now one of the great gurus of web usability is the following name Jacob Nielsen, and he
wrote a classic text designing web usability from new writers published in 1999.
And he talks about this in terms of semantic encoding.
And by this he means encoding the text in terms of what it means and how it functions within
the document, not in terms of how it will look.
So to Nielsen, it would be very wrong to take the title of your page and place tags that
make the font bigger and bolder as a way of saying, hey, this is the title.
Instead we use a tag called H1, and H1 directly states this is the title of the page, that's
what an H1 tag is supposed to be used for.
And that's an example of semantic encoding.
We take a piece of text and we put something on it and says, this is the title.
Don't say anything about, at this point, we don't necessarily say anything about what
it's supposed to look like.
We've just declared that it is the title.
And the benefit of doing it this way is that any person or device that accesses this
page will unambiguously know what the title is because it's been properly tagged.
Using readers for the visually impaired text-device software, search engine spiders, it doesn't
matter all will know exactly what the page title is by the proper tag.
Now, this becomes important when searching, for instance, because it helps to improve
the quality of the search results.
If a piece of software simply reads the page and records the appearance of a word, how
significant is that word to the meaning of this page?
If the word is in the title, probably means the whole page is about that topic.
Whereas if it appears somewhere in paragraph 5, it may well be less important.
Semantic coding helps solve this problem.
Have you ever had the experience of doing a web search?
And you start clicking on results?
And it's like, why did they send me here?
This page has nothing to do with what I'm looking for.
Well, it's a good chance.
You're the victim of a page designer who never understood semantic coding.
So that's why semantic coding, and I think this is a concept that has broader applicability.
One of the things that we are dealing with these days is making sense of a mountain
of data.
We're at the point now where the amount of information that is being generated in the
space of a year or two is about equal to every bit of information compiled by the human
race from antiquity up until a year or two back.
I was just exponential growth all over the place, and one of the biggest problems is making
sense of all of that information.
So it really does help if we use semantic encoding to do this.
It's going to make a lot easier to find information.
Now, if you're putting information up on a web page, presumably you're doing it because
you want people to access that information.
You want to make it visible.
You want people to find it, and particularly you want the people that really want that
specific information to find it.
Okay.
So that's the semantic encoding, but at the same time, the web is at least in part a visual
medium.
That's how the vast majority of people interact with it.
There still is that visual language, and so you're thinking, but I want my titles to
be in a bigger bolder font.
And I like using italics to emphasize words and phrases.
After all, this is a visual language that almost all of us have grown up with.
It's when we're fluent in, and it helps us to build more compelling pages.
So we don't want to throw out visual presentation.
We just want it to take its proper place.
And that's why the W3C did not say to get rid of visual language, only that we keep
it separate.
Do not use the visual language to short circuit the semantic encoding, but use it alongside.
And there is a way to do that.
And that way is through something called style sheets.
Now in the web, it's called cascading style sheets, or CSS.
The cascading part is you can have a style sheet that calls another style sheet that calls
another style sheet, blah, blah, blah, blah, don't worry about that too much.
But a style sheet, per se, is a concept that predates the web by many years.
In print production, style sheet is used to create a distinctive appearance.
Now, sometime, if you want to have some fun, seeing how people think about all this stuff,
there's a movie called Helvetica.
And if you're thinking, hey, isn't that the name of a font, yeah, you're right.
Someone with a passion made an entire movie devoted to a font.
And the thing is, it's a great movie.
If you have any feeling for graphic design, or just what it is to be a geek, because
this is a type of geekery that we're talking about, it's a great movie.
I recommended highly, get it from Netflix, or wherever fine movies are obtained, wherever
you are.
So anyway, back to the story, style sheets, publishers of magazines and newspapers would
select certain type faces, a certain color palette, some maybe some other elements of
visual design and combine them in a style sheet that told the designers, this is how we
want to appear.
So you may not have noticed it, particularly if you're not trained as a graphic designer,
but it's already all around you.
I bet you can identify many different magazines at a glance just because you know how they
look, even if you never consciously thought about it before.
Now, in terms of web design, a style sheet is a way of saying, every time I put this kind
of element on a page, here is how I want it to look.
A style sheet lets you specify, for instance, that every H1 element on your site, and remember,
the semantic meaning of the H1 tag is that it's the title of a page.
So you could say, well, all of those should appear in aerial font, bold, 16 points in
the color blue.
And this just an example.
You can do any way you want, but the point is you can make that specification on a style
sheet and say, this will apply to all my H1 elements.
Then you can take your subheads, your H2s, and say, okay, I'm going to go through this,
every H2 make the font a little.
Maybe instead of 16 points, it's 14 points, because that becomes then a visual cue, it's
a subhead, not the title of the whole page.
You could then go into every sidebar link and say, I want all of those to appear in this
font, then this color, and so on.
So with style sheets, what you do is you have a control over appearance, but you do it through
the proper semantic tagging of your content, if you're doing it properly.
And because you can apply a single style sheet to the entire site, it is a big time saver.
If I have a style sheet that says, I want all of my headings to appear this way, I don't
then have to go clicking through all of the different settings every time I'm doing a
heading.
I simply say, yeah, this is an H2, this is an H1.
And the style sheet immediately takes over and fills in all of the other stuff because
I've told you to do that.
Furthermore, suppose you decide to redesign your site.
That could be a lot of work, or if it's just the visual appearance that you wish to change,
it could be very little work, because all you have to do is change the style sheet.
All your content stays the same, but the visual appearance can be radically different with
the different style sheet.
Now there's a site called the CSS Zen Garden, again, link is in the show notes, that illustrates
this wonderfully.
It takes a single bit of content, and if you look closely, you'll see the content never
changes, but it gives you a dozen or more different style sheets, and each one of them
makes the site look radically different.
And yet, you changed it with a click of the mouse, because someone already wrote the style
sheet.
In practice, having been there and done that, I can tell you that writing the style sheet
can take a little bit of time.
But for a large site, changing the style sheet is a whole lot simpler than redoing all of
your HTML for the entire site.
So it's a much more efficient way of doing things.
So that is the idea of separating presentation from content in the context of the web.
And it was an important concept, and I was really glad I was introduced to it.
But what I'm going to do in my next program is I'm going to show how I took that insight
and then used it to understand some things about office productivity software, because
it really is a much broader concept than just what happens on the web.
So I'm looking forward to talking to you about that, and until I see you again, this is
a hookah, and I will, once again, just say, Ohio Linux Fest is coming up, Mark your calendar
September 28th through 30th, it's basically the last weekend in September.
And we'd love to see you there.
And please follow us on Facebook, Google Plus, Twitter, Identica, LinkedIn.
We're on all of the major social networks, and so you can get all of the latest news.
And with that, I am signing off.
See you later.