This is the sort of thing I'd be wary of using jQuery for. An activity like this demands high performance and the cruft added by jQuery is noticeable in tools like these that I've tested. contentEditable (and its IE relatives) is pretty easy to get the hang of, why not just write one in straight JS?
Recently I had to roll my own Editable Grid plugin.. We started at 1.0 using jqGrid, but we got a lot of negative UX feedback after releasing it. Speed issues but the vast majority was functionality.
The User Story for 1.0 was simply to be able to edit the data in the grid directly. Balsamiq mock-ups showed the editable grid and we got their buy-in.
But when we launched, man oh man.. nobody complained, because it IS idiomatic of the web. But when we asked them for their pain points, we got an ear full about this.
What the user story should've said, was that they wanted a Spreadsheet. A domain-specific spreadsheet control.
Soooo we rolled our own and so far so good. What we learned about the speed issues is that it was the jqGrid plugin, not the framework. So we stuck with JQ and wrote our own plugin.. We give them a filter to get the data they wanted easily, and we designed it to be no-lag responsive with 100 rows and hardly-noticeable-lag responsive up to 250.
But in the wild users were digging the excel-like UI and loading up 400, 500, 700, even 1000 rows. And they were dragging and dropping and shift-selecting columns and applying functions.
So we spent a lot of time under a JS profiler in FF3 and we got it running positively speedy. We thought about making it standalone outside of jQuery but we just didn't have a reason to. The data just didn't support it.
And, of course, when we first installed a pre-release of FF3.5 we were ecstatic with the performance.
All I'm saying is, jQuery has served us well, and this use-case isn't much different than a traditional edit-in-place.
Now... users are wanting the ability to type their own formulas.... ugh... I prototyped it a few weeks ago and just the churning needed for constant circular reference checks alone makes me weep.
So I clearly disagree that jq is too slow for heavy tasks, but I also wonder... what cruft do you see in it? Cruft and abstraction are obv. different things.
6 comments
[ 5.0 ms ] story [ 27.0 ms ] threadThe User Story for 1.0 was simply to be able to edit the data in the grid directly. Balsamiq mock-ups showed the editable grid and we got their buy-in.
But when we launched, man oh man.. nobody complained, because it IS idiomatic of the web. But when we asked them for their pain points, we got an ear full about this.
What the user story should've said, was that they wanted a Spreadsheet. A domain-specific spreadsheet control.
Soooo we rolled our own and so far so good. What we learned about the speed issues is that it was the jqGrid plugin, not the framework. So we stuck with JQ and wrote our own plugin.. We give them a filter to get the data they wanted easily, and we designed it to be no-lag responsive with 100 rows and hardly-noticeable-lag responsive up to 250.
But in the wild users were digging the excel-like UI and loading up 400, 500, 700, even 1000 rows. And they were dragging and dropping and shift-selecting columns and applying functions.
So we spent a lot of time under a JS profiler in FF3 and we got it running positively speedy. We thought about making it standalone outside of jQuery but we just didn't have a reason to. The data just didn't support it.
And, of course, when we first installed a pre-release of FF3.5 we were ecstatic with the performance.
All I'm saying is, jQuery has served us well, and this use-case isn't much different than a traditional edit-in-place.
Now... users are wanting the ability to type their own formulas.... ugh... I prototyped it a few weeks ago and just the churning needed for constant circular reference checks alone makes me weep.
So I clearly disagree that jq is too slow for heavy tasks, but I also wonder... what cruft do you see in it? Cruft and abstraction are obv. different things.
http://code.google.com/p/jquery-in-place-editor/
used it several times... excellent; flexible.