RSS

Category Archives: technology

Going Solid State

August 17, 2014
Tubes gave way to solid state

Tubes gave way to solid state

When I was a small child, I would climb up onto the top of the black-and-white television in our living room. It was warm up there, and I would peer through the vents down into the television. Its innards were lit by the dim glow of vacuum tubes. I figured out those tubes were part of the reason why there was a long delay between turning on the set and getting a picture or sound; until they began to glow red hot, Mr. Magoo would not appear. Eventually I would clamber down and sprawl on the floor to watch the flickering gray images. I also remember being bewildered by that stupid lying NBC peacock, which would spread its feathers and proclaim the next show would be in living color…it never was.

My parents finally bought a Zenith color television around 1973, an emblem on its front proclaiming it as SOLID STATE. I wasn’t sure what that meant, except that the warm glow of the tubes was gone and the picture and sound came on very quickly. The peacock was proud and colorful.

Solid state circuits with transistors revolutionized electronics, and now solid state drives are changing local storage on our computers.

Hard disks vs. solid state drives

For decades we’ve relied upon the incredible hard disk drive first introduced by IBM in the 1950s. For years every decent personal computer had one or more of these spinning drives, with their steadily increasing capacity and decreasing cost, as I outlined in my previous post. But in 2010 I bought a laptop computer with no hard drive, a second-generation MacBook Air. I knew its 128 GB solid state drive meant it would boot up very quickly and perform admirably despite its somewhat dated microprocessor, but I was still startled by the performance increase it gained by dispensing with an electromechanical hard disk.

Solid state drives are now commonplace in our smartphones, tablets, and some laptop computers. But it has taken much longer for them to creep into our desktop systems because the old hard disks have so much more capacity and are far cheaper. I finally took the plunge this month of buying a one-terabyte solid state drive for my five-year-old desktop computer, and this post is about my experience of installing and using it.

Cleaning up my system

I debated doing a fresh installation of Windows 7 on the new solid state drive and then re-installing, one-by-one, the various applications I use on my desktop machine. That would clear a lot of cruft from the computer and its registry, but it would mean a lengthy process of locating, re-downloading, and re-installing software packages. Back when everything came on an optical disc, re-installations were fairly straightforward, but now many of my applications are downloaded from the web and I’d have to find download links and locate emails with their registration keys to get them back up and running.

That was too big a hassle for me, but I also wanted to make the image of my existing disk as clean as possible before cloning it onto the new drive. So I used Control Panel > Programs and Features to list the dozens of applications on my system and began working my way through them, uninstalling anything I thought I would not use. Over its five years of use, I have installed on my desktop machine many different video and photo editing applications and accumulated various utilities I needed once or twice and then never again. In the end, I wound up uninstalling over 40 different programs. After a reboot to ensure clean-up from the uninstalled programs, I was ready to install my new solid state drive.

My Crucial M550

My new solid state drive and installation kit

My new solid state drive and installation kit

I had ordered a Crucial M550 one-terabyte drive with a SATA interface from Amazon for $432. I also purchased a $24 desktop installation kit which provided a SATA cable to connect the drive to the computer’s motherboard, an adapter bracket to fit the laptop-sized 2.5″ wide drive into a desktop’s 3.5″ bay, and Acronis TrueImage HD software to help me migrate my system from my one-terabyte hard disk to the solid state drive.

Thankfully Windows 7 is new enough to know how to handle a solid state drive; if a new drive had meant moving to Windows 8, I would have refused. I hated Windows 8 when I previewed it back in the spring of 2012 and the few times I’ve used it since have convinced me to stick with Windows 7. I won’t get a new desktop computer until after the successor to Windows 8 is released; I often skip versions of Windows and have never regretted it.

Installing the new drive

My hard disks before the new drive was installed

My hard disks before the new drive was installed

I unplugged the power and all peripherals from my CPU and opened it up. I had two one-terabyte hard disks; one was the primary drive and the other for backup. Both were connected to SATA ports on the motherboard and to power cables from the power supply.

Four screws that came with my installation kit secured the tiny solid state drive into the wider adapter bracket. The drive is only 7 millimeters thick, which makes sense for a laptop computer, but looks comically thin compared to my system’s hard disks. The bracket then was supposed to be secured in a drive bay by four more screws that came with the kit. But my bay is not easily accessed on one side, so I was only able to easily screw in three of the four screws. It seemed sturdy enough, and solid state drives are much less susceptible than a hard disk to vibration damage.

The new drive installed in my computer

The new drive installed in my computer

Next I hooked one end of the keyed SATA cable which came with the installation kit to the new drive. The other end keyed into an empty port on the motherboard. I found an unused SATA power cord coming out of the power supply and hooked that in. With that, the hardware installation was complete. It was time to tackle the software side of things.

I needed to clone my boot hard disk to the new drive, tell the computer to start booting from the new drive instead of the old hard disk, and then tweak some Windows settings to help prolong the life of my solid state drive.

Cloning my disk

I closed up the computer and hooked everything back in. I flipped on the power and inserted into the optical drive the Acronis TrueImage HD disc from the installation kit. I was fast enough that the machine booted up in Acronis instead of Windows.

The Acronis software listed the new solid state drive and both of my hard disks. I instructed it to clone the boot hard disk C: over to the new solid state drive, which it had labelled as F:. It took 2.33 hours for the 772 GB of data on the hard disk to be copied over to the new solid state drive. I then exited Acronis and the machine rebooted.

Changing the boot settings in the BIOS

Pressing the DEL key repeatedly as it booted up interrupted the boot sequence to bring up the BIOS (Basic Input/Output System) menu where one sets boot options and the like. I changed the boot sequence to first try to boot from the CD/DVD drive, then each of the four USB flash drive slots on the front of the computer. This would allow me to easily bypass Windows if I needed to use a disaster recovery disk or a utility like Acronis. Next in the boot sequence came the new solid state drive, then the hard disk I had been booting Windows on, and finally the hard disk I was using for easy in-the-computer-case backups. (Yes, I also periodically make backups to a portable hard disk which I store off-site.) I saved the settings and exited the BIOS, and hoped that Windows would come up on the new drive.

It worked like a charm, with Windows 7 Home Premium booting up much faster than I’d ever seen before on my machine. I checked in Windows Explorer and verified that I had booted from the solid state drive; it was shown as drive C: while my backup hard disk was now drive E: and the hard disk I had been booting from previously was listed as drive F: (the optical drive is drive D:).

Making sure Windows 7 is being SSD-friendly

I’d noticed that Windows had installed some device drivers when it booted up, and one was for the new solid state drive. I hoped that meant Windows had been told to no longer try to defragment the boot drive and to use TRIM. Hard disks can be defragmented every so often to consolidate files spread out across the disk and speed up the disk’s performance; this was much more important in the old days than it is today with our enormous hard drives. But you should NOT defragment a solid state drive, since the resulting reads and writes simply waste rewrite cycles of the memory without improving performance to any meaningful degree. TRIM should also be enabled on a solid state drive; this changes how deleted files are handled to help preserve the usable life of the drive.

An article at Lifehacker helped me check that TRIM was enabled (it already was) and that defragmentation was disabled on the solid state drive. Older articles had urged disabling the SuperFetch service, relocating the Windows Page file to a hard disk, and the like. Other articles said those changes were not all that important, but I did them anyway, including implementing some more tips from ghacks.net.

The results

The new drive dramatically improved the boot process on my machine, which had become very slow and tedious with the hard disk maxing out as Microsoft Security Essentials and Dropbox and other services did their thing. Here’s a comparison:

Boot item Time after boot from hard disk (minutes:seconds) Time after boot from solid state drive (minutes:seconds)
“Starting Windows” screen 0:26 0:26
Windows password prompt 1:15 0:46
Desktop background appears 2:06 0:53
Desktop icons first appear 2:37 0:53
Windows logon sound 2:38 0:53
Desktop icons fill back in 4:20 1:02
Networking icon shows ready (most start-up services running) 6:40 1:08
Dropbox shows ready 16+ 2:08

As you can see, it was taking forever for my machine to fully boot up – a major reason why I invested in the solid state drive. For years I’ve examined the disk activity via Windows Resource Monitor and seen how processes associated with Microsoft Security Essentials and Dropbox, and sometimes the disk indexing service and iTunes, were maxing out my hard disk’s throughput.

Dropbox and other services were hogging my hard disk after boot-ups

Dropbox and other services were hogging my hard disk after boot-ups

I had used various online tips over the years to tweak various services and settings, but they didn’t help much. Eventually things would settle down, but sometimes that would take 15 to 20 minutes, during which time my system was very sluggish. So I almost never rebooted my machine, and dreaded when a security update or the like would force me to reboot.

The left graph shows my hard disk finally settling down 19 minutes after booting; the right shows my solid state disk less than 3 minutes after booting.

The left graph shows my hard disk finally settling down 19 minutes after booting; the right shows my solid state disk less than 3 minutes after booting.

The two graphs at right illustrate how much nicer things are with my solid state drive. On the left is a graph of hard disk use 19 minutes after a recent boot-up, when the hard disk finally settled down, transitioning back to more normal behavior after continually reading data as fast as it could. The right graph shows the solid state drive’s use less than 3 minutes after boot up; notice the change in the scale of the y-axis: the drive has already read all that was needed for the various services and is just doing minimal background tasks.

So thus far I’m extremely pleased with this upgrade. It will make booting and using my five-year-old machine much more enjoyable and hopefully allow me to stretch its useful life out for a few more years.

I have some nostalgia for that old tube television from my childhood; I remember the glow of the vacuum tubes, the comforting heat they generated, and the smell of hot dust as the television warmed up. But I will never be fond of my memories of the interminable boot times and sluggishness of my desktop computer before I installed the solid state drive. In this case, I’ve gone solid state and won’t look back.

UPDATE: One of my students this year told me that I needed a SATA III port to get the most of out of drive. My 2009 motherboard only has SATA II ports, which have less throughput. So eventually I might invest in a SATA III PCIe card. That would improve throughput even more, although still not reaching the level available on a motherboard-based SATA III port.

 
Leave a comment

Posted by on August 17, 2014 in technology

 

Slimming Down Before Speeding Up

August 17, 2014
Decades of data

Decades of data devices

I’ve been working with personal computers for over 35 years, so I’ve endured seven types of long-term computer data recording and storage:

  1. cassette tapes
  2. floppy disks
  3. hard drives
  4. ZIP drives
  5. tape drives
  6. optical discs
  7. solid state

Each had its pros and cons, and this post was prompted by my plan for another transition in primary storage: switching my five-year-old desktop computer from hard drives to a solid state drive. But first let’s revisit past transitions.

Cassette tape to floppy disk

My first computer was from Radio Shack: a 1980 TRS-80 Color Computer with 32 kB of RAM. It used a cassette tape to store and retrieve programs. At 1500 baud, the data transfer rate was about 4 million times slower than the transfer rate of the new solid state drive I’m planning to install in my current desktop computer. So it took a long time to record or load even the tiny programs of that era, and sometimes a cassette load would fail, meaning I had to fiddle with the volume on the tape player and try again.

My CoCo used cassettes

My CoCo used cassettes

The same technology was available for my 1983 Tandy Color Computer 2, but I convinced my parents to invest in a series of 5.25″ floppy disk drives to improve data capacity and transfer rate. The first drive was made by Radio Shack and the single-sided floppy would hold about 140 kB of data after formatting, which is about 7 million times less storage than my new solid state drive. I learned I could save money by cutting a notch in a floppy disk’s outer jacket and flipping it over to use the other side in the drive. Later I upgraded to a couple of double-sided drives for almost a half-megabyte of readily accessible storage.

First floppies

First floppies

Floppy disk to hard disk

My first hard drive was 10 megabytes in my Tandy Model 2000

My first hard drive was 10 megabytes in my Tandy Model 2000

The first time I remember using a hard disk drive was in the summer of 1985. I was working at the Oklahoma Department of Tourism at the state capitol as a minimum-wage office assistant. At one point I was plunked down in front of an old dedicated Wang word processor terminal. Next to me was a noisy 10-megabyte hard drive about the size of an apartment-size washing machine. But that was a government office, so the technology in use was already obsolete. Hard drives were making their way into personal computers, and I would add a couple of them to my next personal computer.

My 1985 Tandy Model 2000 started out with two 720 kB floppy disk drives, but later I spent $1,700 to add an internal 10-megabyte hard drive to it. Compare that cost of $170 per megabyte, in 1980s dollars, to the 0.043 cents per megabyte I paid for my new solid state storage, or better yet the 0.0057 cents per megabyte I paid for my latest 2 TB portable hard drive.

That was the beginning of an uncounted chain of hard drives I have owned, in capacities leaping from that initial 10 megabytes up to 2 terabytes, a 200,000-fold increase in capacity. Data transfer rates improved over time, with the 1-terabyte hard drives in my latest desktop computer, spinning at 7200 rev/min, reaching as high as 142 MB/s. But the solid state drive I plan to install should at least triple that transfer rate.

Backups of all sorts

The ZIP Drive

The ZIP Drive

Hard drives are great, but their inevitable mechanical failures mean you have to make regular backup copies of the data. The floppy drive was the basis for my portable storage and backup for years, first with 5.25″ floppy disks ranging from 140 kB to 1.2 MB of capacity. Hard drive backups on those floppies were a real pain, with me having to repeatedly swap dozens of 5.25″ disks to make a backup. Eventually hard-shell 3.5″ floppy disks took over, but their typical capacity was only 1.44 MB.

The nightmare of disk swapping led me to the ZIP 100 drive, a specialized floppy disk system which could hold an amazing 100 MB of data. I later upgraded to a 250 MB ZIP drive system. But hard drive capacities were rising so fast that it still took a lot of swapping of expensive ZIP disks to back up my computer.

Tape Backup

Tape Backup

