Click here to go back to the Welcome Page of the Reeves Motal Piano and Synthesizer Music Website

Web Design

When I started this website, there were a number of key requirements that I outlined:

1. Multiple Purpose Use

The public purpose was to showcase my songs.

The internal purpose was to serve as an information database. I try to provide a little background to the songs when I play them. To do that, I needed to collect and maintain a lot of reference information. Instead of keeping the information in a internal database, I put it on the website both for my convenience and because some of my visitors may find it interesting.

You can dig down behind each songs to the groups, to the individual performers, and even to the events of when the song was playing on the radio. I mostly play old songs and each one of them is also a memory.

It didn't dawn on me until the site was starting to come together, but I unconsciously modeled it after Wikipedia in some ways. There are countless times that I've clicked on Wikipedia to quickly look up some specific item, then found myself an hour later still following embedded links to other interesting stuff. My music website has the same flavor and might provide a little of the same inquisitive addiction.

You can start at a song, then follow it to the group, then to another of their songs, then to the songwriter, then to the songs he or she wrote, then to the studio musicians that played on them, then to more songs, etc., etc., etc. I'm always amazed at how music and musicians are all linked together.

When I first decided to create a website, I planned to use one of the web creation packages. However, every one of them had "quirks" that wouldn't let me do all the things I wanted to do. They are kind of like a high level programming language - it's easy to program in them but you are stuck being able to do only what they allow your to do. Way back in the 1950's I originally began programming in Assembly Language which is at the lowest level of code down at the raw register level of programming. The only limitation is hardware - you can do just about anything. To achieve that same level of capability, I decided to create the entire website in hand optimized HTML code.

2. Available on Multiple Platforms - Computers and Smart Phones

The last time I was designing websites, it was a lot easier. The only platform you had to design for was a PC with a 13 inch to 17 inch monitor with a screen resolution of typically between 1024 X 960 and 1280 X 1024, an aspect ratio of 5 X 4. Now, I'm writing this on a 49 inch screen with 1920 X 1080 - who knows what kind of monitor someone might be using to view the web pages?

The smart phones were even more of a Herculean problem. I went back only ten years and found 46 different screen sizes:

320 X 240, 432 X 240, 480 X 320, 800 X 480, 854 X 480, 960 X 540, 960 X 640, 1040 X 160, 1136 X 640, 1280 X 720, 1280 X 768, 1280 X 800, 1334 X 750, 1512 X 720, 1520 X 720, 1570 X 720, 1620 X 1080, 1680 X 720, 1792 X 828, 1920 X 1080, 1980 X 1080, 2048 X 1536, 2152 X 1536, 2160 X 1080, 2220 X 1080, 2242 X 1080, 2244 X 1080, 2246 X 1080, 2248 X 1080, 2270 X 1080, 2280 X 1080, 2310 X 1080, 2316 X 1080, 2340 X 1080, 2436 X 1125, 2480 X 1148, 2480 X 2200, 2560 X 1312, 2560 X 1440, 2688 X 1242, 2880 X 1440, 2960 X 1440, 3040 X 1440, 3120 X 1440, 3840 X 1644, and 3840 X 2160!

The smallest width is 320, smallest height is 240 - the largest width is 3840, the largest height is 2200. AARGH!

Many (most) of my pages are too long (high) to display on any screen height, so you'll usually need to scroll up and down - I couldn't see how to avoid that while making navigation easy and presenting things in a logical order and in sufficient detail.

What I wanted to do is avoid having to also scroll horizontally (sideways) so the width parameter was more critical.

There are two ways of approaching the problem.

One way is before each page loads for my server to ask your device what size screen it's got and then to reformat the screen to an appropriate size before sending it to you. This involves some tricky, cool, awe inspiring (and very breakable) coding on the server side.

The other route is to let your browser figure out how to display the page since it knows your screen size and it already has the coding to adjust the way the page displays.

See requirement 5. Robust - Bullet Proof below and you'll understand why I've left it up to your browser to figure it out.

The only requirement was to tell your browser the preferred way to reformat the pages. This was done with only six functions in a "Cascading Style Sheet."

