Previous Entry Share Next Entry
Quick question about bulk-edit defaults
querki
jducoeur wrote in querki_project
I'm looking for a sanity-check from the crowd. This one's purely a design decision, not a technical one.

I'm finishing up the first-draft "bulk edit" capability. Basically, the [[_edit]] expression, when used on a Model, is going to mean "let me edit all of the Things of this Model, on a single page". I expect this to be useful enough that it'll become a standard feature pretty quickly.

For the use case at hand, we need a "Create a new Foo" button at the bottom of the list -- when you press that, it instantly creates a new instance, in place, ready for you to fill in. This will make it *vastly* faster to enter a large number of records. But question #1 is: should that button always be present? My original plan was that you would have to explicitly say something like [[_edit(_withAddButton)]] to show the button, but the more I think about that, the less sure I am that there are likely use cases for not showing it. I'm now leaning towards including it by default (if the viewer has Create rights), and later adding a parameter to *suppress* the button if it's not desired. Opinions?

(I think I'll also eventually add a "Delete" button -- an "x" in the upper-right corner of each mini-Editor. Anyone see a likely problem with that?)

Finally, another, subtler question. When I press the "Create" button, where should the focus go? Should the text focus stay on the button (so that you can create several at once), or into the first field of the newly-created Editor? My guess is the latter (you can always create several in a row by clicking the button with the mouse instead of the keyboard), but I'm honestly unsure of the ideal workflow here...
Tags:

  • 1
* I think showing Create by default makes sense.
* It might be that showing it at top and bottom makes sense? Not sure.
* I don't have a strong opinion about the text focus, but do think that unless the UI update is basically instantaneous (and perhaps even then) that there ought to be some way to create more than one Thing at once. Otherwise, I'm going to have to click that button 180 times in a row and wait for the UI to update after each one, and that'll get annoying *really* fast; it also means I need to keep track of how many times I've clicked the thing. This is a one-time annoyance, but it's also an up-front barrier, which you probably want to avoid. (Even a "25 at a time" button would make it less stupid, and would be less abusable than free specification.)
* Relatedly: is the bulk edit page capable of pagination? Most browsers will grind to a slowdown (or halt) on pages of sufficient complexity; I've no idea if my 180-Thing page would run into that or not.
* Relatedly relatedly: is it possible to filter the instances going into [[_edit]]? (I don't know that this would be necessary, except as a workaround for pagination.)
* And: If you call [[_edit]] on a Model which has only sub-Models, do you end up adding/editing sub-models, or instances of all child models?

I don't have a strong opinion about the text focus, but do think that unless the UI update is basically instantaneous (and perhaps even then) that there ought to be some way to create more than one Thing at once. Otherwise, I'm going to have to click that button 180 times in a row and wait for the UI to update after each one, and that'll get annoying *really* fast; it also means I need to keep track of how many times I've clicked the thing. This is a one-time annoyance, but it's also an up-front barrier, which you probably want to avoid. (Even a "25 at a time" button would make it less stupid, and would be less abusable than free specification.)

Hmm. We'll see what the speed is like -- it's near-instant on my test machine, but I don't know what we'll see on the real server. I *think* it's mostly a question of wire latency, but we'll see.

I'm surprised at your expected use case, though. I almost never try to populate all of my new entries at once in a UI like this; I generally do maybe ten at a time. Do you actually expect to want to create everything, and then fill everything in at a shot? I suspect that's unusual, if so, but I might be wrong.

Relatedly: is the bulk edit page capable of pagination? Most browsers will grind to a slowdown (or halt) on pages of sufficient complexity; I've no idea if my 180-Thing page would run into that or not.

Good question. No, and yes I'm concerned about it. We'll see what the reality looks like. I expect that pagination will be necessary sooner or later -- the question is, as you say, whether your case forces that issue.

Relatedly relatedly: is it possible to filter the instances going into [[_edit]]? (I don't know that this would be necessary, except as a workaround for pagination.)

Not yet, but I've thought about it, and will probably add that whenever we get to the need. It requires a specific QL enhancement that I've been planning, so that we can have syntax like [[_edit(filter=_equals(Element,Fire))]].

That said, it can already be mostly worked around easily enough, as [[My Model._instances -> _filter(_equals(Element,Fire)) -> _edit]]. So I'm not too worried.

And: If you call [[_edit]] on a Model which has only sub-Models, do you end up adding/editing sub-models, or instances of all child models?

As currently defined, just instances. That might possibly change, but my current party line is that Models and Instances have sufficiently different requirements that their Editor UIs are going to begin diverging substantially. I have no plans for bulk editing of child Models -- I strongly suspect it's a bad idea...

I agree with Mindways, and add:

--a "push button" keyboard command, along with focus shifting to first field, would allow you to either create-and-fill OR create-create-create equally easily

--a keyboard UI I remember from some tool I used in the 80s was prefix multiple -- kit a magic multiplier key, then a number, then the command (or click a button). Cash registers used to implement it, too (or sometimes a post-fix version). Perhaps this would be helpful both here and in other places?


Possible, although I'm fairly suspicious of subtle commands like these: it's too easy for them to turn into a design crutch that winds up over-complicating life for the typical user. That said, it might be a way to deal with mindways' use case, which seems like a power-user feature anyway.

The keyboard command effectively already exists -- that's what the spacebar does, simply by browser default. That's really the motivation for my question: should the assumed "standard" case be hitting the spacebar to create a new entry, and then immediately begin typing in it, or hitting spacebar several times to create several entries, and then having to, eg, mouseclick to go back and begin entering data. I'm genuinely unsure which is likely to be better...

Thinking more about using it: If the button's at the end of the form, I'd say put the focus onto the newly created record. That gives the fairly natural workflow of:

1. Click button
2. [Type-tab-type-tab-type-tab-type-tab to fill in record]
3. Spacebar to create new record
4. GOTO 2

Much friendlier to not require any mouse usage. Zero clicks is way better than even one click.

And I realize this also obviates the need for the create-lots-of-records; the primary motivation for that was so I wouldn't have to break out to perform a mouse click after every record.

Okay, cool. Yes, pretty much that exact workflow was my rationale, and this afternoon I'm trying to get that working...

Right. This is an established workflow I think. I use it all the time in something like excel, or online survey forms where it is 'next page', type-tab-type-tab, tab to next page button, hit spacebar.

Ah, I see. I think the problem is in having an "in band" command -- space. If the command to "hit the button" is "out of band" -- i.e. Meta-control-cokebottle --, then that problem goes away. My suggestion of a prefix "do many" command (also expected to be out of band) was both in response to Mindways' use case and my own recollection of frequently wishing I had that feature.

When composing lots of text, it's certainly irritating to have to keep returning to the mouse.


Just so, hence the question. Each of the options favors a particular operation, and uses the mouse for the other one. If space sends focus to the next field, then you probably need to use the mouse to do create-many. (Although your out-of-band command key idea is a possible workaround.) If space keeps focus on the button, then you need to mouse up to the text-entry field when you're done creating. (You *could* shift-tab back to it, but that's a hassle.)

I suspect that sending focus to the data-entry probably matches the common use case best, and allows you to work completely mouse-free if you like: you tab from field to field, the final tab takes you to the Create New button, you spacebar to create a new entry, and keep going. We'll see if that works well in practice...

Button by default good.

Delete button, with confirmation good. Perhaps hidden until you mouseover the item, so you only see the delete button in context appropriate way, instead of a superfluous plethora of delete buttons.

Put the keyboard focus on the new Editor. Perhaps put a numeric entry box next to the button that defaults to '1' so those who want to create a raft of multiples can enter the number -then- press the button.

Delete button, with confirmation good. Perhaps hidden until you mouseover the item, so you only see the delete button in context appropriate way, instead of a superfluous plethora of delete buttons.

Hmm. Not a bad idea, but let's get the thing working in the first place first.

Perhaps put a numeric entry box next to the button that defaults to '1' so those who want to create a raft of multiples can enter the number -then- press the button.

Possible, but I think this one fights for its life. It's a very rare feature in my experience, so I'm going to want to see that people actually care before I clutter the UI any more.

but let's get the thing working in the first place first.

Well, once it is working, it's a bit of CSS to change the visibility on mouseover and address some of the visual clutter.

I think this one fights for its life.

Yep. And I'm not going to be fighting for it. But I threw it out as a compromise option. But don't compromise to benefit the very few at the expense of the overwhelming majority, so long as those few have another valid option.

Well, once it is working, it's a bit of CSS to change the visibility on mouseover and address some of the visual clutter.

... okay, that's beyond my poor CSS skills. Do you have details? I basically have a _deleteInstanceButton (technically an absolutely-positioned span) inside an _instanceEditor div. It's not terribly hard to deal with that visibility programmatically, but I don't have the requisite clue to make it happen in CSS. I assume there are some fancy selectors involved in this?

Here's where I picked up the idea from:
https://moodle.org/mod/forum/discuss.php?d=197470

There's a visual explanation at http://imgur.com/a/kzok8#0

Effectively, you set that piece of your setup to have the specified icons set to 'display:none' until you do a hover, and then switch them to 'display:inline'.

Edited at 2014-01-16 09:53 pm (UTC)

Sweet! Yes, that proves ridiculously easy to add, and Just Works. Thanks for the pointer...

  • 1
?

Log in

No account? Create an account