December 16th, 2010 Brian Herzog
Remember a few months ago, when I was inspired by Steve Butzel's presentation at NELA2010 and created a mobile version of my library's website? I bet you have that date marked on your calendar.
Anyway, one lingering problem I had was some mechanism to automatically detect mobile devices when they visited our website, and reroute them to the mobile version instead of the full web version. I finally had some time this week and was able to accomplish that - aided by the fact that it was easier than I expected.
The ultimate goal is to redesign our entire site along the lines Brett suggested, by creating a stylesheet specifically for mobile devices. Brad pointed out that the Canton Public Library employs this, awesomely: visit their site and slowly make your browser window smaller, and watch the website flip from "full web" mode to "mobile" mode.
- Php is more fun, and I know our server runs php
The website offering the php method is http://detectmobilebrowsers.mobi, and very happily they make it available free for non-profits. Here's what I did:
- Read and reread their website
- Downloaded the main bit of code, and uploaded it to our web server
- Used their Function Generator to create the snippet of code to paste into the top of our homepage. I chose to treat all of their options as a mobile browser, and redirect them to http://www.chelmsfordlibrary.org/mobile - the resulting code looked like this:
(this should be two lines of code, but it wraps because of the width of my blog - if you use this code, make sure the second and third lines above are actually one long line)
- I copy/pasted that code into our index.html homepage. However, because this is php code, it had to go between php tags, (<?php and ?>), so the complete code I actually added to the top of our page was:
(again, see note above about line wrapping)
- Note that the path in the "require_once" line must match where on your web server you actually saved the mobile_device_detect.php file (downloaded in Step 2)
- Now, the last step was a little tricky, because it involves editing the .htaccess on the server. It's easy though, and one of their faq answers explains it.
Basically, .html files don't normally run php code - .php files do that. So if our homepage was index.php instead of index.html, I could have skipped this step. Instead, in order to make .html pages execute php, I had to add a few lines to our server's .htaccess file - which was no trouble at all - and then everything worked splendidly
That is, at least, so far. I've done some testing with mobile devices and (as suggested) with the User Agent Switcher Firefox add-on, and all of that has worked. But please, if you have a mobile device, visit our homepage (http://www.chelmsfordlibrary.org) and let me know if you don't get redirected to our mobile site.
A couple other notes:
- I also added a link to the mobile site in the upper-left corner of the homepage, in case the redirect doesn't work
- I only added this auto-detect to the homepage. I thought about adding it to every page, but our full site has a lot of information our mobile site doesn't - especially descriptions of our events. If I added the redirect to every single page, people with mobile devices basically wouldn't have access to any of that. So, my thinking is to provide mobile users with the (robust) basics, but if they want more than that they'll have to endure our not-great coding until we're able to redesign the entire site to be mobile-friendly
This was easier than I was expecting, which makes me think I missed something.
Update: someone pointed out a gap in my logic. On the mobile site, there is a link to "Visit our main site" which linked back to our full homepage. However, since the homepage redirected people to the mobile site, anyone clicking that link from the mobile site just got looped right back to the mobile site. So, I changed that link to go to our About page. Again, this is a good reason to just have mobile-friendly stylesheets like Brett and Brad suggest above.
Tags: auto-detect, cell, cell phone, code, coding, conference, detect, iphone, libraries, Library, mobile, phone, phones, PHP, public, redirect, smart, smart phone, smartphone, steve butzel, website
November 18th, 2010 Brian Herzog
Thinking about the new design of the San Jose Public Library reminded me that I've been collecting links to tools and articles about web design. I posted a few resources before, but the demise of Bloglines has prompted me to pull out all my bookmarks and do something with them.
I'll be using these when we redesign our website, and hopefully you'll find them helpful too:
Web Design Overview
Design Tips & Goals
Testing & Development Tools
And the final word on this subject will come from Chuck - Design Coding is not only hilarious, it's amazingly accurate:
But I'm sure there are tons of other tools out there, so please share your favorite in the comments. Thanks.
Tags: coding, design, development, libraries, Library, public, site, sites, tools, web, web design, website
November 16th, 2010 Brian Herzog
Whoa - check out the new website for the San Jose Public Library:
Sarah goes into some detail about the features of the new website and their reasoning behind it, which is worth reading. Here's my two cents too:
- I love that they've done away with organizing their website along library department lines (Reference, Childrens Teens, etc.)
- The design is wonderful - so clean and simple, yet colorful, engaging and informative. It's so different it's shocking at first, but once your eyes and mind adjust to the new design, everything is just there
- Actually, now that I think of it, the homepage reminds me of the app icons on a smartphone - which is an interface that increasing numbers of people are becoming familiar with
- I like embedding functionality, so two things I'd be curious to try to see if they'd work are:
- In the New and Events block, instead of a picture to click on, embed a scrollable list of upcoming events to bring that info one step closer to the patron. Also include the link to drill down into the rest of that section
- In the Locations block, again instead of a picture, it'd be neat to just embed the Google Map right there, and have each of the branch location markers include address, phone, email, and hours. That would put so much information right on the homepage, and of course again include a link to get into the rest of the section
- But these might be overwhelming, so you'd have to try them to see
My library is planning to redesign our website, ahead of our migration to Evergreen. I'm definitely going to lobby to use SJPL's design as one of our models. Good job guys.
November 19th, 2009 Brian Herzog
Sometimes, being a librarian equates to being a packrat. At least in the virtual world, I can collect as many links as I want and it doesn't take up any room. However, to be useful, it does take organization.
For awhile now I've been bookmarking posts about free resources for clipart, photographs and other artwork. I use them for library publications, and also for my posts here. But just this week I got my act together and started transferring those links from my Bloglines account to my Delicious account, and thought I'd share them.
If you're curious how to do this with Delicious, check out my how-two post for creating library subject guides.
And just for good measure, here are a few web design tools I had bookmarked, too:
April 14th, 2009 Brian Herzog
Twitter has been around for a long time, so all the press it has gotten recently surprised me. Personally, I never really had much interest in it, so I just more or less ignored it.
Until a few months ago, that is, when I found a way to use it for the library.
The snowfall and storms this winter seemed particularly bad, and we had quite a few early closings or delayed openings. Whenever this happens, one of the ways we get the message out is to announce the change in hours prominently on our homepage.
However, it's the library director who makes the decision to close the library, but she had no easy way to update the homepage from home. She hasn't coded in html for years, and installing an editor and ftp program - and then her having to remember how to do everything - seemed like an unnecessary barrier. So, she asked me to find an easier way for her to update the homepage.
Ah-ha, I thought - I know libraries are displaying their Twitter feeds on their homepage, so why can't we?
I signed up for a Twitter account, learned how to customize the feed display, and added it to the library's homepage. I set the feed to only display one message, and after some trial and error figured out how to send a blank message (use the html code ). That way, after the storm passes, we could send a blank message to remove the announcement from the homepage.
Then, to make it as easy as possible for my director to update from home, I also created a Twittermail account. Using Twittermail, all she needs to do is send an email message to our account, and whatever she types into the subject line with then display on our website (centered on the very top of the page). Neat.
When I demo'ed it for her, it worked like a charm, and she was very happy. But of course, we haven't had a snowstorm since.
And see, that's the problem - I created this Twitter feed for a very specific purpose, and we haven't had much of a need for it yet. However, since I created it, seven people have started following the library on Twitter.
We don't promote it, so how'd they find it? They must have gone looking. If our patrons are expecting us to be on Twitter, and voluntarily pay attention to us, doesn't it make sense that this is a tool we should be using? To me, it does.
So, in addition to storm closings, I've lately been trying to think of other "announcements" that deserve top billing on the library's homepage - just so I don't feel guilty about these Twitter followers not getting their library tweets.
This is very much a case of "if you build it, they will come." Now I need to live up to the implied second half of that saying, "when they come, make sure it's worth their while."
April 7th, 2009 Brian Herzog
The Mass.gov website has a lot of great information, and being a librarian in Massachusetts, I use it all the time. However, one thing it does very poorly is URLs.
The powers that be at Mass.gov recently launched a new section of the website, devoted to the Massachusetts Recovery and Reinvestment Plan for the state's economy. What's the URL, you ask? This:
A recent promotional email introduced the site's resources, and listed the URL. My first thought was, wow, that pretty much guarantees it won't get used. Perhaps it's the Marketing degree in me, but if something doesn't have a catch name, or at least a moderately decipherable one, it automatically has less chance of succeeding.
I'm sure whatever CMS software the state uses is to blame for the ugly URLs, but they certainly have the power to do better. To wit: about a week later, a second email went out saying the new URL for the website was Mass.gov/recovery - perfect.
I use redirects on the library's website, and am glad that the state is too (and I'm sure it took more than my complaint email to do it).
But in addition to local redirects, URL shortening services like tinyURL.com, icanhaz.com and others can also help. Their popularity seems to have shot up with Twitter, but I use them in email instead of having monstrous URLs wrapping to multiple lines and thus not working. There are drawbacks to these services, but now that custom URLs are possible, I feel a little more comfortable using them with patrons.
It'd be great if all domains offered these short URL redirect services, and were limited just to that domain. That way, anyone could turn one of the standard Mass.gov long URL into a nice and clean Mass.gov-based useful URL, while at the same time not redirect a Mass.gov short URL to a porn site. I checked around and didn't see such software, but I'm going to keep looking.
Tags: domain, domains, icanhaz, libraries, Library, link, links, mass, mass.gov, public, short, shorteners, shortening, tinyurl, url, url shortener, urls