Once uploaded, documents retain their visual integrity and can be edited or revised on the site by any number of users.

For now, iWork.com will be offered a free, closed beta, but eventually it will become a pay service.

We’ll update this post when more information becomes available, but right now, it appears that Apple is taking a similar approach to web applications as Microsoft. iWork 09 + iWork.com feels a lot like Microsoft’s client + cloud vision, in which desktop software is complimented by an online version of the application that allows for cross platform collaboration and web based storage.

Update: Apple’s iWork.com site is now up, and on second glance it appears that iWork.com competes more with services like Adobe Share or Microsoft Office Live Workspace than it does with Google Docs. iWork.com is not a full fledged software as a service suite of productivity applications. There are no web app versions of Pages, Numbers, or Keynote as part of iWork.com.

Instead, what Apple has created is a service built into the 2009 release of the desktop version of iWork that allows users to share documents via a web interface with other users. Documents can be downloaded in iWork format, Microsoft Office format, and PDF, and users can leave comments on shared items than can be downloaded as part of the shared document by the original author.

There is no full online editing feature of iWork.com, however. So it doesn’t compete with Google Docs — at least not yet. For now, iWork.com is a software + services play that specifically focuses on very basic sharing and collaboration. It’s a nice addition to iWork, but nothing that will really set the world on fire.

When it was initially announced, iWork.com sounded like something that could potentially be very cool. But upon closer examination, it’s actually not all that exciting.

TechCrunch, which covered the VixML launch and calls it “revolutionary,” says that for now applications created using the platform can only be published to Viximo’s upcoming TrueFlirt app, which lets users create (using VixML), send to friends, and view “flirtatious” animations and mini-apps for the iPhone.

Developers can use VixML to create apps that are then published for use with TrueFlirt, either within the app itself or as part of standalone add-on bundles for the TrueFlirt app that are sold via the App Store. Viximo reportedly plans to share revenue with the developers of VixML apps, who TechCrunch points out face a double approval process — they need apps to be approved both by Viximo and by Apple.

The platform within a platform approach is interesting because it lowers the barrier of entry for development for the iPhone by making it easier for web developers to create native apps — they can skip learning Objective C by using something like VixML. And though VixML is unique in its approach, it isn’t really what we’d call revolutionary. We reported in September on two other iPhone development platforms that greatly lower the barrier to entry for developers and do so in what we think are more clever ways.

Big Five (iTunes) is a web application gateway for the iPhone and iPod Touch that offers an API allowing developers to access native iPhone functions such as the accelerometer, GPS, and camera via JavaScript. Apps are published to the web and accessed via the Big Five browser, which the user purchases from the App Store. When we wrote about them in September, Big Five had been rejected from the App Store, however it has since been approved and is for sale for $14.95.

The other iPhone development platform we mentioned a few months ago is PhoneGap, which is something like Adobe AIR for the iPhone. PhoneGap allows web application developers to compile their web apps as native iPhone apps and then submit them to the App Store for inclusion. The platform is essentially a container for web applications running on the iPhone that allows them to access the accelerometer, GPS, sqLite, camera, and vibration controls. PhoneGap also uses a JavaScript API for accessing native iPhone features, and then creates a location bar free web browser that points to a specific web application URL, which can be wrapped up as a standalone application and submitted to Apple. Some iPhone apps already in the App Store are using PhoneGap, such as the free “Binary Clock” app (iTunes).

All three of these options drastically reduce the barrier to entry for creating iPhone apps by allowing web developers to create apps that access native features by using technologies they already know, such as XML and JavaScript. We’re big fans of the PhoneGap approach, since it is the only one of the three that allows developers to create applications that can be served directly to users via the App Store without having to go through an intermediary app (i.e., TrueFlirt for VixML, and the Big Five browser for Big Five). All of these platforms, however, make iPhone development easier, which is a good thing for developers.

As CSS advances and implementations improve, more and more is possible purely using style sheets and without the need for additional scripting on either a site’s front- or back-end, which reduces the amount of executable code. One possibility that dawned on me recently was that, using only bits of CSS2.1’s generated content properties, we can aggregate and expose supplemental information about whole portions of pages.

Like many other blogs, SitePoint’s blog posts have a small paragraph of metadata at the end of each post. The paragraph gives readers supplemental information about the post, like its publish date, its tags, and any categories the post is filed under. Let’s see how easily we can add new information to this using only CSS.

Using (and abusing?) CSS counters

One feature of CSS2.1 that has remained underutilized for a long time is CSS counters. Counters are a subset of the CSS specification’s generated content sections. They are ostensibly a generic mechanism for numbering groups of elements that appear in a document tree. Sadly, support for this CSS feature has been lacking from certain browsers for a very long time.

What’s really interesting about CSS counters is that since the act of displaying a counter is decoupled from the counting mechanism itself, we can utilize them to display total counts of elements in addition to merely numbering elements in a series.

As a brief refresher, here’s how the CSS2.1 specification says we can replace the numeric markers of a typical ordered list with a CSS counter to achieve a more-or-less equivalent visual result:

ol { counter-reset: item; }
ol li { display: block; }
ol li:before {
    counter-increment: item;
    content: counter(item)". ";
}

This code initializes a counter called item at every ol element. Then it turns all the li elements into block-level CSS boxes instead of their default list-item boxes so they won’t show a marker (i.e., a number or bullet from the list-style-type property). Finally, for each list item, it increments the item counter, and then renders its current value.

Now, here’s how we can use the same mechanism to display the number of total list items at the end of the list with only minor and perfectly valid modifications:

ol { counter-reset: item; }
ol li {
    display: block;
    counter-increment: item;
}
ol:after {
    display: block;
    content: "Number of items in this list: " counter(item) ".";
}

The only “trick” is not to call the counter() function more than once. Specifically, you call it only :after you’ve finishing incrementing the counter at each element you’re counting. Used in this way, you can see that CSS counters are like a limited sort of integer variable.

Thanks to these two generalized capabilities—CSS counters and CSS generated content—we can start to get really creative.

Getting creative: Counting things in a blog post

One interesting use for this technique is to extend or, perhaps in some cases, completely replace programmatic code such as JavaScript or server-side scripts that count things. For example, here’s how I might use the technique above to count the number of distinct sections in a SitePoint blog post:

/* Initialize counter to 1 (not 0) since titles are outside .entrytext but may include intro paras. */
.post { counter-reset: num-post-sections 1; }
.post .entrytext h2 { counter-increment: num-post-sections; }
#thisentry:after {
    content: "This entry has " counter(num-post-sections) " sections.";
}

The code above simply increments a counter called num-post-sections each time a h2 element is encountered in the entrytext of a post, and then displays the result at the end just like the previous list item counting example.

Of course, you’re not limited to merely counting one thing. Here’s how I might count the number of sections and the number of code excerpts in a SitePoint blog post using the same pattern:

.post {
    counter-reset:
        num-post-sections 1 /* titles outside .entrytext but may include intro paras */
        num-code-listings
    ;
}
.post .entrytext h2 { counter-increment: num-post-sections; }
/* match both with (pre>code) and without (table.dp-c) JavaScript code highlighting */
.post .entrytext pre > code, table.dp-c { counter-increment: num-code-listings; }
#thisentry:after {
    content:
        "This entry has " counter(num-post-sections) " sections and "
        counter(num-code-listings) " code listings."
    ;
}

Screenshot showing this SitePoint blog post with the CSS excerpt applied.

As a pattern, this becomes more useful if we generalize the above SitePoint-specific CSS rules so that they will work for any blog whose posts are structured using the hAtom microformat, so you can use it across many sites or insert it into your own browser as a user style sheet. The only necessary changes are the CSS selectors, but you can get very fancy. For the sake of example, I’ve thrown in a bunch of additional counters to illustrate more possibilities of what you can count.

