hpr-knowledge-base/hpr_transcripts/hpr1538.txt

Episode: 1538
Title: HPR1538: Overhauling the School of Music website
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1538/hpr1538.mp3
Transcribed: 2025-10-18 04:48:26

---

Is this thing on?
I think it's on.
Hey, this is John Culpin, Lafayette, Louisiana, and I want to start today with just a little
public service announcement, and that is when you are recording one of these HPR episodes,
make sure that your recorder is actually recording.
The first attempt at this episode was last week, and I spoke for a good 30 minutes and
quit everything, got home, planning to edit, only to find that I had not recorded anything
except about six seconds of silence, and so I'm being extra careful today to make sure
that I'm recording.
I see that I'm up to 40 seconds on my Zoom recorder, so it looks like things are going
fine.
Anyway, in this episode I want to talk about another overhaul project.
The last one I mentioned was overhauling a public domain counterpoint textbook for use
with my counterpoint classes.
This is a different sort of overhaul, and it came about when I was made Webmaster for
the School of Music website at the University where I teach our old Webmaster.
I took a job elsewhere, and I don't know that I was next in line, but I had the skills
and the interest necessary to run a Web site, and so I inherited a site that was in pretty
bad shape.
I think the guy who was running it before had more on his plate than he could handle and
didn't have time really to keep it up as well as he would have liked to, but it was
a static HTML site built in Dreamweaver, largely using tables for formatting, you know, for
page layout, not at all mobile friendly, direct formatting everywhere.
There was no main style sheet to control the appearance of the site.
Many of the pages had content that was incorrect or out of date.
Lots of the photos were really old.
I mean, it was pretty messy.
The site is hosted on a server here on the University somewhere.
I don't know where it is, but we got some web space.
And the only access I have to it is FTP.
And so this is a little bit limiting, and there was no way for me to install a content
management system on it or do anything of that sort.
I mean, really the only access I had was FTP to my little corner of the server.
And so at first I did not plan to overall overhaul the Web site that much at all.
What I really set out to do was not all that ambitious, and that was simply to make the
site less embarrassing than it was.
And to do that, I started going through all of the pages and trying, as a first step,
to get a little bit more consistency in the appearance of the site, because there was
a great deal of inconsistency in font type and font size.
But sometimes even on one page, there would be two different font types for paragraphs.
And so I went through and did a bunch of standardization of fonts as a very basic first step
and started to build a standard CSS file that would control the entire site.
And then I went through and tried to reduce the amount of text that was on the site.
The text was way, way over the top.
It was built in a time maybe where people had longer attention spans and could stand to read large amounts of text.
But I think nowadays a website should have much less text than this.
So I went through and tried to get things down to base.
There was one page that had, I don't know, 20 or 25 full paragraphs of text.
And I managed to scrunch that down to a table that had the relevant information in very pithy,
terse layout.
And so that, everyone who saw it said, thank you, that is so much better.
And so things of that sort, I went through and did updated photographs.
We, my director, actually hired a photographer, a professional photographer to go around and take new photos of all of the faculty.
And so I got very high quality images to put up.
And so gradually it got less embarrassing.
I also encouraged my colleagues to send me videos.
Or else post videos themselves up on YouTube or some other service where I could embed some more multimedia in the site.
There was just too much text and not enough multimedia.
And so these kinds of things were fine.
And it definitely helped.
But at some point I decided to actually tear the whole thing down and rebuild it.
And I think it was when I had learned a little bit of CSS layout.
I knew already how to control things like text attributes with CSS.
But at some point I decided to try to learn how to layout web pages using CSS.
I learned the basics of that by just reading online and seeing examples of it.
And I thought, you know, maybe I can actually do this.
The advantage of this, of course, is getting the layout out of tables and into CSS is the just much better flexibility of the website.
I really wanted to have a site that would work well on mobile devices.
And so once I learned the basics of CSS layout, I started building a new template for our website using CSS instead of tables.
And it took a while, but I got something that looked pretty decent and that would change dynamically according to the detected screen width of the device that was accessing it.
I used as a guide, I suppose the essential layout of the university website, which is run on Drupal.
I should have mentioned that the entire university eventually will be using Drupal for content management, but they're going department by department and helping people learn how to use it and helping them get their sites up and running.
And the School of Music is not due for this migration until the spring of 2016.
And I thought that was just too long, too far in the future to live with this terrible website until then we had to do something right away to at least hide it's over until we can get Drupal.
So I made up a template that is based on the basic design of the university website as a whole.
It has a top navigation thing, a header with the university logo and then some text showing which department it is and there's a left navigation panel and then a main content area.
And then at the bottom, a footer and some navigation links with social media icons and things of that sort, I used colors that are part of the officially approved university palette of colors, which I found on there's a very helpful page on the communications department website where they say these are the official like primary palette and then the secondary palette for other things.
And so I came up with something that I thought was okay, I emailed a link to somebody who's kind of in charge of the website oversight and she took a look at it and said, yeah, that's looks pretty good.
You might consider changing this color here or that color there.
And so after a couple of emails back and forth, I got the green light from higher ups about the design.
And so then began the process of taking every page on the old site and converting it to work with the new template.
Since I didn't have a content management system to deal with this and I could not, I couldn't use Dreamweaver like the last person did.
I don't necessarily think the Dreamweaver is an evil tool, although it seems to encourage bad habits if you are somebody who doesn't understand how websites work.
But one of the features of Dreamweaver that I could have used is the push everything up to the server feature.
And I'll get to that in a minute, you know, push it in a smart way, you know, only files that have been changed and things like this.
But I kind of had to come up with my own content management system.
I wanted to separate presentation from content.
And so I wanted, when I worked on a web page, only to be working on the main content area, either the text or the images that appear in the main content area and did not want to have to worry about the header, left nav bar, footer, all of those things.
I wanted to keep all of that stuff separate and then build an entire page around the main content.
So the way I came up to do with, to do this was to write a bash script.
And this shouldn't be surprising to people who have heard my podcast before because it seems like a bash script is my solution just about every time.
But I came up with an idea that I could keep the content area in a separate file with an extension called dot contents.
And in that file, I would just have the part that appears in the main content area.
And then I would have a script that I would run on the dot contents file and it would assemble around it.
All of the navigation things, an image that would appear under the left navigation panel and various other things that might change from one page to another.
Anything that would be exactly the same on every page on the whole site, I kept in a separate plain text file that would then be grabbed in the process of the bash script and inserted at the right place.
There are certain things on web pages that change from one page to another, even if only a little bit like the page title.
So every page on the site would say school of music, but then there would be an M dash and then something indicating what page on the site it was, whether it was the list of ensembles or the faculty bio of somebody, whatever it might be.
And so I didn't want to have to edit the head, the header content of every file to change these things.
So I came up with a system where at the top of every dot contents file, I would store certain variables in comments.
So for example, the page title would be stored in an HTML comment and then part of the bash script would be to scrape through all of the comments at the very top of this file and extract the variables that it needed to put into place.
So there would be things like the page name, okay, well, page name, I suppose is what I was just speaking of as the page title.
And that is what appears in the browser, it depends on the browser, but in Firefox, for example, it appears across the very top of the browser on whatever page you're looking at.
The body ID, which is something that I would use for CSS purposes, navigation image, the image alternate text, the image caption image title, and all of these things would have the anything of having to do with the image would be specifically for the image that appeared under the left navigation panel, because I didn't want, I wanted a picture to be under there, but I didn't want to use the same one on every page on the site that would be boring and kind of stupid.
And so part of the variables at the top of the file then would tell the script which picture to use there and what caption if any to put under it, what alternate text to put with it and so forth, and it would just insert all of that stuff when it was building the page.
And so I'm pretty proud of this script, it works very, very well, and I can very quickly build all what 85 to 100, I'm not even sure how many pages we have on our website, but there are quite a lot.
I can build all of them in 15 or 20 seconds, and it would be faster if I didn't put little sleep commands in there to make sure the things don't choke.
But anyhow, so I came up with a way to build everything, the next thing to do would be to figure out a way to transfer it over to the server.
Now I had used FileZilla, FileZilla is an excellent open source FTP program, and it works fine, but as far as I could tell there was not a way to tell it to do smart transfers of things.
In other words, only to transfer files over there that needed to be transferred because they had just been updated.
And so I looked around for a command line tool that I could use, I could not use our sync because I didn't have any SSH access to the server, but I found a tool that I had not heard of before called LFTP.
And it does most of the things that I wanted from our sync, you can have files excluded either on math, like a whole groups of files with, say, certain extensions, like all of the .txt files I did not want to be pushed, all of the .contents files also I didn't want to be pushed, so I can exclude all of those.
And it also can tell, you know, based on the command you give it, only to update files that have either changed in size or in date and time stamp and things like this.
So anyway, it works pretty well, and so I had a pretty reliable and efficient way to transfer files over there, so that was good.
Also, one of my big concerns in redesigning the website was that it work well on mobile devices, and so in my CSS file, I have several break points for different screen sizes, and it will either change font size or leave elements out or change the maximum image width size or things of this sort to make sure that everything lays out in a sane way on a smaller screen.
It goes anywhere from 240 pixels wide up to, I think, break points are at 320 and 460, 720, and maybe a 1024. I have several break points.
And one thing I found very handy when testing all of these different screen widths, because I don't have physical devices of all these different size, is a Firefox keystroke,
Control plus Shift plus M, as in Moon, Control plus Shift plus M. If you hit that while you're looking at a web page, it will change its layout so that it looks like you're looking at it through a small screen.
And you can choose from any number of preset screen sizes, or you can make a custom screen size to see how your page is going to look in that. It's a very, very handy tool for web development, if what you're trying to do is optimize for screen sizes.
As far as that optimization for screen sizes, I had to learn that by just reading around online and seeing examples of how people did it.
The most crucial element is putting in the header of each page a line called Viewport and setting a couple of parameters in there.
Let me see if I can find that here. Where do I put that?
There it is. MetaNameEqualsViewportContentEqualsDeviceWith. Then you can set an initial scale. You can set a maximum scale that's larger if you want people to be able to zoom in.
And then UserScalableEquals, either yes or no. This line will enable the website to respond to different screen widths.
And then in your style sheet, you have to set up different media queries based on screen widths where you want it to start looking different.
It took a little bit of experimentation and stuff because I'm not a professional web developer. I'm a music professor.
So I was learning all of this stuff on my own, but I'm going to have links on the show notes for the site so you can poke around and see what you think.
See whether I did a decent job or not. I'm pretty happy with it and my colleagues are all happy with it because it's less embarrassing than it was.
The entire site except for two pages is just HTML. I tried to conform to HTML 5 standards. I also tried very hard to conform to all web accessibility standards.
And so I use various online website checker services for this. There's one called web aim. I think I will have a link to that in the show notes as well where you can put the URL for your site.
And it will check the various accessibility things. I'm making sure that you have alternate text for images and all kinds of things.
I can't remember what all it checks right now, but my page has got the green light on the accessibility front.
I also learned, I don't remember at what point. It was sometime after I had finished this whole overall. I learned about how you can have alternate style sheets.
And I don't remember a fun this one I did it or if it was just on my personal website, but I learned about alternate style sheets that users can choose themselves.
And also I learned about a wonderful accessibility font called Open Dislexic font and on my home website and on all of the HTML materials that I use for my classes that I teach I have started providing alternate style sheets.
So that users who have dyslexia can very quickly change to the Open Dislexic style sheet. And it changes a couple of layout things, but most importantly it changes to the Open Dislexic font, which by most accounts makes things much, much easier for a person with dyslexia to read accurately.
It doesn't necessarily improve speed that much, but it doesn't improve accuracy quite a lot.
As a side note, I had two students in a recent class who were dyslexic and I printed out their exams on exam day using Open Dislexic font and they really appreciated it, said it made it much easier and less stressful for them to take their exams.
So anyway, that has to do with the style sheet. I also, I wanted the website to be light and flexible and to load quickly.
And so I tried to optimize everything that I could to make sure that it would load up fast. There's a tool, one of the Google web developer tools you can use called PageSpeed.
And I will have a link to that in the show notes as well. And you just put in the URL for your site and it will check and see how well your site scores on the optimization scale.
And I got this website where the desktop version scored like 95 to 96 out of 100 and then the mobile version of it would score in the upper 80s out of 100.
There were a couple of things that I could never get to score higher than that when it was loading up for a mobile device, but it was still much better than many of the sites that you see.
There are two pages on the site that have JavaScript. One is the very front page where I have an image slider kind of thing and the other one is a place where we list all of the various degree programs we have.
And I wanted to hide the descriptions of the degrees using a bit of JavaScript so that the page wouldn't appear at first glance just to have so much text.
And I want to thank one of my friends online Bob Junkman went back and forth with me a couple of times on our status net platform helping me understand how my JavaScript was working on that page.
It turns out that the way I first did it, I was not using JavaScript to hide the descriptions but rather to display them.
And so when he went there, he's a little bit paranoid about JavaScript and he has JavaScript disabled in his browsers and he was not able to see any of the descriptions.
And of course that is not the behavior I wanted. I wanted someone who went there without JavaScript enabled to just see everything and anyone who went there with JavaScript enabled would have all of the things collapsed and then they could click on each degree program and then it would expand to show them the description.
And so with Bob's help I got that sorted out and it behaves in a JavaScript in a no JS friendly way. So I could go there on a text browser like e-links or Bob can go there on his JavaScript disabled browser and see everything just fine.
Let me see, part of the optimization was of course to make sure that all of the images were scaled properly for PNG files which were not most of the faculty images and images of our students performing and so forth were in JPEG.
And so I would just scale those two size and leave it at that. For the various PNG things on the site I used another tool called TinyPNG.com. There's a web-based tool called TinyPNG and you can reduce the file size of PNGs there which I think by default are a little bit too large.
But I was able to reduce the file size of the PNG files by something like 75 or 80% in most cases. And so that of course helps loading up the pages faster especially on mobile devices.
I also used a minification tool to minify the if you're not sure what minification is it's this crazy thing where it just removes all white space from your HTML page and so when you are editing the HTML you don't want it to look like this because it's too it's not human readable.
You need to have proper indentation and stuff like that to make sure that you can find what you're looking for and edit it quickly. But a web browser doesn't really care how about this indentation and about comments and things like that.
So before you put it up on a web server it's suggested that you minify the code to get rid of all comments and white space and that helps it to load faster.
And so part of the build script my my bash script that assembles the entire page around the dot contents file is to minify everything.
So if you look at the source code of any of the pages on this site you'll see that they're minified and there are tools online that you can use to go the other way as well.
If you have some minified code that you need to expand to show proper indentation then you can just copy and paste them into this little text box and then click unminify or something and it will expand it for you.
But for my part I I only edit the dot contents file which has all of the comments and the indentation that I need to do efficient editing and I never even look at the minified code.
Let's see I think that is probably about it there was something that occurred to me a moment ago then I wanted to mention and now I don't remember what it was.
Not that important but feel free to go over to the school music website I will put a link in the show notes so you can check out what I did I wish I still had a link to the old version so that you could see the before and after but I'll just tell you the before was really very ugly and not the least bit flexible whereas the after is actually pretty good.
Oh I should mention one other thing that I found in the course of doing this and that is a terrific set of icons called font awesome font awesome is it has some kind of free license I don't want to say the wrong license but if you go to the font awesome website you can get these free icons to use on your site and I was able to use things like the little three bars for a menu on the mobile site.
And the various social networking icons and things like that and they're they're great because they're actually fonts they're not images.
And so that makes them very easy to scale they're very high quality I don't know how they go about I think people request certain icons to be done and then someone creates them in in escape or something of that sort and then adds it to the font set but I highly recommend font awesome.
If you are in a position where you need to develop a website it's it's great.
All right well I think that's it I'm done talking about the school of music website and it looks like my recorder is still recording so I'm happy about that.
And I guess I will talk to you guys some other time I'm not sure what my next topic will be but we will see.
Take care. Bye.
You have been listening to Hacker Public Radio at Hacker Public Radio.
We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show like all our shows was contributed by a HBR listener like yourself.
If you ever consider recording a podcast then visit our website to find out how easy it really is.
Hacker Public Radio was founded by the digital dark pound and new phenomenon computer cloud.
HBR is funded by the binary revolution at binref.com.
All binref projects are crowd-responsive by linear pages.
From shared hosting to custom private clouds, go to lunarpages.com for all your hosting needs.
Unless otherwise stasis, today's show is released under creative comments, attribution, share a line, read our own license.