Slight semantic "enhancements" to admin-side 4.0.9.

Destry · 2009-01-21 12:14:24

Saccade has been giving unprecedented attention to translation and editing efforts in TextBook (if only everyone did a fraction as much). We are working out what is the cleanest way to document TextBook in the wiki when describing the admin-side and using images to do so. Although my views on it are a little different than Saccades, there is one thing that is making any approach to documenting Txp more difficult — consistent heading/labeling of admin-side panel widgets/fieldsets.

Consider the Write panel, for example, which I also discuss in that link above. It has three columns, the middle of which we can disregard here as it’s sufficient enough. The right column is also sufficient, and a good example of what I’m getting it done well. Each widget or set of controls is distinguished with a fieldset and this makes it easy to document. The left column, however, is a different story. It’s inconsistent with the right column in that is has a column header while the right column does not; but more importantly, the controls are just kind of sprawled out in the left column with no real distinction or care for order. They need grouped somehow and labeled so that each “group” can be described in a focused way.

What would be nice (and professional) is if we could tighten these kinds of things up in every panel that needs them (maybe that’s it, haven’t really looked closely yet). By doing that — if you go back to that other thread where I’ve talked about the copy-image relationship — it makes it considerably easier to document the interface in a consistent, concise manner. Not to mention it makes the admin-side look tighter.

Is this a possibility in 4.0.9? Do you want some mockups of such “tightening?” Rest assured, from me at least, I’m not interested in redesigning the admin-side, I just want to refine what is there.

Last edited by Destry (2009-01-21 12:20:41)

wet · 2009-01-21 12:55:33

Destry wrote:

Do you want some mockups of such “tightening?”

You bet.

Destry · 2009-01-21 13:31:45

OK. Cool. Will do when I get a decent chance.

In the meantime, anyone else is welcome to contribute visual suggestions too. As a reminder, my only focus here is with improving the way controls are grouped/referenced so that documentation efforts are easier. There’s been a lot of ideas in the past about redesigning the entire backoffice, and you can find plenty of threads on that, but that’s not the aim here.

This thought-provoking article from 37Signals comes to mind as an indication of the localized focus I’m talking about (though maybe not to that extreme in this case).

Destry · 2009-02-05 15:24:35

wet wrote:

You bet.

Here it is. I needed an excuse for web content so you get background and theory too. :)

ruud · 2009-02-06 17:55:01

Quick comments:

If the Concept is Folders, Make Them Folders => I think the current design looks better.
Label-to-Tab Proportioning (Sliding Doors) => no objection to that.
Adding Fieldsets to Related Controls => nice questionmark graphic. The hide/show indicators (the triangles) are not very clear, IMHO. Using a [+] or [-] is perhaps more informative. I’m not sure about the fieldsets. url-only title isn’t something I’d group under META for example.
Custom Fields: A Special Case => no objection, although mentioning custom fields as the fieldset legend is a bit too much here. Might work if Keywords also falls under that header
Dynamic Publishing Dialog Front and Center => No point in displaying all that information. Users don’t need to be reminded who they are and what time it is when they post something. The additional coloring is not pretty. The concurrent edit warning is an ugly hack really (not talking about the way it displays).
Article Title Field => “view” is separate because it makes you leave the admin side
Logical Position of Article Elements => you’re assuming that both excerpt and body are displayed at the same time. Some people really do use the excerpt to create a summary of an article. The body is always entered so should be on top (so you don’t have to scroll), contrary to the excerpt which is optional. Those that like it otherwise could install a plugin that reverses the order (shouldn’t be too difficult).
Merciful Handling of the Copy Preview Tabs => do we need “preview” if there’s also “view”? The “text” tab isn’t necessarily Textile. That depends on the advanced options. The problem with the “view” tab is that it leads to the public TXP website and doesn’t work unless you first save the article. Mixing that with the other tabs (I don’t mind them being tabs) is confusing.
Footer (h2 is missing there in the article, btw) => TXP version is in diagnostics, no point in showing it everywhere. Logout+name clearly visible at the top would be an improvement. The “Go…” menu is already at the top. Removing it at the bottom would be fine by me. What if we renamed it to “Go to…” instead.

jakob · 2009-02-06 18:41:21

Interesting write-up, Destry. You may be right that the incremental approach may have a better chance of making it to the core as they maintain current behaviour and break existing plug-ins less. I’m just not sure how much difference they will actually make, though – more about that further down.

Here’s my take on your points:

Global Tabs – Tabs => agree with variable width using sliding doors, absolutely agree with making full tab clickable. To me though, your proposal feels cramped and needs more space and visual differentiation – one needs to tell them apart at a glance, not have to look for them. The existing shadows help one to do this, even if they are not brilliantly executed.
Global tabs – Gradients => I understand the point you make that the tabs should have the colour. At the same time, the active tab also relates to the page that is shown on the main screen. The gradients respond to the first visual problem but creates a second problem by creating a separate colour swathe between tabs and page content. The removal of the shadows and the double layer of gradients makes what were two levels of tabs into a yellowy-cluster of 11 tabs that stop rather abruptly at the sides. So, while I understand the sentiment, I don’t feel the current execution is not an improvement (I know, you did say it was rough).
Textpattern’s yellow bar => I love textpattern and push it again and again but for client’s/end-users it’s mostly irrelevant. Ideally, they want it to have something to do with them. I don’t propose removing it, but it needs designing in such a way that other things (client branding) can co-exist alongside it.
Alignment, grids and space => YES to alignment with common datum lines, YES to more space at the top but adhering to a grid is in my view secondary, especially where content is variably long in different columns.
Excerpt-Body / Body-Excerpt => Different projects use these differently, some never use excerpts. Organised people probably have a brief synopsis in their heads and may start with an excerpt. Many who enter or copy text pre-prepared elsewhere will copy the body and title out of a file, then write an excerpt. Ideally this should be a preference. A draggable lower edge to the textareas would allow everyone to size them as they see fit.
Fieldsets and hide/show => YES to hide/show but with ability to make them stick, e.g. via cookie setting and ideally for different user classes (as with ied_hide_in_admin). In your layout there’s currently some redundancy with double titles plus it spaces everything out a lot so the visual grouping is lost (in my view not just aesthetics but also to do with orientation).
Preview tabs => I hardly ever use them myself and like your suggestion as the sideways tabs are often overly present, especially where the text is short. I don’t agree on the wording though: the “text(ile)” label is too clever for a new user and “rendering” and “presentation” are not immediately differentiable in the same way as “source code”, “text preview”, “full preview” are (by way of example). One last thought, the tabs do denote a pane-view of the main content which the links don’t render in the same way.
Message box => I agree it must be visible, not sure about smack bang at the top, though. There are, of course, message boxes that appear there and then fade after a short while.
No footer and login at top => I have this like this permanently on my own setup.

Overall, when I look at your mock-up compared to the original and screw up my eyes, I’m sorry to say that I think it has actually lost some visual clarity and differentiation of the original. A lot of things have fairly equal visual weight and have been spread out more evenly with the result which, in my view, makes it less clear to navigate.

I think one of the main reasons why all previous attempts have fizzled has to do with the fact that many people have different preferences, different projects use fields differently (indeed different sections already do, see sed_section_fields) and that different user privileges need to be able to see different information (something that ied_hide_in_admin addresses). Some projects have a lot of entries/sections/forms… which then benefit from foldaway panels, others have just a handful. Additionally many want to “brand” the interface, at least nominally, to fit their clients colours/site.

In my view, this is not just about aesthetics (which is a valid reason too) but is about improving usability and about simplifying things for clients (both those clients challenged by too many input boxes as well as those with a tendency to fiddle with the unnecessary) and about increasing the client’s identification with “their site”, so that the likelihood that they can take care of it themselves is better.

So the discussion will likely persist until the back-end can be modified and tailored relatively easily (if not granularly, then in a couple of variants). Hence the numerous patches and admin plugins, some of which go to quite extraordinary lengths to change the admin (e.g. aro_myadmin which is essentially a convoluted per-page repaint job). Meybe if we can modularise the back-end into sensibly-grouped and used-together items and recreate the existing interface, that will ensure continuity while also making it possible to tailor the interface more to individual needs.

Destry · 2009-02-07 01:29:26

Thanks for the comments, gents.

This was not meant to be a prescription for doing, but rather a proposal for thinking about the kinds of things that can make a difference. A lot of design attempts don’t think past color changes and jelly buttons, or whatever. I hope it was clear in the article that I feel as Jakob described — that it’s not about aesthetics as much as it is about usability.

Documentation is my main motivation in all of this. People writing about the interface need hooks just as much as a programmer does for working with function and style. If you can’t effectively describe the interface because of it’s inconsistent design, then you’ve failed the user in a different kind of way, with the documentation. Hell, you’ve failed the author who might offer to write documentation to begin with.

You see what would be the obvious thing to do here, right? Sift through your replies to my proposed stabs and list out where everyone agrees. Those are the logical changes. Then list out where there was some agreement, hash out the minor differences and maybe those become second-round changes. Etc. The point is that your not overhauling the entire interface, but making productive strides each time, and eventually getting to that easy to reskin state that Jakob refers to.

