Tuesday, September 9, 2008

Selling Software Is Hard

Writing software is hard, but for a programmer, marketing it is even harder.

Once you've written the functionality, gussied up the interface, prepared the documentation and created the related webpages it is extremely frustrating to find that in actual fact, all you've done is managed to finish the easy stuff.

With 6 billion people in the world, you would think that getting some of them to look at and use your software would be straight forward.

The trick to selling software is surprisingly easy to state: All you have to do is create software that performs a task, find a group of people who need that task performed, create a moment of clarity for them regarding the purpose of the software and then find some way to stop them from crushing you in the rush to purchase.

The problem comes at the point you try to get the people who need the software to notice you, and to listen to you long enough for you to convey that moment of clarity.

The name of the game is Persistence.

Good Luck :)

Saturday, September 6, 2008

The iPhone, Legacy software and modern computer security

The problem with most common security models is that they are based on a security model that was developed many years ago for mainframe computer systems in an environment where, in general, the user was the distrusted element and not the process.

The user based security model that Unix and Windows offer today is actually nearly useless in the face of the real threat.

Traditionally in large mainframe systems it was the user that was seen as the threat, everything on the system was backed up on a regular basis and software in general did not tend to travel far enough, fast enough, to be much of a vector.
Because the user was seen as the potential source of trouble, they were given 'sandbox' environments known as 'user accounts' in which they could roam freely but not easily leave without demonstrating that they had the right to access other parts of the system.

On a modern PC, we all have documents, pictures and other personal files that we do not want to lose in the case of a problem, yet very few people outside of the IT community actually have backup systems in place, and nearly everyone stores those documents and files within their own user profile - the same user profile within which they run software they download from the internet, mount drives other people give them and generally take insane risks on.

The threat in this modern age is from the process and not the user. With password protected access the user can be assumed to be trusted to a reasonable extent, burglary victims aside, whereas a lot of software cannot.

A seemingly obvious solution to this is to place each application within its own 'user' space, treating them in the same way as Linux, Mac OS X and Vista currently treat individual users, with their own limited file access.

...and the iPhone does exactly this. Each individual iPhone application is limited to its own set own of folders, and has no ability to look outside them or to open or alter documents in other areas of the file system.
There is a single shared area, where the user can choose to place files for which that makes sense, but fundamentally each application is being given its own user space in exactly the same way that users are on other operating systems.

It is an interesting step forward, and one that I do expect to see appear on mac os x. The most likely initial implementation is as a 'sandbox' environment in which untrusted applications are run by default, with the user having the ability to move them outside of that environment once they are happy.

Tuesday, August 26, 2008

Clarity and Context

When developing an interface (or writing code for that matter) the best interfaces make each decision required by the user to be the outcome of a moment of clarity and context.
The user needs to know where they are, what they are doing there and what they are attempting to achieve at that moment.

This tends to be harder than it sounds.

Context and clarity is not often achieved by providing the user with more and more information, in fact the more information you attempt to give the user the less they are likely to understand (or even read) any of it.

Programmers tend to be aware of a lot of underlying context that almost certainly does not need to be known by the user unless they specifically request it. This can make it very hard to convince programmers to take away options and remove information simply because *programmers will think that the information they are removing is important*.

Clarity and context is achieved by stripping away absolutely everything that can be stripped away, and then presenting that which means in as clear a manner as possible, providing as much related information as possible and then indicating the most likely decision under the circumstances.

...this represents a fantastic contradiction, which tends to explain some of the grotesquely ugly interfaces that exist today...

The mechanism I find most helpful is to add everything that *could* be there, and then strip away everything that *shouldn't*, and finally to put back..often in small text and corners...information that might be helpful to them when they are making a decision.

but the real secret, when in doubt, take it away.

Sunday, August 24, 2008

The Trials and Tribulations of a Software Developer

There are an almost insane number of factors that a computer programmer must consider as a part of their day.

A 'simple' web developer utilising mysql, php, javascript, css and html. is moving between *5* different syntaxes on a minute to minute basis, the typical development target for web development these days is IE 6, IE 7, and the most recent versions of Safari and Firefox/Mozilla.

That is effectively 5 languages (for some definition of the word) focusing on 4 noticeably different platforms, with different quirks and tricks.

at the same time the programer must be aware of the layout and design of the database, the layout, design and future goals of the code base, the possible ramifications of the changes they are making on those goals, on the existing codebase.

Also they must consider the security ramifications of the decisions they are making as they go,

They are usually working with code written at least in part by other developers in the organisation with skill levels that vary, they will frequently be working with third party libraries and API that vary in quality and ease of use and they often have to deal with features that must be implemented on short notice or with limited initial research time available.

When they actually write code they must keep in their heads the design goals of the specific problem they are trying to solve, the best way of fitting those goals into the overall design goals and methods of the larger codebase and the limits on the resources that they have available in terms of browser CPU usage, bandwidth, database access times - *and* they have to have formed an opinion on the best way of solving the problem within those limitations.

and..especially with web design...the result must look good.

Being a good developer is about achieving Context and Clarity at each step of the process, concentration focused on the goal, but maintaining awareness of the complexity that surrounds them, allowing it to guide, without letting it distract them.

With all this to consider it is, quite frankly, astonishing that they can bring themselves to take the risk of writing any code at all.

Visual Task Management

So I am a great fan of using task lists and to do lists, but have often found myself a little frustrated with my inability to group tasks visually, move them around the screen, collapse them together, file them away and generally treat them like pieces of paper.

this is an alpha version of a combination todo list and task management application that is designed to let tasks be grouped visually, filed away for future reference, moved from one task to another, become projects themselves and so forth.

Basically I am aiming for a very flexible way of pushing tasks around, and this lets me do most of that, I am interested in what people think and whether you find it generally useful.

it is written in fairly OO php 5, and uses the prototype javascript library pretty heavily for the ajax stuff.


its a little slow, btw. this is caused entirely by the fact it is run on a godaddy server.

Saturday, August 16, 2008

Science - a game of belief the whole family can play

The basis of science is a simple game that anyone in your family can play.

it goes like this: take any simple observation and ask yourself 'if God didn't do this, what did?'

The idea is not to deny the existence of God. Science has nothing useful or intelligent to say on that subject.

The idea is to seek simple explanations for simple observations of natural phenomena and to use the solutions to improve our lives.

The Game of Science has brought us tampons, computers, microwaves and flushable toilets. It is a fun game.

Teach it to your children.