186. Mobile Web

On this week’s show: Brian Suda talks about the mobile web and Marcus suggests ways of responding to email inquires.

Download this show.

Launch our podcast player

Win Pitches, Charm Clients and Get Signoff

Being a great designer or developer is only half the battle. You also need to be able to promote and sell your services. Unfortunately many web designers and freelancers struggle to engage with clients.

The problem appears to be so big and I get so many questions on the subject that I have teamed up with the guys at Carsonified to run a full days workshop on the subject.

It takes place on the 23rd of October in London. If you book soon the price is £375 although if you quote the code CWPB_09 you can get an additional 15% off.

Book Your Place Now!

Back to top

News

Sign up, Log in

Everybody hates signing up for new services. We also hate having to log in especially when we have ticked that little ‘remember me’ checkbox (or at least we think we did).

There is so much that can go wrong with sign up and log in, from lost passwords to mistyping. It is therefore vital that the usability of these forms is as good as possible.

This week I have come across two posts that might help.

The first is a post by Jeremy Keith in which he challenges two current practices for sign up and log in forms. The first is the practice of requiring users to enter an email address or password twice. The second is the default on ‘remember me’ buttons, which generally seems to be unchecked.

The second post I wanted to mention is a brief review by Techcrunch of the new Facebook Connect Wizard.

In case you haven’t come across the Facebook Connect Wizard, it is an easy way for anybody to add Facebook Connect to their website even if you have no coding knowledge. The wizard seems to consist of three simple steps that take a matter of minutes. Once complete users can log in to your site using Facebook. One less username and password for people to remember.

Search results design

Smashing Magazine has released a post that looks at how a large cross section of websites deal with search design. This follows on well from the recent A List Apart edition that dealt with search and we mentioned on last weeks show.

The Smashing Magazine post analysis’s the search design for a whole range of sites from Google to Walmart, and draws some interesting conclusions. These include some great advice such as:

  • Visited links should be indicated
  • Where possible, results pages should have RSS feeds or “subscribe” options
  • To monitor future improvements, request feedback from users after searches are conducted
  • If results span different sections of the site, indicate this by sub-headings or other dividers
  • Should allow re-sorting or filtering of results

Of course, just because a lot of websites have a certain approach to search, does not mean it is best practice. I have often seen bad practice copied from one site to another. That said, the list of recommendations seem solid. To read the complete list of suggestions check out the post on their site.

Is Windows 7 about to make our lives easier?

I was reading a post on Sitepoint this week entitled ‘Why Windows 7 Will Revolutionize Your Browser Testing‘ and it has started me thinking.

The part of the post that particularly caught my eye was XP Mode. This allows users to run IE6 for specific web applications under Windows 7. However, their default browser will still be IE8.

This will change everything. As I have said numerous times before, the reason IE6 survives is because of legacy systems within large corporates. In a single move this will overcome the problem. If they can use IE6 for these systems and IE8 for everything else then life is rosy.

There is a lot of positive buzz around Windows 7, and I know many large organisations who skipped Vista entirely are now serious considering upgrading. If that is the case we should see the number of instances of people running IE6 fall through the floor over the next year.

Finally we can move on!

CSS: From beginners to advanced

With the increasing buzz around CSS3 it appears CSS is having a renaissance. There are a growing number of articles which focus on emerging CSS support and browser manufacturers are falling over themselves to add new features.

This week Firefox 3.6 Alpha has been released adding support for a number of interesting new CSS features.

Sitepoint’s post ‘CSS3: To Infinity and Beyond‘ catalogues some of these additions and looks at how wide browser support for these now are.

The list of new features include:

  • Background resizing
  • Multiple background images
  • CSS gradients

Of course, unsurprisingly IE support is scares. However, with the proper application of graded browser support this should not be a major issue.

If you are starting out with CSS all of this talk of CSS3 may seem overwhelming. However, there is still some great advice being posted for you guys too.

One post you might want to check out is ‘30 CSS best practices for beginners‘. As the name suggests this should get you up and running fairly quickly and ensure you are building sites in the right way.