So I went back to the beginning: using magnetic tape for storage. Tape backup cartridges had immense capacity and were much faster than my pitiful old cassettes from the early 1980s, with gigabytes of storage possible on specialized units like the Ditto Easy 3200. I could pop in a tape and let it run unattended during a long backup. But tape backup was noisy and sequential. It took a long time to recover just a file or two from a tape backup, and I always worried about a faulty backup recording or broken tape.

For awhile I used recordable optical CD and DVD disks to backup some data, but they were slow, and my recordable DVDs topped out at 4.7 GB. With my hard drives reaching tens of gigabytes by the 2000s, I needed something easier and faster.

Hard drives can backup hard drives

Hard drives can backup hard drives

So I switched to the kind of backups I’ve been doing for over a decade: backing up my primary fixed hard drives with portable hard drives. I still have my first portable hard drive, a 30 GB Backpack unit. Later I used 80 GB, then 120 GB, and finally 1 and 2 TB portable drives for backups.

And for years I relied upon dual hard drives in my desktop machines in a RAID 1 configuration where one drive was constantly mirroring the other. That way when one failed, the other could take over without a hiccup. Well, that was the theory. While my RAID 1 drives did indeed prevent any data loss when one failed, sometimes it took a lot of work and head-scratching to recover from a drive failure. RAID 1 is not very popular in personal computing, and it is now rather difficult to buy a computer outfitted for it, and the tools for doing it yourself are somewhat arcane.

Nowadays I use Dropbox to keep my most useful data readily accessible and synchronized on my various work and home desktop computers, laptops, tablet, and smartphone. But I don’t want to pay for a terabyte of more of online storage; my 100 GB Dropbox account has about 65 GB of data in it, which is less than one-tenth of the data on my primary hard drive. So I still have to manually backup a lot of data if I don’t want to risk losing it.

Compression

As hard drive capacity increased over time, so did my data storage demands. In one generation of hard drive after another I would begin bumping up against a drive’s capacity. I would try to prune obsolete files and then have to use the Windows Disk Cleanup buried at Accessories > System Tools to regain space, sometimes even uninstalling unused Windows components to regain space. For awhile Windows had built-in data compression software, and that let me stretch the use of my 1993 desktop system all the way to the year 2000. In my next system I avoided using the disk compression, instead adding a second hard drive when I needed more room. But it was a pain to keep some data on a separate D: drive from my boot C: drive.

My Desktop Computers’ Maximum Hard Drive Space

CPU Year Max. Capacity (GB)
1985 0.01
1990 0.14
1993 1.6
2000 85
2004 750
2009 1000

My last big leap in main drive capacity was the terabyte system in 2009, with two mirrored RAID 1 drives. Since then both of those hard drives have failed and been replaced, but it was proved difficult to get them reconfigured for RAID 1 mirroring. So now I have a 1-terabyte C: drive, a 1-terabyte D: drive I use as an in-the-case occasional backup, and several 1 or 2-terabyte portable drives I use for offsite long-term backups.

JPEGmini busily compressing my photos

JPEGmini busily compressing my photos

By mid-August 2014 the one-terabyte C: drive had about 275 GB of documents, 225 GB of digital photographs, 185 GB of music, and 200 GB of miscellaneous files and applications. That data horde is what remained after occasionally offloading data I didn’t expect to need again onto a 2-terabyte shared network drive which I don’t bother to back up. With formatting overhead, I was down to about 50 GB of free space on my desktop’s one-terabyte drive. 5% free space is not a good place to be. I certainly could prune some more data, since some documents date back to 1988 or earlier, but the big unified categories of data capacity usage were my huge collections of photographs and music. I’m not inclined to discard any of my photos, and my music is already-compressed MP3 and AAC files.

So when I heard about JPEGmini on the Home Theater Geeks podcast this week, I quickly tried out the utility, was suitably impressed, and bought it for $20 to optimize the JPEG compression settings throughout my digital photo collection. That has reduced the total space dedicated to photos from 225 GB to around 130 GB. So I have enough space to keep going with my five-year-old system without bothering with a drive capacity increase.

But what has really irked me is the hard drive speed bottleneck in my desktop system, even with fast 7200 rev/min drives. I have plenty of fast computer cores and lots of RAM, but after 5 years of use my Windows 7 machine takes forever to boot up and frequently bogs down because of Microsoft’s disk indexing services and the like. A lot of cruft builds up in a computer system when you install and use various programs and utilities and lose track of things, but even a clean install of Windows 7 and the applications I currently use would be limited by the data transfer rates of my hard drive. It used to be that adding RAM was the best way to speed up an older system, but now the best thing to do is to switch over to a solid state drive.

Hard disk to solid state

My MacBook Air introduced me to solid state drives back in 2010

My MacBook Air introduced me to solid state drives back in 2010

Solid state long-term storage first appeared in the form of USB keys. I’ve used a bunch of them over the years, and have some truly tiny ones with 8 GB of storage. But they were never my primary backup method; I just used them for portable storage. My introduction to the incredible speed and reliability of a solid state drive as the main drive was in my 2010 Apple MacBook Air. It remains my personal portable computer, and I am still surprised by how quickly it boots up and how it remains quite snappy despite its terribly outdated 1.6 GHz Intel Core 2 Duo microprocessor with 4 GB of RAM. That pales in comparison to the Intel i7-920 microprocessor with four 2.66 GHz cores in my five-year-old desktop computer with its 8 GB of RAM, but the MacBook Air seems brisk because of the speed of the solid state drive. And while I have backed it up a few times, I’ve never really worried about its data. Someday the solid state drive will reach its end of life and become unreliable at retaining data, but I’m pretty sure the computer will be so obsolete by then I will have already abandoned it.

Until now, capacity limits and costs prevented me from considering switching my desktop computer over to solid state storage. My MacBook Air’s solid state drive is only 128 GB, and I do not want to hassle with a solid state drive for booting, applications, and often-used data coupled with a separate spinning hard drive for the rest of my data. I want everything on the same drive, and I need a terabyte of storage to pull that off.

On a recent This Week in Tech podcast, guest Allyn Malventano mentioned his reviews of solid state drives and said that prices had fallen and Crucial had a one-terabyte solid state drive that was a good bargain. I verified that report and ordered the drive, along with an adapter kit to fit it into my desktop machine since it is sized for a laptop computer’s form factor.

In the next post I report on buying, installing, configuring, and using that drive in my 2009 desktop computer. As you have seen in this post, it is the latest link in a long chain of data leading back to my childhood. I’m hoping it will extend the use of my 2009 desktop computer for several more years.

 
1 Comment

Posted by on August 16, 2014 in technology

 

Mobile site design tips

August 1, 2014

Browsing on small screens is a challenge

Browsing on small screens is a challenge

In the previous series of posts, I have outlined why the increasing number of mobile browsers being used on our school district websites led me to develop a new mobile website for the district. My next target was to build a similar mobile website for the high school, but my previous post described the problems our district has had with inconsistent websites, so I was determined that the two new mobile websites avoid those problems. I also needed to think about how to structure the high school mobile site to duplicate the functionality of the regular high school site, which is more complex than the district website, while keeping navigation easy and mobile-friendly.