Because of that, all my web pages will shrink down to a screen width on only 271 pixels and still display properly, although if you are using Internet Explorer/Edge as a web browser, you will need to horizontally scroll to see "all" of the Audio control with a small screen. You don't even need to do that to start or stop the audio playing - that works fine at 271 pixels - but to see the progress bar moving as the song plays, you'll need the 571 width minimum.

3. Audio Excerpts without Plug-ins

Since the focus of the site is music, it's pretty critical that there is some way to allow you to play song excerpts. There are two ways to handle that.

The web runs on "html" - H yper Text M arkup L anguage - standards of which are set by World Wide Web Consortium (W3C) https://www.w3.org These are the people that define the web. They set the standards for writing web code and how browsers must interpret it to be in compliance.

Other the years different versions of HTML have been released. The current version is HTML5 which was released about ten years ago. HTML4 was the previous version.

A lot of my site is still in HTML4 because I could "cut and paste" a some of the code generation software I'd written before for other sites. More about that in 11. Database Generated below.

The problem with HTML4 is that it doesn't natively support playing audio (or a lot of other things.) To play sound in HTML4 it was necessary for each user to download a plug-in like Flash or something. This was always a problematic approach because both web developers and users needed to keep both a web browser and various plug-ins up to date and "happy."

This is the route I've had to take in the past and it is a pain for everyone.

The second method to play sound is to use the Audio element from HTML5.

With the release of HTML5 audio support became an integral native part of the web and the ability to play audio should have been incorporated into all compliant browsers - plug-ins were no longer needed.

This is a much more painless approach for everyone - except that you need a reasonably current and robust browser that recognizes the HTML5 audio element.

You need one of the following browsers versions (or their equivalent) to run the audio element.

Chrome - version 4.0 or higher - released 2010

Internet Explorer/Edge - version 9.0 or higher - released 2011

Firefox - version 3.5 or higher - released 2009

Opera - version 10.5 or higher - released 2010

Safari - version 4.0 or higher - released 2009

Android - version 2.3 or higher - release 2010

Or some browser equivalent in capability to the list above.

If your browser is earlier/older than about 2011, then the only solution is to download a newer version. You should do this regardless as the older browsers not only lack capabilities, they also lack security features found in the latest browsers.

If you are using a phone and have a current browser version, then you might have a stripped down browser that doesn't support the audio element. This is most prevalent in older phones. Please take a look at Audio Help as to how to (hopefully) solve the problem.

4. Same Look and Feel as Albums

I've had a few comments about the plain Jane white on black look of the web site. There are several reasons why it looks this way. (By the way - I ignore all those sort of comments.)

First, large graphics and particularly video chew up bandwidth and wouldn't really add much to my site. This is all about music - not graphic elements. The song excerpts are the "bandwidth extravagance" of the site. Even though they are MP3's at 128 Kb, there are a LOT of them and they eat up bandwidth and thus take a while to download. Take a look at Sound Fidelity to see what I think about low quality MP3's. Still - it's the only practical thing to do on the site. My "real" CD music is eating up over 20 gigabytes on my hard drives - a "little" too much to download reasonably.

Take a look at Song Excerpts for other considerations regarding lower quality MP3 and the short audio excerpts.

With having to deal with the audio files bandwidth issues, I've used graphics very sparingly and when I have, I've tried to keep them small. They also are mostly on "read once" pages - such as this one.

The actual black and white look happened serendipitously as a result of the first CD I made for my friend Richard Moore. See the first album below for notes about that:

Click here to go to Album 01 -  Piano and Synthesizer - Debut Album of the Reeves Motal Piano and Synthesizer Music Website

After I'd burned the songs to a CD, I put the CD into a jewel case to protect it. Hmmm - I need to provide at least a list of songs and tracks. I opened up CorelDRAW and hastily created a song list and a title. My color printer was out of supplies, so I printed it out on my black and white laser, clipped it to size, and stuck it in the jewel case.

First Black and White Album Cover as shown on the Reeves Motal Piano and Synthesizer Music Website

I kind of like the black and white minimalist look so I've retained all those covers. However, I've now gone back and created a full set of more colorful (and in some cases more obscure) album covers. You can preview and download both varieties from the individual album pages and also from the PDF Downloads page. Here's an example cover from the first album.

