Modifying txp-save-zone / pane-header?

jakob · 2025-03-08 09:37:00

I get the reasoning behind the reshuffle of items in txp-save-zone with regard to which buttons need to remain visible when scrolling and the space requirements for the many buttons, but I’m also not super-happy about the splitting off of related functionality (save and duplicate) into separate blocks, as they are now in the txp-actions area in pane-header. We now also have many different “preview” buttons, which, while useful in some ways, kind of add confusion for end users.

So, before upgrading some users, I’d like to dumb down some of the options in my own slightly modified admin theme. Is there a way of rewriting, rearranging those areas in my own theme? Possible options that spring to mind in order of preference:

Use some kind of pluggable_ui function to change how txp renders those areas. I don’t see any suitable hooks in the core. Could those be added?
Rewrite parts of the UI after rendering with js
Modify the core (hmmm)

Space issues can be resolved by making sub-actions just icons with a tooltip (the trade-off being that that the label is not immediately visible). I could cope without having a dedicated “New article” button, as it’s easy to choose Content › Write.

Bloke · 2025-03-08 09:47:53

If it’s not optimal and you think it could be presented better/more logically, by all means submit a PR for review, or chuck some ideas here if it’s easier.

That said, if we don’t have a pluggable_ui hook for the save zone and the txp-actions area, we should.

Bloke · 2025-03-08 09:50:21

I also admit preview/view is not the best terminology. There are a lot of them splattered throughut the page and it’s not obvious what they do. How do we get across the difference more concisely and cleanly so people know what each does? Is it just a case of proximity to various other controls, or do they need relabelling or different icons or… something?

phiw13 · 2025-03-08 12:14:21

Bloke wrote #339209:

I also admit preview/view is not the best terminology. There are a lot of them splattered throughut the page and it’s not obvious what they do. How do we get across the difference more concisely and cleanly so people know what each does? Is it just a case of proximity to various other controls, or do they need relabelling or different icons or… something?

The two “Preview” labels … I think the one triggers the iframe view is most unclear. What is the difference with the “View” link?

In my ideal setup, the save-zone on the Write panel would only have a “View (article)” link and a “Duplicate (article)” link. When I proposed the reshuffling (moving view/preview (iframe) under the save button), that was based on the thinking that that was the more important action – and that pair was already tied together.

phiw13 · 2025-03-08 12:21:25

And btw, the current split happened because I sort-of-complained that the save zone block had become quite overloaded. I still think that having 4 button/links is mostly problematic, and prevents having those including in the pinned save zone on small screen devices.

Bloke · 2025-03-08 13:37:50

We’re absolutely open to suggestions and/or mockups on how best to lay this out for the cleanest and most obvious workflow. We have an opportunity between beta.2 and final release to get this working optimally.

Bloke · 2025-03-08 13:49:05

Thing is, we have small Preview links adjacent to every box (textarea, custom fields, etc) to see just that content in a popup. So we may be able to improve things by renaming the page-level “preview” as something else?

The tricky thing is, View renders only stuff that has been saved (i.e. in the database). The preview (or whatever we end up calling it) renders stuff that is currently on the page and may or may not have been saved yet. So it is a preview of sorts before it’s been committed. Not sure what else to call it. Ideas welcome.

giz · 2025-03-08 16:43:54

Conceptually, Save, Preview, View, New article & Duplicate belong together. Maybe Article preview could live in a textarea’s Preview dialog as another tab…

Is it a big deal if .txp-save-zone gets a little taller so its not cluttered? Its sticky function could be disabled in height-restricted viewports.

Alternatively, maybe the save zone could include a toggle called Article actions?

Better icons would help in discerning the difference in Preview & View – Preview opens in a dialog, View opens in a new window.

towndock · 2025-03-08 16:45:07

Having “View” come from the database, and “Preview” (in effect pre… view) come from just the browser, actually makes sense. It makes sense for the whole page to be previewed. I like it.

We all have different workflows & sites, but to me all the additional Previews (body, excerpt, custom fields) lead to confusion, with little benefit in return.

jakob · 2025-03-08 18:19:23

