These are among the books  that have most influenced us:

Some of the beloved / informative or both are not currently in Open Lab, because some of us is reading one or is hiding it at home, among which:

Our software house is not formally a startup, though product development has changed so much in the last 12 months that we are proceeding as a startup. There are many nice books from the past in our libraries, whose content is always valid.

-

Also a section for the IT guys:

And there is more:

This is what we believed, and it has been a long journey to realize how wrong we were. In your startup you will need a lot more skills or “hats” to succeed. For example, you need to do SEO on your product presentation site, you need to write license agreements for your software, you need to create and maintain a consistent design, you need to present your plans to potential funders, you need to interview and select workers, you need to have a way to test the application both functionally and on end users, and so on.

A review of the range of activities needed can be found in The Web Startup Success Guide, which I also reviewed here. I have been focusing recently on a skill that underlies many of the needed “hats”: this skill which your startup absolutely needs is

copywriting

usually referred to simply by “copy”. Wikipedia defines copywriting as

Now, there is an apparently simple way for a startup to compensate the lack of internal skills: hire consultants. What is sometimes missed in this “solution” is that most of the needs listed before are not the problems of a day: you have to create copy material almost every day of your startup activity. Also consider that the value of your product may be in details that get added day by day, and there must be a close collaboration between production and copywriting to communicate effectively to the users / visitors / buyers. Considering also that as startuppers you are likely a group of creative people, you may opt for creating contents yourselves! Many – most? – successful startups do that, cultivating a blog, site, tweets and more. And I suspect that spelling out in clear writing the benefits of your product may also help the development of it.

I took notes while studying the literature and introductions to copy, and extracted from there some notes in the form of blog posts. I hope that can be of help to others that are trying to learn copy for their startup.

A note about the “startup” term: I use “startup” more to mean an attitude, or even state of mind, that even software houses which strictly speaking are not startups may assume. In particular in the European Union, creating a new software product and creating new companies may be activities that do not coincide, given the complexity of setting up a company.

These two posts are directly about writing:

Improving the writing style of technical blog posts (part one)

A checklist for improving the writing style of technical blog posts (part two)

and I will talk about this theme at the forthcoming Developers in Florence 01 meeting.

This is about home page composition:

Get visitors to read and remember your home page – the principles

Get visitors to read and remember your home page – applications

and as I will talk about the latest two at the forthcoming Better Software conference, I am expanding the information there with new experiences – will publish an update blog post.

Good luck with your copywriting!

As you survived reading up to here, now you get a reward: a simple checklist which you can use to verify your posts before publishing them. The checklist does not contain anything about the core quality of your contents: being a technical writer / worker, it is simply assumed that you have something of value to say, but don’t know exactly how.

Checklist

(Get attention)

• There is an effort to capture reader’s attention in the title and very first sentence

  Copy is never too long, just too boring.

• Benefits for the reader are immediately clear – instead of features
  

  I woke up this morning thinking: I really need …

• At least in the first paragraph, every sentence somehow leads to the next one.

• The post contains a (short) story

  “For sale: Baby shoes. Never used.” Ernest Hemingway

(Authority)

• Substitute opinions with descriptions

  “That’s just like, eh, your opinion man” Big Lebowski

• Your assertions are backed up with specific proof

• You establish authority somewhere, somehow

• You kept the initial promise through which you got attention

(Style & format)

• Can you make it shorter? Where in doubt, cut it out

  “To be or not to be?”
  

• You kept the language simple and clear.

  No one will ever complain that your writing is too easy to understand.

• You sum the contents up at the end of the post.

(Review)

• You’ve printed the draft on paper and re-read it

  A way to get a new perspective, a bit like giving it to someone else to read it.

• You read it loudly

  A way to become sensitive to the rhythm of your writing.

• Immediately before publishing it you did spell check it not just on some online spell checker but on Microsoft Word.

This is it. Shouldn’t be too hard. Download here the checklist in PDF format.

