Admin Panel Edits for 4.0.4

Destry · 2006-08-15 05:51:57

Mary wrote: Destry: you’ll notice whichever link you choose pre-selects from the dropdown type.

I did notice. As I said…

I realize that the option you click is in the default Type position in the code builder, but might it just be a bit cleaner (and less redundant) to have a link in the image row that reads “build tag” instead of the three different links, …

In other words, is that preselection worth the extra vertical space it requires in the images panel? If you have a lot of images (thus rows) those extra lines caused by the redundant three tag type links can really add up. Why not something like this…

The idea now being that when a person clicks the “Build it!” link, their taken to the code builder as before, but instead of a particular tag type already preselected, the Type default is blank, or perhaps reads “select type” (either way).

I think this is just as clear and easy; you’re simply moving the user step of making a type decision to the code builder (it makes sense that it’s part of the building process anyway), and in return you save vertical space in the images panel. Individual row height is reduced by reducing the Tag column from three line spaces to one, which in turn eliminates a line from each row altogether.

EDIT: By the way, Mary. Love the new tabs! Thank you. Thank you.

Last edited by Destry (2006-08-15 06:07:13)

Destry · 2006-08-15 12:56:23

EDIT: By the way, Mary. Love the new tabs! Thank you. Thank you.

I’m digging the changes so much I had to repeat it. And thank you for changing site admin to Users. That was one that bothered me as much as the organize tab and I completely forgot to mention it. Nice thinking on the logs tab too. I’m so happy to see all this. This really does make it easier for us writers, believe me, not to mention the users.

I’m slowly getting to updating the TextBook Site Administration docs (and writing the ones missing). People can help and/or check my work. So far…

Users Subtab (Note that section 4 of that panel, Add new author, needs title-style edits… Add New Author. Otherwise all looks good on that one.)

Zanza · 2006-08-16 11:21:56

Destry wrote:

bq. Mary wrote: Destry: you’ll notice whichever link you choose pre-selects from the dropdown type.

I realize that the option you click is in the default Type position in the code builder, but might it just be a bit cleaner (and less redundant) to have a link in the image row that reads “build tag” instead of the three different links, … In other words, is that preselection worth the extra vertical space it requires in the images panel?

Hi. I love this thread and your works, because it shows a lot of useful situations about usability improvement of interfaces, that I’m going to use in some courses of mine to illustrate the concept that usability is a matter of tradeoff and you need to balance between different goals and cost/benefit ratio.

Take this one. The three labels (Textile,Textpattern,XHTML) let you have a efficiency advantage on building a tag. If you do a task analysis, you can see that it saves actions. With 1 click, you save all the actions you need to select from the dropdown (point, click, shift, release mouse button) in 2 cases out of three. This is great and I love it.

On the other hand, Destry points out that this adds an extra line for every image! This force you to see a fewer number of images in the viewport, so that you may need to extra scroll (this is a lose of efficiency in some cases). Also true.

As always, can we reach a win-win option? I guess. Maybe you could revert to the old one style of “Textile/Textpattern/Xhtml” on one line (or maybe on two), but acting as in the new version.

Could this be done? Maybe this would be a happy tradeoff…

Bye

Z-

Last edited by Zanza (2006-08-16 11:23:03)

Mary · 2006-08-17 00:51:24

They are one per line because of concern over the table’s overall width. Once you start adding thumbnails, you could easily have a horizontal scrollbar appearing. You really don’t “save” any significant space by having them all on one line.

Zanza · 2006-08-17 10:21:46

True, if you have thumbnails you don’t save any space. About width of table, at 800 × 600 it allows some extra space to be added, but I see that it isn’t really useful to put labels on one line. I think it’s a good work.

By the way, 2 extra things (i’m going off topic) I’d find useful:

There’s no way to have also caption searchable? Both in backend and in front site, actually…
A way to edit insertion date of images and file. I think this plugin for editing link date is a good idea, also for images.

Bye

PS: casually validating: 1 div closed that is not open. A legacy tag, maybe. I don’t know if validating the backend is an issue (I know people that would apreciate, but it depends on the effort needed), but in this case it’s only one tag, maybe it worths.

Destry · 2006-08-17 14:16:01

