Continuing our theme of Frog Software Design Principles (First Post):
There are a number of design metrics used at Frog. I’ll deal with these in more detail later, for now I’ll cover just one or two that illustrate the building of a sense of pride and achievement mentioned in the previous post.
The first point is perhaps obvious. If you want someone to get a sense of achievement for their creations, then they need to be able to create something in the first place. This means that the system must be closer related to a toolkit, or a platform than to an application. If it was just an application with set parameters on use then there is no opportunity for creation, and therefore no opportunity to feel good about what you’ve created.
We need to make people feel like they are the developers of the system, and not just the users. No-one likes being told what to do, but being told how to do it is particularly upsetting, especially if it’s not in line with the way you’ve been successfully doing things for years.
Secondly, in order to achieve our lofty ambition of allowing “ordinary people to create extraordinary systems”, the platform must focus around a specific set of problems. Frog’s primary focus is web applications. Within that we have a number of sets of components, including e-learning, e-commerce, social networking, collaboration, database applications, and so on. Within each of these areas, our users should be able to build pretty much whatever they need. As an example of something outside of these areas, Frog is not particularly suited to building graphic manipulation applications, whereas other development environments, like Visual Basic, might be. By maintaining a tight focus on what your platform can build, this allows the individual components, or Lego bricks to be similarly focused.
In short, what I’m saying here is that to provide 100% flexibility we would need to start with a completely blank sheet of paper – this would require our users to be professional programmers. Instead we define boundaries about what the system can do, allowing us to code in all the typical use cases, making the system accessible to all, and not just programmers.