When Adrian Zuzic and Matej Robar set out to be entrepreneurs, the Slovenian friends had no clear idea of what they wanted to invent, much less how they'd go about inventing it.

Yet after an agonizing and largely undirected period of trial and error, what they ended up inventing was Blooki.st, a blogging platform that, oddly enough, lets visitors wander through photographs, essays and personal stories in much the same aimless yet rewarding way Zuzic and Robar created the site in the first place.

Meet Blooki.st

Blooki.st is a blogging platform stripped almost to the bone. Open a "blook" — supposedly what you get when you cross a blog and a book — and it suddenly consumes your entire browser screen. Scrolling down actually moves you from left to right in typical Western reading fashion. With this full-screen approach, photography is blown up to stunning, enveloping proportions. The only other feature you can tack on is text in a single font. 

"What we wanted was to offer anyone a piece of their own land," Zuzic says. "With Blooki.st, we reverse engineered the whole process. We knew where we wanted to end up and then stripped it down to the bare essentials." Not surprising given its straightforward focus on images and text, Blooki.st has created a small but dedicated niche for itself as a place to showcase portfolios and travel photography. 

So how did a couple of post-grads with ambitions set on the IT industry transition to a serene blogging platform perfect for cutting out the noise?

"We always wanted to build something that would give back to the community," Zuzic says. Initially, the pair thought the music world was their calling, but were drawn more and more towards publishing platforms as their idea machine kicked into high gear. "We were changing ideas week by week until we ran out of everything. A "blook" was just a concept we had lying around until one day we realized that was it."

The fact that each blook moves left to right is a nifty touch. But from a self-publishing philosophy standpoint, a blook contains a myriad of possibilities reduced to the simplest of forms, with potential far beyond portfolios and photography. As more blooks get added to the site, the way people use it begins to change, noticeably, day by day. 

A Good Wander Spoiled

When the Blooki.st cofounders initially hopped a plane out of Slovenia, they had high hopes. Zuzic had studied law and Robar media communications, but both were convinced the world's most desirable opportunities lay elsewhere.

"I thought there must be something better than ordinary life in the office," Zuzic says. "We had big egos, and lots of optimism...so we took the plunge." The plunge was London, where Zuzic and Robar flew without a return ticket.

The plan was ambiguous: start a company, expand an idea, create something unique. The focus was originally on IT, but it was broad, and without ever having crafted a single line of code, the pair knew that their loose roadmap was a bit of a risky undertaking. 

That was in April of 2011, and it did not go well. 

"All projects or ideas we had were disastrous," Zuzic admits. "We were looking for that perfect idea, looking for people to join our team, facing high costs of living and had no success." When it starting becoming clear that it wasn't going to be as easy as the duo had hoped, they were forced to recalculate their approach. "We realized that optimism without a bit of realism won't work."

So Zuzic and Robar started from scratch, and kept the ball rolling through failed idea after failure idea. Not until a good friend of theirs, developer Jani Gorse from the Slovenian village of Kot pri Ribnici, showed interest in participating in something outside of his day job did the team find that they were ready to get an idea off the ground. And thus Blooki.st was born.

Blooking Ahead

The team has now expanded to four people; in October of last year, Luka Locniskar joined as a front-end developer. But the platform is still in a stripped-down alpha phase.

"The good news is the platform is already publicly available," Zuzic says. Blooki.st launched on April 3, and began quietly will a select few invites. The team let it grow organically from there, and by mid-April it had garnered around 600 users. That met the requirements the team needed to test all the aspects of the platform properly.

"We were a bit 'evil' and did not include any guides, because we wanted to see how our users will respond," he adds. "Regarding the content, we have seen various styles, from poetry to photography, short cute blooks to massive ones, showing the variety we have to promote and work on." This variety has given the Blooki.st team some ideas about moving forward, especially in a rather unchartered space for blogging: user revenue models.

"We aim to start challenging the traditional platforms not only in terms of content distribution, but also revenue options for the users," Zuzic says. There are also plans to make Blooki.st as writer-friendly as it is photographer-friendly, with a focus on self-publishing everything from journalistic non-fiction to novellas and poetry.

What any of that will look like is still part of a fluid process changing week by week, but the Blooki.st team's attitude towards planning seems to have aligned with that of the very simple nature of the blook itself: it will happen when it happens, naturally, and without too much fuss. 

A prime example of this blookist attitude is with the site's beta release, which is Blooki.st's closest thing to an official next destination in the meandering roadmap that started two years ago in Slovenia. (The site is officially still in alpha, if you believe what you see when you visit it.) But there's no official timeline for a beta release, either. Zuzic says it might just come overnight whenever the team feels ready.

Theoretically, online services shouldn't ever get so mobbed by customers that they can't deliver a game or service, because it should be ridiculously easy to bring on additional capacity to meet demand. And yet here in the real world, exactly these sorts of failures seem to crop up with dismaying regularity.

So it's time for these services to fess up: Why can't Johnny scale?

Scale Fail

The biggest such disaster recently was Electronic Arts's blinkered SimCity launch earlier this month. Because of EA's decision to saddle users with an onerous digital-rights management system through its Origin service, players had to be online at all times and connected to EA's servers, even in single-player mode. The demand was too much, and those SimCity users who could actually connect experienced widespread problems with gameplay.

(See also: Will SimCity Launch Disaster Stop Online-Only DRM?)

Or take the less-publicized problems that ComiXology was having early last week. At SXSW, Marvel Comics announced March 10 that they would be releasing over 700 #1 Marvel issues through the digital comic service. Six hours later, ComiXology's servers crashed in flames.

ComiXology CEO David Steinberger sent out a quick e-mail the next day acknowledging the problem, which affected not only the Marvel promotion, but also regular comic sales from other publishers like DC and Image.

"We had believed ourselves prepared — but unfortunately we became overwhelmed by the immense response. We're still struggling to keep our systems up," Steinberger wrote. "The result is that you aren't getting your comics when and where you want."

Given that I am a ComiXology user and it was less than 48 hours until Wednesday — New Comic Day — you can bet I was focused on this news. To their credit, by the time I tested the app Tuesday afternoon, everything seemed to be working fine. But the Marvel promotion has been postponed for now.

Finally, I wanted to check out the mail-sorting service known as Mailstrom, a free beta service that lets you view your email account through different lenses that enable you to clear out your inbox faster. A colleague had recommended it, and the thought of achieving Inbox Zero at long last called to me like a distant dream.

I signed up for the service, and was informed I was 4819th in line. I like in a world of big numbers, so I wasn't worried. Computers, I've heard, are fast.

But two days later, when I checked my status on the queue again, I had only risen 36 places in line. By my projections, that put me at getting the service applied to my account by Dec. 4. I sent an interrogative via Twitter, was chided a bit about projections and told to drop a line to Mailstrom's service e-mail account. I did so, and was told to swing back in a week if I hadn't been activated.

Huh.

To be fair, complaining about a service that is both free and in beta is a little like kicking a puppy. Also for the record, Mailstrom did get me activated on March 14, six days after sign-up.

But the small hiccup I had with Mailstrom just underscored a systemic problem in the online world. Given that businesses are living and operating online these days, why are so many companies failing to meet instances of high demand?

Inefficiencies of Scale

One common perception is that when you have problems of scale, the best thing to do is throw more resources at them until they go away.

This tends to be the default plan for many people. If the shark is really, really big, then sure - "we're going to need a bigger boat."

Sometimes this works. But sometimes it doesn't. In the case of the shark, perhaps a more efficient and less risky plan might have been stay out of the damn thing's food chain altogether. Alas, there are times when we have to deal with the shark anyway. Is more always better?

Consider the more reality-based problem of the airport gate. At most gates, there are two (sometimes three) terminals behind a desk, which is usually more than enough to handle a planeload of people, since much of the check-in and boarding work is done before the passengers even get to the gate.

But introduce a problem to the situation, such as a delay, and things can bottle up very quickly. Passengers line up to find out what's happening. Or switch to another flight because they're going to miss a connection. Or just generally complain. Whatever the reason, the line can become very long, slow and aggravating very quickly.

If you try the simple solution to solve this problem — add more resources, this time in the form of gate agents — it simply can't work. Remember, there are only two terminals capable of delivering information or solutions at the gate. Other gates nearby may not be busy, but they have their own passengers to care for, or they're not crewed.

This is, for all intents, a pretty fair analogy of what's not working well with today's online environments.

Architecture Matters

Applications were built, for the most part, without true scaling in mind. And why would they have been? If you're in a corporate environment, why develop a program that has to handle a sudden influx of new users or clients hitting your servers? Unless HR suddenly hires 1,000 people overnight, scaling is a slow and gradual process.

Internet commerce changed that. Vendors like Amazon had to invent whole new technologies for data management and storage just to keep up with holiday shopping. Yes, Virginia, there is a Santa Claus… and he was the necessity behind the invention of cloud computing.

But in this age of cloud computing, applications are still not optimized for the cloud. Nor, for that matter, are networks and infrastructure. It does little good to add more servers to a cluster that's bending under the weight of traffic if your app doesn't know to automatically shift to the new resources or if the network between servers vaporizes trying to handle the load.

"Fundamentally, cloud-optimized architecture is one that favors smaller and loosely coupled components in a highly distributed systems environment, more than the traditional monolithic, accomplish-more-within-the-same-memory-or-process-or-transaction-space application approach," Microsoft Architect David Chou wrote in 2011. His words still hold true today.

Given the many approaches one can take to shore up a web service to prevent a meltdown, why is this still such a problem?

• Lack of knowledge. We know about the cloud, but we don't know the cloud. Relatively few people do, outside of the people who invented the technology. That's changing, but it still remains a huge barrier to proper cloud use.

• Non-lateral thinking. Remember the airport problem? Passengers with smartphone apps can avoid the line to find out info or re-book themselves. Or just call the airline. But they don't, because they have to face someone right there to get their problem solved. They are not laterally thinking. (Nor are the airlines. Perhaps use apps that can actually run on commodity hardware and deploy crisis teams equipped with tablets or laptops to gates with problems.)

• Fear of... whatever. Fear of migration. Fear of losing data. Or money. Fear of looking stupid. Pick one. Or all. Because fear of shifting to any new technology is always an issue, and always will be. Solving the "lack of knowledge" problem will help alleviate this issue, but it cannot be ignored.

These are some of the biggest obstacles to getting apps and services out there that won't crash anytime there's more than a stiff breeze blowing. There are others, and they all must be solved. Cloud vendors are in the best position to create effective solutions, but customers can take matters into their own hands and start thinking of lateral solutions to their problems.

There's an iconic capitalist image of the overrun shop owner fending off a crowd of customers all clamoring for a hot product. That scene is manageable, at least after a fashion, because there's still be some business-to-customer contact — the shopkeeper can always try to yell over the crowd, after all. Online mob scenes, though, are worse, because it sometimes means there's no B2C communication at all. It's as if people came to the store and found the doors chained shut.

The solutions are there. It's time to embrace them, before your customers walk away.

Image courtesy of Shutterstock

When future historians look back and try to determine the exact moment when the personal computer and desktop form factor started to decline, there will be a lot of pointing at Jan. 27, 2010 - the day Steve Jobs announced the iPad. In truth, the downward spiral isn't marked by one event, but a lot of little incidents that mark the trail.

On March 13, Adobe unexpectedly added a chapter to the story of the fading of the PC, when it announced that it would be closing down its BrowserLab service effective… March 13.

The closure was as surprising as it was abrupt. BrowserLab enabled developers and web designers to test their work on different desktop browsers and operating systems, to help ensure cross-platform uniformity in look and operation.

In a statement to users on the BrowserLab blog, Bruce Bowman, Sr. Product Manager Edge Tools & Services and the Adobe BrowserLab Team, cited the popularity of mobile platforms as the big reason for BrowserLab's deactivation.

"When we originally launched BrowserLab as a free service back in 2009, our customers were struggling with testing their web content across desktop browsers and platforms. Since then with the growth of the importance of mobile devices and tablets, the landscape has changed dramatically. Because of this shift, we have seen the usage of BrowserLab drop over the past year while at the same time our engineering team has been focusing on solving this new challenge with new solutions.

"Due to this, we will be shutting down the Adobe BrowserLab Service effective immediately," Bowman added.

The resources BrowserLab must have taken up for Adobe must have been significant, for them to want to retask their team to focus on mobile development. Adobe has long been a strong presence in web design, desktop or otherwise, so it seems odd for them to abruptly drop even an ancillary service like this. While no one would argue that desktop is in decline, it's not completely going to go away.

An unspoken reason here may also be the way major browsers use rolling release schemes, where updates happen transparently and rapidly. Keeping up with those many different browser releases may have been too much of a challenge for Adobe, especially if is focused on delivering a similar service for mobile developers with its Edge Inspect product.

BrowserLabs users won't be left in too much of a lurch: Bowman specifically pointed out BrowserStack and Sauce Labs as two viable alternatives to BrowserLab.

In the grand scheme of desktop these days, I suspect the departure of BrowserLabs will create little more than a ripple within the development community. But it is one more signpost on the shift from desktop to mobile, and a potential harbinger to developers focused on the desktop that their tools and services may one day disappear.

Guest author Todd Anglin is EVP Cross Platform Tools & Services at Telerik.

For HTML5 developers and decision makers, the most important technologies right now are HTML, JavaScript, CSS, mobile platforms and devices and evolving HTML platforms (browsers and operating systems). But what does that mean in the real world? It means these 10 things in 2013:  

1. Rise Of HTML5 Mobile Platforms

HTML5 has played an increasingly important role building cross-platform apps for mobile devices. So far that has primarily been done using native “wrappers,” such as Cordova, which allow HTML and JavaScript to power apps on other native platforms (such as iOS and Android). This technique is called “hybrid” app development.

This year, though, a wave of emerging platforms will support HTML5 apps as a first-class citizen - no wrapper required! The biggest players will be Chrome OS, which is about to get much more attention from Google; Firefox OS, already scheduled to start shipping on low-end ZTE and TCL devices in Europe; Tizen, a new HTML-focused platform backed by many industry heavyweights, including Intel and Samsung; Ubuntu Phone, which brings the most popular flavor of Linux to phones, again with a HTML-centered ap strategy; BlackBerry 10, which puts HTML and JavaScript at the center of its next-gen app strategy; and Windows 8, which introduced a new HTML and JavaScript development model for it’s “Windows 8 style” apps.   One (or more) of these platforms is bound to succeed in 2013. My money is on Chrome OS and Tizen. With the backing of Google, a revamped developer and consumer push, and the broadest platform strategy (spans mobile and desktop), Chrome OS is very well positioned.

Tizen, meanwhile, enjoys broad industry backing from Intel, Samsung, NEC, Panasonic, Sprint, Huawei and Vodafone (among many others), and engineering stewardship in The Linux Foundation. It shows the most potential to challenge Android as the “more open” (read: more customizable) open source device platform, which should appeal to device makers.  

2. Made For Chrome(kit)

A growing number of sites are once again buildiing Web apps tested to work in only one browser. Like the “Made for Internet Explorer” badges of the 1990s, developers are now proudly advertising “Made for Chrome” in their apps. Not using Chrome? No guarantees.   This trend is likely to accelerate in 2013.   With a rapidly evolving, highlycapable browser platform that is available on virtually every major operating system (Windows, Mac, Linux, Android and kinda iOS), and a Webkit foundation that helps deliver a little extra compatibility with other non-Chrome browsers (like Safari and BlackBerry browser), developers are likely to conclude that the “good outweighs the bad” when it comes to building exclusively for Chrome.   In exchange for potentially alienating some users, developers building for Chrome can more aggressively leverage HTML5 APIs and save valuable development and testing time.  

3. IE10 Euphoria - And Pain

