Fixing an out-of-touch district website

July 30, 2014

My previous posts outlined how I host and develop my various websites and why my two main sites for the district and the high school needed updating. Since 2009, when the current version of the high school site was designed, the number of visitors using mobile devices and tablets jumped from 2% to 37%. About 1/3 of visitors appear to be using small touch-screens instead of the traditional computer monitor and mouse. Those small screens make it harder to use the densely linked, multi-column layout of the websites, with horizontal header navigation menus or buttons plus additional vertical sidebars on the high school site.

Responsive design or a separate mobile site?

There are two basic ways to respond to this issue. You can devise a separate website tailored to small screens and touch control, with large header/footer navigation buttons, scrolling and collapsible screen-width menus, etc. Or you can re-structure your existing site for “responsive web design.” That means it has graphics which are scaled as percentages of a column rather than in pixels, and fluid columns and page elements which elegantly re-arrange themselves depending on the width of the viewing screen. Designmodo posted a bunch of examples.

Responsive Design is one way to be mobile-friendly

Responsive Design is one way to be mobile-friendly

Responsive web design is becoming more prevalent, since it has some distinct advantages over a separate mobile site:

  • Only one code base to support instead of two separate ones for large vs. small screens requiring replication of changes
  • Similar appearance and navigation for visitors using large (PC), medium-size (tablet), and small-screen (smartphone) devices
  • Simpler for web analytics and search indexing

The downside to this approach is that you have to re-think the structure of every page of an existing site. You need to think about columns and how they might best be re-ordered, or nested, and whether the navigation elements need to switch to a different style once the screen width narrows beyond a certain point. This requires some fancy footwork in the Cascading Style Sheets (CSS) which structure the page.

Separate mobile sites discard all of that complexity and re-coding of existing pages in favor of a separate site with a simplified interface. Mobile sites can be built which work with a wide variety of browsers on different operating systems of varying capability and ages. Mobile sites use larger interface elements to solve the “fat finger” problem. Consider the difference shown between Olive Garden’s regular and mobile sites.

Olive garden's mobile site differences

Olive garden’s mobile site differences

Until July 2014 I had no experience coding mobile-friendly websites and I knew there was no money in the district budget to go out and pay for one. So I first checked out what my existing 2012 version of the Adobe Dreamweaver CS6 web development software had to offer. It included both responsive-design and mobile-specific options.

Fooling around with fluid flow

Fluid layout options in Dreamweaver CS6

Fluid layout options in Dreamweaver CS6

My first attempt, back on July 11, was to try to re-create the district homepage using Dreamweaver’s “Fluid Layout”; this was clearly their take back in 2012 on responsive design. I have no Dreamweaver training, so I found an online 35-minute video from Patrick Lowenthal which stepped me through creating a page with a fluid layout. I fleshed out a page with the sort of menu layout I preferred and then tried viewing it at various screen widths.

The results were unimpressive. I didn’t like how the site looked at the narrowest setting or the widest. Goldilocks wouldn’t want the porridge on offer from my Baby Bear layout or my Papa Bear layout. With enough thought and care I could reach a better compromise, but I feared it would feel like a compromise, reducing the usability and efficiency of the current site on large screens.

Nor did I relish having to re-think every page of the website in terms of what would flow well. I wanted to complete an initial draft in a few days before I had a conference out of town, not get bogged down in a full rebuild. And I wanted the entire thing, with all of the polishing and debugging, wrapped up by the end of the month. Bartlesville teachers report back on 8/8 this year, and classes start on 8/12, and I have plenty of advance work still to do on teacher appraisals, a technology training manual, etc.

A separate but equal mobile site?

Dreamweaver's Sample jQuery Pages

Dreamweaver’s Sample jQuery Pages

So I shifted my attention to devising a separate mobile-only site. It could concentrate on easy navigation, while still offering full access. A pet peeve of mine is how many mobile sites only encompass a fraction of the options of the regular site, offering no clue of what has been omitted. I wanted our sites to provide access to everything on the regular site, even if that meant sometimes giving up on trying to convert content that was too much for tiny screens; if things got hairy, I still wanted links that would pop back into the full website.

jQuery inserts in Dreamweaver

jQuery inserts in Dreamweaver

Browsing through Dreamweaver’s New Document dialog box, I came across some sample “Mobile Starter” pages written using something called jQuery Mobile. I started messing around with those and liked what I saw. Clean, simple boxes with big buttons and a variety of options for displaying links and information. Clearly the resulting site would look silly on a big screen, but it would be quite easy to navigate on a small smartphone.

So I re-created the district homepage contents and links using the jQuery Mobile commands on Dreamweaver’s insert menu, without any fancy touches. The result reminded me of something I’d seen before…what was it?

I eventually figured it out; my sample page looked like the National Weather Service’s pages do when you use a mobile device. They must have coded them in this jQuery Mobile thing.

