Why not do more, much more, with mashups?
Mashups are today used either in widgets supplied by online service providers, or built by hand by developers for particular sites and pages. Thinking about generalizing and simplifying the usage of mashups and the creation of web widgets, came the idea of creating a dedicated online service, Patapage.
Some definitions and references
I’ll start by quoting the Wikipedia definition of mashup:
In web development, a mashup is a web page or application that combines data or functionality from two or more external sources to create a new service. The term mashup implies easy, fast integration, frequently using open APIs and data sources to produce results that were not the original reason for producing the raw source data. An example of a mashup is the use of cartographic data to add location information to real estate data, thereby creating a new and distinct web API that was not originally provided by either source.
And also that of mashup enabler:
In technology, a mashup enabler is a tool for transforming incompatible IT resources into a form that allows them to be easily combined, in order to create a mashup.
Now mashups are mostly used by developers, in particular, JavaScript developers. A nice and typical example is this one:
How to build a personal mashup page with jQuery
and the result is this:
where we see the date collected and displayed. Notice that this is all done purely in JavaScript on the client, also using Yahoo Pipes service; but this requires some development and maintenance, and the server side service has to be already available; you cannot build your own service without installing and maintaining your own server. Another widely used option is to use the web service provider widget (“web widget”), where the style is more or less fixed.
Our idea
Our starting idea was… why not give even more power to site builders on the client side by relying on a unique, simple service, acting both as direct content manager and as “proxy” for other services? The fact that Ajax calls allow to add and call Java scripts on say a button click to an existing, fully loaded page, and then by making cross domain requests it becomes possible to add contents to (over) the calling page, opens a world of possibilities, which up to today has been used only by developers of both client and server side code, by low level access to such features and then lots of hand coding.
Couldn’t it be easier? Couldn’t the HTML designer be spared of (re)building specific client readers and server-side services, and focus on just integration and building a beautiful and friendly site? And even if you are a server-side developer, why not delegating web site content building to a third party, and focus on your main activity?
Why use mashups only to add RSS aggregation, pull data from social sites and multimedia contents? Why not use for any kind of dynamic contents? Why use it in blogs and not web sites? The structure of web site is more complex, and the services needed more refined, at times, but that’s no obstacle to the idea.
Also in case of hand built integrations, the graphic quality of the integration is often not at the same level of the originally designed site.
This is where we started thinking about a new online service, and then started building it up. In mashup terms, we started building friendly data sources to be called and used on button and link clicks; then we standardized even the buttons and links, so that the web builder has just to paste the button script on the page, and gets immediately fully working buttons, links and associated services.
Since we had the service up, almost every day a new possibility of a button comes up, as the sum of serving both the client side JavaScript and the server side content, or proxy to contents, opens a lot of possibilities. See in the side picture just the first suite of buttons.
More are being added, like a Delicious aggregator, Picasa integration, custom designed forms; the existing ones are being extended, like the Wiki-button will allow creations of new pages from links, like Wikipedia.
What superficially looks like a single functionality, like adding a wiki-like button (“PataWiki”), actually adds to your web page a layer of dynamically updatable content, by both the site maintainer and site visitors (if that is what is wanted). This could be a “help” page, contributed contents, a “more in depth” presentation, a “buy now” page (we’ve seen it online used this way already), a way to publish news, …
Each button / link you paste in your pages is associated with a “page id”, which the designer can set by hand: this way the same mashup / widget combination can be used across the entire site, on a single page, or shared across a specific group of pages. This is a flexibility that usual mashup on blogs don’t need, as these are basically single paged, , but is a necessary extension for using mashup effectively on web sites.
-
We also developed a web based configuration of buttons and opened windows, which allows setting of style, dimension and layout. This is what you had to do by writing code and HTML by hand when displaying the contents of mashups – before Patapage 
. Of course if the designer wishes, she can customize the layout of the buttons integrating in the existing layout, as done in this example.
Another recurring problem when adding the possibility of visitors contributing and commenting your pages is that of spam, moderation, e-mail verification and in general of security. Like for example if you enable moderation, you have both to reassure users about their contribution, manage the incoming list to be moderated, notify on approval, etc.: imagine having this by just pasting a little script on your static site instead of configuring a CMS to do that! And you should be able to do this differently for each link or button, if you wish so.
The resulting application is not only a mashup enabler as defined at the beginning, but also a tool providing mashups of all sorts ready to be used.
So we are covering the problems of layout, contents, social contributions, notifications, security… all typical problems traditionally requiring installing your own CMS. This way we are empowering links on the web pages of a site that is preserved as it is, with all its style, effectively progressively making classical CMS’s site development look like stone-age site building.
All this functionality is available in an online service, currently in beta, which we called Patapage1,
from there you can try the demo, see a video, and just enroll and try it on your site. When out of beta, the service will be a paid one (see here for details) which will be a way of keeping it ad-free: as one of our ideals is to give as much as an unobtrusive service as possible, channeling ads would result in just the opposite. We also believe that using a commercial service is a higher guarantee for the users.
I’d be glad to read your impression of this idea – use the comments, or tweet me.
[1] Raymond Queneau has described ‘pataphysics as resting “on the truth of contradictions and exceptions.” Well.. we just liked the sound of the word.
Java is just fine for your online service startup development
There is a commonplace going round according to which Java/J2EE is not an appropriate development platform for startups creating online services. This commonplace is repeated again and again,
e.g. on answers.onstartups.com How to pick a platform for a startup web 2.0 app?
stay away from J2EE. J2EE is too heavyweight. Takes too long to develop. Its great for consultants because it means more billable hours but not good for nimble startups
or
Java is too expensive. Higher initial investment for hardware, human resources, and too much code to write to do just simple thing. A startup can’t afford it.
I hope to show in the following that this is simply false.
The origins of the commonplace
As most commonplaces, they are simply the repetition out of context of something true in context, and all those who have followed Java and its evolution in the last ten years, and the coming and going of many, too many, architecture astronautic – inspired frameworks and fashions, there has been no lack of context where Java has been and is used in absurdly convoluted ways; but this is history, boring, and by now not very interesting. And of course the point is that there is nothing in the nature of the language and tools that forces you to use complex solutions.
My point is the opposite of the commonplace: if you have Java expertise, you are in an advantageous position to start developing an online service.
Using Java for your online service will lead you to a change of focus from corporate development, together with a complete revolution in marketing strategy; it is likely that the business logic involved will be relatively simple, you won’t need to redistribute your code, you won’t need say to certify it for some complex pharmaceutical software standard; other different, complex problems will come to the surface. But this will happen whatever language / framework you are using.
A pragmatic attitude
The quoted common places assume that being a Java programmer simply means the lack of pragmatic sense; but why should that be? Surely there is no entailment there.
Lets tell a few simple facts that most experienced developers are perfectly aware of, but don’t say in conferences: you can write excellent applications and never ever write a single line of unit testing and Javadoc. And put all the time you saved from writing and fixing bugs in the unit tests ( 
) in having human testers try your application, and in this way get feedback worth a million times what your own self-test would tell you (assuming optimistically that the code-based tests are bug free). Also human users will tell you about interface bugs that no code test will ever do, like about the dark gray buttons on a black background, or the unpredictable series of clicks ad back which users find so intuitive and code tests will never cover. You can be self-satisfied with your unit tested and JavaDoc-umented code (remembered to update it all by hand after the last refactorings and fixes?), and release a totally unusable program filled with what for the user look like serious bugs, though you didn’t perceive them as so.
Having a firm pragmatic and user oriented attitude is not at all in contrast with using Java for development: you can be a talented duct-tape programmer, and indeed use Java.
We should all be grateful to the dynamic language communities, that with their repeated successes have shown that the “king is naked” and self-referential practices of formal code quality or blind following of methodologies valid for over-ruled corporations are useless advice in many environments, and that a more socially oriented testing and user interface design is what wins for creating online services. But I believe the development language involved is accidental.
There are all sorts of tricks you can use in Java to avoid complications: as class reloading may cause the web server to drop sessions, you may simply publish some experimental business logic in an included JSP file – yes, as simple as that. Having “duct tape” capacities is not language-dependant, and if on top of your pragmatic skills you use Java, you’ll be perfectly fine.
Note that I am not saying that the development language choice is a crucial step in you startup path (hear the end of this podcast for some wise considerations): I’m just saying that if you have Java expertise, use it, and you’ll be fine.
Online in three months
As a concrete example, working in Java, having a considerable experience in Java web development (we develop Teamwork), and using the simplest solutions and the best tools available, we developed two online services from scratch and put them online in three months, with 2 people working for each service and one shared. The services are these:
http://patapage.com “add dynamics to your web pages by embedding simple widgets”
and
http://bugsvoice.com “turn bugs into opportunities”
and some of the work done for development and marketing is presented here. Anyway in this post the focus is on whether Java helped in the process, or it was a hindrance.
Notice also that the server side development is more and more a fraction of the total development needed; as you can see in the example services above, the design and UI/JavaScript part is getting more and more important.
Java’s comfortable world
If you are a Java developer and are thinking of dropping it, think carefully before doing that: there are many features that you may assume as “obvious” which are not at all available in other environments. A few examples:
Choices. In the Java world we are happily used to having choices; that is, for a well defined common problem, not only you often find a solution, you most often find more than one. This is in stark contrast with “canned” environments.
Refactoring. You take as granted Java’s clear syntax, and all the advantages of its static typing. If you are fascinated by dynamic injection, consider for example that you’d simply have to drop your trust in refactorings to work, which with Java (and Intellij ) is close to certainty. And this may mean a shift of focus from the core of your problems to… find-and-replace by hand, a reversion to stone age code writing – sounds silly enough. Java core is stable, and basic signatures can’t be overwritten: in many case, this is a quality. Listen to this very interesting Java Posse podcast for competent discussion of Static vs. Dynamic Typing, which will help you get a clear picture about the myths of dynamic language productivity.
The largest server side development community you can get. That’s a simple fact. See this and this, for example.
Good producer support. Server side Java really runs well everywhere, and also is fast everywhere (see e.g. Twitter: Service vs. Platform), and keeps getting faster; with today’s servers that is not that relevant. Anyway, it feels good to know. Being fast, no great hardware support is required, which is the opposite of the commonplace quoted in the beginning.
If you are using a relational database, all the components scale, with well known and documented practices.
A real virtual machine. Virtual machines should run on all main OS out there, and with identical functional coverage. Otherwise its cheating.
All this makes Java a great platform for almost any kind of development; but lets see some specific needs for online services.
Some positive examples
Lets see how the Java platform, available APIs and some tools developed by us along the way can help you in several concrete cases.
While developing your new online service you will probably need to meet these or similar problems along the way, which you will hardly have met doing say intranet corporate development:
- Cross-site scripting
See a definition here. Examining these kinds of problems, we put together a quite complete Java HTML sanitizer here, which everybody can freely use. The development process is described here.
- Cross-site request forgery
See a definition here.
- Filtering spam
For this there are many solutions, see this one for example:
http://www.theserverside.com/tt/articles/article.tss?l=UsingCI-Bayes
We are experimenting using an online service; the nice thing about using Java is that because it is so widespread, everybody provides the Java stub for their services, ready to use.
- Exposing a (RESTful?) API
Here our solution is under development (but almost there), in our experiments we are using JSON-lib.
- Configuring/scripting your service
A (great) example where we used the power and openness of Java to “talk” with a wider audience is in BugsVoice rule scripting language, which is simply JavaScript; given the large and cross server-platform competence in JavaScript, it is the ideal language for letting a wide audience script your application. See here for details.
- Integrating Open Id
We use openid4java, but of course here too there are plenty of choices.
- Talking with Google applications, Twitter, … .
Here too the fact that everybody is exposing stubs for Java is just great, and saves a lot of time.
- Full-text and even smarter searching
Lucene here is the framework to mention. Actually there are many cases, in particular in online services, where full-text search is not enough; never tried Google? So we did some work on this theme too. Here is a quote from Smarter search and recent object functionality :
Here we examine a technique to improve usability in complex applications by introducing smarter search and “recent objects” functionalities. As usability becomes more and more a crucial feature of applications, helping users with full-text search and recent object lists may still prove insufficient. You may need to go beyond these features, by having a way to keep track of “most used” objects, which will help to:
- guess what you are looking for
- find what you are searching for
(Some links on this problem:
Google’ page rank paper: The Anatomy of a Large-Scale Hypertextual Web Search Engine
A discussion on badges: http://stackoverflow.com/questions/135647/how-do-badges-work-in-stackoverflow
An introduction to full text search: http://www.javaworld.com/javaworld/jw-09-2006/jw-0925-lucene.html
Hibernate full-text search: http://www.hibernate.org/410.html
Our contribution to Hibernate full-text search: http://www.hibernate.org/432.html)
Conclusions
The basic question is: does the Java environment help solving your real problems, apart from any architecture astronautic fad? I hope that the examples above show that it does.
Introducing Patapage
We just put online a new web service, Patapage:
Patapage is a way of adding services to web sites (also static ones) in a most simple way: just by adding buttons. There are buttons for socially contributed contents, like adding a wiki-like layer to your pages, and also comments, image galleries, contact forms, rating, retweet, Google or Twitter searches, windows on other websites, annotated feedbacks, and so on. We are adding more services almost daily.
By relying on this service, you are avoiding any kind of server maintenance, and getting some nicely designed and customizable additional layers on your site. All this in an unobtrusive, simple way.
Anyone who is familiar with adding Google analytics or Twitter gadgets on their site will find Patapage simple to use and in line with the current evolution of the web.
There is simply nothing of the sort, and to see the demo you don’t even need to enroll: so just give it a try!
Introducing BugsVoice
BugsVoice site
Error trapping is a well known “secondary” aspect of application development that has received a certain attention in recent years in usability studies. It is more and more believed that it is not that a secondary point, and that handling it properly can be a considerable help in developing quality applications and online services.
It is also true that managing this will make you loose focus with respect to the main target of your application development; so we came with the idea of providing an online service that would solve the problem for you, where you are either a web application developer of the maintainer of hosting services – or both. We called such service BugsVoice “turn bugs into opportunities”.
The service will provide you with a choice of friendly error pages, which you can eventually customize, and guidance on how to integrate your application error handling with the service. If you stick to the basicsm, you should be up in no time. Enough words: BugsVoice beta is online here – give it a try!
Pricing an online service
This in one of a series of posts that are a sort of “marketing diary” of our (attempt at) launching two new online services. The posts are put into context here.
In this post I articulate the reasoning that led us to define a pricing policy for our new online services. In order not to repeat mistakes made by others, I tried to become familiar with experiences, mistakes and successes from many sources – I give a short selection of references at the end. During this search, I have come to the conclusion that there is a simple and single principle, the “nobody cares about features” one, that every developer/marketer that comes to pricing software should keep clear in mind: this is probably the single original point of this post.
We got to define a pricing policy having already three years of experience and alternate success in selling software online; but this was a downloadable product, not an online service, and things are different. One point I got while thinking and researching about pricing is that “no price is an island”: the price of your online service is one aspect of a more general “pricing policy” that includes demo conditions, free licenses, refunds, segmentation (eventually), and other aspects.
I had got to some principles:
Transparency. Your prices and entire pricing policy should be public, clear and completely defined from the very beginning, from the very first moment your beta goes public. This because you must not keep any of your users and potential customers in a state of uncertainty. This way you may reduced the time it will take to make the first sales, which is a critical factor for your success.
Simplicity. Your price must be simple. Nobody wants to make complex reasonings when trying to understand costs. We’ll get back to this after stating the “nobody cares about features” principle, because its related to that.
Give refunds. Your worst enemy in sales is user’s fear, and anything that can lower that, should be welcome. A clear refund policy reassures evaluators, and do you want to keep unhappy users around? It’s not a good idea for an open, blogged about service.
Have only paid accounts. And then a choice we made is to have only paid accounts; a free online service, say ad-based, is a very complex undertaking, whose difficulty and implications for the users are easily underestimated. The mass audience that you must reach to make such choice profitable is rarely found. Another option that rarely works is the donation model. No, we want to give a refined, quality service, for real money.
Fixed these principles, we are still in the dark about how much we should price an account, say per month. You may start looking for a formula, well, there are two values that can be sort of determined:
Costs: you can determine how much development and maintenance costs, and what is the marginal cost, that is, the cost of activating and maintaning a new account.
Real worth: you can probably determine how much worth your service will be for your average customer, how many days of work and confusion it will save them, etc.
Well, now comes a fundamental realization: these two values are entirely, completely irrelevant for determining your service price; because you are looking at things from the wrong direction and/or with the wrong user model in mind. Consider the theme of my previous post about finding a pitch for your product (Get visitors to read and remember your home page):
The day you realize that nobody is interested in reading your product or service homepage because you love it, may be a bit depressing, but may also be the start of a re-design that will lead to more returning visitors.
Well, something similar holds for your pricing: in a competitive market, you simply can’t base yourself on what you believe your service is worth, or how much is costs, or the features you know it has, because nobody, absolutely nobody cares about that. Sad, but true. You have to set the price for the most direct and simple advantage the user can evidently and quickly see she /he will get.
You should never overestimate the will of an evaluator to carefully review your application: so you should surely put no limitation whatsoever in the service you are providing in the demo or free phase of the service; but then, this also influences your pricing, because if you are attempting what is called “segmentation”, based on limiting the features offered by different levels of pricing, you are sort of preparing a “nasty surprise” for those that want to turn from the full, complete demo to paying accounts: so I think this is a very bad idea. Developers love their products and their features, and (wrongly) assume that visitors to the presentation web site have the same drive; no, visitors drive has to be conquered, with the full power of your service, and also through simple and convenient pricing policies.
If you look at the typical policies of expanding software houses, these are often based on a flat, aggressive pricing policy; look today at how much more appeal has Apple’ OS simple pricing policy compared to the academic segmented prices of Microsoft’s OSs (and when Microsoft wanted to become a leader, it had the same policy as that of today’s Apple).
So the policy I support is to let the evaluators use the service in full, and give a single, simple price if they want to turn to a pay account. This is not what the marketing litterature suggests, but… things change, markets evolve, become more competitive, and also certain costs, like bandwidth, decrease.
Anyway, you may have noticed that we are still in the dark for fixing the price, as simple as it may be! Well, at least we’ve set the background principles, we can now look at similar successful software and services in similar fields; I’m not saying same fields as your service is a new, revolutionary idea, right? This also means that you won’t find many references to compare. At least you can be happy that with online services, all the piracy problems are over.
Another way to get an idea on price is to ask for opinions to your followers, or on The Business of Software, answers.onstartups.com, or Startuptodo. But only those who have a complete and clear picture of the entire pricing policy can take a decision; and I hope that will include you, in the end
For our two new services, we actually fixed the price through a session where the entire software house took part, and voted. So we fixed a price (39$/month) for both our services, with only a limitation for really huge customers.
We’ll see whether it works…
References
Don’t just roll the dice – A usefully short guide to software pricing – by Neil Davidson
Camels and Rubber Duckies – by Joel Spolsky
The Web Startup Success Guide – by Bob Walsh
Subscription based models, how to determine pricing ?
Our new web services: Patapage “More options for your website users” – BugsVoice “Turn bugs into opportunities”
Productivity by delegation vs. productivity by outsourcing
Teamwork's Q&A's new site
In Open Lab we just adopted a StackExchange instance as support for Q&A’s for our Teamwork product (here), and another one for generic jQuery support (here). Now, the speed with which you put up one of the highest quality services available on the web is such that it ridicules any attempt to build such a service in-house – a mistake that we actually pursued. This has led me to the following thoughts.
Many developers and managers live in a omnipotence dream. The apparent power of a Turing-complete tool, that in principle can perform any kind of computation, feeds the illusion that having developers in-house means that any software task can be solved by simply developing the application from scratch. If this seems obviously false to you, just take a look around and you’ll find more examples that you’d ever imagine.
So, we need a support forum for our product? Let’s just develop one. We need a bug tracking system? Let’s just develop one. We need to build a web site with database? Lets develop it internally.
Taking the opposite attitude, that is, developing from scratch only what is strictly related to your core business, can be a way to becoming more productive. I’ll call this the software delegation principle.
Ok, assuming this principle looks easy enough; but… there are several mistakes that can be taken in sweeping generalizations of the principle above. The worst one is confusing delegation of secondary services with outsourcing the core productivity of your company. There is a semantic difference between “delegating” and “outsourcing”, and it is connected to where you put your company’s worth.
If you put it in designers, developers and their skills, you can delegate everything but their activity, you will have to struggle to keep their focus on our main development, without making them develop say a support forum when it has nothing to do with their core issues.
If you are a software house, renting a coder is probably a bad idea – see Jeff Atwood’s Can You Really Rent a Coder? . For similar reasons, though many developers and bloggers don’t get it, it is just as well a bad idea to rent a designer. Your people’s skills are the core of your value. Like, our core competencies are development, design and marketing our web applications. Anything that distracts us from our goal, should be removed if possible.
Another in some sense opposite mistake is delegating problem solving which touches your core competencies: like using tools that give you simplistic solutions that hide you the real complexities involved and that will lead you to great troubles when going in production. A classical example is like trying to set up a web site using visual tools, without understanding HTML, JavaScript, and eventually the server-side part that goes with that: maintenance, cross browser compatibility etc. will soon become a nightmare. But delegating non core issues will actually help you going in-depth about your core issues. This is the mistake of outsourcing the core productivity of your company.
If you are a traditional custom-development based software house, what I am saying here applies in a different interpretation, simply because the value of the company is in the customers, not in production (in the case of a software house, this means the developers). Quality is concentrated in making deals with the managers, not in providing good solutions. That is why often such companies really outsource everything but marketing.(I personally don’t like much such business model, but that is another matter).
Made the necessary distinctions, if you overcome the temptation to build everything in-house, here are some examples of services that you can delegate if you are developing online services:
Development:
- writing code -> get the best IDEs, working stations, monitors, keyboards, that money can buy (see CodingHorror for many advices)
- integrating third-party technologies in your software: -> rely on available APIs
- designing mock ups ->use Balsamiq Mockups
Testing and support:
- testing your application – use http://www.usertesting.com or similar services
- collect feedback from your users – use an online service like UserVoice or GetSatisfaction
- support questions and FAQ – use StackExchange
Marketing:
- statistics of your site – use Google’s analytics
- following marketing progress – use StartupTodo
These are just some examples that I am using or exploring.
Using the best tools for development, like using the best IDEs (see The Joel Test: 12 Steps to Better Code), goes in the same direction: you delegate syntactic work to your development environment, and you focus on solving the business model problems and, most importantly, on usability.
Productivity by delegation can also be a great source of new products and services ideas; we in Open Lab are just now developing two new products exactly for this end, one for delegating collection errors and user feedback online (BugsVoice), the other for making your web sites dynamic without using a CMS (Patapage). Time will show whether I’m right…
Get visitors to read and remember your home page – applications
This is the second part of the “Get visitors to read and remember your home page” theme, the first is here. These marketing posts are put into context here.
Now that we have the design principles perfectly clear in mind, let’s apply them to Open Lab’s two new online service home pages, Patapage and BugsVoice (public betas will soon be available).
Patapage
So the first version of the Patapage web site home, after brainstorming, was this one:
Now what is basically missing is any reason for the visitor to get interested in the service: the pitch is not good because it refers to itself, it does not talk to the user. So the version got after reading “Made to Stick” is this one:
The pitch is six words, and talks directly of benefits, not just of features. Furthermore, a mysterious link to a short story has been added: the story begins like this
To read the rest, you’ll need to access Patapage’s beta Actually, the page we have now is even nicer:
So lets fill the scorecard for the obtained home page:
Not bad.
BugsVoice
So this was the page we first got to after brainstorming:
The pitch is invisible and badly worded.
After revision:
The pitch here is just 4 words! So lets fill the scorecard for the obtained home page:
Now… its your turn.
P.S. We finally changed “turn bugs in opportunities” to “turn bugs into opportunities”, after discussions and enquiries: though it doesn’t sound as nice, it is semantically correct.
Get visitors to read and remember your home page – the principles
This blog post is in two parts, this is the first, the second is here. These marketing posts are put into context here. The process here described has also become a step-by-step project on startuptodo.com.
The day you realize that nobody is interested in reading your product or service homepage because you love it, may be a bit depressing, but may also be the start of a re-design that will lead to more returning visitors. Nobody is going to link, talk, or blog about your product without a good reason to do so. There must be something surprisingly interesting, beautiful, disruptive, horrible, rarely thought of about your home page contents to get people to look at it.
Here I will consider some redesign principles that you may use once you got this “satori”.
So, you understood that your web site needs to convince people: you need a home page that will capture visitor’s attention. Taking the user’s perspective is non trivial, say Dan & Chip Heath, because you are under the “Curse of Knowledge”: it is very hard for you and your team to look at your product from the perspective of someone who knows nothing about it, if you don’t dedicate some time to this. This project is heavily inspired by the principles which can be found in the book Made to Stick by Dan & Chip Heath. The aims of this blog post can be summarized as:
(1) get visitors to read your home page
(2) get visitors to remember your home page
Home page effectiveness analysis
As an example, consider this analysis done on the startuptodo.com home page:
The crucial part of the home page is the pitch or lead, in this case “be successful faster”.
The transparent 1,2,3 are a likely order of attention of the first time visitor: she will first read the lead, then the text below, then eventually go more in detail. In a following step we’ll get back to this structure.
Now focus on another part of the home page:
If you can talk about your product / service features using a story, instead of a set of features, you will be much more effective: people tend to remember stories.
Let’s finally focus on a third part of the page, where the site is asserting its credibility:
By Sinatra effect it is meant that a single great testimonial can raise your credibility considerably (“If I can make it there I’ll make it anywhere…”). This example can be summarized using a scorecard:
The pitch and page scan flow
There is a sort of “page scan order” assumed in designing such pages:
The 1,2,3 numbers in the first screenshot of the site above are a sort of reading order, which you should follow in writing contents. The web site gives different levels of information to the visitor, trying to lead her to the evaluation part.
A perfect sample application of “the pitch” principle and of the page scan order is on the UserVoice site:
Notice that the pitch “Your customers have great ideas. Are you ready to listen?” talks about advantages for the users, not directly about features of the service. Below one gets more information, in two further levels. The pitch is even inserted in the service name!
Now go and (re)design your home page
Some steps that you may follow in designing your own home pages.
Describe your product / service
Describe your product / service and its advantages, the problems it solves, the pain it takes away, in short sentences, using a simple language.
It is often done in a group “brainstorming” session.
Find the pitch
This step will be crucial for making visitors actually read your home page, together with the following step “Break a pattern”. This is the hardest part, probably best done in isolation by the most “creative” writer of the group. You have to find the pitch searching in the second and third level descriptions found in the first step. It has to be a short sentence that presents the product advantages to its users. What it is often used as pitch is a sentence which summarizes the descriptive sentences found in the previous step. Mistake! What you should find as pitch is what the user will gain from your system, not a resume of what the system does. It is a subtle but essential difference.
Write a story about some humans using it
Find a storyboard for a video, or write a short story, with characters, people, talking about your product / service. This is the step which will solve point (2), making visitors remember your home page.
Break a pattern!
Something in your home page must break a pattern. Never do the mistake of cloning a successful site layout and that’s it. People just don’t look at known stuff. Either the graphic layout, the text, add a joke, something must be unexpected. The unexpected should be in a context very friendly and predictable: don’t take this as a hint to start surprising the user in general with developers tricks on the interface. Just “going wild” is a commonplace too, and won’t work.
Consider also this case: a bored PR man is taking a look to a set of sites, all with their plain obvious marketing hypes and strong words. Then it comes to your site and… finds something different, interesting…
Design page and publish it
Once designed and published, ask for reviews, test page speed and wide compatibility with the various tools which can be found online. The home page speed in loading and browser type and screen resolution compatibility is important. Put a beta of your page online, with Google analytics on it, and analyze how many people in % get to your “enroll” or “download”. Try variations. Buy a test at http://www.usertesting.com or similar services. Remember to get someone to read this blog and then evaluate the scorecard against your draft. Good luck!
End of part 1 – what is in part 2
In order not to make this blog post uncomfortably long, the following part, concerning how we in Open Lab applied the principles above, is published here, in a second blog post.
A note on how to give titles blog posts: the first title of this post was “Writing an effective product homepage”; but for the very reasons explained in this same blog post, this wasn’t a good title. A candidate title was “Turn homepages from feature reports to ’short novels’ “, but that is a bit cryptic, so the one I choose is the one above, “Get visitors to read and remember your home page”, which talks directly about what you gain from this post, instead of indirect advantages through features.
A review of “The Web Startup Success Guide”
This is a review of the book The Web Startup Success Guide by Bob Walsh, who is also the author of Micro-ISV: From Vision to Reality, published previously. Mr. Walsh is also the creator of the The Startup Success Podcast, and a moderator of the notorious The Business of Software (BOS) discussion forum. This book is aimed at developers who intend to create a new product and are ready to do all that is needed for getting to sell the product, so not only development, but also marketing, selling and collecting feedback.
I am writing a review of this book because I believe it fills a need which has been there for a while; I fantasized writing something similar myself, but luckily Mr. Walsh has come out with this, which spares me of the effort, which was unlikely to succeed anyway as writing something of this kind requires a total commitment. Before this book, to collect something similar to the information reported in it, you had to painfully go through the discussions in the BOS discussion forum, find links to other blogs and books from there, parse what was outdated, what is wrong and so on (this is particularly painful also because for unfathomable reasons those discussing the business of software are not provided with the quality of service that developers get with Stackoverflow and all that family – though it is from more or less the same source, and of course we should be grateful anyway for the service as it is all free). But the book is not a mere anthology of old and new information, it gives you a structured path to follow (a guide), divided in 10 chapters. The advice and references is further supplemented by interviews with about 50 guys from startups who have already gone through (sometimes several times) what the reader is about to start; the interviews are a great way to get informally in contact with what happens once you are “out there”.
Roman mask at Teutoburg.
This book is not “invaluable”, but actually concretely valuable for startups, as it can save hours of search and months of wrong paths taken; you will avoid several common blunders right from the start. Something I believe is a key to success is to choose a product idea with which you will find yourself in what may be called a good strategic position – GSP – my company is developing two new online services ideas which we evaluated along these criteria. When you are in the idea selection process (frequently referred to with the not-so-beautiful term “brainstorming”) considerations such as those of chapter 3 (“So many platforms, so many options”) will give you first criteria for selection, which won’t be sufficient, but are a good starting point: on top of that, what real user need your application solves will be crucial. Starting in a GSP will not make success certain, but at least possible. It is particularly important to start by asking you such questions before being fascinated by development in itself, which is a mistake to which we developers are prone. If you start in a bad strategic position, no amount of effort and quality of product is going to take you out of there – you’ll be the Romans in the Teutoburg forest. Solving marketing problems by sheer effort is a bad habit that many developers acquire in custom development, where they are rented by the hour – more hours, more pay. That does not apply neither in product marketing nor in product development. Unfortunately I still see product proposals on BOS which are in a really bad strategic position, like a client app for URL collecting (!), the painful proposal of a “new” Twitter client, and similar ideas; read this book!
I would like also to point out that much of the advice from the book is good also for the evolution of an existing software house, and for the launch of every single new product, not just for startups. My own software is just an example of the latter. But much is implied about how the software house should be organized for the production and launch to work if you want to follow the book’s implicit philosophy, and its assumption about company “transparency”; you can get further information starting from reading the long early articles of http://www.joelonsoftware.com.
Reviewing a book that gives advices on how to operate in a productive activity could hardly be done without experience in the field; and my review of this book is positive also because many of the findings to which we unfortunately got by trial-and-error are here reported as advices. And proceeding by trial-and-error in such time-consuming activities as software development often is not a viable solution.
Criticisms
The title part “success guide” seems to suggest that closely following the book, success is inevitable, which is false, and actually this is clearly explained in the book; I know that authors sometimes do not have the last word in picking a book’s title, and that marketing considerations get in the way, anyway I would have preferred a more cautious title. Better though unlikely would have been a simple English translation of “Some sparse ideas for web startups valid in 2009-2010″. But as said before, the startup scope too is too restrictive, so a revised title would be “Some sparse ideas for product-launching software houses valid in 2009-2010″. Ok, its horrible
In this (positive) review the title is further criticized again for being too restrictive, for the “web” word. Ok, maybe, anyway enough bantering on the title.
The part concerning Venture Capitals (VCs) and “angel” founding (chapter 5) is almost useless for European startuppers, as money lending is handed mainly by banks and European Union (EU) programs, and not by private founders; also American VCs are interested only in European software houses that already sell at least one million dollar/year (I know that for direct experience, as when my software house won a Jolt award we started to receive calls from American VCs), and so may be out of the scope of the readers of this book. So my personal advice to Europeans startups is for example to check your local universities engineering departments for joint applications to EU founding, instead of running after American VCs.
The worst sin I can find in the book is reprinting the word “dollarize”, which may be the ugliest expression ever selected in the (countably) infinite spectrum of possible English words.
Counter-criticism
I’ve read in other reviews that a weak point of the book is the lack of a “chapter about marketing”; this makes me wonder whether the other reviewers have read the book cover to cover, because one of the main points of the book (and one I found most interesting) is that traditional marketing is getting replaced by activity on social media: chapter 6, page 211: “social media replaces traditional advertising”. And the most interesting chapter 6 details the point further, just read it (I read it twice to be sure I got the points). Of course one may disagree, believe that it is a wrong idea, but an idea of marketing is indeed in the book, and quite articulate.
Mr. Walsh implicitly takes the position that effective marketing of software product and services is one that should appeal to a conscious, reflecting and informed user, quite differently from the unreflected stimuli on which traditional marketing relies. This thesis can hardly be held in general, in particular if one is considering business-to-consumer low cost products; but for other categories, direct and selective access to information from users has increased in time. I know that even one of the comparatively slowly evolving industry, the automotive one, is paying a lot of attention to what bloggers and other social agitators say about new car models released, so maybe its time that you too pay attention to them.
Then chapter 7 gives detailed criteria for the composition of a unique selling proposition (USP), which I believe can be useful even at the very beginning of your start-up. Try this: when you are “brainstorming” on a candidate product idea, try putting together a USP for it. Is this feasible? If not, this may show you that what you are considering maybe is not such a good idea: probably you are not solving some really felt need of the users.
Getting Things Done
Chapter 7 is about personal productivity: personally I’m a bit allergic to this topic, as it evokes images of “self-punishing solipsistic puritan bigotism”; but actually in the book it is not at all treated in this perspective. If one bears in mind that spending too much time and concentration on priority lists and things of the sort can actually damage your meeting the main problems of your startup, the advice given in this book can reduce time wasted. If you simply get to concentrate your “social marketing” activity in definite periods in the day, instead of getting and searching continuous distractions, you’ll surely get more and better work done (I’m actually doing that for my “social” online activity). Still in my experience the key for getting things done is not as much lowering distractions, but is not working alone: write your code in pairs, discuss your specifics in general meetings, select your USP and brand images by showing them to as many people as possible, test your application with as many people you can (also with low cost testing like http://www.usertesting.com), and so on. Anyone’s energy levels change in time: the day you are feeling tired by coding, you can be a good pair partner; and you’ll probably need more energy than you can imagine you have to get your startup to succeed. Not to speak of the countable but non computable number of advantages that a mixed-gender and mixed-skill pair and group of developers / designers has by default. You can’t do it alone!
Other reviews
http://bzkicks.posterous.com/the-web-startup-success-guide-review-0
http://blog.businessofsoftware.org/2009/08/the-web-startup-success-guide—a-book-review.html
http://www.amazon.com/Web-Startup-Success-Guide/dp/1430219858
Final considerations
Putting together what written above, I strongly suggest any startup and company that wants to launch new software products and services to get this book and then read it twice We are applying many of the ideas from the book for both an established product (Teamwork) and for developing and launching our two new online services. I’ll post here updates on our progress.
An “office exchange” opportunity in Florence – Italy
Open Lab's office
Many people use “home exchange” services, such as HomeExchange or HomeForExchange, in order to travel abroad comfortably and somehow “introduced” in the local community. Many of Open Lab have decided to generalize this to an “office exchange” initiative: we are willing to coordinate a temporary exchange of several apartments and part of a working place in Florence, Italy, with a modality similar to that of home exchanges. You will get houses with WI-FI, cars, bicycles, computers, usually also filled with books, some in Florence center town, others in the suburbs.
Our software house is presented here:
Three of the available houses:
http://pupunzi.wordpress.com/where-i-live/
http://homeexchange.com/show.php?id=111560
In total currently there are 8 apartments available of various sizes.
For the office part, here are some pictures:
http://jblooming.blogspot.com/search/label/office%20space%20pictures
We would extend insurance to cover your stay there, and we expect the same from your company.
The period would be in 2010, when is to be determined (not the first half of June), and the length – we were thinking from one to two months. For the location we are open to offers, would prefer to exchange in an English speaking country, but it is not necessary.
We will supply all the details to candidates – just write to ppolsinelli at gmail dot com.
4 comments