This is big. 80 million users play Farmville, on average, a month on Facebook. 28M for Poker. 23M for Mafia Wars. These users bring their friends and family along to build and tend virtual farms, whack mob bosses, and perfect their poker face. Zynga and Yahoo! both will actively promote their latest games on Yahoo!’s canvases, and Yahoo! in turn will build extensive hooks for all developers (ALL developers) to re-engage their users post-install.

Additionally, we’ll be working to expose new engagement channels to drive repeat usage of Apps in a way Yahoo! never did before: navigational links to a user’s favorite Apps and persistent requests on every page of our network. New places to play Zynga (and other) games. A far richer social graph than users have today.

My team, and the larger Yahoo! family, have been and continue to work around the clock to make lots of new opportunities open up for all 3rd-party developers. You can read more on my YDN post about the developer-facing components, as well as the TechCrunch scoop on the deal. It’s exciting to be able to share the news.

All they heard was whining and how you couldn’t do anything modern with Web-based Apps. Too slow. No offline access. Not enough system-level controls/hooks.

So, they hunkered down, doubled back, and made the premiere “closed” App ecosystem. Sold like hotcakes. Got mobile curmudgeons to start thinking about mobile-dominant futures. Got 10-year-olds excited about programming. Made individual developers’ works available to the world with only a $99 budget.

And they’re now hated for not being “open.”

I’m not going to defend Apple, or get into whether Android is better because of it’s open nature. (I will say it looks like a rosy future for Android, though.) Me? I love Apple hardware and software (and their somewhat-open ecosystem), but am deeply troubled by their mobile ecosystem’s closed marketplace (in other words, not the store itself, but simply that I can’t side load software onto devices I own outright without Apple blessing it first).

So troubled that I’d get rid of my iPhone and iPad? Absolutely not. So zealous that I won’t consider Android? Nope, already have one, and will be an excited early adopter of Google TV.

The “open” argument will win against iPhone only as soon as Android marketshare and dollars start hurting Apple. I doubt Steve Jobs will spend much time listening to his critics a second time until then.

I intentionally list developers first, as I strongly believe developer-friendly products encourage significant innovation on top of Web products… which, in turn, greatly benefit everyone else (who get features and support for niches that no product could conceivably support on its own).

I am happy to announce, after significant time and effort from a great crew of present (and past) talent at Yahoo!, we now support Apps built by 3rd-party developers (i.e. people who don’t work for Yahoo!) on the Yahoo! Homepage. What this means is you can now add just about any type of content and functionality to the Web’s most popular starting experience.

More than a dozen of these Apps can be found right now by clicking the “+ Add” link next to “My Favorites” on Yahoo.com. From managing your money with recently-acquired-by-Intuit Mint.com, to checking out the weekly ads for Target stores, to puzzle-solving games with Flood-It!: there is an App to suit your interests.

Disagree? Get started building one today… there’s no fees (although you can make money inside your App as you like), no complex SDK (write your code the way you prefer on your server), and no obtuse App Store approval process (instantly share your App with millions and/or promote it using Yahoo!’s in-product App galleries).

To do this, the Yahoo! Developer Network lets you:

• learn more about YAP (our App development platform),
• get up and building an App, and
• create/manage your Apps.

Let me know your experience with these Open Apps on Yahoo.com… I’m excited to see my team’s work see such a large online audience, but I’m also equally exciting about adding even more support and features for developers soon.

Update: TechCrunch has just covered the release of the Mint.com App (and others) on Yahoo.com.

The App’s visual representation of the buildings are handled by beautifully-rendered illustrations (by Kalani Kordus) rather than over top of a Google map. This affords an ability to see each level of each building and highlight only elements of importance (conference rooms, not janitors’ closets).

The App, however, is missing some very important information. It doesn’t know -where- these important elements are. And because it doesn’t know that, it can’t know where I am in relationship to the rooms.

To know where such things exist, a location data store (describing lat/long locations of every object’s borders) must exist. The problem is, how do you get the very data that has, to date, been hard to come by? How can Apps get access to location data which isn’t in Google Maps already but is relevant to a group of people? In other words, how do we move from just understanding objective data (such as “Golden Gate Park” or “701 1st AVE, Sunnyvale, CA 94089″) to something more subjective (such as “de Young museum lawn” or “Yahoo! 1st floor bathroom”)?

I think the answer is somewhat simple: build a mobile App and a website to leverage those same people who’d be interested in the data in the first place. As they have a vested interest in the service, these users could accomplish tasks fed to this App by the developer looking to harvest and use the data.

To do this, the App would need to do several things:

1. Sign In/Register. Not because users love making new accounts, but rather because the system will need to support private projects and online storage.

2. Location capture. Lat/long coordinates WITH WiFi base station MAC address. Also any info from gyroscope and compass, if possible. (Could be useful if you’re wanting to plot where the door to a room is, or indicate direction.)

3. Metadata capture. User-added tags, notes, photos, videos, audio, etc. (Optional, but could feed the developer useful materials.)

4. Project selection. Choose a community project (whether public or private) based on current location and/or user account; or, choose a personal project.

5. Settings. Assuming most users will be submitting several locations towards the same goal, the App must facilitate rapid entry where it’s default is to use the last-used project, tags, etc. (Maybe the App should set a distance threshold, so that if a user captures a location 6 miles away from the previous location, the App assumes a new project?)

6. Submission queue. Connectivity could fail at any point; hold onto any captures that haven’t yet been submitted.

Additionally, this App will need a Web front-end (where developers can post projects, determine whether anyone or just a select few can participate, review results, modify entries, get access to the data via data dumps (i.e. CSV, XML, etc.) or data feeds (i.e. An API), and highlight their most prolific/helpful contributors. Assumedly users should be able to access the site, too, to modify their submissions, see the results of their participation, and sign up for projects not yet tackled.

The value of such an App would seem to be immense to anyone building location-aware Apps whose locations aren’t covered (or applicable) on Google Maps and other traditional mapping/location services. Developers could offer successful contributors money ala Mechanical Turk, a free copy of their App, or just recognition of who helped out.

There’s already been numerous successful user-submitted tagging enterprises to-date. Why not one for location, where the user doesn’t even need to learn lat/long coordinates, machine tags, or anything technical? Instead, all they need is the desire to help, an iPhone/Android phone, and the ability to press a button when at a location a developer requests.

Sounds possible. The question is: who wants to help build it?

• Read the profile of your user (photo, nickname, real name, age, sex, location, work and education history, and interests),
• Read your user’s list of friends/connections,
• Read/Write your user’s status message,
• Read your user’s list of Updates (i.e. their activities from Yahoo! and the rest of the Web),
• Write your user’s activities from inside your app into her Updates stream,
• Query, filter, and join any data from Yahoo! and other Web services via YQL, and
• Broker your user’s permission to access this information using OAuth.

What does all this mean? It’s simple. An app using this SDK can pull in my Yahoo! profile information, plot me and my friends on a map (grabbing the locations stored in our profiles), compare our listening preferences (grabbing our favorite music preferences), and broadcast my activity (i.e. “Micah just posted a new high score of 18,478 in Bejeweled 2“) which, in turn, drives my friends (and more) to your app.

You can learn more at YDN (as well as find all the documentation).

And, if you build anything interesting using the code, please let me know… we’re always interested in showcasing great developer-built solutions (using Yahoo! technology) on the YDN blog. Even better, come out and join in at the iPhone Dev Camp Yahoo! is hosting July 31 – August 2, 2009.

With this approach in mind, I’d like to propose a solution that fits within this vein: a standardized means for publishers (i.e. anyone producing Web content) to expose their Application offerings to users.

Applications are all the rage now. Facebook kicked off the trend, Apple came in with killer iPhone Apps, and Yahoo!, Google, MySpace, and others all have App offerings, too. As such, many publishers have Apps in many flavors (i.e. platforms), but may not actively promote them around their site. Or, if they do, they don’t all consistently feature and talk about Apps in a manner that helps users know where to go to find out if their favorite site offers an App.

This problem, though, isn’t unique to Apps. It was a similar problem for RSS feeds when they emerged several years back. And the solution proposed then (and since implemented) would seem to work equally well for Apps: provide an autodiscovery tag for Apps in an HTML document’s head element. Once folks begin adding App Autodiscovery tags to their pages, browser makers (such as Firefox, WebKit, Opera, Internet Explorer, and others) and other software vendors (such as Yahoo! Toolbar, Apple’s iPhone version of Safari, etc.) can look at how they’d like to visualize such information (if at all). (This type of solution has been extended to content other than RSS, such as FOAF and Sitemaps.)

An example of how App Autodiscovery tags could be visualized in a browser.

Why do this? There are a number of reasons:

• A common standard for App autodiscovery will allow browser and software vendors to develop innovative means of exposing related App content;
• App Autodiscovery won’t negatively impact users or browsers that don’t understand the tag; it will just be ignored.
• App Autodiscovery is easy to integrate;

To prove the last point, the code for such an effort is simple:

<link rel="alternate" type="app/facebook" title="The New York Times News Quiz" href="http://apps.facebook.com/nytquiz" />

The type attribute could be populated with any series of attribute values (which would need to become normalized and approved MIME types), such as:

• app/opensocial
• app/facebook
• app/yap
• app/iphone

Additional title and href values would define the App’s unique name and location, which could tell a user where to use/install the Application in the appropriate App platform.

So, with this thinking in place, App Autodiscovery code could begin to be integrated into sites today in the following fashion (using my friend and colleague Matt Lock’s App: Minsa):


<html>
  <head>
   <title>...</title>
   <link rel="alternate" type="app/yap"
    title="Minsa"
    href="http://apps.yahoo.com/-6lOOCT7a" />
  </head>
  <body>
   <!-- the web page's contents -->
  </body>
</html>


Adding this one line of code (per app per platform) within your website’s head element can make relevant App discovery much easier for people in the places they already have an interest (i.e. the places they visit). What do others think? Let me know if you know of alternate/better solutions to address this issue.

* For those unsure of what I’m referring to, the Semantic Web is an effort to provide structure and additional information around content on the Web. Why? Because most content on the Web is understandable to its readers, but not to computers. As such, you can discern that an article online is talking about an event (like a concert at a certain place at a certain time), but your calendar software can’t recognize it as such. Therefore, you need to manually “rebuild” such event info in your calendar, which breaks its relationship to the online article; if the article was updated, you wouldn’t know, and your calendar would be out of date. These disconnects happen all over the Web today, but could be significantly reduced via concerted efforts by publishers to enhance their Web content with semantic markup (which in turn would open their content up to many inventive possibilities that are today exceedingly difficult).

For more information about the Semantic Web, check out the W3C’s efforts (as well as the community-driven Microformats efforts) to see how content on today’s Web pages can be enhanced to support this model.

Or so my theory goes.

Why is that? Apple dropped the Apple TV on consumers in January 2007 as a “hobby.” Since then, it has released several software updates, including a major on-demand kiosk service this past January.

Also during that time, Apple has released two versions of the iPhone, one of its biggest mainstream successes to date. Unlike the Apple TV, though, Apple provided iPhone users with an App Store: a means of extending the device with 3rd-party-developed Apps.

These Apps are developed somewhat differently than those for the Mac desktop. Namely, rather than the keyboard and mouse standards of yore, they are tuned to leverage the device’s alternate input mechanisms (multi-touch display, limited visible real estate, accelerometer, gyroscope, location-aware GPS/WiFi, Bluetooth, camera, and cellular connection) and alternate environments (indoors/outdoors, small physical screen, one-handed interaction, noisy surroundings, varied lighting, etc.).

Because of this shift in development, Apps developed for the iPhone (in my argument) are more in line with Apps that would be useful for the Apple TV (and not desktop Apps). The Apple TV currently ships with an Apple remote control that took some cues from the iPod: it has a 4-direction clickwheel and two buttons (Play and Menu). This limited set of possible interactions generally works well for the TV, but would work terribly for desktop Apps (where users are used to multiple inputs: 104-plus keys on a keyboard and a dual-click, scroll-wheel mouse). Anyone, in fact, who’s had to enter their 32-character WiFi password on the Apple TV unit using the directional clicker and Play button knows such interaction is painful; what is easy on the computer desktop is very difficult six feet away from the screen with limited input controls.

Apple clearly knows this.

To date, Apple’s software updates have added very few Apps to the Apple TV. Those they do provide are primarily restricted to “browsing” functions (i.e. tasks that involve simple directional scrolling and a couple clicks). Aside from browsing/playing video content, you can browse/play music, photos, and podcasts. In the few cases where the user needs to do more than browse or play, “keyboard entry” is limited to activities such as entering search terms for podcasts or supplying a username and password. Why? Because moving across a virtual, on-screen keyboard one click at a time with the Apple remote is time-consuming, painful, and so not “Apple-like.”

However, Apple has begun to tie the iPhone and Apple TV together already to simplify such a complex interaction. By releasing the “Remote” Application on the iTunes App Store at launch, Apple now provides Apple TV users an alternate means of accessing a virtual keyboard: rather than click with the Apple Remote, users can instead access the iPhone’s virtual keyboard (far from perfect, but light years better than the Apple TV’s beast). Aside from just keyboard entry, the “Remote” App also provides alternate menu access to controlling the selection and playback of video and audio content on the TV.

With one tiny App, Apple unveiled a powerful connection between the two non-Mac devices. Suddenly, users have two devices that stand tall on their own, but, by joining together, add up to be greater than their sum. The result? Giant, hi-def HDTVs as the display; Web-connected computer capable of handling concurrent App tasks and video signal decoding; a remote that has a multi-touch display, accelerometer, gyroscope, camera, and cellular connection; and (maybe most importantly) a compact format that fits well in a home living room entertainment center.

Because of this possibility, I would predict Apple begins to do 2 things:

1. allow developers to create rich, Internet-connected, iPhone-controllable Apps for the Apple TV using an extension of the iPhone SDK, and
2. distribute Apps to the Apple TV using the iPhone App Store (potentially with a filter for TV-only Apps).

So, aside from creating a cool home entertainment hydra, why would Apple enable the iPhone SDK for development of Apple TV Applications? I would posit several reasons:

• Name:
  I’ll lead with my weakest argument: the iTunes App Store is called the iTunes App Store, not the iPhone App Store. This would seem to suggest Apple is keeping the door open to distribute Apps to platforms beyond the iPhone and iPod Touch.
• Greed:
  $30 million was earned in the first month of the App Store’s release, with $70 million more the following month. Six million total Apple TV units are predicted to be in homes by end of 2008 compared to the 12 million iPhones in the market now. This would suggest a theoretical $25 million/month for the yet-to-be-supported Apple TV unit. Do I think that’s unrealistic? Sure. But even 1/10th of that figure would suggest an attractive revenue stream.
• Development Environment:
  Both Mac and iPhone development use Apple’s Xcode. And while the iPhone uses it’s own OS, the Apple TV uses a customized OS X. Apple TV App development could leverage UI controls and the simplified focus of the iPhone while having access to OS X’s amazing developer palette.
• Patent Mining:
  Apple filed a patent two years ago suggesting some big changes to the product: the Apple TV as a lightweight widget/application platform. The thinking therein appears to suggest that app-like widgets could enhance a user’s viewing experience (whether by facilitating live chat with other viewers, providing contextual information against the current feature ala VH1′s Popup Video, etc.), and describes a number of possible widgets: Weather, Stocks, World Clock, Sports, and Video Chat.

Because of these points, I believe there’s a strong chance Apple will further connect the iPhone and Apple TV. Or, Apple could replace the Apple TV entirely, and come out with a killer Mac Mini/Apple TV-hybrid unit. One generally never knows what Steve Jobs has up his sleeve until his Tuesday announcements…

(Side note: this isn’t a new idea… several more-informed folks have suggested similar ideas in the past. AppleInsider proposed the Apple TV as a “casual gaming” device, and The Unofficial Apple Weblog has been clamoring for Apple TV Apps for some time. Update: The Inquisitr just proposed a similar call for an Apple TV App Store.)

I instantly downloaded it, and added several of my WordPress blogs to the app. Aside from the annoying Twitter Tools glitch (which sent an empty tweet on blog setup), I was surprised to see some big omissions that would impede regular usage for site administrators… at least from my standpoint.

• Dashboard functions
  As readers here know, I don’t post every day. I do, however, very regularly check my WordPress Dashboard. The Dashboard wraps up basic stats, such as the five most recent comments, incoming links, number of new unapproved comments, and WordPress news for the package itself (and 3rd-party plugins).

  I find this data invaluable to know if there’s anything I need to take action on (such as marking a new comment as ‘approved’ or ‘spam’) or learning about a security exploit.

• Global Drafts
  The second-most popular task for me in WordPress is creating and editing a draft post on the server. It generally takes me several revisions before I post a “post” here. (This one, for instance, has taken 10+ edits over 1.5 weeks.)

  Unfortunately, though, the iPhone WordPress app only can edit and save local drafts (i.e. those on the iPhone itself). This is probably the biggest deal-breaker for me. I don’t want to write and edit on my iPhone, as the keyboard is so awkward. I would, however, as it makes it convenient to drop in a quick edit or two, or get started on a new idea. But, preferably, I’d take a full, non-finger-crippling, physical keyboard experience over the on-screen, cramped digital keyboard. Because of this, I wouldn’t now dream of starting a post on the iPhone knowing I couldn’t switch back to the desktop keyboard later.

  Maybe one day Apple will allow Bluetooth keyboards to pair with the iPhone. (Maybe even starting with their own keyboards, in fact!) Until then, this app will just serve as a monitoring and quick editing environment.

  (Side note: It appears this issue may be larger than that of this app. I’ve noticed similar drawbacks plague ecto and MarsEdit, too. Anyone know why this is, and/or a workaround?)

• Links (add, remove, order)
  The iPhone has a number of built-in controls and UI elements for creating and managing lists. WordPress, too, has great built-in support for Links which populate a blog’s Blogroll section. Why not blend the best of both worlds? List management for your blog using the iPhone’s easy list management UI features? It sounds delightful.
• Widget addition, order, removal
  Similar to Link management, the ability to re-order, customize, and enable/disable Widgets for WordPress. Honestly, re-ordering widgets using the WordPress Web-based manager is rather awkward… having used the iPhone’s list control UI before, I imagine I’d prefer handling all Widget activity on the iPhone altogether.
• Plugin control and updates
  Plugins are well-known to cause performance issues for some WP blogs, and occasionally they can cause sites to come to a screeching halt. Being able to toggle a plugin on and off remotely would allow site administrators to quickly re-enable a site simply by flipping a plugin off (and/or back on). Further, WordPress now allows most plugins to be updated (when updates are offered) via the Web interface. As such, being able to click a couple links to bring all your plugins up-to-date would be very useful.
• Run backups
  The thing about backups is: you never think to backup your files till its too late… why not just offer the “Save to server” and “Email backup” options (sans “Download to your computer” due to limited iPhone storage opportunities)?
• Stats
  Last but not least, the WordPress Stats plugin has become invaluable to me. I’m a big fan of Google Analytics (who significantly raised the bar on visualizing web usage data several years ago), but there are few times that I head over to the Google site to check out how my blog is doing. The WordPress Stats plugin gives me my most basic visualizations (such as visitors over time, top posts, top searches, and most active) right on the Dashboard. It’s not a 3rd-party plugin, as its made by Automattic (the folks behind WP itself and Akismet), so no (legal) reason not to include in this package.

  I know the plugin currently uses Flash to render its chart, but I’d happily deal with a static, cached PNG or GIF if that got me some level of site monitoring via the app.

Please, don’t get me wrong. I understand I’m looking at a 1.0 release, not a 2.x or 3.x version. Many of the features I’m describing are fine to release after supporting basic posting functionality. Further, the app is free… which means the good folks at Automattic dropped at least a benjamin simply to offer freeloaders (like myself and all other WordPress user) a means of managing our blogs on the go. (So, to the good folks developing this app, “thank you.”)

Automattic has been kind enough to provide a list of upcoming bug fixes and features for the app. I didn’t see any of my ideas already listed there, but don’t doubt that as time passes, the app will become considerably more usable.

What features of the app do you find missing? And/or invaluable while on the go?

Update: Daniel Jalkut, author of MarsEdit, kindly offered a solution to the issue of Global Drafts, which ended up serving as a great workaround. (Thanks, Daniel! Anyone else know how to solve the remaining open 6 features?)

The Future Design 2008 article spans a number of genres and media, and tries to paint a picture of what issues designers are facing in these varied industries. I try to wax on a bit regarding the push to design every experience as if it could pick up, pack up, and head over to another site to hang out with users there; letting users grab content and take it where they will while continuing to interact with their social connections is quickly becoming the norm.

Widgets, widgets everywhere. That’s what 2008 seems to be looking like to me.