A Study of Textpattern's Admin-side Write Panel

5 February 09

The admin-side of Textpattern has changed little in the near five years Textpattern has existed. Outside of a few alterations (organizing preferences, evolving tag builder tools, fixing orthography, and extending the Article and Image tables are a few I recall) the back-office of Textpattern is business as usual. That’s not because the admin-side does not get attention from the community, on the contrary, but the focus on presentation, and the extent of that focus, might be why we have not seen change to the core yet. I offer my two cents on the topic and propose to developers a few ergonomic improvements, if not some interesting design modifications too.

If you’ve been using Textpattern as long as I have, and monitoring the community forum on a regular basis, then you may have witnessed many discussions over time about redesigning Textpattern’s admin-side. For example:

Such discussions usually attract people wanting to get in their design chops and see something new put in the core. There was even a community Admin-side Redevelopment Working Group at one time, which fizzled like many good-intended working groups do. Despite all the efforts, not much has changed. There’s likely two reasons for this.

First, the admin-side of Textpattern, though a little plain for some tastes, is largely intuitive and usable as it is. Furthermore, a lot of veteran users like the down-played aesthetics, which don’t get in the way and seem fitting to Textpattern’s essence, which is a no-nonsense, lean, mean content publishing machine (if I do say so myself). There’s certainly some room to improve, but it’s usually the admin-side’s aesthetics, not usability, that motivates each redesign campaign. Indeed, there have been some very attractive mockups contributed (and sadly some lost to dead web links), but in the end it is usability, not just design, that really counts.

Second, Textpattern’s admin-side has a rather rigid structure. Most people will notice it’s still heavily table-based (as of version 4.0.8) and loaded with inline styling. Often not realized, however, is how integrated the admin-side markup is with the PHP engine. It’s not impossible — nor likely even difficult — to change, but it would take time to re-factor the admin-side to be more semantic and standards-compliant. Developers usually spend their available time on functionality, not presentation, which, again, is what really counts.

None of this means to suggest Textpattern developers are not interested in improving the admin-side, certainly they are, but presumably so long as the mods improve usability (not just appease one’s aesthetic tastes) and don’t take up the time of an entire version release. Good advice to admin-side thinkers would be to forget about aesthetic overhauls and focus on localized enhancements to panel interfaces as they already exist. Textpattern developers will likely be able to insert small changes over time as opposed to one big redo. Helping them figure out what those change priorities are is the key. Eventually we can work toward a Textpattern core that makes it possible to re-skin the admin-side without modifying system files; that should be greatly appreciated by designers and developers alike who use Textpattern for client projects.

In the meantime, I propose a few changes of the kind I’m talking about for the admin-side’s Write panel (some carrying over to other panels as well), which should improve this panels usability yet require modest investment of developer time to implement. These changes were inspired by the fact authors of Textpattern documentation need an easy way to refer to — and describe — interface elements. Not all elements on every panel are developed in such a way as to be suited to this document-interface relationship.

For the overall effect, you can compare a screenshot of the existing Write panel (version 4.0.8) with a mockup of my proposed changes . Each change, and motivation for it, is described in the rest of this article.

Layout with Grid in Mind

For the most part the layout is the same, but one thing that often troubles the eye of designer types is the rather loose way elements in the admin-side panels sprawl about. It’s clear it was not done with a grid in mind (only tables), so the first thing I wanted to do was put some sense of alignment to things. This is an ergonomic issue as much as one of aesthetics.

Textpattern’s trademark yellow bar still spans the entire width of the page, but the content inside of it and everything else underneath it fits within an invisible container. For the bulk of the panel, this is business as usual, but I’ve tried to bring more definition to it. There are two places where alignment changes are immediately obvious (others will be pointed out in context later).

The first is with the positioning of the “Textpattern” logo in the left of the yellow bar (note the system version number is dynamically added at right of logo) and the login/logout dialog on the opposite side (moved there from the bottom of the panel). Both elements bump up against the invisible container edges, respectively.

The other change is with the tab navigation; which is no longer just there somewhere in the middle, but left-aligned with the invisible container edge. Further, tab aesthetics no longer span the width of the view, but are now contained and add to the overall sense of alignment.

In addition to putting things right (no pun intended), I also added a bit more space between the yellow bar, the tab navigation and the dynamic publish dialog, which I propose to have positioned underneath the tab menus. (More on the dynamic publish dialog in the Middle Column section later.)

Global Tab Navigation Mods

A lot of people want to change the tabs in some way; either by creating a new presentation or replacing them altogether for some thing more menu-like. From a usability standpoint, the tab navigation is hard to beat, but the tabs do need some aesthetic attention.

If the Concept is Folders, Make Them Folders

