Boagworld

A blog, podcast and community for all those who design, develop and run websites.

Skip to content
Boagworld
Menu Subscribe
  • Boagworld
  • Podcast
  • Archive
  • Forum
  • Books & Talks
  • About me
  • Hire me
  • Boagworld
  • Podcast
  • Archive
  • Forum
  • Books & Talks
  • About me
  • Hire me
Subscribe Now
First time visitor to boagworld? Find out how the site can help you with our Guide to getting the most out of boagworld

Tag Archives: log in

186. Mobile Web

Posted in Classic shows on October 7, 2009 by Paul Boag

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

Play

Podcast: Download (33.8MB)

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

126. Scaling

Posted in Classic shows on July 14, 2008 by Paul Boag

In this weeks show we learn lessons from the botched iPhone launch here in the UK. We chat to Jeff Veen about the designer / developer relationship and Marcus talks about adding jingles to your website.

Download this show.

Launch our podcast player

Watch the behind the scenes video (Part 1)

Watch the behind the scenes video (Part 2)

News and Events

The Mobile Internet has reached critical mass

This week saw the release of a new report by Nielsen Mobile entitled “The Worldwide State of the Mobile Web“.

The gist of the report suggests that the mobile web is considerably more popular than many of us would believe. 15.6 percent of mobile subscribers in the US and 12.9 percent in the UK, use the mobile web regularly. In the US this equates to 40 million users. A substantial number.

Interestingly the most common device used for accessing the mobile web is not a smartphone but rather the Motorola RAZR. This reenforces the answer I gave Wayne in last weeks show. I said we cannot design exclusively for devices such as the iPhone.

With people like the VP of Google stating that the future of the internet lies with mobile users, there can now be little doubt as to the direction things are moving. This is especially true now that we are seeing unlimited data plans.

Web Standards Curriculum

A regular complaint I hear from students is that they are concerned about the out of date techniques they are taught at school or college. With many institutions still teaching table based design it is a legitimate concern.

Fortunately they are not alone in this concern. Opera and Yahoo! have teamed up to produce a web standards curriculum. This curriculum teaches best practice in web design and is broken down into modules that can be taught either by themselves or part of existing lesson plans.

If you are a student or educator definitely check this out. Hopefully you can get it adopted at your institution. Even if you cannot, there is nothing to stop you working through the course yourself.

Working with designers

Although our next post reads slightly like a rant (I should know what a rant sounds like!) it nevertheless communicates some excellent advice.

It is a post aimed at clients and provides 12 tips for working with designers. Advice includes leaving preconceived notions at the door, be specific in your requirements and design for your customers and not yourself.

There is no doubt that many clients serious misunderstand the role of the designer. However if I was a client reading this, I might find the tone hard to swallow. Despite that I would encourage those of you who work with designers to read this article. My favourite quote is…

Just as writers are not just people who can type, designers are not just people who can use graphics programs.

Web form design patterns

Our final post this week is a survey Smashing Magazine have done on 100 popular sign up form. The idea of the survey is to give you a better understanding of what makes an effective sign up form.

Of course, just because other sites do things in a certain way, does not make that the best approach. You should never blindly follow the crowd. Nevertheless this is a fascinating read.

The post is split into two parts and contains information such as…

  • How the link to the sign-up form is titled
  • The placement of sign-up links
  • Whether the sign-up form is a single or multiple pages
  • How labels are aligned
  • How many fields are mandatory
  • What help and tooltips are provided
  • How validation is managed
  • How error messages are designed
  • Is it necessary to confirm the email address
  • Is it necessary to confirm the password

The list goes on.

If you are looking to justify design decisions you have made or need some help designing the perfect signup form, this is a great place to start.

Just a quick reminder that the news we feature on the show is only a fraction of what myself and Paul Stanton post on the website. To get a more comprehensive view on what is happening in the world of web design, make sure you subscribe to our news RSS feed.

Back to top

Feature: Lessons to be learnt from O2

I am not sure whether you noticed but this last week saw the launch of the iPhone 3G. It would certainly have been hard to miss it.

I don’t want to add anymore to the endless discussion surrounding this launch. However, I would like to focus on a side issue. I want to look at how O2s website handled this momentous event and what we can learn from their mistakes.

Back to top

Interview: Jeff Veen on working with developers

Paul: So I’m very excited to have Jeff Veen joining me today on the show. Good to talk to you Jeff!

Jeff: Oh, it’s absolutely my pleasure. Thanks for having me!

Paul: Well it’s really good to get you on the show. I’ve wanted you on for ages, but I haven’t had the guts to kind of approach you so I sent Ryan to talk to you instead. I feel vaguely like, you know, you get at school discos where you fancy a girl and you send your best friend over ’cause you don’t have the guts to do it yourself. Or is that just me?

Jeff: Well I’ll tell you, I’m happy to have this dance Paul. It’s great.

Paul: Right, well for those that don’t know you Jeff and don’t know your background can you just tell us a little bit about yourself and how you ended up in a situation where you ended up working for Google. You know, how did that come about happening? ‘Cause that’s what we’re going to talk about a little bit today is your experiences of being at Google.

Jeff: Well, I tell you I’d been working with developers, as kind of more on the design side for quite a long time. Do you remember hotwired.com from Wired Magazine?

