Hive 4.6 and beyond

Bloke · 2016-09-12 07:44:34

phiw13 wrote #301346:

That is actually quite a difficult issue to resolve across the board.

Yep, I haven’t a clue, but I like some of your suggestions. If it’d make it easier for general styling and theme authors if we didn’t specify a rows attribute on textareas (or a cols for that matter), then I’m all for it.

one press of the tab key should focus the Save button

Ah yes, of course. Knew there was a reason we adhered to the tab chain :-) Thanks for the tip. Tab->Enter should be fine for rapid saves here.

phiw13 · 2016-09-12 07:59:54

Bloke wrote #301350:

Yep, I haven’t a clue, but I like some of your suggestions. If it’d make it easier for general styling and theme authors if we didn’t specify a rows attribute on textareas (or a cols for that matter), then I’m all for it.

Hmm, you should specify the rows attribute anyway (satisfies eventual accessibility requirements, IIRC), but at least that can be solved easily. We could specify a “low” row count though, say something like rows=20 – that would compute to ~350px height. The let the theme set both min- and max-height.

All of this assumes I understood correctly what Bert actually wants. Perhaps he wants something else: no scrollbar at all on the window, or, IOW, the whole page fits in his viewport, the textarea fills the space. For that I’m not sur I can think of a reasonable solution.

philwareham · 2016-09-12 08:31:33

I can use autosize JS script to make the textarea as long as the code within it (as we already do for write page), kind of like GitHub does in their browser-based editor (note the save button is below code on GitHub, lol). That doesn’t save you any scrolling time (in fact it’s generally more scrolling) and I didn’t particularly like it in testing, but it eliminates the second scroll bar which you seem to find annoying.

The other option is as Philippe noted, putting a max-height on textareas. That isn’t failsafe unless you also have min-height for people on smaller screens such as tablets and mini laptops. Hence why I originally chose somewhere between option 1 and 2 above (because, you know, I actually think about and try these things in code instead of just griping about it in a forum or on textpattern.com blog post comments).

Textareas should have cols and rows so I’m not taking those off – they are overruled by any stated CSS height anyway so makes no difference.

philwareham · 2016-09-12 08:35:16

On a more positive note, I’m starting to explore ways of customising the panes for users to tailor their workflow in 4.7. Initially just hiding panes and table columns that are not desired (as well as giving the option of moving the multi-edit from it’s default position below lists to above it, if you so wish – Dale will be happy with that, I think!).

hcgtv · 2016-09-12 10:32:46

philwareham wrote #301352:

Hence why I originally chose somewhere between option 1 and 2 above (because, you know, I actually think about and try these things in code instead of just griping about it in a forum or on textpattern.com blog post comments).

Forms tend to be small snippets of code, where Pages tend to be longer. It doesn’t make a lot of sense to put such big text areas on the Forms panel, I can see it on the Pages panel.

Would you like me to stay away, I can handle making changes to my own administration screens, and forget about the OOBE?

Bloke · 2016-09-12 11:12:13

hcgtv wrote #301356:

Forms tend to be small snippets of code, where Pages tend to be longer.

Sure, not all the time though. Mine are routinely the opposite. My Pages are often about 5-20 lines of code that offload the lion’s share of processing to Forms with loads of conditionals in them:

<txp:output_form form="head" />
<body id="<txp:if_section name="">front<txp:else /><txp:section /></txp:if_section>">>
   <txp:output_form form="navigation" />
   <txp:output_form form="front_article" />
   <txp:output_form form="complementary" />
   <txp:output_form form="footer" />
</body>
</html>

Thus, dictating a textarea’s usage isn’t universally a good idea; although we, umm, do it on the Write panel where Excerpt is smaller than Body to bend towards convention.

Perhaps allowing textareas to be set to suit an individual workflow might be better. If you were able to resize the Forms textarea, for example, and it remembered that setting automatically, that’d satisfy everyone, right? Worst case would be that first use would be “too big” or “too small” for your ideal, you’d tweak it, then forget it. Desktop, mobile, wouldn’t matter. Set it for your device and it’d remember it in localstorage.

Any downsides? If not, then I decree that it should be so (if it’s at all possible, I don’t know). And if so, that’s why we invite — and try to employ — feedback from everyone, so a suitable system can be constructed for the good of more people.

Keep ‘em comin’.

EDIT: Looks like it is indeed possible in more than one way.

hcgtv · 2016-09-12 11:46:53

