Web Site Greetings and Localization

As I tackled a couple of tasks for a project I’m working on I had a few thoughts, yes… contrary to popular belief it does happen! How do people perceive greeting messages? Do people require them? Do they expect the message to stay the same? Do they expect that it will be localized appropriately?

See, what I have been thinking is that I personally prefer a blend of locales. Meaning, in one instance I wouldn’t mind seeing a French version of Hello or Welcome while on my next visit I see it in English, and then another in Spanish. I’m not sure whether that is just me or not. So I’m asking you what you feel about this.

Or, an I just overthinking the whole greeting in that it doesn’t really matter. You see it once and then move straight to content?

What are your thoughts?

Axiom Stack is Open Sourced!

While on my way to the 1223 event with a friend, Periodic Design, this week I received a text message, “Stack = open source!” Yes, I’m talking about the Axiom Stack. And my friend can attest, I was _not_ quiet about it. I made sure to confirm it with a few additional sources. While I’m unsure of the exact reasons for open sourcing this product I can tell you some of the benefits, and hopefully I don’t sound like a broken record for the OSS community.

OSS provides a number of benefits to the community. I have recently been using Django a bit for some side projects outside of work. One of the biggest sellers for me was that I had a huge wealth of knowledge already at my disposal. It wasn’t the community and it wasn’t the documentation. It was the ability to dive right into the code and really see what was going on. This is now possible with the Axiom Stack which is _great_. I now have the ability to see the “Axiom” way of doing things by having access to the full codebase. I can also look into issues within the stack code to see whether the problem with my app exist there or in my own source.

Also, now that the source is opened. It is easier for me to make modifications and enhancements to the source. This means that if I feel there are areas which I can enhance, then I have the power to. I don’t have to wait for an enchancement ticket to be pushed into the queue. Now, don’t get me wrong, I think that the engineers working for Axiom Software, Inc are incredibly bright people, much moreso than myself, but in the offchance that I see something that needs some polish, I can do that as well and shoot the patch file back over to those guys. This means that they get time spent on the project that they may not have otherwise normally received.

So, going beyond the benefits of Open Source and looking at the stack itself, I think this is a great move. The Axiom Stack itself is a great web platform. It is extremely easy to develop with and holds a lot of possibility. I’ve used it in developing client sites and on a couple personal projects with another in the works. The Axiom Stack will certainly benefit from this news, however I have a feeling that the benefit will not be solely to the stack but to the community as well.

A Process for Web Application Development

A friend and I were sitting at lunch one day discussing web application development. He was talking about the models that a number of these “fresh ideas” start with, “it needs to make money”. His notion was that this is the wrong approach. His point was that you should build an application that you would want to use, and then let your users drive a number of your features. You can find his post at Offbrand Turnips. What I believe is that his fundamental idea is right.

So many new ventures fall into the trap of wanting to make money or be the next big social thing or get into advertising that they forget to produce a quality product. As my friend says, “Most of the new wave of Web 2.0 apps are just social media spinoffs waiting to be bought out rather than building apps…” What is the point of making an application that doesn’t work. Sure any press is “good” press, but what about the users that expect your product to work? Thus, the idea is that while you need to make sure that you have a sound business idea, don’t jump the gun on wanting to make a profit or blowing your cash on marketing gimmicks. Make sure that you have a good sound product first. Make sure that your application can stand on two feet before sending it off to “fight the Persians”.

So how does one, or a small team, do this? Easy. Prototype your product. Put it into a closed alpha/beta. Generate feedback. Rework the application. Expand the beta or even do an open beta. More feedback. Rework once again. Then launch. By this point you have accomplished a couple of things. You’ve delved into viral marketing, you have some branding, and you have a userbase. If people come back for your expanded beta then you have a pretty good idea that your product has something to it. If not, time to hit the whiteboard.

This is the way I look at it. We developers view software development from a couple of perspectives. There is first the waterfall school of thought and then the agile school of thought. I’m a fan of agility. Thus, I feel it’s appropriate for many parts of a company, including product launches. If you look at the steps above as sprints then you involve people in fast paced ever changing iterations where they feel that their contributions are being taken seriously. When that happens, people will stick around to see what the next chosen feature is that will be released. Your clients, aka users, will be able to tell you what they like and dislike about how you do things. And, by working in these sprints they will see results almost immediately.

So, by the end of this post my goal was to point out that monetizing your product is not the most important thing when creating a web application. Making sure it works and that it is something you’d like to use is equally, if not more, important. Without the product, you get to monetize nothing. And, paying huge advertizing campaigns can be a waste with the social media market. Thus, closed betas are likely more productive in attracting the “easly-adopter” crowd. Once you have users and some feedback you can rollout your pay-for products/features and begin to pull in some revenue.