Hive 4.6 and beyond

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.

Bloke · 2016-09-12 13:47:27

etc wrote #301373:

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

Ab-so-lutely!

phiw13 · 2016-09-12 14:03:31

Bloke wrote #301366:

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

Even for long articles we (me as editor, but authors as well) are not really confortable with it. It is fine for the average commercial text that is mostly published these days. That is why Sand space theme doesn’t include it.

The suggested option (resize + remember) for the Forms and Page panel sounds good though.

etc · 2016-09-12 14:04:35

It’s easy to store UI settings locally, the problem is to clean up the storage when something (plugin…) gets uninstalled. For example, panes states of ied_plugin_composer are stored locally in 4.6 (so you don’t need to sendAsyncEvent() here anymore). But they persist in the storage even when the plugin is deleted, you’ll need to write few lines of js to remove them.

philwareham · 2016-09-12 14:22:14

Bloke wrote #301371:

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

Yep, will do. I’ll also mockup up a static HTML example this week. Exciting!

GugUser · 2016-09-12 16:16:06

Until now I had no time to install Textpattern 4.6, but in version 4.6 beta 3 still works rah_expanding.

It’s one of the plugins that should be updated and integrated in the core.

etc · 2016-09-12 17:43:08

GugUser wrote #301379:

It’s one of the plugins that should be updated and integrated in the core.

Why isn’t it ok as plugin? I respect everyone’s choice, but wouldn’t use a script that listens to all keystrokes if I had choice.

Textpattern CMS support forum

#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:

#25 2016-09-12 13:47:27

Re: Hive 4.6 and beyond

etc wrote #301373:

#26 2016-09-12 14:03:31

Re: Hive 4.6 and beyond

Bloke wrote #301366:

#27 2016-09-12 14:04:35

Re: Hive 4.6 and beyond

#28 2016-09-12 14:22:14

Re: Hive 4.6 and beyond

Bloke wrote #301371:

#29 2016-09-12 16:16:06

Re: Hive 4.6 and beyond

#30 2016-09-12 17:43:08

Re: Hive 4.6 and beyond

GugUser wrote #301379:

Board footer