Forums / Suggestions / Usability: Suggestions for using "non-technical" speak within ez3

Usability: Suggestions for using "non-technical" speak within ez3

Author Message

Georg Franz

Saturday 22 May 2004 7:36:39 am

Hi,

as you know ez3 is a very "abstract" system. And there are some phrases within the cms which causes understanding problems for non-programmers (the "normal user").

I've made many trainings and know the main understanding problems at least for the german-speaking people.

So, some suggestions to make the cms more user-friendly:

a) "content object":
If you say "content object", a normal user don't know what is meant by that.
My suggestions:
Use "item" instead of "object" (you do that already in some cases)
Don't use "content object" and "object" but:
-) "item (like an article, image, folder etc.)" or
-) use the class-name instead where it is possible
-) "related objects" => "related items"
-) "default placement for objects" => "default location for new items"
-) "new objects will not be placed in the content tree" => "new items have no default location and won't be shown within the content tree"
-) "new objects will be placed in %nodename" => "new %classname will be placed in %nodename"
-) "create or browse objects" => "create a new item or choose an existing item from the tree"
-) "object count" => "number of items"
-) strip off "content object" where is no need for that phrase like:
"the content object %1 awaits approval ..." => "%1 have to be approved by you"
-) "Edit the object" => "Edit" / "Edit %object_name" / "Edit %class_name"
-) "Replace object" => "Choose another item" (some users thought that the content of the choosen object will be replaced and not the relation link)
-) "Remove object" (in design/standard/content/datatype) => "remove relation to choosen item" ("remove object" is very confusing because the user thinks he is going to delete that item)
-) "The object is owned by %owner" => "%object_name is owend by %owner"
-) "Default object view" => "Default view" (there is no need for "object")

b) "Node":
For a programmer, the meaning is clear. But you have to explain it to a normal user.
My suggestion is: A "node" is a "location" within the content-tree.
Furthermore use the name of the node instead of "node" where it's possible.

Example:
"Are you sure you want to remove %1 from node %2?" =>
"Are you sure you want to remove %1 from %2" (there is no need to use "node" in that case.

"Removed nodes can be retrieved later. You will find them in the trash." => That needs further explanations.

Example:
"Deleted items can be restored. They will be moved into the trash." (Don't use "node" in that case because a normal user will never understand the difference between a "node" and an "object".)

c) "children / parents"
At my trainings I earned a lot of laughter if I sayed: "Ladies and gentlemen, now we are gonna to delete our annoying children!" :-)
The parents weren't amused ;-)

So, my thoughts about that - difficult - issue: You can't use "child/children" or "parent/parents" - it's too confusing.

My suggestion: Give a longer description about what's going on, example "trash-page" / "deleting process":

Say something like this on the confirm page of the deletion process:
"If you delete %name_of_the_object, all content of %name_of_the_object will be deleted too.
Further details: %number_of_nodes items are placed beneath %name_of_the_objects. %number_of_items_which_has_no_other_location items will be deleted permanently."

So you can avoid using the term "child/children" ...

"Parent": Try also to prevent using "parent".
My suggestions:
"choose parent node" => What is meant by this?
Choosing a location for the current item.
So "choose a location" will do the job.

"select parent node for new node" =>
"select a location for %node_name"

"select parent node" => "select a location for %node_name"

"you must assign all nodes to new parent nodes" =>
"you have to assign all importet items to new locations"

"choose a node for default selection" =>
"choose a location from where items should be selected"

d) "object relation" and "object relation list" (datatype):
That is confusing because you are using "wrong words".
It's an "object assignment" and a "list of object assignments".
But that's to technically for the user interface.

So, my suggestion:
Prevent the usage of "assign/relation" and say it with other words.
e.g. "Choose an existing item"

e) "placement": replace that with "location". (Or - if you like "placement" more, replace "location" with "placement".) -> the same for "node" (so if you use "location" for "node" you have to change "location" to "placement" in that case too)

f) "Node ID" / "Object ID": display that technically items with font size 1.

g) "Publish" / "Post"
That's very confusing. Sometimes it means "save" and sometimes it means "send for publishing".

Okay, I don't want to rename eZ Publish to eZ Save ( ;-) ) but there are some cases where "save" is the better word.
Example: If a user creates a new account, he want to "save" his data and not "publish" it (he may thinks that he is providing his data to public)