However, one word of warning. A few of these best practices are not so much… best practice. In fact some of the advice is down right bad! But do not let that put you off of reading the post. The editor has actually responded to the bad advice explaining why he believes it to be wrong. As long as you read his comments too you will be fine.

Back to top

Interview: Brian Suda talks mobile

Paul: so joining me on the show today is Brian Suda. who is on to talk about mobile web, good to have you on Brian.

Brian: Thank you very much.

Paul: Thank you so much for coming on, I think a good place to start would be if you tell the listeners a little about yourself and why the mobile web, and why we are talking to you about that in particular.

Brian: My background is originally in programming and software systems. I did my undergrad in massuri US, from there i moved on to the uk and Scotland, where I studied more about infomatics. So im really interestedin the background aspects, all the technical issues. But alot of the things iv developed when i started working on sites is more the front end and the usability, the way people think about mobile. Recently I’ve been working on lots of little mobile sites here and there as a freelancer all these new kind of mobile. Its getting much bigger and i think now is about the time the customer should be looking into it and the right time for them put their feet into the water or take what they have and maybe take it to the next step.

Paul: hmmmm, i mean one thing that’s knocking around a lot that people talk about when it comes to the web is the one site fits all mentality. Which raises the question of do we need to be doing things specifically for mobile devices or if we build out websites right can we avoid the whole problem.

Brian: It’s a very interesting question. Because the W3C does push this concept of the one web and there are definite pros and cons to it. The definite pro is maintenance costs, if your only dealing with one website you don’t have to worry about updating and keeping things in sync with data and things on a constant basis. But at the same time there are certainly different aspect to the way people use the site. One of the things that we really try to do is keep the one web in mind and really that means all the same information is available. It doesn’t have too look exactly the same or being the exact same format, it just needs to be available to the end customer.
So one of the things we’ve been stressing is that we don’t like the words “mobile web”, were trying to find a better term for that. Mainly because “mobile web” infers that your using a mobile phone or some sort of mobile device but thats not necessarily the case i mean the way we picture the mobile web is its about mobility. I think they’ve got mobile as a noun and it should be mobile as a verb. You are moving, your mobile. So really the same kind of site doesn’t always work. A good example of this is if you have a fancy iphone or ipod touch and your at home sitting on the couch you have no quarms about viewing the full bbc website. Your on wifi nice fast connection no big deal. But if your out on the move, want to catch the tube, or your late for the bus you want the mobile version of the site. Because you want it quick, you might be on GPRS or edge, you don’t have the time or the energy to download the full bbc website. So its not really about the device, its more about the situation.

Paul: Thats quite interesting that you raise, obviously the iphone is going to come up in the conversation when we talk about the mobile web as does android and the various other new operating systems that are emerging. The one kind of trait all these have is they have this rich browser experience, you know quite powerful browsers and again the other question i guess people are saying is the idea of designing for mobile devices going to disappear because the browsers are so capable. But i guess this issue of environment and situation applies whether or not the browser is sophisticated.

Brian: theres also going to be situations where even if you have a very robust browser, form input is always going to be a pain. So even though you may basically have safari replicated for the iphone it maybe easier to just have a phone number. I mean you have a device in your hand designed for making phone calls, thats what it’s number one purpose is. To force someone to fill out a form can just become a ridiculous pain, it disappears into the web somewhere and maybe someone will answer in 48 hours, but you maybe sat in an airport having lost your luggage. You know you want to talk to a real person immediately, not fill out a form. So i think there is always going to be situations where the medium or the situation is going to define what you want to do.

Paul: i guess also you were mentioning there about whatever mobile device your going to be using its difficult to fill out a form. I mean that brings up the whole issue of the user interface, that mobile devices are very different in terms of it’s not a mouse and a keyboard theres lots of different interfaces and i’m guessing thats problematic as well.