Besides improving the tab menu’s alignment, it might be nice to reverse the use of color so the design better fits the mental model of manila folders in a file cabinet drawer, which is surely the original idea behind the tabbed menu design (Figure 1). The active tabs should be gold, while the inactive tabs something else (white works just fine). To help establish the effect of active folders, gold gradients are used under the tab rows to suggest the body of the folders themselves; a darker shade for the primary tabs folder, and a lighter gradient for the secondaries. The gradient for the secondary tabs extends into the top of the panel just a bit to lend to the folder effect and make things a bit less stark.

Current and proposed design of Write panel tab menus.

Figure 1: Current (top) and proposed (bottom) designs of admin-side tab menus.

Out with the Shadows

With the tabbed folders concept improved upon, there’s no need for the dirty drop-shadows (or would you call those “top shadows?”), which always looked pretty sloppy and served no purpose anyway. Instead, a darker shade of gray-gold is added on the borders of the active tabs and the top of the folder edges that span the width of the container.

Label-to-Tab Proportioning (Sliding Doors)

Finally, I would propose using the sliding doors technique (see Part 1 and Part II) to style tabs so they adjust to the text labels rather than having fixed widths. The fixed widths look unbalanced against labels of varying character counts, and consume more horizontal real estate than is necessary. The fact only the text labels are links (not the whole tab) makes the current widths even more irrelevant. (Ed. — [correction] The tabs are blocked, but it’s not immediately obvious if you don’t watch the cursor.]

With these mods to the tab navigation, the entire masthead area is tighter, cleaner and more balanced. Admittedly, my mockup is a little rough in the graphic sense, but you should get the idea of the intended effect. Someone with a bit more Photoshop savvy could sweeten things a bit.

Left Column

Unlike the right column, the controls in the Write panel’s left column seem to be floating loose with no logical grouping or order. This shows a perfect example of how the current interface is sometimes hard to document with specific focus, and in fact is the reason I’m writing this article now.

Adding Fieldsets to Related Controls

The controls in the left column can be grouped into small fieldsets. The fieldsets then make it easy (by way of the legends) to document these controls with more precision and context (Figure 2). The fieldsets also provide a sense of balance/consistency with the right column which already employs them.

Current and proposed left column of Write panel.

Figure 2: Current (left) and proposed (right) organization of Write panel’s left column.

Logical Ordering

Note that by grouping controls, we can easily see the kinds of semantics/vocabulary that might work well in the legends, even a different sense of top-to-bottom order as would fit many mental models of page structure and/or workflow.

Custom Fields: A Special Case

The proposed Custom Fields fieldset is a special case; in addition to the fieldset, this also becomes a widget area having it’s own header with a hide/show mechanism. Thus, this may need to come out of the Advanced Options widget to function independently. Some site owners may use all 10 of the default custom fields (or even more if by way of an extension), while others may never use any. Either way, authors may not always want to reveal this fieldset, but rather have the ability to show custom fields only when needed (Figure 3).

Proposed custom fields widget.

Figure 3: Proposed Custom Fields fieldset as independent hide/show widget.

Note the legend of the Custom Fields fieldset includes a link reading “Manage” that points to the custom fields section in the Advanced Preferences panel, thus making it a useful navigation aid.

Alignment with the Grid

A couple more notes on grid alignment can be mentioned at this point. The left borders of the new fieldsets are aligned with the left edge of the invisible container, as are the various widget headers in the column.

The first widget header, Textile Help, is top-aligned horizontally with the Title field in the middle column, and with the “Create new article” element in the top of the right column (or the Status fieldset if view is in new article context). This is not different than it currently is, but it’s worth confirming to emphasize that the dynamic publishing dialog above the Title field is effectively in it’s own cell to alleviate congestion and bring attention to it. (More on the dynamic publishing dialog later.)

Aesthetic and Functional Enhancements

In addition to the fieldsets, a few functional enhancements are proposed that should be easy to add.

First, make the fieldset legends bold to stand out from the control labels themselves. This should be done consistently in the right column fieldsets too, as well as anywhere else in the admin-side where fieldsets are used.

Second, because blocks of controls in the left and right columns behave like hide/show widgets, it would be beneficial to add conventional up/down arrows (black directional arrows) to the right of each widget header so that it’s more obvious the header functions as a trigger to hide and show the associated controls. When widgets are expanded, the arrow should be up to indicate the direction of the widget action if clicked, and vise versa.

Finally, we should be able to use a help graphic that is more harmonious with aesthetics. Used in combination with the fieldsets, it’s now possible to eliminate a few of the help icons. We can now include two help tips, for example, in a single help pop-up associated to the parent fieldset.

Middle Column

There are four changes proposed for the middle column.

Dynamic Publishing Dialog Front and Center

I made reference earlier to what I call the dynamic publishing dialog (Figure 4). This is a reasonable reference to two interface elements merged in this study: the author-date-time dialog that currently resides at the bottom of the panel, and the publishing status dialog that currently appears at the left of the primary tabs when the article Save button is clicked. (You could test this in your own installation to verify what I’m talking about.)

