Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
New sections tab, multi-edit control block
The multi-edit control block (now) has a usability problem. When you select an action through the select widget, the little popup (#js > span) appears, but is now completely disconnected from the select widget (visually). It is now tugged to the left side of the block, relatively far way from where the action originated.
Would it make sense to have that widget inline inside the multi-edit control block, right after the select widget in the code and before the ‘go’ button ? (one could always style it to appear under the select widget, with a bit of absolute positioning). The added benefit is that it would be kept in the tabbing order.
To be clear, from an UX & accessibility perspective the issue was aways there. Given the new formatting, it is now a visual problem as well.
Thoughts ?
(aside – when you select something and that additional popup thingie is added, it includes a <br> right after the ‘go’ button; that is not needed at all.)
(aside #2, it put this in a separate thread, the main thread on the new sections pane is getting pretty cluttered with various meta discussions)
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: New sections tab, multi-edit control block
Speaking of the multi-edit, if I may say, the thing would probably need some fresh love. I.e. the whole static Go button and the select none, all and range buttons.
The selection buttons (none, range, all) could be replaced with something better. Keyboard navigation would be amazing for example. None and all could serve well as a checkbox placed to the table head row (would be ideal location imo) and range selects can be replaced with shift click (which isn’t hard to implement thanks to jQuery).
The go button gets pretty confusing to users. On these forums we have some reports where users have no idea how to use the multi-edit thing, which is unfortunate. I somehow got the feeling that not so many even use the multi-edit thing at all.
Usability issues are mostly likely due to the button, which doesn’t make clear that some of the actions take multiple steps. Heck, I remember when I started using TXP and had no idea how that thing worked. To make the thing somewhat clear, I would suggest showing that button on the second step. If no second step is needed, the action (e.g. delete) can be done on change.
If you devs (Robert, Stef) have any interest in that, I can look into writing new JS for the multi-edit functionality in way of patches (keyboard navigation etc). I actually have a script on GitHub that changes the current markup/functionality to work like that (it adds shift-click, double click, and shows Go button only when needed).
Last edited by Gocom (2012-06-23 05:28:30)
Offline
Re: New sections tab, multi-edit control block
Gocom wrote:
The selection buttons (none, range, all) could be replaced with something better. Keyboard navigation would be amazing for example. None and all could serve well as a checkbox placed to the table head row (would be ideal location imo) and range selects can be replaced with shift click (which isn’t hard to implement thanks to jQuery).
Isn’t that already partly implemented on the sections tab ? And unless I misunderstood what he said in the other thread, Bloke plans to remove the ‘all’ and ‘none’ buttons soon – and implemented that across all panes.
The go button gets pretty confusing to users. On these forums we have some reports where users have no idea how to use the multi-edit thing, which is unfortunate. That’s most likely due to the button, which doesn’t make clear that some of the actions take multiple steps. To make the thing somewhat clear, I would suggest showing that button on the second step. If no second step is needed, the action (e.g. delete) can be done on change.
Yeah, in combination with my suggestion upthread, that might help some people.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: New sections tab, multi-edit control block
Gocom wrote:
If you devs (Robert, Stef) have any interest in that, I can look into writing new JS for the multi-edit functionality in way of patches (keyboard navigation etc).
GO!
Offline
Offline
Re: New sections tab, multi-edit control block
Gocom wrote:
Better to wait what Bloke has in his sleeve.
No, no, no, as Robert says: GO!
I did intend to remove All/None, and admit that Range is confusing. Toggle was just something I was trying out to save a few clicks when you need to select “all things except these 3”, but if the whole system could be redesigned then please do it.
One thing that’s always bugged me, btw, is that generating the multi-edit dropdown options in txplib_head are a mess. I would prefer a nicer system of adding the options which is extensible by plugins via callbacks. If that’s part of your vision then please do what you can. I’ll roll it out across the core once the dust has settled.
Last edited by Bloke (2012-06-23 06:57:17)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: New sections tab, multi-edit control block
During last night and this morning I sketched up some code for it. Needs some major cleaning up still and gotta find some sort of way to make its method members accessible from outside while keeping multiple instance support intact. Probably means removing some of the caching too.
What it does is:
- Adds shift click support for selecting ranges. Also has toggle for selecting all/none via a checkbox.
- Extends checkbox selecting to the row itself. Clicking any empty space on the row selects the checkbox (excluding any interactive control, i.e. link, input and takes bubbling into account).
- Tracks checkbox checks via change event, and adds highlight class to the checked row.
- Works with rows added via Ajax or on later events (derp caching).
- Supports multiple instances (i.e. doesn’t use IDs, does all targeting within single container).
- The current poweredit() function that hosts the multi-edit actions is implemented as objects attached directly to the
<options>. This means that set HTML element(s) from the page can be attacked to a option (see below).
Bloke wrote:
One thing that’s always bugged me, btw, is that generating the multi-edit dropdown options in txplib_head are a mess. I would prefer a nicer system of adding the options which is extensible by plugins via callbacks. If that’s part of your vision then please do what you can. I’ll roll it out across the core once the dust has settled.
For example on the new Section’s panel the multi-edit markup with the new functionality looks like this;
<p class="multi-edit">
<select name="edit_method">
<option value="" selected="selected">With selected...</option>
<option value="changepage">Uses page</option>
<option value="changecss">Uses style</option>
<option value="changeonfrontpage">On front page</option>
<option value="changesyndicate">Syndicate</option>
<option value="changesearchable">Include in site search</option>
<option value="delete">Delete</option>
</select>
<div class="multi-option" id="multi-option-changepage">
<select name="page">
<option value=""></option>
<option value="default">default</option>
<option value="error_404">error_404</option>
</select>
</div>
<div class="multi-option" id="multi-option-changecss">
<select name="css">
<option value=""></option>
<option value="bootstrap">bootstrap</option>
<option value="default">default</option>
<option value="formalize">formalize</option>
<option value="styles.min">styles.min</option>
</select>
</div>
<div class="multi-option" id="multi-option-changeonfrontpage">
<input type="radio" id="on_front_page_0" name="on_front_page" value="0" class="radio" />
<label for="on_front_page_0">No</label>
<input type="radio" id="on_front_page_1" name="on_front_page" value="1" class="radio active" checked="checked" />
<label for="on_front_page_1">Yes</label>
</div>
<div class="multi-option" id="multi-option-changesyndicate">
<input type="radio" id="syndicate_0" name="syndicate" value="0" class="radio" />
<label for="syndicate_0">No</label>
<input type="radio" id="syndicate_1" name="syndicate" value="1" class="radio active" checked="checked" />
<label for="syndicate_1">Yes</label>
</div>
<div class="multi-option" id="multi-option-changesearchable">
<input type="radio" id="searchable_0" name="searchable" value="0" class="radio" />
<label for="searchable_0">No</label>
<input type="radio" id="searchable_1" name="searchable" value="1" class="radio active" checked="checked" />
<label for="searchable_1">Yes</label>
</div>
<input type="submit" value="Go" />
</p>Obviously as it uses stored objects, it can work directly via JavaScript (or PHP wrapper of sorts) too. E.g. along the lines of:
$('form').txpMultiEditForm('addOption', {
'label' : gTxt('delete'), 'value' : 'delete', 'html' : null
});Well, or could once I get those methods to work outside their given context while keeping multiple instance support. Makes my brain hurt. txpMultiEditForm is rather long name, eh.
Offline
Re: New sections tab, multi-edit control block
Gocom
In the words of Neo: Woah!
Terrific work. Can’t wait to get my paws on it, thanks man.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: New sections tab, multi-edit control block
Great stuff. I’d been planning to find out what modernizeTextpattern was exactly, and it sounds exciting. I’ll stay out of this for the moment unless needed – I’m working on the installation pages section so that won’t mess with any of your plans.
Offline
Re: New sections tab, multi-edit control block
@gocom
One thing I’ll mention, which is probably relevant (and you may already be aware):
The multi-edit column being the first table column (like it currently is on new sections page) will be done on all the other list pages too. Don’t think that affects your code at all but just in case it wasn’t clear and you thought the sections page was an anomaly. We also want to get rid of the tfoot section entirely if possible.
Other than that, if there’s any other parts of the UI you think could benefit from some jQuery/JavaScript love then please share them too. All ideas considered.
Last edited by philwareham (2012-06-25 23:04:47)
Offline
Re: New sections tab, multi-edit control block
philwareham wrote:
The multi-edit column being the first table column (like it currently is on new sections page) will be done on all the other list pages too. Don’t think that affects your code at all but just in case it wasn’t clear and you thought the sections page was an anomaly. We also want to get rid of the tfoot section entirely if possible.
It could, but it doesn’t since I’ve loosen the rules a bit from what they were in the ModernizeTextpattern scripts. The concept of both is similar.
Because the multi-edit code makes empty areas on the row clickable, if a (third-party) theme wants to hide the checkboxes altogether they can too. Plus it helps with table responsiveness issues, which is probably the reason why the checkboxes have been moved to the first column. If user scrolls to right side and doesn’t see the checkbox, it doesn’t really matter. Any empty space is enough.
Offline
Re: New sections tab, multi-edit control block
Is a class placed on the table row if it is in selected state? If so let me know the class name and I’ll make sure the core themes have support for it. And yes, the multi-edit checkboxes were moved for usability reasons.
Last edited by philwareham (2012-06-26 13:00:33)
Offline