Suggestions for usability improvements in ezp

Author Message

Eirik Alfstad Johansen

Friday 09 January 2004 7:45:38 am

Hi guys,

I'm glad to hear that you are taking suggestions for usability improvements. Here are some initial suggestions from me. These are of course available for discussion, and I hope others will contribute with their suggestions as well.

All suggestions apply to the default admin design.

Consistent placing of checkboxes (for deletion), preferably on the very right. The column containing the checkboxes should be labeled "Delete".

Consistent labeling of Remove buttons. Som are labeled "Remove" while others are images of a trash bin. A text button is prefered. Also, "Delete" is a more common term than "Remove". Finally, consistent placing of the "Remove" button, preferably right below the column containing the delete checkboxes.

The text "Create new object (of the class): " should prepend the drop down list for creating new objects.

The "Update" button which is displayed when a node uses sorting by priority (as well as in templateview view of the setup module) should read "Update priority" to make it clear exactly what it updates. Alternatively, the priority column should be replaced with arrows pointing up and down to easily move an element up and down in a list. This would also make the sorting more consisten with the sorting functionality in the edit view of the class module.

Template should be better grouped and sorted. Finding a template that's not on the "most common templates" list is a true hassle. I have yet to find out how the complete template list is sorted. Also, I would prefer to have the most common templates list replaced with a list that actually contains the templates most commonly edited by me (and not the ones selected by ez). Alternatively, the latest edited templates, like the list that has been implemented recently for classes.

The templatelist view of the setup module should be redesigned to recemble the default node line view list. This would include elements like "Edit" and "Copy" buttons for each template. Furthermore, I don't know the purpose of the design resource column. Finally, I would like to have the option of naming templates in a more descriptive manner.

The text "Select site design" should prepend the drop down list of available site designs in the templateview view of the setup module. If only one site design is available, the selection list should be hidden.

The button "Create new" in templateview view of the setup module should be labeled "Create new template".

When one creates a new template with the same name as an existing template, one should be warned before the existing template is overridden. The warning should include a button to select overriding the template, as well as an input box and a button to allow giving the new template a different name.

In "view" view of the "content" module there are two drop down lists; one to create an object under the current node, and one to create an object, upon which you have to choose a placement for the node. Consider removing the latter as I think it causes more confusion than usefulness. When creating a new object, I belive it's customary to start by navigating to the node under which one plans to create a new node.

Buttons, which purpose is to create a new element (either a node, a template, a class or a placement), should be moved to the top (above the list) when displayed in conjunction with a list. The reason for this is that creating a new element does not directly apply to the elements in the list (as apposed to the "Remove" and "Update" buttons which should remain below the list).

The magnifying glass under "Associated objects" in edit view of the content module should be replaced with a button labeled "Browse".

When viewing a node or a class, one should have the option of creating a template specific to that node or class. When selecting this action, one should be able to select which template to use as a basis, and which additional conditions that apply (like selecting a specific section in addition to a specific class).

The translations have a create potential for improvements. For instance, for somethng as common as the template views of the setup module, most terms are not translated to the selected language. If there is to be any point in providing language packs, maintaining these needs to be a top priority.

Consider having the content classes renamed to the the primary language selected upon installation when first installing the distribution.

Consider renaming the term classes to "content types" as such a name better describes the purpose for a non-programmer. Node is also a vague term for a non-programmer, but I have no better name suggestion for this element.

When clicking the buttons "Bookmark" or "Keep me posted", one should be informed that a bookmark has been added or that one has been added to the notification list for that specific node.

A new button labeled "Update order" should be created and placed below the placements table in edit view of the content module. The button should update any changes to the order of each placement, and the main placement, leaving the user in object edit view.

The placements table should be placed below the main object edit area to keep the main focus on the object itsself and not its placements. Many newbies will get by without having to alter the placement of an object, at least in the beginning, and having this on top is therefore likely to confuse them.

When editing the access rules for a role, the access roles should be automatically activated after being edited without the user having to hit the "Save" button in the edit view of the role module as well.

I would very much like some feedback one these suggestions, both from the community and the ez crew. Thanks in advance !

Sincerely,

Eirik Johansen

PS. Please ask if any of my suggestions are unclear.

Sincerely,

Eirik Alfstad Johansen
http://www.netmaking.no/