Internet Explorer 10 is widely regarded as a huge step forward for the venerable Microsoft browser. With more support than ever for Web standards, IE10 goes a long way to put Microsoft’s browser in the modern HTML5 conversation.   But as fast-updating browsers like Chrome and Firefox race forward through 2013, IE will once again be left looking old and slow. There is a glimmer of hope that Microsoft will evolve IE more quickly: The Microsoft-owned HTML5 Labs, launched originally in the IE9 days, is continuing to publish new “experimental” improvements for IE10 that make it an even more capable HTML5 browser. Baby steps, but still a good sign.  

4. The Death Of IE6, IE7 & IE8

While IE10 will be in the spotlight, the long death march for Microsoft’s older IE versions will continue. Only the most stubborn corporate environments (and China) still require IE6 support, and much of the world skipped IE7 anyway. If you haven't already stopped supporting IE6 and IE7, 2013 is definitely your year.   Dropping IE8 is a bit more of a stretch, but the pressure is on. Not only does IE10’s release make IE8 two versions old (often used as a “clean” support cut-off justification), but jQuery 2.0 will join Google Apps in cutting-off IE8 in 2013. By the end of the year, most developers will conclude IE8 is not worth their time.  

5. The Death Of Android 2.x

Until recently, it looked like we had another IE6 on our hands with Android 2.x (Eclair, Froyo and Gingerbread). According to Google’s own stats, as recently as mid-2012, these versions of Android (mostly 2.3.x) represented more than 90% of all Android devices in use, despite the fact that Google was already shipping Android 4+! Google was failing to keep its Android user base (and ecosystem) upgrading.   Fortunately, the 2012 holiday season seems to have broken the logjam. Usage of Android 4+ (Ice Cream Sandwich and Jelly Bean) surged to nearly 40% at the end of 2012. By the end of 2013, Android 2.x will likely account for less than 15% of the market, and Android developers will be able to shift focus to versions 4+.  

6. Responsive Design Goes Mainstream

So far, responsive design has remained on the fringes of Web development - something nice to do “if you have time."   That's about to change. With the lines between PCs and mobile devices increasingly blurred, developers will have no choice but to develop websites and apps that can dynamically adapt to an unpredictable array of screen sizes and resolutions.

(See also The New ReadWrite: Looking Good On Every Screen [Video].)

To ease the way, look for new techniques and defacto standards to also emerge, offering guidance for properly dealing with different device capabilities and form factors.  

7. Mobile Development Overtakes Desktop

It doesn’t take an expensive analyst to see the growth in phones and tablets while traditional PCs fade. Right now is the moment when developers will begin spending more time developing software for mobile devices than for traditional desktop PCs, extending from the consumer market to businesses of all sizes, for both internal and external audiences. If you’re not developing for devices in 2013, you’re either A) maintaining legacy software, or B) missing the boat.  

8. HTML On The Desktop

Just because mobile is on the rise, don’t start writing an obituary for desktop development. The traditional desktop form factor will remain critical for many information workers. But as the PC becomes one among many screens, developers will look for ways to write code that can be shared across the PC and mobile devices.   HTML and JavaScript are perfectly positioned to offer this capability, and platforms like Chrome Packaged Apps and Windows Store Style (WinJS) apps will make this possible. With both Microsoft and Google pushing HTML for desktop app development, developers will take notice and start embracing cross-platform desktop development with HTML and JavaScript.  

9. SPA Time

With the shift of desktop development and increasingly complex mobile apps to HTML and JavaScript, developers will recognize the need for new techniques to build maintainable cross-platform apps. The “Single Page Application” (or SPA) has been on the rise thanks to powerful frameworks like Backbone, Knockout and even Kendo UI. If “RIA” (Rich Internet Applications) was the buzzword in 2010, “SPA” will be the buzzword in 2013.   If you’re looking for the one new technology or concept to learn as an HTML and JavaScript developer in 2013, it's SPA architecture.  

10. HTML Gets Naked (Again)

Now that the W3C has “finalized” HTML5, public conversation and media coverage is going focus on what’s next for the Web standards platform. The W3C is already working on HTML 5.1, the next “snapshot” of the “living standards” work done within WHATWG, the Web Hypertext Application Technology Working Group. But as we move past the “HTML5” bubble, we’ll once again settle-in to talking about HTML, sans version numbers. After all, who wants to talk or write about “HTML5.1” or “HTML5.3”?   Whatever it’s called, the next wave of HTML platform improvements will shift focus beyond the lower-level core at the center of HTML5 (DOM elements, CSS styles, Simple JavaScript APIs like Geolocation) and instead characterize improvements that are important to more robust application development (like ShadowDOM, Web Components, CSS layouts, speech recognition and more).

The HTML conversation (and technology) will continue to evolve, even if the version numbers don’t come along for the ride.

Image courtesy of Shutterstock.

Microsoft on Thursday launched Modern.ie, a set of free tools and services designed to facilitate writing better code across a variety of operating systems, browsers, and devices. But it's also an effort to keep developers coding for the PC and Windows, with an emphasis on Internet Explorer.

That doesn't mean that Microsoft hasn't included any juicy carrots as part of the deal: part of the benefit to developers is personalized interaction with the Internet Explorer team, Microsoft executives said. There's also a free three-month subscription to BrowserStack, which allows a developer to quickly test a Web site on any (Windows) browser/OS combination through a virtualized cloud service, as well as some tips on cross-platform coding.

Based on conversations with developers, devs spend as much as 20 to 30% of their time testing for compatibility across the various operating system versions, Internet Explorer general manager Ryan Gavin said an interview. "The work we're trying to do here is to make developers lives a little easier," he said. "We want them to spend more time innovating, and less time testing."

What's Involved

The main features of Modern.ie break down into three parts: the free, three-month BrowserStack subscription, which usually costs $19 per user per month; twenty best practices for cross-platform coding, authored by Dave Methvin, the president of the jQuery Foundation and Microsoft evangelist Rey Bango; and a third tool, an automated scanner that will run against an existing Web site and seek out compatibility issues.

As part of the BrowserStack subscription, Microsoft will make available free virtual images for developers to download and run local versions of Internet Explorer with Windows for testing – even on Mac, Linux, or PC. Microsoft also created BrowserStack add-ins for developers using Chrome or Firefox.

The scanner tool also assists those developing for Microsoft. After simply typing in a Web page URL into the field, the scanner will first look for problems, such as an out-of-date jQuery framework, with older versions of IE - browsers that Microsoft might wish to die, but still hang around on older machines. Results break down into such categories as "Frameworks & Libraries" and "Web standards docmode" where problems, if they are found, are represented in the context of whether or not they will work with IE.

The scanner will also provide advice for developers hoping that their site will run well across a range of devices, both on the desktop as well as mobile browsers. (M-dot sites, such as m.sfgate.com, are supported, Gavin said.) Modern.ie's scanner recommends supporting features, not browsers, properly implementing CSS, and other techniques.

Microsoft also said that the scanner will detect issues on both Platform Previews and pre-releases of future IE platforms. If a developer agrees, and is properly authenticated by Microsoft, the scanner will pre-populate an email to Microsoft's IE developer relations team. Within 48 hours, the developer can receive advice on how to improve his or her own code, or be advised of bugs within IE and possible workarounds. There's also advice on how to implement the site as a Windows 8 live tile and implement touch support

Gavin said that Modern.ie would be set up as a developer-to-Microsoft interaction, rather than a community presided over by Microsoft developer relations employees. (Modern.ie does link to StackOverflow, a popular third-party coding site.) And Microsoft is pitching this as a gesture to the developer community, rather than a way to lure support. "There's no catch, but thank you for your cynicism," Gavin joked. 

Actually, there are: not only are the virtual images Windows-specific, but the BrowserStack deal will let developers test their code on any browser that runs on Windows. BrowserStack supports iOS devices like the iPhone and iPad, plus specific mobile devices such as the Amazon Kindle and older phones such as the Motorola Droid Razr and Samsung Galaxy S. The way Microsoft has phrased the deal, however, it's not clear that these will be included.

While developers historically complained about supporting IE, IE10 is probably Microsoft's most standards-compliant browser to date, although third-party evaluations tend to favor Google's Chrome in terms of HTML5 compliance. In an email, Lea Varou, an engineer involved with developer relations at the W3C Web standards body, said that modern.ie was useful for Web developers as a whole.