Brian: certainly, i mean navigating either between tab, the opera browser will do it one way where the down button will scroll through the page through the links, where the iphone everything is done with your fingers. So yeh its going to be different interfaces means different ways of doing things. Some flyout menus when you do on hover just don’t work on some devices. And i guess that comes back to basic web 101 accessibility and progressive enhancement. You know, make sure it works without javascript, without a mouse, just a keyboard and then start layering the information on top of that.

Paul: does that mean that there is going to need to be a lot of device sniffing to identify your on an iphone there for you have a touch interface, your using an older mobile device there for your using a keyboard or whatever else. Or is there another way of doing that?

Brian: unfortunately yeh, browser sniffing is one of those things that everyone says you shouldn’t do and it technically usually its done in a bad way i mean we all experience browser sniffing when we go to out banking website and the website says “sorry you must have firefox2 or higher” and you know you’ve got version 3, you scratch your head and figure they can’t do the math. Its usually because they browser sniff and then restrict what you can do. Where you should do it the other way around and say heres a working website, we are going to try and determine what browser you have and then layer extra functionality on top of it. And again this is one of those things you can skim the surface or you can spend working on it and tweaking your site, and its going to really depend on your audience. So with someone like the bbc who might have loads and loads of resources might want to go through and wrap loads of if statements around all different parts of their website. But then it becomes a trade of between maintenance and usability vs how much of a good experience your customers get.

Paul: I mean you eluded earlier to this issue of context, the environment and surroundings that people are in and i heard Cameron mold* SP speak on a similar subject. I’m just interested in your take on that an you know what kind of elements come into it. I know we’ve talked about user interface but what other element of context are important to consider.

Brian: can you give an example?

Paul: well, the one that springs to mind i guess is environment. You talked about being at the bus stop is an issue, there are other things like that.

Brian: sure, Google a few years aog did some really deep research into all of their properties Gmail, docs and everything like that and they realised that their mobile user base fell into 1 of 3 categories. There was a sort of “bored now” – people saying ok i’m waiting for coffee, i’m waiting for a friend i’ve got 10 minutes to kill I want to go do something, just to keep me occupied. And youtube does a good job of this, they say “we know you just want to waste some time so heres the top 10 most interesting videos”. So its not so much browsing and searching its just keep me occupied. Another category is the “urgent now” – so theres been an accident outside or the powers been cut. Thats good example of because if your power is cut your internet connection and regular computer might also be down, but you want the phone number of the electric company to report the outage or see how long this is going to take, maybe the only way to do this is through the mobile interface. This si one of thing you want to bubble up, if your the clientele your expecting this kind of information your wanting to bubble this information upto the top. We did some work for some airlines and we realised this is one of the categories “have i missed my flight” don’t burry this information 5 levels deep. The last category is “repetitive now” people who want to check their stock, the weather and they are done. They’re not here to browse necessarily or spend 30 minutes looking at the website, they are looking for one key piece of information and they are done. So depending that your customer base is these will kind of lead or guide your design decisions and usability and how you layout your website.

Paul: thats really interesting in terms of the different kind of content that you bubble up depending on the kind of device your on and the situation your in. I mean i guess that leads on to a more question in that there are a lot of website owners that are listening to the show, you said at the beginning that people need to be thinking about the mobile web, how do you go about deciding whether your content and what you provide as a website owner is relevant for a mobile device or ifits not. And then what out of your content is worth taking across to the mobile site, and whats not relevant.