Oh, I opened a can of worms here. But it seems we all have opinions and particular workflows. Hence also my initial question being about ways of adapting things for my own uses.

phiw13 wrote #339212:

… the save zone block had become quite overloaded. I still think that having 4 button/links is mostly problematic, and prevents having those including in the pinned save zone on small screen devices.

Yes, I agree on the reasoning. It was getting very full, and in languages with long words like German, where “Publish” becomes “Veröffentlichen”, even more so.

giz wrote #339217:

Is it a big deal if .txp-save-zone gets a little taller so its not cluttered? Its sticky function could be disabled in height-restricted viewports.

I’m not so keen on this (or the toggle for that matter). I’ve always found the sticky box in the corner a bit clunky as it is, and, as you say, the problem rears its head again when trying to fit them all in at the bottom on mobile viewports. Do you leave some options out? Or make a double-decker footer, which really eats away at screen real estate, or make a twister to reveal more options…

Bloke wrote #339209:

I also admit preview/view is not the best terminology.

giz wrote #339217:

Better icons would help in discerning the difference in Preview & View – Preview opens in a dialog, View opens in a new window.

I agree. My instinctive response would be to differentiate between those two “notions” and their icons more strongly, e.g. “preview” (in the modal, i.e. on this page) and “visit the page” (on the front end, i.e. on another page)… so maybe make preview the “eye” icon and an “up-right-arrow” for visit the page: completely different icons for “look here” and “go there”.

I did think about variants of “eye” and “eye-in-corner-of-modal” / “eye-over-new-page”, or “eye” and “eye-in-frame-corners” as icon possibilities, but while possibly more accurate, I think it would still have people guessing at what the difference is.

Bloke wrote #339213:

We’re absolutely open to suggestions and/or mockups on how best to lay this out for the cleanest and most obvious workflow.

To be honest, I’m not sure about the best approach. There are good arguments for all the combinations of what should belong together or what needs to be visible on scroll. But my general feeling is there’s now a lot going on with buttons and options at the top of the write panel, before you get to the “just write” textareas that are so distinctive of textpattern.

One option might be to make the entire top row (including the title) sticky, so you have the page title at the left and then buttons over at the right, giving you more space to spread things out (on desktop views at least). Currently the markup doesn’t make that easy. It also feels a bit weird having a text input in the sticky top row.

Another option is to make the sidebar a bit wider to relax space constraints. It’s not really resolving the problem, just making it less acute.

What I’ve experimented with so far for myself was to bring all the buttons into one row, and make the secondary functions in txp-save-zone just an icon-button with a simple css-tooltip on rollover. The extra functions then fit nicely (especially with a wider sidebar). On mobile view, everything fits more easily too, but as there’s no rollover on mobile, you get no tooltip. That’s suboptimal, but hopefully users will be familiar with the button icon from prior desktop use.

While I find this option generally tidier, you can already see that I now have three different types of buttons: icon-with-text-link, button-with-text, button-with-icon, which isn’t really great UI design.

So, coming full circle to my original question: I (speaking for me personally) would like to change the grouping, so that the txp-save-zone would have “Save/Publish” as a text button and then “Duplicate”, “Preview” and “View” as icon buttons. I’d then drop “New article” as the two clicks necessary to get to Content › Write is, in my opinion, tolerable. The left-hand block would then disappear entirely, and the UI is clearer. Hence my initial question about the best way of rewriting those blocks with my admin theme.

Bloke · 2025-03-08 20:14:46

Killing off New Article works for me. If you’re editing an article, the chances of needing to start afresh from that panel is way, way down the list compared with duplicating it and checking what it looks like.

Conceptually, is part of the problem that the save zone is sticky, or just that we need better iconography? Or a better place to stick it / lay it out on various devices?

Last edited by Bloke (2025-03-08 20:16:01)

giz · 2025-03-08 21:01:02

I agree with Jakob & Bloke – New article is redundant.

By ‘toggle’ I mean’t ‘twister’! Theme css can control visibility of the twister-icon and buttons if conditions allow (wide screen, wider side-panel). If we save the twister state in local storage like the others, we’d have a flexible solution.

Textpattern CMS

Textpattern CMS support forum

#1 2025-03-08 09:37:00