"Most of its tools are useful in general, not just for IE," Verou said of the site, via email. "For example, the free 3 month BrowserStack subscription can be used to test in a number of desktop and mobile browsers, not just IE. Also, their tool for checking mistakes and omissions in websites isn't particularly IE focused in the things it checks (with 1-2 exceptions if I recall correctly)."

"In general, I think modern.ie is a sign of Microsoft's turn over the last few years to embrace web standards and the open web platform," Verou added.

Microsoft's design has also begun influencing the direction of the Web, although that will likely be influenced by the success of Windows 8 and the so-called "Metro" interface. 

Still, the ties to the IE team, the scanner framework, and the little pushes towards Windows 8, are all to Microsoft's benefit. Microsoft's traditional fiefdom is the PC, and it needs to shoulder the burden if Windows, the PC, and IE are going to survive in a world driven increasingly by non-mobile browsers. 

You have a brilliant software idea. Now you need to design a good-looking prototype. You look around. You search high and low. Chances are you will dig up a sum total of three usable tools.

That’s right, three.

Rapid Prototyping Is A Wasteland

Welcome to the largely ignored world of rapid prototyping.

If you design on the PC, you can choose from three tools:

1. Axure RP ($290)
2. Mockup Builder (free)
3. Serena Prototype Composer 3 (free/$300)

If you prototype on the Mac, your three choices are:

1. Axure RP
2. Balsamic Mockups ($79)
3. Sencha Architect ($400)

Balsamiq Mockups is a cross-platform rapid software prototyping tool that allows a UX designer to quickly create a mockup of software screens. This is a prototype I created for a next-generation CRM program. One major quibble: no ready-made icons for folders or documents.

If you develop mobile apps or websites, there are more choices, including Protoshare ($29/mo.), a Web-based (SaaS) software solution and Tiggzi ($40/mo.). If you like to design apps entirely on the iPad, there’s AppCooker ($40), AppSketcher (free), Blueprint Lite (free), Interface HD ($10), iMockups for iPad ($7) and Mockop (free), plus many others.

According to an educated guess, there are some 12 million programmers worldwide. That’s equal to the population of metropolitan Los Angeles.

Now imagine you are one of those 12 million LA inhabitants, and you have only three, maybe four, auto repair shops to choose from. What’s wrong with that picture? The size of the global information technology industry was estimated at $3.8 trillion in 2012, according to Gartner.

The same CRM mockup created in Azure RP, another cross-platform prototyping tool, that creates more buttoned-up designs. Tools that address various software design work styles are much needed.

Here’s a another cogent example. I searched the Home Depot site for cordless drills and found 348 search results. Try it yourself. And that’s for a global power tool market that will reach only $27 billion by 2015.

The Disconnect Opportunity

Notice a disconnect here? In a previous post, I wrote about the need to create 1,000 user-experience (UX) design studios in the U.S. alone. These studios would require a healthy infrastructure of innovative rapid prototyping and coding tools. Yet it's clear that when it comes to creating software, designers lack much choice.

What type of prototyping tools are needed? For one, they should be collaborative. I know this because I found a sparse factoid on the design activities of programmers that suggests that unlike the relatively solitary activity of coding and testing, designing interfaces requires much collaborative work.

Finding the above statistic buried in a Microsoft site full of articles about finding bugs was a worrisome sign all in itself. You would think that, given a $4 trillion information technology economy, there would be a lot more research about software-design habits.

Please plug this innovation gap, entrepreneurs and venture capitalists! We need a lot more help to make software work the way it was intended. And do contribute to my crowdsourced ideation engine and suggest more ideas on what type of software is needed to help create a next-generation software economy.

Lead image courtesy of Shutterstock.

When Microsoft gave its first public preview of Windows 8 in 2011, the now-President of Windows Julie Larson-Green sent shockwaves through the Windows development world with just four words: "our new development platform." The reason? That platform was based on HTML5 and Javascript.

To casual observers, that makes sense. HTML5 is roaring to the forefront of development far faster than industry predictions. We even saw some commercial proof of the platform's "Write Once, Run Anywhere" promise in 2012. To seasoned Windows developers, though – particularly those building enterprise apps in dedicated Microsoft shops – it crushed their world. After spending decades learning to use different languages and development environments – most recently Microsoft's proprietary but feature-rich WPF and Silverlight – the thought of jumping ship for HTML5 was devastating.

Microsoft has backpedaled in a number of forums since then, assuring developers that while HTML5 is the new standard for cross-platform apps, other tools will continue to work for Windows-only development. But the writing is on the wall. HTML5 is the future, so if you develop enterprise Windows applications, should you bite the bullet and make the move?

Will HTML5 Save Enterprises Money?

The cost argument will rage for some time. One camp holds that HTML / Javascript developers are cheap and plentiful, so HTML5 is necessarily cheaper. The other side believes that instability of the HTML5 spec (only recently finalized and not scheduled for Recommendation status until 2014) compared to the more mature development environments available for "traditional" Windows development means developers can build complex applications faster, without worrying about tweaking things down the road.

The CTO of one small software vendor saw value in both views: "For our simpler apps, I can hire kids with good Javascript skills and let them learn the Windows specifics on the job. For really complex applications with tens of thousands of lines of code or more, It would be dumb to break what already works." He added that his more experienced Windows developers are mentoring the generally younger HTML developers to cross-pollinate knowledge. "Ultimately, each tool will have a use, for at least the next several years, and I want all of my devs to be able to pick the one that makes sense."

"Serious Coders" vs. "Script Kiddies"

His biggest problem so far is a reluctance to embrace change. "I have a couple 28-year-olds who act like grumpy old men, afraid that the 'script kiddies' without any real computer science knowledge are moving in on their turf. To them, HTML5 cheapens the application, dumbs down their resumes, and opens the door to a whole lot of bad coding from people who know how to make Web pages, but don't have any formal experience with structured coding."

The last point is probably the most valid. Knowing HTML and some Javascript isn't a particularly high bar, so enterprises need to be diligent about hiring and mentoring. If you pull developers off of Craigslist for $15 an hour, you're not going to get quality enterprise work. Even well-established Web developers coming from a LAMP background may not have the right experience. A mentoring program using Agile or another pair-programming methodology – can be a great way to ease Web developers into a more formal programing environment.

What Do Developers Want?

One long-time C++ and (more recently) C# developer wasn't excited about the rise of HTMLt5: "Eh. I get what they're doing. It's all about the portability of UI. They've been on that path for a long time, but whatever. The thing is, developers don't want to learn a new markup when Microsoft has already forced them to learn one recently. WPF / Silverlight is crap, but so was Winforms. If they'd skipped WPF, they'd probably have more success trying to get people to shift to HTML5... I'll go where the money is, though."

That last point is telling. Developers will follow the work, they really don't have a choice. And that it won't be long before everyone will be doing at least some work in HTML5. Smart enterprises will be begin mixing in some of that work now makes sense, but there's not yet good reasons for a complete shift.

Earlier this week I sat down with a startup working on an iPad app for news discovery. For several hours the talk revolved around user interface and experience, user acquisition and retention and the difficulty in penetrating a mobile market that is so flooded with apps that individual apps find it almost impossible to stand out. The mobile app industry has grown to mammoth volumes so quickly that even terrific products can't make an impact among the chaos. And without impact, there are no users and without users there is no business model. 

This startup is entering a field dominated by the likes of Flipboard, Pulse, Zite, News.me, News360 and several other new aggregation/curation apps. It is going mobile first (tablets specifically) and plans to roll out to the Web next.  I looked at the CEO of this startup and asked, very pointedly, “So what? What makes you think you can cut through all clutter to not only grab my attention, but keep it?”

The question was rhetorical and a bit unfair. I was not really talking about his specific product, but about any mobile app getting ready to launch. 

Several years ago, the call to action among venture capitalists and startups was to build new products “mobile first” and for the Web second, if at all. As it becomes increasingly hard to compete in the app market, some people are starting to rethink this strategy.

Rethinking The Mobile First Mantra

Prominent venture capitalist Fred Wilson was one of the first to endorse the mobile first movement, in a blog post in September 2010. Nearly two years later, Wilson has revised his views on the matter in a new blog post called What Has Changed. His new position: “think mobile first, but do not neglect the Web.”

Wilson notes that only a few apps have done extremely well going mobile only. Wilson quotes Vibhu Norby, co-founder of Everyme and Origami, who lists Instagram (which parlayed its mobile photo sharing app into a huge acquisition by Facebook), Tango, Shazam and, “maybe 2 or 3 others” as companies that have truly succeeded on a mobile-first basis. Mobile only social network Path might belong on that list, but “successful” in terms of user acquisition and retention might be a stretch for Path. If we look at success from a gaming standpoint, several mobile game makers have found success, most notably Angry Birds maker Rovio.

Norby continues, “I use my phone more than anything else. I just don’t think that an entrepreneur who wants a real shot at success should start their business there. The Android and iOS platform set us up to fail by attracting us with the veneer of users, but in reality you are going to fight harder for them than is worthwhile to your business. You certainly need a mobile app to serve your customers and compete, but it should only be part of your strategy and not the whole thing.”

Therein lays the rub. The acceleration of the Mobile Revolution makes developers and entrepreneurs eyes pop and rush to their favorite IDE to build what they believe in their heart of hearts will be the next big thing. Once the design and development work is done, they hit “publish” for the iOS App Store and Google Play, hope for positive TechCrunch reviews and wait for the users to come rolling in.

And are disappointed. Bitterly. 

The Staggering Numbers

Earlier this week, mobile analytics company Flurry reported on the massive growth it sees in the mobile app economy. Flurry tracks 250,000 apps from 85,000 developers, a massive slice of the app industry. In November, Flurry recorded a trillion app events (an event is when someone completes an action within an app, like recording a song). Flurry also recorded 60 billion user sessions (tracked by when a user opens and then closes an app). This data produces the classic “hockey stick” that charts explosive growth. 

Flurry then notes the amount of time people spend with their mobile apps per day in relation with the Web and television. Apps are catching up, Flurry says, with 127 minutes of app usage per day, in comparison with 70 minutes of Web and 168 minutes of TV (I would like to meet some of these people who use apps for more than two hours a day). Gaming dominates mobile usage (one reason Rovio does so well with Angry Birds) followed by social networking then entertainment and utilities. 

Developers see these metrics and tell themselves, “I can build an app and take advantage of all these eyeballs. It will be easy.”

The problem is that Flurry equates this massive growth with opportunity. In reality, this growth can actually make it more difficult for mobile app developers to succeed. The barrier for entry for a significantly successful mobile app has never been higher. There are more than 1.4 million apps between Android’s Google Play and the iOS App Store. Add in another 200,000 or so on between BlackBerry World and the Windows Phone Market and, well, those are staggering numbers. Of course, there are duplicates among and within the app stores (you can find Instagram on both iOS and Android, for instance) but the amount of unique apps vying for attention is immense. 

“Mobile and apps are gobbling up the Web and consumer Internet, and that’s where the opportunity is. And the opportunity has never been bigger,” Flurry’s CEO Simon Khalaf notes in the blog post. But Khalaf also notes the very problem plagueing would-be app makers. “Traffic acquisition is still an art more than a measurable science. No one has defined a set of metrics that the venture industry can use to universally compare the value of one app property to another, and business models on mobile are still new,” Khalaf writes. 

The app economy is incredibly top heavy - the biggest and brightest taking the lion’s share of revenue. Research firm Canalys reports that the top 25 app developers in the United States account for nearly 50% of all revenue. Most of those are gaming companies like Zynga, Electronic Arts, Disney, Rovio and Glu. Games accounted for 145 of the top 300 apps in the iOS App Store and 116 of the top 300 in Google Play. This covers only app sales and not necessarily advertising revenue or in-app purchases, but it makes sense that games dominate the app economy. Flurry’s data supports this, with 43% of time spent on mobile apps being some form of gaming. Flurry’s analysis from July shows that 32% of revenue for apps on iOS and Android go to the top 100 apps. 

The paid download economy for mobile apps is likely to be in the vicinity of $10 billion in 2012. That's big enough that the long tail of the app economy can make money - but with anywhere from 32% to 50% of revenue going to only a handful of app makers, the chances of big success in the long tail (where 99% of apps live) is slim.

Wilson also notes that the cycle inherent to gaining users in the mobile first world is difficult to master on any type of large scale.

“… [D]istribution is much harder on mobile than web and we see a lot of mobile first startups getting stuck in the transition from successful product to large user base. strong product market fit is no longer enough to get to a large user base. you need to master the ‘download app, use app, keep using app, put it on your home screen’ flow and that is a hard one to master,” Wilson wrote. 

Mobile First Or Multi-Channel From The Start?

The problem with the mobile first approach is user acquisition and retention in the face of immense volume. Even the best built, most beautiful apps will fail if their creators cannot rustle up enough eyeballs.

So, we come back to the original question: Do you build for mobile first from the beginning or do you build for multi-channel distribution knowing that it might take more time to get the service off the ground? A mobile-first approach implies that, for a significant period early in your apps life, it will be mobile only. And that can be a problem.

To a certain extent, it depends on what you are building. Games are much easier to make mobile because they are self-contained units specific to the device they were downloaded on. Yes, it would be nice if I could pause a game of Angry Birds and move from my tablet to my PC and pick up at exactly the point I left off, but this is not really necessary. WIth a news app or a social network or a photo app or a music app, users very much want to move from their smartphone or tablet to their computer and back again with as much ease as possible. For every Instagram that survives the mobile-only world, there are startups like Path where mobile only might be one of its biggest detriments. 

Norby gets to the heart of the mobile-only conundrum: It's much easier to get new users on board a service on the Web than on a mobile device. 

“… [T]he experience of signing up for a service is superior in every way. Typing is easier. Sign-up with OAuth is faster. Tab to the next field. Provide marketing alongside sign-up as encouragement. Auto-fill information is a feature in every browser. The open eco-system of the web and 20 years of innovation has solved many of the most difficult parts of onboarding. With mobile, that kind of innovation is lagging significantly behind because we create apps at the leisure of two companies, neither of which have a great incentive to help free app makers succeed,” Norby wrote. 

Developers need to think of more than just the product they are creatiing. “Will it work on Android? iOS? Windows Phone?” is an important question, but it's secondary to “What do I need to do to turn this into a viable business?” 

That business question is often lost among excited developers building a great app. Ironically, it is one reasonswe end up shedding tears for all the crappy startups that can’t raise any more money. It is not enough to build a great app, throw it into the celestial ether, maybe do some press outreach and marketing and hope for success. There are too many startups building apps, not businesses. 

Mobile apps that come to the fight with the appropriate tools in place give themselves the best chance of success. That means a website to easily onboard mobile users and give them information, a plan for marketing that offers a chance to reach the top lists on the app stores, and a consistent message to the press and consumers.

Sound like a lot of work? It is a lot of work. It takes time, money and patience - on top of everything that goes into creating the app itself. 

The era of easy riches in the mobile app economy is over. The first movers have consolidated their positions. Sure, there are still a few lucky stories (like this Dental Surgery app that came out of nowhere) or outliers that fall into success without the requisite groundwork - but they are increasingly rare.

That doesn't mean the mobile market still doesn't offer immense potential for riches. And designing a business with a mobile-first mentality is definitely the way to go. But make no mistake, rising above the noise with a mobile-only product is getting harder and harder - no matter how good the app may be.

Top image courtesy of Shutterstock.

Welcome to your "official" support site, Web developers. The Web’s top four browser developers - Google, Microsoft, Mozilla and Opera - teamed with the World Wide Web Consortium (W3C) and technology companies including Nokia, HP, Adobe and Facebook -  to create Web Platform Docs, a Wiki devoted to sussing out and stomping bugs and other issues when trying to develop for multiple browsers.