In this post I discuss the deliberate design differences between the two mobile websites, features on the mobile site which helped address the complexity of the regular site’s navigation and content for small screens, the issue of when and how to redirect visitors to a mobile site, and designing alerts for the mobile site.

Similar but different

I needed to walk a fine line on how to make the two new mobile websites similar but different. I couldn’t make the high school mobile site look just like the district site, or users would become confused as to which site they were using. But I also did not want the shift from one to the other to be too jarring.

For the homepages, I used the same color scheme to unify the designs. But I used a different background color for the headers and adorned each homepage with a different upper-left corner graphic. I also used a different style of search and back buttons in the headers for the two sites.

UPDATE: Later I changed the styling of the upper right header icons at the high school site to resolve some issues with title text.

If you play “What is different?” you should also pick up on how I deliberately inset all of the main buttons on the high school website, whereas the district site’s buttons extend across the full width of the mobile screen.

The most obvious difference was how I included on every page of the high school mobile site, including the homepage, a horizontal button bar at the bottom of the header. It matches the primary entries in the regular site’s top horizontal button bar with its entries for News, Bulletin, Calendar, and Contact. While having these functions always readily accessible is nice, I was really more motivated by how that would distinguish the high school site from the district one, which has no recurring button bar in its headers.

A button bar in the header distinguishes the high school mobile site

Different header colors and buttons distinguish the two mobile sites, along with the high school site’s header button bar

That way, no matter where you are in either site, there are several distinguishing characteristics to help keep you oriented. The limited screen size meant I did not want to expand the header to include more than a simple title on each page. People are always reluctant to scroll, so it is important to keep as many buttons visible as possible on the initial pageload. Below is a comparison of pages situated one level deep at each of the sites; note the various subtle changes.

Different headers and buttons help distinguish the two mobile sites

I also used full-width buttons on the district site versus inset buttons on the high school site

When visitors did scroll down far enough to hide the header, I still wanted visual clues as to which site they were using. The inset buttons on the high school site were my solution, plus a different color scheme and button style for the footer. Since the footer concludes a page, I felt free to add “Bartlesville Public School District” to the district footer below its discrete buttons, but felt that adding “Bartlesville High School” to the high school footer’s button bar did not blend well with its rectangular design. So I put “BHS” on the central button itself.

UPDATE: Later I discovered how to keep the header visible at all times and opted to do that, although I kept the high school site’s button bar out of that always-visible header.

The footers of each site are also quite different

The footers of each site are also quite different


Navigational differences

Resources page links appear only on the homepage of the BHS mobile site

Resources page links appear only on the homepage of the BHS mobile site

The comparison of the two footers also points out a navigational difference between the two sites. The high school site includes in its footer a direct link to the district’s mobile site, but of course the district site doesn’t return the favor.

Instead it just has a little information button which gives me credit for the site, provides an email link for feedback, and provides brief instructions for converting the mobile site into a homepage icon on iOS and Android mobile devices. That same information is more hidden on the high school site; it appears as a “Website issue?” entry in the Frequently Asked Questions nested lists in the various Resources pages.

Those Resources pages provide specific sets of links for students, parents, staff, alumni, and visitors. They’ve been a part of the high school site since 2009 and are thus carried over to the lower part of the mobile site’s homepage. They are a good example of the space dilemma one confronts on a mobile site, which does not concern me much on a regular site with plenty of screen real estate. While on the regular site you can always see those resources links along with several other sets of links, the mobile site steadily displays only a select group of links.

More complex navigation at BHS

The high school’s regular site has three main navigation areas: key functions in a top-of-page button bar, links to specific programs in a “Life at BHS” left sidebar, and the audience-targeted Resources links below that on the left sidebar. This is considerably more complex than the navigation at the district’s regular website, where everything is sorted into six areas with a single horizontal button/menu bar below the header (plus groups of links buried way down in the footer).

The more complex navigation layout for the high school’s regular website reflects the great quantity and depth of information on it; in some cases the links nest into one another four levels deep. For example, information on facility additions made in each decade are shown under:

About BHS > Facility History > Campus Additions > 1990s, etc.

To keep people from getting lost down there, selecting “About BHS” reveals a second left sidebar for that link’s entries there. Picking one of those links then reveals a nested button list of additional choices. I like using vertical sidebars for this because it keeps the various choices visible while also providing a continual reminder of where you are at in the structure by using boldface list entries, nested bulleted lists, and > signs. This is more powerful than simply displaying a linked chain of nested choices, a la “About BHS > Facility History > Campus Additions > 1990s.”

Multiple left sidebars on the regular BHS site keep visitors oriented in the deeper levels of the structure

Multiple left sidebars on the regular BHS site keep visitors oriented in the deeper levels of the structure

All that has worked fine for the regular site, but a mobile site doesn’t have that luxury. No one wants to click on tiny text links which are always displayed; you want whatever you are looking at to be the main focus and to rely more on scrolling than anything else to stay oriented.

So on the mobile site I dropped all of the visible left-sidebar links; you have to go back to the mobile homepage to reach another “Life at BHS” area or access a different audience-targeted Resources page. But those links are always just one click away using either the Homepage button at the top left or bottom left of each page. Notice how they are both on the left side; consistency is important to website visitors.

I used thumbnail list buttons for photos

I used thumbnail list buttons for photos

And sometimes I just didn’t try to convert things into mobile format; the high school site’s extensive entries on school and facility history have no mobile equivalent. If you select them from the mobile site, it just plops you back in the regular site. The message is that if you want to read all of that text, go get a bigger screen. But for more visual items, such as the collection of facility photos, I did take the time to build out an elaborate set of pages with a link to every photo. And each of those links includes a thumbnail view of the photo it links to. That lets users select based on the photo itself as well its description. Selecting a photo link displays the photo, with a caption, in a pop-up window resized to the device display. That avoids creating another page and is visually and operationally more simple than using an accordion list, a feature discussed below.

Choosing what to include and what to omit

I also took the time to create full mobile versions of the faculty and staff listings, both the long alphabetized list and a departmentalized one, with the latter adding thumbnail photos and buttons for email and web links. Again what you include depends on your goal and the screen size: someone using the long alphabetized list is probably just searching for an email link, so don’t lengthen that list with thumbnails and big buttons. Just include a job title to help reassure them they have the right person.

Someone looking at the departmentalized groups is likely more interested in things like a photo and web links. Also note how the email buttons in the alphabetized list have labels showing the person’s email address username, reflecting the focus of that listing, while the departmentalized groups go for easy navigation with a big “Email” button. The limited screen size meant that the buttons in the alphabetized list had to be smaller so that long usernames could fit without line-wrapping an entry; for a long list you want to keep the entries a consistent size for easier navigation.

The long alphabetized list omits the thumbnails and buttons shown in the shorter departmentalized groups

The long alphabetized list omits the thumbnails and website links shown in the shorter departmentalized groups


Accordion lists

