gistfile1.md

History

This all started when I moved to a design-in-browser workflow over the winter.

Designing in the browser is a workflow pain, jumping back into photoshop & shiny up a design is a productivity killer. I try to work in code as long as possible and avoid PS. I originally started out with an HTML/CSS to PSD converter using the PS API, although I got pretty far I quickly discovered it was going to be too slow. Parse HTML and for everything element create relevant layers, PS could barely handle it much less perform effectively.

I had two options; 1. Reverse engineer a PSD format writer or 2. Start work on a app that could speak both graphics and HTML. The latter seemed like an easier task so here I am.

The Basics.

The basic idea is this; a node based graphics editor with WebKit canvas(es). The WebKit canvas is abstracted & won't care how it gets HTML/CSS, just that it gets it. For me I imagine I'll route my HTML from a Slim + Compass source into the main WebKit canvas layer.

There will be some kind of minimal editor widget to develop entirely in app, but there is no way I want to tackle building a full fledged IDE. Plus I like TextMate and VIM, anything I could build editor wise would just feel like a half-assed clone.

Its symbol based & node based, not layer based. Think of FireWorks but with symbols that are generated from HTML. And instead of applying filters, layer styles, effects etc through menus; there is only one way, the node editor. The WebKit canvas possibility is not just at the primary view/page level but at a symbol level as well. E.g A vector graphic could be a vector image or a WebKit canvas layer.

This means things like layer styles done in CSS3 for a WebKit symbol and for a image symbol its layer styles are done as nodes. Why nodes? Its GEGL based for all images. This level of abstraction goes for the drawing tools as well. Same drawing tools different canvases. Imagine drawing vectors directly in canvas. Vector to complex? Simply convert to a vector image layer and continue drawing.

What its not

Unlike FW or Adobe Catalyst this is is not an in-between app. No pseudocode, layout is done entirely in CSS/HTML. Adobe put an almost comical amount of effort into developing things like MXML etc that essentially re-invented the HTML/CSS wheel. Who in their right mind thinks this is easier than HTML/CSS?

<mx:Form>
	<mx:FormItem label="Email:">
		<s:TextInput id="email_ti"/>
	</mx:FormItem>
	<mx:FormItem label="Password:">
		<s:TextInput id="password_ti" displayAsPassword="true"/>
	</mx:FormItem>    
	<mx:Button id="myButton" label="Click Me" mouseDownEffect="{myWL}"/>
  <mx:Button id="myOtherButton" label="Click Me" mouseDownEffect="{myWL}"/>
</mx:Form>        

Of course there is a reason why these tools use a pseudo HTML language, the app needs metadata for elements.

Take a sprite for example. You cant edit a sprite without being able to determine where to get its source. In a pseudocode app you might point the source file like <mx:Sprite source="" /> and when you edited that element you'd open a symbol view and edit it.

More on how it works.

I'm solving this metadata issue using a clever scheme of abstraction. The end metadata is the same, but it can get there via a variety of ways;

1. Conventions.
   There will be variety of conventions to accomplish things likes sprites, automatically creating a graphic symbol for background layer etc. Need a graphic symbol add the class "symbol". The only problem with class usage is it can pollute your html with useless classes.

2. A canvas that can be spoken to. With JS bindings the WebKit rendering can tell the app what to do. Not using a local based tech? No problem just code up some javascript to tell the app how to get things. Need to tell it what is a sprite, add some JS.

3. Creating HTML within the App.
   This wont be the preferred method but there will be a way to create HTML symbols and the resulting css will use absolute positioning. Just like other WYSIWYG apps.

4. Creating metadata in the app.
   Think a WebKit inspector, click on element and pickwick (After effects term) to a Graphic symbol. That symbol becomes the background.

5. Language Extensions. Pseudo code isn't bad if its done right. The right way is to respect the existing philosophy of the language being extended. Things like background-filter: -appname-gaussian-blur(radius); are perfectly fine however <appeleem:filter name="gaussian"> <img></img> </appeleem:filter> is not.

The End

Ultimately what I'm trying to is build a web design app that takes popular workflows into account and tries to take them to their logical conclusion. Perhaps thats Adobe's biggest problem, not many of their devs do actual web-design. I don't want an entirely new web design workflow I want my existing one to be better.

More about the tech later. Questions?Ask me on twitter b00kworm