Library%20in%20 Your%20 Pocket Slideshare[1]
Upcoming SlideShare
Loading in...5
×
 

Library%20in%20 Your%20 Pocket Slideshare[1]

on

  • 3,677 views

This is a presentation given at Online Northwest 2010 by Kim Griggs and Hannah Gascho Rempel about how we designed our mobile library site and recommendations for how libraries can design their own ...

This is a presentation given at Online Northwest 2010 by Kim Griggs and Hannah Gascho Rempel about how we designed our mobile library site and recommendations for how libraries can design their own mobile library site.

Statistics

Views

Total Views
3,677
Views on SlideShare
3,672
Embed Views
5

Actions

Likes
4
Downloads
28
Comments
0

1 Embed 5

http://www.slideshare.net 5

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Educause presentation by NCSU, Washington Times article, Elsevier presentation The Library in Your Pocket: Making the library truly accessible anytime, anywhere By Wan Wee Pin, Liau Yi Chin and Chua Lay Lian, National Library Board, Singapore T oday we’re going to cover Why your library should consider going mobile Some design strategies to thing about before you go mobile Some practical steps for actually mobilizing your library’s website
  • Data about mobile phone use and its rapid expansion from Laurie’s prezi
  • Hopefully you now have an idea of the rapid expansion of mobile technologies and perhaps a hint of areas in which libraries need to do more work. I’m going to begin by talking about how we at OSU Libraries started our mobile library site process. So in thinking about starting a mobile version of our website, we did some looking around. One of the first places we looked was in best practices documentation for building mobile websites. The World Wide Web Consortium (W3C) technical document, Mobile Web Best Practices 1.0 (MWBP), recommends that the mobile experience merits its own design. So even though many websites will display on a mobile phone, this does not mean they provide a good experience for the mobile device user. For example, I’ll pick on Harvard Libraries, since I don’t think anyone attending today is from Harvard. This is Harvard’s desktop version of their library website.
  • This is what Harvard Libraries’ website looks like on the small screen of a feature phone. Feature phones don’t have a QWERTY keyboard, touchscreen capabilities, you can’t download software or apps, and are generally less powerful than a smartphone, like the iphone). You’ll notice that you don’t see much of their website and that it is going to take a lot of effort to see more of their site. Here is what their site looks like on an iphone. You can see the whole page, but the clickable links are tiny, a lot of space is given to their information like their exhibits that could have been used for more mobile-specific links or features. We’ll talk about what some of those mobile-specific features might be later in our presentation. So that’s what sites look like when they are not designed specifically for the mobile interface. They are viewable (although on some phones, just barely), but the experience for the mobile phone user is often less than ideal. To create a more ideal experience for mobile device users, let’s talk next about what mobile device users want to do with their mobile phones, which can help us think about how best to design a mobile site for them.
  • So first, back to the Worldwide Web Consortium best practices document: “Mobile users typically have different interests from users of fixed or desktop devices. They are likely to have more immediate and goal-directed intentions than desktop Web users. Their intentions are often to find out specific pieces of information that are relevant to their context.” (2008). Give examples of goal-oriented intentions What is the weather going to be like tomorrow? Who was that actor in Milk ? Where is that Indian restaurant? What is the call number of that book? (or to settle a bet) -minimum salary with no experience in NFL In addition to looking at best practices documentation to help us determine how to design the OSU Libraries mobile site, we also looked at other mobile sites to think about what we could learn from a variety of commercial and library mobile sites. In this next section, I will walk through several commercial and library sites that have created mobile-specific sites to discuss some of what we can and did learn from them.
  • To reiterate, it’s easy to think of your mobile website as a miniaturized version of its desktop cousin, but this would be a mistake.
  • So for this part of our presentation, I’m going to encourage you to use your mobile phones if you have them, which goes against my nature since I’m usually telling my students that they can handle turning off their phones for the next 30 minutes. Feel free to look up the mobile version of the sites I pull up so that you can see for yourself how they look on your phone. First let’s look at a couple of commercial sites. These sites are noted for having designs that are mobile friendly. First I’ll show you the desktop version of the site, and then I’ll show you the mobile version of the site, and for consistency I’ll be showing the iphone versions. This is where you get to play along. I’ll be asking you for the design differences that you notice between the desktop and the mobile sites. This is Amazon’s desktop site, so take a look at it for a second.
  • And here is their mobile site. I actually took two screenshots here so that you could see the content once I scrolled down the page. what do they notice between the two interfaces -fewer images
  • This is Yahoo’s desktop site
  • And here is their mobile site, again I’ve taken 2 screenshots to represent what you see when you scroll down. Ask audience what they notice between the two interfaces -less flashy ads
  • Now let’s look at some examples of libraries with mobile sites. I’ve tried to collect a variety of sites that have several different features. I think all of these sites contain helpful elements in planning for a mobile site. First I’ll start with a couple of public libraries. This is New York Public Library’s desktop site.
  • Here are two versions of NYPL’s mobile site. The first is the iphone version, and the second is a feature phone version. What design elements do you notice? The site wasn’t designed for feature phones.
  • Next is an example from an academic library - North Carolina State University.
  • Here are their mobile sites.
  • Back to OSU Libraries. After doing this background research of considering best practices, looking at other mobile sites, and realizing the enormous growth in the mobile market, we were at a point where we could verbalize the problem we needed to solve. So our problem statement was – “ patrons are growing accustomed to using mobile phones to access online websites for information, but OSU libraries web pages are too long and cumbersome for small screen viewing.” Our solution, which I’m sure you’ve already come to the same conclusion, was to create a mobile library site .
  • So instead of just jumping in with designing and developing our site, the next step on our path to actually creating a mobile site was to use some guiding scenarios to help us think through what patrons actually wanted from a mobile version of our site. Scenarios are like small generalized stories that help you think from the perspective of a particular user group. For students, the scenarios we came up with were… Students -The other day my friends and I were leaving class when I suggested we go to the library to study for the upcoming test. Since it was late in the day, Joe suggested we find out if the library was open before we walked all the way across campus. None of us had a laptop, plus we were walking so it wouldn’t have done us any good, but most of us have a phone with Internet service.    For Library Staff the scenarios we came up with were…   -Once I was working on meebo chat and I got a student question about hours. I responded with, "Here is the link to our hours" to which he responded, "I'm on my mobile! Just tell me!”     For General Public the scenario we came up with was… -I needed to use a computer to view and print some legal documents. I was near the Library, but wanted to make sure of the use policy for non-students before I tried to find parking. I had my phone with me but the regular website is pretty hard to use on my small phone and I couldn’t find the information.
  • So based on these scenarios what sort of things made sense to include on a mobile site? Time saving applications Call numbers next to a floor map link Location sensitive information Real time computer and/or laptop availability Map-based directions News and events Use mobile device’s native capabilities Auto-dialing phone numbers Texting a course reserves title or NY Times bestseller Short videos Not everything! No long documents!
  • Now that we had some direction, we began to implement our mobile project. It was best for us to attack our mobile strategy in three stages so that we could demonstrate progress early and often. So in Stage 1, which we’ve really already been talking about, we wanted to make sure we understood our mobile user . For OSU Libraries, our main audience is students/patrons looking for basic information about the library through newer mobile devices Next we identified the specific content to make mobile by evaluating main site use stats, considering the mobile context – so thinking through some of what I talked about before about not including lengthy documents and including location-specific information, soliciting stakeholder feedback, which we did by polling our users through our website about what they would want on a mobile library site, and looking at what content we had that was “fast, easy, and fun.” We conducted an environmental scan, which I’ve already talked about. We selected the mobile devices we wanted to target with our mobile design, which were both feature phones and smart-phones. The market share of feature phones is 85%, in addition international students are very familiar doing a lot of Web tasks on their feature phones, so we didn’t feel it was appropriate for us to only design a site that worked for the iphone crowd. We chose to build on existing web services to be more efficient in the way the site was programmed.
  • Even with all of these considerations in mind, deciding which elements of a site to make mobile is hard. It’s easier to say what you shouldn’t include, which is the entire library site. A mobile site should reflect the best of the best. The most active, the most popular, the personalized, the unique. Boil down your site to just the bare essentials and start there. Leave everything else out. So what we chose for stage 1 of our mobile site was – library hours, contact information, directions and address, our FAQs list, and how to get places within the actual library building.
  • After stage 1 was completed, we were ready to move on to stage 2. Again, we used guiding scenarios to help us think through what we should include in this stage of our mobile development. Our guiding scenario for students was… -“ I can't count how many times I'm in the compact shelves reading a journal, and in the references I'll see some other article that looks relevant. It would be great to pull out my phone right there, look in the catalog to see if we get the journal the article is in and head directly to its location. That's just something I think would be nice to have.”   Reference Staff When I am helping a patron find a book I sometimes have to leave them to look up the call number on the closest computer. It would be easier if I could look it up on a portable device as we walk around.   General Public “ The mobile website was very helpful in helping me find my way to the library, now if it would only help me find a book!” All of these scenarios indicate a desire to connect the catalog with location information. In the previous stage, we had call number listings, but no way to link to the library holdings in a mobile friendly way.
  • In addition to focusing on the catalog because of our guiding scenarios, we also received feedback from our online polls that indicated that patrons wanted catalog access and the ability to text call numbers to themselves, as well as the option to send a catalog record to themselves via email. In addition to including catalog access, we wanted to beef up some of the features we already included in stage 1. Based on use stats, we learned that the top pages viewed were hours, ask a librarian, texting contact information, and texting directions.
  • So in stage 2, we added the ability to view what computers were available in our Learning Commons, a staff directory that was broken up alphabetically.
  • And we added a catalog search. Our mobile catalog search included the ability to search by keyword, title, author, call number, or ISBN, and the ability to look up Course Reserves by course or instructor. The results list showed patrons right away what library the item was at, what the availability of the item, the call number, and the floor that call number is located on, which is a feature that is not available on our desktop site.
  • Our Mobile Catalog Results were scaled to fit mobile devices and emphasized item location and availability. In addition, we provided the option to use SMS services to text the item record along with its call number.
  • After stage 2 we had some pretty interesting usage stats, our average unique visitors per day was at 99. The average number of pages viewed per visit was 3 and the average time spent per visit was four minutes. The top 5 pages viewed were computer status, catalog search, hours, floor maps, and call number. The mobile devices people used to view our site were 75% iphones, 9% DoCoMo (???) and 12% feature phones.
  • We promoted our mobile site first by making sure patrons could get to our site a variety of ways. The first way we did this was by creating several different iterations of our mobile URL based on the examples you see here. The second way we did this was by making sure patrons could get to our mobile site from the desktop version of our site both through auto-detection, which Kim will talk more about later, and by including a link in our menu (although you could also put those links in your header or footer). We also wanted to make sure our site was as findable as possible and we did this by registering with an SMS link service so that students could enter our URL into something like Yahoo’s SMS link service, and then their phone would remember our link. This is sort of like creating bookmarks for mobile phones. We also added ourselves to mobile aggregators and directories. So in the same way that you would use search engine optimization to make sure Google found your regular site, you can make yourself search engine optimized for mobile sites. In addition, we promoted the site through our main website, library and campus news. Now we’re going to switch gears and get more technical. Kim is going to give us some of the nuts and bolts of how to actually develop a mobile site.
  • Now that we ’v e seen the benefits and challenges of the mobile Web, and ways libraries are making use of it, Lets move on to how to develop a mobile presence. The first thing to determine is a mobile strategy approach. Things to consider when deciding on a mobile strategy are effort and resources, programming skills, features you want to add and existing Web services you want to build on, and the mobile devices you want to support. You have the choice of several methods to provide mobile content to your patrons. The easies approach is to simply Do Nothing. .If you follow standards carefully, there is a pretty good chance that most mobile browsers will be able to at least interpret your sites and render them in a manner that is basically usable. This is not a bad way to go, but there is more that can be done to improve the mobile user experience if you have the time and the know how to spend on it. Another approach is to miniaturize your site by providing an adapted version of your Main web site designed for mobile devices . Using this approach in addition to graceful degradation works well for simple sites and makes maintenance easier since you only have the one site. The main problem with this approach is that it does not take the mobile user context into consideration. Recent usability studies by Jacob Neilson, a leader in Human-Computer interaction found that that users performing tasks with their phones on sites that were designed for mobile devices received an increase of 64% in task success and received higher satisfaction ratings. To provide an optimal mobile experience we recommend building a mobile specific website even though t his does mean having to maintain two web sites. You can minimize maintenance by using web services to reuse your existing content. For example, the mobile Library hours page and staff directory, pulls the data from the Main web sites Drupal database. Once you have decided to create a mobile specific website you then need to consider the limitations and constraints of mobile devices. For example different devices support different markup features and different screen sizes may demand different sized images. Mobile devices also have limitations such as memory and bandwidth and the possible absence of a pointing device. Another considerations is the mobile domain. There are thousands of mobile devices and hundreds of browsers. The mobile browser domain includes devices that have a Full Web Browser, such as the Iphone, those running a constrained browser, such as Blackberries, and limited proprietary browsers such as those on your standard flip style phone. Then the trickiest part of developing a mobile presence isn’t building the site (that’s relatively easy), it’s deciding which device path you’re going to take – in other words, which mobile devices/browsers you’re going to support and which you aren’t.
  • Coming from the desktop web, you’re probably accustomed to supporting all the top browsers. But A common trend in the mobile web is to only develop sites that work on smart phones with full web browsers. We should instead see mobile users as another class of disabled user “” The W3C Web Accessibility Initiative compares mobile users to people with disabilities as having similar limitations and barriers when accessing Web sites. And for this reason suggest that all mobile users be treated with the same consideration and care.
  • One way to provide an optimal experience is adaptation. Adaptation, sometimes called multiserving, means delivering content as per each user device's capabilities. Using any of the adaptation techniques I am about to describe you can implement a mobile site that is optimized for all mobile devices and as time goes on standards support will improve across mobile browsers, to the point where mobile web development isn’t really that much different then web development.
  • Media types are an easy way to give users on both high end and low-end mobile devices an optimal experience by linking to device appropriate stylesheets. Media types have been around since the early Web and are used to render content differently for different screens. The media types applicable for mobile devices are the handheld and screen types. In addition to media types some browsers support media queries which can further adapt styles. Using a combination of the two allow for the best customizing effect. W3C specifications for optimizing mobile sites recommend using the handheld media type to link to mobile stylesheets. The problem with this is that all mobile browsers do not adhere to this recommendation. Handheld media is are supported by Opera, OpenWave, and partially by Pocket Internet Explorer. Palm’s Blazer, IEMobile support both screen and handheld. Apple and Nokia do not support the handheld media type, rather they uses Media Queries to render the screen type. A method that works correctly on a large number of mobile devices is to link to a basic stylesheet for feature phones that support the handheld media type and use the screen media type and to link to a stylesheet with media queries that is styled for smartphones.
  • The next techniques takes adaptation further by detecting and redirecting to different versions of a mobile site depending on device capabilities.
  • Using a server-based scripting language (like PHP), it' is easy to detect device types by reading the UserAgent string. You can use a detection algorithm on main websites to auto-redirect mobile users to your mobile site. You can also use it on your mobile site to manipulate header code per mobile device - for example you can test for iPhones and inject code that turns all the phone numbers on your site into auto-dialing links. Any type of redirecting to device specific layouts should also provide users with a choice. It’s consider bad practice to force or limit your mobile users to a specific layout. Give them the freedom to make that choice by including a link to your full site and make sure to remember that choice and not redirect them to the mobile site the next time they visit.
  • Browser detection can only tell you so much about the device your users are on. Feature detection tells you about the mobile devices capabilities. One resource for feature detection is WURFL. WURFL is an XML configuration file that contains capabilities for hundreds of devices. For example, in order to know the device display width and height, it's possible to check the 'resolution_width' and 'resolution_height' capabilities. This would allow you to Apart from the XML file, a set of APIs are provided for different programming languages, in order to easily perform the feature detection process Device and feature detection often results in multiple copies of content formatted specifically for a range of devices, and therefore requires constant maintenance as devices come and go. And, it’s worth noting; device and feature detection is rarely 100% reliable. A feedback link on your mobile site can help patrons contact you if they experience a false redirection.
  • Rather than maintaining multiple copies of content, it is better to have content that can dynamically adapt for the type of device accessing it. There are commercial and open-source tools that can auto-generate device-specific versions of your site. One such tool is The Wireless Abstraction Library (WALL), a free Java tag-library that provides a universal mark-up for wireless devices. With WALL, you can code for all those devices using just one HTML-like mark-up. Wall in combination with WURFL can detect what a device can do and make sure that the best possible mark-up is delivered to that device.
  • There are also tools that can create a mobile site with no programming and little development effort. Google conversion utility is as simple as it gets. Just enter the URL of your website, check the option for ‘No Images’ if you do not want images to appear, then click on the ‘GO’ button. You can then use the link google provides for your mobile pages. There are also online CMS like tools such as MobiSiteGalore and InstatMobiliezer that Let you build websites that will work consistently across most mobile phones The Drupal Mobile Tools module is targeted both towards making a mobile version of your existing Drupal site, and making a mobile site from scratch. And y ou can turn any of your RSS feeds into mobile pages . There are a couple of free options for pulling in RSS feeds and displaying them as HTML such as SimplePIE, Feedburner, and RSS2HTML
  • There are a couple iPhone tips that can immediately enhance your mobile web presence. one simple strategy is to have an additional style sheet that’s only used by the iPhone. This link element uses a media query to target devices with a maximum width of 480 pixels—that is, the available width when the iPhone is in landscape orientation. Another easy element to add is the the viewport meta key . Typically, you use the viewport meta tag to set the width and initial scale of the viewport. If you are designing an iPhone-specific web application, you should set the width to the width of the device. Setting user-scalable to no disiables zooming in and out and also prevents a webpage from scrolling when entering text in an input field. Typing is a pain even on the iPhone. By adding this element to your header users can add your web application link to their Home screen. To do this, create a PNG and put it in the root of your web server. The iPhone will automatically add the glossy effect and rounded corners. Even though the iPhone can do a good job at of rendering most sites, developers should be aware of their limitations and design accordingly. Iphone documentation is a must read for mobile developers.
  • AS part of our requirements documentation we drew up a list of design recommendations based on W3C’s 60 guidelines and Apple’s iPhone Human interface manual. The first recommendation is Don’t make the user click more than 3 times to get to the information Assign each navigation link an accesskey number and do not exceed the numbers on a phone pad. Include a link to the full Web site Keep URLS short and do not use non-alphanumeric characters &,_,- Do not rely on support of style sheets, fonts, color & javascript Use selects, checkboxes and radios over textboxes to minimize typing Keep images to a minimum and compress them Place a link to the mobile home and back links at the top and keep to one line including the header. Place related links below the main content Use tried and true design patterns from standard web design as well and Apple, Safari and Opera and keep an eue on emerging patterns from mobile leaders.
  • Similar to CSS, HTML and ADA standards w3c provides The mobileOK Basic Tests The MobileOK checker is an online tool that automates the tests and provides detailed information where and how a site fails. The checker tests for the m o bile-friendliness of a mobile site. A page on your mobile site is scored on a scale of 0-100 for the O K -ness. This rating system lets you work towards meeting the guidelines and to prioritize the severity of the failures. In addition to the MobileOK checker tool, DOTMobi provides a tool, MobiReady, that e v aluates the mobile-readiness of a mobile site. Unlike the W3C tool, you can test your complete site at once. Pages are rated on a scale of 1-4 and analyzes a site for page load speed and weight, and validation errors and warnings. Validating your code should be done continuously as you develop your site. The level of conformance you choose to require should be part of your development plan.
  • In addition to fledgling standards, testing is often an issue in mobile application development. Testing can be done on desktop browsers in the early stages of development and on online simulators or emulators. iPhone, Palm, Blackberry and many others provide a SDK with simulators that provide more realistic testing When OSU Libraries’ mobile development was at the final stages we went to the nearest T-Mobile store and asked if we could test the site on the display phones. The manager agreed and even ended up helping us test. He proved invaluable, as he knew which phones came with what default setting and browsers. Another option is to pay for a service called DeviceAnywhere which lets you test on a wide range of devices online. Evaluations and user testing can be performed on paper prototypes and simulators, but nothing beats testing on mobile devices in the real world. Hallway usability testing can easily be performed on mobile devices and provide the on- the -go context of mobile users.
  • Future development of OSU Libraries mobile website include adding access to the mobile databases that are becoming available, such as ebsco host. Providing the ability for patrons to check their due dates through their library account and reserve study rooms. As well as add our news and events feeds, text-a-librarian service and SMS alerts. In addition to the mobile web site we also have innovative mobile applications planned that include using our digital collections, way and friend finders, and an art tour using QR codes.

Library%20in%20 Your%20 Pocket Slideshare[1] Library%20in%20 Your%20 Pocket Slideshare[1] Presentation Transcript

  • Library in Your Pocket Kim Griggs Hannah Gascho Rempel (and Laurie Bridges) Oregon State University Libraries Online Northwest Feb. 5, 2010
  • Reasons to go mobile
  •   View slide
  • http://lib.harvard.edu/ View slide
  • Why a mobile library site?
    • Mobile sites are not just smaller versions of your current site
      • They need their own design
      • Users are more likely to have “goal-oriented intentions”
  • Mobilized vs. Miniaturized
    • Library Examples
  •  
  • Amazon http://www.amazon.com/gp/aw/h.html
  • Yahoo
  • Yahoo http://m.yahoo.com
  • Insert NYPL homepage (desktop)
  • http://m.nypl.org/
  •  
  • http://www.lib.ncsu.edu/m/home/
  • Problem Statement
    • Patrons are growing accustomed to using mobile phones to access online Web sites for information, but OSU Libraries' Web pages are too long and cumbersome for small screen viewing.
    Solution: http://m.library.orst.edu/
  • Stage 1 – Guiding scenarios Unhindered by Talent acpl Students Library Staff General Public Brandon Cirillo
  • What to include on a mobile site?
    • Time saving applications
    • Location sensitive information
    • Expose native capabilities
    • Not everything! No long documents!
  • Stage 1 – Make a Plan
    • Break up project into stages
    • Understand the mobile user
    • Identify content to make mobile
      • Main site use stats
      • Mobile context
      • Stakeholder feedback
      • Fast, easy, fun
    • Conduct environmental scan
    • Select target mobile devices
    • Build on existing web services
  • Stage 1 – Select Content
    • Library Hours
    • Ask a Librarian
      • Chat client / Lnet
      • Email
      • Ref desk hours
      • Phone #
      • SMS Contact
    • Address / Phone #
      • SMS Directions
      • Google Map
    • How Do I ?
    • Where is it?
      • Floor Maps
      • Call Numbers
  • Stage 2 – Guiding scenarios Unhindered by Talent acpl Students Library Staff General Public Brandon Cirillo
  • Stage 2: Add New Features
    • Based on Feedback
      • Poll Winners
        • Catalog
        • Text Call Numbers
      • Emails
        • Catalog
    • Based on Use Stats
      • Top Pages
        • Hours
        • Ask a Librarian
        • Text Contact
        • Text Directions
  • Stage 2: Computer Status & Staff Directory
  • Stage 2 – Catalog Search
  • Item Record Save Items SMS Stage 2 – Catalog Results
  • Stage 2 - Assessment & Feedback
    • Average Unique Visitors: 99 a day
    • Average Number of pages viewed per visit: 3
    • Average Time spent per visit: 4 min
    • Top 5 Pages
      • Computer Status
      • Catalog Search
      • Hours
      • Floor maps
      • Call Number
    • Mobile Devices
      • iPhones: 75%
      • DoCoMo web phones: 9%
      • Feature phones (Blackberry, LG, Samsung): 12%
  • Stage 2 - Promotion
    • Link on main website (header, menu, footer)
    • SMS link service
    • Add to mobile aggregators and directories
    • Library & campus news
    • Advertise on home page
    Mobile Site
    • Use Mobile URLS
      • m.your-domain
      • mobile.your-domain
      • your-domain/mobile
  • Mobile Development
    • Mobile Strategy Approaches
    • Limitations & Constraints
    • Mobile Domain
    • Device Path
  • Optimal Mobile Experience
    • Pe ople with disabilities using computers have similar interaction limitations as people without disabilities who are using mobile devices. Both experience similar barriers when interacting with Web sites. (Web Accessibility Initiative, 2009)
  • Adaptation Techniques
  • Media Types and Queries
    • <link rel=&quot;stylesheet&quot; href=&quot;screen.css” media=&quot;screen&quot;/>
    • <link rel=&quot;stylesheet&quot; href=&quot;handheld.css” media=&quot;handheld&quot;/>
    • @media screen { /* rules for computer screens */ }
    • @media handheld { /* rules for handheld devices */ }
  • Media Types & Queries Nokia S60 browser, Netfront (configuration dependant), Teleqa Q7, IEMobile 7.x Screen iPhone’s Safari, Opera Mobile starting v9, Opera Mini starting v4 Screen & Queries Palm’s Blazer, Nokia S40 browser, IEMobile 6.x and 8.x Screen & Handheld OpenWave browser, Nokia lite-web browsers, Netfront (configuration dependent), Digia, BlackBerry browser, Opera Mini until v4, Opera Mobile until v9 Handheld
  • Technique 2: Browser Sniffing
  • User Agents
    • $currUA = strtolower($_SERVER['HTTP_USER_AGENT']);
        • if ((strpos($currUA, ’Agent Smith')>0){
    • header( 'Location: http://mobile.matrix.com'}
    • }
  • Feature Detection wurfl.sourceforge.net
  • Technique 3: Automatic Adaptation http://wurfl.sourceforge.net/java/wall.php
  • Mobile Site Creation Tools
    • Google’s Conversion Utility
    • MobiSiteGalore
    • Drupal Mobile Tools
    • InstantMobilizer
    • RSS Feed
  • iPhone Tips
    • <link rel=“ s t ylesheet” href= “ iPhone.css ” media= “o n ly screen and (max-device width:480px) ” />
    <link rel=&quot;apple-touch-icon&quot; href=&quot;/images/apple-touch-icon.png&quot; /> <meta name=&quot;viewport&quot; content=&quot;width = device-width , user-scalable = no&quot; />
  • Design Recommendations
    • Don’t make the user click more than 3 times
    • Assign each navigation link an accesskey number
    • Include link to full Web site
    • Keep URLS short and do not use &,_,-
    • Do not rely on support of style sheets, fonts, color & javascript
    • Use selects, checkboxes and radios over textboxes
    • Keep images to a minimum and compress
    • Place a link to the mobile home and back links at the top
    • Place related links below the main content
    • Use tried and true design patterns
  • Validation Tools
  • Mobile Testing
  • Stage 3 - Expand Services
    • Databases
    • Room Reservation
    • Library Account
    • News & Events
    • Text-a-Librarian
    • SMS Alerts
  • Resources
    • Library/mobile: Tips on Designing and Developing Mobile Web Sites; Griggs et al; Code4Lib Journal 8
    • iPhone Human Interface Guidelines
    • dotMobi
    • W3C Mobile Best Practices