Bloke wrote #301360:

Sure, not all the time though. Mine are routinely the opposite. My Pages are often about 5-20 lines of code that offload the lion’s share of processing to Forms with loads of conditionals in them:

About 7 or 8 years ago, I did the same. My Pages were just skeletons, and I hung out in forms, exclusively. When I decided to start creating Themes, back in the Stuart Butcher days, I had to change my ways, or else I’d freak out the new users.

Perhaps allowing textareas to be set to suit an individual workflow might be better.

That would help.

The text areas are just one aspect, menu placement (forms were on the right since the beginning of time, now they’re on the left), quick access to the Save button. Just in general, why all the white space on top when screen real estate is at a premium, especially on the Forms panel.

philwareham · 2016-09-12 12:29:34

Bloke wrote #301360:

EDIT: Looks like it is indeed possible in more than one way.

I’d be happy to see this in core (if you decide not have auto expanding textareas as mentioned in previous message). I’d still put a min-height rule in place (of about 3 rows minimum height) as a safeguard.

Bloke · 2016-09-12 12:36:51

philwareham wrote #301365:

I’d be happy to see this in core (if you decide not have auto expanding textareas as mentioned in previous message). I’d still put a min-height rule in place (of about 3 rows minimum height) as a safeguard.

Min-height: absolutely!

Given that we’re looking at moving towards a more “drag, drop ‘n remember” kind of zero-config interface, and Oleg has already done some great work on localStorage for subpanel twisty settings, remembering other things like textarea sizes is a logical extension of the idea. I say let’s explore it.

Autogrowing textareas have their place, but scare me when we think about the Plugins panel and smd_tags, for example: ~4200 lines of code :-)

philwareham · 2016-09-12 12:50:55

Yep, agreed. As I said, I tried auto expanding code fields and didn’t like it.

We should also hook up the list options soon too (where you can specify exactly which columns in a table are visible – replacing the clunky ‘show more options’ checkbox we currently have). Local storage or database could be used to save those settings.

I’ll also see about incorporating Philippe’s sticky multi-edit field, I like that idea.

Bloke · 2016-09-12 13:14:23

philwareham wrote #301368:

We should also hook up the list options

Ooh yes. That goes hand-in-hand with this idea. It might also be able to borrow code from the search dropdown thingy — similar jQuery tech to show the available columns and allow you to (de)select them, subject to a minimum of 1(?) column or a ‘core’(?) column or two, I suppose. Presumably at least one column that allows you to jump to the ‘edit’ step has to remain!

We can chat about the specifics later, e.g. whether it’s tied immediately to the checkboxes and columns via jQuery or if you have to ‘submit’ first, and such like.

If there’s no Issue for it yet, wanna add one with a little bit of detail how it should work?

etc · 2016-09-12 13:44:22

philwareham wrote #301368:

We should also hook up the list options soon too (where you can specify exactly which columns in a table are visible – replacing the clunky ‘show more options’ checkbox we currently have). Local storage or database could be used to save those settings.

IMO, localStorage fits better for this kind of things, since you can have different settings on desktop and mobile.

Textpattern CMS

Textpattern CMS support forum

#13 2016-09-12 07:44:34

Re: Hive 4.6 and beyond

phiw13 wrote #301346:

#14 2016-09-12 07:59:54

Re: Hive 4.6 and beyond

Bloke wrote #301350:

#15 2016-09-12 08:31:33

Re: Hive 4.6 and beyond

#16 2016-09-12 08:35:16

Re: Hive 4.6 and beyond

#17 2016-09-12 10:32:46

Re: Hive 4.6 and beyond

philwareham wrote #301352:

#18 2016-09-12 11:12:13

Re: Hive 4.6 and beyond

hcgtv wrote #301356:

#19 2016-09-12 11:46:53

Re: Hive 4.6 and beyond

Bloke wrote #301360:

#20 2016-09-12 12:29:34

Re: Hive 4.6 and beyond

Bloke wrote #301360:

#21 2016-09-12 12:36:51

Re: Hive 4.6 and beyond

philwareham wrote #301365:

#22 2016-09-12 12:50:55

Re: Hive 4.6 and beyond

#23 2016-09-12 13:14:23

Re: Hive 4.6 and beyond

philwareham wrote #301368:

#24 2016-09-12 13:44:22

Re: Hive 4.6 and beyond

philwareham wrote #301368:

Board footer