/* Initialize counters. */
.hentry {
    counter-reset:
        num-post-sections
        num-code-listings
        num-code-listings-css /* code listings that are specifically CSS */
        num-links
        num-links-internal    /* links to other blog posts on this site */
        num-links-rel-tag     /* rel-tag microformat */
    ;
}
/* Increment counters. */
.hentry h2,
.hentry h3,
.hentry h4,
.hentry h5, /* consider any headline an additional "section" */
.hentry h6 { counter-increment: num-post-sections; }
.hentry pre > code { counter-increment: num-code-listings; }
.hentry pre > code.css {
    counter-increment:
        num-code-listings     /* increment count of total code listings */
        num-code-listings-css /* AND the subset that are just CSS samples */
    ;
}
.hentry :link { counter-increment: num-links; }
.hentry :link[href^="/blogs/"] {
    counter-increment:
        num-links
        num-links-internal
    ;
}
.hentry :link[rel="tag"] {
    counter-increment:
        num-links
        num-links-rel-tag;
}
/* Display results. */
.hentry:after {
    display: block;
    content:
        "This entry has a total of "
        counter(num-post-sections) " sections, "
        counter(num-code-listings) " code listings "
        "(" counter(num-code-listings-css) " are CSS) "
        " and " counter(num-links) " links, "
        "of which " counter(num-links-internal) 
        " point to other blog posts on this site "

        " and " counter(num-links-rel-tag) " are tags."
    ;
}

Naturally, you can only count what you can target with a CSS selector, so generating a word count isn’t possible. Also, you can only display totals in generated content that comes :after all of the markup you want to count, not :before it. Obviously, this implementation detail can limit the design flexibility you have.

Finally, it’s worth stressing again that CSS counters are not implemented in IE 6 or 7 (sigh…). Further, since we’re dealing entirely with CSS generated content, the displayed text may not be selectable by the user or accessible via the DOM for further manipulation. And of course, in many instances you may want to put such things directly into your markup as “real” content.

A point perhaps more important than these limitations, however, is that this is a powerful demonstration of how you can use your markup as an API to let the advancing capabilities of CSS do things you could once only do with client- or server-side scripting. Now that’s exciting.

It was actually fairly common for web apps of 4 years ago not to be cross browser, or cross platform compliant — which seems absurd given that the ability to work anywhere, on any computer is a major selling point for web apps. But when 9 out of 10 potential customers — or more for some market sectors — are using Internet Explorer, why pour resources into designing for other browsers? (Note that greater than 96% of all web users were on Windows in 2004, compared to about 88% now.)

Flash forward to today and the landscape looks totally different. IE commands under just 70% of the market, Firefox is over 20%, Safari greater than 7%, and even though newcomer Chrome weighs in at just under 1%, we’ve predicted that Google’s browser will grow significantly next year. The search engine is already putting Chrome links on Google.com and YouTube, and in Gmail for IE6 users, plus the browser might start coming pre-installed on PCs next year.

Though IE still has a commanding lead in the browser market, 2009 should see continued growth for Firefox, Chrome, and Safari (though Chrome could slow down the growth of other alternative browsers once it has extensions). Internet Explorer, meanwhile, is expected to continue its decline. As browser parity nears (at least in terms of user reach), cross browser and cross platform functionality is becoming more and more important. Already Firefox and Safari have shares of the market too significant to ignore, and Chrome could get to that point in a hurry.

That’s great news for consumers, who get more choice, and is a mixed blessing for web developers. On one hand, it means even more browsers to test and develop for. However, on the other hand, the rising popularity of open source browsers means a trend toward the adoption of open standards. Competition fueled development means better rendering engines, faster JavaScript interpreters, etc., which in turn means better resulting products. And not just browsers — better web applications will also be a result of heightened browser competition.

The decline of IE might mean more initial development required to make sure the maximum amount of users can access your site or application, but in the long run, it’s a great thing for everyone (except perhaps Microsoft).

Mobile blogger James Kendrick noted today that if mobile phones like the Apple iPhone, HTC/T-Mobile G1, Blackberry Storm, or Nokia N95 are considered computers, then Nokia was the largest computer manufacturer in 2008. But are smartphones really computers? Yes, they have increasingly more powerful processors and do many computing tasks, but as Kendrick points out, they don’t do all the things your laptop or desktop personal computer can do.

Smartphones are not personal computer replacements just yet — and they might never be. It’s hard to imagine writing a term paper or designing a web site on your phone. As good as the experience on the iPhone and Blackberry is for many common computing tasks — like email or web browsing — you wouldn’t want to use your smartphone to edit a photo.