Obviously, the effort primarily benefits developers, but it should eventually result in a greate number of sites that work properly no matter what browser you use to access them.

Other sites already provide the same sort of collaborative approach to development, including SitePoint and especially StackOverflow, which uses the same votes/answers model of presenting questions and answers. In those sites, designers and developers work together to develop solutions, with some participation from members of the individual browser companies. 

The idea is to smooth Web development, eliminating bugs, development costs and headaches. In one example cited by Microsoft, Erik Klimczak, creative director at Clarity Consulting, had been using a common trick to make an image uniformly scale, but found out it didn’t work on a particular browser. After contacting the browser’s development team himself, he found that the feature was supported, but in an undocumented feature.

A Cooperative Venture

All of the major browser makers have committed to funding the site and providing resources, according to Ian Jacobs, the head of communications for the W3C. He was unable to say, however, what the extent of each company’s contributions would be.

“I think the first thing to note is that there are many great sites out there, but one of the challenges we’ve heard from developers is that when you look at all the sites around there it’s time-consuming, and there might be inconsistencies,” Jacobs said. “Vendors, when they put up information, it may be generic, and it might be proprietary, and so we want to the W3C membership, and said we’d like to do the same thing we do with membership, which is to leverage the collective effort... and remove redundancies, remove inconsistencies and make it easier to find things.”

In an email, a spokeswoman for Google said that the company wouldn't disclose its financial commitment: "We don't disclose any financial terms or details, but in regards to maintenance of the site, the community and some people from the stewards organizations will continue to work on and monitor the site."

Microsoft provided a bit more detail: "The role of stewards is intentionally limited in favor of self-governance by the community," a Microsoft spokeswoman said in an email. "Stewards focus primarily on facilitating the long-term operation of Web Platform Docs. In practice, this means that stewards provide Web Platform Docs with funding and relevant infrastructure, while helping the community address issues that may arise that the community is not able to address. The stewards do not manage the content of the site, nor do they define the processes the community adopts to manage itself, unless requested to by the community. Although some representatives of the stewards participate in developing the site, they do so as peers of other members of the community."

You'll Find What You're Looking For

One of the site’s strengths, according to Jacobs, will be the inclusion of clear, ordered documentation from the W3C. Visitors to the site will find published content from the founding organizations, including more than 3,200 topics from the Microsoft Developer Network, Microsoft said. In addition, there will eventually be a sample library that takes into account real-world scenarios, and tutorials that provide guidance on how to use new and existing technologies.

That may mean that the documentation content will favor IE, at least in the early stages. A generic search for “Chrome” in the documentation portion of the site favored IE in most of the results, although expanding the results offered up more choices. (For example, in the page describing CSS properties for font size, portions of the content were pulled from MSDN, and there are several MSDN links at the bottom.) The Web Platform Docs site does claim that it’s still in an alpha status, however.

“With Web Platform Docs, we now have a central place where we can learn what the standard is, when we can use that particular feature, and the right way to use it,” Rey Bango, a Windows technical evangelist at Microsoft, said. “That’s important to me, and it’s important to Web developers. They want to take advantage of the cool stuff - the toys - and they want to do it responsibly. This site gives them that capability.”

Hands-Off Approach

According to Jacobs, the site will take a hands-off approach toward managing content, allowing users who achieve the same level of expertise - which appears to be assigned through a points system - to achieve the same status as representatives from the browser developers themselves. Content will be developed as much by the users as much by the companies. 

“We decided that it would be better to open up Web Platform Docs to the community as early as possible, so that everyone – including you – can help expand and refine the documentation, and ultimately define the direction of the site,” Alex Komoroske, a project manager with Google’s Open Web Platform team, said in a blog post. 

Jacobs also said that the “official” nature Web Platform Docs site won’t prevent a free-wheeling discussion. That should mean that a developer who asks about a controversial topic, or who makes a claim about which browser correctly implements a CSS feature, for example, won’t be moderated down just because one of the site’s members disagrees with the premise. Don’t expect a discussion of proprietary technologies like Javascript, Jacobs added; however, nothing’s truly “out of scope,” he added.

“One of the great things is that we have the attention of the vendors. And while they’re keen on accuracy, the policies of the site won’t restrict the nature of the discussion,” Jacobs said.

Do Not Track, a tool designed to afford users privacy as they browse through the Web, will be active by default when users install or first-run Internet Explorer 10 in Windows 8. But in an effort to save Do Not Track, one developer for the popular Apache Web server is trying to to add a feature in Apache that will actively ignore any Do Not Track settings from any future IE 10 users.