My first jQuery page and a NWS mobile page

My first jQuery page and a NWS mobile page

That meant I could visit in my desktop web browser, do a “View page source” and study the underlying HTML and CSS files, and see what Javascripts they used, even though I don’t know Java. I suppose the traditional approach would be to go look up jQuery Mobile on the web and review the documentation, but that isn’t my default mode. I like to find something I like and try to peer at the code to see how it works so that I can steal and adapt from it.

I downloaded the various CSS and Javascript support files the weather service’s pages were using and starting building out my own pages to mimic the structure of the regular district website. There were the usual oddities that result from this sort of tinkering, with absent or mismatched graphics, flakey controls, and the like. But I knew I could eventually sort that out once I got the basic structures built to ensure this approach would satisfy my goal of a mobile-friendly site with full functionality, including fall-backs to the regular website as needed.

Internet tools evolve quickly

jQuery Mobile has some great demo sites

jQuery Mobile has some great demo sites

While debugging my code, I stumbled across a very well done website with online documentation and example code for jQuery Mobile version 1.2. I really liked the jQuery Mobile 1.2 demo site and made extensive use of it to learn various tricks. But I was seeing formatting glitches. Hmmm…my 2012-vintage Dreamweaver created version 1.0 files, while the weather service site I’d selected as a model used version 1.3 files. Evidently jQuery Mobile had put out several major new versions beyond what my copy of Dreamweaver knew. Since I’d been using some files via the NWS code, a mismatch of downloaded icon files, stylesheets, and Javascript was no doubt causing the formatting glitches I was seeing in my new site.

Eventually, when I couldn’t get something to format the way I wanted, I discovered at jQuery Mobile’s main site that they’re now up to version 1.4.3. But I couldn’t simply download and install the latest version: back in the transition from 1.3 to 1.4 they dumped several default themes I was using in my code and the demo site for 1.4.3 showed they’d reworked a lot of the styling codes.

Two buttons, one created in jQuery 1.2.0 and the other in 1.4.3

Two buttons, one created in jQuery 1.2.0 and the other in 1.4.3

For example, to create small button with a delete icon above the text, I’d grown used to coding:
<a href=”#” data-role=”button” data-icon=”delete” data-iconpos=”top” data-mini=”true” data-inline=”true”>Delete</a>
while the new version created a similar button with:
<a href=”#” class=”ui-btn ui-btn-inline ui-icon-delete ui-btn-icon-top”>Top</a>

I could see that they were trying to be more compact for faster code loading, but the new API (application programming interface) was also harder to remember with all of those ui- bits after growing used to more obvious codes. While the later version offered some snazzier options and special features, I had whipped up my own workarounds for what I needed with some inline CSS code.  So I didn’t have to jump to the newer version. I knew that if I did go to the latest version, I would want to re-work all of the code I’d written over several long days into the new style, since I hate mixing old and new styles in a page. I may not look at a particular page again for months, and I wouldn’t want to have to wrap my head back around two different coding methods.

So I gave up on using a more modern version of jQuery and standardized my site on version 1.2. I gave up some speed and efficiency and would be left without a few new features, but what I had coded was working well and I knew I’d be spending plenty of time polishing it before it could go public. Perfect is the enemy of good; I needed to stick with what I had already started to master. I had a fully operational version completed by July 14 and sent the link out to some administrators for their review. A bit more polishing and then I’d be headed down to Norman for a couple of days.

Homepage of my completed district mobile site

Homepage of my completed district mobile site

When I had some free time in Norman, I toured the vastly improved museum of art (a post on that with photos is still pending). But it was gnawing at me that, while I had checked repeatedly how my mobile site code behaved on my iPhone and iPad, I hadn’t checked it on any Android devices. That operating system is very popular, but I’ve never used Android more than a minute or two, and the only Android device I had easy access to would be Wendy’s Kindle Fire. That unit is older and uses its own fork of Android which is different from the versions on the popular Samsung phones. So while in Norman I popped into their Target store. I found an Android tablet demo unit there and pulled up my initial mobile site. It ran pretty well, with few glitches, and no fatal flaws I could find. That let me relax a bit.

After my conference, with only positive feedback about the new site, I polished it some more and then submitted it to the superintendent for consideration. But I still had almost two weeks before the end of the month, when back-to-school activities really would start to intrude; why not go ahead and use my new district site to help me build a mobile version of the high school site?

As I built another mobile website within the district, I needed to bear in mind a lesson from our district’s experience with multiple regular websites. That lesson will be delivered in the next post.

About Granger Meador

I enjoy day hikes, photography, podcasts, reading, web design, and technology. My wife Wendy and I work in the Bartlesville Public Schools in northeast Oklahoma, but this blog is outside the scope of our employment.
This entry was posted in technology, web design. Bookmark the permalink.

Leave a Reply

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

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

Facebook photo

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

Connecting to %s