On the other hand, in many parts of the world, especially in developing nations, mobile phones are already being used as primary computing devices. And more and more we’re spending a majority of our computing time on smartphones, doing common, everyday tasks like emailing, instant messaging, web browsing, playing games, taking photos, managing appointments, and even doing things like monitoring servers or managing our financial portfolios. If we can do all that, isn’t the smartphone a computer after all?

Let us know what you think in your poll and then share your definition of what makes a computer a computer in the comments.

As software applications move to the cloud, once dominant leaders will be challenged by new upstarts. Microsoft Word will face a real challenge from the likes of Google Docs and Zoho Writer. Quicken and Money may be challenged by the likes of Mint or Cake Financial. Photoshop will face competition from online apps like Aviary, Pixlr, Splashup, and Sumo Paint. iMovie may find itself playing catch up to web-based applications like JayCut. PowerPoint will get a run for its money from SlideRocket and 280 Slides.

Whether or not Apple really does push iWork or iMovie into the cloud this week at MacWorld doesn’t really matter (though it would be cool if they do), the point is that Apple and other companies have an amazing chance, due to the growing popularity of software as a service, to compete in areas they were never before competitive.

Currently, iWork is a non-competitive desktop office apps suite, for example. Even though it stacks up to Microsoft Office on features in some cases, iWork remains only a niche Mac product because so many people already rely on Office that compatibility issues generally force people to shell out for it. But an online, cloud-based, cross-platform version of iWork would be different. There are no established leading web applications for word processing, spreadsheets, or presentations, so any app developer has a shot to compete with the current heavyweights of the desktop world.

SaaS resets the playing field and erases established leaders from the discussion — the desktop versions so entrenched in our lives no longer matter once software completely moves to the cloud — if it does, so the door is wide open for new competitors. That’s why SlideRocket, a web-based application initially developed by one person, may end up taking down PowerPoint. That’s why 37signals, a bootstrapped company with just a handful of employees, can take on Microsoft Project with Basecamp, and why Salesforce.com has been able to take on SAP and Oracle.

The web apps mentioned in this post generally don’t compete with their desktop counterparts feature-for-feature. If they were desktop apps, they probably wouldn’t have a chance to compete because people would dismiss them for not stacking up feature-wise, or for having compatibility issues. But web apps gets some leeway. People don’t expect them to be as feature rich yet, and convenience and accessibility make up for lack of features. Further, compatibility issues matter less with web apps because you can usually just share work directly via the app with a collaborator.

And because the software as a service model makes it easier to push out updates to all customers at once, SaaS apps have so far generally been more agile and able to iterate and improve a lot faster than their desktop counterparts. SaaS wins when it comes to convenience, accessibility, collaboration, and agility — so they get a pass on features for now.

As I said, these might be obvious points, but they only became clear in my mind recently, so I thought I’d share. If you agree, disagree, or have something to add, please respond in the comments below.

So if every major newspaper in America is using RSS (and I’d guess most major papers worldwide that have a modern web presence do as well), why would the Agence France-Presse (AFP), one of the world’s three largest news agencies, decide to nix RSS feeds on their homepage?

There was no press release or official statement about the decision to pull RSS support from AFP.com, just confirmation that the AFP had indeed shut off its RSS feeds via a high level employee speaking to the NewsCred blog. However, this seemingly protectionist, walled garden tactic is not new for the AFP. In 2005 the news wire sued Google for linking to its stories using a headline and short excerpt. The AFP said that Google was using content without permission and infringing upon its copyrights.

It would appear that the suit was less about protecting copyrights and more about trying to land a big new client; a couple of years later the AFP settled with Google by roping them into a syndication deal. In the long run, suing Google actually worked for the AFP — they probably make more money licensing their content than they do when Google sends them traffic to AFP.com.

When I started writing this post, I planned to argue that turning off RSS wouldn’t have the same positive long term effect that suing Google ended up having. However, after writing it out, I’m starting to come around. First, here’s why RSS makes sense for most content publishers:

Why RSS Is Good For Users

