Friday, March 26, 2010

Aptana sucks too

Aptana/Eclipse/PDT is like the cold headache you get from eating ice cream. It seems really great at first, but then you find yourself in so much pain that you forget what you saw in the first place.

I'm setting up a XAMPP environment, with a shared host as an eventual target for the output, along with separate source trees for a bunch of shared "stock" Joomla components/templates/modules/plugins, as well as a source tree for the client's customized site code. After a while, I may need to recreate the XAMPP htdocs area, but anyway an installed htdocs area is never, EVER, sufficient to manage source changes reliably.

So, I bootstrapped the site initially on the shared host, just to put up a work-in-progress page, then found it trivial to pull in sources into a local workspace via Eclipse. Just configure an FTP connection, then configure a local disk connection. After the XAMPP Joomla is installed and bootstrapped (via Joomlapack it is easy), it is a a simple matter to push small changes up to the XAMPP installed directory. Except it doesn't work the other way around. Right clicking on a folder, you'd expect that you could select from the local connection to pull back changes... but it doesn't let you pick the local connection as an option.

I could use Phing, but WTF: I can already use ANT or Phing outside of Eclipse. The one thing I'd like to see in an Eclipse based tool, is SIMPLE features NOT BURIED 10 levels deep, that DIRECTLY eliminate the repetitive tasks of staging files during the development. Instead what I find is that it gets in the way of the work far more than it facilitates it. Currently the staging is too badly broken in Eclipse to pay anything back from the investment of time.

What do I want? I want to be able to tell the IDE simply that when I change a static source file -- one that need not be modified or "built" prior to use -- there is a mapping for where it should be pushed, and a mapping from where it could be pulled, relative to a connection. I thought this was possible with Aptana, but apparently it only kind-of-sort-of works, if and only if the target tree is isomorphic to the source tree. That is a laughably silly implementation for anyone who has done real software work, but it is the (reasonable) result of relying upon external build tools perform the distribution function. Problem is, that's not the way the Web works. Our tools should facilitate the way we work today, not the way a Java coder used to work in the late '90s.

Web "Content Management" ? Don't make me puke!!!

People who use the phrase "Web Content Management" in conjunction with any PHP application should be hauled up in front of congress, stripped of their civil rights, and be forced to buy health insurance. Wait... sigh... too late. Demokrat leadership is way ahead of me.

Ever edit something in Joomla and hit "backspace" accidentally, when the focus just happened to change to the wrong object? You've just lost any work you put into editing. Stupid fraking tools. At least Blogger asks you if you want to navigate away.

And don't get me started on how all these Web 2.x apps are so HORRIBLY SLOW. The keyboard just can't keep up sometimes, and I'm hardly a touch typist. Two-second delays while typing? Really?? Why  do we pay for quad core multi gigabyte systems??? Never mind that the cursor often disappears mysteriously, a victim of using non-native Javascript to emulate native editing. Load up all the modern crap we need just to work on the Web, and my 1980's era Atari ST looks like a performance enhanced hot rod by comparison. (Of course, MS Windows bears a lot of the blame here too.)

Sigh. Layers upon layers upon layers, injecting more and more waste. I want to wash it all away. Get out a simple #2 pencil and paper, and stop killing all these trees. We waste more in packing materials for video screens and coal to generate electricity in an attempt to save paper we haven't really saved anyway from using all these falsely-so-called content management systems.

In the world of the Web progress mostly moves you sideways but creeps forward. Contrast this to congress, where our civilian rights have been rolled back via a nationalized form of 18th century indentured servitude.

Don't chose to believe the comfortable lie of layering in too-big-to-fail. Give yourself the chance to sweep away the institutionalized corruption. Show no mercy. Strip it all away. For only then can you identify genuine opportunities to do better.

Tuesday, March 16, 2010

A New Old Positioning Model forThe Web

One of biggest pain points for Web Designers -- and one that often makes them doubt their skills and abilities -- is that CSS includes a legacy of HTML formatting which, were it to have been a newly proposed Web Design standard in 2010, would be dismissed out of hand as worthless crap. As it is, CSS3 embeds HTML formatting as its enduring legacy, so most people accept the premise without thinking twice and move on with their lives.

I've complained elsewhere about the CSS positioning model and cascading, so I won't repeat those rants. My objective in writing this is to propose another way. Maybe it will be found to be even a crappier way than the bits of CSS we all hate. And maybe I live in a glass house, not having contributed directly to the working group efforts, but I think for the sake of Web Designer sanity it is about time that someone threw the first stone.

We need a new formatting model for the Web. Oh, don't get me wrong: most of CSS is great. The syntax is compact. The abstract model of how style information is attached to the tree is really pretty elegant, even if The Cascade does cause the occasional seizure in the average Web Designer. But the box model interactions are pernicious enough to cause fits of blind rage in ordinary people. Much of the genetic inelegance of CSS really arises from the continued inbreeding with HTML since the early days of the Web.

The solution is to introduce a new strain of positioning model, one which redefines the antiquated notion of "the" in "the normal flow". Here are my premises and logic:
  1. Unless it can be demonstrated that the designer should absolutely not have access to a parameter, all algorithm parameters should be made explicit through syntax.
  2. The designer should be able to control the flow.
  3. Therefore the flow itself should be made explicit to the designer.
In short, I don't think the idea of one "normal" flow was ever sufficient for good design. It is necessary however, for quickly laying out markup. So make "flow" an explicit construct, and refactor "normal flow" as a pre-configured instance which takes over when no other flow is specified.

How? The WDG and W3C vendors seem to have completely missed the boat with CSS3. The most obvious fact that is being ignored is that Web designers have been doing layout for years with markup. Not HTML markup mind you -- the syntax was indeed HTML but as anyone working on HTML5 will tell you, the tags are meant to convey the meaning of content, not the formatted layout. Instead the Web design discipline has very clearly overloaded HTML markup as a primitive layout language.

It is great that CSS allows the designer to separate out the style properties, but it perfectly SUCKS at layout because it got most of its layout algorithms come from HTML formatters, and despite the cleverness of Web designers, overloaded HTML still sucks at layout. It doesn't say explicitly what designers need it to say. Thus, CSS is crippled by its codependent relationship with half-arsed formatting solutions. CSS3 could be so much better, if it stopped looking toward a content specification to specify formatting layout, and instead adopted a separate and distinct markup language to specify layout models and provision formatting algorithms explicitly.

Where can we get such a model? The closest thing in existence today that I know of is XSL-FO. The XSL Recommendation has been tried and tested through years of industrial scale document formatting, yet the overall application model seems poorly suited toward interactive applications.

Is it really?

We are seeing movement in the DITA camp that belies this assumption. DITA is another industrial-strength markup language architecture, which for years has been positioned to perform batch-formatting of content. Yet IBM developers have demonstrated that a little imagination and a lot of work can bring dynamic interfaces for topic-based content forward, exposed directly to face the Web. With a little imagination and a lot of software work, I propose that XSL FO can be adapted to fundamentally enhance the design vocabulary of Web rendering engines.