YUI extension grid (and editor) feedback

[ecmanaut]

I really miss a stable sort function in the grid (for example: click the price column to sort by price, click the indoor column to reorder the view only on the indoor-or-not aspect, otherwise keeping the prior price order).
The grid component does not allow editing using keyboard only, except for check boxes. Perhaps revisit the idea of enter hitting the next line, to toggle editing/not-editing contexts instead, similar to how mouse clicks do?
A TextEditor validate shorthand that accepts just a RegExp object rather than a full function would be useful.
Your disabledDates example (http://www.jackslocum.com/yui/2006/09/10/adding-built-in-editing-support-to-the-yahoo-ui-extensions-grid/) is off by a quoting level; it should read "03\\.08\\.03", as string literal notation eats a round of quoting (which RegExp literal notation /03\.08\.03/ notation does not).

[jack.slocum]

I really miss a stable sort function in the grid (for example: click the price column to sort by price, click the indoor column to reorder the view only on the indoor-or-not aspect, otherwise keeping the prior price order).

I see what you mean. It may be possible to store the last sort, and then when doing the sorting comparison if value1 == value2, then compare the value of the last sort column. I'm not sure if Array.sort will still function but it might. I will give it a try. This obviously won't work for remote sorting.

The grid component does not allow editing using keyboard only, except for check boxes. Perhaps revisit the idea of enter hitting the next line, to toggle editing/not-editing contexts instead, similar to how mouse clicks do?

The only one I see that you can't edit using the keyboard is the select. Maybe if I attach a key listener to select so *space* clicks it and opens it, then it would be editable without a click too.

I like the enter to go to next line. It is standard for spreadsheet apps. If what you want to do is move to the next item on the same line when you are done editing you use tab. Navigating through the cells does put them into edit mode, but if nothing is changed then it won't affect that data or fire edited events.

A TextEditor validate shorthand that accepts just a RegExp object rather than a full function would be useful.

I have added it. It is in the development version (/build/yui-ext.js). I updated the blog post with the option as well.

Your disabledDates example is off by a quoting level; it should read "03\\.08\\.03", as string literal notation eats a round of quoting (which RegExp literal notation /03\.08\.03/ notation does not).

Good catch, I've updated that as well.

Thanks for the feedback.

Jack

[ecmanaut]

I suppose what I'm reacting to is that all text input cursor movement gets overridden with move-to-adjacent-cell commands. The way I see it, you either use Tab/Shift-Tab only to move sideways through columns, or adopt a select-cell-to-edit approach; breaking cursor movement and cursor selection (Shift + three taps on Left selecting previous three characters, for instance) yields a very hampered editing experience.
.

I see what you mean now. That is irritating actually. Dsiabling something like standard text selection is not a good idea. I opened up excel to see how it handles the same thing. It does move from cell to cell with the arrows, even when you are edit mode but only if the cell is blank.

I also agree there does need to be an edit and no edit mode. I guess it's time to implement a CellSelectionModel and do it the right way. Since Excel is the most popular spreadsheet app out there, I will copy their keyboard navigation scheme and implement it in Javascript. This should be fun.

Thanks for the insightful feedback and persistence. ;)

Jack

[ecmanaut]

I've been doing lots of custom UI input handling work in javascript myself, and it's amazing just how many expectations one has on how text widgets behave, and the amount of code that goes into emulating it manually, like here.

A very useful tip: when you feel you are close to what Excel does, do some hallway usability testing, preferrably with a few persons who in some capacity often edit and/or maintain spreadsheets, and they will likely find a few additional things you didn't think about yourself, but which severely impact the usability for, say, 10-20% of the user base that will actually use this (covering up 90% of the user base by just satisfying "can it be done" is easy, vs the harder "can it be done without frustration with the user interface") eventually.

There always is those last bits of "oh, so ctrl-up/down on an input widget with enumerable discrete steps changes to the adjacent value, i e previous/next date; I had no idea!" -- a fabricated example (which, for all I know, might be true) -- but in general, it is often difficult to get that kind of feedback on your code, for lots of reasons. Not getting it now will have some people feel about the YUI grid the way you did about other grid components when you started working on your own. :-)

[jack.slocum]

ecmanaut,

The latest development version allows for arrow navigation to be disabled or require the control key. This version should be out within the next couple days. Here's what I mean.

Disable arrow navigation:

var sm = grid.getSelectionModel();
sm.disableArrowNavigation = true;


Require control key be pressed for arrow navigation:

var sm = grid.getSelectionModel();
sm.controlForArrowNavigation = true;


These can both be changed globally on the prototype:

YAHOO.ext.grid.EditorSelectionModel.prototype.disableArrowNavigation = true;


Until a second editor selection model allowing cell navigation without editing exists, either of these would allow you to edit text using the arrow keys.