One could add to this list, with a slight change of focus, “Did you insert meaningful SEO words?” in your writings – but this opens up further considerations, maybe I will discuss them in a following blog post.

Using these techniques

Am I using this checklist? Well, I am. Consider for example this recent blog post I published in one of the most boring blogs on the web, the one where we announce Teamwork’s releases:

Teamwork’s blog usually has posts like “Teamwork 4.3.12323 released”, followed by say a series of bug fixes which make sense only for Teamwork administrators, and can be made more interesting (and popular) using the techniques just described. In fact many people liked this last one.

Another example, this very blog post: this is a bit particular as it is half way between a guide and a blog post, some call it a “blogzine” entry. I did review it (several times) according to its own criteria, and made many changes (improvements, I hope).

A well-written blog post can have several “usages”:

• It can be used as a base for a talk for a conference – or for proposing one
• It can become a chapter of an e-book
• It can be the base for building the contents of a dedicated micro-site
• It can be transformed in a project – for example as done at the Startuptodo service

Again, all contents of good quality have a positive SEO effect: it is a side effect, but it can be great.

Exercise: review your latest blog post with this checklist. Is there anything that could be improved?

Conclusion

So we started from examining the writing and narrational style of some popular technical blogs, and then isolated a few techniques in a checklist which you can use to refine your own blog posts. This is just a start, you can find references and more material to study in the next section.

Further reading

I would like to thank Mr. Brian Clark for his brilliant site, copyblogger, that I discovered half way through and gave me a host of new ideas. Some advice on how to write blogs is at the end of this podcast:

http://blog.stackoverflow.com/2010/01/podcast-81/

From the notes:

Some tips from Joel and Jeff about why and how (or if) programmers should blog. Set a schedule and stick to it. And don’t be a commodity blogger! It helps to focus on the storytelling aspect of the writing, per Ira Glass. And remember, writing a better article on any topic is usually pretty easy, because so much of the content on the internet is so darn bad.

The Delicious links provide some sources.

This blog’s theme is discussed on Twitter and classified in Delicious under the tag “wellWrittenBlog”. The first part of this blog post, “A checklist for improving the writing style of technical blog posts” can be found here.

Most popular blogs are “well written”: by this I don’t (just) mean grammatically correct, I mean well written by looking at them as sort of short stories. Looking at blog posts in this way is a perspective that probably escapes technical writers; it is obvious for anybody who has copywriting experience. A blog can be very well written and not be popular, and there may even be popular blogs that are badly written, but there seems to be enough correlation with “good writing” for blogs that have contents as good as those of many others but stand out in popularity.

Now we will examine three popular blogs, to see some writing techniques in action. Then we will try to define some rules to improve your blog’s writing.

I will not go into why having a popular blog can be important, I just assume that it is so – a discussion would lead us to an entirely different topic. What is here said about writing is contextualized to blogs, but I believe can be a help in any kind of copywriting activity.

Three popular blogs

The blogs I’ve chosen as examples are those of Joel Spolsky, Jeff Atwood and Seth Godin. The first two are about programming,  the work of programming and software marketing, the last one about marketing and spreading ideas.

Joel On Software

As an example post from Spolsky’s blog I’ve picked this one: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!), and here is a short abstract from the blog, the opening paragraphs:

Notice how this blog post, which is highly technical, start by asking questions and telling short stories – I’ve underlined the starts. And not only is the beginning like that, it keeps proceeding in such fashion. Why don’t you go now and read it, trying to notice the short stories that pepper this nice post.

Coding Horror

Let’s examine now Atwood’s Coding Horror blog, for example this blog post: The Great Newline Schism. The topic of this  post is newline invisible characters, and this post  topic is probably on one of the most uninteresting topic ever, but reading it is a pleasure anyway because of the way Atwood evokes old typewriters and nice pictures to lead the reader along; he is not telling a story in a classical sense, but he is indeed engaged in narration:

Seth’s blog

Finally, let’s consider the posts from Seth Godin’s blog: these are short (yes, mine aren’t ).

Consider The hidden power of a gift:

“Perhaps we resolve it, as the ancient Native Americans did, by acknowledging the power of the giver … The key is that the gift must be freely and gladly accepted”

and Frightened, clueless or uninformed?

“Comfort the frightened, coach the clueless and teach the uninformed.”

His posts are filled with anthropological observations: he manages to link to the readers’ emotions. He has a talent for finding latent emotional roots in apparently purely commercial / economical interactions. He looks at human beings as emotional chimpanzees – which you may say is exactly what we are – and as shaped by implicit social norms; we are not as logical as we’d like to think we are. Seth explains behavior through micro anthropological narrations, which take little time, and stimulate reflecting on the bases of motivation – hence on marketing.

Design for beauty or readability?

The communication strategy which we are trying to refine here is focused on narration, as this is a way to transmit contents. A different strategy is to use design, but then it will be much harder to communicate a specific content; you will need a different design for every post, and find / invent a graphical metaphor. This is what indeed some talented designers are doing: see

http://line25.com/articles/tips-for-designing-unique-and-attractive-blog-posts

http://www.smashingmagazine.com/the-death-of-the-blog-post/

These are incredible designers that create a different design for each blog post. But as said above, our idea is to excite the reader with narration, not with novel design, as we want the reader to focus on contents. So pick a simple, highly readable, consistent layout for your blog and stick to it. Use very simple typographical tricks to lighten the reading experience, and few pictures.  For an example, consider Joel’s clean style. Don’t invent a layout – its non trivial!

The importance of a good start

Blog titles play a crucial role in your posts, similar to that of product / web site’s pitches. What is the purpose of the pitch – in our case, of the title? The purpose of the title is to make the first sentence read. And what is the purpose of the first sentence? The purpose of the first sentence is to make the second sentence read. And so on: if you don’t get the attention of the visitor with the title, your failure is complete.

So make sure you try lists of different titles and starts, and variations on them. Get someone to verify them with you. Do the titles and openings grab attention? Interest?

The words that you are choosing there are important too: these should be inspired by the words used by your potential visitors / customers to describe their wishes, hopes, desires, dissatisfactions, fears, worries in relation to your topic / product.

You should probably dedicate almost half of the total time you dedicate to the post’ writing to experimenting with the title and start. For example, in the case of our Patapage site it took me months to get to a decent pitch. A blog post title is somehow less important than a home page pitch, but still put a significant part of your effort on the opening.

Why telling stories is good idea?

First you should realize that “by default”, nobody is interested in your blog posts, apart from very few people close to you who maybe, maybe, are interested. This is so important to deserve repetition and bold fonts:

nobody is “spontaneously” interested in what you are writing.

This is a “negative” truth. But here comes a “positive” one:

people are hungry for stories.

These two facts can help all along your writing.

As a technician, you are probably the least apt to communicate to the general public, and you also have to communicate the hardest topics. Furthermore, what you are trying to say cannot be trivialized without losing its essence. If you explain your ideas in technical terms, it will be non trivial to keep the attention of the readers. This is why using stories is a good idea: you can begin communicating non trivial ideas building up the readers’ attention.

So tell a story. Now, not a silly story: the point is not telling jokes, the point is to introduce your topic.

The conclusion is: in your post, tell stories, about conflicts, experiences, problems leading to your theme, and you’ll get the reader’s attention.

Hiring a copywriter may not always be the solution

If you are working with a large budget, the simplest way to solve any copywriting problem like writing good blog posts is simply to hire a copy. With the web and social media opening “windows” on companies’ activities, many (most?) companies actually need to create well written, interesting contents every day of work. Now, can you hire a full-time copy? If you can’t, like me, you can do a lot by yourself.

As a startup, there are several occasions where we got perfectly good solutions with a little internal research instead of paying expensive consultants with dubious competencies. The “solution” hire a consultant simply assumes that consultants are competent by default, which is often not the case. Need to write a license? Need a user guide? Need SEO optimization? Hire an expert. We didn’t, and are happy with the results; again, these problems appear continuously, so you need the relative competencies in-house.

In order to write, you need to have some “creative spirit”. It is impossible to learn to be creative: Steve Jobs as quoted in Inside Steve’s Brain says that seeing people trying to become creative is “painful to watch”. Indeed it is. Here I’m just assuming that you are, and that maybe your attention needs to stop a bit on your own writing style.

And now… go to the checklist!

This blog’s theme is discussed on Twitter and classified in Delicious under the tag “wellWrittenBlog”. The second part of this blog post, “A checklist for improving the writing style of technical blog posts” can be found here.

Actually, the answer is everyone in Open Lab,  and specifically no one. I always found a bit simplistic the idea that the “developer” creates applications by programming, and when the app is working and almost done, he/she asks a designer to create some graphics for it. In this line of reasoning there is a family resemblance with the idea “I first create an application and then market it.”, which I find deeply wrong – but this is another topic. If you are developing web applications aimed at wide markets, design and application development integrate one another at every development step. And this is how we create and design applications in Open Lab.

Like when we have to create a logo, the internal designers, who are also developers, propose candidates in a meeting to which the entire software house takes part; not only design and application integration are considered, but also marketing must be taken into consideration when evaluating design solutions.

Interface design and graphic design are different concepts, but are also related: a usable interface must be pleasant, not confusing, and both skills must be used to get a good result. Today’s users expect applications to be pleasant; and a well designed and pleasant application will more easily elicit a “collaborative” attitude from users in the first steps of evaluation, and even afterwards, if the design is consistent throughout the application. Consider also “wow” effects that designers can create.

The gaming software industry has understood the crucial role of designers long ago. And the boundary between gaming techniques and usability for “serious” software can be crossed proficiently – we did this with good results in our Teamwork software. A great introduction to this theme is  Putting the Fun in Functional: Applying Game Mechanics to Functional Software by Amy Jo Kim. In order to use such techniques, good design is essential.

People that have designers take part in development, will notice that they can learn a lot from development, even when they get back to more design-specific tasks. And vice-versa, even more, holds for developers. Usability is often supplying the right metaphor: algorithmic experience often won’t help in such tasks, but the culture of a good designer can.

If you are doing web development, can you draw a strict line between what is done in your CSS for usability and what for esthetic considerations? And with say jQuery JavaScript selectors, their usage is for behavior, layout, design? There is no clear distinction; and you may see this as a problem, but also as an opportunity for interdisciplinary work.

This also evidences that it is a bad idea to use just external occasional collaborations for graphic design; you should find a way to have a consistent and continuous flow of design ideas in your software house. A similar conclusion is reached by Joel Spolski in this podcast: “Joel explains why he no longer believes in outsourcing design.”

So among the hats one startup should include in its first team, there is indeed development and marketing, but also graphic and usability design.

Similar considerations to the one above are valid also in the rest of the industry, not only in software; I was recently in Milan in the Triennale expo about Deepdesign (see a review here), and what they are doing brings together design, industrial prototyping, integration with mass production, and hence the distinction between design and product engineering is blurred.

Another, similar development: with Patapage in Open Lab we are working continuously crossing the boundary between page design and data / contents mashupping, creating a tool that makes the distinction between designing a site and inserting / updating / community contributing its “contents” problematic.

And the answer to“who designed the graphics?” is… the entire Open Lab team.

Some definitions and references

I’ll start by quoting the Wikipedia definition of mashup:

And also that of mashup enabler:

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:

http://enriquez.github.com

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 Patapage¹,

http://patapage.com

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.

e.g. on answers.onstartups.com How to pick a platform for a startup web 2.0 app?

or

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.

  http://patapage.com

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!

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!

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”