Facebook is all the craze on the Internet but also for developers, at Lemon we get asked about our Facebookabilities on a weekly basis!

We have finally popped our cherry and developed several applications using both Face Book Markup Languages and Iframe techniques and found it interesting to say the least.

It was pretty easy to get started as I am already on Facebook, I just had to add the developer application and read the start up documentation, its easy to read and full of good tips, I literally created my set-up in 5 minutes downloaded Visual Studio elements and got started.

We eventually found out that both can be good depending on the type of app you build:

- FBML gets the Facebook look and feel right, it has great custom controls, makes it more intuitive for Facebook users and pages load faster as one does not need to constantly call the Facebook API.

However, as Facebook act as a proxy it only allows for 12 seconds timeouts, the user of cookies is restricted and JavaScript very difficult to use and debugging is tough.

- Using an Iframe gives you more control over development: cookies, JavaScript, debugging but limits your Iframes in dimensions and does not allow you to use the built in Facebook controls and generally affects the look and feel of your app.

We will be releasing our own ‘fun’ Lemon application very soon and keep you posted.

Martin, Senior Web Developer

• Increased loyalty
• Increased page views
• Increased frequency of visits
• Increased session time
• Increased word of mouth

• Many people use less popular browsers – Internet Explorer may be the dominant browser, but other browsers are used by the visually impaired and other internet users.
• Increased traffic from search engines – techniques used to make sites more accessible, such as clearer navigation and text alternatives for images can have the added benefit in helping your SEO.
• Legal requirements – The UK and many other countries have legal requirements to make websites accessible. Providing accessible websites is a requirement of the Disability and Discrimination Act, required by law from 2002. In the 2002 code of practice there is a legal requirement for websites to be accessible. This is particularly important for sites which provide a service, such as travel or financial websites.
  

Imagine walking through the halls of a museum, not understanding hieroglyphics, any of the Persian languages, Aramaic, or even perhaps some of the Cyrillic languages. If you only knew how to speak English, the meaning of any of the above texts would be lost on you. Similarly, when it comes to delivering web projects, most of the things web professionals do is a foreign language to the average business person – where the average business person understands English (or for the purposes of this blog post, the language of their occupation).

However, when you walk into the ancient Roman or Greek halls of the museum, you’re struck by the visual cues that the ancients used to communicate. Yes, they did have their own language, but the frieze on the wall conveys the victory of the battle scene as clearly as the text beneath it.

Likewise, when it comes to delivering for the web, wireframes are the visual equivalent of the frieze on the wall. With wireframes, you get to create something that everyone can take visual cues from – so the structure and positioning of elements in a page are things that can be moved around and changed, instead of re-worded and abbreviated.  From a business perspective, it’s cheaper to get the visual process started with wireframes, than hiring a designer to create true design routes, too.

The big problem with most things technology is that in order to tie people into specific deliverables and timescales, suppliers are made to agree to and sign on specification documents that are generally long winded and overly complex. The problem itself stems from the different ways people interpret written text and descriptions – everyone draws their own conclusions and makes their own assumptions.

So, one of the ways you can get around this problem is to get into the joy of wireframing. There’s a simple satisfaction from delivering a set of wireframes to a client, and seeing them smile because they’re able to visually interpret things the same way you envisaged they would – there’s a congruency that you don’t often find in spec documents.

One of the tools we use, Axure (http://www.axure.com/), enables us to do exactly this. Because it generates an online prototype (which allows users to navigate between pages) that can be interacted with, and is so quick and easy to use, they get to interact with their project right from the beginning. As a result, feedback is immediate, and thus changes almost as immediate, which means that there is real, rapid iteration – mush more so than trying to get everyone to agree on a document. We’ve found that this is so useful that all of our medium to large sized projects have a wireframing / prototyping phase.

I’m not suggesting that you should get rid of the specification documents, as they have their place and serve their purpose, but I am suggesting that adding a wireframe process to any web project should be as natural as talking about the design - even more so since they both work hand in hand.

So, the next time you’re doing a web project, and you’re handed a 123 page spec document, and there’s no wireframes inside, you need to ask yourself if your interpretation of someone else’s specification writing is going to match up to your own expectations. Further to that, will the designer be thinking the same thing too?

With the rise and rise of Firefox as the industries darling web browser, Microsoft has been hard at work on their latest release of Internet Explorer, IE7, aimed at maintaining the MSFT consumer browser dominance.  The recent release of the latest version of Firefox (version 2 – called FF2) might even get you thinking that there was a race on, so we’ve written this to give you some more info and analyse what it means for you.

So what does it mean for the average user of the interweb?
If you’re a typical web user then for the most part you probably won’t notice much at all, but there is a chance that your own site might not look the same as it did in previous versions of IE.  This is primarily because Microsoft has worked hard to fix bugs in IE6, which web developers had in turn created hacks for to make things work across browsers, so those self same hacks that are meant for good might actually do more harm than good.  If you’re using IE7 that is. 

Of course, beyond the basics this might be important to you so we’re going to go through this in a bit more detail:
There are some positives
IE7 is more compliant with current web standards.
IE7 has fixed many CSS issues that were troublesome and required hacks.

And a few negatives
Sites that rely on CSS for presentational positioning may cause issues, with many websites looking broken as a result of the new IE7 compliance.
All hacks used by developers to fix IE6 bugs will cause issues for IE7.
IE7 may still be slower then FF2 in some instances.
 
As usual, Zeldman has something to say that might also be worth reading if you’re more interested in the technical bits and bobs.

The take home is that most people have Windows Update set to update automagically, which should update their browser version to IE7, which means that if you’re worried about your site looking a little wonky for those users, and your target market is indeed largely made up of IE users, then it’s definitely worth doing something about.

Simply updating to IE7 and checking your website for problems yourself is an obvious thing to do, but if you’re not up for that then contacting your web agency about potential problems your website might have is the next best idea.  If you’re a large corporate and you’re serving web pages to lots of people, then it’s probably better to do it sooner rather than later!!