Restrictive Creativity

Work on my ‘Interactive Outliner’ system is coming along extremely well. I’ve run into a few hurdles here and there, but I’ve gotten through them by focusing on a few key ideas:

  • This is 1.0 – There are features that I want to put in, parts of the system that I want to redesign, more long term planning that I want to do. But that’s what version 2.0 is for. This version just needs to work and get out the door. Real artists ship.
  • Restrictions are good – It is extremely difficult to make something that does everything people would ever need. Damn near impossible. Decide what rational limits need to be and stick with them. If the restrictions are too much refer to the above point.
  • Constantly look for inconsistencies. – This project has its own mojo and it needs to permeate throughout the entire code base. Straying from said mojo is not only bad style but negative progress. Don’t cut corners just to get something done. Do it right the first time.

IOML – Interactive Outline Markup Language

The format I have been working with now has its official name: Interactive Outline Markup Language. IOML.

The IOML format is an evolutionary step from OPML with some of the structure changed to make using outlines, uh, interactive.

IOML is used to communicate with an Interactive Outline Server. The server I am working on is called CoffeeTalk. It is written in Python. Initial coding is almost (damn I’ve been saying that for a long time) done. The feature set is almost frozen. I’m only debating on one more feature before deciding on freezing the specification.

The first clients to use IOML will be in Python, ActionScript 3.0, and JavaScript/Ajax. The Python client is being developed along with the server.

I’m very excited about the possibilities of IOML. It is very flexible, easy to understand, scalable, portable, and, best of all, it just makes a lot of sense.

Development at the speed of thought…

Flash/Flex vs. WPF/e: How I Learned to Stop Worrying and Love the Bomb

Some interesting discussion about Flash/Flex vs. WPF/e on Robert’s blog, and an old post I just read on Anne’s blog.

Selecting a platform to write for and worrying about how easy it will be to port to another platform is a sign of unintelligent design. It’s a sign you have no idea who your target market is. It’s a sign you, or your developers, have no grasp of reality when it comes to developing, shipping, and supporting a project.

You shouldn’t worry about portability, but that doesn’t mean you shouldn’t take it into consideration. You should worry about the core pieces of your project to ensure that they follow widely accepted industry standards. Those standards are there for a reason. Use them wherever possible.

Both Flash/Flex and WPF/e represent vendor lock-in. Tough. That’s the way the free market works. You are most definitely empowered to build your own toolkit, push it to the point where it has a huge developer-base, and user-base, and bring it up to the same level as Flash/Flex and/or WPF/e (or .Net 1.*, Java, etc.) Go ahead. You’ll probably get some help, but the vast majority of us will be picking a side and actually writing the coolest software applications ever possible.

Let Microsoft and Adobe duke things out, spend their enormous sums of money to build up their nuclear arsenals. Ajax-based toolkits have their hands in all of this too, but they’re playing with much lower yield weapons when compared to Microsoft and Adobe. In the end, we, developers and users alike, win.