Brian: sure, you can probably ask that same question of a regular website. The guy on the corner who is a corner, does he need a website and does he even need a mobile website. Maybe he needs a mobile website more than he needs a real website. Again its so easy to get started in the mobile area because you don’t need to learn anything new, you can do it with all the existing html and web standards now that you already have. Its just a matter a repurposing it or thinking in the context of a mobile device. A lot of that is just realising screen width, bandwidth information you can cram on a page, there is a few things to learn, but its not that difficult to get you feet wet and i would argue that its best to get started on the cheap and easy and see if it works. Try early and fail fast. From there you will kind of learn what your customers want, one of the things we kind of keep in mind is we don’t like the term mobile website so what we’ve tried to come up with a new term. We tried to think of sugar free or fat free. So we kind of framed the situation as the traditional desktop website we call that either full flavour or full fat, and then what people call the mobile web we call the sugar free or fat free. People understand fat free and full fat, everyone understands those concepts. So because its about the situation we might say ok im at my desk and im getting a million phone calls about x y z. sometimes its easier for me to look at the mobile website on the desktop computer because there is no ads and there no company history or anything. It’s just the raw information i need. So if you start think about it in the terms of fat free of full fat its other side consequence is if you are developing a mobile site and you boss may say we need this this and this. Your like ok its mobile site we can just add another navigation item, but if you start talking about things in terms of fat free when your boss comes to you and says we need this, you can say well is you site still fat free if we are adding more and more navigation links? And its a way to argue against feature creep.
P. yeh, that sounds very sensible. You said something very interesting there, you said its very easy to get started on the mobile web. And i can’t remember where i heard this, it may have been from you but someone once said something like as web designers you get really annoyed when a print agency turns around and says we can do the web as well. And yet web designer oh yeh we can deliver the mobile web. So i’m just interested in your perspective as to whether web designer should even be trying to do this kind of development or whether its really down to a new breed of mobile web specialists because there are different element involved in it. So is its something web designers should be doing and should websites owners be looking to them to do it, or should they be looking elsewhere?

Brian: thats very good question. I like the analogy of print design, because there will be loads of people who’ve bought a computer and get on indesign and all of a sudden think they are a print house. I think form a technical point of view there is nothing greatly different between a mobile and normal website. Its the same html, same knowledge, same standards and code. The bigger difference is the usability and the way people use the device, how you lay it out. You can probably make the same argument between web designers doing websites, like business card websites and web apps. There is still a lot of design element and design ideologies that transfer between both of them. Maybe in another year or two there will be a bigger niche for someone who specialises in mobile websites and usability. It’s one of these things people are hammering on the door mobile is the next best thing, for 5 or 6 years now and it’s always next year. Maybe it will be the same with specialist, but maybe again it’s a chicken and the egg and we need specialists before we get mobile websites. It’s a good question i don’t know.

Paul: ok, fairenough. I mean you talk there about technically its relatively straight forward to get going maybe you could kind of give us some ideas of where to start. There are web designers here that want to kind of explore it from a technical point of view, what are the common mistakes and what do they need to be aware of?

Brian: erm, well there’s a few of them i guess. Depending on the audience, that’s the first slice you need to taste. Who am i developing the site for? Sometimes it maybe internal to a company and sometimes it maybe very high profile and you realise most these people aren’t going to have iphone they will have blackberry or something similar. You need to figure out what your audience will mostly be using. This is just base line. The bbc would have a different set of rules, but this will get you started. Find out what their device is and what they are capable of. Most of the newer devices have a decent web browser, maybe running webkit or some other new browser that can handle html and xhtml. And then you can code up your sites like you do normally. Some older browsers and phones don’t necessarily handle all the css or everything in the same way, and then people argue its like coding for the web cerc 1999. You need to get back to tables etc it’s not pretty. Again it’s all down to how far and how deep you want to go. For things to get start there lots of good resources out there i know dev.opera put a few article up about introducing / getting into the mobile web. Theres lots of stuff on the web as you said Cameron mold *sp. I could send you some links for the show notes.

Paul: yeh that would be really useful people are always keen to take these in and move on with them.

Brian: i think it’s also a bit of stigma that everyone kind of assumes its quite difficult because they here these buzz words like 3G and WAP when in reality a lot of it has past now because the phones of today are capable of rendering html. I think people are just a little gun nshy of where to get started. I think it’s not as mystic of an area as people assume.

Paul: ok so, presuming then that the technology side isn’t too bad, let’s talk about the design side, the layout and the usability that kind of thing. Which is a different environment that we have been used to designing desktop applications. Tell us about some of the common issues and mistakes.

Brian: certainly, the biggest one is probably realising the vast variety of phones and browsers outhere. The physical device itself varies in just screen width and colours and what each is capable of. Where on a desktop it’s probably ranges from 800 to 1600 pixels and we have all these grid designs. Really in the mobile world it breaks down to screen from anywhere such as 88px to 120px all the way to the iphone at 480 in landscape. So how do you design for this, most of the time it ends up being a stack, where you stack them on top of each other, much like the iphone navigation. That at the moment seems to be what is falling into place. It’s probably like the rules of the web in 1999 when you have navigation in your left and then header and body area. As things develop trend and design of how things will flow evolve as well. Design wise things like the iphone handle lots of css just fine, some phones don’t. This kind of forces you to all the little tips and tricks with css where you put in h1 then indent text with negative marging and replace with background image. But it doesn’t always work when you get to mobile, maybe it won’t show background images. Maybe the blackberry doesn’t display images at all due to bandwidth. So there are always little catches here and there, it’s just a matter of testing, its going to come into alot of time on device. People assume testing, you’ve got to buy an iphone.

Paul: I was about to ask that.

Brian: the simplest way is you probably look around the office, maybe now everyone has an iphone. You code it up, you go around everyone and look at everyones phone. You go around and spot any issues. There a few other companies out there who you can buy time. I think device anywhere who will rent time on their server farm, you load a little java app…basically a webcam and you can see the phone in front of you. And you can say no i want to try on this and this phone. It allows you to get a quick grasp of what’s going on. Again nothing is ever going to be pixel perfect but once you realise, ok background images don’t work you have to do it this way. You get into a rhythm after one or two go around of what does and doesn’t work. if your a freelancder or do it for your company, you build up a nice little template and test suite so you know what works and doesn’t. So next time you pull out your template and your pretty much there already.

Paul: you mentioned there about what everybody in the office is going to have an iphone. I’m picking up a kind of trend that everybody within the web design community are excited about the iphone or love the iphone. It’s got a very capable browser that can do a lot and they know there is a good audience there and they are just going building application or websites that are optimise for the iphone. Do you think it’s a mistake, should we be looking to produce web content for a broader range of devices or is it ok just to target one or 2 deivces.

Brian: i would personally say that it’s a bad idea because I’m more of the thought that it should build a baseline set that works everywhere and build on it. That being said google said that 505 or more of its traffic is coming from the iphone so it’s a massive player in the audience that you can’t ignore. If those are your customers and your trying to sell something and you want to give them the best experience possible you may have to spend a bit more time and optimise for the iphone. Again whoever is the main one in the market, the iphone at the moment, the competition is going to build to that spec. So if you optimise for what’s in the lead and the other ones will come along to meet it. Again it’s not a great philosophy, again you at the click here for IE click here for netscape type thing. Best viewed in iphone browser. Which i prefer to avoid but it seems not be the way its going right now.

Paul: i guess you also need to take into account how people are using those phones. For example we know there are phones out there that are more popular than the iphone but iphone users are the ones accessing the web so it’s the number of people using the web using the device rather than number of handsets out there i guess.

Brian: yeh, the most famous kind of quote number against it are nokia 1100 phone little candybar phone, for everyone 1 iphone out there, there are 14 of these nokia phones, but they are the old green screen doing sms and that’s about it. Like you said the iphone isn’t a high percentage of the phones out there but it is a high percentage of those who are using the web.

Paul: its ultimately ROI that if you’ve got limited budget for this your better of concentrating on the device which the users are actually using the web. I guess to some degree that you also know iphone users are relevantly affluent if you’re selling something. If its an ecommerce site then that’s worse considering too i guess.

Brian: very true, very true.

Paul: so just to kind of wrap up here, where should people start where should they go from here. They’ve herad this interview, maybe they are a website owner or designer what should those 2 audiences next step be in investigating the mobile web be?

Brian: from a technical point of the easiest thing to is to make a few mock ups, that’s probably low cost to just get your feet wet. Test it on a phone or two and then show it to a boss or the rest of the team and say hi look, this took me an afternoon, i’ve learnt something new look how great it is. From that you don’t need to make it public, some of the sites we have done in the past have stayed within the company for 6 months maybe a year, sometimes even never launched. Just to kind of get internally the feel of is this we want is this what we want the public face to be. Can we actually release because this it has less features. So t’s not a huge commitment you don’t have to announce it to the world, i guess that’s one view of developer. From a design perspective i guess it’s just how and the usability works, what you can and can’t do. A lot of css doesn’t work, understanding that will give you a leg up when you want to develop a real website. If you developing a traditional website you may use x hours in photoshop and x to cut it up, if you quote the same thing for a mobile website you will probably be well of, a lot of going back and forth. So learning some of this early on is probably going to help you alter on when you want to pick up and quote on a job or you want tp pitch something. Your going to be more realistic and it will certainly take more hours. Some skills will transfer but it will be a bit of learning curve.

Paul: ok thats really great thanks for coming on the show and we will include those links if you send them over. Thanks very much for your time.

Thanks goes to Andy Kinsey for transcribing this interview.

Back to top

Listeners feedback:

We have been collecting some subject suggestions via Skribit. Some of the suggestions do not justify an entire blog post so we thought we would respond to a couple here.

If you want to submit an idea, use the Skribit widget in the right hand column of this blog.

Responding to email enquiries

When we receive an email asking for a quote how do we follow it up?

Well, the honest answer is… it depends! People get in touch in a number of ways and with varying levels of detail in their enquiry emails. Blunt honesty is usually the best policy so I will say that the first thing I am trying to gauge on any enquiry is whether or not we are a good fit financially with the prospective client and whether or not we can deliver whatever ‘it’ is within the requested timescales.

I have talked about this in the past so won’t dwell on it too long but, I have been bitten too many times not to consider it important. Only a few months back I spent nearly a week putting together a proposal for a prospective client that was dismissed out of hand because it was too expensive. What an utter waste of my time and, please note, a fairly large waste of this particular client’s time too. It takes a fair amount of time to wade through a hundred page document and, if they had provided budget information I would probably have passed thereby leaving the way for another agency who may well have been their first choice. Grrrr…..

Calm… calm…

So, before getting into any serious detail about a project I will ask people about their budget. If they don’t know then I will talk about the kind of prices associated with a particular type of project. If the figures seem to fit reasonably with expectations then I will ask about delivery deadlines (and why they exist). Often deadlines exist because people think they should have one but equally there may be a flagship conference or similar that the ‘site’ must be completed by.If we can reach a rough agreement on budget and timescales then the next thing is usually for us to put together some kind of quote or create a proposal.

For pretty much any job I will ask the client for a brief describing the work. In fact, most enquiries have some sort of brief attached to them (for those who don’t I often direct people to a questionnaire on the Headscape site that asks for the kind of information we need to put together a proposal). But often, briefs are extremely well written and can therefore easily be interpreted into a project. Often they’re not and require a lot of discussion to get to the bottom of what a client is looking for. Usually this will be done via the phone and email but often for larger more complex projects we will want to meet face-to-face prior to creating a proposal. Geography can be a big factor on whether that happens though!

All in all, it’s a balancing act. I have to carefully judge whether something coming is a good fit with us. This usually means being quite direct with a potential client (I’ve learned that beating around the bush doesn’t work!) but, of course, I really don’t want to upset anyone or give an arrogant or aloof impression which is possible if you’re trying to tell someone that they can’t afford you!!

It’s so hard being me. Please send more jokes to cheer me up.

Back to top

  • Thanks for that great interview on mobile! If people are interested in going deeper, I can heartily recommend “Mobile Design and Development” by Brian Fling. He does a great job explaining how to approach mobile from a variety of directions. Plus, it’s a fun read – if you’re a geek ;-)

    (sent from my fone)

  • Rob

    Good podcast as usual. Any chance of those mobile web links?

Boagworks

Boagworld