The controversial choice was made by Apache HTTP developer Roy Fielding, who actually authored part of the standard that dictates how Do Not Track (DNT) is supposed to work. The patch proposed for the popular Web server would effectively make all websites running Apache servers (about 60% of the world's total sites) blithely ignore IE 10 browser's requests for DNT -precisely because the feature is pretty much turned on by default.

Security By Default Is A BAD Thing?

Confused? It's easy to get lost here, since one would think that a security feature that's turned on by default would be a good thing. But Fielding has taken exception to this practice, taking the extraordinary step to specifically short-circuit Microsoft's plans, which he sees as ultimately trying to bring DNT down.

Here's how DNT should work: a user decides that he or she does not want their information tracked by advertising and marketing sites and vendors as they surf around the Web. So they go into the settings of their browser (IE, Firefox or Chrome, to name the three most popular) and turn on DNT.

After that, every time they visit a new site that would like to track them, the user's browser sends a signal within the HTTP header informing the target website not to track that user. If the website's managers and developers (as well as the advertisers paying to be on that site) choose to honor DNT, then the user will be allowed to go on their way unmolested by cookies and other such tracking measures. Note that participation by websites is voluntary.

Microsoft Turns On Do Not Track in WIndows 8 / IE 10

In late May, Microsoft announced that DNT would essentially be turned on by default in IE 10 when the new browser is released within Windows 8, due out in late October.

"Consumers should be empowered to make an informed choice and, for these reasons, we believe that for IE10 in Windows 8, a privacy-by-default state for online behavioral advertising is the right approach," wrote Microsoft's Chief Privacy Officer Brandon Lynch at the time.

In August, Lynch elaborated on how DNT would work in IE 10 and Windows 8.

"DNT will be enabled in the 'Express Settings' portion of the Windows 8 set-up experience. There, customers will also be given a 'Customize' option, allowing them to easily switch DNT 'off' if they'd like," Lynch indicated.

Do Not Track Only Counts If It's A "Choice"

Not everyone agreed with Lynch's judgement. Certainly not Fielding, and not Microsoft's chief browser competitor Mozilla, makers of the Firefox browser, who believe that DNT should represent the user's wishes, not a default setting from the browser maker.

After Lynch's initial May announcement, Mozilla's Privacy and Data Policy Manager Alex Fowler blogged, "DNT allows for a conversation between the person sitting behind the keyboard and the site that they want to visit. If DNT is on by default, it’s not a conversation. For DNT to be effective, it must actually represent the user’s voice."

Surprise! Advertisers Don't Like The Default Option

That theme was avidly picked up by the Digital Advertising Alliance, which conveniently announced that it would not honor DNT from any user that had the setting turned on by default. Of course, since there's no way a website can tell if DNT was flipped on by the user or set at the factory, the DAA basically washed its hands of having to honor DNT at all. (Or at the very least not honoring it for IE 10 users.)

Fielding's stance falls in line with Mozilla's. In the comments to his patch to the Apache Web server defending his stance, Fielding wrote, "[t]he only reason DNT exists is to express a non-default option. That's all it does. It does not protect anyone's privacy unless the recipients believe it was set by a real human being, with a real preference for privacy over personalization."

What Does "Choice" Really Mean?

Fielding's patch has stirred up a firestorm of protests in the Internet developer and user community, with opponents arguing that Fielding, and by extension Apache, has no business dictating for millions of potential IE 10 users that privacy settings they thought were turned on will now be effectively negated.

"My biggest concern with all of this is the fact that Apache thinks its OK to be the standards police like this," blogged Yammer JavaScript engineer Oscar Godson, "It's making the conscience decision to interpret a spec and give punishment to a vendor for not following it exactly (I think Microsoft did, but that's beside the point). That’s just not how we've all decided to do the whole standards thing. We decided that we were going to stop with with the 'this site looks best viewed in…' banners and instead organically get vendors to follow along, not force them into following it and punishing users while they’re at it."

Questioning Motives?

Since Fielding is also one of the authors of the DNT standard, which is currently in draft form, questions have also been raised about Fielding's motivation. In his day job as a principal scientist with Adobe Systems, Fielding's employers would have a vested interest in keeping tracking from being avoided.

"Do you honestly believe it's coincidence that the patch was submitted by an Adobe employee, given their position in the market? Do you not see how they benefit if the most widely used webserver (Apache) ignores the setting in the most widely used browser (IE)?," commented developer Andy Cadley.

But Fielding contents taht there's conspiracy to be found here, it's coming from Microsoft acting as an agent provocateur.

"Microsoft deliberately violates the standard. They made a big deal about announcing that very fact. Microsoft are members of the Tracking Protection working group and are fully informed of these facts. They are fully capable of requesting a change to the standard, but have chosen not to do so. The decision to set DNT by default in IE 10 has nothing to do with the user's privacy. Microsoft knows full well that the false signal will be ignored, and thus prevent their own users from having an effective option for DNT even if their user's want one. You can figure out why they want that. If you have a problem with it, choose a better browser," Fielding argued.

In that context, Fielding claims to be actually trying to protect the standard as it is exists, and give organizations like the DAA less of an excuse to ignore DNT.

Whatever his reasons, patch may amount to little more than a political statement from Fielding. To date, his patch has not been accepted by the main Apache team, so it isn't yet part of any official Apache release. And even if the patch were accepted, it will be a simple matter for Web masters to turn it off.

Still, the controversy is raising new questions about the very viability of Do Not Track at a time when it is being targeted by advertisers who still want to gather that all-important user data. Fielding's medicine could be worse than the disease, but in yet another irony, that may be exactly what it takes to get the online industry to keep paying attention to their privacy obligations.

Images courtesy of Shutterstock.

Prior to the library, getting things out of the Google Analytics API wasn't a trivial process. According to the post announcing the feature, developers had to learn the API, then figure out how to handle authorization, and then meld the data with another visualization library. Fun for some developers, but definitely not speedy. And when has management ever said "we'd really like a better dashboard for our Web traffic, but take as long as you like to come up with it"? Right, so something better was obviously needed.

The Easy Dashboard Library

Google worked with students at the University of California, Irvine to come up with something better. The Easy Dashboard Library has three basic steps: Set up API access with an OAuth 2.0 client ID; copy and paste some code; and configure the code to query data and select your chart type.

The post from Google demonstrates how to create a quick-and-dirty chart for pageviews, visits and visitors over the last 30 days. You can test out a demo on Google Code, where the library lives.

Developers have the option of using line, bar, pie, table or column charts. The demo shows a pretty simple query, but developers can set queries using all kinds of dimensions and metrics supported by the Core Reporting API. It looks like developers can also use the data with another chart API if they prefer.

If you still don't think it's quite easy enough to use or would like to see additional features, you may be in luck. Google is planning to work with another group of students at the university for the next three quarters. The main goal is simplifying the library, but Google is also encouraging feedback via the Google Group for the Easy Dashboard Library.

Given the prevalence of Google Analytics, this should be good news for a lot of developers. It should also make custom dashboards more accessible even to more casual users, who might not have been eager to spend the time needed to get up to speed with the Analytics API but can ramp up pretty quickly with the Easy Dashboard Library. If you've taken a stab at using it, or have any recommendations for working with Analytics data, let us know in the comments.

As we reported yesterday visual content is continuing its steady rise in dominance over written content. But that doesn't mean we should give up on good writing: if anything, it means we need to think harder about how we write for online readers.

Online Readers Are Different

Seems pretty obvious, right? But the fact is, many of us still write the same way online as we do for books, magazine articles and other long-form and traditional print mediums. Research hightighted in books like Reading In The Brain shows that online readers use vastly different sections of the brain than offline readers. In short, the brain is conditioned to skip around when online reading, as clicking on a link, for example, will reward the brain with new images and content.

With offline readers, we can take our time and develop points with long blocks of text and narrative, and with fewer visual elements. Offline reading rewards the brain that slips into a state of deeper concentration.

In Plain English, Please

Your writing - offline or online - is effective when readers take away your message. Writing effectively online doesn't mean that every reader reads every single word that you write (and even if they done, Dale's Cone of Experience argues they'll ownly remember 10% of what they read). It means they can quickly and efficiently get the information that is most important to them and move on.

People who read our blog posts come from all over, and from a wide range of backgrounds. The reason they choose to read a particular post will vary from reader to reader. Your job as the writer is to make sure they can find the information that is most important to them and move on to using that information.

Best Practices

I've spent a good portion of the past two years researching reading habits of online readers and have been sharing that research with writers, bloggers and journalists, as I did during my presentation at BlogWorld East last May and as I continue to do with my students at the college where I teach.

I can talk for hours on the subject, but if asked for the most effective ways to get online readers to read what you write, I would offer these strategies as the most important, which are backed up by eye-track studies as being an effective way to get your message across to online readers:

1. Write compelling but clear headlines: Don't get cute. Online and in print, the headline is almost always the first thing readers look at. Make sure it is clear and gives a good idea of what the post is about, while still leaving the reader wanting more.


2. Write in the active voice: Effective online writing is all about getting to the point, and on a line-by-line basis, the most effective way to do that is to use the active voice, which naturally lends a sense of urgency to your writing. The easiest way to do that is to start each sentence with the subject, immediately follow that with a strong, active verb, and then follow that with the direct object. Avoid adverbs: they're a telling sign that you chose the wrong verb.


3. Online writing is visual: Long, dense paragraphs turn off online readers. Create white space in your copy by keeping paragraphs short and using bulleted lists when appropriate. Use bold text to accent key information and use block or pull quotes to draw readers into the copy.


4. One main idea per sentence: Keep sentences on point. Avoid multiple clauses and phrases, and lots of information stops and commas. Make sure each sentence has one idea, and not much more than that.


5. No sentence without a fact: Every line you write needs to move the story forward. If a sentence doesn't have a fact, cut it.

How long should it be?

I hate this question and always offer a smart-aleck answer: as long as it needs to be. If every sentence has a main idea and no sentence is without a fact, keep going. I do, however, recommend the 3-2-1 formula. For every 1,000 or so words that you write in an online article or blog post, be sure to include:

• Three subheads: Subheads are bold, one-line headlines that break up long chunks of text and organize information. Keep the same headline-writing rules in mind when you write subheads.


• Two links: Links offer additional information for readers who want to go deeper, and they also give your post authenticity and transparency about where you information came from without getting into long, narrative attributions.


• One graphical element: A photo, a chart or anything else visual helps readers. Whatever you use, make sure it advances the story: don't just put a photo in the post for the sake of posting a photo.

A week later, the W3C has overridden the decision, restoring the <time> element back to the HTML5 spec.

The <time> tag, as its name implies, is intended to designate timestamps and other time-related data on Web pages. This adds additional semantic context to this type of information when it shows up on the Web and makes it more machine-readable.

It also gives front-end developers the opportunity to more easily style timestamps using CSS. This of course, could always be done by assigning a unique class or ID name to whatever HTML tag happened to contain the date and time information, but giving <time> its own tag simplifies things a bit.

The element was initially slated for removal from the spec by HTML5 editor Ian Hickson. The move didn't sit well with many developers and semantic Web advocates, a sentiment that ultimately trickled up to the W3C working group overseeing the development of the HTML5 specification.

Not content to settle for what's possible, Adobe has recommended some specifications to the W3C that will allow CSS to create much more fluid, flexible layouts.

CSS Regions is a module that builds on the column-based layout options now available in CSS3 to enable front-end developers to flow text across different columns (or "regions") on a page. This allows for more dynamic page designs, which can shapeshift to fit different devices and device orientations on-the-fly.

The CSS Regions standard recently made its way into both the WebKit browser engine project and latest Chromium release, and will also be supported by Internet Explorer 10.

Another improvement to CSS proposed by Adobe is called Exclusions, which lets developers flow text into a non-rectangluar shape, or to wrap it around graphics on the screen, much like what's been possible in desktop publishing for decades. Check out the video below for examples of these new standards at work.

In the meantime, a Brazilian company called Movile has launched a new version of its Web app store, Zeewe 2.0, which incorporates some key HTML5 features and could provide a roadmap for U.S. developers, like Facebook, in creation of a Web app store.

Offline Caching

One of the features of HTML5 is the ability to use offline caching to create Web apps that work when you do not have an Internet connection. This is essentially what Movile has done with Zeewe 2.0. The app store will function just fine, even if your smartphone is in airplane mode.

Offline caching means that Web app downloads up to 10-times faster than the original version of the store. We have seen various U.S. developers, like Amazon and Mozilla, start implementing offline caching in their apps. The browser does not need to go back to the server for data retrieval. Currently, four main Movile partners have games that will function with the data caching aspect as well: Block Dream, Blast Effect, Checklist and Card Flip.

The faster an app store is, the more likely that users will click through to buy and app. Once a user has an app, Movile hopes that they will then use their new payments API to push users towards in-app purchases.

Carrier Billing Partnership With Zong

Movile has created a roadmap that a company like Facebook should take note of. HTML5-based applications tied through carrier billing and the mobile browser. It is about as easy a formula to follow for a consumer than almost anything else in the mobile realm.

Movile head of innovation Eduardo Lins Henrique told ReadWriteWeb that almost 60% of the apps available through Zeewe are from game developers. That would mesh with what we have seen from domestic developers - the gamers are on the forefront of the HTML5 push. Henrique also said that there is an adult content section to the Zeewe store, something that most U.S. HTML5 developers will probably shy away from. Yet, do not discount the ability of the massive adult content ecosystem to push the envelope of HTML5 development.

Does Movile have the right model? How long before something similar comes from a prominent developer in the United States? Let us know in the comments.

It's for the cross-platform utility that magazine publisher Hearst Magazines has announced a plan to convert all of its websites into HTML5 sites, starting with Good Housekeeping.

The benefits to Hearst are obvious: one site per magazine title that works across devices, instead of multiple sites for each device. But there are benefits to Hearst's readers too, primarily that the user experience will be mostly the same for a particular website - no matter which device is used to access it.

The first Hearst website to undergo an HTML5 redesign was Good Housekeeping, the venerable women's magazine founded back in 1885 (you wouldn't get away with launching that brand name nowadays!).

