Website redesign (part one)

I have hitherto avoided inflicting my technical problems on the
readers of this blog, but this subject is what I really need to
think about, so it doesn’t really make sense to go finding other
things to write about the way I did yesterday. I’ll
try to keep the tech talk understandable to the lay user; let me
know if I fail.

This post is going to discuss only the basic functionality of
how the transcribed pieces are described, and how the user finds
them. The other parts of the site will be discussed in future posts.

Why a redesign?

Because the original design has gotten unwieldy both for
me and for the users.

The reason I didn’t add new pieces to the site for over a year
wasn’t that I wasn’t transcribing new pieces, it’s that the
procedure for adding things is quite clumsy. After I changed
computers and ISP’s in August it was clearly going to need an
unknown amount of debugging. The debugging turned out to be small
when I finally got around to it, but adding a piece that’s been
transcribed and proof-played should be just an easy couple of clicks.

For the users, the one-page By
Composers
listing is an increasingly unwieldy way to find what
they want, and doesn’t include all the information they need. For
instance, one of the most-requested things is a way to find pieces
by number of parts. It would also be good to have some idea of
the ranges of the parts.

The original site design did have both number and ranges of parts
when you got to the page for the piece,
but it happened by displaying short excerpts
from each of the parts, which
broke fairly early on, and wasn’t really the right answer for
doing searching anyway.

So here’s my picture of how the site should look:

  • The primary entry to the collection of transcribed works
    should be a search page that allows selection by composer,
    dates, number of parts, instrumentation, country, language, or
    any combination of those things. That is, if I’m looking for a
    trio for voices in German, I should be able to just say, “Show
    me all the three-part vocal pieces in German.” Or if I want to
    know what there is by Billings, I should be able to just request
    that.
  • The current static html pages which are generated from the
    database by a script I wrote, should be generated dynamically
    from the database. (If that doesn’t make sense, see below.) This will make adding a new piece much
    simpler. You don’t want to know what I do now; what I’ll do
    then is run one script which will add the piece to the database
    and upload the files.
  • I think it might make sense to leave both the current search
    pages (By
    Composers
    and By
    Date
    ) there, but of course have them dynamically generated.
    The idea is that for browsing, having a way to look at what’s
    been added or changed since the last time you browsed, or at
    what the distribution of stuff by composer is, is easier than
    just dealing with the search page. Possibly it would make sense
    to add other pages like that, such as “By Country” or “By number
    of parts”.

Static and dynamic

It looks like the major technical jargon I wasn’t able to edit
out of the above was the static/dynamic distinction. So here’s
an explanation.

In general, if you go to a page like www.laymusic.org/directions.html,
it’s static. HTML is a markup language, so the person who
authored the page just wrote text, and then put in some commands
to say things like, “Here’s a new paragraph,” or “Display this
image here.” Then they put that page on the site, and kept
track of where they put it so that they could refer to it from
other pages, or from emails.

If you have 500 pieces, or a couple of blog entries a day, this
might not be such a good idea. So the way most of those sites are
done is that the information you want to maintain about each
individual item is in a database, and
the text you see when you look on the web at that item is
generated by a program from what’s in that database. For
instance, each piece on my site has a title, a composer and a
list of files someone might want to download
in the database, and there could be a program that gets run on the
server every time someone says, “I want to look at that piece,”
that would display that information.

It was even at the time wierd, but when I designed the site, I
did put the information in the database, but instead of having the
program on the server to display it, I have a program that runs on
my own computer that writes an HTML file to display it. This
means I have to rerun that program every time the information
changes, and run the program that generates the “By Composer” and “By
Date” pages every time I add something. This was fine when there
were only a few pieces, but it’s getting tedious now that there
are more than 500, with another hundred or so that I haven’t yet
put up.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s