Improving Edit in Place

Dan Rubin made comment on an implementation of Edit in Place I had linked to:

"I'm stumped about how one would further optimize or improve (Edit in Place), but I'm also curious: would you improve it, and how?"

What's interesting is that there are two aspects where improvements can occur: implementation and design.

Improving Implementation

By implementation, I mean, how has the developer put it together to give his code flexibility and allow for the extensibility of his code in ways he never expected. (Flexibility and Extensibility were two of my keys of Rapid Development presentation, by the way).

Take a look at the code for the EIP article that I had linked to and you see stuff like this:

if(set['type'] == 'select') {
   field = '<span id="' + set['id'] + '_editor"><select id="'
      + set['id'] + '_edit" class="' + set['css_class'] + '" name="'
      + set['id'] + '_edit">';

But what if I wanted to set my own class on the span? or wanted to add some additional properties to the select? I don't have that option. The EIP object takes a restricted set of properties and that's it.

However, this could be done through a properties object that could be passed in. A default object would be stored in the EIP object and it's properties can be overridden by the properties object passed in.

var o = {
  "id":"editinplace",
  "class":"help",
  "value":"defaultvalue"
};

for(i in o)
{
  s += ' ' + i + '="'+o[i]+'"'
}

This example is just a snippet but the o object just has a series of properties and values (a valid JSON object, in fact). Then we loop through each property and append the key (the part before the colon) and value (the part after the colon) onto the string that would be my innerHTML. In fact, if you were a DOM purist, you could instead create and set your attributes in the for loop.

Improving Design

From a design perspective, the examples given weren't bad but I found them "jumpy". The padding on hover didn't feel right. Certainly this is just a style issue and easily fixable. But there are a couple other things, such as the "saving" dialog. It pops up in the same place as the editing. Can I have this appear elsewhere, do I have control over how this looks and feels?

A callback mechanism would be a nice to have for before edit, before save and after save events where I could simply tie in my own saving feedback.

Another subtle design thing that Flickr does is retain the yellow highlight for an extended time once you've left the editable area. This is effective at drawing you back to this editable area but also minimizes the jumpy feeling that one gets of seeing the yellow turn on and turn off from an accidental swipe through the area.

"There are 4,382 ways"

Okay, I think I ripped that from Dan Cederholm's Bulletproof presentation but the point being that there is always more than one way to solve a problem. And in JavaScript, there are ways to make it easier for others to use our code.

Published July 25, 2006 · Updated September 14, 2006
Categorized as JavaScript
Short URL: https://snook.ca/s/629

Conversation

5 Comments · RSS feed
Dan Rubin said on July 25, 2006

Thanks Jonathan, this is exactly the kind of explanation I was looking for - constantly expanding my poor level of understanding :)

Joseph Scott said on July 25, 2006

I've been wrapping up a new release of EditInPlace that fixes some bugs and adds some additional flexibility. In general I've tried to lean more towards low bloat instead of unlimited possibilities.

My JavaScript skills are pretty basic and I've been learning a lot from writing EditInPlace. Based on some of the feedback I've had on the project there are many, many ways to write similar solutions.

Sean Sperte said on July 25, 2006

How about integration with dynamic databases so we bloggers can edit-in-place our blog entries? :)

Jonathan Snook said on July 25, 2006

Dan: glad I was able to explain it a little more. :)

Joseph: Sorry if this came across as a knock on your skills. That was unintentional. The goal was the mention an alternative, one that hopefully offered more flexibility and could do so without adding bloat to the code.

Sean: that's a pretty cool idea. Let me know when you've got it built. ;)

Joseph Scott said on August 03, 2006

The new version (0.3.0) is up. The announcement addresses some of your points, a few new features and bug fixes.

I've rewritten this thing a few times now, I'd be interested in hearing your comments on my approach for 0.3.0.

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.

Want to learn about scaling CSS for large projects?

I'm available for full and half-day workshops on scalable CSS architecture. I can provide on-site training for your team. Interested?
Get in touch.