Paul: Oh yes, definitely.

Jeff: Way back when, right? Like we launched that back in 1994 and that’s really when I got started on the web, was coming over to Wired, working on their online properties like Hotwired, Webmonkey, and HotBot search engine, you know stuff like that. So I was with them for quite a while, they went through an acquisition and brought us over to Lycos, that big search engine. And then from there I started a company called Adaptive Path. Adaptive Path is a user experience consulting group in San Francisco. It was seven of us, we were all friends from the industry. We really focused on research, design, information architecture, usability, stuff like that. And I did that for a number of years with them and then finally convinced my partners that doing a product would be something interesting for us to try. We had done consulting. We had done some events. So we were kind of looking for the next thing to try. So I put together a small team of developers and some other designers and we made a product called Measure Map. That was a web analytics tool aimed specifically at bloggers. And just as we were about to launch it, we had done a bunch of work on it, Google gave us a call and said, “We love what you’re doing. We want you to come over and bring that to Google.” So we went through an acquisition there and that’s really how I got to Google.

Paul: Ahh, I see. ‘Cause I remember very vividly Measure Map coming along and getting very excited about it and then it kind of disappeared.

Jeff: A little bit, yeah.

Paul: Yeah, ’cause you got swallowed into Google.

Jeff: Well Google was very clear that they had a lot of respect for the work that we had done around designing Measure Map and wanted us to apply that expertise to their big Google Analytics product which had recently, sort of. They had acquired a company called Urchin, which had kind of an enterprise analytics package and they had made it free, and that had brought it to a whole new audience that really, sort of, didn’t quite understand how analytics worked. So we brought some of the best practices of design into Google and redesigned Google Analytics to make it sort of, kind of maintain all the power that it had, but make it much more accessible to a broader audience. So that’s really what we spent our time doing at Google.

Paul: OK, so we saw Google Analytics and those changes that you made to Google Analytics appear a few months back, and you know, were very impressive. But I’m quite interested in what happened. How did that come about, and how did that process work? So you arrive at Google, you walk through the door of Google. Now, one presumes that there was an existing Analytics team already working. Is that right?

Jeff: Yeah, that’s right. There was probably about twenty developers or so that were working on the Analytics application. Almost entirely all, sort of back-end engineers. As you can imagine, something of that size and scope, it’s a pretty impressive technical feat. The amount of data that they’re tracking every day, really just continues to blow my mind how much scale they have over there. So there was really, really talented engineers that had been working with the product for quite some time. That product had been around for a number of years. I think they were in version six of the product. But, to their credit, the Director of Engineering, a guy named Paul Moret, really knew that he had to change that application for this new audience that he had, sort of had started to grow by being at Google. So he was really behind the idea of completely rethinking. “Like lets,” he said, “Let’s start from scratch. Right, we have a lot of users. We have a really powerful product that I want to completely rethink how this happens.” And so, yeah, we really just rolled up our sleeves and sat down with him and his team and really sort of became one team. Got in there and made a lot of change. One of the things I think that really helped us be successful there was that we had a pretty robust methodology for user research that really resonated with a lot of the engineers that we were working with. It was really sort of. It was like I said, pretty mature, had a lot of data behind it so we could really show a lot of the work and helped us really get over a lot of the perceived subjectivity of design. So, you know, you can imagine this team comes in. We are a bunch of relatively technical designers, but still designers. And we sit down with these very, very technical engineers and we kind of showed them a process of how we were going to talk to a lot of the existing audience, a lot of the new segments of the audience, take everything that they told us and kind of boil it down into a lot of actionable next steps. And a way of prioritizing what features and changes we wanted to make. And so rather than us kind of going off, doing a bunch of design work and presenting it to them, we really involved everybody, or as many people as we could, in the process of how to change that application at its very basic level. So I think the results of doing all of that with the technical team was that we built a lot of trust between us. So that we could take some of their fundamental assumptions and really question those, but include them in that process so that there was a lot of give and take.

Paul: I mean yeah, because your initial reaction when you look at a company like Google, that it is a very developer-centric company. So I was kind of half-expecting you to say that you encountered quite a lot of resistance to the kind of design changes that you were introducing, but from the sounds of it, because your methodology is quite scientific, for want of a better word, you know it’s very logical, etcetera that it sounds like it went down quite well.

Jeff: Yeah, it did. It feels like we’re using the scientific method: doing testing and research and analysis and things like that. Ultimately though, so much of design is really, really hard to measure. Especially when it comes to matters of taste and perception and things like that. I mean, we can measure click-throughs and we can measure conversion rates and things like that, but ultimately the changes had to come from just being good designers. So having this relatively, kind of quantitative analysis that we did just allowed us to sort of speak on the same terms with the engineers. Have them trust us, and then let us make the changes we felt in our gut we should be making. So a lot of times I’ll be working with somebody who is very technical and they want to say, “Well if you make that change, can you show us some data that’ll prove that that’s the right change to make?” And almost never can I do that. Right, like we can do little tests and we can do some A/B testing and multivariate testing and stuff like that. And that’s good for little incremental changes but when you’re fundamentally changing an application it’s almost impossible to measure the accuracy of the decisions that you’re making. And that can be hard for somebody who really is a very analytical thinker, very quantitative in the decisions that they make, to sometimes kind of let go and say “No. You’ve go
t to trust us. It’s just going to be better.”

Paul: So were there other techniques that you used beyond providing data to kind of bridge that gap between the way that maybe designers see the world and that of developers?

Jeff: Well I’ll tell you another thing that I really believe in, is prototyping rather than just drawing mockups. One of the benefits I had going into Google is that I had a remarkable team at Measure Map that were quite technical. A very good front-end developer who could do lots of JavaScript, AJAX, CSS markup kind of work. A talented Ruby developer, and then a guy who was great with Flash and ActionScript. So bringing this team together, all of them good designers, but all of them with very technical backgrounds, we could come in and very quickly start to realize what a redesign might look like. Also the thing that really helped us was that Analytics internally had a very well-developed API. So we could say “All right, show us how this API works, then we’re going to immediately start experimenting on top of it using real data. We can bring users in for usability tests and they can see their data in our prototype in a matter of weeks, rather than months and months of development.” So having that separation between design, front-end and back-end, through a robust API allowed us to prototype so quickly that they could immediately say, “Wow! Look at all the work this team is doing!” Rather than us standing in front of the projector pointing at Photoshop comps or something and saying “Imagine what it would be like to click here.” We just had a thing working that people could log into anytime.

Paul: Yeah, I can really understand how that would make an enormous difference. So I’m presuming that you talk about your little team of people that went in there and started doing prototyping and stuff like that, but obviously you’re going to want to engage more with the developers that are there. I mean, the traditional danger has always been that as a developer and a designer you work independently. The designer does his thing. He hands it over the partition to the developer. The developer goes away and does his thing. Now I presume you wanted to avoid that. So how did you establish that working relationship? How did you end up working closely together?

Jeff: I have almost no interest in that sort of “waterfall method” where somebody goes off and does research, hands it off to designers, designers then do some of their magic, hand it off to developers. I’ve never been successful at doing that, primarily I think because I learn so much from the process of building things. So again, it was just, really one of the first things we did was invest a lot in getting the teams to trust one another. And that meant really just spending time with each other. So that meant almost every day just scheduling some time in the conference room for us all to kick around ideas, to look at some of the existing work that they were doing, some of their future plans and just spending a tremendous amount of time with them. We also just had our desks right next to the development team. We were embedded, we were just right there. So we felt like part of the team. We’d all go eat lunch together. I mean simple things like that just make the development process so much more, so much easier because there’s real people working with each other rather than faceless “other people” handing specs over. So putting a lot of time in: absolutely crucial to success in a process like that.

Paul: So obviously you got to work with a great group of people over at Google. Some of the most talented developers in the world I guess. So I’m really interested to know, what was it you learned from them? You spent all this time with them, what was the kind of thing that you took away as a front-end interface designer what did you learn from this amazing group of developers?

Jeff: Well, a couple of things really. I think the thing that struck us the most when we first got there was just the enormous scale of everything. Like Google, as you can imagine, Google has lots and lots of users, but they have a tremendous diversity of users too, literally from around the world. A statistic that we throw out all the time is that seventy percent of Google’s traffic comes from outside the United States. So the audience that we were used to designing for is really the small minority of people, and in fact the rest of the world is where all of the products are being used. So we had to think about that diversity of audience even in the design decisions that we were making every day in that everything that we were designing was going to be translated in up to forty different languages. So that was probably the first thing that really brought our attention. The second thing was the unbelievably high standards that Google had for their products. Like you said, I totally agree, they’re some of the best engineers in the world. They have coding standards. They have testing standards, QA standards that were absolutely remarkable. I just learned so much about how every little detail fits into place to make a product that’s as robust and as really scalable and useable by a global audience that Google has. It was really like I got a crash course in some of the best computer science education I could possibly ever ask for.

Paul: Very cool indeed. So for the designers that are listening to this now, the front-end people that maybe are working with developers day in and day out and secretly behind their backs are having a bit of moan about those developers, they’re finding them quite tricky to work with, what advice would you give them about interacting and working with developers?

Jeff: Well, like I said, you’ve got to spend time in the trenches with them. That I think is just the most obvious thing that I can recommend doing. For both sides. It was hard for me to trust a lot of developers, like “Oh, you’re only concerned about your servers, you don’t care about users at all.” Which of course is completely false, but that’s an inherent bias that I would have. So again, spending that time: incredibly important. I think one of the things that I try to educate the most while I was there was that the level of detail, the care, everything that goes into the coding standards that engineers have, we have that same standard for the interfaces that we build. So I think sometimes, and I hate to generalize across developers, because I’ve worked just the entire spectrum of developers. One of the themes that I hear from time to time is that design is something that kind of happens at the end. Like “We do all the hard engineering. We get all of these systems in place and write all of this code and then we need some designers to come on and put the interface on so that we can actually launch this thing.” That I think cheapens a lot of the work that we do, and it’s a little bit demeaning for the discipline of design, of user experience. So I think we have biases on both sides and that frankly understanding more about what goes into the process both from a front-end and a back-
end point of view is kind of what brings us all together.

Paul: So if you could communicate one thing to the developers, one lesson, the question the other way around I guess. I guess in some ways it’s the same answer, isn’t it? It’s kind of stick with one another.

Jeff: Yeah, a little bit. Also there’s some really simple techniques that I’ve used, for example: even before we started we’d schedule a usability test with the existing product and get the engineers into the room behind that one way mirror and we would just watch. And we would watch people flail around with the interface and struggle and get frustrated and push the keyboard away. I mean that’s just golden. People see that and they’re just like, “Oh man, we’ve got some work to do.” So making it as clear as possible, what our users are trying to do, how we can all collaborate together to help them: incredibly, incredibly important. That said, it wasn’t, you know when I did consulting at Adaptive Path I was inside lots of companies. I worked with some of the biggest companies in America and saw inside of them and, to be honest, Google is truly a user-centered company. I was just so impressed with that. Broadening that idea of user-centered technology development is something that we worked on. Making it more of a balance between front-end and back-end is more some of the things we worked on. But ultimately I think Google really understands that putting users first is the way to be successful. Just look at the search results page with it’s very simple but incredibly effective advertising techniques, and you know, Google never had a front page that was full of the sort of portal design stuff that Yahoo! and other companies have done. So really, it was very fertile ground for the kind of work we wanted to do when we got there.

Paul: Very interesting. I’ve just thought of one other question that I get asked a lot from people looking to get into web design: they say, “So what am I better off doing, you know, where’s the best place to work? Is it in the large company? Or is it doing something in a small company by yourself?” Now you’ve obviously done both of those and there is no definitive answer, but what would you see as the pros and cons of a large company in comparison to working somewhere smaller like Adaptive Path?

Jeff: You’re right, in my career I’ve got swung back and forth between big and small. There are definitely benefits and drawbacks to both of them. In the bigger companies I think just inherently things move slower. Now, I mean Google is renowned for it’s “bottom-up culture” and good ideas are always emerging from people taking their twenty percent time. None of that is a myth. That all really happens. But at the same time, like I said, when millions of users, or hundreds of millions for some of the products. You just have to take a lot more steps, and what that does is it increases the distance between the idea that a designer or developer has, and a user actually seeing that idea. And one of the things that I love about this sort of entrepreneurial startup environment is that you can think of something, you can try it out, you can get it in front of your users. You can do that in an afternoon. And you can’t do that with a product like Gmail or Adwords or something like that because there’s so much inherent infrastructure and risk, things like that. I think it’s incredibly worthwhile for people to have both experiences, and frankly see what they like best. One of the things I really have learned in my career is that there are people that like to start things, and that there are people that like to run things. And there is no inherent judgment between the two, but once you understand “Ooh, I love having a big system and having that system run perfectly, and putting all the things in place to keep that, you know.” And that’s fantastic. I’ve learned, in my career, that I’m kind of on the other side. I love starting with nothing and building up something, and at some point I need to hand it off to somebody who is much better at running and maintaining, right. So those are the kind of things you learn by doing a lot of very different projects and product development and stuff like that as your career kind of goes on, I think.

Paul: So you’ve left Google now? So what’s the next step? What are you up to at the moment? Let’s finish on a looking forward note. Where are you going? What are you doing?

Jeff: I was at Google for just over two years and left about six weeks ago, and to be honest I’m spending a lot of time right now cycling and trying to sleep late, and things like that. I tell you it’s a tremendous luxury and I’m not taking it for granted at all. The immediate next thing is that I’m organizing a little conference with my colleague Bryan Mason, who I have worked with at Adaptive Path. He and I are doing a conference in San Francisco in August about starting companies. Yeah, as I was leaving Google I was thinking, “Well, what should I do next? What would be interesting?” So I talked to a bunch of my friends who have been entrepreneurs, or who are now investors and I just asked them, “Tell me your story. How did you get to where you are?” And I found those stories so interesting that I thought, “Man, we’ve got to share this. This is great.” And I thought, “Well, I could do a podcast or something like that.” But then I thought, “I love getting people together and having sort of a community feel.” So we thought: we’ll get one day, San Francisco in August. We’ll get everybody together and we’ll just have these conversations. So I’m really looking forward to it. It’s called “The Start Conference” and you can find it at thestartconference.com. That’s what we’re doing now.

Paul: Excellent stuff. Thank you so much Jeffrey for coming onto the show and talking about that. The issue of designers and developers working together is something that’s really important and I think there’s a lot of work still to be done, and it’s good to see that there are people out there that have got it right and are going in the right direction.

Jeff: I appreciate that Paul.

Paul: Thanks for your time.

Jeff: Thank you.

Thanks to Todd Dietrich for transcribing this interview.

Back to top

Listeners feedback:

Adding a jingle to your site

Chris writes: A client of mine wants to incorporate 4 second jingles at various points on their website, triggered on page load, to reinforce their servicing brand. My first reaction is that this could get annoying but was curious as to your thoughts on the use of audio on the web.

I don’t think that there is any set ‘rule’ here but basically I would agree 100% that you shouldn’t do it because it will annoy the hell out of the site’s users.

There is an argument that audio branding can be included if th
e user only has to hear it once. However, I would dispute this as well for the following reasons:

  • It may well still annoy (and therefore have a negative effect upon) the site’s users
  • Users aren’t expecting it and it could embarrass them in an office environment
  • Quite a lot of users will have the sound off. Therefore, if you decide that the audio is only an ‘add on’ for the brand then you may as well conclude that it’s not necessary at all.

I have talked about audio on website before and reached the conclusion that, even though technology and bandwidth makes it more doable, it’s the wrong medium for audio. I think I likened it to having a soundtrack while you’re reading a book – it’s just wrong!

Of course, there are no doubt exceptions to this rule – really well thought out and produced audio indicators on a web app for example – but, generally speaking, audio branding on a website will have a negative effect. If your client is insistent, try and persuade him to include a video download on the site where audio will certainly work.

Fixed or bespoke pricing

Jon writes: We are a small web design and development company (4 people) and have tended to concentrate on higher value bespoke work. We are probably about to merge with another slightly larger company in a neighbouring town. This other company have traditionally aimed at a somewhat lower value market.

My question is about pricing. The other company operate to a very structured price list (£x for a 5 page brochure site, £Y for a basic ecommerce site, £Z for an ecommerce site with knobs on etc). We have always priced each project individually using a mixture of time costing, guesswork, and a “how much can we get away with” approach.

Do you think that a merged company approaching a wider market and value range would be better to adopt one approach or the other, or continue to do both? Would the existence of one approach damage the ability to operate effectively at the other end of the scale?

I guess the big question here is – are you going to remain as two different entities with some shared resources, or are you going to merge more fully and share work between the team no matter where it is sourced from (i.e. will one of their designers work on a future project from one of your existing clients)? If it is the former (which I suspect it isn’t) then I would keep the two pricing models the same as they are. I wouldn’t try and hide the fact that the two companies have ‘merged’ though, just explain that there are two teams delivering different services.

However, if the two companies are merging more fully, then I think this is actually fairly fundamental stuff. It’s almost like you’re all starting again and need to write a business plan. I think you would be opening yourself up for much criticism if you tried to operate both pricing plans.

I suppose other questions to you would be:

  • Which pricing plan is most effective (who is making the most profit)?
  • What does each company’s order book look like? I.e. have you just signed a massive contract at your higher rates?

This is interesting stuff and I’d like to know how it works out. I suppose the biggest unknown for me (that may well answer all of my other questions) is that I don’t know the reason for the merger in the first place.

Back to top

118. Geo

Posted in Classic shows on May 20, 2008 by Paul Boag

On this weeks show we look at geocoding, Tom Coates talks about Fire Eagle and find out how we achieved the tabbed menu effect on the Headscape website.

Download this show.

Launch our podcast player

News and events

New tools for web designers on the way

A few months ago the guys over at clear:left put up a holding page for an application called Silverback. Exactly what Silverback was became a topic of much discussion and a considerable amount of buzz.

This week Andy Budd has finally revealed exactly what Silverback is on his blog. He describes as…

An OSX application to help people run their own low-cost Guerrilla usability tests. It captures screen activity, records audio and video from your built in iSight, and then composites it into a handy Quicktime movie for later use.

I have been fortunate enough to play with an early beta and I have to say it’s a great idea. It has the edge on other "screen capture” programs because it is designed specifically with usability testing in mind. For example, you don’t need to export the movies as soon as they are recorded. You can save them until you have finished a day of testing when more time is available.

If you ever do user testing get yourself over to the Silverback site and signup for the beta.

It would of course be remiss of me not to mention GetSignOff.com as we are on the subject of tools for web designers. Like clear:left Headscape have been developing an application and this week we provided our first walkthrough showing exactly what it does.

In essence GetSignOff is a web application that allows you to present designs to clients in a more professional manner, manage the feedback you receive from them and organise the multiple iterations of each design.

To really get a sense of what it does you need to view the screencast so be sure to check it out.

Effective online delivery of video

There can be no doubt in anybodies mind that online video is huge. It has taken a long time to arrive but with broadband so widespread it is now a reality. Increasingly users are expecting video content from websites and it is up to us as web designers and owners to deliver.

Delivery is fairly straightforward when you can use sites like YouTube or Vimeo. However, that is not always possible. Constraints on size and quality can make these services unsuitable. Not to mention their over demanding terms of use. So what do you do if you are forced to host and deliver video yourself?

My advise is to read an excellent article on the Digital Web Magazine that looks at the various approaches for delivering video over the internet. It explains concepts like progressive download, RTMP streaming and HTTP streaming. It is a superb source of information for anybody who has to host and deliver their own video content.

Some Javascript slight of hand

Our next story is some slight of hand by Robert Nyman.

I find myself increasingly using Javascript to show and hide content. However, being a well behaved standards designer I have to be careful how I build pages. I avoid hiding content with CSS because if I do and Javascript is disabled, users have no way to show the content again. Instead I use Javascript to hide the content so that if it is disabled the hidden elements will show by default.

The downside is that you can get flashes of content because Javascript has to wait for the page to fully load before it can hide content.

Fortunately Robert has come up with a nifty little workaround where he uses Javascript to load a CSS file, which in turn hides the content. This happens before the body has been loaded avoiding the flash of content.

If like me you occasionally suffer from content appearing when it should not, then bookmark this approach for later use.

Overcoming creative block

Our final news story today is a post on overcoming creative block. Creative block is something we all suffer from whether our job is perceived as being a creative one or not. Every job requires some degree of creativity and we all know what it feels like to stare blankly at a computer monitor unsure of where to begin.

This post provides a list of excellent tips on how to overcome brain freeze from going for a walk to throwing away the piece you like most. It really is a superb read. Another one to bookmark for the next time your creative juices fail to flow.

Surprisingly he has missed my number one technique, sitting on the toilet… or is that just me?

Back to top

Feature: Location Aware

The web is full of exciting innovations at the moment. However, it is geocoding that personally excites me the most. In this weeks feature I explain what it is and why I believe it offers so much potential.

Back to top

Interview: Tom Coates on Fire Eagle

Paul: Ok, so joining me today is Tom Coates from Yahoo. Good to have you hear Tom

Tom: Nice to be here

Paul: So I’ve just been hearing from Tom that he’s got a massive line up of interviews to do for a product that he’s been involved with called Fire Eagle. So he’s talking to the Guardian, the BBC and lots of important people, but thank you for sparing a few minutes to talk to us too. We’re very honoured.

Tom: No problem at all.

Paul: So, lets kick off for those who haven’t come across Fire Eagle before. I think you talked about it at dConstruct last year.

Tom: Yes

Paul: That was when I first heard about it, perhaps you could tell our listeners a little bit more about what it is, and what it does.

Tom: So Fire Eagle is a service that helps you share information about your location, online. So that’s both for people, and more importantly for different sites and services. The other side of it is that it sort of fixes a problem with the development community for the use of applications that use your location. In that it makes that process much easier. So in principal, it means that from a user’s perspective, you can capture information about your location and use it in lots of different places. And from a website owners perspective you can start to think about how your service can respond to someone in the world without having to do a lot of donkey work.

Paul: So it’s not primarily, in itself, like another web application like Twitter where you’ve got to sign up for and take part in it? I
t’s more of a API framework type of thing.

Tom: Well, when you think about it, it is both, because if you think about it as a place to sort of store information about your location. We give you the tools to go in and update that information, decide who to share it with, and manage that information. So in some ways it’s like your location preference page, which helps you control that information. So yes you do sign up for it, it uses a Yahoo ID, the same one you use for Upcoming and Flickr, but really, once you’ve started capturing your location or sharing it with particular services, you don’t really need to come back. We’re not trying to build a sexy fun service for day-to-day use, but we’re trying to make something that makes it easier for you to build, and other people to use, services.

Paul: OK, so how exactly does the service work Tom. I’ve seen other location based stuff where you have to do horrible things like enter grid references or terrible stuff like that. How do you use Fire Eagle?

Tom: What you do with the site, is you go to the site, and you log in with your Yahoo Id and you do a simple terms of service thing, which asks how often you want to be reminded that you’re sharing your location. From that moment on you’re up and running. The simplest thing to do, is go to a web page called where am I, and you can type in your address and, we will work out where you are in the world, and we’ll plonk it on a map. Now that in itself isn’t terribly interesting. So the interesting thing about it, is that we’ve opened up the API’s so that anyone in the world can build something that could update your location, and anyone in the world could build something that could use your location. So we have an application gallery, and you could go along to that, and on that at the moment there are services like Navizon, which work out where your location is by nearby wifi signals. Or Loki which is from SkyHook the same people who power the iPhone location thing, and Dopler and all kinds of stuff. You can tell those services that you’re OK sharing that information with Fire Eagle. So I have an application on my phone at the moment from Navizon that works out where I am every 10 minutes and tells Fire Eagle where I am. So that location just sits in Fire Eagle and then I can decide to share it with people. So as an example a plug-in for movable type that Ben Trott has built and that means that you can put on your blog, a little map of where you are right now which is quite fun. What we do is, to help maintain your privacy, you choose which services you’re comfortable with sharing your location with, or get an update from. You can say to what level of granualarity you’re comfortable sharing with it. So you can say, just share my city, or my state (if you’re in America) or your neighborhood or your exact point. Then you can hide information at any time, or delete all information in the system.

Paul: Oh, OK.

Tom: So basically it means that you would go and find one really good way to get where you are, or lots of little ones all around the place that compliment each other, and sort it out into the middle of this little repository of data, that you can then say, yes I’d like to use this on Flickr, or on Facebook, or on moveable type, or wherever.

Paul: So the way you’re describing it is that there are multiple entry points into it, where you type in your exact location, weather it’s your mobile phone updating it?

Tom: Yes

Paul: You know I even noticed from looking at the site that you can now Twitter your location in.

Tom: Yes

Paul: And that there are multiple output points, where it’s going to Movable Type, or to wherever else.

Tom: Yes

Paul: So what type of things are we going to see with this. What are you expecting people to develop? Is there any cool stuff at the moment that you can tell us about?

Tom: Yeah, well there are a fair number of cool things that have already come out, which is kind of interesting. I mean one of the things on the engineering side – so there is a bit of a problem with location based services, and everyone’s been talking about it for a very long time, you know they have all these kinds of things that you couldn’t find friends more easily, or find out things about your neighbourhood or whatever. And the problem is, and has always been, that it’s quite hard because what you have to do is, every time you want to use an application like that, you have to install another application on your phone, or go through another extended rigmarole about how to do it. So our plan is that we take that away, so what you basically do is you find any piece of software that gets your location usefully, and you install it, and it updates Fire Eagle. So from that moment on any application in the world that is Fire Eagle enabled can go and get that. So any website in the world could respond to where you are, without ever having to build the thing that works out where you are. So some examples – Navizon as I said is this lovely little application that runs on most mobile phones, captures your location. There is a thing called Fire Bot, which is a Twitter Bot, and on that one you can do a Twitter direct message, with a text string of where you are. So you can say I’m in San Francisco, or I’m in London, or I’m in.. as I am now, at Yahoo’s offices at 125 Shaftesbury Avenue. And you can type that in and you can then share that with all the applications you’re comfortable with. We’ve also taken Cell ID information, so if you have a mobile phone, many of those on a technological side expose the Cell ID. So that’s the tower, or mobile phone mast kind of thing. Quite a lot of people are doing interesting mappings based on that. That in particular is at a very early stage so we don’t actually get much good information from that, but, you know we do take in all different types of data. You could have a GPS log coming from a mobile phone, or anything that could get long/lat coordinates, or anything that could get text string of the place you’re in. On the other side, is the things that could use it, which is where the fun starts. There are all kinds of things that people have built. And more coming. So there is a service that Leonard Lin, the founder of Upcoming made for us, called FireBall, and FireBall was particularly useful in San Francisco in the last couple of weeks because of the Web 2.0 Expo that was out there.

Paul: Oh yeah.

Tom: And the idea with that was you could either send a Twitter message of where your location was, or if you were getting it from FireEagle, it would automatically use that. And at any point you could say "Where are my friends” and it would go to Twitter, find out all your Twitter friends and plonk them on
a map for you. And you could do that on the iPhone as well because it would send you a file that could then be opened by the Google maps thing. So you could literally call your little maps thing on the iPhone and it would say "Here’s where all your friends are”, which is really lovely, and really nice, because it’s all about your friends there.

We’re building a Facebook App, this is no particular secret, we’ve talked about this before, and its going to be one that means you can decide to share your location on Facebook with your friends, which is going to be quite fun. A guy called Simon Willison who I used to work with, who has built a thing called WikiNear. There are over a million geo-coded articles in Wikipedia, which basically means someone has put in the longitude and latitude of where the thing talked about in the article is. So Simon’s thing is a little web page for your mobile phone, and you bring it up and it says "Here are the 5 nearest interesting things to you”.

Paul: Cool!

Tom: Which is pretty fun, so you can wander around London and here’s the British Museum and you can click on that to go to the media wiki page to talk about that.

Um, there are other things like that, I mean LightPole is a little company that we’ve been working with. They’re doing things like local services around you, which again is mobile phone focused. A company called Outside.In, they do things like try to work out where all the blog posts and news stories are about, and they can bring that information to you if they know where you are – and they are going to get some of that information from FireEagle – which is really cool. So as I said we’ve got this Moveable Type thing. So there are all kinds of stuff that is going on at the moment. We build these wonderful little widgets, which I really like, they are for OS 10, and one of them is a little updater. You can type in your location, press a little button and it will update it to FireEagle. One of them tells you the weather where you are right now. So if you travel a lot, it will give you the weather forecast of where you are. And one of them shows you nearby flickr photos, so it just goes and gets those geocoded photos from Flickr and gives you every day a little photo montage of all the cool things that are going on around you. So lots of interesting new uses really.

Paul: It’s interesting you mentioned Flickr. I mean you can imagine the reverse of what you just described with Flickr, so if your location is been taken each time, it would know the location where you took that picture and geo-code that picture on Flickr. Is that the kind of thing that you’re planning to do?

Tom: I mean there are a lot of really interesting uses based around geo tagging. So whenever I write a blog post, it would be really awesome if my Moveable Type blogger could go and look up on FireEagle where I was, and say "This article was entered here”. So you could say "What do you think about Gordon Brown in Edinburgh” as apposed to "What do you think about Gordon Brown in London” or "Wales”, and that would be really fun as a good way of slicing through this enormous amount of blog posts that are out there.

Twitter messages as well, that would be lovely – it would be really great if every time you wrote a Twitter message they went and grabbed your location, and you could say, well I want to explore the public conversations going on in my neighborhood right now. That would be lovely. Um, and with Flickr as well, when you click on a photo on your phone, uploading it immediately. If you havn’t got the location on that device, being able to get it from FireEagle would be really useful. And you know obviously whatever amount of information they can get, so perhaps FireEagle only knows you’re in London, that’s still useful – you know you can still help people find photos just because they are in London. Or if they are at an exact point that’s also good. The only thing about Flickr is that often people take photos and upload them later. And at the moment because we want to make sure that we’ve thought about all the implications, and we don’t want to weird any one out, we’re making sure that we don’t keep any ones history.

Paul: Oh Ok

Tom: So it’s literally just your current location we look after for you.

Paul: Ah, that’s good.

Tom: Yeah we’ve talked to a lot of people about this, and we have been very careful about the privacy and control. These are the two watch words of the project. We are incredibly conservative, we don’t want to worry’s any one out. So at any time you can press a button to hide your information. Information will still come into FireEagle, but it won’t go out. Or you can delete all your information on FireEagle at one time, so we won’t keep any records at all if you do that. At the moment we don’t keep any location history at all – any tracking, or location history there. And we even by default will send you an email once a month saying "Are you still OK sharing”, and if you don’t reply to the email, or you don’t click on the link in the email, then we’ll stop immediately. It’s just so there is no risk of you doing anything, you know, accidently, exposing it in ways you’re not comfortable with.

Paul: I mean when I first heard you talk about this it struck me as hugely exciting, that location based information is an area that I’m massively excited about. And I think there is so much potential to add a new level of context, you know, on the data that we see on the web. Something that has been very much lacking since the beginning. And there is so much potential here, for pretty much anyone listening to this show, whether you’re a design or a web site owner.

Tom: Yeah

Paul: So where would people start to find out more information about this. Where’s the good place to begin?

Tom: OK, so one of the parts of the project that took surprisingly the most time, was actually making sure that the documentation was really good. At the moment it’s an invitation only service, so we have a few thousand people using it and testing it at the moment. We’re opening it up to more invitations pretty regularly. It’s only been out in the wild about 6 weeks. So if you’re interested in using FireEagle, just go to the website, put your email address in the box, and over the next few weeks we’ll be sending out more invitations.

Paul: And what’s the website address?

Tom: Oh, it’s FireEagle.com

Paul: OK

Tom: So that should be nice and easy to find. On that site, if you can get an invitation, and if anyone spots us around the
place, ask us, because we have little cards we can give out. There is extensive documentation on how it works, that really falls into two big chunks. Partly it’s this use of this new standard called OAuth. Which is a really good way, meaning sites can talk to each other on behalf of users, and you can set your preferences around that. So getting your head around OAuth is really useful because so many services – I think Google and Yahoo have both announced that there is going to be support for OAuth as a standard now. So that’s really great, we’re all really happy about that. And the other side, is the FireEagle APIs themselves, which are very simple, sort of three main ones. 1. Where is the user. Again, all of this only happens if the user has given explicit permission for this service to see it.

Paul: Sure

Tom: One is update the location of the user, and one is ambiguous query, so such as, you say you’re in London, which is great, but there are hundreds of London’s in the world. So there is one service where it says "which London” and you can say "this one”. So they are the three core queries , it is very very simple. We have another couple of ones, for particular web services, to bring back users of my application within that particular area, like SOHO or London.

Paul: Yep

Tom: Another one, bring back the hundred who have updated their location most recently. So just think, just to make it easier for developers to build useful services.

Paul: Cool, that just sounds really exciting, and I can’t wait to see some of the stuff that is developed in the future. Tom, thanks so much for coming on the show.

Tom: No problem, I hope that was useful

Paul: That was incredibly useful, and I’m sure there will be a lot of people hounding you for invites, well there probably already are thousands of people hounding you for invites. Have you got any idea when it’s going to go "Full Open”?

Tom: Yes, I do have an idea when it’s going to go full open.

Paul: But you’re not going to tell me.

Tom: Well its within the next couple of months. We want to make sure we’ve had conversations with some really interesting people, so that we have some really cool stuff to show off at the same time. So you’ll just have to wait and see on that line I’m afraid.

Paul: Oh, so that’s really exciting and thank you again for coming on the show.

Tom: No problems. Cool.

Thanks to Nathan O’Hanlon for transcribing this interview.

Back to top

Give Away: Fire Eagle Invites

So as we mentioned in the interview, Fire Eagle is currently in beta, but if you can’t wait for the full release and want to get playing with it right away your in luck. We have around 20 invites available for boagworld listeners. To claim one, e-mail [email protected] with the subject heading of "Fire Eagle Invite" and Ryan will send you your code, while stocks last…

All tickets have now been claimed!

Back to top

Listeners feedback:

Tabbed menus?

David Bridle writes: How did you get the tabbed menu to work in the headscape website?

When writing the answer to this question, it turning into quite a lengthy explanation. So I wrote a blog dedicated to it, which can be found here.

Back to top

About this site

Photo of Paul Boag

Hi, I am Paul Boag. I am a co-founder of web design agency Headscape and host of the boagworld podcast.

If you are looking for advice on designing, developing or running your website then you are in the right place.

I recommend starting with:

  • A guide for those new to the site.
  • Searching for a specific topic.
  • Following me on twitter.
  • Subscribing to updates from me.
  • Reading more about me!
  • Subscribe to Boagworld
  • Learn about Headscape
  • Hire me

I am not the only person at Headscape sharing great advice. Make sure you check out these guys too!

Others worth following

  • Chris Sanderson (Designer) Chris Sanderson (Designer)
  • Craig Rowe (Developer) Craig Rowe (Developer)
  • Dan Sheerman (Front End Dev) Dan Sheerman (Front End Dev)
  • Ed Merritt (Designer) Ed Merritt (Designer)
  • Leigh Howells (UX Consultant) Leigh Howells (UX Consultant)
  • Marcus Lillington (UX Consultant) Marcus Lillington (UX Consultant)
  • Rob Borley (Future Tech Guy) Rob Borley (Future Tech Guy)
or contact me