So what else does the mobile site use to tame the navigational complexity? One trick I used a lot was expanding “accordion” lists. Those are single or grouped buttons which don’t load another page when tapped, but instead open up to reveal information or another set of links. That allows the mobile site to have fewer pages while keeping a page from getting too long. You expand the page only when asked, plus when someone opens another area in the same accordion group, the previously open area closes as a new one opens. That keeps the page from expanding again and again to awkward length and speeds up navigation. The user can scroll just outside of the currently opened item to quickly select other items above or below it, and also scroll more quickly to the header or footer.

All that is well and good, but the user has to realize how it works. So you want the accordion list to be clearly different from a regular button that goes to another page. jQuery swaps out the usual > icon at the right edge of a button with two different icons on the left end of accordion buttons. A + icon appears on closed items and a – icon on open ones. That is pretty clear guidance as to what is going on.

jQuery also automatically insets accordion lists, but on the high school site I was already insetting entries and I didn’t like mixing full-width buttons with inset accordions on the district site, so the insets wouldn’t help distinguish the accordions. Thus I chose, on both mobile sites, to emphasize that accordion lists were different by changing the colors of their buttons. I made them blue so that when an item opened up, the blue buttons of the neighboring accordion items would form obvious borders to the opened content. That would help folks realize what was going on when they scrolled out of larger opened items.

Accordion lists are a great tool for mobile sites

Accordion lists are a great tool for mobile sites

The FAQ accordions use smaller buttons to fit more questions on the screen

The FAQ accordions use smaller buttons to fit more questions on the screen

The screenshots show I used accordion lists both for sets of links and textual information. On the right is an example of a nested set of accordions; a large “Sponsored Student Activities” entry is part of an initial accordion list, but when you open it you find another set of accordion entries for the various organizations. That lets you build a lot of information into a small display space without requiring endless scrolling.

A variant on the nested accordion is the FAQs on each resource page; I used the “data-mini=’true'” option there to fit more of the FAQs onto the screen. The smaller button also reduced the size of the button text, allowing me to squeeze more question text onto each button.

Form select menus

Another trick I used to squeeze more onto the screen was form select menus. Website forms include various functions such as text input bars, radio buttons, checked items, sliders, toggle switches, etc. But the select menu is what interested me. A form will then display, using the operating system’s own formatting if you like, a list of items the user is to pick from. This is best used for a list of closely-related items which is too long to comfortably fit on the screen.

I used this type of input for state report cards on the district site, since there are so many different groups of them and every group had the same list of school sites. Accordion lists were not a good choice in that case because one expanded entry would look just like another: a long list of the same sites. You could easily get confused as you scrolled back and forth.

By using a select menu, I could keep more of the different groups of reports cards visible and let the device’s software provide the most convenient method of selecting an item. For example, opening a select menu on an iPhone produces the three-dimensional illusion of a scroll wheel of items on its small screen, whereas opening the same menu on an iPad produces a text box of entries for you to pick from on its larger display. The iPhone’s styling makes it easy to scroll and select an item with your thumb as you hold the phone. The iPad is likely used two-handed or while propped on something, so tapping with a finger on an item in a smaller text box is more practical on it than on a tiny phone.

Form select menus render differently on iPhones versus iPads

Form select menus render differently on iPhones versus iPads


“Go Back” buttons and a deliberate inconsistency

The homepage swaps the go-back button for an escape hatch

The homepage swaps the go-back button for an escape hatch

Another important navigational feature of a mobile website is the “Go Back” button, which displays the previously viewed page. In an environment with limited navigational controls, users often want to return to where they just were to select a different item or re-orient themselves. Nowadays many mobile browsers, such as Safari on iOS, maximize the screen real estate for a webpage by hiding the usual address bar and forward/backward web navigation buttons. That meant I chose to include a “Go Back” button at the top right of every page of each of the mobile sites to make that an easy option for the user.

But that isn’t quite true; there is one page at each site which lacks a “Go Back” button…the homepage. Why did I create this obvious inconsistency? Because the homepage is special; it is the anchor for all of the site’s navigation. You can go back to the homepage, but then you are not allowed to easily “Go Back” to a different level in the webpage’s structure. That emphasizes that the homepage is the starting point and also prevents someone from tapping the “Go Back” button repeatedly and having page-load latency mean they start looping wildly through the site.

So on the homepage I replaced the “Go Back” button with a large labeled button that takes you to the regular website. That killed two birds with one stone: it got rid of the “Go Back” button on the homepage while replacing it with an important feature for that page: the escape hatch. I will soon begin redirecting anyone who visits the regular websites’ homepages on a small screen to the corresponding mobile homepage. Below I’ll explain why I’m being so pushy, but I also know that anytime I force someone down a different path, I had better provide an escape hatch in case they didn’t WANT to be redirected.

Sometimes people don’t want to be on the mobile site; they want the regular site even on their tiny screen. So a mobile site should always include an escape hatch on every page; I included it not only at the top of the homepage but also in the footer on every page of the mobile sites.

Will that mobile user really be happy about the redirect?

Will that mobile user really be happy about the redirect?


The controversy on mobile site redirects

Informed people argue back and forth about whether someone trying to access a regular website on a mobile device ought to be redirected to the mobile-friendly site or not. Since many people will not discover the mobile-friendly site on their own, and it improves the web experience so much on tiny browsers, I think folks should be redirected to it when they are using a small screen. But you have to include an escape hatch in case they prefer the regular site, get confused, or somehow the redirection occurs when it shouldn’t.

Once I decided I did want to redirect, the next question was when and how. Web browsers include in their page requests information about the viewing screen size, the browser make and model, and the device. Any of that information can be falsely reported, but it does let you detect when someone reports that they are using a certain browser, device, or screen size. So when do you decide to force a redirect?

Some people argue that you should only redirect specific devices. For example, redirect iPhones but not iPads; redirect iOS and Android devices, but leave alone less popular devices which may not properly display the mobile site. Others argue that you base the decision on screen size, and I agree with that view.

I cannot take the time to maintain code to test for the latest and greatest in the blizzard of devices coming onto the market. And the whole point of the mobile site is to make things easier on small screens. So I wanted the redirects to occur when the screen size was smaller than a tablet’s typical resolution, thus targeting smartphones.

As for how to accomplish the redirect, the simplest choice seems to be this bit of Javascript code in the webpage header of a regular site’s page:

<script type=”text/javascript”>
if (screen.width <= 720) {
window.location = “mobile/default.html”;
}
</script>

If someone loads the page while on a device with a display that is less than 721 pixels wide, they’ll be redirected to the mobile website. I plan to activate this code on the homepages of the respective regular websites, but I did not want to do that without warning. No one likes big surprises, especially the average joe who is not overly familiar with web interfaces.

Of course redirection really isn’t as simple as the above code snippet. If that were all I did, then problem a) would occur: someone using the link on the mobile site to see the regular homepage would just be redirected back to the mobile site again. That has to be prevented, along with problem b): someone on a mobile device selecting the regular homepage, navigating elsewhere on the site, then returning to the homepage only to be redirected again to the mobile site. Problem b) is fairly common merchant sites, even large operations, and it is very annoying.

