The Unforgiving DOM, How to Remove an Object from the DOM

Sep 30, 2006 by Matt Ammerman

This morning when working on some user interface pieces, I came upon a situation that required me to remove an HTML element (in this case a tag) from the page.  Not just hide it, but delete it completely.  This, of course, is done through the Document Object Model.The cross-browser way to accomplish this is as such, where the span element has an ID of ‘MySpan’:

myObj = document.getElementById('MySpan');
myObj.parentNode.removeChild(myObj);

That’s finding the span in the DOM and then telling its parent node to delete the span as a child node.  (You could do this with myObj.removeNode() without needing the parent, but that does not work in all browsers).

However, my situation was a tiny bit different… I needed the span element to be removed if it (itself) were clicked on.  Again, we go to the DOM, and we modify the span element’s onclick behavior:

myObj = document.getElementById('MySpan');
myObj.onclick = function removeMe() { this.parentNode.removeChild(this); }

It’s that simple. 

So why is this post called ‘The Unforgiving DOM’?  Well, think about it, that onclick handler is telling the span element to tell it’s own parent to execute the removal.  Now, if the removeNode() method mentioned above worked in all browsers, we’d have simple DOM object suicide (myObj.removeNode())…. but instead, we have to tell the object to tell its parent to commit filicide.  Seems a little harsh, eh?  Almost Shakespearean.

 

read more

SaaS Requires Less Competition and More Collaboration

Sep 27, 2006 by Matt Ammerman

Part of the reason that the move from a traditional software business to the SaaS model presents difficulties to independent developers is just that:  they’re independent.  As SaaS finds roots in the workplace, end users demand the custom integrations and mobility that they’ve come to rely upon in their current (or previous) client-server infrastructure.  So what, or who, in the SaaS world provides these added values of integration, collaboration, and mobility?

With service-oriented companies spawning left and right, fueled by the “If It Ends In ‘r’ or ‘igg’ It Must Be Web 2.0 Goodness” milieu of today’s SiliconValley, and the seemingly blurry lines between an understanding of pure SOA and Web 2.0, true enterprise SaaS applications run the risk of becoming a fragmented pool of killer apps coupled with mashups.  That works in the consumer space, but the corporate world needs something a bit more solid.

The answer is in SaaS enablement technology.  The Internet by itself does not take the integration and collaborative hurdles away from independent SaaS providers, if anything it promotes disparity and a reliance on mashup-style 3rd party integration, as evidenced by Web 2.0.  For SaaS to thrive, a fundamental purely service-oriented layer is required – and this layer has come to be known as ‘SaaS enablement’ technology.

read more

Scale as a Commodity

Sep 26, 2006 by Sinclair Schuller

I’ve been keeping tabs on SaaSCon and the speakers. A post on the SaaSCon Revolution blog seems to paraphrase Hummer Winblad’s Ann Winblad:

SaaS allows software companies to SCALE at a rate that is so much higher than traditional software companies.

This statement couldn’t be more true. One thing I tend to think about is the long term effect of what this means. In the future, I see scale as a commodity rather than a differentiating characteristic found only in the most expensive software packages and developed by the engineering and infrastructure elite. SaaS really helps define “Scale for the Masses.” As the industry moves in this direction, the focus can be moved to software functionality (the stuff that counts) and away from software overhead (waste of everybody’s time). That’s a beautiful notion;-)

read more

Addendum to SaaS Enablement Collaboration Post

Sep 25, 2006 by Matt Ammerman

In my last post, I mentioned that SaaS enablement technologies must support and promote vendor collaboration and integration. 

Here I’d like to provide one caveat to that statement:  independent software vendors still need a sense of identity.  If your SaaS enablement platform swallows all vendor recognition, what incentive do they have to market their own applications?

I raise this question after visiting the AppExchange from Salesforce.com.  The AppExchange is probably the best known, and definitely the most widely used, early SaaS enablement platform.  But here’s what I saw when I visited the AppExchange and clicked on an application category to peruse the selections:

I wonder if the makers of EDVantage lite and NPOrganizer lite are happy that they paid enough money to be sponsored, but not enough to have their company names displayed.  Not to mention the screenshots… which basically turn the decision of which app to choose into “the left one or the right one”.  These vendors have been stripped of their identities AND have paid extra money to be sponsored in the AppExchange only to present potential subscribers with a 50/50 chance of picking their software.  In this case, it would seem that both the AppExchange marketing model, and the AppExchange development model (i.e. the similar UIs) are working against the vendor.

You can’t fault the vendors on this one.  Instead, this brings up an important point for SaaS enablers.  Wrap your vendors in SaaS enablement, provide them a platform on which to launch service-oriented software, let them work together, but most importantly:

Let them create what they are capable of outside of your platform, not what they are capable of because they are using your platform.

I know - ”Easier said than done, Matt”.  To which I can only respond – stand by and check back often.

read more

Strategically Choosing SaaS Enablement

Sep 25, 2006 by Sinclair Schuller

SaaS enablement technology is a driving force behind the adoption of SaaS. When going the route of using enablement technology or an underlying platform for a software as a service offering, the decision can be nerve racking. After all, you as a software engineering firm or vendor are molding part of your strategy as a business entity around something external and out of your control. While browsing for new and interesting bloggers, I bumped into David Terrar’s Business Two Zero blog. Two articles caught my eye: AppExchange – killer app or all hype? and a similar article for Jamcracker entitled Jamcracker = AppExchange without the CRM tie in. Cutting through some of the article, Terrar implicitly provides some insight to what is and is not important on the enablement level which closely aligns to where I see Apprenda going in the future.

In the former of the two articles, Terrar states that “…it sounds like the AE [AppExchange] platform itself is a much thinner technology base compared to things like Netweaver.” The title of the former is quasi-parallel to the statement I’ve highlighted. The real take away is that software vendors do not like to be tied down, locked in (as in “vendor lock in”), or otherwise gagged by their technological decisions. However, these same vendors do not want to use software components or foundational platforms that prove too rigid, preventing them from exercising the full extent of their creative capability. Once a vendor has decided that some set of enablement technologies fit their technological needs, they need to analyze their decisions based on a strategic approach. The strategic approach really needs to focus on the two aforementioned factors.

 

When deciding on what technology to use (for example, Jamcracker vs. AppExchange) the attributes of ‘Transparency’ and ‘Flexibility & Control’ should come into play. Transparency is most simply described as the factor that determines the amount of vendor lock-in experienced. The more transparent the technology, the less lock in. Vendor lock-in is reminscent of being a consumer in a monopolized market: The technology has created the unfortunate constraint of being a corral of sorts, preventing a consumer of that technology from investigating other solutions in an inexpensive fashion in the event that the quality of the prior has been reduced to unsatisfactory. Flexibility & Control determines how much creative muscle you can flex with the technology you have. Some technologies drastically dampen a developer’s capabilities. We can strategically map these two concepts (see matrix above) as relating to the integrative risk that a development firm takes on, how coupled or “married” it is to the technology and the effect of the technology on its market agility (ability to respond to market needs).

Enablement technologies for delivering software as a service are all over the chart. For example, it seems as if Salesforce.com’s AppExchange and NetWeaver fall somewhat under the category of very low transparency. AppExchange is very meta-data oriented. Their own marketing material(PDF) -See Page 3- states that the meta-data model has limitations, but then try to spin it with a phrase indicating that the limitation is a boon to the developer…right… Although I do not have direct experience with AppExchange, after much research and discussion, they seem to fall somewhere in the lower left quadrant of the matrix, as does NetWeaver. Being forced to develop the server side with nothing but meta-data and a constraint hierarchy (p number of pages, n number of ‘custom objects’) seems cave-manish and can definitely be defined as ‘opaque.’ In addition, it heavily reduces the amount of flexibility. Others fall in less restrictive quadrants, but nonetheless require the ISV to carefully make a platform choice because of the restrictions inherent to their technology sets.

I urge anyone reading this that is looking to develop or deploy an SaaS application to stay tuned and remember this article!

read more