Zanza wrote: I love this thread and your works, because it shows a lot of useful situations about usability improvement of interfaces, that I’m going to use in some courses of mine to illustrate the concept that usability is a matter of tradeoff and you need to balance between different goals and cost/benefit ratio.

I agree, this is entertaining discussion. ;) Are you a teacher or a student? Just curious. I’ve had quite a bit of theory, practice, and research in usability myself (as a student and practitioner) and your right, usability is often a trade-off, but we know metrics and cost/benefit ratios are only part of the puzzle, and only on the theory side at that. In practice, the target audience and all their collective schema (i.e., what they deem as being understandable, memorable, and easy to do…cognitively speaking) is the bottom line.

With this crowd, I don’t think micro-analized mouse actions weigh as significantly as functional use of panel realestate. For the sake of simplicity, let’s consider your “point, click, shift, release mouse button” phases as a single selection operation using the mouse against a form control. For example:

following a link is one mouse operation (one click),
selecting a yes/no response in a radio button is one click,
selecting an option in a dropdown menu is two clicks; first to drop the menu, second to select the desired option. (Note: you could hedge the bet here a little bit by setting one of the menu options — ideally the most popular — as the default, which has the potential of eliminating the two click operation altogether in many user instances.)
etc.

Now, lets count the number of clicks as it’s currently necessary to start a tag of a given Type in the code builder…

One, gauranteed. Achieved by clicking either the Textile, Textpattern, or XHTML link in the images panel, which then appears in the default position in the code builder. However, were left with the repeating Textile, Textpattern, or XHTML links in each row in the images panel, which is the realestate problem.

(Note: This says nothing of the likely extra clicks users will make in the code builder’s Type dropdown menu simply for exploratory reasons. It’s often shown that when things are too automated, users will explore a few things on their own anyway to be sure they understand what’s going on. Hence, I’m betting the one click operation is an ideal myth at first until users come to fully understand how the code builder functions; they’ll be clicking all over simply to learn. Just an educated hypothesis.)

Now the clicks as they would be required in my proposed panel changes above…

One or Three. If no tag Type option is made default, it’s a sure fire three clicks, but it’s absolutly clear to a user every click of the way what it is they are doing and how the code builder should function. On the other hand, if a tag Type is set in the default menu position, then there is a good chance that only one click is needed, which is the initial click on the “Build it!” link in the images panel (in this case, the same “exploratory” behavior noted above will likely be in affect initially because again you’ve automated something that may be manually investigated).

(Note: If a Type option was to be put in the default position, a sensible usability tack would be to ask the community which tag Type they often prefer, and then go with the majority vote, that’s as good a method as any (and probably the best) and increases the odds of establishing a default that users in general would want, and thus potentially reduces the total mouse clicks from 3 to a 1.)

When it comes down to it, neither method (existing or proposed) is particularly harder than the other to do, and I don’t think an extra click or two is going to bother Txp users if it’s logical according to normal form control behavior (which it is); however, what seems to be gained from my proposed change (as it seems to me) is a more consolidated images panel and fewer links to look at.

Last edited by Destry (2006-08-17 14:18:15)

Zanza · 2006-08-17 16:08:33

Destry wrote:

bq. Zanza wrote: I love this thread and your works, because it shows a lot of useful situations about usability improvement of interfaces, that I’m going to use in some courses of mine to illustrate the concept that usability is a matter of tradeoff and you need to balance between different goals and cost/benefit ratio.

I agree, this is entertaining discussion. ;) Are you a teacher or a student?

I’ve been a usability consultant and teacher for the last 6 years. I also wrote a book on the topic, but I’d better not to advertise it here. :) I’m a forum participant as everyone else, every one has his experience in a topic or another. The melting pot of experience is good. :)

I’ve had quite a bit of theory, practice, and research in usability myself (as a student and practitioner) and your right, usability is often a trade-off, but we know metrics and cost/benefit ratios are only part of the puzzle, and only on the theory side at that. In practice, the target audience and all their collective schema (i.e., what they deem as being understandable, memorable, and easy to do…cognitively speaking) is the bottom line.