I could alter the links to the regular homepage throughout the mobile site so that the redirection code is disabled when they are used, but that would only fix problem a). Setting a session “cookie” that requests the regular site instead of the mobile site is a better solution. (A “cookie” is a bit of information you ask the user’s browser to remember for you; session “cookies” only last during a given session with the browser, while permanent “cookies” are stored for use in future sessions.) I might also use a “landing page” approach where small-screen users hitting the regular homepage are always asked if they prefer to see the mobile or the regular site before proceeding, with a timer that eventually kicks them to the mobile site if they don’t respond. I’m not used to doing any of this, since the only redirection I’ve used previously is a simple timed or immediate redirection to a new page when someone visits a page that has been superceded by some replacement located elsewhere.

A mobile link was added to the header of every page on the regular site

A mobile link was added to the header of every page on the regular district site

All of this complexity meant that when the mobile websites launched, I did NOT include the redirect at first. Instead I mentioned in the news announcement about the sites that in a couple of weeks users on small screens would be redirected, with an immediate reassurance that a link back to the regular website would be available on every page of the mobile sites. That provides a sense of fair warning. Meanwhile, I added a mobile link to every page of the regular sites so that folks could trigger the mobile site if needed. And I made sure the various links between the regular and mobile websites matched up: the mobile button on the regular search page takes you to the mobile search page, while the regular-site button on the mobile search page takes you to the regular-site search page, and so on throughout the sites. This helps users recognize that every page has an equivalent on the other site and access it more readily..

The high school site header bar also got a new mobile link

The high school site header bar also got a new mobile link

I decided to not include a redirect on pages other than the homepage. I did not want to drop someone into the mobile site willy-nilly; a forced redirect only occurs on the homepage. That way if someone uses a link to a sub-page on the regular site, they’ll always see the same thing. I don’t want links to sub-pages to give varying results; that sows confusion. And if someone is going to save and distribute links to sub-pages, I want those to go to the regular site, not the mobile site: the mobile site is NOT suitable for a large-screen display. Someone on a small screen who follows a link to the regular site can always invoke the mobile site with the links I’ve included in every regular page’s header.

UPDATE: When I implemented redirection for both of the mobile sites on 8/14/2014, I used a script installed only on the homepage of each regular website. The script checks the screen size and if it is less than 721 pixels it displays a dialog box. The visitor chooses “OK” to be redirected to the mobile site or “Cancel” to stick with the regular site. The script is smart enough to notice if the visitor just came from the mobile site’s homepage and in that case suppresses the dialog box and displays the regular homepage. This approach avoided having to modify every link to the regular sites on the mobile sites to include a cookie and then having to check and clear a cookie to avoid redirection loops. I think visitors can tolerate the minor inconvenience of the dialog box appearing when a visitor tries to visit the regular homepage on a small screen.

Alerts

BHS Mobile alert page

BHS Mobile alert page

Another precaution for the forthcoming redirection of small screen users is that I put a “New mobile website” alert button on the mobile website homepages. That provides an explanation for when the redirects begin and for folks who stumble into the mobile site on their own. Alerts are important for these sites for notifying visitors of inclement weather closures, vital deadlines, etc. I use blue and red-bordered text boxes for alerts on the regular high school site’s homepage, and a scrolling marquee on the district site’s homepage. Those elements simply disappear if no alerts are in effect. For mobile, it was obvious to put a big yellow button for an alert right below the header area. But then what?

Should the alert button link to a pop-up box? How about a separate page, kept in its own file on the server? Neither of those options worked out, although I tried both of them. I thought a pop-up box made sense, but when I implemented it in jQuery Mobile 1.2.0, closing that pop-up box was a problem. Sometimes I fumbled with the close target on my iPhone, and I noticed that re-invoking the alert made closure even more difficult. Also, while I had used pop-ups to enlarge photographs on the site, they are problematic for text. What if the text exceeds the screen area? Do you really want to scroll a pop-up? That isn’t intuitive.

So I gave up on pop-up alert boxes and tried invoking a dialog box loaded from a separate server file. That also suffered from the hard-to-close problem and the scrolling-box issue, and also meant I’d have to edit both the main mobile HTML file and a separate alert HTML file for each alert. That was too much work, especially since some alerts need to go up ASAP.

So I finally just had the button link to another internal page in the main HTML file, but coded that page’s header with a yellow theme, eliminated the usual header button bar on the high school site, and included a dedicated button at the bottom of the alert text to return to the homepage. Each of those changes would emphasize that an alert was important, different, and fell outside the usual navigational structure of the site.

That wraps it up

That wraps up my five consecutive posts on web development:

If you are a school district patron, I hope you enjoy using the new mobile websites. A lot of thought, care, and time went into their design and development; I sure hope it pays off for you.

 
Leave a comment

Posted by on August 1, 2014 in technology, web design

 

Our district’s multiple personalities on the web

July 31, 2014

In a previous post I outlined how the visitors to one of our high school websites showed a dramatic shift away from large screen PCs to small-screen mobile devices. That led me to build a new mobile site for the school district. With that ready to go by mid-July, I still had time before the start of the new school year to create another mobile site, one for the high school.

I knew right off that I’d want the high school mobile site to be similar to the district one, so that the modal transition between the two would not be too jarring. I knew this was crucial because, for well over a decade, our district has suffered from multiple-personality-disorder amongst its various websites. I explore that problem in this post.

Our websites’ multiple-personality-disorder

For many years none of the district’s websites were alike. Each had its own layout and structure, navigation system, colors and theme – the whole works. There was no sense of continuity for parents who might have children at multiple school sites, nor for the public accessing different district websites for information. Some sites had very outdated code, leading to malformed pages. Overall it was an idiosyncratic mess.

Until 2014, every website had a distinct design

Until 2014, every website had a distinct design

Those failings were due to the homegrown nature of the various websites. Each was initially built by a volunteer webmaster without any direction from the district. Eventually the site principals at the uppermost grade levels began paying a staff member to act as that site’s webmaster, but the elementary and middle school sites are still run by altruistic staff volunteers. To my knowledge, the district didn’t even earmark any funds for the district-level webmaster until it began paying me a small stipend in August 2012.

Using iframes to create a district border

I now embed school websites in a district-level iframe

I now embed school websites in a district-level iframe

In 2013 I took the first step to bring some order to this chaos. I reformed the district site’s link to each individual school site so that the school website displayed in an iframe. That let me keep a simple header navigation bar for the district site at the top to indicate that a viewer was still in the district’s website system.

However, using a basic iframe created a kludge. It forced the school’s website into a restricted window and was annoying, especially for scrolling content in the separate iframe window. So I made sure to include an obvious link just above the iframe that would open the school’s website in a full window, eliminating the frame.

Finally this summer I discovered how to use Javascript to automatically size the iframe to a school’s website if the school website’s files were located on the local server. So for those sites I now customize the iframe’s height and eliminate the frame’s scroll bars. Unfortunately that trick doesn’t work with sites hosted elsewhere (which is what is done for most of our sites now, as you’ll see below).  So for them I had to just set an arbitrarily large height for the iframe. This still simplifies the appearance to one window with one set of scroll bars, but it causes many pages to have immense blank footers. I found some of our websites have pages running over 10,000 pixels high, which isn’t good design, but you get what you pay for. I left the option above the iframe to escape it and reload the site in the full window.

