New sections tab, multi-edit control block

wet · 2012-06-29 04:05:59

Bloke wrote:

whether the nightly cron job runs at GMT or CET

0:00 GMT.

phiw13 · 2012-06-29 08:41:28

When I’m using the new multi-edit widget to delete something (tested: Images pane and Sections pane), I see a weird behaviour:

select some item
from the select widget, choose delete
up comes the alert (‘are your sure ?’), click OK
(weird part —>) I then see (briefly) the widget block expand, display a second select form control and the ‘go’ button.
the second select and the button then disappear.

It doesn’t matter how I style the div class=multi-step multi-option, btw.

Safari 5.1.7 release, Safari nightly build and Opera 12.

Bloke · 2012-06-29 10:06:41

phiw13 wrote:

I see a weird behaviour:

Hmmm, the ‘Go’ button is meant to appear when you select any item other than the label. However, when you select an action that doesn’t require a secondary action (such as delete, or any of the actions on the Comments panel) the form is auto-submitted. At that point you have the option of hitting Cancel if you really didn’t mean it and altering your selection before hitting ‘Go’ to register your intention.

Under both Remora and Classic I don’t see the expansion and secondary control appear as you outlined in point (4) but then the response is so quick that maybe my eyes just can’t keep up with the display.

I’ve tested in both Chrome and FF/Win and can’t replicate the behaviour. Very strange. There’s a possibility it’s a browser thing, but since Opera and Safari use different rendering engines it’s unlikely.

Which leaves us with the code. Are you using Classic or Remora, btw? One of us (probably Gocom!) could check the multi-edit code to make sure it’s not doing any unexpected onsubmit show/hide stuff. If you have any further info on specific circumstances when it does / does not happen it might help us. I’ll test it in an RTL language too in case that has any bearing on it.

phiw13 · 2012-06-29 10:29:45

Bloke wrote:

Hmmm, the ‘Go’ button is meant to appear when you select any item other than the label. However, when you select an action that doesn’t require a secondary action (such as delete, or any of the actions on the Comments panel) the form is auto-submitted. At that point you have the option of hitting Cancel if you really didn’t mean it and altering your selection before hitting ‘Go’ to register your intention.

In both Safari and Opera, when I select the ‘Delete’ option, I first see the js alert, and clicking OK (submits the form and) shows the expanded widget. When I hit cancel in the js alert, there are no problems at all – the ‘go’ button (only that button) comes up. Gecko shows the ‘go’ button immediately while the js alert pops up.

It doesn’t matter which theme is in use, nor which language (Fr/En-gb/Sp).

Under both Remora and Classic I don’t see the expansion and secondary control appear as you outlined in point (4) but then the response is so quick that maybe my eyes just can’t keep up with the display.

It definitively is visible here, or else I wouldn’t have mentioned it. The other options (which should trigger a secondary select + go button) work fine, afaict.

Gocom · 2012-06-29 11:00:23

Good call. As far as I can tell, it’s not a second select field or anything like that. That does indeed happen (so that’s confirmed), but it happens after the document has changed. What you are seeing are the .multi-option blocks that appear when a (new) page is reloading.

This is due to JavaScript processing delay. The .multi-option blocks are visible until the JavaScript has a change to kick in. To fix it, the styles would need following type of lines;

.multi-option {
	display: none;
}
body .multi-step {
	display: block;
}

That should hide the .multi-option blocks until the JS has picked them from the page. In the above .multi-step is an selector applied to an active step.

The other thing, which is the select option and submit button visibility changing only after clicking Cancel/OK, is because JavaScript spawned confirmation dialogs (confirm/alert etc) block the thread and all processing inside the webview process. On Safari that can be noticed as Safari updates the visually visible option in fields (like that select field) after a change event, and not right away (it does update the actual sent value of course, that’s just a visual thing). This, and other processing blocking caused by the dialogs/popups can only be fixed by writing our own dialog implementation instead of using confirm/alert functions.

Last edited by Gocom (2012-06-29 11:08:26)

Bloke · 2012-06-29 11:02:23

phiw13 wrote:

In both Safari and Opera, when I select the ‘Delete’ option, I first see the js alert, and clicking OK (submits the form and) shows the expanded widget.

I’ll download Opera and try it then as I can’t for the life of me see it in Chrome / FF. But, like I said, it may just be that my server is too quick to respond and I don’t notice it.

Interesting that the visibility of the ‘Go’ button differs across browser, with Gecko showing it immediately and some others showing it only after interaction with the Confirm dialog.

It doesn’t matter which theme is in use, nor which language (Fr/En-gb/Sp).

OK, I wont bother looking there: thanks for the report.

The other options (which should trigger a secondary select + go button) work fine

Also useful info, thanks. So it seems that (possibly only in certain browsers) the multi-edit code is briefly rendering one of the other ‘html’ entries on submit, when the option you chose doesn’t have a secondary action. Which means the effect is probably not visible on the Comments page, since that doesn’t employ any secondary action. OK, Gocom figured it.

