Archive for May, 2006

Futurex Johannesburg

I’ve just come back from Futurex at Sandton convention centre – its late and I haven’t got time to write a long post, so all I have to say right now is that it is a lot more impressive than I expected and the level of proffesionalism is great. Even though it is small, it compares to CeBit in a number of ways. Well done SA – we are are on the right track. More to follow…

7 more reasons why web apps fail

According to bokordo there are seven more reasons why web apps fail… in summary:

  • They’re never built.
  • They’re modeling an offline activity incompletely.
  • They’re ahead of the curve.
  • They don’t plan for change.
  • They don’t charge money
  • They have no barrier to entry…at all.
  • They don’t think holistically.

Read more at
http://bokardo.com/archives/7-more-reasons-why-web-apps-fail/

Some new features on the RE/MAX NZ website

Have a look at www.remax.co.nz

Yesterday we published some nice enhancements for the public front end site using some AJAX scripting.

Read on for more details…

Small & Medium Business Website Costs in South Africa (upfront & ongoing)

When consulting with a new potential client, the biggest fundamental question is – “do you want to be able to update the web site yourself (lets call this “option A” or “dynamic”) or do you want to have to employ a programmer to do it for you (lets call this “option B” or “static”).”

At White Wall Web, we only do option A type sites and I will explain below why I believe that this is the only way for a business to run a website effectively. The crux of the issue revolves around scalability and website management issues – but there are also hidden costs associated to running a static site. Below I go into further detail about costs and motivation for using option A, but let me also first explain why we developed our own CMS (Content Management System) which is called WebStream.

  1. Because we can – many web site companies don’t have the skills in house to do this. Often they use open source or proprietary products to provide CMS sites for their clients (which is completely legitimate). We on the other hand are a web application development company and our core business is building bespoke web products.
  2. We couldn’t find any open source CMS products that worked the way we wanted them to.
  3. We didn’t want to pay the high license fees for the good proprietary CMS products and then have to pass those fees on to our clients.
  4. We wanted to build a framework that we could use to build larger more complex apps on top of, and could not see the logic in having this framework separate from our CMS framework. This also gives our ‘smaller’ CMS clients a more cost effective upgrade path.

Basic web principle: A good website is useful to the end user. A useful website has regular changing content.
With that in mind, lets look at the details of costs and the difference between option A and option B…

Online Developers Manuals

Get free access to Windows manuals online at http://www.helpreader.com/pages/browse/

These currently include a PHP, mySQL, Smarty and Python manuals amongst others. Useful if you have a team of developers and you don’t want to save and maintain versions on your LAN.

SkypeOut is free in the US and Canada

Great marketing move on the part of Skype. Any chance of us getting free local calls in SA? Dream on…

7 Reasons Why Web Apps Fail

I could agree with Joshua Porter’s list more:

  1. Focus on social instead of personal.
  2. They solve too many problems, or try to.
  3. They’re about making someone other than the user happy.
  4. They sell it the wrong way.
  5. Not in it for the long haul.
  6. They show too much of what’s going on, and get gamed.
  7. They don’t have an underlying business strategy of improving people’s lives.

Numbers 2 and 4 are problems common to web companies creating thier own aps.

Numbers 3 and 5 are problems common to companies working as outsourcing partners whose client is not the end user but the software owner/funder.

Spelling in Web Solutoins…

As a company with several Afrikaans engineers, the English spelling on our solutions has been an issue from time to time and part of testing has involved checking spelling.

Spelling errors on web sites, blogs, intranets etc. can be rather embarrassing as they undermine credibility of both the organization and the engineers.

I find the best way to check spelling on web systems is to simply copy the web page and paste it into a word processor and run a spell checker before publishing to the repository.

I was made to feel a lot better about the odd spelling error that creeps through the cracks, when Andy D pointed out a spelling error he found on the Google Maps API FAQ this morning. Lets see how long it stays up there :)

Google API Solutoins

2009
2008
2007
2006