Balazs Halasy

Friday 09 January 2004 8:08:46 am

Great list of suggestions!

Thanks for all the input.
We've also an internal list (well, actually several lists) - and some your suggestions can also be found there. Keep them coming!

Balazs

Alex Jones

Friday 09 January 2004 8:14:43 am

My thoughts on some of Eirik great suggestions. :)

[quote]
The “Update” button which is displayed when a node uses sorting by priority (as well as in templateview view of the setup module) should read “Update priority” to make it clear exactly what it updates. Alternatively, the priority column should be replaced with arrows pointing up and down to easily move an element up and down in a list. This would also make the sorting more consisten with the sorting functionality in the edit view of the class module.
[/quote]

I would actually ask that the numbering boxes be kept and that the class module be changed to follow the same method. As stated in previous threads, I find it really time-consuming to edit the placement of fields for extended classes.

[quote]
Consider renaming the term classes to “content types” as such a name better describes the purpose for a non-programmer.
[/quote]

Renaming "classes" would be a very good move as that word has several meanings for developers as well as non-programmers, including classes that are used with PHP and those used in CSS.

I will try to add some suggestions when I have a bit more time to write them out.

Alex

Alex
[ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ]

<i>When in doubt, clear the cache.</i>

Alex Jones

Friday 09 January 2004 8:15:34 am

Balazs, is there any chance that you could post the internal list for comment?

Alex

Alex
[ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ]

<i>When in doubt, clear the cache.</i>

Balazs Halasy

Friday 09 January 2004 8:24:10 am

There is not one but several lists - some of them in Norwegian and some in English. We'll have to synchronize the lists and go through them. In other words: if they are to be published, they won't be published at this time.. can't give more specific details, I'm sorry.. However, keep the suggestions coming.. :-)

Balazs

Balazs Halasy

Friday 09 January 2004 8:33:53 am

Regarding the "class" term. What about "Data structure" or "Structure definition" - something like that perhaps? I guess that these terms would be more understandable for a non-geeky/non-programmer person.

I've been thinking about this for some time now;
One solution could be to create two admin interfaces: one for power users and one for "regular" users. In this case, the power user interface would make use of terms that also can be found in actual eZ publish code (class, node, etc) while the "normal" interface would use friendly terms such as "data structure", etc. Again, I'm just thinking loud here...

Balazs

Alex Jones

Friday 09 January 2004 9:56:40 am

Thanks for the update on the list Balazs, I understand that it isn't feasible to post it at the moment.

I would recommend that a single set of terms are used throughout the product. Having two interfaces with different terms for the same concept would prove very confusing in short order, especially for those who have to support the non-programmers.

I like Eirik's suggestion of "Content Type" as it is pretty descriptive, though I am open to other terms as well. When you go to edit what is currently called a class you would be editing the Content Type structure, much like your suggestion.

Alex

Alex
[ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ]

<i>When in doubt, clear the cache.</i>

Eirik Alfstad Johansen

Friday 09 January 2004 11:17:42 am

[quote]I would actually ask that the numbering boxes be kept and that the class module be changed to follow the same method. As stated in previous threads, I find it really time-consuming to edit the placement of fields for extended classes.[/quote]

That might be better. The most important thing for me is to keep consistency, meaning that they both use the same method.

[quote]I would recommend that a single set of terms are used throughout the product. Having two interfaces with different terms for the same concept would prove very confusing in short order, especially for those who have to support the non-programmers. [/quote]

Agreed! Also, if we could change classes to something like "content types", there's really no reason keeping the old term as far as I can see.

Sincerely,

Eirik Johansen

Sincerely,

Eirik Alfstad Johansen
http://www.netmaking.no/

Marco Zinn

Friday 09 January 2004 12:09:14 pm

Hi,
great list of suggestions, Eirik!
I agree with all of them, except one:
When updating priorities, i love the new way of entering priorities directly. This should just check for distinct priority numbers, as duplicate numbers must lead to problems with sorting.
One could use the "up-down" arrows additionally to the numbers. When using the arrows, ez should exchange the priority numbers and not set auto-created priorities. Why? Cause i like to "block" priority numbers like 1,2,3, 10,11, 21,22 .... so i can easily insert new objects.
Also, when using arrows, "rollover" must be implemented, so a new object (which currently gets ID 0 and is at the top of the list) can be moved to the "other side" (buttom) of the list with one click.