Last edited by Bloke (2012-06-29 11:03:51)

phiw13 · 2012-06-29 12:13:40

Gocom wrote

Right, that’s exactly what I ‘m seeing.

I added to my stylesheet:

.multi-option {
	display: none;
}
.multi-step {
	display: inline-block;
	margin: 0 .5em;
	padding: 0 .5em;
}

And that improved things (the second block, I already had ); it is not perfect, but it doesn’t feel weird anymore.

phiw13 · 2012-06-29 12:19:16

Bloke wrote:

But, like I said, it may just be that my server is too quick to respond and I don’t notice it.

More like: your hardware is faster at processing the js calls ? My oldish Mac start to show its age… ?

Gocom · 2012-06-29 13:05:38

phiw13 wrote:

More like: your hardware is faster at processing the js calls ? My oldish Mac start to show its age… ?

I use 2010 iMac, and while in Firefox everything is fine even with crazy large <table>s, ridiculously long nodes and nesting, in Safari JavaScript is just handled — as 2nd hand quest. Almost as if Safari makes fetching and getting content on the screen the top priority, sacrificing rest.

Last edited by Gocom (2012-06-29 13:09:26)

Gocom · 2012-06-29 13:29:18

phiw13 wrote:

And that improved things (the second block, I already had ); it is not perfect, but it doesn’t feel weird anymore.

Is there something that doesn’t work? If you mean that it’s not optimal solution or the right solution, unfortunately that’s how we do those things when you need to change something with JavaScript on page load. I.e. you halt loading or hide parts of the page until its ready.

Um, yeah, you won’t fix the dialog block (aka process lock) which is invoked when a (native) confirmation dialog is spawned. That’s what those windows are designed to do. To fix that, Textpattern needs it’s own confirmation/dialog system. And since it’s a lock, I can’t really do anything about it in the multiedit script — other than remove auto-submit. And as it’s invoked auto-side the context (with inline JavaScript), I can’t really either do any type of checks or prepare for it (e.g. reset the selection/step cancel which could prevent it from being visible).

That said, anyone want to write/implement confirmation/dialog/modal system for Textpattern?

Gocom · 2012-06-29 13:39:13

What about if we remove the inline verify() call from the form and we add it to the txpMultiEditForm()? I could add a message option to the plugin, and since Textpattern has now those l18n function for JavaScript, localization is possible directly within JavaScript.

Then when user clicks Cancel in the dialog, we reset the multi-edit method, and remove the added step (if any). This would aid the potential process lock issue, as it’s not visible to the eye. This would also make the submit button behave same in all browsers. As the selection is reset, the button doesn’t need to be added when there is no step.

Anyone against? Suggestions? Shall I do it?

Last edited by Gocom (2012-06-29 13:43:07)

Bloke · 2012-06-29 19:34:47

Gocom wrote:

What about if we remove the inline verify() call from the form and we add it to the txpMultiEditForm()? I could add a message option to the plugin

I’ve often wondered about this. The forced verify is fine, but it does sometimes feel like “What!? Another click? Yes, yes, go ahead and do it already.”

With some functions — like delete — the extra verification is good. And with the auto-submit, I’d say incredibly important to combat mouse slippage / fat fingers. But for other options on the same multi-edit, especially ones that involve a secondary action, it feels unnecessary and gets in the way.

If the ability to verify or not could be added to the options array — with a default of ‘on’ if there is no html option specified — then it leaves the door open for per-option verification, BUT from a UX perspective it’s probably terrible (just guessing) because then some options will trigger it and some won’t.

I dunno. I’m no UX guru. But for me with my humble user hat on, I can honestly say that not having the additional verification after a secondary action would be great. (with the possible exception of the Delete User and assign-assets dance. That probably needs verification, but even then I could live without it).

In summary, I’d be all for it, but before you commit to shedloads of dev hours I’d seek comment from others, as my opinion here is lacking any sound usability background.

Textpattern CMS

Textpattern CMS support forum

#61 2012-06-29 04:05:59

Re: New sections tab, multi-edit control block

#62 2012-06-29 08:41:28

Re: New sections tab, multi-edit control block

#63 2012-06-29 10:06:41

Re: New sections tab, multi-edit control block

#64 2012-06-29 10:29:45

Re: New sections tab, multi-edit control block

#65 2012-06-29 11:00:23

Re: New sections tab, multi-edit control block

#66 2012-06-29 11:02:23

Re: New sections tab, multi-edit control block

#67 2012-06-29 12:13:40

Re: New sections tab, multi-edit control block

#68 2012-06-29 12:19:16

Re: New sections tab, multi-edit control block

#69 2012-06-29 13:05:38

Re: New sections tab, multi-edit control block

#70 2012-06-29 13:29:18

Re: New sections tab, multi-edit control block

#71 2012-06-29 13:39:13

Re: New sections tab, multi-edit control block

#72 2012-06-29 19:34:47

Re: New sections tab, multi-edit control block

Board footer