Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Categories: Visual 'description limit' indication
Destry wrote #336333:
there’s this ‘description’ field, all neat and tidy for purpose. Why not use it to output a description.
It’s currently limited to 255 characters. If we beefed that up a bit, where do you see the sweet spot, size vs storage?
I mean, it’s varchar so it won’t take up any more than it needs to fit the content in, but still. No point us allocating tens of KB to it.
1024 characters?
2048 characters?
More?
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
Online
Re: Categories: Visual 'description limit' indication
Mastodon posts limit me at 500 chars by default and that works most of the time. Sometimes I need just a bit more wiggle room to make a clear statement about some heady thing…
I think 750 chars would be all I’d ever need, but if it’s the same diff at 1024, I wouldn’t argue it
Offline
Re: Categories: Visual 'description limit' indication
Destry wrote #336434:
I think 750 chars would be all I’d ever need, but if it’s the same diff at 1024, I wouldn’t argue it
Done. I went with one less than the power of 2, as is traditional for such things. 1023 bytes are yours.
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
Online
Re: Categories: Visual 'description limit' indication
The length of those description fields are a little all over the place: some have a limit (maxlength) of 1023 (categories, sections), articles is set to 255 (reason iirc: google search only reads that much of the <meta description /> field). Files, Images and Links have no limits set.
Then, Themes has a limit set to 10240. Typo ? I could eventually see a reason, allowing including a full description or usage instructions / help file.
Oddly, the plugins panel: the Description field is a single line <input /> with a size="96" attribute.
–^–
BTW, on the Edit themes panel, the layout for the description field is different / inconsistent with other panels where it spans the width of the panel. The container <div /> is missing a class, it should be <div class="txp-form-field txp-form-field-textarea edit-skin-description> .
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Categories: Visual 'description limit' indication
Here’s a SQL hack to get the maximum length of a column:
SELECT CHARACTER_MAXIMUM_LENGTH AS `max`
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'txp_category' AND COLUMN_NAME = 'description'
LIMIT 1;Maybe that information could be combined with <meter min="0" max="" value=""></meter> tag. 👍
Offline
Re: Categories: Visual 'description limit' indication
That’s appealing, especially for the cases when admins change default txp settings. A db query per field looks prohibitive, but we could probably retrieve all input fields max length in one go.
I’m more sceptical re <meter />, it could uselessly add some clutter. Currently, a tooltip appears when one reaches 75% of input’s maxlength, but UX gurus advice is welcome.
Offline
Offline
Re: Categories: Visual 'description limit' indication
Interesting. I don’t have an opinion either way between meter and a tooltip. But how does it fare for people who rely on assistive tech? How do they know how many characters are left?
Can we/should we hook into aria live for either the tooltip or the meter? And if so, how? See GitHub issue 1842 for more.
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
Online
Re: Categories: Visual 'description limit' indication
The ui-tooltip that was used first is, I think, quite a bit better. For the visual user it is a discrete indicator that does not get in the way and is not much distracting; there is clear indication how many characters are already set and what the upper limit is. On the accessibility front, I am a little ambivalent. It does broadcast the current value. It does set the aria-live attribute, possibly a little too verbose (and noisy) as the default is aria-live=assertive.( I think one can change that with options { 'aria-live', 'polite'} [?] check the relevant JQUI API)
The current <meter /> element is not great at all. It does give some visual indication that you are reaching the “danger” zone (close to the max allowed characters) but does not say how many characters are left. It is worse on a small(ler) textarea or input such as the meta-data fields on the Write panel – as the “steps” are visually more narrow. For AT users it is not really good. At default it seems to say “step 4 of 6” type of message. Screen readers mostly seem to ignore the widget when it is styled – only announcing there is a meter element without much detail about the status.
An option: instead of <meter />, perhaps <progress /> can be investigated, it does not tell either how many characters are already used or are still available. But it “tells” better the story: progressively filling the field and to AT users tells a “80%” type message.
A second option to investigate: the JQUI progressbar widget which does broadcast the status (quietly I think). Con: dependency on JQUI.
Winner so far is the JQUI ui-tooltip widget:
- Pro: verbose enough, discrete, fairly good AT support
- Con: JQUI dependency
PS
- improvement to that ui-tooltip widget: specify classes on it
txp-character-meter warning. - test with a real screen reader user regarding the
aria-livestatus (see above).
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Offline
Re: Categories: Visual 'description limit' indication
etc wrote #336444:
That was my impression too, but I’m not AT user and do not know how to test it. Thanks for any hints.
I am no AT user either, and what more I have often trouble hearing what a screen reader tells me (VoiceOver). Anyway, only hint I can give you – for JQUI widgets, look at the elements tab in the web developper tools, make sure the body is open and look at the bottom, right before the </body>tag. In the case of the ui-tooltip, you are in luck as it is a little verbose and it adds a <div role=log aria-live=assertive> for each instance it is called. For standard HTML elements there is not much you can see – in the case of the <meter /> you just added, you can see the value attribute changing (which is the base of what the screenreader eventually hears, if anything is broadcasted, dubious as note before) In Firefox, you can right-click the element and select Inspect Accessibility Properties which will tell you something. All that does not tell you how a screenreader experience the thing.
My ears being a little more collaborative this AM I tried to use VoiceOver, and I think it is a little less noisy that I feared, only saying something when I pause typing (disclaimer: 1 – hearing is not good and 2 – only very amateur & beginner VO user). That could match what I see in the dev. tools where the log div is only updated when pausing.
Textpattern really should be checked by an experienced AT user. 4.9-dev is, I think, in a better state than 4.8.8.
PS -the Twitter character counter is a <progress /> meter (custom made, ofcourse ‘cuz reasons and react.js…), as far as i could track in the mess of nested divs, it sets aria-live=polite on it.
PS 2 if possible, please revert to that ui-tooltip. ty.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Categories: Visual 'description limit' indication
BTW, Sara Soueidan has two articles just out on the subject of Live regions: part1 and part 2. Recommended.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline