Recently in Web services Category

Web services and web programming. Includes REST and SOAP APIs, script enhancements, and web platform development.

  1. Jan03

    Facebook v. Power Ventures

    Facebook v. Power Ventures

    Facebook filed eight legal complaints in United States federal court against Power Ventures, operators of social aggregator Power.com (story via NYT Bits blog). Facebook claims Power collected Facebook usernames and passwords, stored Facebook data on their servers, used the Facebook trademark without license, sent e-mails posing as Facebook, and knowingly circumvented Facebook's attempts to block access. The lawsuit, filed on December 30th in San Jose, comes one month after Facebook initially contacted Power.com regarding its violation and attempted to transition Power to an acceptable method of access: Facebook Connect.

    Power.com is headquartered in Rio de Janeiro, Brazil with additional offices in San Francisco and Hyderabad, India. Power raised $8 million from Draper Fisher Jurvetson, DFJ affiliate FIR Capital, Esther Dyson, and other investors. Facebook is seeking triple damages for willful violation including all revenue generated by Power.com in the month of December. Facebook may be able to claim $10,000 for each Facebook account accessed by Power under California Penal Code section 502 due to repeat violations.

    1. The password anti-pattern
    2. Social data distribution
    3. Dispute timeline
    4. Tips for business partnerships
    5. Summary

    The password anti-pattern

    Facebook login

    Collecting Facebook usernames and passwords is at the heart of the dispute. Power.com impersonates a Facebook user after collecting their username and password. The site imports friends lists from Facebook and other social providers to create a meta profile for its over-networked members trying to keep their many personas in sync. Facebook Connect, announced in May and available for beta testing shortly after, provides account linking between Facebook and other sites, SSL transport, and friend imports. Facebook Connect limits the data flow of Facebook user data in ways a direct login would not. Power.com assumed full user powers as a remote agent of a Facebook user instead of an authorized proxy to accomplish its own goals and violated Facebook terms of service in the process.

    I covered some of these data portability issues and best practices in my Data Portability, Authentication, and Authorization post last year.

    Social data distribution

    [T]he sole end for which mankind are warranted, individually or collectively, in interfering with the liberty of action of any of their number, is self-protection. That the only purpose for which power can be rightfully exercised over any member of a civilized community, against his will, is to prevent harm to others. His own good, either physical or moral, is not a sufficient warrant...In the part which merely concerns himself, his independence is, of right, absolute. Over himself, over his own body and mind, the individual is sovereign.

    John Stuart Mill, On Liberty

    Modern society mostly allows people to commit self-harm as long as that action is not also harming others. Facebook restricts access to another person's member data beyond the original intent that person's sharing. New data use must explicitly receive permission to participate in shared data beyond the walls of Facebook.com (you may invite me into this new context but I am not automatically imported). Data is shared within a friend context on Facebook with the understanding such information is protected and may be limited to only a group of approved friends. Once that friend data starts propagating outside its initial use (by a Facebook member or Facebook itself) the trust associated with sharing data is violated. If you have ever thought twice about posting an e-mail address on a web page out of fear of automated data harvesters you have experienced communicating with a known community of site visitors versus other uses. Facebook wants to be an identity hub of real data about real people and takes certain steps to protect that data exchange.

    Power.com knowingly violated the Facebook Terms of Service and encouraged Facebook members to do the same.

    Dispute timeline

    Power.com launched to a United States audience on December 1, 2008. The site previously focused on the Brazilian market with support for Flogão and Google-owned Orkut since launching in August. Facebook contacted Power.com on December 1, according to the lawsuit, notifying the team of their terms of service violation.

    Power Ventures CEO Steven Vachani responded to the Facebook inquiry on December 12 (11 days later) promising to delete all existing Facebook data stored on Power.com servers and implement Facebook Connect as a replacement by December 26. The next business day Facebook acknowledged the e-mail and waited for confirmation of data deletion and Connect switch-over. Vachani confirmed the transition progress on December 22 (4 days before the supposed switch).

    Vachani e-mailed Facebook legal council after the close of business on December 26 and communicates a "business decision" not to comply with Facebook's request to stop collecting and storing Facebook logins on Power.com. Vachani claimed the site would implement Facebook Connect but such integration would take over 5 weeks to complete. Power.com kicks off a "launch promotion" that same day with a $100 reward for the Facebook user who invites the most friends to join Power using their Facebook credentials. Facebook implements an IP-address block against Power.com servers on the evening of December 26 to prevent further abuse.

    Power.com circumvents the IP-block by Facebook and continues its marketing campaigns. Power sets up a Facebook event page to promote its $100 signup give-away and uses the existing Facebook accounts in its system to send event invites to friends lists.

    Facebook took legal action against Power Ventures on December 30, one business day after the Christmas holiday weekend, to prevent further abuse after civil discussions obviously broke down. Facebook accused Power of trespassing on Facebook servers in San Jose (a modern form of ToS violation), spamming Facebook members (violation of CAN-SPAM), and knowingly circumventing data protections (DMCA), and unlicensed use of the Facebook trademark.

    Tips for business partnerships

    Power Ventures could take proactive steps to look like a legitimate, responsible business in the eyes of potential business partners such as Facebook.

    Create a meaningful WHOIS record

    Power.com domain data currently lists "DiscountDomainRegistry" as a technical contact. "Power Assist Inc" is listed as a registrant and "Leigh Power" is listed as an administrative contact. Not good identity management.

    Add SSL

    If you are going to collect member login credentials from other sites you should at least use a SSL certificate for more secure data transfer. Self-sign if you must, but $30 will buy you a certificate recognized by major browsers. If you can afford extended validation certificates and the verification process that entails, even better.

    Register your company with the partner website

    Facebook allows its members to join one or more corporate networks. Register your company on Facebook and at least associate executive and developer accounts. This additional verification step helps Facebook identify your employees. Other social networks have similar verification and associations.

    Power Ventures is not listed in the Facebook corporate network directory.

    Summary

    Power.com violated Facebook terms of service by accessing and storing Facebook member data on its servers. Facebook immediately contacted Power regarding this violation and attempted to work with the site as they transitioned to the official data API, Facebook Connect. Power reneged on their agreement hours before promised delivery and immediately launched a marketing campaign to financially reward further violations. Facebook decided enough is enough and blocked Power through technical measures followed by legal measures when the site did not comply.

    I have little sympathy for Power and its actions. I hope other sites violated by Power.com such as Google, Microsoft, MySpace, and Hi5 put a stop to websites like Power harvesting user data instead of using permitted access methods such as OAuth. Locating your business in Brazil with servers in Canada and development in India does not shield companies from the consequences of abusive practices.

  2. Dec10

    Looking to join smart, challenging team to change your Web

    I have decided to once again seek full-time corporate employment. I miss being surrounded by smart people every day and the new synapses that light up in such an engaging environment. I have started talking to a few companies about working on difficult Web problems full-time as they strengthen their online business. It will be fun to fully invest in a single product once again in a specialized role.

    I like to think of my work over the past two years as rethinking front-end development. In the social, distributed web our front-end exists beyond the borders of our own websites. It's inside web feeds, widgets, and specialized applications that deliver the right content at the right time to the right audience inside their consumption environment of choice. Web development is headed in this direction, causing us to rethink the differences between a website and a web application while delivering more context-specific experiences to our audiences. I have covered some of these changes at three Widget Summit conferences, taught computer science classes in China, rewired consumer electronics devices for the Web age, restructured large media companies to embrace syndication beyond their walls, and basically changed the way data is rendered and consumed. Fun stuff and I would like more challenges every single day. Many websites still need to better embrace the syndicated web and I'd like to dedicate myself to that type of front-end excellence every day.

    So that's what I'm up to. You'll continue to see new product and demonstrative web apps released here over the coming weeks. The quiet of the holidays typically yields interesting hacks such as creating visitor profiles based on browser history, analyzing Google's new indexing techniques, or reverse-engineering Google Reader data formats.

    I am looking for tough new challenges on a full-time basis among other bright, driven people. If you're building cool new things among a good group of people and we're not already talking contact me and perhaps we'll create some excellent products together. Official résumé also available, with the concise bullet-point summaries such a document requires.

  3. Dec09

    OpenSocial REST for social data interchange

    OpenSocial is best known for its social applications: canvas and profile views powered by JavaScript and Flash. Applications and widgets are just one part of the full OpenSocial offering. Over the past few months the OpenSocial spec has grown to include JSON, Atom, and XML outputs over a RESTful interface. OpenSocial containers MySpace, LinkedIn, and Plaxo already expose social data over these protocols, with additional support from large networks such as 51.com and Yahoo! expected in the near future.

    Sharing and Accessing Social Data in OpenSocial

    Exposing data over OpenSocial REST foramts is not limited to widget containers. Social web apps such as Flickr, Twitter, or even Facebook could support OpenSocial data standards without ever adding OpenSocial application support to their web pages. Last week I turned TwitterFE into an OpenSocial RESTful container, opening up Twitter data for OpenSocial clients. OpenSocial 0.9, scheduled for release on December 19, will help solidify these new protocols across containers (I found many errata in 0.81 and I am pushing for changes in 0.9). In this blog post I will provide a brief overview of OpenSocial RESTful protocols and its data implementation for any website interested in standardized descriptors of social data.

    1. OpenSocial background
    2. People
    3. Activities
    4. Advertising OpenSocial support
    5. Summary

    OpenSocial background

    OpenSocial applications request and interpret applications via JavaScript requests. An application might request profile data on the logged-in member viewing the app, write a new story to a member's social news feed, or store custom data such as a member's favorite color. These data objects are called Person, Activity, and AppData respectively. Each of these data objects contain a minimal-set of required information and a long list of optional data that varies by implementation. Most social applications store a member ID, username, profile photo, and a profile URL, for example, but specified views on romance or religion are less common.

    Yet OpenSocial isn't just for widget containers. Social web apps can export and import user data via anonymous and/or authenticated requests. You just have to speak the language of OpenSocial data to achieve fluid data interchange between servers. Data requests may occur with or without a login but additional data may be exposed to requesters with proper OAuth credentials for a particular account.

    People

    People are the center of a social network experience, connecting us to new data and interactions. OpenSocial maps common profile components across containers including e-mail addresses, profile pictures, location, and member bios. Friends lists are a collection of people objects mapped to a particular owner.

    The only required person data from a container are a display name and a container-specific identifier such as the numeric auto-increment id you are storing in your users table. Websites need to stick to a specific Person vocabulary to ensure compatibility across sites.

    Portable Contacts and OpenSocial RESTful Person objects are wire-compatible formats. The specs are currently aligned but you might hear either one used interchangeably in conversations.

    Example

    <person xmlns="http://ns.opensocial.org/2008/opensocial">
      <id>mysite.com:1234</id>
      <displayName>John Smith</displayName>
      <name>
        <givenName>John</givenName>
        <familyName>Smith</familyName>
        <formatted>John Smith</formatted>
      </name>
      <gender>male</gender>
      <emails>
        <primary>true</primary>
        <type>work</type>
        <value>john@example.org</value>
      </emails>
      <ims>
        <primary>true</primary>
        <type>aim</type>
        <value>johnsmith</value>
      </ims>
      <account>
        <domain>mysite.com</domain>
        <username>johnsmith</username>
        <userid>1234</userid>
      </account>
    </person>

    In the above example I've defined some basic data about a fictional user of MySite.com using the OpenSocial Person vocabulary in an XML format. Consuming agents can write a single interpreter for multiple OpenSocial containers and easily display, export, or annotate profile and friend data over this interface.

    Activities

    Activities are small application updates usually posted to a social news feed. When a member adds an event, posts a status update, uploads a photo, or takes some other action websites usually write a new activity into the member's feed. These actions are normalized in the OpenSocial context into a specific Activity vocabulary.

    Example>

    <activity xmlns="http://ns.opensocial.org/2008/opensocial">
      <title>Updating my MySite account</title>
      <url>http://mysite.com/johnsmith/status/123456789</url>
      <id>mysite.com:1234/activity:123456789</id>
      <userid>mysite.com:1234</userid>
    </activity>

    The above example normalizes a text-based status update into an OpenSocial activity expressed in XML. I can post this message into an OpenSocial activity stream, open up export capabilities for members, or interface with a wider array of applications (desktop, mobile, etc.) that already support activity stream display.

    Advertising OpenSocial support

    OpenSocial RESTful resources are described using XRDS-Simple. If you have used OpenID or OAuth you're likely already familiar with this markup and discovery process. Agents can probe possible supporting containers for application/xrds+xml response support to receive a full descriptor set.

    OpenSocial REST containers advertise supported data objects by the object's name. A type of http://ns.opensocial.org/* advertises RESTful support, data objects available (person, activity, etc.), possible query types, and a hint of specversion (currently "2008"). You might choose to support some or all of the OpenSocial data objects and your XRDS document will serve as the central discovery resource for such data.

    Summary

    OpenSocial is about more than just widgets and applications rendered in a web browser. The project exposes standardized interfaces and object descriptors for social web components while offering interoperability with very large social networks around the world. Any social website can allow public and private access to member data using OpenSocial RESTful protocols and responses. You will open up new API opportunities, allow import and export of data between sites, and even expose more granular data to crawlers such as Google (if you choose). Interesting stuff that's just getting started.

  4. Nov19

    Rewriting Twitter for web best practices

    TwitterFE.com screenshot

    Last week I decided to rewrite the Twitter.com front-end on Google App Engine to incorporate modern front-end programming best practices, exceptional performance, and establish a solid platform for further development. TwitterFE.com is a fully-functional read-only clone of Twitter.com designed to make your web browser sing. I created the site as an example of web development best practices anyone can integrate into their web presence.

    The new web front-end on TwitterFE.com features localized templates, expressive markup, distinct URL structures, integrated site search, geo-distributed dynamic and static servers, and more available features than Twitter.com. In this post I will outline some of the changes I've applied to the Twitter front-end reproduction as they apply to general front-end web development.

    1. Global audience
    2. Unique usage models
    3. Consolidate URLs
    4. Expressive markup
    5. Split the page load
    6. Know your cache settings
    7. Review access controls
    8. Expose site search
    9. Summary

    Global audience

    Twitter.com top countries - Google Trends

    I added a localization framework to the Twitter front-end to enable site content delivered in multiple languages. According to Google Trends Twitter's top regional languages are English, Portuguese, Japanese, Chinese, German, and Spanish speaking regions. I isolated the site's template strings and translated all key phrases into Spanish. Visitors with an Accept-Language header of es will receive template strings in Spanish.

    Twitter profile about box Spanish - Evan Williams

    The most difficult part of localization is isolating your template strings and choosing common wording across the site. Twitter uses the terms "person," "user," "account," and more to reference a profile owner. Websites need to pick common concepts to explain their site interactions before requesting translations.

    Modern websites rely on crowd-sourcing to translate a site into new languages. Porting a web application to your native language is a point of pride for many communities. Something as simple as "favourites" instead of "favorites" for the Brits could help create identity around a product in other countries. Facebook Translations and Google in Your Language are just two examples of large localization efforts led by an engaged community.

    Unique usage models

    Twitter.com has three main visitor interactions: anonymous visitor, annotator, and author. The current Twitter website loads resources for all possible interaction types, weighing down the page and interfering with the intended experience. I tore the site down and started from scratch, building up each interaction model starting with the anonymous visitor.

    Anonymous visitor

    Twitter logged out view - Evan Williams

    The anonymous, public visitor is anyone browsing Twitter content in a non signed-in state. This audience typically makes up the majority of site traffic and includes both humans and search engines. Websites need to clearly and concisely communicate content to this new audience who is likely inexperienced with your site while quickly while smartly driving business objectives such as member signups or advertising.

    Annotator

    Twitter logged out view - Evan Williams

    The annotator is a logged-in member browsing site content with an opportunity for annotation. They may want to discover new social network friends, mark content as a favorite, or otherwise engage with an existing content. Annotations are typically short and asynchronous, posting new associations between an account holder and a unique content identifier. The majority of pages presented to logged-in users on Twitter.com follow this annotation interaction model.

    Author

    Twitter logged out view - Evan Williams

    Twitter is a message authoring platform. Logged-in users may publish new text updates from their homepage while browsing other subscribed content. Authors type into a text area and receive real-time feedback on authoring limitations while they type. The author commits new content to Twitter's servers after hitting a submit button, and the service responds with a confidence indicator for accepted updates.

    Consolidate URLs

    How many possible URLs represent the same content on your website? Websites should avoid duplicate content spread across multiple paths, subdomains, and protocols. There should be one strong public-facing match for your distinct content.

    Which one of the following URLs represents the profile page of Twitter CEO Evan Williams (username ev).

    • http://twitter.com/ev
    • http://twitter.com/ev/
    • https://twitter.com/ev
    • http://explore.twitter.com/ev
    • http://m.twitter.com/ev
    • and more...

    Websites need to pick a winner and funnel visits into that best representation of content. Search engines are crawling multiple versions of Twitter right now and splitting authority between many different options.

    Be aware of URL propagation when you introduce new subdomains and schemes with relative URLs inherited from a common template. You might be buying new servers to keep up with a crawl load across your millions of pages as a result.

    Expressive markup

    TwitterFE uses an xHTML vocabulary to express content, CSS for positioning and styling, and JavaScript for progressive enhancement and interactions. Gone are the table-based layouts of Twitter.com and its heavy DOM footprint. Resources are split into dynamic and static content and served from geographically-distributed datacenters for optimal performance. Twitter currently stores static assets such as profile pictures on Amazon S3 and does not use a distributed CDN to address speed of light issues.

    Comparing a user such as Al Gore on TwitterFE vs. Al Gore on Twitter.com shows a 41% difference in required resources sent over the wire (89 vs. 152 KB). The new site also reduces the total DOM footprint for faster parsing, layout, rendering, and addressing.

    Microformats expose unique structured objects within each page such as people, relationships, and feed mappings. Search engines such as Yahoo! tap into microformat content to expose deeper information about a page. I cleaned up microformat support on Twitter pages and added support for Internet Explorer 8 Web Slices.

    Expressive markup helps web browsers and search engines better understand the content within your pages. Sites can fully utilize xHTML vocabulary sets independent of default styling to best define the content and the rendered display of each page.

    Split the page load

    Web pages should respond quickly with progressive enhancement added after the main page content renders on the page. We might, for example, load a page and then apply search field listeners, autocomplete, or menu expansions as a second wave. Splitting our pages into "must have" and "nice to have" segments helps us deliver core content quickly while still providing the on-page interactions and magic sprinkles that thrill our visitors.

    Twitter's profile pages load 36 of the profile owner's following list onto each page. That's 36 tiny little 700 byte profile images all waiting in line for a remote connection and display on page. I tripled the total number of displayed member pics but loaded the list asynchronously after the rest of the page finished loading. I can pre-fetch these components into cache on the original profile request and respond very quickly to the async request after page load.

    Know your cache settings

    How long should browsers and other requesting agents hold on to a piece of content before requesting a fresh copy? A frequently changing profile page might expire its HTML every 5 minutes or so while static assets such as a site logo or icon should be kept in browser cache for a long period of time instead of requested with each page. In some cases Twitter sets image Expires headers 5 minutes into the future, slowing down pages and increasing bandwidth costs for the company and its visitors.

    Review access controls

    Some sites split pages into public-facing and login-required access models. Twitter places pages such as a following list or a full-sized profile picture behind a login screen while exposing the same data over their APIs without such restrictions. Twitter.com is losing search engine exposure and logged-out user browsing capabilities due to these inconsistencies in implementation, not policy.

    Expose site search

    Firefox OpenSearch Twitter

    The OpenSearch format exposes site search options to web browsers and search engines alike. If your website offers site search you should be lighting up the browser chrome with new search options for the given page. Twitter acquired a search company in July but has not exposed available search hooks in their main website's front-end. Think about how you might want to scope a search to the currently viewed user account as well as an expanded site-wide option.

    Summary

    TwitterFE is a read-only clone of Twitter's front-end that fixes many of my frustrations with the site's front-end engineering and creates a new platform for future third-party development. Any site could roll these types of improvements back into their core services. Twitter APIs are full-featured enough I can clone the Twitter front-end without creating yet another stand-alone Twitter-like site.

    There is a difference between a website or widget rendering in a browser and having the same site perform exceptionally well. Established web teams should revisit their web content to optimize experiences.

    TwitterFE.com is the result of one person working part-time for a week to re-write the front end of a website serving millions of monthly visitors. Similar lessons apply throughout the Web world.

    I now have a new platform to develop features beyond what's currently offered on Twitter.com. If you're an iPhone developer in need of a headless Twitter API proxy for push updates let me know.

    What other front-end features do you wish established websites would invest time and effort to improve?

  5. Sep03

    The story behind Google Chrome

    Ben Goodger and Google Chrome

    Google released its second web browser yesterday afternoon, adding additional headroom for web applications stretching the limits of what it's possible to accomplish within a web browser. The Google Chrome team assembled domain experts in various fields over the past six years, both through direct hires and acquisitions, to create a new browser and its critical components from scratch. GMail and Google Maps pushed the Web to its limits, taking advantage of browser technologies invented in Redmond but left dormant for far too long. Contributing to Firefox's core, writing browser extensions, and championing HTML could only take the $150 billion company so far: they needed to own the full browser to push their Web efforts forward at full speed.

    1. Growing Frustrations
    2. Acquisition Boost
    3. A New Browser from Scratch
    4. Rev your JavaScript Engines
    5. Meet the Team
    6. Summary

    Growing Frustrations

    Brian Rakowski joined Google in July 2002 as the company's first associate product manager. His first assignment? Launch GMail with features and responsiveness to rival desktop mail clients. Gmail tapped into relatively dormant browser features such as XMLHttpRequest, sockets, prefetch, and more to create a web applications stretching the limits of what was possible inside web browsers of 2004. Today's Gmail continues to run into a browser's limits, setting minimum requirements of Internet Explorer 7+ and Firefox 2+. Google web apps teams such as Maps and Mail continually bump their heads against the latest capabilities of web browsers and in some cases invent their own runtimes.

    Ian Hickson first learned the inner workings of web browsers while an intern at Netscape. After working on Opera for a few years and creating tests for Firefox Ian joined Google to continue his work on new browser features. HTML5 and browser compliance "acid" tests are significant attempts by Ian and others to redefine Web browsers through specs, test, and implementations but until now Google could only offer development help and browser extensions such as Gears to accelerate browser capabilities.

    Google extended what it could not immediately add to the browser core. Gears for new application functionality on multiple browsers. Browser Sync to synchronize browser settings and data across multiple computers. Safe Browsing to create more web trust. Teams from each of these extensions are now working on Google Chrome.

    Acquisition Boost

    Google released its first official Web browser on August 18, 2008 with the beta release of the Android mobile operating system. Google acquired Android in August 2005 to establish a foot-hold on the fastest growing computer (and Web) market: mobile handsets. Android highlights Google's web properties through its WebKit-based browser and dependent applications. Google acquired Ottawa-based Reqwireless and its mobile web browser in the summer of 2005 to team up with the Android team on its web interface. Web views are an integral part of Android and Google Chrome shares much of Android's code, including its graphics engine.

    Google Chrome and Android both take advantage of the Skia vector graphics library developed by a small company in North Carolina Google acquired in 2005. The Skia team formerly worked on Openwave's popular mobile browser's graphics engine. Google Chrome browser includes Skia graphics engine ports for Windows, Mac, and Linux.

    Google acquired application security company GreenBorder in May 2007. GreenBorder technology automatically sandboxes web code and network traffic by creating a bridge between applications. The GreenBorder technology isolated Internet Explorer or Firefox instances into a "sandbox" inside virtual machine instances. These sandboxes form the code isolation layers of Google Chrome, protecting other tabs and the parent operating system from the code executing on each web page.

    A New Browser from Scratch

    Ben Goodger, Google Chrome's tech lead, is best known for assembling the Firefox web browser out of Mozilla's SeaMonkey application suite. Manticore, Camino, and later Firefox were all attempts in 2001 to rethink the Web browser for the modern age. Browsing took center stage away from a communications suite, user interfaces reimagined for Web efficiency, and (some) legacy cruft tossed to the side. Google hired Ben in 2005 to strengthen its own browser contributions and eventually fully rearchitect a web browser for the modern Web.

    Google hired top Firefox developers in 2005 and 2006 such as Darin Fisher, Pam Greene, and Brian Ryner. In Spring 2006 the team began work on a new browser prototype built on top of WebKit designed for broadband-connected, always-on, web applications such as Gmail or Google Maps. Could the browser experts give web apps some breathing room?

    Modern computers feature multi-core multi-gigahertz CPUs, gigabytes of memory, megabits of bandwidth, and bulky hard drives. Our web browsers should separate browser tabs into their own processes, multi-thread all communications with the operating system, boost cache sizes, and not be afraid to command more bandwidth when available. Internet Explorer 8, Firefox 3.1, and Apple Safari are taking fresh approaches to web browsers for modern machines but Google Chrome has the advantage of a fresh start to achieve some features not currently possible in other browser architectures.

    Features such as tab-isolation and task monitoring are difficult tasks to add inside an existing browser architecture of shared run-times and window models (as John Resig mentioned). Internet Explorer 8's Loosely Coupled IE partially abstracts browser tab instances and the industry is generally headed in this direction.

    Web application-specific resource monitoring should motivate more websites to reduce their browser bloat now that they've been identified. Individual users can also compare web application resource usage directly with their desktop counterparts.

    Rev your JavaScript Engines

    Lars Bak and his team in Århus, Denmark have spent many years writing virtual machines: the run-times that translate programming code into machine code. Lars wrote Sun's Java VM, HotSpot, and later slimmed down the VM for J2ME (CLDC HI project Monty). A few years ago Lars and his team in Denmark began work on a new interpreted JavaScript engine optimized for x86 and ARM architectures.

    The V8 engine is specifically tuned for recursive JavaScript tasks, optimizing commonly used components of your application. V8 is multi-threaded, opening up new parallel processing on multiple computing cores. V8 guesses how you might use your JavaScript code, and backtracks over any faulty assumptions. It's just one of the new engines we'll see inside our web browsers by the end of 2008.

    Google Chrome could have used the same JavaScript interpreter as its WebKit rendering engine (JavaScriptCore, SquirrelFish) but the team had an opportunity, and the funding, to rewrite an interpreter from scratch for desktop and mobile runtimes.

    The V8 engine enables new feature sets for Google's web applications such as Gmail and Google Maps. Web application developers avoid adding features that visibly slow down browsers or cause processing pauses in your application experience. New speed in new areas adds functionality to existing apps. Google programmers should create more efficient code, tested against multiple interpreters, and optimized for modern computers as a result of V8. Even if Google Chrome gains no significant browser market share I still expect it will be the best single-site browser for Google web applications.

    Google Chrome adds additional JavaScript functionality through Gears. Gears is bundled with every Chrome install, adding new features to the web browser faster than previous plugins. The Gears libraries include support for new local cache structures, local databases, location data, background tasks, and file handling. Chrome boosts the available Gears footprint for web developers, including Google's own apps such as Google Reader and Google Docs (and my blog). The current Gears code included in Chrome replicates V8 and sqlite code already present in the browser, a bolt-on that will hopefully be integrated in the near future.

    Chrome, V8, and Gears will be a new testing ground for Google's HTML5 efforts, winning a new seat at the table as an implementor with upstream standards groups such as W3C.

    Meet the Team

    Google Chrome team leads

    I am tracking at least 20 people involved in the Google Chrome project across Google. I'm sure Chromium commit logs will reveal even more (update: more complete list here), but below is a quick summary of Chrome staff.

    Brian Rakowski, Lead Product Manager
    Brian was Google's first associate product manager in 2002, assigned to Gmail. He later worked on the Google Browser Sync Firefox plugin.
    Ben Goodger, Software Engineer
    Ben is the former Firefox 1.0 project lead. He also authored the Firefox extensions system. He joined Google as 2005.
    Mike Pinkerton, Technical Lead
    Mike is one of the Google team members responsible for bringing Chrome to the Mac. Mike worked at Netscape and later on the Gecko-powered AOL client before co-founding the Camino project. Mike joined Google in September 2005 and continues to lead Camino development.
    Darin Fisher, Software Engineer
    Darin was a frequent contributor to the Firefox codebase. He specialized in network libraries, cookies and permissions, and the Netscape Portable Runtime. Darin joined Google in 2005.
    Lars Bak, Software Engineer, V8
    Lars was the core developer on Java HotSpot VM and Monty VM in J2ME for Sun. He co-founded object-oriented VM companies for embedded devices before joining Google. Lars worked on V8 from a farm in Århus, Denmark before moving the team to university offices.
    Kasper Lund, Software Engineer, V8
    Kasper shares a long history with Lars Bak working on virtual machines.
    Brian Ryner, Software Engineer
    Brian is a former contributor to Firefox where he added mousewheel support, tweaked the Gecko rendering engine core, password management, and Linux installers.
    Pam Greene, Software Engineer
    Pam is a long time Firefox contributor. She added OpenSearch to the browser and contributed to full-text search in Places/AwesomeBar.
    Ian Fette, Product Manager
    Ian is a former Firefox contributor who worked on anti-phishing, anti-malware, spelling correction, and the Safe Browsing API.
    Arnaud Weber, Software Engineer
    Arnaud is a former Director of Research and Development at Netscape and Borland before joining Google to work on a "secret project" in September 2006.
    Brett Wilson, Software Engineer
    Brett formerly worked on the Google Toolbar. He contributed to Firefox history and bookmarks functionality.
    Mike Belshe, Software Engineer
    Mike helped write an Outlook add-on called Chrome for Lookout Software before being acquired by Microsoft. Mike also formerly worked at Netscape and Good Technology.
    Huan Ren, Software Engineer
    Huan works on network flow control, negotiating browser interactions with network resources. Huan formerly worked at Microsoft.
    Erik Kay, Software Engineer
    Erik formerly worked on the AvantGo browser, Qurb anti-spam software for Outlook and Outlook Express.
    Glen Murphy, Software Engineer
    Glen specializes in user interface design. He previously worked on user interface. Firefox extensions. Google Browser Sync, Google Blog Search
    Evan Martin, Software Engineer
    Evan writes automated testing tools for Chrome and the Web.
    John Abd-El-Malek, Software Engineer
    John is part of the Windows specialist team at Google bringing Google Desktop, Google Talk , and Breakpad onto Windows XP and Windows Vista.
    Amanda Walker, Software Engineer
    Amanda is one of the people responsible for Chrome's upcoming Mac version.
    Mark Mentovai, Software Engineer
    Mark was heavily involved in moving Firefox for Mac to its current Intel-based architecture. He has worked on the Breakpad project and many levels of Chrome's code.
    Carlos Pizano, Software Engineer
    Carlos formerly worked on GreenBorder and continues to work on Chrome sandboxing.
    Mark Larson, Program Manager
    Mark is also formerly of GreenBorder and its sandboxing specialties.
    Aaron Boodman, Software Engineer, Gears
    Aaron improves user experience with JavaScript. He's best known for his work on Gmail, Greasemonkey, and Gears.

    Summary

    Google Chrome logo Google's business depends on the speed and availability of Web access to search, advertising, and applications. Chrome is Google's second attempt to better control the front-door to its content with full applications optimized for its heavy apps. Google Chrome builds on top of the work of Android by adding individual applications to already popular operating systems. Google has flirted with the idea of its own web browser for many years but has only recently released working implementations of its own full browser applications.

    Android, Chrome, and Gears will continue to grow in unison and extend individual pieces into established operating systems. Google is building a new suite of application extraction layers that should have strong leverage across Windows, Mac, and Linux to directly control the company's destiny on these platforms.

    It's an exciting time for new browser technologies as Internet Explorer, Firefox, and WebKit each compete over standards implementations and performance. Officially adding Google Chrome to the browser space only strengthens Google's position strengthening the future web and delivers strong single site browsing experiences for their core web applications.

  6. Aug28

    Internet Explorer 8 Search Suggestions

    Microsoft released a second beta of its upcoming Internet Explorer 8 browser yesterday afternoon. The new browser will reach full release by the end of the year, changing the way most Windows users view the Web. There are many new features of IE 8 for web developers, including completely new ways to light up the browser chrome. Microsoft has extended the OpenSearch protocol with a new search suggestions data formats expressed XML or JSON. The new format will display real-time search results, summaries, images, and even search result classifications inside the browser chrome for any site owner supplying the appropriate format. In this post I'll teach you how to add search suggestions to your OpenSearch description document for instant search suggestions in IE8.

    1. Search Suggestions
    2. Suggestions Format
      1. Quick element definitions
    3. Summary
    IE8 instant search Wikipedia

    Internet Explorer's Instant Search provides suggestions based on text already entered into the search box. The functionality is very similar to Google Suggest and its JavaScript feed expanded for multiple categories, graphics, and short descriptions.

    The new format covers search suggestions and not necessarily search results. Syndicated search results should continue to be exposed as a Url element of attribute type of Atom or RSS.

    Search suggestion data files are exposed through a new MIME type referenced in a OpenSearch descriptor's Url element: application/x-suggestions+xml.

    <Url type="application/x-suggestions+xml" template="http://example.org/suggest?q={searchTerms}" />

    Suggestions URLs should follow the same fill-in-the-blank parameters defined by OpenSearch such as result count or language scope.

    Suggestions Format

    How do you make your site light up with pretty pictures in the search box? Just add XML descriptors of possible intended searches.

    <?xml version="1.0"?>
    <SearchSuggestion>
      <Query>ajax</Query>
      <Section>
        <Separator title="Web Development"/>
        <Item>
          <Text>AJAX Developer Center</Text>
          <Description>Asynchronous JavaScript and XML</Description>
          <Url>http://developer.mozilla.org/En/AJAX</Url>
          <Image source="http://example.org/ajax.jpg" alt="AJAX Web Development"
                 height="50" width="50" align="middle"/>
        </Item>
        <Separator title="Soccer"/>
        <Item>
          <Text>AFC Ajax</Text>
          <Description>Amsterdamsche Football Club Ajax</Description>
          <Url>http://english.ajax.nl/</Url>
          <Image source="http://example.org/afcajax.jpg" alt="AFC Ajax"
                 height="50" width="50" align="middle"/>
        </Item>
        ...
      </Section>
    </SearchSuggestion>
    

    In the example above I provided search suggestions broken into two sections with Separators: web development and soccer. Each section has a list of Items defining title text, a short summary, and a related image.

    Internet Explorer 8 also supports results in JSON format if you prefer.

    Quick element definitions

    Separator
    A distinct grouping of your search result set. Correlates well with site categories.
    Item
    An individual result wrapper.
    Text
    Your result title. Internet Explorer will highlight text in your result title matching the text entered in the search box.
    Description
    A short summary of the search result. Similar to a HTML meta description or search result snippets.
    Image
    An image you would like to display alongside the search result. Internet Explorer 8 will pass along height and widths in the drop-down configuration -- max width, row height, and section height -- if you setup a few extra parameters in your OpenSearch description. The image should be relatively small to fit alongside a search result title and description (~75px).

    Summary

    Internet Explorer 8 opens up more of the browser chrome to user search customizations including instant search suggestions. Webmasters can enhance their search results for supporting web browsers with suggested terms or results served directly within prime browser real estate. Images, highlighted text, and short summary will help your results stand out and should drive increased search usage by loyal customers.

    Google crawls web forms and I expect their search team will look for signals described on the page such as OpenSearch or site suggest to make an educated guess about the best ways to probe your site for deep results. Adding search suggest markups to your site could also help machines discover deeper content within your site among popular keywords.

    Internet Explorer 8 just released beta 2 and these features are not frozen. Search suggestion XML are a good feature to track for sites with deep content and engaged users.

  7. Jan29

    Data interchange for the social web

    Data portability is only useful if outside systems can comprehend the exported data. Well-described and interoperable data sets open new possibilities for context-aware social applications, importing your friends, photos, or genetic markup from an existing system into your current tool of choice. In this post I will discuss website best practices for exporting portable, descriptive data sets in the name of data portability. This post builds upon user authorization concepts covered in my last post.

    Expressing data between two unrelated systems is difficult at best. You need a shared set of vocabulary to explain even the basic data points (time, person, etc.). Good data exports will want to represent as much data as possible with the least probable data loss.

    Voyager golden record cover

    NASA launched the Voyager 1 spacecraft into space in September 1977 with a set of golden records onboard. These records communicate small pieces of human knowledge to any intelligent life that may discover our small explorer. The graphic above is humanity's attempt at data interoperability, teaching alien explorers the proper positioning of an included stylus over a record rotating once every 3.6 seconds (time is expressed as the fundamental transition of the hydrogen atom). Thankfully web developers do not have to worry about interoperability with so many unknown measures, but your data could just as easily lost and never played back for other worlds to hear.

    Identify exportable data

    The first step in data export is identifying the unique pieces of information you would like to package and ship outside your walls. What information might be useful to a user seeking to backup or otherwise export his or her data? How would you like to import such data back into your own website?

    Google Mail message listing sample

    Pictured above is a list of messages stored in Gmail. One message is part of a continuing conversation or thread, another message is flagged, and two messages have custom labels. A typical e-mail system might just export a list of raw messages but could possibly lose key data such as a flagged state or labels/tags.

    Research existing data standards

    Data interoperability is not a new concept and your current challenges may be easily solved by existing certified and de-facto standards. Standards increase the chances your data will be consumed, processed, and understood by others. You could invent an entirely new dialect and vocabulary to describe your information but you will be much more successful at disseminating data if you are easily interpreted.

    Standards organizations have spent years analyzing the essential elements and interoperability requirements of many common forms of data. Below are just a few standard data formats for elements of the social web.

    People, Places, and Things
    vCard
    xNAL
    KML
    LDAP
    Events
    iCalendar
    News articles
    Atom Syndication Format
    News Industry Text Format
    Human DNA
    NCBI homo sapien genome build 36.2, FASTA.

    Each data markup has a specific set of required data intended for a specific audience or interpreter. Google Maps prefers a feed of business listings and locations in xNAL while Google Earth prefers KML for example. Bloggers output news articles in Atom for consumption by a specific set of tools, while mainstream publications mark up their stories in a news industry format for increased granularity. Some formats may not be applicable if your product does not store all the required types of data (i.e. you know their name but not their hometown). Your company will need to select a target output format based on expected external use and how your information might map onto a format's required elements.

    Extend where appropriate

    Each format supports extended namespaces for custom data not covered by the base vocabulary. A member's favorite food or soccer club is not an essential component of an international standards body but can easily be extended with your own custom namespace where appropriate.

    The same rules of data loss apply to custom namespaces: custom definitions are more likely to be missed while common namespaces are more easily understood. Extended namespaces may already be in active use by a big company or a coalition, increasing your chances of data visibility. An AOL Instant Messenger screenname is defined as "X-AIM" in a vCard context for example, where the X- represents an extension element.

    Summary

    Data portability and interoperability on the social web continues to be a hot topic. While there are PR benefits for first-movers I expect there will not be widespread adoption until portable data has a remote consumer. Startups with limited resources will need to see a possible consuming service for their exported data before carving out part of their product cycle for the new feature. I think data portability is a great project for this summer's interns, providing deep exposure to data complexity and the industry as a whole while balancing proper authenication and privacy concerns.

  8. Jan21

    Data Portability, Authentication, and Authorization

    The social web is booming, signing up new users and generating new pieces of unique content at a steady clip. A recurring theme of the social web is "data portability," the ability to change providers without leaving behind accumulated contacts and content. Most nodes of the social web agree data portability is a good thing, but the exact process of authentication, authorization, and transport of a given user and his or her data is still up in the air. In this post I will take a deeper look at the current best practices of the social Web from the point of view of its major data hubs. We will take a detailed look at the right and wrong ways to request user data from social hubs large and small, and outline some action items for developers and business people interested in data portability and interoperability done right.

    General issues

    Friends, photographs, and other objects of meaning are essential parts of the social web. We're much more inclined to physically move from one city to the next if our friends, furniture, and clothes come along with us. The interconnectedness of the digitized social web makes the moving process much simpler: we can lift friends from one location into another, clone your digital photographs, and match your blog or diary entries to the structure of your new social home. Each of these digital movers represent what we generally call "social network portability" or, more generically, "data portability."

    Social networks accelerate interactions and your general sense of happiness in your new home through automated pieces of software designed to help you move data, or simply mine its content, from some of the most popular sites and services on the Web. These access paths are roughly equivalent to a new physical location setting up easy transit routes between some of the largest cities to help fuel new growth.

    Facebook Friend Finder e-mail import

    Your e-mail inbox is currently the most popular way to construct social context in an entirely new location. Site such as Facebook request your login credentials for a large online hub such as Google, Yahoo!, or Microsoft to impersonate you on each network and read all data which may be relevant to the social network such as a list of e-mail correspondents. Every day social network users hand over working user names and passwords for other websites and hope the new service does the right thing with such sensitive information. Trusted brands don't like external sites collecting sensitive login information from their users and want to prevent a repeat of the phishing scams faced by PayPal and others. There is a better way to request sensitive data on behalf of a user, limited to a specific task, and with established forms of trust and identity.

    1. Use the front door
    2. Identify yourself
    3. State your intentions
    4. Provide secure transport

    Use the front door

    Google, Yahoo!, and Microsoft all support web-based authentication by third parties requesting data on behalf of an active user. The Google Authentication Proxy interface (AuthSub), Yahoo! Browser-Based Authentication, and Microsoft's Windows Live ID Web Authentication issue a security token to third-party requesters once a user has approved data access. This token can allow one-time or repeated access and is the preferred method of interaction for today's large data hubs. The OAuth project is a similar concept to web-based third-party authentication systems of the large Internet portals, and may be a common form of third-party access in the future.

    Google Accounts Access example

    Supporting websites provide limited account access to a registered entity after receiving authorization from a specific user. The user can typically view a list of previously authorized third parties and revoke access at any time. The third-party retains access to a particular account even after the user changes his or her password.

    Imagine if you could give your local grocery store access to just your kitchen, but not hand over the keys to your entire house. A delivery person would be automatically scanned upon arrival, compared against a registry, and granted access to the kitchen if yo previously assigned them access. You could revoke their access to your kitchen at any time, but they never have access to your jewelry box or other non-essential functions within your house.

    Identify yourself

    Third-party applications requesting access should first register with the target service for accurate identification and tracking. Applications receive an identification key for future communications connected to a base set of permissions required to accomplish your task (e.g. read only or read/write). A registered application can complete a few extra steps for added user trust and less user-facing warning messages.

    State your intentions

    Your application or web service should focus on a specific task such as retrieving a list of contacts from an online address book. Your authentication requests should specify this scope and required permissions (e.g. read only) when you request a user's permission to access his or her data.

    Google services with Gmail highlighted

    An application declaring scope lets users know you are only interested in a single scan of their e-mail and you will not have access to their credit card preferences, stored home address, or the ability to send e-mails from their account. Not requesting full account access in the form of a username and a password creates better trust from the user and the user's existing service(s).

    Provide secure transport

    Armored Truck How will you transport my user's data back to your servers? Did you bring an armored car with your company's logo prominently displayed on the side or will my data sit in the back of your borrowed pick-up truck? Requesting applications should transport user data over secure communications channels to prevent eavesdropping and forged messages. Registered and verified secured communications will result in less user-facing warning messages of mistrust, and secure certificates are relatively inexpensive. Large portals such as Google or Microsoft will bump your communications (and privileges) to mutual authentication if you are capable.

    Twitter SSL certificate Firefox view

    Register an SSL/TLS certificate for your website to enable secure transport and further identify yourself. Certificates vary in cost and complexity from a free self-signed cert to paid certificates from a major provider with extended validation and server-gated cryptography. Google and Yahoo! use 256-bit keys. Windows Live and Facebook use 128-bit keys.

    Summary

    Data authorization is the first step in data portability. Emerging standards such as OAuth combined with established access methods from Internet giants provide specialized access for third-parties acting on behalf of another user. Sites interested in importing data from other services should take note of these best practices and prepare their services for intelligent interchange.

  9. Aug03

    JavaScript Map API comparison

    Mapping APIs are some of the most popular data services on the web today. If you've ever visited a restaurant website, taken your car in for service or browsed a mash-up you've probably come across interactive and static map images powered by Google, Yahoo, Microsoft, or AOL. In this post I'll compare performance and developer friendliness of JavaScript mapping APIs and dissect choices made by each platform that may affect your website.

    Maps API comparison

    I chose my office location in San Francisco's South Park district as a basis of comparison. The area has large buildings, small alleys, one-way streets, and newly constructed roads and bridges. Each map is a 400-pixel square centered on my office using lat/long coordinates and marked with each service's default marker. I specified a small zoom control and no marker events for quick and minimal interaction across platforms. This simple test is my attempt to recreate what a flower shop, mechanic, or other business might place on their website to help visitors add context to an address.

    Performance

    Every time you add a widget or other external feature to your website you are handing over part of your web page experience and performance to a third party. The responsiveness and total page load of these external services is one way obsessive geeks tune and tweak their sites for optimal performance. Let's take a look at how the major mapping players performed.

    Map API performance
    ProviderRender (s)Size (KB)FilesMemory (MB)
    Yahoo!3.052072413.43
    Google3.182232719.8
    Microsoft3.652362013.9

    Yahoo! offered the fastest performance, the smallest total download, and the smallest memory footprint in my tests. Microsoft's maps took a half-second longer to download and display than either of its competitors. Google had the highest total file count due to its mapping tile behavior.

    Measurement Method

    Map API performance was measured using Mozilla Firefox and Firebug network monitoring using a first-generation Apple MacBook Pro connected to the Internet over cafe Wi-Fi in San Francisco. I restarted Firefox for each of the three performance tests and requested each service with a clean cache.

    Closer look

    If you take a closer look at each of the APIs the performance impacts and general API design begin make a lot more sense. Increasing your domain count allows more parallel downloads but will also require a new DNS lookup for each new domain.

    Google Maps API 2.84

    Google served its 27 files from six separate domains. Google placed 16 map files in my browser, covering a 4096 pixel square to deliver my 400 pixel square window, or 10 times the total requested area. If a site visitor clicks and drags your map they will not have to load another tile as they explore the immediate vicinity.

    Yahoo! Maps API 3.7

    Yahoo! Maps utilize the YUI JavaScript library to interact with the page and handle new events. They are using old beta versions of YUI 2.0 libraries DOM, Event, Drag and Drop, and Animation.

    Yahoo! served files from 4 domains including 9 map tiles. Yahoo! adds a map scale to each page, adding a few more images and functions to your total page load.

    Windows Live Local Search Maps Virtual Earth API 5.0

    Microsoft uses its ASP.net Ajax ("Atlas") JavaScript libraries inside of your map view. The Virtual Earth API adds files and features you never asked for such as CSS files for traffic conditions and extra images typically used in its Dashboard interface.

    Microsoft rendered its map using only 6 tiles covering a 1500 pixel square, or about 4 times the requested map window.

    Quick notes

    My mapping test was a quick experiment to measure the strengths and weaknesses of various developer platforms and services. You can view my full test suite and alter each comparison for your own needs.

    All of the mapping API providers offered similar street data but differentiated itself with add-ons and overlays.

    Best developer site
    Virtual Earth Interactive SDK

    Microsoft's Virtual Earth Interactive SDK was the best-designed site for new map developers. I was able to easily browse examples, view each example on a live map, view source code, and dive deeper into each method's full documentation when needed. Microsoft helps upgraders quickly figure out what's new with a special call-out at the bottom of their dashboard.

    Best use of color
    Yahoo! Maps include color-coded neighborhoods, green parks, and dark blue water. The bright red freeways draw attention away from my points of interest. Yahoo! color-codes some building outlines but it's unclear how someone might decipher a pink office building or orange hotel.
    Best buildings
    ATT Park Virtual Earth

    Microsoft provided the best identification of major buildings in my tests. Their map showed the outline AT&T Park, a baseball stadium home to the San Francisco Giants, and not just the plot of land.

    Best map design
    I prefer Google's map markers over the talk bubbles, pushpins, kites, and stars used by other services. Google's placement and size of street names was the easiest to read in my tests. Street names are repeated every few blocks so you're never too far away from the proper context.

    I tried the MapQuest Open API beta but found the documentation and learning process extremely frustrating. The MapQuest API provided no live drag events in my testing and seemed to prefer surrounding your map in a colored navigation frame and web form. MapQuest may be the current mapping leader, but its API is far behind the large web portals.

    I like the ideals behind the OpenStreetMap but its United States coverage is almost non-existant.

    Summary

    Google Maps continues to dominate the mapping API space but there are some viable alternatives. Yahoo! and Microsoft may have an advantage bundling maps and other APIs with their freely available JavaScript, Flash, and Silverlight libraries and frameworks while Google adds advanced features such as street-level views and Google Gadget info windows.

    I'm glad big Internet portals are spending millions of dollars for online mapping supremacy I can easily integrate in my web applications. The mapping API space changes at least once every 6 months but I am still satisfied with my choice of Google Maps on Startup Search.

  10. Apr23

    Podcast: Taking Ajax offline

    Rich Internet applications are stepping out of the web browser and onto the desktop, helped along by a new set of toolkits. Web developers are able to code against desktop resources using familiar languages and toolkits such as JavaScript, Ruby on Rails, or HTTP interactions. Offline access for web applications is about much more than planes, trains, and automobiles -- it can accelerate performance and integrate with established desktop interactions as well.

    Offline web applications are a hot topic, but often misunderstood. In this week's podcast I step beyond the myths of offline web applications with special guest Brad Neuberg. Brad has spent years digging into reliable storage methods available within a browser environment, and most recently developed the Dojo Offline Toolkit for complete offline access. You can directly download the Offline Web Applications podcast or head on over to the podcast blog post to read more about discussed topics.

    Beyond disconnect

    Offline web application capabilities are about more than a missing Internet connection. Application data is stored on a local hard drive instead of a far away datacenter, boosting your load times. Web applications become searchable components of the local operating system, displayed inside a Windows Vista Search result or Mac OS X Spotlight. Your application data might become fully integrated with desktop calendar, address book, or web feed platforms, exposed to any requesting application including mobile phone synchronization or personal backups.

    Summary

    The offline web application space is a hot topic of discussion which may or may not apply to your product. Is offline access a graceful enhancement on top of your existing application? Are customers clamoring for it? Will you take your application offline using Adobe Apollo, Firefox 3, Joyent Slingshot, XULRunner, or Zimbra Offline? Those are just a few of the toolkits we know about this month, yet more are coming.

    It's time to demystify. I hope you enjoy my podcast with Brad Neuberg, one of the experts in the space of offline access for web applications, as a quick way to get your head around some of these larger issues in the future of web application development.

Niall Kennedy Niall Kennedy is a web technologist in San Francisco, California in the United States. I am very interested in the world of... MORE »

Search this weblog:

Subscribe:

Recently Popular

Archives: Popular Categories

Sites: More from Niall