Use the Facebook.showPermissionDialog FBJS api call to authorize the Page for which you are an admin. Set the enableProfileSelector to true and include the page id in the profileSelectorIds. Once  the app user has authorized and given the extended permissions, You can use the Stream.publish api call with the page id as the target id and publish on behalf of the page.

The Details – Posting to the Facebook Fan Page on behalf of the page.

Facebook allows you to create pages aka fan pages for your website, business, product, or almost just about anything. Page admins can customize their pages by adding facebook applications from the app directory to their pages. Using Facebook applications for fan pages allows you to integrate into the social connections of your fans better.

Applications with extended permissions can publish to a user’s wall, news feed stream or profile. In addition, applications can now publish to a Page wall.

Publishing to a Page as a user is fairly simple with Stream.publish facebook api, the Facebook developer api covers this well. You can prompt the user for  ’publish_stream’ extended permissions using the  fb:prompt-permission FBML tag, preferably during an initial set up workflow.

Once the user has authorized your app and given the extended permission, You just have to set the target id to the page id in your Stream.publish api call.  See the sample php api call below,

$facebook->api_client->stream_publish($message, $attachment,$action_links, $target_id);

Publishing on behalf of  a page is trickier.  Page admins have to authorize the app to publish on behalf of a page. You can do this by using

the Facebook.showPermissionDialog FBJS api call.

Facebook.showPermissionDialog('publish_stream, read_stream', ondone, showProfileSelector, [1234,2345]);

Just replace the profileSelectorIds ( [1234, 2345]) and include the page id in the FBJS call above. This should bring up a permission dialog and show

a “profile  selector” including the page for which you are an admin.

You should now be able to use the Stream.publish api call with the page id as the target id and publish on behalf of the page.

Web designers are forced to think within the constraints of the web browser when it comes to user interaction design.

The post above discusses more general approaches to user interaction design and not just within the context of the web browser.

Since I am mostly involved in web UI interactions these days this post was very refreshing as it brought a new perspective to me.

While developing the UI for a web app recently I realized that the web design world is in the search-discovery cycle of  “patterns” that guide user interactions.  Patterns in user interactions has the dual benefit of helping both designers and users. Much like the “guidelines” on Windows ( Windows User Experience Interaction Guidelines ) or Mac (Apple Human Interface Guidelines ) development platforms that help Windows or Mac application developers respectively while standardizing the user interactions of the applications developed on those platforms. These guidelines ensure strict quality, improves user experience and makes the life of designers easier.

There are plenty of resources that discuss “web ui interaction patterns” .

Designing Interfaces is a good resource if you are designing web user interactions. Rob Adams one of the core developers of Adobe’s Flex  has an excellent set of introductory articles which not only apply to designing user interfaces using Adobe’s Flex but applies to user interface design in general. I especially liked the Structuring your Application part.

Everyone loves the web, even if there are a few frustrations that we still have to overcome

Happy Surfing !

If you are using Fiddler 2 follow the instructions in the Fiddler FAQ

Why don’t I see traffic sent to http://localhost or http://127.0.0.1?

Fiddler does not capture packets sent to the localhost URL which makes debugging web applications hosted in your local machine painful.

Here is how I configured Fiddler to debug web applications hosted in your local machine,

Lets say your application is accessed using the URL http://localhost:8090/MySpiffyApp/default.aspx. To make fiddler capture the HTTP requests sent to this URL, all you have to do is edit the HKCU\Software\Microsoft\Fiddler\ReverseProxyForPort and set the decimal value to 8090. This tells fiddler to proxy all traffic sent to HTTP port 8888 (default proxy port) to HTTP port 8090. Now access the application using the fiddler proxy port

http://localhost:8888/MySpiffyApp/default.aspx

and you should be able to see the packet trace in Fiddler.

If you see the page below instead of your application then try restarting Fiddler and make sure the registry key name matches exactly as above.

1. Set the HKCU\Software\Microsoft\Fiddler\ReverseProxyForPort registry DWORD to the local port you’d like to route inbound traffic to
2. Restart Fiddler

Let me know if this didn’t work for you or if you have another way of debugging web applications hosted on your local machine.