provides some great functionality but doesn't have a convenient way to delete multiple rows or move rows around within a table. I've created some changes that barely touches the existing EditTablePlugin
- 14 Mar 2007
Very cool addition. I have really missed this feature for a long time.
Some suggestions and a few details.
First the details
In the EditTablePlugin
topic you need to hack the text file after editing so that
- The author is TWikiContributor
- The revision is $Rev$
Then some suggestions.
- I find the icons for move and delete very large and very colourful. I think it would look better and take less real estate making them 16x16 pixels and with transparent background so it will fit better different skins.
- Insert row is not needed because you can add a row and then move it. But maybe we should consider insert as well?
- Since this is a default plugin I propose that the new feature is turned off by default so that upgraders do not see any difference. And then you can either selectively turn the feature on or turn it on my default. I would personally turn it on by default
- I had to experiment a bit to find out how the move feature works. One detail that I think people will fight is that if you click the move button and then accidently click the delete button of another row you delete the row and move nothing. Maybe the delete feature should be disabled while you have the move activated. If this is possible.
Finally a question that I could answer myself if I had time this morning.
- 15 Mar 2007
I am working on an update. I will address the most important issues.
- Created new icons, in line with TWikiDocGraphics
- Added redrawing of alternating row colors after moving/deletion
- Made delete button disabled when moving. Created a "disabled" delete button image.
- Added an animated gif as drop targets. Still not the best interface.
- Added link objects to the buttons to let a mouse hand appear at rollover
- Moved hardcoded styling to
- Refactored the plugin topic to remove references to Mishoo (no longer used)
- Added twiki CSS classnames to form objects
- Fixed the "eating of double newlines" bug: 2 or more newlines (to create a new paragraph) are now kept when the table is saved
And yes, it does fallback gracefully. No js: nothing to see.
Waiting for release, not released yet.
Thanks guys for the attention and help so far! I really like the idea of changing the move button's appearance when a move operation is in progress. Does this perform well on large tables and low-end hardware too?
- Thanks for the new delete and move icons -- much better than my originals :-).
- The ability to enable/disable the dynamic editing features is also quite thoughtful, so thanks again. However, I propose that if this goes to release, it should be the enabled default functionality. It's just my guess that more users would be served by having the dynamic table editing on by default, than otherwise. Since it adds to, but doesn't doesn't change the previous functionality in any way, backward compatability is preserved. The only users I think could actually be harmed would be those who use browsers for which the feature is broken, and hopefully we can find and address any such before release.
- There appears to be a bug in the code that changes the button graphics when a user clicks the move button. At least in Firefox: every time I click the move button, the browser jumps back to the top of the page.
- Some of the new changes do not appear to be related to this particular enhancement. They're probably good changes, but are there other item number topics that should be referenced here and in the SVN commit log? For example:
- eating of double newlines
- Removing of references to Mishoo
- Change the calendar button functionality
- Addition of CSS classnames to form objects
- 17 Mar 2007
Looking over the way alternating row colors are handled in the updated code, I have a couple comments:
- The code appears to force every cell in the table to have a specific background color, even if it has to use a hardcoded default of #FFFFFF. I think this could mess up cases where the colors are supposed to be inherited from parent elements, including use of the CSS classes, .twikiTableEven and .twikiTableOdd. Haven't tested this yet, but I think we'll want to support some kind of "none" color.
- 17 Mar 2007
About default yes or no: the current interface is still not intuitive enough to let it out in the wild. Upgraders will be faced by a new interface and they will have to instruct their users how to work with it.
I've included more fixes to this enhancement. I've changed the entry summary to include these.
Alternating colors: This can probably be mostly fixed by initially scanning row colors into a list until we encounter a repeated color.
This has the problem that colo sequences may have colors listed more than once, for instance "blue, red, blue, green". Edit mode does not have
to mimic the view mode. For instance, there is no point in keeping a blue background while the textarea is just white with black text. Alternating colors should enhance readability of the table. So perhaps we could just stick to 2 fixed colors, set in
- Fixed jumping to top bug by not using a link element but by setting the mouse style with CSS.
- Background color is no longer forced.
- 17 Mar 2007
- the current interface is still not intuitive enough -- Yeah, I agree. My original version popped up a dialog when you click on a row to be moved, to tell you what to do. But that was just way too chatty. This way is much more effective to use, but less intuitive. There must be something we could do to make it more user friendly. Got any ideas? Maybe adding some kind of context help or a one-timish dialog?
- I think it might be a good idea to improve the way color and style updates are maintained. Currently, it looks like every move operation causes the scripts to process every cell in the table, even if a row is only moved by one position, right? I think the function that moves the row could update the styles and colors while it's processing the affected range. For large tables, I think this will yield a pretty good improvement in average case processing time.
- I'm also toying with the idea of an undo feature. Do you think this would be useful? It's not completely necessary because a user can always cancel their edit session. But if they've made a lot of changes that might be unfortunate.
- 18 Mar 2007
Hmm, possible answer to making the interface more intuitive: In addition to the animated move button you provided, how about simply adding a message to the browser's status bar? "To move this row, select a destination". Fancier things like floating tooltips are also possible, but it's a matter of deciding how much messaging is the right amount to communicate this functionality to users. What do you think?
- 18 Mar 2007
The confusing thing is you now seem to drop the row unto another one, while in fact you want to claim only the position
. It may seem now rows will be swapped. It would be better if you could drop the row in the position between
- 18 Mar 2007
We could certainly do that. We could provide a very thin separator between rows, on which users could click to effect a move. It would mean doing away with the animated move buttons though. I'll give that a try. (BTW, have not added the insert-row feature yet. Was too busy this weekend.)
- 19 Mar 2007
Yes, the animated targets are no longer necessary then, but the move buttons would need to show a disabled state anyway. Leaves the question what a "cancel move" would be...
- 19 Mar 2007
Okay, I've committed a change to this effect. There is now a thin area between each row that is used to specify the move destination.
- 20 Mar 2007
I really like this last enhancement. A major improvement in usability.
- 20 Mar 2007
Do you think this feature set now rises to a level of usability such that it could be enabled by default? If not, what else might we be able to improve? (BTW: Thanks again for your time and input so far
- 22 Mar 2007
The move buttons need to be disabled when starting to move. I think 2 lines of animated gif dots would give a better indication where to move to. The alternating colors could be simplified to 2 default (light blue and white).
- 23 Mar 2007
Hi -- I've just been waiting to see if Ken or anyone else would offer comments before I took further action...
So, if I read this right, is the suggestion that the 2 lines of gif dots would surround the row which has been selected to be moved? That is quite doable with a "background-repeat" style. I'll put it in.
Once this is incorporated, is there a good way to get more feedback from anyone other than the three of us? Since I'm advocating turning this on by default, I'd just appreciate any eyeballs and feedback we can get, to help make sure it's thoughtfully implemented.
- 29 Mar 2007
I've gone ahead and implemented (my interpretation of) Arthur's suggestion. Moving dashes are now displayed above and below a row that has been selected for moving, and the old move button graphic with moving dashes has been removed.
As usual, I've tested this in Mozilla and IE 6, and would be grateful for reports of compatibility in other browsers, or in fact any kind of feedback at all.
- 24 Apr 2007
Since there's been no further comment in a while, I've changed the state to "Waiting for Release".
- 11 May 2007