Let’s try and see where we overlap, or not. And, you know, modifications to the ideas to find common ground are expected.

1) Tab Menus

Actually, I agree with the fact the existing color use on the tabs is better than what I proposed, for the very reason Jakob points out about the active tab being the face of the panel. I recognized this while writing the article, but wanted to show the other perspective nonetheless. We also seem to agree on the sliding doors, and perhaps to address Jakob’s concern for compactness you simply add more padding on each side of the tab text. This still keeps the tab widths relative to the text (thanks to the sliding doors), but adds some breathing room too. (Unlike Jakob I still don’t see the point of the shadows, but two out of three is pretty good.)

2) Left Column Controls

We seem to agree on the need for visual indicators for hide/show states, and I agree with Jakob on the need to make them stick as a user desires. In fact that’s already been pointed out.

I would argue Ruud’s view on the type of indicator though. Sure, you could imagine [+] and [-] triggers, but I think conventions associate these with folder hierarchies more so than with expandable/contactable widgets (note I use “widgets” for lack of a better word). The arrows are not something I just made up, but in fact are used in interfaces of different kinds (CMS, browsers, web applications…) to indicate the very thing being described here. Just look in the header bars of Firefox, for example, and note the black down arrows for navigation, visited addresses and search engine options. I think users would connect better (from experiences they have elsewhere) with the conventional arrows than with math symbols.

As for the actual organization and semantics of the left column controls, that still needs worked out, apparently. I see what you mean with the redundancy on the header and legend with the custom fields. I didn’t catch that, but you’re right. Change the legend to “Fields Defined” and it’s workable. (Might suggest not having two defaults show if not defined.)

3) Dynamic Publish Dialog

Ruud’s response on this has me a little confused. So the Txp developer is saying these dialogs are not important? Then I would ask, what are they in the interface for? :) Seriously, I think they do offer some value, the contexts of which will be different to different people. If you keep them, they should be prominent. If they’re not important, they should be eliminated entirely. Nothing is served by tucking them aside in odd, unnoticeable places.

4) Excerpt/Body

OK, I agree there is less use of the excerpt so not to warrant putting it first. No problem. However, Ruud, I was not assuming anything. In fact I use the excerpt as you say on my own home page. Unless you meant to write “do not use the excerpt…” :)

5) Preview Copy Options

I think we at least agree on making these options horizontally aligned and improving the text labels, and that’s the most important thing in my view. Whether it’s tabs or just links is secondary. I went with the cleaner code choice. The exact semantics could be figured out. As to Ruud’s point about the “View” function taking a user out of the admin side…so what? It’s still a copy preview option, and like the others it only takes a single click to get back to the previous view. Also, I think the current “View Site” semantics of the primary menu tab is potentially confusing against the “View” link. Putting it in the preview options with a different label eliminates that potential entirely.

6) Client Branding

The yellow bar is simply a default. You’ve got to start somewhere. I’m in complete agreement with all thinking towards making the admin-side easier to skin for the sake of branding one’s self or client.

7) Dropdown Navigation

“Go to…” works for me. The “to…” makes the difference; giving the cue of “navigating.”

jakob wrote:

Meybe if we can modularise the back-end into sensibly-grouped and used-together items and recreate the existing interface, that will ensure continuity while also making it possible to tailor the interface more to individual needs.

By the way, Jakob, I liked that mockup you offered in the fork project. Still a few issues, I think, but definitely the most fresh “outside the box” idea I’ve seen yet. :) Can’t seem to find that link now though.

jakob · 2009-02-07 09:30:20

Yes, I’ve had several goes at this and so have come up against several of the problems you mention in the past. For myself, I don’t mind departing from the standard version but I realise that is not for everyone and causes support problems.

Some are on flickr, the one you were referring to with its branding variations is on Skitch (I’ve no idea if xpattern went on to use it – thread with explanations). One of my earlier variants has a go at updating the standard tabs but after doing it I found the yellow a bit overwhelming and the tabs a bit large (probably needs toning down a bit). A more recent iteration has more compact tabs with clear visual cues. Needless to say they all need hacks to the core (some quite considerable) and break the behaviour of some admin-side plugins, which is why they are not in the wild as there would be endless support issues which I am anxious to avoid landing the forums with, or myself for that matter.

Almost all the above tackle some of the issues you mentioned, which is why I mention them – as you say for thinking about: this thread should not become another facelift round – but all go further than slight changes as I realised that some arrangement changes were necessary to adequately resolve some of the issues:

All the tabs use variable width ‘sliding-doors’ (using tab code from philippe and mary).
Several use the tabs metaphor but with inverted colours.
The top right area for login and user infos, and no footer (code form rloaderror and others). You can look up the version number in diagnostics.
The top area for colour and ‘branding’ and site name or logo with the txp logo arranged to the right beneath the tabs (think of it as a discreet emblem on a pullover rather than a label on one’s forehead).
This area is also where the message box appears, clearly but out of the way and without obscuring anything.
The central column or main edit area is variable width.

There are several things they don’t always address, though, for example as I rarely use the jump drop-down or the preview tabs, I left them out sometimes and one could debate about the right way to group things probably endlessly. Other admin makeovers adopt similar strategies.

Maybe, as mentioned above, a first step would be to realise a version similar to the existing setup but with new tabs and head so as to maintain continuity, then move on from there.

ruud · 2009-02-10 10:48:03

Dynamic Publish Dialog
Ruud’s response on this has me a little confused. So the Txp developer is saying these dialogs are not important?

No, I wasn’t, although there are quite a few messages that are not important at all. I was mainly responding to the specific example you have, showing some information that TXP currently doesn’t show at the top.
Since there is a difference in importance between messages, one might consider displaying them in different ways that are appropriate for the level of importance. Ranging from the way they display now to annoying javascript alert windows (which are hard to miss).

Excerpt/Body

Yep, wrong assumption on my end ;)

Preview Copy Options
As to Ruud’s point about the “View” function taking a user out of the admin side…so what? It’s still a copy preview option, and like the others it only takes a single click to get back to the previous view.

The vertical tabs are forward clicks, from which you can return by clicking another vertical tab, but to get back from the “view” function, you can only use the back button, which is not guaranteed to preserve what you entered/changed on the write tab before using “view”.

renobird · 2009-02-10 14:41:20

Jakob,

I can’t even look at your examples without getting all hot and bothered.

:)

—
T

Destry · 2009-02-10 15:03:49

ruud wrote:

which is not guaranteed to preserve what you entered/changed on the write tab before using “view”.

I hadn’t realized that. Good point. (I’ve been saving instinctively before using that feature.)

I don’t think anyone would be confused by having to use the backbutton in this day and age, but if your data is lost, that’s something else entirely.

Still, the link labels between the View Site tab and the View link are too similar; not communicating the true nature of what one is looking at. Especially since both appear with the presentation layer added.

Maybe the View Site tab could read “Site Home” (always pointing to the site home page), and the View link changed to “View presentation” (or “View styling” ?) so it’s actually clear what it is you will be viewing (a fundamental usability rule for links).

nemoorange · 2009-02-23 14:12:04

re: sliding doors on the tabs.

This is a good idea, but currently the tabs all sit inside a table. In creating some of my themes, I tried make some styles that used variable width. This worked out okay for the one word tabs (Presentation, Admin), but anything that used two or more words had the danger of being split into two lines, since the table cell could be resized. From this experience, I’m assuming that for the sliding-door technique to work, an unordered list would have to implemented in place of the table for the top navigation. While I would LOVE that from a CSS standpoint, I’m not sure how feasible that is as a ‘slight enhancement.’ Seems more like a big overhaul.

<txp:shameless_self_promotion> I just released a bunch of CSS themes for the Textpattern admin where I tried to address a bunch of these issues: tabs, buttons, typography, etc. For those interested, I wrote an article all about the minutia of designing the themes. </txp:shameless_self_promotion>

Textpattern CMS

Textpattern CMS support forum

#1 2009-01-21 12:14:24

Slight semantic "enhancements" to admin-side 4.0.9.

#2 2009-01-21 12:55:33

Re: Slight semantic "enhancements" to admin-side 4.0.9.

#3 2009-01-21 13:31:45

Re: Slight semantic "enhancements" to admin-side 4.0.9.

#4 2009-02-05 15:24:35

Re: Slight semantic "enhancements" to admin-side 4.0.9.

#5 2009-02-06 17:55:01

Re: Slight semantic "enhancements" to admin-side 4.0.9.

#6 2009-02-06 18:41:21

Re: Slight semantic "enhancements" to admin-side 4.0.9.

#7 2009-02-07 01:29:26

Re: Slight semantic "enhancements" to admin-side 4.0.9.

#8 2009-02-07 09:30:20

Re: Slight semantic "enhancements" to admin-side 4.0.9.

#9 2009-02-10 10:48:03

Re: Slight semantic "enhancements" to admin-side 4.0.9.

#10 2009-02-10 14:41:20

Re: Slight semantic "enhancements" to admin-side 4.0.9.

#11 2009-02-10 15:03:49

Re: Slight semantic "enhancements" to admin-side 4.0.9.

#12 2009-02-23 14:12:04

Re: Slight semantic "enhancements" to admin-side 4.0.9.

Board footer