Admin Panel Edits for 4.0.4

Destry · 2006-08-14 19:29:11

IMAGES PANEL

Just occured to me that each image row in the images panel has the Textile, Textpattern, XHTML link, but when you click either of the three the same code builder pops up with the three options available in a dropdown. 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, and then users just select which option they want in the code builder? Or am I misunderstanding the nature of the beast again?

rsilletti · 2006-08-14 21:04:11

Mary,
I love the work you have done on the <articles – comments> tabs interface, the “manage” link is the best idea yet, my time thanks you, my patience thanks you. The only thing I’ve noticed that you might look at is “view_per_page” at the bottom of the comments tab. I think my last Rev from SVN was 1669.

Last edited by rsilletti (2006-08-14 21:08:42)

Mary · 2006-08-14 21:59:18

Rick: update your language.

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

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

Textpattern CMS

Textpattern CMS support forum

#13 2006-08-14 19:29:11

Re: Admin Panel Edits for 4.0.4

#14 2006-08-14 21:04:11

Re: Admin Panel Edits for 4.0.4

#15 2006-08-14 21:59:18

Re: Admin Panel Edits for 4.0.4

#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

Board footer