UPDATE: At the start of the school year I kept running into link issues with the different school websites when embedded in an iframe. If links did not include target=”_top” they often did not work in some browsers. Since most of the websites are now more unified in their look and feel, as described below, I decided to stop using the iframe banner approach.

A new unified look-and-feel across most of the school websites

In 2013-2014 the district’s Teacher Specialist for Instructional Technology worked with the various volunteer webmasters for grades PreK-8 to migrate their websites to the MyBigCampus service the district has as part of its Lightspeed internet services agreement. At this point seven of the eight sites have moved to that service, with a consistent use of a header with a photo of the school and a horizontal menu bar. The body of the pages all use a white background. This has considerably unified their look and feel.

Six sites now use MyBigCampus, providing a more consistent look and feel

Seven of our district websites now use MyBigCampus, providing a more consistent look and feel

The remaining website design outliers are one elementary school, the Will Rogers Complex, the mid-high, and the high school. I presume that MyBigCampus could provide what is needed for the remaining elementary school and the Will Rogers Complex, so hopefully we’ll get those into the design fold. The mid-high site will be eliminated in August 2015 when grades 9-10 become part of the expanded 9-12 high school. That leaves the high school website to consider.

But what about the complex high school website?

The Freshman Academy poses a website design challenge

The Freshman Academy poses a website design challenge

The site for grades 11-12 at the high school is already far too complex for the MyBigCampus service, and it will only grow more complex when the school expands to grades 9-12 in August 2015. I will either need to expand the existing design or re-think it entirely.

I’ve put a lot of work into the existing site, so I’d hate to start over from scratch, but the Freshman Academy creates a website issue that needs to be resolved. 9th graders will have most of their classes in a distinct area of the campus. They’ll have their own bell schedule, cafeteria period, administration, counselor, office, and library. So I’m leaning toward them having their own distinct website.

A potential way forward

I’m hoping that the Mid-High’s current webmaster, who is slated to be in the new Freshman Academy, will still be paid to run a new Freshman Academy website. It could link over to the 10-12 website as needed for shared content on news, services, campus information, and the like. We could stick with hand-coded websites or try to move one or both sites to a cloud-based web service for easier development and maintenance. If we went to a cloud service, it would need to have mobile-friendly responsive design.

Thankfully we still have a full year to work all of that out. Meanwhile, in July I had a mobile version of the high school website to build, and I wanted it to work very much like the district’s mobile site, but with just enough differences to orient a visitor as to which mobile site was being displayed. Addressing that problem, and how to deal with the more complex structure of the high school website in the mobile environment, is the focus of the next post.

 
1 Comment

Posted by on July 31, 2014 in technology, web design

 

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 mobile.weather.gov 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.

 
Leave a comment

Posted by on July 30, 2014 in technology, web design

 

The shift to mobile browsing means other shift happens

July 30, 2014
Mobile browsing was once impractical

Mobile browsing was once impractical

Yesterday I posted about how my various websites are a mix of hand-coded HTML and hosted free services. Google Sites offers an option to “Automatically adjust site to mobile phones” which will try to sort things into a single column and scale the graphics accordingly. That works fine on a simple site like the news sites for the high school and district as well as the district technology support site. But the more complex BruinBond.com I created for bond projects looks terrible on a phone screen when I enable that setting.

This MEADOR.ORG site is mobile-friendly, with the menus and sidebars tucked away and posts converted into a stream of text interrupted by same-size embedded images. But the complex sites I coded for the high school and the school district are NOT mobile-friendly. The high school site’s design dates back to 2009 and the district’s to mid-2012. The way folks are accessing those sites have shifted considerably over those time frames, as we’ll see below.

Zooming in on the district site makes navigation difficult

Zooming in on the district site makes navigation difficult

You can zoom, but can you navigate?

Granted, both of those multi-column sites with headers and footers are coded with Cascading Style Sheets (CSS), which means they have a logical structure (created by DIV tags) which mobile browsers can interpret for smart zooming. I can tap on those sites and my iPhone knows which column or graphic to zoom in on. But zooming in means you can no longer operate the navigation menus without a lot of scrolling or going back to the tiny un-zoomed view. That is a real pain on a tiny phone screen.

Now most people are mobile when surfing the net

The shift toward mobile web browsing

The rapidly expanding use of smartphones for web browsing means that websites designed only for use on personal computers and large tablets are no longer serving the public well. At the start of this year, mobile apps overtook PCs in U.S. internet traffic. Nielsen supports that finding, with its data that U.S. adults now spend an average of 34 hours per month using the internet via smartphones, while spending only 27 hours per month using the internet with a PC.

We don’t have good analytics on our main sites, which are hosted locally. But I have run Google Analytics for years on the high school’s separate news site. A review of that data shows a dramatic migration to mobile devices. Four years ago, only 2% of visits were made using a mobile device. Last year 29% were on what Google terms a mobile device, plus another 8% were on tablets. So our existing websites are probably not easily navigated by 29% to 37% of the viewers.

People are switching to mobile devices

Our audience is shifting to mobile devices

Schools are hardly speed demons when it comes to technology, but eventually we do react. The ever-increasing prevalence of students with smart phones is an indicator every teacher is aware of, but the web statistics show just how much things have shifted in the past few years. That convinced me we had to change our sites to be more mobile-friendly. The challenge was how to accomplish that despite a non-existent budget and my own unfamiliarity with mobile-friendly site design. My next post is about my search for a solution.

 
Leave a comment

Posted by on July 30, 2014 in technology, web design

 

To HTML or not to HTML?

July 29, 2014
I like to code...do you?

I like to code…do you?

This post is a long history of my website development efforts in the school district where I work. I provide a thorough overview of the websites I maintain and how they are hosted and coded. This nerdy navel-gazing retrospective was triggered by the several weeks I spent this summer coding mobile versions of the websites for our school district and high school. This the first of five consecutive blog posts in which I elaborate on that coding adventure.

Frankly, while this history is of interest to me, it really might not interest you. So if you don’t relish reading about every website I run and how it is hosted and some background on why I use various services and software, please feel free to click away from this post. If you’re into visuals, you could pick out a set of my travel photos to peruse. Or check out the big multi-post summer trip travelogue about the trip Wendy and I took along Route 66 this summer, which is chock full of scenery and art.

Okay, that pared things down to the truly nerdy, right? Here we go!

My old bulletin board machine

My 1989 bulletin board machine

It Started as a Hobby

I have been hand-coding HTML websites for almost two decades, and before that ran a couple of primitive dial-up bulletin boards dating back to the early 1980s.  The only computer courses I ever took were a high school course in BASIC in the early 1980s and a college course in FORTRAN in the mid-1980s. So I acquired my knowledge of HTML from trial-and-error coding based on the source code at various websites, various web tutorials, and good tips back in 1998 from Vincent Flanders’ books based on his venerable Web Pages That Suck website.