Yes. But we sparely know about cognitive schemas of txp users about single issues: we can only guess. Metrics are objective, and for a piece of software like TXP they’re valuable as well. Both approaches can (should) live together.

With this crowd, I don’t think micro-analized mouse actions weigh as significantly as functional use of panel realestate.

That’s the way GOMS Task Analysis works. They are different action, and involves time and effort for users. I agree with you when you say that the difference is not that big. But if it makes a little difference, that’s better than nothing! :) GOMS is inappropriate on informative websites, but useful for repeated tasks in software. Here I think TXP should be considered as a piece of software, also. People would click on the labels many times, not only once. It’s a repeated action, learned. In that cases efficiency (less time, less actions) is valuable.

Now, lets count the number of clicks as it’s currently necessary to start a tag of a given Type in the code builder… (..) One, gauranteed. (..) One or Three.

I agree with your analysis, and I stll prefer “always One” than “One or three”. :)

(..) however, what seems to be gained from my proposed change (as it seems to me) is a more consolidated images panel and fewer links to look at.

Yes, your proposal is a little more compact as an advantage, and a little less efficient (and less visible) as a disadvantage, as often usability changes are. So it’s really a matter of tradeoff. As Mary pointed out with thumbs the three lines don’t make a difference anymore. And for me the advantage of visibility (the three actions always visible and available at 1 click) and efficiency is better, that’s all. I understand if you prefer the other option. Even if I’d like to see you managing lots of images daily on your site and click many times the ‘build it’ link and then change the select 2 times out of 3… It depends on context, on task, on user. But I think that the disadvantage of three lines is less crucial than the advantage of efficiency, for “frequent image handling” context of use (i also have sites with many images).

So that’s my choice as a “frequent image handler”… :) Anyway, I’d revert on your choice if the alternatives were more than three (imagine 5 or 6 lines: that would be unacceptable, the space wasting too much for the little advantage of visibility). So I really think this example is a good “case study” for usability tradeoff, because if you change a little the interface or the context of use, you can go for different conclusions.

Bye

Z-

Destry · 2006-08-17 19:45:16

Ah yes, know GOMS well. And yes, the thumbnails do influence the realestate issue.

Zanza wrote: I also wrote a book on the topic, but I’d better not to advertise it here. :)

Oh come on, cat’s out of the bag now; at least a hint. You don’t even have a Web site link for us to follow. Seriously, I’d like to check it out. English copy? Email me if you like.

EDIT: I think I found it…Ecologia something, HOPS is the publisher? I guess no English version.

Last edited by Destry (2006-08-17 19:50:39)

Zanza · 2006-08-19 11:02:03

No english version. You’d better not to learn italian just for this… ;-)

Bye

Z

Destry · 2006-08-20 21:54:30

There’s still many instances in the panels, particularly the different Preferences panel views, where issues I brought up in the initial post still apply, namely title-style labels for non-questions type controls and question marks (where missing) for question type controls, but since I’m working on the preferences panel docs at the moment, I have a couple other notions to bring to light:

In the Preferences panel, Advanced Preferences view, Publish section:

First widget of the Publish section reads allow_raw_php_scripting. I’m guessing that’s supposed to read as Allow raw PHP scripting? with a Yes/No radion button pair? Also, see #4 below, and then see #7.
Three more down from that one is the ping textpattern.com? widget. What exactly is the purpose (value) of pinging textpattern.com. The internal help for that one just indicates that choosing yes lets you do it, it doesn’t explain at all why you would want to do it, or even what it does if you did. Anyone care to enlighten me?
Five more down from that one there is the Never display email? This is awkwardly being asked in the negative (see notes in initial post), which is confusing. It should read as Always display email?, and the radio functions should be corrected if needed. Actually, I wonder if this should even be an option. The way security issues are anymore, this should just be set as no all the time and unchangable. Or am I overlooking something?
The next two have to do with allowing PHP on pages and articles. How is that different from #1 above, Allow raw PHP scripting? Redundancy?
A couple more down from that there is the Include email in atom feeds? widget. If a person says yes to this, is the email address open to the world/harvestable? Oh, and going back up a bit there’s another one that reads Use mail on feeds id?. Should that read as e-mail?. Also see #7 below.
Near the end there is the Permalink title format (needs a question mark). The internal help uses the word “hypen” twice. I think it means hyphen? Also, it indicates having the option of using CamelCase. Where is the CamelCase option acted upon? Where’s the controls for it?
The last two having to do with using plugins or pinging Ping-O-Matic make me thing this whole section of widgets needs rearranged a bit better so that like topic widgets are next to eachother. For example the admin-side plugin widget question is clear up near the top while this one is at the bottom (there’s 21 widgets in that section). Same goes for the _ping-related widgets, and so forth. It’s just easier on the brain to compare and understand like questions when the questions are directly next to eachother.