I tapped into my inner 1950s American housewife and checked out the new site on 3 devices: PC, iPhone and iPad. It displayed very well on each device, including the drop down menus - often a good test of mobile website functionality.

PC version

Perhaps being overly boastful, Hearst claims that HTML5 is "more comprehensively used in this site [Good Housekeeping] than practically any other media site that we know of." I'm not sure if that's true, especially since Boston Globe just launched an HTML5 redesign.

Hearst plans to implement HTML5 redesigns for the rest of its network over the next 18 months.

This is a great initiative by Hearst and we expect to see many other media companies roll out HTML5 websites over the next couple of years.

iPhone version

iPad version

The W3C's new Community Groups allow any developer to propose a working group for a proposed standard. As soon as there is some degree of support for the standard among peers, the group, which is free to participate in, can get started.

Similarly, industry and business representatives who want to create or contribute to the development of Web standards can do so via Business Groups, which offer a "vendor-neutral forum for the development of market-specific technologies." The first Business Group will be one specialized for the oil and gas industry.

"Innovation and standardization build on each other," said Jeff Jaffe, CEO of the W3C. "The stable Web platform provided by W3C has always encouraged innovation. As the pace of innovation accelerates and more industries embrace W3C's Open Web Platform, Community Groups will accelerate incorporation of innovative technologies into the Web."

Previously, the only way to contribute to the creation of a standard was to present it through a W3C working group, where it may or may not get any traction and move forward. With the introduction of these new groups, developers and businesses can get more directly involved in the adoption of a standard, and can do so with access to the W3C's infrastructure.

Jaffe first told us about the groups in a session at the ReadWriteWeb 2Way Summit in June.

The W3C isn't wasting any time getting started with this new initiative. The first groups to launch will include Web Payments, Semantic News, XML Performance and Declarative 3D for the Web Architecture.

The search giant's recent beta launch of its Page Speed Service gives us the latest in a long line of products and tools designed to help site owners boost page load speed. In what is by no means a comprehensive list, we've outlined a few such tools worth checking out.

First, Measure Your Site's Speed

The first step toward speeding up your site's load time is to determine what that load time is. What you experience loading the site may be different than somebody on a different Internet connection, using a different browser or in a different physical location. There are quite a few tools out there for page load speed testing.

Pingdom

Pingdom is a site that tests page load time and breaks down how long it takes for every script, CSS file and media asset to load. You can use the resulting chart to make decisions about things like whether to consolidate your CSS files or whether a content delivery network (CDN) might help deliver images faster.

In addition to page load time, Pingdom lets you test your DNS settings for issues and perform a ping or traceroute to test network connectivity to your server.

YSlow

Yahoo's YSlow has been around for a few years but it's no less useful today, even with the arrival of several new competitors on the market. YSlow, which is available as a browser plugin for Firefox and Chrome, clocks page load time and then provides a detailed report card, complete with letter-based grades.

Unlike some other tools of this nature, YSlow goes the extra mile by offering specific, actionable tips about how to improve page load time. Their Best Practices for Speeding Up Your Website is a worthwhile read for any Webmaster or site owner, regardless of whether or not you use Yahoo's tools.

Google Page Speed

Google has been incresingly fixated on speed as of lately, both in its own products (see Chrome and Google Instant) and the Web at large, having announced last year that site speed now plays a role in organic search rankings.

Before releasing a few tools designed to actually speed up your site (more on that below), Google put out its own answer to Yahoo's YSlow called Page Speed. It's available as a browser extension and also a Web-based test. It's pretty similar to YSlow in that it returns a series of specific action items that, if undertaken, would improve a site's load time. It ranks those suggestions by priority, which is helpful in assessing what to tackle first.

Improve Your Site's Load Time

Once you have an idea of how much improvement is needed, you can begin implementing the right solution. Inevitably, some of the necessary changes will require some manual coding, but there are a few turnkey tools that will help.

Google's mod_pagespeed and Page Speed Service

In addition to its site speed measurement tools, Google offers a few ways to actually do something about your sluggish Website. The first is mod_pagespeed, a module for Apache that rewrites the HTML, JavaScript, CSS and image assets on a page and serves them to visitors more efficiently. More recently, Google introduced Page Speed Service, which achieves the same thing through DNS changes. Google may charge for this service in the future, but for now the beta is free.

Other Content Delivery Networks

One of the most effective ways to boost a site's load time is to deliver its static elements over a content delivery network (CDN). There are many CDN's available at different price points.

Some of the better known commercial CDN's include Akamai, Limelight Networks, BitGravity. Here at ReadWriteWeb we use MaxCDN, which is a relatively affordable solution. CloudFlare is a product that specializes in Website security but has content delivery and site speed enhancement features built in. Amazon Web Services customers might want to look into Amazon CloudFront.

Minify and Merge Your Code For Faster Load Time

Another common culprit that drags down a Website's loading speed is code that hasn't been consolidated, especially CSS and JavaScript. While you could manually remove whitespace from the code and consolidate the number of external files, there are a few automated tools to help make it easier.

MinifyJavaScript is a simple, Web-based tool for compressing JavaScript right in the browser. Similarly, this site will do the same thing for JavaScript and CSS using Yahoo's YUI Compressor.

Minify is a PHP-based tool that developers can use to automatically compress and consolidate external scripts and stylesheets. There's also a Wordpress plugin for it.

Photo courtesy of Flicker user Nathan E. Photography