I learned HTML by doing, not studying. But learning how to improve and update my code with CSS (cascading style sheets) was another matter. Its nesting and different cascades of styles was bewildering until I picked up and carefully read David Sawyer McFarland’s CSS: The Missing Manual back in 2006. I was using the first edition of that book; I see he’s up to the 3rd edition now and I’ll bet it is just as invaluable.

I recommend this book for learning CSS

I recommend this book for learning CSS

I’m hardly a CSS expert, but I can figure out what is going on eventually. It became much easier to cope with when I shifted from an old web editor to Adobe DreamWeaver CS6. I’ve only tapped part of the power of that program, which has many tools to help you figure out what to do and, perhaps more important, what has gone wrong in your code.

But for some websites coding everything by hand is not necessary, or even the wise thing to do. I have written before about my evolving personal websites, with me eventually switching from a hand-coded website, hosted by my cable provider, to the Blogger service and then finally to WordPress.com in 2008. Using the blog services makes creating posts far easier than hand-coding, and I don’t need fancy layouts for blog posts. So long as I can plop in and scale to my liking some linked photos with the text, I’m set for blog posts. I’m still quite happy with the existing design of MEADOR.ORG and the editing capabilities and free hosting at WordPress.com, but I know that someday this site will need another overhaul. But hopefully that is far in the future.

Now It’s More Than a Hobby…A Bit More

I’ve created many websites over the years; some were for my personal hobbies like local history, and several were pro bono public services for local foundations and the like.  But I am actually paid to code and update only two websites: the ones for the Bartlesville Public School District and also for Bartlesville High School. Mind you, I’m not paid much for those duties at less than $7 per day for them both, but something is better than nothing for us woefully underpaid classroom teachers in Oklahoma.

The high school's homepage

The high school’s homepage

I took over the high school website back in 2004 and have fully re-vamped its look a couple of times, with the last major overhaul back at the start of 2009. Back then I thought I might shift the site to a free hosted service, such as Google Sites, but in the end I only used Google Sites for the news items at the school, since several have to be posted each week. I like the ability to have a scrolling feed of posts on the homepage which visitors can select from.

In February 2012 I did set up a full website via Google Sites, one devoted to instructional technology support for the district’s teachers. That superceded a long series of hand-coded help pages I’d created over the years on the high school site.

A Coder, A Coder, My Website for a Coder

BPSD Homepage

The district’s homepage

Back in 2011-2012, the district’s volunteer webmaster left; yes, the district website was being done pro bono by a helpful district technician. The district’s continuous budget woes meant that it still did not want to invest in a managed content website from a provider like SOCS; we still leave that to richer and bigger districts like Jenks. So the district’s website stagnated and by the end of that school year I was desperate for an update – desperate enough to roll my own version in HTML.

Without anyone’s prompting, I coded a new version of the district website and presented it to the administration. They adopted my replacement version and the very sweet school board members bought me a sizable gift card out of their own pockets. Remember, school board members in Oklahoma do a lot of work for zero pay; most are as altruistic as the teachers they employ.

To its credit, the district then managed to start paying me a stipend for maintaining the district site. That goes along with the stipend my principal pays out of her site budget for me to run the separate high school website. Those stipends have enabled me to keep making steady refinements to the sites and keep up with the many changes in documents and links which everyone needs done.

Out-of-Pocket if not Out of My Mind

Wouldn’t you rather code on this?

Mind you, the district is so underfunded and Oklahoma school finance so restricted that I still am out-of-pocket some expenses. State school finance laws meant that I could only use a district-provided copy of the Adobe Dreamweaver website development software at home if I restricted myself to using it on a years-old school laptop. That’s hardly appealing when I am used to coding on my decent home desktop machine using a 24″ main monitor for coding and a smaller adjacent monitor for previewing. So in September 2012 I spent $179 out of my own pocket to purchase a home copy of Adobe Dreamweaver CS6. I’m still relying on it because Adobe has gone to a subscription model and no longer sells stand-alone copies of DreamWeaver. I’d need their Creative Cloud bundle to get DreamWeaver updates, and that carries a regular price of $30/month. Even with my educator’s discount, it would cost $20/month, meaning I’d have to shell out over 10% of my annual webmaster pay to have the Creative Cloud on my home machine. My webmaster pay is too little to take that kind of hit, given that I’m already shelling out $90/year for my personal subscription to Microsoft 365 for use on my Windows desktop, Macbook Air laptop, and iPad tablet computers.

Why Not Use Cloud Services?

mybigcampus

Most of our district sites have switched to MyBigCampus

So the extremely limited budget means that I’m sticking with my old DreamWeaver and free cloud services to keep our sites running. This summer, tired of hand-coding the homepage’s news items, I set up a district headlines site via Google Sites as I had done previously for the high school. And our district’s Instructional Technology Teacher Specialist has been training the elementary and middle schools’ volunteer webmasters to migrate their school websites to the MyBigCampus service our district gets with its LightSpeed internet services contract.

MyBigCampus is far too limited to be used to replace my existing high school and district websites, and while I could try to approximate them in Google Sites, the design limitations and storage restrictions would be onerous. So I’m still hand-coding the suckers. Eventually I suppose the district will pay for a managed-content system that not only makes building and maintaining the district and school websites easier, but more importantly provides teachers with easy ways to build their own course websites and calendars. But until then we’ll be using Google Sites and Weebly and MyBigCampus and the like.

I use Google Sites for the local teachers' union website

I use Google Sites for the local teachers’ union website

I use several free cloud services for website hosting and development. Google Sites not only handles the district news and technology support sites, but also the site for the local teachers union. Facing a slew of curriculum revisions, I’m thinking of shifting the old hand-coded Science Department website over to Google Sites as well.

I also use Weebly to sell my physics curriculum, and found the very-cumbersome-but-free AwardSpace to host my site on local history after my local cable company stopped providing web hosting.

There are also more advanced for-pay services out there, such as SquareSpace with its mobile-responsive design and drag-and-drop interface. The catch there is the for-pay part.

Do It Yourself If You Want It Done Your Way

The truth is that if you really want to control every aspect of a website, nothing beats coding it yourself by hand. And if you can’t spend any money, there are decent free services, but they all have significant design limitations. So I still hand-code the district and high school websites, my pro bono site for the local school foundation, a site about the history of our school district facilities, and the sites for our science department and my own physics classes. Those sites are pretty stable, and until July 2014 I hadn’t really learned much new in HTML for several years.

Learning to code for mobile devices

Learning to code for mobile devices

BUT…I did learn a lot of new HTML over the past few weeks. Why and how? Because I decided to bite the bullet and tackle a shortcoming of my district and high school websites, one which was becoming very problematic in this age of smartphones. I needed to create mobile-friendly, touch-friendly versions of each site. And I did not know how to do it. So I learned how to do it the way I acquired most of my knowledge of HTML…by playing around with the editor software, scouring the internet for ideas and examples, and doing a heck of a lot of trial…and error.

My next post addresses WHY I needed to tackle this issue; later we’ll get to HOW.

 
Leave a comment

Posted by on July 30, 2014 in technology, web design

 
 
Follow

Get every new post delivered to your Inbox.

Join 202 other followers

%d bloggers like this: