Entries from September 2009 ↓

Facebook Connect launched to the public less than a year ago, and already it’s seen an incredible amount of traction. Unfortunately, for those people with little to no coding experience, implementing Facebook Connect has seemed like more trouble that it was worth. Today, Facebook has an answer: Facebook Connect Wizard and Playground.

Facebook writes that “you can now incorporate Facebook Connect into your site in 3 easy steps.” The process is simple. First, you enter the name of your site and its URL. Then Facebook asks you to download and then upload a special file to your site’s main directory. And.. that’s about it. Once you’ve done that, Facebook will present you with its Playground — a list of code snippets you can embed on your site to round out the functionality, including Login buttons, profile photos, publishing items to News Feeds, and rendering photos of a user’s friends.

Deciding to put their little wizard to the test, I tried to implement Connect on one of my personal sites (note that I’ve never tried to implement Connect before so I really didn’t know what I was doing). And to my surprise, it worked: I managed to have a very basic form of Connect up and running on my site within all of two minutes. It will obviously take longer to make sure the new icons and buttons play nicely with your site’s design, but it’s really surprisingly easy.

Crunch Network: CrunchBoard because it’s time for you to find a new Job2.0

Who has the time to watch all the viral youtube hits of the last few years?

Well clearly it appears I do after recognising nearly all of the top 100 greatest hits of YouTube cleverly packed into 4 Minutes:

Which one puts the biggest smile on your face?

 Â

Everyone would agree that usability is an important aspect of Web design. Whether you’re working on a portfolio website, online store or Web app, making your pages easy and enjoyable for your visitors to use is key. Many studies have been done over the years on various aspects of Web and interface design, and the findings are valuable in helping us improve our work. Here are 10 useful usability findings and guidelines that may help you improve the user experience on your websites.

1. Form Labels Work Best Above The Field

A study by UX Matters found that the ideal position for labels in forms is above the fields. On many forms, labels are put to the left of the fields, creating a two-column layout; while this looks good, it’s not the easiest layout to use. Why is that? Because forms are generally vertically oriented; i.e. users fill the form from top to bottom. Users scan the form downwards as they go along. And following the label to the field below is easier than finding the field to the right of the label.

Tumblr features a simple and elegant sign-up form that adheres to UX Matter’s recommendation.

Positioning labels on the left also poses another problem: do you left-align or right-align the labels? Left-aligning makes the form scannable but disconnects the labels from the fields, making it difficult to see which label applies to which field. Right-aligning does the reverses: it makes for a good-looking but less scannable form. Labels above fields work best in most circumstances. The study also found that labels should not be bold, although this recommendation is not conclusive.

2. Users Focus On Faces

People instinctively notice other people right away when they come into view. On Web pages, we tend to focus on people’s faces and eyes, which gives marketers a good technique for attracting attention. But our attraction to people’s faces and eyes is only the beginning; it turns out we actually glance in the direction the person in the image is looking in.

Eye-tracking heat map of a baby looking directly at us, from the UsableWorld study.

And now the baby is looking at the content. Notice the increase in people looking at the headline and text.

Here’s an eye-tracking study that demonstrates this. We’re instinctively drawn to faces, but if that face is looking somewhere other than at us, we’ll also look in that direction. Take advantage of this phenomenon by drawing your users’ attention to the most important parts of your page or ad.

3. Quality Of Design Is An Indicator Of Credibility

Various studies have been conducted to find out just what influences people’s perception of a website’s credibility:

• Stanford-Makovsy Web Credibility Study 2002: Investigating What Makes Web Sites Credible Today
• What Makes A Web Site Credible? A Report on a Large Quantitative Study
• The Elements of Computer Credibility
• Elements that Affect Web Credibility: Early Results from a Self-Report Study (Proceedings of ACM CHI 2000 Conference on Human Factors in Computing Systems, v.2, New York: ACM Press)

We don’t know if Fever app is any good, but the sleek user interface and website make a great first impression.

One interesting finding of these studies is that users really do judge a book by its cover… or rather, a website by its design. Elements such as layout, consistency, typography, color and style all affect how users perceive your website and what kind of image you project. Your website should project not only a good image but also the right one for your audience.

Other factors that influence credibility are: the quality of the website’s content, amount of errors, rate of updates, ease of use and trustworthiness of authors.

4. Most Users Do Not Scroll

Jakob Nielsen’s study on how much users scroll (in Prioritizing Web Usability) revealed that only 23% of visitors scroll on their first visit to a website. This means that 77% of visitors won’t scroll; they’ll just view the content above the fold (i.e. the area of the page that is visible on the screen without scrolling down). What’s more, the percentage of users who scroll decreases with subsequent visits, with only 16% scrolling on their second visit. This data highlights just how important it is to place your key content on a prominent position, especially on landing pages.

This doesn’t mean you should cram everything in the upper area of the page, just that you should make the best use of that area. Crowding it with content will just make the content inaccessible; when the user sees too much information, they don’t know where to begin looking.

Basecamp makes great use of space. Above the fold (768 pixels high), it shows a large screenshot, tagline, value proposition, call to action, client list, videos and short feature list with images.

This is most important for the home page, where most new visitors will land. So provide the core essentials there:

1. Name of the website,
2. Value proposition of the website (i.e. what benefit users will get from using it),
3. Navigation for the main sections of the website that are relevant to the user.

However, users’ habits have significantly changed since then. Recent studies prove that users are quite comfortable with scrolling and in some situations they are willing to scroll to the bottom of the page. Many users are more comfortable with scrolling than with a pagination, and for many users the most important information of the page isn’t necessarily placed “above the fold” (which is because of the variety of available display resolutions a quite outdated, deprecated term). So it is a good idea to divide your layout into sections for easy scanning, separating them with a lot of white space.

For further information please take a look at the articles Unfolding the fold (Clicktale), Paging VS Scrolling (Wichita University – SURL), Blasting the Myth of the Fold (Boxes and Arrows). (thanks, Fred Leuck).

5. Blue Is The Best Color For Links

While giving your website a unique design is great, when it comes to usability, doing what everyone else is doing is best. Follow conventions, because when people visit a new website, the first place they look for things are in the places where they found them on most other websites; they tap into their experience to make sense of this new content. This is known as usage patterns. People expect certain things to be the same, such as link colors, the location of the website’s logo, the behavior of tabbed navigation and so on.

Google keeps all links on its websites blue for a reason: the color is familiar to most users, which makes it easy to locate.

What color should your links be? The first consideration is contrast: links have to be dark (or light) enough to contrast with the background color. Secondly, they should stand out from the color of the rest of the text; so, no black links with black text. And finally, research shows (Van Schaik and Ling) that if usability if your priority, sticking to blue for links is best. The browser’s default link color is blue, so people expect it. Choosing a different color is by no means a problem, but it may affect the speed with which users find it.

6. The Ideal Search Box Is 27-Characters Wide

What’s the ideal width of a search box? Is there such a thing? Jakob Nielsen performed a usability study on the length of search queries in website search boxes (Prioritizing Web Usability). It turns out that most of today’s search boxes are too short. The problem with short boxes is that even though you can type out a long query, only a portion of the text will be visible at a time, making it difficult to review or edit what you’ve typed.

The study found that the average search box is 18-characters wide. The data showed that 27% of queries were too long to fit into it. Extending the box to 27 characters would accommodate 90% of queries. Remember, you can set widths using ems, not just pixels and points. One em is the width and height of one “m” character (using whatever font size a website is set to). So, use this measure to scale the width of the text input field to 27-characters wide.

Google’s search box is wide enough to accommodate long sentences.

Apple’s search box is a little too short, cutting off the query, “Microsoft Office 2008.”

In general, search boxes are better too wide than too short, so that users can quickly review, verify and submit the query. This guideline is very simple but unfortunately too often dismissed or ignored. Some padding in the input field can also improve the design and user experience.

7. White Space Improves Comprehension

Most designers know the value of white space, which is the empty space between paragraphs, pictures, buttons and other items on the page. White space de-clutters a page by giving items room to breathe. We can also group items together by decreasing the space between them and increasing the space between them and other items on the page. This is important for showing relationships between items (e.g. showing that this button applies to this set of items) and building a hierarchy of elements on the page.

Notice the big content margin, padding and paragraph spacing on The Netsetter. All that space makes the content easy and comfortable to read.

White space also makes content more readable. A study (Lin, 2004) found that good use of white space between paragraphs and in the left and right margins increases comprehension by almost 20%. Readers find it easier to focus on and process generously spaced content.

In fact, according to Chaperro, Shaikh and Baker, the layout on a Web page (including white space, headers, indentation and figures) may not measurably influence performance but does influence user satisfaction and experience.

8. Effective User Testing Doesn’t Have To Be Extensive

Jakob Nielsen’s study on the ideal number of test subjects in usability tests found that tests with just five users would reveal about 85% of all problems with your website, whereas 15 users would find pretty much all problems.

Source: Jakob Nielsen’s AlertBox

The biggest issues are usually discovered by the first one or two users, and the following testers confirm these issues and discover the remaining minor issues. Only two test users would likely find half the problems on your website. This means that testing doesn’t have to be extensive or expensive to yield good results. The biggest gains are achieved when going from 0 test users to 1, so don’t be afraid of doing too little: any testing is better than none.

9. Informative Product Pages Help You Stand Out

If your website has product pages, people shopping online will definitely look through them. But many product pages lack sufficient information, even for visitors doing a quick scan. This is a serious problem, because product information helps people make purchasing decision. Research shows that poor product information accounts for around 8% of usability problems and even 10% of user failure (i.e. the user gives up and leaves the website) (Prioritizing Web Usability).

Apple provides separate “Tech Specs” pages for its products, which keeps complicated details away from the simpler marketing pages, yet provides easy access when they’re needed.

Provide detailed information about your products, but don’t fall into the trap of bombarding users with too much text. Make the information easy to digest. Make the page scannable by breaking up the text into smaller segments and using plenty of sub-headings. Add plenty of images for your products, and use the right language: don’t use jargon that your visitors might not understand.

10. Most Users Are Blind To Advertising

Jakob Nielsen reports in his AlertBox entry that most users are essentially blind to ad banners. If they’re looking for a snippet of information on a page or are engrossed in content, they won’t be distracted by the ads on the side.

The implication of this is not only that users will avoid ads but that they’ll avoid anything that looks like an ad, even if it’s not an ad. Some heavily styled navigation items may look like banners, so be careful with these elements.

The square banners on the left sidebar of FlashDen are actually not ads: they’re content links. They do look uncomfortably close to ad banners and so may be overlooked by some users.

That said, ads that look like content will get people looking and clicking. This may generate more ad revenue but comes at the cost of your users’ trust, as they click on things they thought were genuine content. Before you go down that path, consider the trade-off: short-term revenue versus long-term trust.

Bonus: Findings From Our Case-Studies

In recent years, Smashing Magazine’s editorial team has conducted a number of case studies in an attempt to identify common design solutions and practices. So far, we have analyzed Web forms, blogs, typography and portfolios; and more case studies will be published next month. We have found some interesting patterns that could serve as guidelines for your next design.

Here, we’ll review some of the practices and design patterns that we discovered in our case studies in this brief, compact overview, for your convenience.

According to our typography study:

• Line height (in pixels) ÷ body copy font size (in pixels) = 1.48
  1.5 is commonly recommended in classic typographic books, so our study backs up this rule of thumb. Very few websites use anything less than this. And the number of websites that go over 1.48 decreases as you get further from this value.
• Line length (pixels) ÷ line height (pixels) = 27.8
  The average line length is 538.64 pixels (excluding margins and padding), which is pretty large considering that many websites still have body copy that is 12 to 13 pixels in font size.
• Space between paragraphs (pixels) ÷ line height (pixels) = 0.754
  It turns out that paragraph spacing (i.e. the space between the last line of one paragraph and the first line of the next) rarely equals the leading (which would be the main characteristic of perfect vertical rhythm). More often, paragraph spacing is just 75% of paragraph leading. The reason may be that leading usually includes the space taken up by descenders; and because most characters do not have descenders, additional white space is created under the line.
• Optimal number of characters per line is 55 to 75
  According to classic typographic books, the optimal number of characters per line is between 55 and 75, but between 75 and 85 characters per line is more popular in practice.

According to our blog design study:

• Layouts usually have a fixed width (pixel-based) (92%) and are usually centered (94%). The width of fixed layouts varies between 951 and 1000 pixels (56%).
• The home page shows excerpts of 10 to 20 posts (62%).
• 58% of a website’s overall layout is used to display the main content.

According to our Web form design study:

• The registration link is titled “sign up” (40%) and is placed in the upper-right corner.
• Sign-up forms have simple layouts, to avoid distracting users (61%).
• Titles of input fields are bolded (62%), and fields are vertically arranged more than they are horizontally arranged (86%).
• Designers tend to include few mandatory fields and few optional fields.
• Email confirmation is not given (82%), but password confirmation is (72%).
• The “Submit” button is either left-aligned (56%) or centered (26%).

According to our portfolio design study:

• 89% of layouts are horizontally centered, and most of them have a large horizontal navigation menu.
• 47.2% of portfolios have a client page, and 67.2% have some form of standalone services page.
• 63.6% have a detailed page for every project, including case studies, testimonials, slideshows with screenshots, drafts and sketches.
• Contact pages contain driving directions, phone number, email address, postal address, vCard and online form,

Other Resources

• 15 Valuable Usability PDFs You’ve Never Heard Of
• 15 Important Research Findings You Should Know
• 10 Additional Research Findings You Should Know
• Introduction To Good Usability
• 11 Striking Findings From an Eye-Tracking Study
• 25 Incredibly Useful Usability Cheat Sheets And Checklists
• 10 Usability Findings To Increase Sales And Customer Loyalty
• Web form design guidelines: an eye-tracking study

Have any thoughts on what we’ve covered, or know of other useful usability findings? Please leave a comment below.

About the Author

Dmitry Fadeyev is the founder of the Usability Post blog, where you can read his thoughts on good design and usability. Follow Dmitry on Twitter @usabilitypost

(al)

© Dmitry Fadeyev for Smashing Magazine, 2009. |
Permalink |
221 comments |
Add to del.icio.us | Digg this | Stumble on StumbleUpon! | Tweet it! | Submit to Reddit | Forum Smashing Magazine

Post tags: findings, research, usability

From small-business support company Grasshopper comes Chargify, a billing and subscription system for web 2.0 and SaaS companies that eliminates the need to build bespoke applications.

Their RESTful API and hosted payment solution permit simple integration into any website, allowing businesses to charge customers on a recurring basis, manage subscriptions, achieve PCI compliance, and gain real-time business intelligence from their billing.

Sponsor

In addition to processing one-time and recurring transactions, Chargify handles free trial periods, promotions, refunds, receipts, and reminders.

Also, their pay-as-you-grow pricing seems ideal for small businesses and startups. The first 50 customers are free and range up to $1,500 for 15,000 customers or $2,500 for an unlimited number of customers. Chargify does not charge individual transaction fees.

Take a look at this demo video from the Chargify team:

The API accepts method calls via HTTP and returns responses as JSON or XML, allowing companies to keep the customer purchase flow on their own sites and authenticate users while passing the billing information to Chargify for processing.

Interested parties can sign up for the service, still in beta, at the Chargify website.

Now, it goes without saying that Chargify is far from the first billing software for small- and medium-sized businesses; competitors such as FreshBooks are fast becoming well-known heavy hitters in the space. We also found a couple billing services that offer an API – the Dutch MoneyBird, and two English-language services, Zuora and Vindicia. What – if anything – makes Chargify truly competitive in this increasingly crowded space?

Let us know your thoughts in the comments – especially if you have experience with using any of these online billing services!

Discuss

By Todd Bogdan, Software Engineer

Today, I’m happy to announce that we’re releasing Picasa 3.5, a new version of our free photo editing software. Since we launched it as a beta Labs product 9 months ago, we’ve been steadily improving Picasa for Mac. Now that it has almost all the same features as the PC version, we’ve decided it’s time to remove the beta label once and for all.

If you haven’t tried Picasa for Mac, the new version gives you the ability to add name tags to your photos so that you organize them by what matters most: people. Picasa groups similar faces and lets you easily add a name tag to dozens of photos at once. After you’ve tagged some photos with names, you can do creative things with your tagged photos, like quickly finding all the photos with the same two people in them, making a face collage for a friend, or simply uploading and sharing people albums.

In addition to name tags, Picasa 3.5 has integrated Google Maps so you can more easily geotag your photos. And using our redesigned import process, you can now import photos from your camera and upload selected photos to Picasa Web Albums in one easy step.

Of course, Picasa for Mac is also designed to “play nice” with iPhoto, taking a special read-only approach to editing photos stored in the iPhoto library. It duplicates instead of changing files as needed, so your iPhoto library isn’t ever affected when you use Picasa.

Picasa 3.5 is available in English (for now; more languages to come). You can download and try it today at picasa.google.com.

Want to reach more than 500 million users with your social app? OpenSocial is the key. The OpenSocial standard will allow you to build apps that work across a number of massive social networks, including MySpace, Orkut, Ning, hi5 and LinkedIn (complete list).

OpenSocial defines an API for developing social apps and was designed in cooperation with multiple social networks right from the start. Amongst many others, companies like Google, Yahoo!, LinkedIn and MySpace support the interface.

Editor’s Note: Looks like The Future of Web Apps will definitely sell out. Speakers: Twitter, Facebook, Google, Six Apart, digg / Kevin Rose, Mozilla, Dustin Diaz and more.

OpenSocial Tutorial

I’m going to walk you through building a simple chat application using the OpenSocial API. You can download the complete code for the application here.

If you want to follow our example in code, a few smaller preparations are necessary. These are necessary mainly because of the fact that OpenSocial development only really makes sense inside of a real social platform which provides the API. Isolated on your home desktop it makes little sense because the basic platform is only available online, from the inside (embedded into) the platform.

For our example, you need a free Orkut account (a valid Google account is also sufficient) and access to the Orkut developer sandbox. The setup of your Orkut account including access to the developer sandbox is described in the document OpenSocial-Tutorial for Orkut in the segment “Running your first Gadget”.

Because chatting without friends isn’t very exciting, it’s vital that you also add a few friends to your Orkut account. If you can’t get any of your colleagues to also register for the Orkut sandbox, you can simply create a second Google/Orkut account, open that one in another browser, add yourself (the other Orkut account) as a friend and then install the app as well.

If you want to program your own Gadget and also make changes to the example code provided, you need a little webspace, including PHP and a MySQL. The other preparations for this are documented in the Readme file in the download archive.

Google Gadgets as a Foundation

The basis for an OpenSocial application is a so-called Google Gadget, which could be familiar already to some developers from experiences with iGoogle, e.g.

A Gadget is an XML document and is merely the frame for an OpenSocial app.
An exemplary Gadget definition could look as follows:

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
  <ModulePrefs title="Chat Tutorial">
      <Require feature="opensocial-0.8" />
  </ModulePrefs>
  <Content type="html">
      <![CDATA[
         // here comes our application code...
      ]]>
  </Content>
</Module>

The real application code is defined within the <Content> node of the Gadget and consist of HTML and JavaScript (while the embedding of Flash or Silverlight objects is possible too). All following JavaScript code snippets in this article belong inside of this <Content> node.

Initialize the App

Because we work with JavaScript within our Gadgets, at first we should wait until the page has completely loaded to be able to initialize our application cleanly. From Javascript frameworks like jQuery or Prototype you’re probably already used to getting informed as soon as the DOM is ready and we can begin with the initialization. Google’s Gadget-API also has such a helper function:

gadgets.util.registerOnLoadHandler(function(){
    load_friends();
});

Querying for Data in OpenSocial

An important part of our chat application is a simple list of our friends. To find out who our friends are (and how many we have) we ask our social network container (which is Orkut in our example). The corresponding JavaScript function “load_friends”, which we called on initialization, looks like this:

function load_friends(){
    var req = opensocial.newDataRequest();
    req.add(req.newFetchPersonRequest(opensocial.IdSpec.PersonId.VIEWER), 'viewer');
    var friends = opensocial.newIdSpec({ "userId" : "VIEWER", "groupId" : "FRIENDS" });
    req.add(req.newFetchPeopleRequest(friends, {}), 'viewer_friends');
    req.send(on_load_friends);
}

From this example we see how data queries work in OpenSocial:

In the first line we create a “DataRequest” object. All requests which we would like to have answered are appended to this object subsequently; in our example we first add a query for the profile data of the “Viewer” and then a query for his friends by calling req.add().

Because we work exclusively with JavaScript and HTML here, data queries are also carried out asynchronously through JavaScript (using AJAX).

It’s only in the last line of our example that the request is really sent through req.send(). It’s worth noting that, with this concept of querying, we can immediately take care of several data queries in only one request – instead of needing several AJAX requests and generating traffic and latency several times. Google calls this procedure “batch requesting”.

At the same time, looking at that code snippet, you can clearly see what it’s all about in OpenSocial: it’s about “people data” and the relations of the people to each other. Two types of persons are the most interesting, which is why the API defines them as constants:

One of them is the “VIEWER”. The Viewer is the (logged in) user who’s looking at the profile page on which our application is installed. The other one is the “OWNER”, which is the owner of the profile page on which the Gadget is installed. It is perfectly possible that the Owner and the Viewer at times are the same user – when the owner is looking at his own profile page, using the application.

In addition to Viewer and Owner, it is also possible to request data about other users by their user ID.

As we sent off our requests we had given an additional parameter to the method req.send(). This was the reference to the function “on_load_friends” which is used as a callback and is automatically called as soon as our request was answered and returned data. Therefore, we can access the results of our query – the person data we asked for – inside of the function “on_load_friends”:

function on_load_friends(data) {
    var viewer = data.get('viewer').getData();
    var friends = data.get('viewer_friends').getData();
    ...
}

Accessing our data through the method “get()” is necessary because of the “batch requesting”. While putting together the query, we had provided the strings ‘viewer’ respectively ‘viewer_friends’ as a last parameter. This was necessary because we wanted to request multiple data packages in one go – and of course we want to be able to distinguish them again at the end. Through data.get (’viewer’).getData () we get the return values which we had named ‘viewer’ when we put together the request.

Now in the next step we want to show our friends in a list:

friends.each(function(friend) {
    friends_html += '<div class="friend_name"> '+ friend.getDisplayName()+ '</div>';
});

Those of you who have already worked with Ruby or the JavaScript framework Prototype will probably know the “each” notation. The OpenSocial-API provides this function, too. We use it here to iterate through the records of our friends.

By calling “getDisplayName()” on each of our friends records we use a special function of OpenSocial.

Most data fields are specific for a certain platform. This means e.g. that a field called “hobbies” that exists on MySpace might not exist in another container like Orkut at all. To at least be able to show a display name – in any case, and on any platform – a sensible return value from getDisplayName is guaranteed by the API.

In other cases we should be more careful by explicitly checking if a certain field that we’re trying to access really exists:

opensocial.getEnvironment().supportsField(opensocial.Environment.ObjectType.PERSON, opensocial.Person.Field.ID);

With this line of code, we can check if there’s a field called ‘id’ for objects of type ‘person’. As soon as we know that our field of choice really exists, we can access it through “getField()”:

friend.getField(opensocial.Person.Field.ID);

A few specialities still have to be considered when sending a chat message:

function send_message(message, user_to, user_from){
    var post_data = { action: 'save_message', message: message, to_user: user_to, from_user: user_from};
    post_data = gadgets.io.encodeValues(post_data);
    var params = {};
    params[gadgets.io.RequestParameters.CONTENT_TYPE] = gadgets.io.ContentType.TEXT
    params[gadgets.io.RequestParameters.METHOD] = gadgets.io.MethodType.POST;
    params[gadgets.io.RequestParameters.POST_DATA] = post_data;
    gadgets.io.makeRequest('http://www.example.com/message.php', function(){}, params);
}

Our self-defined method “send_message()” is used to send an entered message via AJAX to a remote server. This remote server then saves the message in a database until it is picked up by it’s receiver.

Inside of this function, the Gadgets-API is used heavily. This is necessary because it’s not easily possible for security reasons to send a request to an other than the origin server with AJAX. Here the Gadgets-API steps in, which makes this possible through “gadgets.io.makeRequest”.

Other Possibilities

The OpenSocial-API offers some more possibilities. With the help of the Activities-API you can, for example, read or write activity messages for a user. Therefore, an application would be able to read or write activity messages like “Mike has a new profile photo” or “Martin and Linda are friends, now”.

A so-called “Lifecycle event” can help developers gear into important points in the life cycle of an application. As a developer, you can for example, be informed when the deinstallation of a Gadget happens and take actions accordingly (by deleting old database entries, for example).

Another area of the API deals with data persistence. This functionality is exciting because OpenSocial apps – being “just a frontend” at first hand – come without their own backends and therefore have no database by default. Every social network can decide for itself to which extent it allows applications to persist data for a viewer.

The concept of “Views” is also an interesting part of OpenSocial development: An OpenSocial-Gadget can have different views. This depends on where the Gadget was integrated, respectively in which view a user is at this specificmoment. The current view can be requested at runtime so that, e.g., different functionalities can be offered depending on the currently active view of the Gadget.

Basically four different view types are defined in OpenSocial: The “Profile” view is active when it is viewed on the profile page of the user. The “Home” view is active when a Gadget is viewed on the personal homepage of the user (on which the above mentioned viewer and owner constants are always identical, because only the account owner has access to his personal homepage). The “Canvas” view is a view in which the Gadget is more or less alone on the page and therefore has a lot of space available. Finally, the “Preview” view has limited accesses and is intended for demo purposes.

Publishing your SocialApp

The development of an OpenSocial application always begins in a sandboxed developer environment where you can work on your application without interruptions. During this time, however, the app is only accessible to the developer himself (or other developers) – but not publicly to normal users.

Then – after some time of development and testing – when your SocialApp has a sufficient level of maturity and is ready to enrich the world, you can submit it to the respective social network to be checked and (hopefully) approved.

Though the submission process is a little different in every social network (as an example you find Orkut’s application form here), it always serves the same purpose: to put your submitted app through their paces.

If then, after several days or weeks, your application was found to be nice enough, it is included into the platform’s list of applications – and can be installed by all users of the platform.

Summary

Google’s OpenSocial-API only really offers the functionality that Facebook developers are already accustomed to. However, with OpenSocial, you can reach a wider and larger audience of 500 million people.

In day-to-day development, in spite of the wholehearted promise “Many sites, one API”, caution is advised: some of the networks don’t implement the complete specification or take awhile to implement updates to their APIs. Sometimes some minor differences in the API implementation force you to adapt to special situations (hi5, for example, requires the Gadget scaffolding to be a little bit more detailed).

The result so far that OpenSocial can present, however, looks good: excellent documentation, more than 30 involved social networks all over the world, and more than half a billion users.

The Dev-Team has released a jailbreak for the 3.1 firmware… it jailbreaks the iPhone 2G, 3G and the iPod touch 1G. You will want to read the entire post before doing anything. Below is a snippet of the post but, you can check out the full article and download the files HERE.

This is the low down on our tools for use with the 3.1 firmware from Apple, please read the whole post in full before attempting anything. Because of changes with Apple’s update techniques this will be a multipart release, starting with the initial release of PwnageTool for Mac OS X – this application supports the iPhone 1st Generation (2G), The iPhone 3G and the iPod touch 1G. NB: THIS DOES NOT SUPPORT THE 3GS OR NEW IPOD TOUCH. redsn0w for Mac OS X and Windows will follow sometime in the near future, please don’t bug us about it – we’ll release when we have something ready.

1.GOLDEN RULE: If you are using a 3G iPhone with ultrasn0w and rely on ultrasn0w to obtain cellular service, then you should only upgrade to 3.1 with a PwnageTool created .ipsw. – Stay away from Apple’s direct updates as described here and here please get up to speed on the whole subject by reading the information contained in these posts.
2.If you have an original iPhone (1st generation) then 3.1 unlock works with this PwnageTool release. iPhone 3G users upgrading to 3.1 will need to continue using ultrasn0w with a PwnageTool created 3.1 .ipsw
3.Please read all parts of this post before downloading and using these tools.
4.Read items 1, 2 and 3 again and again.
5.At the bottom of this post are the bittorrent files for the 3.1 capable version of PwnageTool.
6.This app is suitable for the recent 3.1 release.
7.This version of PwnageTool will NOT work for the iPhone 3GS.
8.PwnageTool WILL work for Original iPhone (1st Generation), Original iPod touch (1st Generation) and the iPhone 3G.

Full article HERE.

Saurik has developed a server that you can point your iTunes to and it will not only authenticate firmware versions that Apple no longer signs (allowing them to be installed) it also saves information during the authentication and will allow you to downgrade later if Apple doesn’t want you to. This blog post he wrote is a really good read, but it’s really long. Here’s a quick highlight but make sure you read the whole thing here: saurik.com/id/12

To this end, I have constructed a server that duplicates the functionality exposed by Apple’s signature server, except using “on file” results rather than live requests.

All we need, then, is to make iTunes use it. Luckily, most operating systems also have the ability to locally define bypasses on specific hostnames through a file called hosts. Using this, we can redirect requests to Apple’s signature server to Cydia.

So, open the file C:\Windows\System32\drivers\etc\hosts (Windows) or /etc/hosts (Mac OS X) and add the following entry to the bottom of the file.

74.208.105.171 gs.apple.com

Now, when iTunes thinks it is talking to Apple, it is talking to Cydia instead. Doing this will allow iTunes to access signatures already stored by Cydia’s “on file” feature.

This server will also act as a cache for any SHSH blobs it hasn’t seen, acting as an intermediary to Apple’s server. This effectively registers your device with the “on file” mechanism, which means you can now enjoy the protections of being able to downgrade your firmware in the future even if you aren’t jailbroken.

This point should be stressed: even if you don’t jailbreak, and even if you never intend to jailbreak, you should consider using the new “on file” service.

Let’s say that Apple releases an OS upgrade in the future, you take it, and they break something important. Maybe they break your e-mail account, or your todo list. Your business is now crippled.

If only you could downgrade, right? Alas, Apple won’t let you anymore. That’s where the new signature cache server comes in: by doing your restores through this server you secure your ability to not accept upgrades from Apple if the need is dire.

Check out the full article HERE.

Ning, the popular online service that allows users to create their own custom social networking sites, launched Ning Apps today. Ning Apps gives users the ability to embed over 90 new apps and widgets on their social networks. Given that Ning Apps is based on the OpenSocial standard, however, developers will surely create a lot more apps in the near future. Ning added basic OpenSocial support to its service last year. At that time, however, Ning only supported about 30 applications and users could only add OpenSocial applications to their own profiles but could not publish them on their network sites so that everybody could see them.

Sponsor

Now, Ning Network Creators – that is, users who administer their own social network on Ning – can finally embed these apps and make them available for all the users on their custom social network. Among the apps launched today are a service that allows artists to sell merchandise from Sellit, a BlogTalkRadio app for podcasters, Huddle workspaces, PollDaddy polls, as well as WordPress apps to display blog posts and a Ustream app for live video streaming. A complete list of existing apps is available here.

While other social networks have obviously provided their users with access to these kinds of apps and widgets for a long time already, this is a major step forward for Ning. Ning, according to its own stats, currently hosts over 1.5 million different social networks (how many of these are active is a different question, however) and has about 33 million registered users. If Ning wants to continue to compete with Facebook and other social networks, it simply needs this kind of open development environment to provide its users with the right set of features, though it also looks like Ning actually has an Apple-like approval process for new apps in place.

Discuss

AppStoreHQ just published a searchable directory of all *published* iPhone app developers (i.e., at least 1 app in the App Store). IMPORTANT – if you do contract iPhone dev work in addition to shipping your own apps, you can edit your listing to reflect that so potential clients can find you. The directory is here: http://www.appstorehq.com/developers