Also use "publish" instead of "post" at a forum message. (If it's the same action, use the same word)

h) "Cancel" / "Discard": These words have the same meaning, so use only one of them. (I think "Cancel" is the better word - same action / same word)

i) "Remove" / "Delete"
Small words / big impact:
At some cases "remove" means "delete" and vice versa. Our users are really confused.

So, my suggestion:
Only use "delete" if an item (content object / node) will be deleted (moved into the trash).
Only use "remove" if you "remove" a relation / assignment / bookmark (etc.)

Kind regards,
Emil.

Best wishes,
Georg.

--
http://www.schicksal.com Horoskop website which uses eZ Publish since 2004

Alexandre Cunha

Tuesday 25 May 2004 11:32:29 am

Hi Emil,

I thing your suggestions are great and their deserve some feedback from the community and eZ crew.
Maybe add your sugestion to the Bug Report as a sugestion.

These sugestions maybe can be included in and related to the discussion about the "Admin Interface Project".
See more:
- http://ez.no/community/news/the_administration_interface_project
- http://ez.no/community/forum/suggestions/administration_interface_and_gui_improvements
- http://ez.no/community/forum/suggestions/the_administration_interface_project

I thing the Admin Interface needs a serious re-thing and re-design and a "end user point of view" for the Admin Interface, is a great idea.

thanks

axel

http://AlexandreCunha.com

Georg Franz

Tuesday 25 May 2004 2:23:56 pm

Hi Axel,

thanx!

I don't want to post it within the bug report, because - I think - this topic needs more feedback.

The main problem of this topic is:
If the developers of ez agrees to some changes of some phrases they have a lot of work with changing them in the templates. And that's not a sophisticated programming work but a "stupid job done for people who would never understand how difficult it was to program that wonderful system".