First Color Album Cover as shown on the Reeves Motal Piano and Synthesizer Music Website

5. Robust - Bullet Proof

This is kind of a corollary to everything else. I've tried to do things in as simple of ways as possible. The more code you write, the greater chance that something will break. I've run all the pages through a couple of consistency checkers so hopefully I haven't included any coding errors.

One thing in particular I avoided was Adobe Flash. In the course of researching songs, I've been to a lot of groups websites. It seems at least half of them require flash to run the animation on the site. At least some of it looks pretty attractive - BUT - Adobe has announced that Flash will be discontinued as of 2020. The various browser developers are dropping support for it. I didn't want to end up with dead end software that would need to be rewritten in the near future.

It's also extremely annoying to go to a site and be told that I must download Flash before I can enter the website. It seems that a lot of people are unclear of the concept - do you want visitors to learn about their music or do they want them to admire the animation they paid someone to write?

Personally, I hope people like MY MUSIC. I'm not too concerned with what they think about my web development as long as they can easily navigate to the music.

My website, and I assume theirs, too, if either an on-line store for their music or at the minimum, a means to promote their music. Why stop someone at the door to your store because they don't have a particular piece of software? When s potential visitor leaves in frustration, they've just lost a customer and a fan.

One last things about Flash and then I'll get off my soapbox. It is an easy way for the jackasses lurking the web to infect your computer with "malicious software." If a site requires Flash, go somewhere else. Miserably negligent security is the biggest reason it is being discontinued - thankfully.

If your do run into some problem with my site, please let me know so it can be fixed.

Send me as many details as possible via the Contact Me page. In particular, make sure your send me:

     1. A correct e-mail address for me to get back to you.

     2. Which computer or phone you are having problems with.

     3. Version of the operating system.

     4. Browser type and browser version.

     5. Complete description of the problem with screen prints if possible.

I'll get back to you as soon as I can.

6. Fast Loading - Minimize Page Size

By minimizing the size of the pages and server side activity the pages should load quickly. The only thing that slows them down are the audio excerpts - they are the bandwidth hogs, but I've got them shrunk down about as much as I reasonably can. And without them, the only attraction to the site is my deathless prose and sparkling wit.

7. Easy to Navigate

Websites that you have to dig for even the most obvious information drive me crazy. I've tried to make this as intuitive as possible. All the main navigation items are in a separate, always visible, column on the left on a computer or a wide screen phone display. If the screen is too narrow, they will automatically locate to the very bottom of the screen. While you'll need to scroll to them, at least they are all in one place. I've placed "Previous," "Home," and "Next" buttons where appropriate at the top of pages and duplicated them at the bottom. Also, almost everything that does "something" on the site has an attached "tool tip" that will pop up if you hover over it for a moment.

8. Minimize Server Side Operations

Running a store requires a certain amount of server side operations - can't be avoided. The rest of the typical service side things I have minimized. A simple straight-forward site helps. It's all about reliability - the more tricky code, the more problems that develop.

9. Static Pages

In a similar fashion, all of the pages are static when they are served to you. There is a great deal of automation used to create and maintain the pages - see the next two sections - but that all happens on my design computer. That cuts down on my server usage and the resulting grief that can lead to. Believe me, it's a lot easier to fix things locally than to move them back and forth to the web server after each even minor change.

The downside to this is that I end up with thousands of pages. Each song is indexed in several different ways - and each song/index method requires a separate web page.

10. Easy to Maintain

The less complex any code is, the easier it is to maintain - fix problems, add features, make updates, etc. My primary focus is on creating new songs - not being a full time web creator and administrator.

11. Database Generated

In the light of the "Easy to Maintain" requirement, all of these web pages, (even this one,) are created via a database. If I make any changes, I only have to do it in one place and everywhere that change should appear happens automatically. Once the database updates the pages, all I have to do is reload them up to the web server. These was the most time efficient route as much of the web page generating database coding had already been written for other projects. I try to avoid re-inventing the wheel whenever possible.

Hopefully this rather long winded exposition will give you a little insight as to how my website was built and is managed.

Reeves

Copyright © 2022 Reeves Motal Music. All Rights Reserved

Last Updated: Saturday, December 24, 2022, 2:53:18 AM CST