While it is true that Nick is responsible for building and coding the site to spec, responsive web design required me to think very differently about the content on the pages. So differently, in fact, that after 14 years of doing web work, I stopped and had a Dorothy moment. I’m not in Kansas anymore.Things can move around on the screen: text, navigation, images, everything. It all needs to shift and compress and breathe to fit varying widths. Content can and should be fluid. Where’s my compass?

So Daisy, our designer, and I took a major, unplanned side trip and delved deeply into RWD theory and process. Essentially, there are two major camps forming on this
topic:

1. The RWD folks who advocate building full-meal sites with all the content and features for desktop and then modify the way the content is displayed for various screen widths and devices via the use of media queries and CSS.
2. The other camp claims this is a faulty approach; among them the ever-controversial Jakob Nielsen who recommends separate mobile-optimized sites that cut features and cut content.

The realities of implementation aside, I would opt for something closer to Nielsen’s approach due to the fact that I am a content person. But without the proper research on what our users are looking for on mobile platforms, we are choosing the simpler RWD route and will modify over time or apply a hybrid version. We are a university with limited resources and we have to make compromises for the sake of making progress.  Our website needs a bail out now.

We deconstructed our process and had a healthy discourse. We met with David Conrad, founding partner at Design Commission, who gave us some great guidance on how to approach this project.  We read many articles and shared several examples. We involved BJ Miller, an Informatics student who works in IT, and he brought some good ideas to the wireframing process. We were finally all on the same page.

Some great resources:
How to Design a Mobile Responsive Website

Top Responsive Web Design Tools

Responsive Web Design by Ethan Marcotte

Gridpak: The Responsive Grid Generator

Podcast from The How and Why of Responsive Design

Top Responsive Websites in Higher Education

Examples of Good Responsive Design

In the move to the “cloud” I’m also beefing up our security. Now that we aren’t sure where the traffic between the DB and Web Server is routed, we decided we needed to encrypt traffic between the two.

Here are the steps I took to make this happen:

First generate the certificates for the SSL connection. I used openssl to do this. These files should be saved in a properly permissioned folder. A common location is /etc/mysql/certs/ or /etc/ssl/mysql/, but anywhere will do.

Create the certificates:

Here are the commands to generate the certs (run these on your DB server):

# Create CA certificate
openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem -out ca-cert.pem

# Create server certificate, remove passphrase, and sign it
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem -out server-req.pem
openssl rsa -in server-key.pem -out server-key.pem
openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem

# Create client certificate, remove passphrase, and sign it
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem -out client-req.pem
openssl rsa -in client-key.pem -out client-key.pem
openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem

When generating these, be sure to use unique common names for each cert.

Edit my.cnf

Now edit the my.cnf file on the DB server. This might be located in /etc/mysql/. Add these three lines under [mysqld] but replace /etc/mysql/certs/ with the path to your certificate files.

ssl-ca=/etc/mysql/certs/ca-cert.pem
ssl-cert=/etc/mysql/certs/server-cert.pem
ssl-key=/etc/mysql/certs/server-key.pem

Restart mysql on the DB server. (tail the mysql error log to see if everything starts up alright)

Create the SSL restricted user:

Hop in to MySQL as root (or another user with grant):

mysql -u root -p

Create the new user and give them access to your database from the IP of the web server. I added –ssl to the username to easily remind us that the user requires ssl.

grant all privileges on YOUR_DATABASE.* to 'YOUR_USER-ssl'@'192.168.0.1' identified by 'PASSWORD' require ssl;

Copy certs to web server

Next securely copy the following files over to your webserver.

ca-cert.pem
client-cert.pem
client-key.pem

Edit my.cnf on the web server

Then edit the my.cnf file on the Web Server and add these three lines under [client]

ssl-ca=/etc/mysql/certs/ca-cert.pem
ssl-cert=/etc/mysql/certs/client-cert.pem
ssl-key=/etc/mysql/certs/client-key.pem

Test the connection

Try connecting to your DB server as your ssl user

mysql -u YOUR_USER-ssl -h yourdb.domain.com -p YOUR_DATABASE

If this doesn’t work, check your error log on the DB server to make sure MySQL started properly with SSL.

Modify Drupal Core so it can support MySQL over SSL

We’re using the MySQLi extension for Drupal 6. To get it to support SSL I had to edit my settings.php file for the site, as well as /includes/database.mysqli.inc and /includes/database.inc

This is a bit hacky, and when updating Drupal these changes will need to be re-applied.

Add the following 3 lines to your settings.php file:

$db_url['certs']['key'] = '/etc/mysql/certs/client-key.pem';
$db_url['certs']['cert'] = '/etc/mysql/certs/client-cert.pem';
$db_url['certs']['ca'] = '/etc/mysql/certs/ca-cert.pem';

These are the paths to your certificate files. (note: if you have a database named certs that you are using with drupal, you’ll need to think of a different approach for this part)

Also within settings.php be sure to set the proper DB username and password in the $db_url[’default’] variable. Here’s what that variable should look like:

$db_url['default'] = 'mysqli://YOUR_USER:PASSWORD_HERE@database.domain.com/YOUR_DATABASE';

Remember, we set YOUR_USER to be someuser-ssl

Now edit /includes/database.inc :: within function db_set_active() there is a line calling db_connect(). I added 1 variable to the db_connect argument list:

$db_conns[$name] = db_connect($connect_url, $db_url['certs']);

Then edit /includes/database.mysqli.inc

Change the function db_connect() argument list to the include following:

function db_connect($url, $db_ssl=null) {

Now right above the mysqli_real_connect() call, add this:

  if(is_array($db_ssl) && sizeof($db_ssl) > 0)
  	mysqli_ssl_set($connection, $db_ssl['key'], $db_ssl['cert'], $db_ssl['ca'], NULL, NULL);

This line sets mysqli to use SSL and it sets the paths to the given certificate files.

With these in place, you should now be able to connect to the DB.

There are many steps to getting this setup properly. Just remember to watch your error logs to figure out what is going wrong and where. Testing out your SSL connection with a very basic PHP Connection test script might also help eliminate some of the variables that Drupal introduces. Here’s a sample test script:

$connection = mysqli_init();
mysqli_ssl_set($connection, '/etc/mysql/certs/client-key.pem', '/etc/mysql/certs/client-cert.pem', '/etc/mysql/certs/ca-cert.pem', NULL, NULL);
mysqli_real_connect($connection, 'database.domain.com', 'YOUR_USER', 'YOUR_PASSWORD', 'YOUR_DATABASE', 3306, NULL, MYSQLI_CLIENT_FOUND_ROWS);

3306 is the default MySQL port, this could be different for you.

To help display and communicate what we learned from the survey, our Graphic Designer, Dasiy Fry, took these results and turned them into the following infographic. Click the preview below to see the full infographic.

The web team is intact and the project has begun. I joined the iSchool a little over a month ago and plunged headllong into planning out the web redesign of our main, public-facing website.  It’s an ambitious task on a tight timeframe and it’s a challenge I relish.

I spent the first month on discovery, research and planning. Upon first view of the site, my thought was, “This is a rat’s nest of a navigation.” It was born out of the complete lack of centralized content oversight and IA strategy. Too many cooks without any recipes. Also lacking is a coherent voice and sound editorial judgement.

There is nothing I like better than bringing order to chaos, organizing ideas, categorizing content and making information flow. I’m in the right place.

We set up the project in Basecamp and I created several planning and process documents. I’m posting them here for anyone to check out and use. I’ve benefited so many times from various university bloggers who have posted their web redesign documentation that its time I return the favor.

An old FAQ page

My goal with this page was to re-design it in a way that made it seem more like a real FAQ page and become more readable and scanable to both a passer by and someone looking for a specific answer to a specific question. To do this, I started off by adding some more contrast between the questions and the answers as well as adding some more space and division between the different question/answer pairs. The first step here was to increase the size of each question to 18px and making the text a deep purple color to contrast the 12px black default text style of the answers. Then I added some spacing between each question/answer pair and throwing in a subtle light gray border to clearly distinguish between different questions. Then, after looking at many examples of FAQ pages on different websites, I noticed that many sites label their questions and answers with a big “Q” and “A” respectively. I felt that this made the site feel like even more of an FAQ page as well as adding a bit to the ease of scanning through the content so I added these labels to the left of each question and answer, again in an 18px font.

This specific FAQ page I was working on had the questions divided up into several sections, each with their own header. The 18px font of the questions, however, broke the hierarchy of scale with the section headers because they were a smaller font. A simple fix for this would have been to increase the size of the section headers to something like 24px, but after trying that out, It just seemed too big. I was really happy with how the questions and answers were looking so I didn’t want to tweak the question font size at all. Instead, I came up with a different approach to making the headers become more defined without going crazy with the font size. The first thing I tried was to give the headers a light gray background to make them stand out and really divide each section. This looked alright, but with the padding of the content container keeping the gray background of the header from spanning across the entirety of the content box, I felt like it still needed something to help divide the sections and stand out as more prominent than the questions. To fix this, I just took the gray box I had formed by giving the header a background and stretching it horizontally so that it extended 4px past the white background of the content box.

The final look after all of the changes

After all of the tweaks, I was quite happy with the readability and overall appearance and so was Nick so I went ahead and applied the new styles to all of the FAQs on the site.

The one drawback to the new style is that it involves adding a fair amount of custom mark-up to the page content which makes it a little tricky to do things like adding or removing questions and sections with the WYSIWYG editor. The easiest way to address this issue for the time being was to just let the page owners know that they will have to contact the web team in order to do these types of changes.

With the new iSchool site currently in the works, we are able to address this problem in a much more elegant and usable way. Instead of just adding the extra markup to Page content, we are working on a FAQ content type that uses a custom field to create new questions and answers and add them to an FAQ page.

What the FAQ content type might look like in the new Drupal 7 site.

Zach and I spent the better part of the past two weeks getting two new servers (both VMs in a clustered environment) set up and decommissioning an old one. Before recently we had a development server that was multi-purposed to also host LTS, our in-house open source daemon that handles secure connections between web services and our apps that want to use them. Basically it’s a middle-man standardized API that interacts with various services available on campus. So to start, one of our new servers is an applications server specifically for LTS and any other random app that we create that needs to be up and secure more than a development server could guarantee. The application server is also setup to host multiple sites so future non-production server worthy tools could live here.

Our second new server is purely for testing and development. We set it up to host multiple domains and have moved the development version of our current site over. In this move we also adjusted our strategy for versioning. In the past the entire drupal site lived in a GIT repo hosted internally. We shifted from that strategy to only housing custom code (modules, themes, and misc stuff) in individual repos on bitbucket. LTS and some of our Drupal modules are open source, but we also have private repos for our theme and various other modules that aren’t yet, or won’t be open source.

Our new strategy partially eliminated GIT as a backup strategy, so we also set up a snapshot script that syncs a weeks worth of nightly snapshots of our sites directory into a snapshots directory (on the same server). Since this is our development server, and we have our hand coded stuff in repos, we currently don’t have an offsite backup strategy in place for it, like we do with our production server.

I also spent a good bit of time tweaking settings on the new dev server so external traffic wouldn’t be able to view the site or get to things that should be internal only. Since all iSchool computers are on the 172.28 subnet it was really easy to only allow internal traffic. For external folks needing to get to the site, VPN allows them to. To quell any confusion, we redirected all external traffic over to a landing page on the live site explaining why they couldn’t access our development site, and how to VPN to gain access.

With everything off the old development server, it was able to be decommissioned. Our next step is to figure out what we want to do with our production server. Our goal is to move production out of our server closet and either into the cloud or over to a reliable dedicated host. While we have some redundancy in our server closet as far as hardware goes, we currently have no redundancy for power failure. With a site re-launch in the works, we’ll likely figure out our server solution for the new site and leave the current site where it is until we launch.

But enough about how some of our information is scattered everywhere, this post is about committees. The result of the committee meeting pretty much reinforced my belief that committees as working groups is a bad idea. The model that was used in this case, where the committee comes together to brainstorm and try to figure out how something should be done is broken. The result is that 45 minutes of a 1 hour meeting were spent discussing the same single issue without ever coming to any conclusions or plans for the future. So essentially time was wasted.

A better model (this is all of course just my opinion based on previous experiences) would be to form a small (<= 5) person working group full of experts that would be tasked to come up with a solution to a given problem (in this case creating a single point of contact for all staff, faculty and PhDs to get information). This working group could meet and work on this problem as much or little as they need to. After they come up with a solution, they present it to the committee (usually 10+ people). The committee can then provide feedback on the proposed solution and also ask for changes where they see additional needs or where needs weren’t met. Then the Working Group would make those changes and present their refined proposal, eventually resulting in the proposal being accepted by the committee (ideally).

In my model, instead of 10+ people “working” on the solution, you have 1–5 doing the bulk of the work and the committee is there to guide the solution to the desired outcome and ultimately endorse it as a committee backed solution. The trick here is to keep the committee on track and keep them from fixating on tiny details that won’t make a significant (if any) difference to the outcome of the project.

So what is Shibboleth?

I asked the same question when I first heard about it. It’s a weird name and I’ve never heard of it before. Shibboleth is a product of the Internet2 consortium. In theory, Shibboleth should catch on all across higher ed and maybe the whole internet. Now that we’re using Shibboleth, the iSchool could allow folks with other InCommon federation member accounts to login with their native credentials on our site. We don’t currently have a need to do that, but in the future, who knows?

So how did I get it to work?

It’s really not as straight forward as I was hoping. The documentation in the IT wiki seems to be a bit out dated, or maybe just different than an Ubuntu package setup, so it wasn’t easy. First, and foremost, what we are doing is setting up a Shibboleth SP (Service Provider); we are not setting up an IdP (Identity Provider). The IdP is hosted centrally by UW and already running. What we need is a Shibboleth SP, with which we will connect to the IdP (and the InCommon federation, if you choose to).

The documentation on the Shibboleth site supports RedHat, SUSE, and OpenSUSE installations well. These are the officially supported Linux Distros. Of course, we’re using Ubuntu, so it seemed I would have to compile from source. This didn’t make me happy and I didn’t want to have to do that. So I went Googling and found out that Ubuntu has some packages available through apt-get that will work.

From a conglomeration of sites I figured it all out, but there are a lot of steps to get this to work. To get started we first have to install the Shibboleth SP which will run as a daemon (service) on the same web-server that will need to authenticate. At the iSchool we’re running Apache so we’ll also need a shibboleth module. The apt-get package will also require some dependency packages, but that’s all handled for us by apt-get.

To perform this setup you will need sudo or root access to the server that you’re installing Shibboleth on, and you’ll need to know your way around Linux a bit.

The install

I’m assuming you have Apache installed and working, as well as SSL working on Apache.

First off, we need to grab some new packages, many of these have dependencies which apt-get will also be installing. Go ahead and update apt-get:

sudo apt-get update

Now start off by grabbing the shibboleth packages:

sudo apt-get install libapacahe2-mod-shib2 shibboleth-sp2-schemas

If you didn’t get any errors, you should have a /etc/shibboleth directory now. You should also have mod_shib_22.so in /usr/lib/apache2/modules, and you should have an Apache module load file in /etc/apache2/mods-available called shib2.load.

Now you’ll need to enable the Apache module:

sudo a2enmod shib2

Then restart Apache (this may be a different command for you):

sudo service apache2 restart

At this point, you can go ahead and start the Shibboleth daemon and see if things are somewhat working.

sudo service shibd start

You should see a message saying “Starting Shibboleth 2 daemon: shibd”. To test it out point your browser at your.domain.uw.edu/Shibboleth.sso/DS. This should redirect you to the placeholder URL https://ds.example.org… If it did, congrats, you have a working Shibboleth daemon. Now you have to configure it to work properly.

Configuring Shibboleth at the UW

This is where I had a heck of a time figuring out what to do. The install documentation in the UW wiki didn’t have much info about the config file, but after digging deeper I realized that there are separate articles beneath the Shibboleth Service Provider Support article (use the left nav to get to them).

The file you need to edit is /etc/shibboleth/shibboleth2.xml. This file will be full of example configuration SAML. You can either download this file from your server and open it on your desktop, or you can edit it in place with your favorite editor. Do note that the file is owned by root, so sudo when you open this file before you make all these changes if you’re using a command line editor (it sucks to forget to do that).

There are a few changes you’ll have to make in this giant file.

1. In the InProcess block change the name attribute of the Site element to be whatever the domain name for your shibboleth install will be. For us it was ischool.uw.edu. In the same element, I added scheme=“https” and port=“443” attributes, to specify SSL.

<InProcess logger="native.logger">
    <ISAPI normalizeRequest="true" safeHeaderNames="true">
        <Site id="1" name="your.domain.uw.edu" scheme="https" port="443" />
    </ISAPI>
</InProcess>

2. In the RequestMapper block, change the name attribute on Host to your.domain.uw.edu too.

3. Now in the ApplicationDefaults block, change EntityID to https://your.domain.uw.edu.

    <ApplicationDefaults id="default" policyId="default"
        entityID="https://your.domain.uw.edu/shibboleth"
        REMOTE_USER="eppn persistent-id targeted-id"
        signing="false" encryption="false">

4. Further on, there’s a EntityID attribute on Session Initiator which needs to be changed to urn:mace:incommon:washington.edu and an ID attribute which needs to be changed to UW.

<SessionInitiator type="Chaining" Location="/DS" isDefault="true" id="UW"
        relayState="cookie" entityID="urn:mace:incommon:washington.edu" forceAuthn="true">
    <SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
    <SessionInitiator type="Shib1" acsIndex="5"/>
</SessionInitiator>

In the above block, the forceAuthn=“true” toggle forces the user to re-enter their password on login even if they have a valid webauth session. We opted for this option since many of our users have web editing privileges on our site and the added security just made sense to us. If you don’t have a need for the extra security, you can go ahead nad change forceAuthn=“true” to forceAuthn=“false”.

5. Now you need to remove or comment out the following two SessionInitiator blocks. The only active SessionInitiator block should be the one above.

6. Further down, you’ll find a MetadataProvider block. Uncomment this block and make the changes as seen below:

<MetadataProvider type="XML"
        uri="http://wayf.incommonfederation.org/InCommon/InCommon-metadata.xml"
	backingFilePath="InCommon-metadata.xml" reloadInterval="7200">
    <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
    <MetadataFilter type="Signature" certificate="incommon.pem"/>
</MetadataProvider>

7. Configuring logout requires a couple more changes. This time in /etc/shibboleth/localLogout.html add the following meta redirect below the content-type meta tag:

<meta http-equiv="Refresh" content="0;URL=https://idp.u.washington.edu/idp/logout"/>

And that was the last required change. There are also error configurations that can be set, but for more info on that you can check out the Shibboleth Wiki.

Save and upload your shibboleth2.xml file.

Next you’ll need to edit the /etc/shibboleth/attribute-map.xml. For info on what to edit here, see the UW documentation on this page.

You’re almost done! Now, if you want to you can revisit the test url I gave above: your.domain.uw.edu/Shibboleth.sso/DS and you should be seeing a new error. Something along the lines of opensaml::saml2md::MetadataException, Unable to locate metadata for identity provider (urn:mace:incommon:washington.edu). If you see that, it means your configuration file is (at least mostly) working as it should. Now you just need to complete a few more steps.

Security keys

The reason it’s unable to find the Identity Provider metadata is due to a lack of the InCommon federation cert. The cert is linked to in the UW documentation and can be found at https://wayf.incommonfederation.org/bridge/certs/incommon.pem.To get it on your server, you can just run this command:

sudo wget -O /etc/shibboleth/incommon.pem https://wayf.incommonfederation.org/bridge/certs/incommon.pem

Alternatively you could just open the /etc/shibboleth/incommon.pem file for writing and paste the cert in, or FTP it up.

You also need to create a self signed cert for Shibboleth to use. The result will be a key file and a cert file. If you need help follow steps 1–4 in this tutorial. You’ll want to name these files sp-key.pem and sp-cert.pem, and copy or move them into /etc/shibboleth/.

Now you need to restart the Shibboleth daemon:

sudo service shibd restart

Hit the test url again and it should be forwarding you to idp.u.washington.edu/idp/profile/SAML2/Redirect/SSO. Your new error should be “Error Message: SAML 2 SSO profile is not configured for relying party ‘https://your.domain.uw.edu/shibboleth”. That means Shibboleth is configured to send your users over to the UW IdP. We’re almost done.

Registering with the IdP

Now you need to register your SP with UW and optionally register your SP with InCommon. The UW documentation is great here. We chose to only register with UW for now, so I’m not sure what the process is like with InCommon, but with UW it was pretty painless. One thing to note; You’ll need official domain access rights to register with UW.

After registering it takes a little while and after that the test URL should resolve to a working UW webauth login form. The next steps in this post are just about getting Shibboleth Auth set up in Drupal.

The Drupal Module

Now that we have Shibboleth up and working, we need to install the Shibboleth module for Drupal. This module works in both Drupal 6 and 7. We are currently using Drupal 6 for our production site, but we have a test server up with Drupal 7 on it. Both are using Shibboleth for auth.

This step is important and easy to miss. Add a few lines to your .htaccess file:

AuthType Shibboleth
ShibRequireSession Off
ShibUseHeaders On
require shibboleth

Now to configuring your new module. Navigate over to the shib_auth module configuration screen at /admin/user/shib_auth. You’ll need to change these Attribute settings (you can verify the accuracy of these variables by printing out $_SERVER after you are logged in via Shibboleth):

Server variable for username: HTTP_UWNETID
Server variable for e-mail address: HTTP_EPPN

Over on the advanced tab I also added in a URL to redirect to after logout. After that, all that’s left is adding the Shibboleth login block to your site. This will vary by site, so I’m not going to go over that beyond mentioning that the shibboleth module includes a login block that you can place on your site. How you want to get that there is up to you and your theme.

The goal of this post is to raise awareness of Shibboleth, and to assure everyone that it is possible to get it working with Drupal on Apache in Ubuntu. It’s also for our own step by step record of how to reproduce this in the future.

It turns out Internet Explorer isn’t king when it comes to iSchool fans, not by a long shot. On top of that when I drilled down into the IE versions I found even greater news.

Less than 2% of our IE users are using IE6. That means 1.9% of 27.2% of our users, 0.5% of our total user base, is on IE6. That number is finally low enough to really consider ceasing support for IE6. This seemed to good to be true, so my first thought was that all of our lab computers running IE9 must be offsetting these numbers. But I looked into it, filtered by external traffic only, and it turns out that number isn’t much different. Only 0.7% of our external users are using IE6.

A really neat fact is that more of our users browse from Android than from IE6. We definitely need to get our mobile style in check.

Does that mean I won’t check sites in IE6 anymore?

I will likely still be verifying that sites are usable in IE6. I am also considering adding a dismissible notice to our site that would show for IE6 users, letting them know that their browser isn’t fully supported and their experience on our site will be degraded while using IE6.

But as for having an IE6 only style sheet that swaps all those PNGs out for GIFs, I won’t be doing that extra work anymore.

In the first day, we came up with some ideas. We weighed out the pros and cons of keeping it simple and being a bit extravagant. Obviously people wanted it to be “cool” and “awesome”. The UW 150th site sure was, why shouldn’t our 100th be? The time crunch was here, we had somewhere around a week or two to get it up. Oh boy! So we did. The result was actually fairly decent, the site looks okay, even though the design wasn’t polished and massaged for weeks. The functionality is all there and it works within Drupal and within the current site’s template.

So what did I do wrong?

The timeline requires Javascript and doesn’t elegantly degrade. This is something that gets under my skin. This is something that I complain about when I look at other people’s work. And here I am, guilty as charged, a hypocrite. Why did I do it? The limitations of the current site template coupled with the limitations of Drupal and the time it would take to build out a custom module to make this work the right way created a wall that would prevent the timeline from being enhanced by the “two months ago would have been ideal” deadline.

What’s so bad about requiring Javscript?

Everyone has Javascript support these days, right? Well, no, not really. There are plenty of people out there with old browsers and old devices. Then there are others who turn Javascript off for security reasons, or maybe to prevent popups, or maybe JS slows their machine down. There are countless reasons a user might turn Javascript off. What we create should be accessible to those users no matter what their settings might be.

What should I have done?

I should have made the timeline work just fine without Javascript. Then, once that was working, I should have added the Javascript layer to make it cooler for people who have Javascript capabilities. In this particular case, the cost would have been a fair deal of time, perhaps twice as much or more, and we simply didn’t have it. What’s stopping me from fixing it now? Still time. We’ve moved on to the next project, and the next project is big.

So far, no one has complained that the timeline doesn’t work for them. I’m not even convinced we’ll hear a single complaint. But the fact is, I did it wrong, and I’m certainly not proud of that.