Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Admin Panel Edits for 4.0.4
A step to making things a bit more sharp in the admin panels, a bit more finished.
First, there’s inconsistency in the way widget labels are written:
- They should all be title-style but some are and some aren’t with no apparent rhyme or reason. The correct way, as the copy editors would tell you, is to capitalize each word (except for articles and conjunctions. For example, Time Zone, Use Textile, Production Status, Brick and Brack, etc. are correct, whereas Site name, Date format, Accept comments, etc. are not correct and should be changed.
- Any widgets that are phrase-style questions (such as Yes/No widgets) should also be title-style and end with a question mark (?). In actuality, there is quite a mixture of formats where either widget labels are not title-style and/or lack the needed question mark. For example, Accept comments is wrong in two respects, it should read as Accept Comments?.
A few more examples for clarity:
- Present comments as a numbered list? should be Present Comments as a Numbered List? (caps)
- On by default? should be On by Default? (caps)
- Mail comments to author should be Mail Comments to Author? (caps and punctuation)
These notes for change would, of course, apply to all panels — any instance where the title-style format is broken. For example, in the forms panel, some of the new tag builder headers are title-style and some are not. Again, inconsistency. All should be title-style.
Second, here are a few that really are usability issues:
- Questions should never be asked in the negative, which confuses what the user is supposed to be responding to. For example, the widget label Disallow user images should be changed to Allow User Images? (positive, caps, punctuation). It’s a lot more clear what the question is asking when phrased positively.
- Site tagline should be changed to Site Slogan. +1 deldindesign (Which is probably easier than changing the tag <code><txp:site_slogan /></code> to <code><txp:site_tagline /></code>.)
- Change the “organize” tab label to read categories. Just like the pages, styles, forms, and sections panels that are called by what they are concerned with, do the same here. The fact that you organize things with categories is a poor argument for not calling the tab something that is far more intuitive, clear in meaning, and cognitively consistent with the rest of the panel labels.
- While we’re here, might as well be thorough, why not change all tab labels to begin with a capital (e.g., Pages, Styles, Forms, etc.).
In addition to consistency improvements, and in some cases usability, these changes would also make it easier for documentation efforts when reference to a given panel or widget is being made. The referral can then be made with assurance that the syntax is exactly as it actually reflects in the site admin; something that can’t otherwise be achieved without having to go and look first for confirmation (due to the inconsistencies as they are).
Offline
Re: Admin Panel Edits for 4.0.4
Can I just say: “Wow.”
You’ve got some amazing thoughts here. I think these are all spot on.
Offline
Re: Admin Panel Edits for 4.0.4
Just discovered the new Image Code Builder that’s accessd when a code option is clicked (XHTML, Textile, Textpattern) from the images panel. Instead of just auto-generating the code as before, you are first presented with this new builder…
<img src=“http://textbook.textpattern.net/txpForumImages/txp4.0.4-imgcodebuilder.png” alt=“Image styles builder.” />space
The builder is great, but maybe make it a bit more inuitive for usability reasons, and apply the aforementioned title-style formatting to widget labels, like this…
<img src=“http://textbook.textpattern.net/txpForumImages/txp4.0.4-imagcodebuilder-sugg.png” alt=“Suggestion for new image styles builder.” />
The idea could be taken further by providing the ability to add img-related selectors to a menu so that they were available as dropdown options in the code builder. That way it’s much easier to remember what the selectors are, and eliminates ever having to refresh one’s memory by first going to the styles panel to hunt for them.
Last edited by Destry (2006-08-12 11:16:06)
Offline
Re: Admin Panel Edits for 4.0.4
I dunno, I do get what you’re saying, but looking at the two screenshots, the first is cleaner, more compact and to-the-point. Maybe that’s just a styling issue. Care must be taken with potential for confusion between image ID and html id, style sheet/inline styles. However in both “escape” escapes me and I don’t see it changing the generated code. What is that?
TXP Builders – finely-crafted code, design and txp
Offline
Re: Admin Panel Edits for 4.0.4
jakob wrote: However in both “escape” escapes me and I don’t see it changing the generated code. What is that?
Yeah, that’s why I put the help buttons in, figured they need them on that one. ;)
Maybe this is a good middle-ground…
<img src=“http://textbook.textpattern.net/txpForumImages/txp4.0.4-imgcodebuild2.png” alt=“Suggestion for new image styles builder.” />
space
- More descriptive Title
- Title-style widget labels
- Intuitive separation of markup widgets from CSS widgets.
- Fieldsets are still there, now borderless.
- Selectors are actualized for absolute understanding and distinction from other ID types (which are notated as ID).
Could probably drop “Stylesheet” for just Style.
Last edited by Destry (2006-08-12 15:06:21)
Offline
Re: Admin Panel Edits for 4.0.4
Definitely better, but still (agreeeing with jakob opinion) I feel the “Style and Selectors” separating label is unnecessary, and is making things less visually compact. I though that Style was the inline css rules… it is not? If it is, changing to “Stylesheet” maybe is not correct. But maybe it is not… :-)
Good thought above, anyway!
Z-
Offline
Re: Admin Panel Edits for 4.0.4
Zanza wrote: I though that Style was the inline css rules… it is not? If it is, changing to “Stylesheet” maybe is not correct.
I believe “Style” is to mean the actual stylesheet (managed in the style panel) that the selectors are actually written into. This would make sense because if you had multiple style sheets, you would need to make it clear which one you we’re pulling from.
Your confusion of the word “Style” by itself convinces me more that a change is needed to “Stylesheet” for improved clarification.
I’m not expecting these changes to be made (probably won’t be), only suggesting that understanding would be enhanced if they were. Design aspects are less important against usability. Design aspects as “cleaner and more-compact” are useless if they are not understandable.
Last edited by Destry (2006-08-12 15:40:19)
Offline
Re: Admin Panel Edits for 4.0.4
I am also under the assumption that style means inline CSS rules.
textpattern.org :: find and share Textpattern resources
docs.textpattern.io :: Textpattern user documentation
Offline
Re: Admin Panel Edits for 4.0.4
That looks a whole lot better, Destry. Yes, I like the ? – makes it all the more intrguing ;-) I thought it might be for entities in alt=“äöü” and title=“ßáé” fields but it seems to make no difference.
stylesheet/inline style: if you try it out you’ll see it’s inline style: you put in something like color:red;padding:10px; into the box and it adds out style="color:red;padding:10px;" to the img tag. To continue your labelling convention the label might be style="".
As always, one could discuss back and forth: style=”“ class=”“ and id=”“ are clear for everyone who knows html – is it safe to assume all admin users will understand html?
TXP Builders – finely-crafted code, design and txp
Offline
#10 2006-08-12 18:39:48
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: Admin Panel Edits for 4.0.4
Yes, I think using fieldsets and legends are a good idea.
(I had just wanted to get it updated since it was soo out of date. Now it’s about up to par, so we can work through fixing them up.)
As far as capitalization, I’ve been updating some of them as I notice them when I work through the various areas.
Some are in the form of questions and also not in “headers” so I don’t think they should be capitalized. For example: Mail comments to author? That’s a form field label. Capitalizing it seems kind of “funny”?
Others you mentioned I agree with you on, like “Time Zone”, “Use Textile”, “Production Status”, etc.
Offline
Re: Admin Panel Edits for 4.0.4
Huh, I’m practically intimate with Web standards (when I’m not too lazy) but I totally read the “Style” label to mean the name of a style (as in styles from the said panel) from which the selectors were defined in. In my mind, that’s more logical, and even if it can’t be done, it would be a lot cooler if it was. Instead of forcing inline styles, you just declare the external rules (stylesheet file and selectors) and output cleaner code.
I guess what throws me, is the idea of using the inline “style” attribute to begin with. I never do that (unless I’m forced to with something like Mediawiki), I always use external CSS to style my content, so it didn’t even cross my mind that this would be a reference to inline CSS. Crazy, I happily stand corrected (sorry Zanza).
Nevertheless ;) … this just shows to me, yet again, that the “style” implication is not totally clear in meaning, and anything less shouldn’t be acceptable. I didn’t try it out or I might have discovered the truth, or, on the other hand, I might have tried adding an actual style sheet name (believing I understood how it worked) and ended up wondering why nothing was working. At any rate, a user shouldn’t have to actually experiment with a widget to figure out how it works or what it’s intended for, that’s a usability failure for sure. If nothing changes on that one, I would at least add another help button to that widget for the waywards like me.
Mary wrote: Some are in the form of questions and also not in “headers” so I don’t think they should be capitalized.
I think it works either way in this case, and a normal looking phrase (punctuated sentence with no caps but the lead word) is probably more accepted with folks here, but there are editing guidelines that define that when something if first a label, even if it’s a phrase, it’s treated as title-style. But again, lowercase here works just as well, and nobody is likely to sue. ;)
Add the “?” where they’re missing for questions and your good in that respect.
So, Mary, what about the “organize” tab label…categories? ;)
Last edited by Destry (2006-08-12 19:30:43)
Offline
Re: Admin Panel Edits for 4.0.4
Destry wrote:
I’m not expecting these changes to be made (probably won’t be), only suggesting that understanding would be enhanced if they were. Design aspects are less important against usability. Design aspects as “cleaner and more-compact” are useless if they are not understandable.
Your suggestions are great and make we think! Krug would agree. ;-)
Definitely understanding is crucial part of usability. Nonetheless, also good design is part of usability. This is often overlooked. I think textpattern is better designed and better looking of most of similar products, thanks to Dean.
So my concern is that understanding and good design are not one against the other! A good design helps understanding, as good labeling, consistance, and other suggestions you made.
This to say that I feel the proposal you made would be more understandable and usable without the double fieldset border and legend: they are unnecessary from my point of view. Don’t help user, because the number of informations are so few (five), that chunking in two group is not needed (it would be with more fields, as in the write interface). With many unuseful signs to visually decode, I fear they could make hardest to understand, not easier. But, well, we should user test to decide! ;-) So it’s a matter of opinion, but I’d make it simpler.
About trial and error understanding of “style”, maybe call the label “inline style” would help? Anyway, maybe this is not clear at first for everyone, but textpattern, unlike most websites and like most applications, can have a learning curve from repeated user. So this is a tollerable tradeoff for me.
And at the end, yes!, I definitely vote for “categories” instead of “organize”!! For months I’ve been thinking the same, without speaking it out! This is totally agreable, organize is meaningless for most first-time user, that are often confused by section-category relations. So make categories handling more evident would help distinguish them from section, and understand textpattern concepts better and faster. :))
Well, just my two cents… :)
Bye
Z-
Offline