Proposed merging and move of publishing dialog.

Figure 4: Proposed dynamic publishing dialog at top of middle column.

There’s no need to have these two dialogs in separate locations. The disparate positions and low-key styling that currently exist make these important information tools almost transparent. Indeed, having them together at the top of the middle column provides the best utility as the dialog information is immediately visible and informative.

The publishing status portion might also be bold and colored to help bring attention to the status cue. When the status cue is a long message, it simply wraps to a second line. An example of such a possible message is: “Article NOT saved. [username] modified the article while you were editing it. If you’re sure, press the ‘save’ button once more.“ Currently, when this particular status is displayed, it breaks out of the primary tab bar and looks bad.

Article Title Field

Two things happen here. First the Title input box is extended to the right edge of the middle column to square things out with the grid.

Second, the new “View” functionality is moved into the copy preview links as a fourth option. This makes perfect sense because the link is just a different way of previewing the copy, in this case with the presentation layer (and other page elements) added. (See section on copy preview tabs below.)

Logical Position of Article Elements

The third proposed change to the middle column is to switch the position of the Excerpt and Body text input areas. Typically sites are built so the excerpt, when used, always appears above the body, so by making this change we satisfy mental models about how this information will appear on the front side; it matches how experienced — and perhaps non-experienced — writers think about document structure. Don’t mess with people’s mental models!

Note with this new positioning I’ve also shortened the height of the Excerpt text input box by a couple of rows. Excerpts are typically (and rightfully) not long anyway, but a scroll bar will appear nevertheless when more space is needed. By the same logic, the Body text input box is taller by several rows, which is better for authors who edit here directly, as well reasonable in this new position. (These are default suggestions. Some browsers like Chrome allow a user to drag the text boxes to different sizes as needed, so there’s no need to be overly perfect by default.)

Merciful Handling of the Copy Preview Tabs

The last proposed change is to right the copy preview functionality so its not hanging like a dead rabbit on a barn door, and to eliminate the tab styling entirely. The tabs work in the main admin-side navigation because the different admin-side panels symbolize folders. That’s not the case here. All that needs done is to position them above the Body input box and right aligned with the right edge. The tab aesthetics can be replaced with normal text links. When a given option is active, it no longer functions as a link. Simple.

Proposed copy preview options and styling.

Figure 5: Proposed text copy preview options, positioning and styling vs. current implementation.

Te semantics of the links also need to be more intuitive and precise. All of them offer a kind of “preview” function, so calling one of the links “preview” is a misnomer. This label provides no indication as to what is being previewed. It would be more clear to use “Preview” as an inline header to this series of view options, and then use link semantics that suggest what is being previewed.

The first link, Text, almost gets it, but not quite. It could be argued that all tabs reveal text in different states. Thus it needs to be more specific what state of the text. It is in fact text with raw (not rendered) Textile. However, since we don’t want to confuse by suggesting the tab provides Textile help, we can be clever and use a label suggesting text that is marked up with Textile, like “Text(ile).”

The second link label, HTML, is fine. This sits well with the mental models most people have about what they will see when looking at HTML; text with HTML markup.

The third link needs a new label, and in this case what is being previewed is the actual rendered text, whether marked up with HTML or marked down with Textile. Thus, we could say we are previewing the rendered text, so “Rendering” might be a good choice for the link label.

Finally, we add a new link option; that which was recently added to preview a given articles presentation as it would be seen by readers on the front-side after publishing live. The choice for a label is obvious – “Presentation.”

Right Column

Aside from consistently using the general enhancements mentioned earlier for left column fieldsets, I have only one suggestion for the right column. Change the text of the “Create new” link to “Create new article” so it’s clear without thinking what is going to be created. As it is now it leaves you guessing, and that’s a link label faux pas (mistake) no matter how obvious the panel context seems.

h2 Footer

The panels don’t actually have footers, per se, and that is appropriate for an administration interface. In the course of this article I’ve noted where elements currently located in the footer could be moved to locations where their utility would be more appreciated. I’ll recap them again:

  • Textpattern version number moved to right of Textpattern logo (left of yellow bar).
  • Login/logout dialog moved to right of yellow bar.
  • Author-date-time dialog move above the Title field in middle column.
  • The Go… navigation moved into the top tabs bar, just underneath the login/logout dialog. Note I also propose changing the text from “Go…” to Jump to…. “Go” is typically used for search buttons, not navigation, whereas “Jump to” is conventionally navigation semantics. The text change makes the purpose of the drop down menu immediately clear.

That leaves only one element in the footer at all, the chiseler logo, which is a satisfactory element for that location.

—- [Update, 08 Feb 09]

Follow-up conversation on this article seems to have materialized in the Textpattern forum; this thread right here.