For the icons: Good icons have some advantages over labeled buttons: The are small (GUI design), elegant and need no translation. But it's hard to find a good, consistent set of icons (for functions).
For icons and terminology question: Let someone check "best business practice".... look at from other CMS software, look from windows, linux, apple, beos GUIs... ;)
Take care of lawyers!

For the type of terminolgy: Please stay consistent in the GUI (admin site),but introduce more "common-language" terms. I like "data structure" etc.
"Classes", "content objects" and "node" are fine terms, when you know them, but don't tell you much, when you are new to ezpublish(3). Again: Look for some widely accepted CMSes. I don't know, if terminology is better elsewhere, but have a look at them.
One Problem will be the Template language: Either template language terms stay constistent with the new GUI terms (-> old template will be broken, backward compatibility is needed and must be maintained for a while) or they get inconsistent with the GUI, which needs even more documentation to get a match between GUI and template language.

Marco
http://www.hyperroad-design.com

Eirik Alfstad Johansen

Saturday 10 January 2004 6:29:11 am

Here's an addition to my list of suggestions:

When hitting the "Preview" button which is included in the default node view of the admin design, one (or at least a person not familiar with ezp) would expect to see the node in full view in the user design.

Knowing how ezp works, however, I know that the admin design (or any other design for that matter) is capable of administrering several designs. So when hitting the preview button, it's not given what design the user wants to view the node in, nor what view (full/line/other).

However, I think a solution could be to show the node in full view (as the default) in the selected design (the same design that is selected in the drop down list when editing templates). Also, if the admin design is set to access only one design, the preview button would automatically show the node as a part of that design.

Sincerely,

Eirik Johansen

Sincerely,

Eirik Alfstad Johansen
http://www.netmaking.no/

Marco Zinn

Saturday 10 January 2004 2:06:02 pm

There is another logical bug around there somewhere in the "preview" or "manage version" context.
At some point, you cannot return to the preview page, you must use the browser's "back" button.
I think, it's on the preview page itself, but I'm not sure now.

One more:
When you published a version, that is messed up (because ezPublish deleted your HREFs or so ;) ), you will want to go back to the previous version.
But, to do this, you MUST "enter" the object in edit mode, which will give you a new draft. There, you will go to the "Manage" screen and select the latest version before the currently published one. You will copy this and publish it. That COPY function will give you yet another draft (which will be published again).
That's one draft to many. You get one draft, just because you MUST enter the edit mode (at the moment). Suggestion: Insert a "Manage Versions" button in the admin interface (just like the "Preview" button)

Marco
http://www.hyperroad-design.com

James Lynch

Thursday 10 March 2005 8:31:21 pm

The "Design Resource" column is a god-send for me, because it conveys the _actual_ location of the template itself.

I have a suggestion/hack for the templatelist too. I didn't find any mention of listing all the templates, so here is how to do it.

1 Go to your template listing (Design > Templates).
2 Browse to the second page of listings ("Complete Template List").
3 If you don't see "/visual/templatelist.tpl" then just keep browsing, or learn to pass it to templateview (in the URL).
4 Create an override, and edit.
5 Find where text is "var=Templates max=20", and change 20 to 1000.

Notes:
In step 4 I tried it first with 2000, did a CTRL-C/CTRL-V to CREdit to count them, voila my version with all options installed (intranet) has little less than 750 templates!

Step 3 was ambiguous, listen here. Just click any template in the list. You will then see "Overrides for <...> template in <...>". Erase averything after "/templateview" in your URL address bar. and paste "/visual/templatelist.tpl" in its place. Now you pick up at step 4.

Oh, my suggestion: There should be a button somewhere to get the entire list.

Gabriel Ambuehl

Thursday 10 March 2005 11:36:54 pm

I would say "Content Type" is a much better term for it even from a programmer's point of view. After all, classes aren't PHP classes, but DB backed compositions of attributes (which in turn are implemented as objects themselves and several levels further down in some cases).

Pet peeve:
- A Create here menu in the dynamic tree menu.
- And of course the template list.
- Versioning of templates would be really really helpful (and to a certain extent, that also goes for INI Files). I know I could put them into SVN but that seems like a lot of work to accomplish it...

Visit http://triligon.org

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.