(ez crew - I hope that you know what I am meaning - it's ironic).

Kind regards,
Emil.

Best wishes,
Georg.

--
http://www.schicksal.com Horoskop website which uses eZ Publish since 2004

Aleksander Farstad

Wednesday 26 May 2004 12:21:10 am

Hi community,

We do see your posts, and there are lots of great ideas and inputs here, like these regarding the naming. Up untill the summer conference and the 3.4 release, we do however not have much time answering these forums. But we do of course see them and we will sum it up and give you feedback. And most importantly they will give us great input on how we can improve eZ publish.

Aleksander

Tony Wood

Wednesday 26 May 2004 12:26:27 am

Emil,

I like where you are coming from. The language used in the site is more developer friendly than it is user friendly. I think a change in some terminoglogy is required but the type of language used may differ from situation to situation. So if we are changing the language; what would you say to there being an ini file that contain the terms and their "user friendly" variants.

terms.ini
object=item
remove=delete
object relation list=relation list

This would enable people to set the language based on their needs. Of course the standard language would be the default as this is required to help new developers uderstand how eZ hangs together.
The site admin could change the language for the users based on their needs language etc.

What do you think?

tony
--
http://www.visionwt.com

Tony Wood : twitter.com/tonywood
Vision with Technology
Experts in eZ Publish consulting & development

Power to the Editor!

Free eZ Training : http://www.VisionWT.com/training
eZ Future Podcast : http://www.VisionWT.com/eZ-Future

Alex Jones

Wednesday 26 May 2004 7:54:27 am

Great post Emil. Your points make a lot of sense in the grand scheme, and I really hope the folks at eZ systems give this thread the attention it deserves. Here are some of my thoughts.

<b>Item vs. Content Object / Location vs. Node / Parents & Children</b>
The use of <i>item</i> instead of <i>object</i> or <i>content object</i> would be a good move. The word is generic enough to apply to every object, whether it be a product, an article or an image. The same can be said of <i>location</i>. While we as developers understand that the data isn't tied to a single spot, the common user/editor still views the information within the site as having an intrinsic place within a structure or hierarchy. Replacing the use of <i>parent</i> and <i>children</i> with the appropriate location or object names follows this same pattern and would make it much easier for the common user to understand what is happening.

<b>Object Relation</b>
I agree that using both <i>object relation</i> and <i>object relation list</i> list is rather confusing. It is another instance where the same word or phrase is given two meanings (which I've brought up previously). While these two have some similarities, I think they prove confusing for new developers. But, I do not know what to use instead. I think it is important to keep the idea of relation within related objects, though not necessarily within the ORL.

<b>Placement vs. Location</b>
I would choose <i>location</i> as the better word.

<b>Post vs. Publish</b>
For the most part I agree, though I actually believe <i>post</i> is the better word for the forum templates as it is consistent with other forum packages that users may encounter.

<b>Cancel vs. Discard / Remove vs. Delete</b>
I agree, <i>cancel</i> is the better word and the usage pattern Emil provided for <i>remove</i> and <i>delete</i> make sense.

<b>Tony's idea</b>
While I am a big fan of flexibility I think providing the ability to modify the terminology would lead to additional confusion. The biggest problem right now is the fact that the terminology doesn't always make sense. Adding another layer would only multiply the possible confusion, especially in the future. The developers and users would be speaking two different languages when referring to the same information or item. Down the road, if a project is passed on to a new developer, they may very well grow frustrated when searching for a term on the eZ publish site, not knowing that the search phrase isn't the standard terminology. Add to that, searches on these forums would become less effective over time as that same standard terminology might be used less in posts. I believe that we would be better off in the long run, were we to keep with a single set of modified terms.

Alex

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

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

Tony Wood

Wednesday 26 May 2004 10:22:04 am

I hear what you say Alex. But we alrady have a lot of code in templates and extensions and changing them would take extra time on an upgrade. Testing etc.

You also have the additional problem that programmers and users use different language. I personally like the term object.. as it "says what it is on the tin". In the same why that we seperate data from display we should seperate programming terms from user terms.

I agree this could lead to future problems... maybe if we could come up with a terminology that worked for both camps?

--tony

Tony Wood : twitter.com/tonywood
Vision with Technology
Experts in eZ Publish consulting & development

Power to the Editor!

Free eZ Training : http://www.VisionWT.com/training
eZ Future Podcast : http://www.VisionWT.com/eZ-Future

Alex Jones

Wednesday 26 May 2004 12:37:53 pm

I see your poitns Tony. Ultimately, I don't have a problem with two sets of terms, but what I would like to avoid is providing the developer the ability to create their own terms. It makes sense to call it an <i>object</i> when speaking to developers and an <i>item</i> when speaking to users, but it could get really confusing if a developer decides to add a third term for the same thing. Extending the vocabulary would prove useful if it is done in a centralized manner. I'm not sure if I am getting my poitn across... Well hopefully so! :)

Alex

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

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

Georg Franz

Wednesday 26 May 2004 2:03:20 pm

Hi,

just two suggestions for future versions of ez:

-) give the possibility to provide two dictionaries (translation.ts files):
*) one for the ez standard terms
*) one for the "user-site" terms

The user-site dict. should be used first, if the string isn't found, look at the standard-dictionary. (Similar as the ini-system of ez)

So this would be great for mainly two reasons:
-) You could easly maintain the "standard terms" of ez and separate them from your specific site-terms
-) You could use an own dictionary for each site-access

-) And - please - don't make english (eng-GB) as - hard coded - default language in future versions. Reason: It can happen that the translator hardly understands english but the current main language of the site. Example: I've made a german site which should be translated to the slovak language. The translator is doing well with german but hardly understands english ...

<b>Developer speak / user speak</b>
I think it's necerssary only using one term for the same thing. (Don't mix "object" and "item") - otherwise it's confusing.

Kind regards,
Emil.

Best wishes,
Georg.

--
http://www.schicksal.com Horoskop website which uses eZ Publish since 2004

Paul Forsyth

Thursday 27 May 2004 2:36:42 am

I wonder if eZ should follow the example set by the mozilla foundation, and set up both a developer and consumer version - mozilla and mozilla firefox/thunderbird/sunbird etc.

eZ publish 3 is largely a library, with a good set of designs. I think this should continue for it allows the developers to do what they do best.

At the same time consumer designs/terminology could be developed to address all manners of usability issues.

For this to work there needs to be a strong relationship between developer and consumer versions, with each driving the other in terms of library functions and necessity.

Resourcing the consumer version may require that the project be a pubsvn project, with commits allowed from people outside eZ.

Conference subject perhaps?

Paul