• It’s a lot easier to read multiple publications on a more regular basis when they’re delivered to you.
• Data and content delivered by RSS can be mashed up in a new and interesting ways that reveal previously unnoticed or inaccessible conclusions.

Why RSS Is Good For Publishers

• Because RSS makes it easier for people to track multliple sources, casual readers who would likely only read your publication once in awhile or not visit at all will be more apt to become regular readers.
• RSS enables mashups that expose your content in new and interesting ways, and will ultimately drive more traffic, readers, and brand recognition.

However, the AFP is in a different situation than most content publishers. They’re not in the business of selling their brand to consumers — they sell content to companies that sell to consumers. Because the AFP has paid syndication clients, full RSS feeds are out of the question — they’d put the AFP in direct competition with clients, and they’d force the company to utilize staff to monitor and track down unauthorized uses of their RSS feed, which would be an unnecessary cost.

The AFP is in the business of providing content to publishers that then offer it to consumers and mashup developers via RSS (such as those top 100 newspapers). AFP content is already available via RSS from AFP clients. Offering it free on their site is detrimental to their business and creates problems for their paying clients.

It may seem like I’m arguing in favor of walled gardens — I’m not, though. I would sincerely hope that the AFP offers licenses to clients that allow them to republish content via RSS, including full text feeds — and then allows that content to be remixed down the line in any way possible. However, for the AFP itself, public RSS feeds are not necessary and actually don’t make much sense given the business they’re in.

In order for OpenID to compete on this new playing field, the OpenID Foundation needs to stop dragging their feet and start working on efforts to educate people about what OpenID is. On the technical site, OpenID is more or less a sound protocol — there hasn’t been any foot dragging there, but on the consumer outreach side, they’re getting beat. Badly.

Most people have no clue what OpenID is, even though many of them actually have OpenID-enabled accounts. Everyone who uses Facebook (which is a lot of people), on the other hand, understands what Facebook is and knows what “login with Facebook” means. OpenID needs to work hard to change that in 2009.

Unfortunately, it appears that the people behind OpenID might be asleep at the wheel in some respects. While Facebook is pushing hard to get Connect out there (and Google is doing the same with Friend Connect — which actually includes OpenID), OpenID is, as Nick O’Neill puts it, “organizing the organizers,” referring to the recent OpenID Foundation community board elections that were held last week.

“I used to be a huge advocate of OpenID and I honestly believe that there is still a lot of movement going on. Unfortunately though I think the group is over planning and under executing,” says O’Neill. “While some large organizations (Yahoo! included) are supporting the identity standard, there is still a lack of general consumer education. Without that there is no way OpenID can compete with Facebook Connect and other new standards.”

Fellow blogger Allen Stern shares some of the same concerns about OpenID. “It’s more likely that the average Internet user will understand the Facebook Connect process than the OpenID process. This is why OpenID must focus on marketing and usability more than technical standards at this time,” he writes.

What the OpenID Foundation needs to do is start “getting real.” Getting real is a business philosophy from 37signals, a successful web application software company based in Chicago. Though there’s a lot more to their idea, one of the main themes essentially boils down to this: stop screwing around with all the stuff that doesn’t matter and just wastes time (like politics and meetings), and start doing the stuff that needs to get done (like building your app). Don’t worry about the details until people are already using what you’re selling.

I agree with O’Neill that so far the OpenID Foundation seems to be spending too much time on organizational stuff, and not enough time on actually doing what needs to get done. In a chapter of their book “Getting Real,” 37signals talks about how meetings can kill productivity. “Every minute you avoid spending in a meeting is a minute you can get real work done instead,” they write. From my admittedly outsider’s vantage point, it appears that the people behind OpenID are getting too caught up in the organizational stuff, getting too lost in the details, and not spending enough time on execution.

My perspective, of course, is that of an outsider. I’m not privy to what’s going on behind closed doors, so to speak. So my perception of what’s really going on could be off. But at this point in the game, public perception is what it’s all about.

So below are eight prognostications for the new year in web tech. Of course, if you saw our list of 2008’s top stories, you’ll know that reality is often too wacky to predict — and that A LOT happens in a single year. Remember to check out how we did with last year’s predictions, as well. And let us know in the comments what you think 2009 has in store for the web.

Note: I use the corporate “we” in this post, but these predictions are really just my own and not those of anyone else at SitePoint. So, don’t blame them for the terrible lack of foresight!

1. Twitter gets a business model. Twitter has a bunch of different options when it comes to monetization. Targeted ads in the Twitter stream based on what you tweet about, built in micro payments, charging high volume users, charging developers to use the API, etc. Twitter may try some or all of these options, but we think the most likely path to monetization is in corporate accounts. When SitePoint ran our highly successful and well publicized book giveaway via Twitter, it was only really made possible because we were able to get on Twitter’s white list and send a large number of direct messages without being blocked. Prior to getting on that list, things didn’t go nearly as smoothly. That’s the sort of added functionality that only corporate accounts would likely need, and that Twitter could charge for.

2. Lifestreaming gets big, but not via FriendFeed. FriendFeed made a huge impact over the past year among the early adopter crowd, but lifestreaming hasn’t quite made its way into the mainstream. People are just now beginning to regularly use enough social services at once — YouTube, Flickr, Twitter, Digg, blogging — that aggregation will start to make sense. In 2009, it will be commonplace to publish your online life in a single stream, but it will be done via Facebook.

3. The Web OS will really start to become a reality. The Web OS race is on. In 2009 we’ll start to see the vision really begin to coalesce from major players like Adobe (Flash, Flex, AIR), Google (Chrome, Gears, Native Client), and Microsoft (Silverlight, Live Mesh), among others.

4. Some really great stuff will come out of Yahoo!, but it won’t be enough to save them. Yahoo! has been doing some awesome stuff by opening up their search results and most popular pages and applications by making them more social and giving developers more hooks. That’s the sort of thing that will ultimately make the web a better place, but unfortunately it won’t be enough to save Yahoo! on Wall Street. Their stock will continue to slide, unless they sign a big search deal with Microsoft or sell their search business outright to focus on the content/platform side.

5. Chrome will take at least 5% but not more than 10% of the browser market by year’s end. Google’s browser, now out of beta and being actively promoted by Google, will take at least 5% of the browser market by year’s end and as much as 10%. IE will continue to decline with both Chrome and Mozilla Firefox on the scene, but Chrome will actually cause Mozilla’s growth to stall, and will probably even steal some market share from Firefox once it supports extensions.

6. Microsoft Office will make people comfortable with web applications. When Microsoft pushes out a web-based version of Office, users in the mainstream will finally start to become comfortable will web apps. Google’s Docs and Spreadsheets apps have certainly already pushed a fair number of people in that direction, but Microsoft will have a vastly bigger impact on the adoption of web applications by mainstream users. Their software + services vision will emerge in 2009 as the clear future of software.

7. Facebook takes over the web. Well, not literally. But Facebook will continue to grow in size worldwide, and will finally over take MySpace as the biggest social network in the US. A lot of the cool web applications that early adopters love, such as FriendFeed, will reach the mainstream as features of Facebook, and Facebook Connect will help spread the Facebook brand by entangling it with other popular sites on the web that people know and trust. The company will also expand their search deal with Microsoft and make web search integration more prominent and more powerful. For many users, Facebook will become their default search engine in 2009, and this will pave the way for an IPO in 2010.

8. Palm will surprise everyone at CES… Nova will be good. Palm’s new entry into the smartphone market will be very impressive. The Nova operating system will look like something that could challenge Android, Blackberry, and the iPhone in the mobile market, but success will depend on the hardware.

What are your predictions for the year 2009? Let us know in the comments.

Listen in your Browser

Play this episode directly in your browser! Just click the orange “play” button below:

Download this Episode

You can also download this episode as a standalone MP3 file. Here’s the link:

• SitePoint Podcast #5: The Principles of Successful Freelancing (MP3, 26.8MB)

Subscribe to the Podcast

The SitePoint Podcast is on iTunes! Add the SitePoint Podcast to your iTunes player. Or, if you don’t use iTunes, you can subscribe to the feed directly.

Episode Summary

Here are the topics covered in this episode:

Interview: The Principles of Successful Freelancing with Miles Burke

• The Principles of Successful Freelancing (SitePoint)

Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.