Debug log:

 
                                

Introduction

Straight to the point

Ok, you've heard it before, some great new product.. So let's get right to the point.

 

+

Looks familiar? Great idea, housing features that will make a change or improvement for you or someone else. That's great. But what's that grey bar in the middle?

 

Yeah. That's the stuff you just have to endure, right? And also seem to be in constant change. Akward, grumpy and unreliable. That's technology as many people know it.

 

If you're lucky, you will find the door on the other side, with specs corresponding to your list of features, and possibly, even providing a user-experience that corresponds to the idea you had in the first place. But it's often a long journey, right? Why?

 

Lost in translation

We have problems understanding each other. The invention called language isn't perfect. We make false assumptions. As project teams grows, communication glitches increases. This costs money. Some still believe that nine women can make a baby in one month. People gets frustrated. And the art of understanding - Theory of mind - is negatively affected.

 

Also, as new features or changes are introduced, these have to be applied in the code. Over time, this code starts to break down. Also, technology evolves and there is simply no bond between the feature-specifications and the code.

 

Hey, It doesn't have to be this way

Now, if the requests of features where written in way computers could understand, could the whole coding process be automated - just as a compiler works? Killing an industry? Probably not, but let's play with it. Remember the illustration on the top of this page? Here's the declaration:

<content type="image/graphics" ftype="png" w="1024" h="600" bgcol="#ff9900">
  <rect x="502" y="30" w="200" h="40" text="From IDEA to SOLUTION" fontsize="40" />
  <rect y="300" x="100" w="120" h="80" t="3" r="5" fill="bgc1" text="IDEA"/>
  <route y="+0" x="+75" path="+50x" arrow="e" t="4" />
  <rect y="+0" x="+125" w="120" h="150" t="3" r="5" fill="bgc1" text="FEATURES"/>
  <route y="+0" x="+75" path="+50x" arrow="e" t="4" />
  <rect y="+0" x="+125" w="120" h="400" t="3" r="5" fill="bgc2" text="CODE"/>
  <route y="+0" x="+75" path="+50x" arrow="e" t="4" />
  <rect y="+0" x="+125" w="120" h="150" t="3" r="5"  fill="bgc1" text="SPECS"/>
  <route y="+0" x="+75" path="+50x" arrow="e" t="4" />
  <rect y="+0" x="+125" w="120" h="80" t="3" r="5" fill="bgc1" text="UX"/>
</content>
+

Ok, maybe not super exciting but it's quite clear what we want and how we want it. The result is of course a real png-image, generated by a corresponding parser, understanding the markup that corresponds to the content-type. It's just a start.

 

Limitations?

Ok, so is this for web stuff only? No. The main principle, to declare specifications using XML can be used to make pizza as well. But the software parsing the XML has its origins in the web environment and the current content-types are primarily targeted for intranet web usage. Now, let's look at some examples!

 

Gerating awsome multi-user database management systems

Generate precise and complex PDF-reports similar to standard markup

Put the iPod to some heavy use.

Example of PDF label generation, using loops and graphics.

Interfacing with industry printers

Making a world-class RWD-template

The impossible mission

General goal and current status of framework.