In several recent projects we attempted to replace Tinymce as the leading content editor of choice with the much simpler Nicedit. We did not have any great need for the advanced features Tinymce offers and were looking for a much smaller, easier, faster tool.

While I’ve used nicedit before in basic situations and had no problems, I encountered several fatal issues which caused us to revert to Tinymce.

Inner-DIV Implementation
Nicedit creates a new DIV element that relies on some newer HTML features to work properly. Multiple issues stemmed from this, but the primary problem was that all CSS from parent elements would cascade into the DIV, thus forcing me to reset or modify some of them.

Tinymce uses an iframe which is a completely new document, so all CSS does not filter through. This also helps avoid the following content problems.

API
When ajax load/save techniques were used, there were problems with how Nicedit would copy it’s content back to the textarea, thus requiring extra programming. The API documentation is not that great, so it was a little difficult.

Elements Used
In firefox, Nicedit would use a different set of markup elements than it would in IE, making the output harder to predict. This issue is partly due to the use of the Inner-DIV and contenteditable attribute. When filtering the input for markup, we had to allow for both sets of elements. In firefox, the elements were all SPANs with style attributes, which isn’t anywhere near semantic.

Firefox LI Bug
Instances of the editor inside of a list item would have a fatal problem with newlines. While you could type alphanumeric characters, newline key presses would have no result. This was a fatal problem that took some time to debug, but it’s been filed and is awaiting resolution.

Obviously, nicedit is a lot less powerful and has a much smaller community. While it works well for quick needs, nicedit just didn’t work for more standard uses, and we found tinymce a much better solution despite it’s bulk. Since then I’ve managed to weed out a lot of tinymce code we weren’t using, optimize it like crazy, and create some custom plugins for it.

Since the recent policy changes we announced in January, it’s become necessary to expand on the new policy regarding project specifications. Project spec documents can be a chore sometimes, but they’re almost the most important aspect of the entire project.

The new policy from January requires that any projects above $1k have an official specifications document and (optionally) mockups that define the official scope of the work. This document needs to be started by the client as they document what they want, and finished on our end as we document the work and technology involved.

But what happens is that it’s often a chick-or-the-egg scenario where clients need an estimate before they can spend time doing a spec, and we need a spec before I can do an estimate.

Beginning immediately, we’re slightly modifying the policy:

We will provide a pre-spec estimate for initial approval. This estimate will clearly be labeled as pre-spec, but will not guarantee the final cost. Once approved, we will require a spec document/material to be submitted by the client. We’ll review the documents, add the technical portion, discuss the revisions, and then provide a final estimate. Before work begins, a signed copy of the project spec and the final estimate must be returned.

To help explain why this document is necessary and how it can be created, please read the “Project Spec Requirements” document.

Trellis Development (a parent company of web-based products which I co-founded) has been developing a custom content management system which needed a form creation tool. I adapted a form builder that I created for a previous project as a jQuery 1.3 plugin. It loads in existing form structure data through an XML file (which would be generated on the server) and passes the changes as a serialized array back to the server.

View the Demonstration
Get source from github

I’ve forked the code from the cms to serve as a stand-alone plugin. It’s extremely easy to setup, as all you need to do is to activate it on an un/ordered list item element. Then, write your backend code to handle the incoming array as you need, and output the xml data for when the form loads.

<ul id="form-builder"></ul>

$(document).ready(function(){
	$('#form-builder').formbuilder({
		'save_url': 'save.php',
		'load_url': 'form-a.xml'
	});
});

The save_url is the url that the ajax will be sent to when the user saves the form. The form information is serialized so that the backend programming may handle it as an array.

The load_url is the url of an xml file that describes any existing form information, and the system uses it to restore the fields.

This requires jQuery 1.3+ and uses the scrollTo plugin for nice scrolling.

This is the first revision that’s external to our cms so I’ve labeled it 0.1.