RSS

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. 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.

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.

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

So 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.

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.

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

 

Kicks on 66, Days 9-11: Relaxation and Return

July 6-8, 2014

Day 9 Map (click map for slideshow)

Blooms

The day after our climactic day hike and flamenco performance, Wendy and I took it easy in Santa Fe. We had an unappealing breakfast at the Flying Star Cafe in the Railyard and walked to the plaza. A stop along the way at the Hilton let me shoot a nice piece of corridor artwork. At the plaza we indulged in cookies and a shake at the Häagen-Dazs. Then we found a place to sit at the plaza amidst beautiful blooms. Wendy tipped a beautiful busker who was playing “Yesterday” and “Blackbird” on a guitar.

I’d considered finally walking along the famous Canyon Road and its galleries, which I’ve never seen, but it was a Sunday, and I figured they might be shut. So I saved that for a future trip and instead walked with Wendy along the northeastern part of the Paseo de Peralta, an old street which encircles downtown. I liked seeing some of the old buildings. It was a sign of the times that the grand old Scottish Rite Temple was up for sale; its 1901 Moorish Revival look doesn’t blend too well with its surroundings, but it is a striking building. Declining membership means the local chapter lacks the cash flow to maintain it.

Name your price for this unusual temple

Across the street from the temple are the beautiful grounds of the Santiago E. Campos U.S. Courthouse. The building was started in 1850 and intended as the territorial capitol, but insufficient funding meant it would not be completed until 1886, by which time a new capitol was under construction. It has beautiful stone walls, and the grounds have lovely tall trees and a nice grass lawn.

Courthouse lawn

Out in front of City Hall we passed the statue of St. Francis and his often-petted prairie dog. The saint appears in various places about the city, which was originally called La Villa Real de la Santa Fé de San Francisco de Asís (The Royal City of the Holy Faith of St. Francis of Assisi).

We passed a VW Westfalia camper, something my father would appreciate, on our way back to our casita. My head ached, so I went out for a stroll around the block, finding a statue at the adjacent hotel of a Hopi maiden sporting immense squashblossom whorls. Princess Leia had nothing on her!

Dinner was a delicious pizza at the adjacent Café Café, followed by us relaxing on our patio for our final evening in Santa Fe.

Day 10 Map

The tenth day began with a wonderful early lunch at Tia Sophia’s downtown. I had beef tacos with Spanish rice, and Wendy loved the tender chicken in her green chile chicken enchiladas. She reported the tamales were good and spicy, if a bit grainy. We enjoyed sopaipillas and honey, bemoaning the fact that we would be leaving behind the wonderful food of New Mexico. Wendy posed for me in a downtown walkway, our last shot in Santa Fe.

Princess the Camry took us southeast to the old Cline’s Corners tourist stop off I-40. The most notable thing was a tremendous collection of horns on a wall. After refreshing ourselves, we headed due east on I-40 back to Amarillo. We pulled off in Santa Rosa to see its famous Blue Hole, an 80-foot-deep pool of 61-degree water which had attracted a number of swimmers. Wendy noted how clear the outflow was.

The Blue Hole at Santa Rosa

Just past Santa Rosa, the interstate divides the ghost town of Cuervo; Wendy thought it must be a fake ghost town or movie set, considering the oddity of driving through it on an interstate. But Cuervo is quite real, as are other ghost towns like Endee, Bard, and San Jon. We were puzzled by the names, but they made sense when we found out Endee got its name from the old ND ranch and Bard was probably a ranch name as well: the Bar-D, which reminds me of the chuckwagon show I saw in Durango back in 2011.

We had dinner at the yummy Blue Sky Burgers in Amarillo. Our evening entertainment was Errol Morris’s memorable documentary The Thin Blue Linewhich saved a man from death row.

Day 11 Map

The final day of our trip was a long drive back to Oklahoma City to have dinner with my folks and then onward back home to Bartlesville.

We began with a great breakfast near our hotel in Amarillo at Ye Olde Pancake Station. Before we left Texas, we pulled off I-40 to take old Route 66 through Shamrock to drive by the restored U Drop Inn, which frankly is the best-looking thing in town. Shamrock, like so many other towns along old Route 66, has been bypassed by the interstate and suffered mightily for it.

U Drop Inn at Shamrock, Texas

The sun was setting as we drove up US 75 to Bartlesville, glad to be returning home, but also wishing that we could spend more time having Kicks on Route 66.

Click here for a slideshow from these days

< Day 8 of Kicks on 66

 
Leave a comment

Posted by on July 21, 2014 in photos, travel

 

Kicks on 66, Day 8: Climbing Kitchen Mesa at Ghost Ranch

July 5, 2014

The eighth day of our big summer vacation was the climax. Or should I coin the term “climbmax” since we ascended Kitchen Mesa at Ghost Ranch?

Day 8 Map (click map for slideshow)

My first hikes at Ghost Ranch in June 2012 were stunning, and I outlined the history of the property in that post from two years back. I loved both the Chimney Rock and the Box Canyon trails, but did not have time to try the third major trail, which leads up to the top of Kitchen Mesa. A year later, I took Wendy out to the ranch, and our hike in Box Canyon was her favorite out of all of the different hikes during our first year of dating. So it was obvious that we had to go out to Ghost Ranch this time to hike together up Kitchen Mesa, the rounded and candy-striped mesa looming over the main buildings.

Hikes with Wendy at Ghost Ranch

We knew the hike would be challenging for us, since we are acclimated to an elevation of 700 feet above sea level, and this four-hour hike through hot desert terrain would climb from 6,500 to 7,100 feet. That included a 15-foot scramble up a cleft in the mesa to reach the top, and the uneven terrain meant we actually had a total ascent of over 1,200 feet.

So we got around early to hit highway 84 north for the 63 mile drive up to Ghost Ranch. We stopped along the way in Española for breakfast at a McDonald’s. We reached the ranch by 9:00 a.m. and checked in, paying the minimal day use fee. A friendly docent warned us about the cleft we would have to navigate to reach the mesa top and provided directions to the trailhead, which is adjacent to the trailhead for the Box Canyon hike we did last year. This time we avoided the long roadside trudge from the Welcome Center to the trailheads by driving around to park at them.

Our hike

As we headed out, our target was directly ahead, backlit by the morning sun. We climbed to a hillside which offered a panoramic view north across the greenery of the Rito Del Yeso arroyo. To the right was the mesa below which one will find the ranch’s Camposanto area, which we had seen the previous year along our Box Canyon hike.

Panorama of Camposanto area

Dinosaur Quarry

We crossed over into the ranch’s dinosaur quarry in the red siltstones and mudstones laid down 205 million years ago in the Late Triassic Period, the beginning of the Age of Dinosaurs. Back then this area was about 1800 miles farther southeast of its present location, putting it near the planet’s equator. 95% of the fossils found were of the small carnivorous dinosaur, Coelophysis. It was 6-10 feet long and weighed 50-100 pounds.

Panorama of the dinosaur quarry

Helpful signage explained the layer cake we saw in the rocks around us. The grey layer atop the cliffs is the Todilto Formation of saline sediments deposited by an inland sea in the late Middle Jurassic Period. The orange and yellow cliffs below it are sand dunes of the Entrada Formation, laid down in the Middle Jurassic about 160 million years ago. The rosy-colored mudstones and siltstones of the cliff base are the Chinle Formation deposited about 205 to 230 million years ago. It was in that period that hundreds of Coelophysis were buried, probably in a flash flood.

Another sign explained that David Baldwin discovered bones in 1881 and mailed them to paleontologist Edward Drinker Cope, who had been through the area earlier and named the fossils Coelophysis bauri. Coelophysis means “hollow form” and refers to the lightly constructed bones, while the rest of the name honors Georg Baur, a German morphologist. In 1947 a field crew discovered a dense bonebed of hundreds of skeletons in the area and excavated large blocks of rock, each containing numerous whole and partial skeletons. In 1981, a century after the initial find, the blocks were collected by various institutions.

It was while Wendy and I were crossing a dirt ridge in the quarry, breathing heavily in the thin and hot air, that a petite tanned mother with two children merrily scampered by. They would go up to the top and be on their way back down even as we low-landers were still slowly ascending the mesa. Rather than being discouraged at our relative difficulty, I took heart that if they could make it up there, then we surely could!

Wendy by a big chunk out of the mesa

A Slow Climb Towards the Cleft

We passed the narrow tip of the northern edge of the mesa as we continued to climb the valley to the east of it. We passed interesting rocks. A rather intimidating chunk of the mesa had fallen away and rolled down, squashing a tree beneath it. The impact with the tree had cleaved off a massive wedge from the chunk of rock.

Spying a narrow vertical slot in the mesa, I teased Wendy by saying we would be scrambling up through it. Of course we could have never managed that. We passed a crude natural amphitheater in the side of the mesa, which reminded me of a much smaller yet similar rockfall at Osage Hills near Bartlesville and the immense Echo Amphitheater near Ghost Ranch.

We steadily climbed in the heat, taking breaks in which Wendy teasingly made some pointed comments about my idea of fun. The beautiful views kept us going. We steadily climbed a ridge of dirt and rock toward the mesa top and suddenly spied the mother and her children clambering down the side toward us. They must have just exited the cleft.

Beautiful views

The Cleft

Their appearance made it easier to spot the way up, but the ranch does have a series of green-painted coffee cans all along the trail to provide guidance. Soon we reached the 15-foot-high chimney cleft we had to climb. Wendy had me pause to pose, and then we made the ascent. It wasn’t as terrible as I had feared, although we did have to go slowly and use all four limbs.

The Cleft

Mesa Top Overlooks

We followed the trail across the mesa top and reached the first overlook. Venturing out there provided a stunning view southwest across the Piedra Lumbre. To the north of the Cerro Pedernal mesa, which Georgia O’Keefe was so fond of painting, was a storm cloud spilling rain onto the desert. I hurried over to the edge to shoot a panorama, with the greenery around the Ghost Ranch buildings far below to my right. Farther to my right I could see the eroding layers of the mesa, with the grey saline sediments on top and the compressed orange and yellow sand dunes below that.

Overlooking the Piedra Lumbre

Selfie atop Kitchen Mesa

We celebrated with a selfie before following the trail northward along the mesa top to where a small grey promontory of sediment marked the second overlook.

I ventured out to shoot another panorama but found the view a ways back, which included the overlook platform, to be just as interesting. Wendy posed at the overlook for me, and then I posed nearby for her before we headed on toward the tip of the mesa.

Second overlook

The surface changed to the grey saline sediment. Being surrounded by that surface seemed unearthly and strange; Wendy described it as a lunar surface. She was fascinated by the white rocks with black veins and the mica glittering in the sun. A lizard scuttled by, and the final overlook we enjoyed provided a sweeping view of the ranch buildings below and the green vegetation along the course of the Rito del Yeso creek.

Ghost Ranch Panorama from Kitchen Mesa

Back Down We Go

The rain was approaching; it was time to head back. We traced our way back across the mesa top to the cleft and carefully descended. We were glad to be headed downslope in the heat, passing cholla cactus blooms. Wendy had frozen water in our bottles back at the hotel, a great idea which provided us with cool water throughout the hike. As we passed the huge chunk of rock beside the trail we’d seen earlier, with shattered wood beneath it, I speculated about which cleft in the side of the cliff it had come from.

Returning to the trailhead

As we walked, we were bracketed by storms. Dark clouds to the east produced a few flashes of lightning and rumbles of thunder, while approaching from the west was the rain storm. Up on top of the mesa, where I could get cell phone reception, I’d checked the NOAA Radar US app and knew the storm to the east was moving away, but the one from the west would eventually arrive over Ghost Ranch.

Nearby storm

We returned to our car, and raindrops began spattering down as we cleaned up and drove back over to the Welcome Center for restrooms and ice cream. A tour was leaving, taking folks to the settings of various paintings by Georgia O’Keefe to compare what they would see with what she captured on canvas. We should take that tour some summer. As we neared the end of today’s trail, I spied the top of Chimney Rock jutting up above the countryside. Although I hiked over to it in 2012, Wendy has not been on that trail.

So we shall certainly return to enjoy the hospitality of the Presbyterians who make these wonders accessible to all. I close this remembrance of our visit with a shot of cholla blooms in front of the distinctive flat top of Cerro Pedernal. Georgia O’Keefe painted that mesa many times:

It’s my private mountain. It belongs to me. God told me if I painted it enough, I could have it.

In a way, she got that wish; Georgia’s ashes were taken to the top of Cerro Pedernal and scattered there.

Cerro Pedernal beyond the cholla blooms

Tower on the former capitol

Capitols of Santa Fe

Tired but happy, we returned to Santa Fe and relaxed before heading out for an early dinner. Wendy clearly wanted more of those “best tamales EVER” at Tomasita’s, and we found it was already crowded at 4:15 p.m. The food was great, and we enjoyed people-watching. To walk off our dinner, we ventured over to see the state capitol.

We’d passed through the original capitol of these lands, the old Palace of the Governors on the plaza, a few days earlier. And we had repeatedly passed the “Bataan Building”, with its distinctive tower, on our way to and from the plaza. It opened in 1900 as a cheap replacement for an expensive territorial capitol, which had burned after only a few years of use. The simple three-story box with a modest silver dome grew over the years, and the dome was replaced by the 105-foot tower in 1950. But in 1966 a very different capitol building superseded it, and the old capitol became the Bataan Memorial Building, named to honor members of the 200th Coast Artillery that served bravely – and met a tragic fate – during the infamous battle and subsequent “Death March” of 1942, in the Philippines.

Wendy with the roses

We were curious to see the adjacent replacement capitol, which is quite inconspicuous. As we negotiated the sidewalks to reach it, Wendy discovered another small rose garden, this one nestled amidst the government buildings. She was impressed by the height of several of the bushes. I was more interested in the panels on the nearby Education Building, which had figures in extreme poses.

The grounds of the capitol itself have been described as, “a lush 6.5-acre garden boasting more than 100 varieties of plants, including roses, plums, almonds, nectarines, Russian olive trees, and sequoias.” But the areas we saw appeared neglected and unappealing. We came across Michael A. Naranjo’s Emergence sculpture, which I am not fond of; it makes me think of a game with a hula hoop. We also saw Doug Hyde’s Buffalo Dancer, which was squat and somewhat comic to me.

Having fun with the boys

I was equally cranky about the new state capitol, a three-story roundhouse which is unique among state capitols and hopefully will stay that way. Wendy, however, was in a playful mood. Inspired by our plan to see flamenco dancing that evening, Wendy stuck a rose in her hair and posed by Glenna Goodacre’s sculpture of two boys playing tug of war with three girls.

Entreflamenco

When planning this vacation, I had considered a performance of Carmen at the Santa Fe Opera. But the tickets were quite pricey, and a long four-act Italian opera hardly seemed in the southwest spirit of our trip. So I was happy to see a listing for Entreflamenco‘s performance in the Maria Benitez Cabaret Theatre at The Lodge at Santa Fe. I had never seen flamenco dancing except on video, and was hoping for an enjoyable evening. Wendy was interested yet skeptical. As it turned out, the performance was riveting, and we were so close to the action that we could see every detail, even the sweat flinging and feathers flying off the incredible dancers.

The stars of the show were Antonio Granjero and Estefania Ramirez. Wendy described Antonio as, “a macho Fred Astaire on crack” with his incredible speed and dramatic gestures and poses. He presented as cocky, powerful, and intense. His performance with Estefania began in an embrace, with graceful movements and then a walk apart on the stage to begin their foot-stomping and elaborate separate dances, to finally end in another embrace. His solo finale included incredibly fast and precise foot tapping and much more. Wendy wrote, “He worked like hell and then swaggered to the foot of the stage, nodded to the audience, and said ‘Hey’, followed by huge applause.”

Estefania Ramirez was incredibly intense, with a slight grin only fleetingly crossing her focused face. One dance was in a white dress with red fringe and Wendy aptly described her performance as, “Sassy, intense, very sexy, and confident.” In her guajira performance, she flicked a fan open and closed and back and forth with incredible precision, a very long skirt flipping and swinging. I could barely imagine someone even walking in such a dress, let alone dancing so energetically. Eventually two other female dances joined in, their movements precisely matching her lead.

There were altogether three other female dancers besides Estefania. A blonde resembled Scarlett Johansson, another dancer was slightly reminiscent of Frida Kahlo, and the third was very Indian in appearance and a bit less sheltered in her expressions. All four female dancers danced together near the start of the show, dressed in wonder-bread-like dresses with bright colorful fringed shawls.

Each of the dancers took his or her performance very seriously, and occasionally we spotted some modern moves in the mix. The experience was intense and emotional, with us sitting in the very front, only a couple of feet from the edge of the stage. Wendy said she could smell the sweat as they performed their intricate high-intensity dances with perfect timing and the flicking of precise gestures. She commented, “Our sweat from the hike at Ghost Ranch was nothing compared to the amount pouring off the dancers.” It was not at all off-putting, but made the experience all the more intense to see, up close, how hard they pushed their bodies in their demanding art.

Syncopated clapping by fellow performers accentuated the beat, and we enjoyed the emotional singing by Roberto Lorente and Francisco Orozco “Yiyi”, who also played the drums. Jose Vega Jurado and Alex Jordan were the fine guitarists. It was a delightful evening we shall never forget, and if you are ever in Santa Fe, you should see Entreflamenco in that cabaret. Sit up front!

This fun-filled day was the climax of our trip; we would spend the next day relaxing as we recovered. One more post will close out this travelogue along Route 66.

Click here for a slideshow from this day

< Day 7 of Kicks on 66

 
Leave a comment

Posted by on July 20, 2014 in day hike, photos, travel, video

 
 
Follow

Get every new post delivered to your Inbox.

Join 192 other followers

%d bloggers like this: