TPR1: CSS Methods for Mobile Devices

Justin: My name is Justin, as you just heard. We're going to be talking about this morning -- or guess, what I'm going to be talking about what you'll be listening to, about CSS4, using different methods of CSS 4 used with mobile devices and so on. I work at a college, I'm a web guy. Now, we could go on to all the details of that but that's not why you're here.

Some of you, I've -- I think I've printed a hundred -- was the suggested number to be prepared for for handing out stuff. I presented this at eduWeb a couple of months back and that was one of the suggestions, have a handout first to have with us. So if you didn't have one I'm going to be making this available online afterwards, so see me afterwards if you do not have a nice white glossy folder in your hand right now.

And much like the white glossy folder which is kind of a low-budget looking type of distributed item, we're all kind of dealing with budget cuts in one way or another, us in California more so than a lot of the other states -- probably our own fault.

I was -- I went to the vending machine last night to get a soda, I realized that Higher Ed were not the only folks with budget issues. I pulled a Santa Coca-Cola can out of the vending machine and --I thought it looked very strange it says Holiday 2009. After I drank about half of it, I noticed it says August 2010 is the expiration date. I found myself wishing I had walked somewhere where they had something fresh, but that's fine. It's probably good until 3010.

OK, so why should we design for mobile at all? Well, back in early 2008, Nielsen put out a report saying more people access browser-based internet content using a phone or handheld device than using a PC. And last year, at the end of 2009, Nielsen put another report where you can read all the pages if you want, look at all the cool charts, but nearly a quarter of all U.S. households have a smartphone. That's actually about 21 or so percent at that time. Little over a fifth -- they say nearly a quarter, it sounds cooler, I guess. It's actually just about a fifth.

So here's one of those cool charts. The top one going down is your feature phone or flip phones or smaller, just regular standard phones whereas the one going up from the bottom is the smartphone tracks. So the projection is, according to Nielsen, that by the third quarter of 2011 or fourth quarter of 2011 it's very possible, based on the way it's trending, smartphones may actually overtake standard-feature phones in the market place.

So how do I design for mobile? Well, you can do just a straight forward nice semantics standards-based XHTML CSS layout design. Separate the XHTML from the CSS so your presentation and your structure are two separate files. And at this point you're really providing a website that will sort of work with most mobile browsers but there's basically still a problem.

Four main things; the screens are small, input is not the greatest, downloads may not be the best depending on which network you're on or where you're at and how the coverage is. In sites where all you're not designed for that layout. So what I thought about was I'm just a single man web shop where I work. A lot of us who are in that boat have smaller teams and don't have a lot of time to -- let's design another site to maintain, that sounds great. Sure, that will be cool.

So I thought, well, what if we take our existing site and just make it work? Use some CSS methods and some other things to make what we already have work and that we're not creating a new site but we're -- for those of us who would be accessing it on a mobile device it looks like a real nice -- hey, I just ripped my CSS off of this site, Times New Roman, white background, black texts, blue underlined links, aligned to the left, that looks really exciting.

But at least you're not creating something new. That will be a quick and easy way to get to something that works. Second step, my thought process was, OK, well, after that it's probably appropriate to think about, well, if I wanted to go to an actual mobile site how would I set that up and I probably want to set up something that would work or at least display very similarly on as many devices as possible, has about the same experience.

And then thirdly, what if I wanted to set up something specific for our iDevices; the iPod Touch, iPad or iPhone and how will I go about that? So that's kind of what I'm going to be talking about this morning. So first thing, make your existing site mobile friendly. Create a blank handheld stylesheet. Basic link tag in the header area of your page. Give it whatever -- you don't have to call it Mobile.CSS, I'm not going to be coming around as the mobile police and checking your CSS filename later and saying, hey, you didn't follow the presentation.

Just media handheld type, pretty straight forward. Making a blank one. For those devices that read handheld stylesheets, there's no styles in there. This is a nice hack for the Windows mobile browsers. I haven't seen Windows Phone 7 yet in my hand to try it. He capitalized the screen media attribute. This will force the Windows mobile browser to use the handheld stylesheet.

So that will be for your existing desktop CSS. So thank you Windows and Microsoft for forcing us to do yet another hack.

[Laughter]

Justin: And then within your mobile or handheld stylesheet, if you enclose the attributes there within and @media handheld media query or that's not really media query but a media type specification, that's just a precaution. That will prevent these styles from being applied to your normal screen layout probably mostly for Internet Explorer also. Floating width aren't really things you want to mess with so much in the mobile screen space. So you know I have an asterisk there floating on and then with width you want to use a percentage or just avoid it all together.

You can use a percentage it will float nicely especially with the landscape orientation or switching screens when you move the device around. Here's a good nice exciting starting point. Basically, white background, black text, nice and exciting, no margin.

Now, if you're going to take your existing content on your site and just kind of poured it basically to work for a mobile device display, then you want to use the outermost element of the area you want to hide. It's simpler, it's less code to write. I don't need my sidebar and my footer. Maybe I don't need my left nav. Maybe I want to create a nav specifically for this and display it. So I just said we're not creating new stuff. So maybe don't do that in this process.

And then basically, take care of your headings to set them with their normal font way. You don't have to do that. That's what I chose to do and it seemed to work pretty well. Control your images whatever your element or your area is or dev on the page and images within that. Set a max width for that so your images don't exceed or try to automatically resize themselves or stick out of the viewport and you're swiping back and forth just to see them. Maybe they only work in landscape if they're too wide.

If you control that or any size you want to target that can be helpful. And then for headings, footer, credits, anything that specifically as far as for the structure of the page or information for like a footer about your institution, something at the top of the page, you topically display what the content is, have that centered. Again, that's really more of a preference thing. It doesn't have to be centered, maybe you want to align it to the right or the left. It's really up to you.

And then make your links stand out. Make them something that looks fairly standard. If you're just stripping all the styling out initially, make the links look like something normal; blue underlined text is a good way to start. It's not particularly exciting but people know what that is. It's very familiar. And then go ahead and copy that down real quick. OK.

[Laughter]

Justin: That's in the handout. If you don't have the handout like I said, see me afterwards. I'm going to be uploading this and I'll give you the URL where you can download it right now before you leave.

I can do that right now but it wouldn't be a good use of your time. I guess this is one option for a way to do that . What I just talked about a very simple straight forward CSS file. And then what I'm going to be talking about a little bit more here in a minute is what's down at the bottom. It says iPhone-specific styles and that's a CSS media query which Safari and Opera mobile support that -- and have support of that for several versions now and support it properly. I'll talk about how that works, too.

OK, there's several different ways to embed a CSS in your page. I'm not going to go into this in any detail because this is pretty standard straight forward stuff. Just a link method in the head area of your XHTML document specify your media type. There's the add imports, take it at the top of your CSS file and specify, hey, here is where my stuff is. Easy way to create a master CSS file for your site by just doing that. Or the @media method which is basically you're calling it from within the CSS file then everything between the curly braces is stuff for that media type. Very exciting. Very ground breaking.

So you're all going to go home and talk about -- he talked about how to call CSS files. So how are they supported? Some mobile devices use screen stylesheets. Some use handheld. Some read both. Some use handheld if they don't see the screen stylesheet. Some could care less. Some automatically disable your CSS or give the user a way to do that.

Of course we're talking more about older phones at this point; just a little bit older. And as far as CSS media queries are concerned, I did mention those just briefly, it's a pixel width max device width or height are maxed or window within height. Those are in pixels specifications. It gives you a nice way to kind of set the viewport this way. There's another way to set the viewport which is probably better than this. This is one method that does work.

Some elements that don't really play very nicely with mobile browsers float display and these are using none if you use none display is good. You don't want to really mess too much with display in the mobile screen environment unless you want people basically treating it like a fullscreen desktop browser.

Padding, margin and background image. Not that you couldn't use them if you are careful with how you implemented them but it's not a bad practice to kind of avoid those if possible and go another route. One of the nice things about web development and design that I'm sure you're all familiar with is it's, from my perspective, it's a lot like geometry. You have an answer over there or a destination you want to get to and there are several different ways to get to that same answer.

This is just one way that you can do that. You may have much better methods of doing that. In which case, anybody that wants to come up and take over the presentation at this point. So just to say there's a number of different ways you could go and still get to the same end result.

So to put that together basically, you could create a stylesheet for your desktop. You already pretty much have that. You can use a Reset.CSS. Eric Meyer put one of those out quite awhile back on meyerweb.com. You can find that in his tools subdirectory Reset. And then bring them together into a master file like I mentioned with the @import statements. That's a real simple way to bring the other CSS files into your implementation without having to go add another link tag in every page on your website.

Here's Reset, so go and copy that down real fast but that's easily -- you can find that on meyerweb.com, Eric Meyer. So then once you've done that, you create a stylesheet for your mobile device that you want to target or for the viewport that you want to target. You put some rules in there to specifically style the content for those browsers and then you can add some link tags in the header of your document or bring them in your @import statement.

So basically, what would this really accomplish if you went through these steps because I'm going to do the reading right off of the slide which I'm sure you're all very excited about. Mobile browsers not only read the handheld stylesheet will not read the CSS properties defined in the desktop screen, a CSS files that they don't support. Mobile browsers that reads screen stylesheets and handheld or media query stylesheets will not be affected by the unsupported properties in your desktop CSS because they're cancelled by the Reset file.

And then finally, the desktop browsers will ignore both the Reset and Mobile.CSS files because you've specified with media types that these are to be used for handheld devices. And there's also the other option, probably a very good option to put in place is to detect the user agent or browser that's requesting content from your web server. It reduces the weight of what you're delivering, what's being uploaded to that handheld device.

There are several different networks around the world that actually, they charge. A lot of us have them in the data plans which is nice but a lot of folks in other countries most of their primary computing device don't have that same benefit possibly or it's maybe out of cost range for them. They are being charged based on the bandwidth of what they're downloading. So it's a nice way to be considerate of that and to understand that situation.

When you're thinking about putting together a mobile site for your users it's good to ask what content do they really need? They probably need a different set of information than what I'm presenting to my desktop or laptop website visitors.

Now, there are a couple of different methods that I've seen as far as doing user agent browser detection. James Pearce on mobiForge had an article that he wrote a year or two ago about not device detection, I thought that was really interesting. He said -- his concept was, there are a lot of different user agents in your handheld devices or mobile computing devices but there aren't really so many operating systems in general for your desktop or laptop environment.

Maybe it's easier to detect and see if a desktop's type of operating system is requesting the site because that's a smaller number of things and if it's not one of those, then deliver the mobile site. A little easier to deal with that way. Just one idea that you could try. And the concept here is the user is what -- is mobile themselves. They're not just holding a device that's mobile, they're mobile themselves. So the fact process and what they need and are looking for is going to be different mentally than if they're sitting at their desks.

Their patience with what you're providing them is probably going to be a little bit lower because of what they're doing. So, I mean, ultimately, you really don't have to create a stylesheet that specifically forms your site to mobile devices because a lot of devices either will give a full desktop experience already and people can zoom around depending on the viewport and what they're using or they can disable it entirely or the phone itself disables it or reformats it, some different horizon, smaller horizon phones will actually have their own nice little render that takes your site and chops it up and makes it really nasty looking almost regardless of what you do.

But if your mark up is standards based and you've got a semantically set up really nice which sounds really great and maybe you have that -- that's awesome and maybe you don't. As long as -- if you're pursuing a standards-based design your website is really going to work on most mobile devices already. Another wonderful page for you to write down on your notes in about five seconds.

Just a number of different links on here Debut 3, Validators, The Mobile Web Initiative stuff. Tiltview is where you can see what the mobile version of a site looks like. Ready.mobi is another emulator that will emulate several different mobile device types and will not only show you what the site would look like but also give you some tips on how to fix issues that your site may have with that particular device.

DeviceAtlas is an online database of mobile device info. There's the Google Web Mobilizer that's got some pretty good and interesting stuff to look at and how they do things -- user-agent switchers and add-on for Firefox which is nice. The Opera browser as many of you know has the ability to display a small screen. It's not 100% accurate but it's as pretty good. And then mobiforge.com has got a pretty good resource of overall mobile web stuff and some documentation and things that you can look at.

Iphonetester.com and testiphone.com are couple of other emulators, they really basically just use the Safari web browser and stick an iPhone graphic and they've got a nice dev where the screen would be.

If you have an iPhone it's better to test with an iPhone than with that but that's an option if you don't have -- happen to have one. This was step two, what about a one-for-all mobile site? This right here is basically what this layout looks like in five different browsers. Put the icon underneath them so that you can get an idea of kind of what they look like. IE is the only one that doesn't support the text shadow CSS element, thank you, IE. And Opera and IE not supporting at that point the border radius options.

Not particularly exciting but looks about the same on most devices. Pull it up in Android, pull it up on an iPhone, pull it up on a Palm Pre or something similar -- looks very similar. It's got a very similarly interface and simple to set up. So how do we set something like that up? Here's our CSS media query. We're saying we want to max device with the 480 pixels on that. You can change that value to anything that suits your particular environment or what you're targeting.

Whatever your selector is that you want to specifically specify or style, you would just change the word selected there what it is that you wanted to focus on. No text resizing. There is an auto-text resizing annoyance in mobile Safari that many of you may have seen or dealt with. This right here what use the outer most HTML element as your attribute and web kit text size are just none. That will prevent that from happening.

This is a meta tag for setting the viewport that we talked about before using a CSS media query for setting the max device width or height. You can do both. This is a way to set the viewport, you can set the initial scale, the maximum and user's scalable option for the viewport that you're delivering your web page to. Here's a Java Script to get rid of the iPhone URL bar. If the web page or the site that you want to create you want it to look like an app, you want to get the URL bar out of there. You know what that shelling otherwise, it's just look like a web page in -- web kit on the iDevice. This will help you get rid of that.

You can do some client side or server side user agent kind of queries, what are you on? Are you on an iPhone? And then if so, then do the following. The third item there in particular is a PHP that says if you are on an iPhone then here's a template to deliver you to or else, here's another page to send you to if you're not an iPhone user agent. And then you could style your pages accordingly based on what attributes are supported on those two devices.

Tool tip, why you would want that, I don't know. I found that but just doing some reading probably really stupid but I would throw it in there. If you wanted a cool pop-up tool tip to appear you can do that. I'll click to co-linker tap to co-link. Pretty straight forward just HRF tag. That way when they tap it, it actually calls the phone number rather than them having to type it in which can be annoying.

A couple of options that are out there at the moment that are very good to starting places. There are available projects that are out there. The jQTouch framework and IUI.

Now, jQuery mobile is set to come out and many of you may have already seen that. That's on the way and it's the goal of that project according to the website is to create basically a jQTouch type of interface for iDevices but also for the Android platform and for several other smartphones that has a very nice visual displaying set up.

And here's an example of what jQTouch looks like at the time that I was messing with that here recently. On the same five browsers I tried the other side on, there are other basic kind of menu really. Opera and Safari look very similar but they function very differently. When using the jQTouch framework there's really a lot of really nice animations and things that happen in the Safari browser which do no happen at all in Chrome and then of course Opera, IE and Firefox because this specific framework is targeting a web kit type of a browser. You don't really get the same visual display although it does work it's just not interesting or exciting in those other three browsers.

Here's an example of -- I spent about a working day and a half or two working days or so with the jQTouch framework after the download again and created just kind of a little menu testing sandbox site for folks around the campus to look at and say what do you guys think of this? Works really well, very nice and easy to set up. Really what it functionally is. If any of you look at it you may have seen. It's basically just a big long single HTML page that is basically there's a bunch of references around throughout the navigation that pull up parts of the page. So it kind of chops it all. So it loads as one big web page. Very similar kind of to the type of technology that flashes where it loads one large file or larger file and then just calls up pieces of it as you're navigating around.

They seem to work very nicely. I'll give you a quick demo of that if you want. Does anybody have any questions for me?

Sir?

Audience 1: [21:03 Unintelligible]

Justin: Well, search engine optimization is --

Audience 1: [21:19 Unintelligible]

Justin: OK.

Audience 1: [21:20 Unintelligible]

Justin: Yeah, it could. With jQTouch, the way it's kind of set up is it's really -- it really loads one large HTML or XHTML file and then the separate different pieces of it are basically called up by the navigation elements. So it's -- like I said, it's similar to flash. It loads one big file and then you're kind of jumping around in the one file you've already cashed to see the different parts of it. So it seems to load a little better. And so the initial bringing-the-site-up kind of a thing is a little bit longer depending on what you've done with it but then once you're in it, kind of like a flash it jumps around a little bit more and it responses a little better because you've already got it loaded but is that the best way to do it?

It maybe not, it's a free framework. You can kind of piece-meal the things around it that you want to do but as far as optimizing it for search engines, if you're setting up a mobile search within that, it's definitely a good thing to do for when people are looking for it externally. Absolutely if you want to do that and now you're targeting specific key words or search terms based on what content that you've put into that mobile space for that site that you're setting up definitely.

I would always recommend using search engine optimization in what the projects that you're using are putting together for -- not specifically for the folks who are actually in the site but for people who are trying to find it and I'm not connected to the internet. So there's our demo of jQTouch, you're welcome.

Does anyone else have any other questions?

Audience 2: [22:55 Unintelligible]

Justin: Yes, the question was how do you decide what content to deliver to your mobile users?

That's a very good question. I would probably -- what I initial did, the reason I even started looking at trying to set up something from mobile or considering something from mobile was my Google Analytics results since we have such a great amount of money to throw around the things, Google Analytics is what we use for size stats and stuff.

And from -- I did a report for some of our management within kind of the IT area of our campus and from about September of '09 to February of this year, we had about 10,000 or so visits via the standard larger mobile devices. Take that same six-month period of time from February this year until the last month and an increase to 115,000 visits. Flew over 1,000% increase in traffic from the Android, iDevices, Blackberry, and Windows mobile phones.

So I showed that to some of the IT management guys I said, look, we've had a significant increase in traffic we need to start looking at providing some type of an interface for this possibly. Maybe strip off some of our styling for them to use so it works and then start considering what do we want to do in actual mobile site.

And Google Analytics or whatever sites that software you're using to analyze that would be a good starting point. What pages are these mobile visitors looking at? They might not be getting the content they want yet because it's not particularly styled for that environment possibly at this point but at least you can see where they're trying to go and maybe start trying to put some of that information in a condensed format over on your mobile site and maybe given them a quick way to email or call which is a tap to call link or give them a quick way to send some kind of a small feedback form where they could actually tell you what they want.

That was one of the things that I included on the kind of a one-for-all site was just a feedback button. It just goes to a little embedded -- a little form like name, email, and what-- what do you want and what do you think kind of a thing. Did that answer your question? Sir, do you have a question?

Audience 3: [25:00 Unintelligible]

Justin: Well, yes, because -- the question was I didn't show a page where you can see actually how Google Analytics really work or be -- would fit into these types of sites. Really they're just XHTML pages with CSS just like your normal desktop pages but you've used styling for your presentation of that content to kind of bring it down into a smaller screen display. So you could, just before your body tag, just like you do on a regular XHTML page, just stick your existing Google Analytics script right there or you could set up another account within your Google Analytics account on other site to specifically focus on these pages and have a separate UA number, separate Google Analytics where's the Urchin Analytics -- I don't know what the UA really stands for, probably not important, but you can stick it at the bottom of the HTML itself and start tracking that information separately. That answers your question?

Audience 3: [25:59 Unintelligible]

Justin: OK. And also -- you have a question?

Audience 4: [26:04 Unintelligible]

Justin: OK. So the question was about margins and padding and how that really works with positioning elements on mobile devices. Again, that would come down to what viewport are you trying to target. Margin and padding kind of set a static amount of space either around the element or within the element itself where your content is displayed which is a pretty simple stuff but as far as how you want to display it within the mobile environment that would really depend on what screen you wanted to target and how many pixels are available to you to display that.

If you leave it alone and do nothing, most of the smartphones as you know, they're going to see the whole page or just going to be zooming in and out. But if you want to get past that and actually provide something more condensed that's where the text is larger and actually the elements are a little bit larger, easier to tap on, easier for the interface elements to deal with, just as more like kind of a trial and error.

Kind of like I said with the beginning, kind of like geometry. It's just like whenever you're trying to set stuff up where it's going to work you just play with it. Mess around with it until it looks the way that you want. The less that you use margin and padding in the display of that if you can avoid them, I would say the better, although you're going to have to have probably a little bit particularly if you're using all CSS for presentation and you're not -- you don't want some kind of a goofy table or something or some other type of hack they're trying to make a display.

If the more you can avoid that, the more standards based you can make your code, the better overall experience your users are going to have regardless of the device they're using. And that's not just true for mobile devices as you know. I don't know if I answered your question or if it sounded like the political answer that gets around the question doesn't give the real answer. Was that OK? OK. Sir?

Audience 5: [27:52 Unintelligible]

Justin: I don't know if you can prevent them from accessing it although, you could do a user agent detection and then using either a service side or client side type of redirect. That will be up to you. You can do that. That will probably be simple way to do that.

Audience 5: And would that mean you're [28:24 Unintelligible]

Justin: I supposed that's possible. I don't claim to be an SCO expert in all the intricacies of that. It might make the keyword search from overall from your domain irrelevant because now you have two pieces of content that are different and have different URLs and now the same keywords being found or indexed twice within the same domain, so I would think that would increase the relevance of that search term if they appeared in both places. If you didn't want your mobile site indexed for search engines which you probably wouldn't really want to do that. You can just do a no-follow type of a meta tag or something.

But that will be really -- that will be a matter of choice and it depends on how you wanted that to be end up being found by the users of your site. That will be a matter of preference to some degree also. I mean, a lot of this is really that. How do you, as an institution, want to display your mobile content, how do you want it found, and how do you want the results of it to be displayed to people? Sir?

Audience 6: Really quick, on top of that if you got duplicate content like that just fill in like a meta tag in there for which piece you want to can your uncle reference to be. And that basically tells Google that there is a duplicate of this and I want you to always reference this piece instead of this piece.

Justin: Alright, thank you. Go ahead.

Audience 7: I just want to get my [29:46 Unintelligible]

Justin: OK, thank you. Sir? Yes? So a couple of comments were about if you have a mobile site, you have a desktop site, you have similar content on both or maybe identical content on both and the comment was to put a conical reference into the meta tag to actually specify this is my primary content, this is the secondary, don't index this secondary content because it's not really necessary it's already here and to not be deemed for just trying to duplicate the content to get better search engine results.

Audience 8: [30:50 Unintelligible]

Justin: I'm sorry?

Audience 8: [30:53 Unintelligible]

Justin: Well, again, this isn't a search engines optimization session so I'm not going to -- I can't say that I'm prepared for all your search engine optimization questions but that's good information and it's good to know. The gentleman mentioned that there is a duplicate content panel within Google search engine results. So it's a good idea, good practice according to the information that we're talking about here. It's a good practice to not have those things be duplicated.

Audience 9: I was wondering about how those [31:27 Unintelligible]

Justin: A user agent detection as opposed to CSS? Not necessarily opposed, you see we have CSS set up to properly display to the particular browser that you wanted to target or set of browsers you wanted to target and then you would use something on the front end either on the service side or the client side depending on what your preference is. You can do either and both do work. It's really up to you on how you would want to approach that. And then you would have that user agent detection process then direct the user based on what the response is to whatever the content is you want them to see. Sir?

Audience 10: [32:07 Unintelligible]

Justin: The question was some sites actually strip a lot of content out when they direct you over to a mobile site. Let's say you don't have the same information or there's some links that maybe you do want to get to but you're not seeing in your mobile environment and there's some cookie-based ways to try and keep some of that stuff in tact when someone jumps over to the mobile site. That's definitely one way that you could do it. You could set a cookie, you could -- that was one of the discussions that James Pearce had on mobiforge.com, one of his articles about not device detection.

You could actually create basically a process where -- and it takes a little bit of setup, it's not overly complicated to do but it's a process. We actually set up -- a cookie gets set basically in the user's browser where when they first visit the site the server asks them or basically does a user agent detection.

It says, OK, are you one of these major OSes, if you're not, I'm going to give you the option to choose desktop or mobile site and then whatever you choose I'm going to set a cookie and remember that for you. And also on the other site a bit about -- you're talking about certain menu items, the content not being available in the mobile version of your site that again would come down to what information do you want your mobile users to be able to get to? That's probably where a feedback type of a process within that mobile environment would be very helpful at first.

I mean, I need that forever but it is not a bad thing to have forever on there. Just have a very simple way for a user to send information back to you. Hey, I was looking for this and see it I had to jump over my laptop or desktop to get to it and it was easy to find there but it was difficult to find in your mobile site, I like to see it. And you could also follow that up by doing some regular analysis of who's visiting your mobile site, what is it they're looking for, what type of search terms are you getting, all that kind of stuff and it's going to be a growing and kind of changing thing for you as you get better information about what it is that those users are trying to find.

And so it's a process just like with anything and you just have to kind of continually analyze what it is you're doing, what you're presenting, and what the users are really looking for when they come to that mobile environment that you're putting together. Did that answer your question? Sir.

Audience 11: [34:30 Unintelligible]

Justin: This was one that, honestly, doesn't work all that great. It sort of works that was this one here. Like this paragraphs about whatever.

And when you place your finger on it then you have something that pops up. It doesn't really work that great, to be honest with you, because the environment and the interface doesn't really lend itself all that great to that type of a thing. It was a question I actually had and I said, well, is there something out there that might do that. This does seem to do that sort of but it's kind of clunky and it's not really very consistent and particularly across the different smartphone browsers it's not consistent at all.

I just threw in there something you can mess with and try and see if it works within your particular interface or environment. It may not be an answer or something you would want to consider. And it's particularly because the interface; you don't really have something resting in that place. Typically, people are tapping and taking their finger off. They really would have to kind of hold it there to see it for it to work properly and it's not really, from my own interaction of watching people, it's not really what I'm seeing. You could use some other method, actually have something pop-up in display and I think that will be a matter of preference or choice.

Audience 11: [36:01 Unintelligible]

Justin: Yes, that's correct. Holding your finger on there doesn't actually -- you're doing the less stuff now not browser stuff anymore within the mobile smartphone environment. So it's not really the greatest -- not really the greatest thing. Maybe I should take the slide out of the presentation but it does sort of work sometimes sort of not. It's almost --

Audience 12: [36:27 Unintelligible]

Justin: Yeah.

Audience 12: I think [36:31 Unintelligible]

Justin: Right, that's a good point. If you're having a -- if you have a pop-up menu or some type of other tool -- you want to have displayed then maybe you have some other type of function or other type of thing that actually causes it to appear based on some action that's taking place on the page and then you choose to have it displayed in some other way but still looked like a tool tip but maybe it's not a tool tip but some other kind of thing that's happening to display to look like that to give you the -- give the users the return back from the page that you want.

Got a question? OK. Sir in the back?

Audience 13: [37:18 Unintelligible]

Justin: Yeah, the question was about ADA 508 compliance XHTML 1.0 and is that going to work with screen readers and various other things. And that is an entirely different topic, really, but it's a very, very valid one because when you design for standards, when you design with your code set up in a nice semantic readable way, when you're using heading tags for important heading information, when you're using paragraph tags for text content and when you're taking care to think about how the old tags are placed in your content for images and various things, and actually download Window-eyes or JAWS and try it and actually see what it sounds like.

And actually close your eyes and see if you can navigate your own site. It's probably one of the best ways to see if screen reader technology is going to work is actually use it. Blindfold yourself and try it. Again, different topic from what we're talking about here but really it kind of all comes together into the same thing because if you start off with the right approach and say, I'm going to design this like universally, I want this to work on a mobile device or at least some of the content to work on a mobile device.

I want it to work on the desktop type of a fullscreen interface. I'd like this to work also and to be usable by folks who can't see it because they don't have the ability, cognitively or physically, to see my content, so I need to make it work. And that's a very good question to ask about that because that also, when you design it in a way where it's web standards compliant, you're also creating content that can then be reused and better used by other types of systems or technologies as well because you've now taken care, you've structured it well, separate your content from your presentation very well, and choose then how do I want to display it or how do I want to render my content based on what type of technology is accessing it whether it be a tactile reader device, whether it be a screen reader, whether it be -- someone with high contrast or very differing visuals than your eye would probably be experiencing on a website.

So like I was saying a little bit at the beginning, if you have a nice XHTML CSS standards compliant design then you're starting off with the best foundation you can have. Sir? Oh, OK, we have one minute. Does anybody else have a question? Sir?

Audience 14: You have a little bit of a [39:55 Unintelligible]

Justin: That's a good question. The question was what kind of content would you really want to see in there? Are you going to see undergraduate recruitment websites on your mobile device? You could have that. You could have some very condensed information that's really kind of bullet point stuff that will maybe jump over to maybe an RSS feed of news, press releases which display very well on mobile devices, just text and images and things.

Like here for example, when I was putting together this kind of really sandbox to mess with jQTouch, for example, we have an iTunes new instance so I threw that out there for use on iDevices, a contact section that has just very -- office hour, phone number, email, stuff that work for the mobile device tap-to-call tap-to-email. Campus news the third link there down in the center, screenshot is just an RSS feed, comes out of our homepage, have it displayed and reused other places.

Campus updates is just a pull of a Twitter feed from our campus. And those are really just fed through feed burner, come back as an RSS and then displayed how we want them using the CSS within this environment. Main website, look at that, it's basically, that's opening on a separate window. jQTouch gives you away a little pop-up, this is going to open in a separate window. Does a full-page Twitter feed. The blackboard link for our Learning Management System at our campus. Could be a link over to a page to download the blackboard learn mobile app. Users already in a mobile environment if they're tapping the link there if I want to see either the mobile app or some information about that. You can send them the --

Audience 15: [41:38 Unintelligible]

Justin: Based on a number of things are some feedback requests that we got from the helpdesk these are what the people are asking about. Here's what a lot of different folks are looking at at a very high number of hits and things from our homepage and through search terms and other things.

Facilitator: I hate to put this off.

Justin: OK.

Facilitator: Thank you.

[Applause]