Last edited by Destry (2006-08-20 22:33:54)

Destry · 2006-08-21 10:41:45

To address these panel edits better, with more organization. I’ve started a new page under the Feature Requests area of TextBook for Improved Copy in Site Administration Panels. If people find things to add, please do so in this TxB page. Thanks.

Mary · 2006-08-22 01:52:54

Yes.
It pings Textpattern.com (just like you could ping Pingomatic). The idea is that at some point, when we’ve got the time to set it up, we can have a “latest Textpattern-powered sites updated”.
Yes, this is not a good one. Unfortunately, because of how the varible is used, switching the name requires updating preferences to reverse the logic. I’m not sure this would be a good idea for 4.0.4, but this can be corrected in crockery.
This isn’t redundant. It determines whether you can enter raw PHP (<?php echo 'hi there'; ?>) as opposed to using the Textpattern php tag (<txp:php>echo 'hi there';</txp:php>).
It is world-readable, yes. Hence the fact that it is a setting you can turn on or off (it’s an optional element in Atom feeds). And the second one should be modified, yes. This is another Atom/RSS thing. If you choose no, then your site url is used instead.
Fixed the spelling mistake. That control is the control for CamelCase, as it states: “Permalink title-like-this (default is TitleLikeThis)”. If you pick yes, you get title-like-this. If you pick no, you get TitleLikeThis.
It’s because of when and how controls are entered. Each pref has a sort order column, where a number is entered where it should appear in the list. Entering in one later, you’d have to update all the others’ sort ids. It’s not difficult to fix per se, it’s just a bit of a nuisance.

Destry · 2006-08-22 15:19:28

Thank you, Mary. This helps immensely with documentation/writing.

Some follow-ups:

2. It pings Textpattern.com (just like you could ping Pingomatic). The idea is that at some point, when we’ve got the time to set it up, we can have a “latest Textpattern-powered sites updated”.

OK, so at the moment this doesn’t work at all, correct? Can you elaborate on this “latest Textpattern-powered sites updated” concept a bit more? Where will this be located, .com?

While I’m thinking of things that are supposedly options in the admin panels but which do not work, what else in the entire Admin side is a viewable widget but which no functionality exists? Is there a list somewhere? Shouldn’t these things be hidden if they’re not functional, to eliminate confusion?

4. This isn’t redundant. It determines whether you can enter raw PHP (<?php echo ‘hi there’; ?>).

OK. Does that mean then (if chosen as yes) that raw PHP can be added to articles too, in addition to templates and forms? This is the kind of stuff that needs made expressly clear in documentation…no assumptions about what the reader already knows about programming. If there’s a FAQ that sheds light on a given subject, put a link to it from the internal help widget. Heck, Txp semantics is a stumbling block for a lot of people as it is; you start throwing in notions about using raw PHP, then help about that topic better express to what extent and where, exactly.

5. It is world-readable, yes. Hence the fact that it is a setting you can turn on or off (it’s an optional element in Atom feeds).

<strong>“Hence the fact that…”</strong> Again, I think it’s easy to assume too much about what a reader understands. The mere existence of a widget option does not always, by itself, explain the extent, value, ramifications of that widget, and it certainly should not be assumed to do so.

Making matters more complicated, a lot of the widget help copy is less than clear (saying nothing of properly structured sentences). Writing to people as if they already understand the nature of some wider scope of technology is the wrong approach, and expecting people to read between the lines for the sake of creating short help snippets is also the wrong approach, you (help writers) might as well not even bother (which, humorously enough, is the case in many instances of widget help).

Don’t take me wrong, I’m not attacking or trying to be annoying…people should know me by now. I’m simply probing these issues to improve documentation/writing efforts (such as in TextBook, or whatever) by people who care enough to make them (me for example), but to do that the extent of the functions have to be understood first, and since the internal help is failing to cut the mustard, the questions have to be asked before someone outside of a Txp programmer can fill in the blanks.

I know most of you are busy with coding and figure help is the last hurdle (it shouldn’t be), but I also know Reid is good with a pen; put that new recruit on internal Help detail, and for that matter panel-editing detail too.

As before, your feedback is very helpful and appreciated. I would encourage you from time-to-time to pop into the Site Administration docs to ensure writing efforts there reflect accurate functionality of panel widgets. I’m currently working in the Preferences docs, as you might have surmised. If any of that copy is accurate, use it to fill your Help gaps; it’s a two-way street afterall.

Last edited by Destry (2006-08-22 15:22:05)

hcgtv · 2006-08-22 15:30:46

Mary wrote:

It pings Textpattern.com (just like you could ping Pingomatic). The idea is that at some point, when we’ve got the time to set it up, we can have a “latest Textpattern-powered sites updated”.

On a default install this should be toggled off until a use is found for it. I had to turn this off on all my sites cause it slowed down article entry.

Mary · 2006-08-22 18:17:55

OK, so at the moment this doesn’t work at all, correct?

If “doesn’t work at all” means doesn’t “do” anything publicly visible at the moment, then yes.

Does that mean then (if chosen as yes) that raw PHP can be added to articles too, in addition to templates and forms?

It’s a little complicated because of old versus new behaviour (backwards compatibility). Earlier, you would insert raw PHP and it would be parsed. Later, a specific Textpattern tag was created to be used instead. Rather than completely removing the earlier behaviour, you get a warning that you should be using the tag for it instead. This new preference is a way of enforcing this – not only would you get the warning, your PHP would fail to be executed. It’s useful if you have more than one user with access to publishing articles and templates.

This is the kind of stuff that needs made expressly clear in documentation…no assumptions about what the reader already knows about programming.

There’s no doubt that some of the docs need retooling (or be created…), but no assumptions are made as to what the user’s knowledge level is. This is what the purpose of “Advanced” options is for, in part: things that are advanced, which a user may not be able to grasp. For those, usually the default is “safe” to be left alone entirely, you need not have a clue what they’re for. Those that care about such things usually do know how they work. When they don’t, or it needs clarification on certain points, that’s what the help popup is supposed to be for. And don’t forget: it’s just as easy to overdo it, and give far more words to an explanation than is helpful.

I’m not in charge of help docs, though I do have access to them. As far as I know, unlike the language definitions, the help popup docs are only accessible to the developers. I am pretty sure you need to contact Pedro to discuss adding/refining help texts.

Textpattern CMS

Textpattern CMS support forum

#16 2006-08-15 05:51:57

Re: Admin Panel Edits for 4.0.4

#17 2006-08-15 12:56:23

Re: Admin Panel Edits for 4.0.4

#18 2006-08-16 11:21:56

Re: Admin Panel Edits for 4.0.4

#19 2006-08-17 00:51:24

Re: Admin Panel Edits for 4.0.4

#20 2006-08-17 10:21:46

Re: Admin Panel Edits for 4.0.4

#21 2006-08-17 14:16:01

Re: Admin Panel Edits for 4.0.4

#22 2006-08-17 16:08:33

Re: Admin Panel Edits for 4.0.4

#23 2006-08-17 19:45:16

Re: Admin Panel Edits for 4.0.4

#24 2006-08-19 11:02:03

Re: Admin Panel Edits for 4.0.4

#25 2006-08-20 21:54:30

Re: Admin Panel Edits for 4.0.4

#26 2006-08-21 10:41:45

Re: Admin Panel Edits for 4.0.4

#27 2006-08-22 01:52:54

Re: Admin Panel Edits for 4.0.4

#28 2006-08-22 15:19:28

Re: Admin Panel Edits for 4.0.4

#29 2006-08-22 15:30:46

Re: Admin Panel Edits for 4.0.4

#30 2006-08-22 18:17:55

Re: Admin Panel Edits for 4.0.4

Board footer