Skip to main content
Cwgordon7 Notes on Drupal, testing, and open source

Archive note

Rearranging the node form without breaking it

A practical look at tabbed editing screens, button placement, and the small layout choices that decide whether a form feels calm or chaotic.

3 min readCharlie GordonField notebook

A content form is a conversation with a deadline. The person on the other side wants to publish something and move on. Every field, tab, and button either shortens that conversation or adds a detour.

Group fields by the moment they are needed

The easiest way to improve a long editing screen is to stop organising it by which module owns each field. Ask instead when the author needs it. Title and body belong together because they are written together. Publishing state belongs at the point of decision. Reference data can wait until the text exists.

That single question exposes most of the clutter. A field that is technically required but rarely understood can move into a secondary area with a short explanation. A field that is used on every entry should never be hidden behind a click.

Tabs are a promise about scope

Tabs work when each one contains a complete thought. They fail when they split a single decision across two panels. If an author has to visit three tabs to publish a page, the tabs are not organising the work. They are taxing it.

Before adding a tab, try writing its label as a sentence the author would say out loud. "Write the page" is a tab. "Advanced settings that only two people use" is not a tab. It is a fold, a details element, or a separate screen.

Working rule

If a field cannot be explained in one line, the problem is the label or the field. Moving it to another tab hides the problem rather than solving it.

Put the save action where the work ends

Submit buttons collect in odd places because they are easy to move and hard to test. A useful default is to place the primary action at the end of the reading order, then repeat it in a sticky bar only when the form is long enough to scroll. Repeating an action is fine. Making people hunt for it is not.

Secondary actions should look secondary. Delete, preview, and revision controls compete with save when they share the same weight. Give the primary action the strongest contrast and leave the rest quiet.

Test the form with a real task

Usability testing does not require a laboratory. Give someone a page to publish and watch where their cursor goes. Note the first pause, the first scroll back, and the first question. Those three moments usually point to the same cluster of fields.

Then change one thing. A moved group, a shorter label, or a clearer required marker is enough for a second pass. Small, reversible changes are easier to defend than a redesign that arrives all at once.

A checklist before you drag anything

  • Can a new author find the title and body without instruction?
  • Does every tab contain a complete decision?
  • Is the primary action visible at the end of the work?
  • Are required fields marked before the error, not after it?
  • Does the form still work with a keyboard and a screen reader, following the W3C accessibility guidance?

None of these questions require a new module. They require someone to sit with the form long enough to notice what it is asking. That is the unglamorous core of usability work, and it is usually enough.