Wednesday 17 March 2004 2:42:36 am

Looks great.

If you are moving to a wholly css layout which version of xhtml are you targetting? Will it be transient or strict? Will the templates for the online editor also be updated?

the other suggestions you have for different ways to lay out things probably need an image, just to be complete.

should 'browse' be a logical state? i think of browse as a function that fetches something my current object/class needs, which is just a file selector.

paul

Wednesday 17 March 2004 6:20:12 am

Thanks for posting the message, it is greatly appreciated!

I would really like to see more information on the changes involving CSS. Specifically, I think there is a lot of room to tighten up the current style sheets. I have also seen many attempts at providing themed or skinned sites and feel it would be good to see your planned approach as there are a lot of pitfalls when moving in this direction. Naming conventions for Classes and IDs as well as proper use of the cascade can have a long term impact on the (re)usability of these templates. It would be great to see the stylesheets and their associated template code for critiquing.

Please do not get me wrong, I think it is the right way to go (I am a big CSS advocate), I just want to ensure it is as smooth as possible once complete.

Cocerning XHTML: I would recommend a two phase time line, start by using Transitional, and after several release cycles move to Strict. While I am trying to stick to Strict in my projects (as is Paul), I think it would introduce a lot of confusion among developers who are not familiar with XHTML. That confusion could cause a lot of small problems to pop up in their sites, causing them to lose a lot of time. In addition, moving to Strict will cause several major changes to be made to templates. For example, <i>border</i> needs to be removed from the image tag.

Like my post below, it is important to list out the supported browser/OS combinations as there are a ton of issues that will come up when working with CSS.

Alex

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

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

Wednesday 17 March 2004 6:46:32 am

<b>Main Menu</b>
Custom: I really think it would be nice to allow the user to denote one or two Custom tabs. A Custom tab would be like a bookmark that is always visible at the top of the screen. Give the user a little more control over the interface to make it easier for them to go to their most commonly visited areas within one of the other sections.

<b>Main Menu Labels</b>
<i>"Content structure" instead of "Content"</i> - I prefer "Content" as this section is more than just the strcture. I don't see a need to make the name longer.
<i>"Library" or "Media library" instead of "Media"</i> - I prefer "Media Library" as the addition of "Library" should make it more clear to new users. This section has been confusing for a lot of people.
<i>"User accounts" instead of "Users"</i> - I like "User Accounts" or perhaps "User Management"/"User Manager"
<i>"My account" instead of "Personal"</i> - I like "My Account"

Alex

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

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

Wednesday 17 March 2004 9:39:20 am

hi,
theese are two suggestions for class editing area in the admin interface.
In my opinion it would be useful to choose how many options will have a ezEnum or a ezSelection datatype when creating it. With this functionality you won't need to click "new option" and reload the edition every time you enter a new option, you'd be able to add several option fields at the same time.
In the same area, it would be useful to be able to choose the position of an attribute directly with a number, so you don't need to use "up" and "down" lots of times when editing a large class.

of course, theese are just some ideas, please discuss them if you don't like, bye!
albert

Wednesday 17 March 2004 10:47:10 am

<quote>
This tool will consist of a button and a read-only input field. When the button is pushed, the interface will enter browse mode. The user will be able to browse the tree in order to select a single node. Final actions: "OK" or "Cancel". Back in edit mode,
</quote>

I dont like this "enter browse mode" when editing content. Confusing for most/new users.

Please consider this scenario:
- when the button is pushed:
possible soluction 1 - opens a popup with the structure tree. the user can choose <strong>one or several nodes</strong>. clicking ok, the popup closes and generates the links.
possible soluction 2 - instead of popup, the right panel shows the struture tree (in a DIV/iframe/whatever).

axel

http://AlexandreCunha.com

Thursday 18 March 2004 4:09:40 am

I think konqueror in KDE should also be officially supported under *nix/BSD

http://liucougar.scim-im.org
SCIM Input Method Platform
http://scim.sf.net
SJSD Online Editor
http://sf.net/projects/sjsd

Friday 19 March 2004 2:58:51 am

Hi

I have a need for moving multiple users/content at once, I also sometimes need to relate several objects. For instance, check 5 users, then move them all to a new destination. I think this would be very nice for sites having various privileges to various usersgroups.

In addition I sometimes have problems if I want to change the content class on my site. For instance I have an News_folder having 60 news articles as children. Then I want to reorganize my News into something like this:

Folder
Board news (news folder)
News for all (news folder)

New I need to move ALL children away from the news_folder then delete it, create an object of a folder class and then add all the children to new respective sub news folders. Here a mulitple move would be very nice.

Cheers
Tore

Sunday 21 March 2004 8:47:51 pm

My client helped me select eZ for our project simply because it provided the most Section 508 compliant CMS tool (that met all of the other requirements). For those not familiary with US laws, this has to do with accesibility of websites for assistive technologies. Many otherwise good CMSs use interface tricks, scripts, DHTML and other non-accesible technologies which make it less attractive to my government client.

The move towards more CSS/XHTML is great, but I think the public sector market would really open up for eZ if accessibility of the admin interface could be considered during this process. We could not find any other products that provided this when we looked just a few months ago.

The main thing would be to not use script for any essential functions. Enhancing the interface with these features can be useful for the majority of users, but if any functions depend on them entirely, it breaks the tool for those who use assistive devices.

Another interface note - make sure that whenever possible, it allows users to hit the back button and actually reach their previous page.

Its great to see such a well thought-out process underway!

http://www.thinkcreative.com
Turning Ideas Into Strategic Solutions

Wednesday 31 March 2004 12:57:51 pm

<i>First of all I'll thank you for improve your excelent product for all your users comfort! and thanks for let us (your users and partners) to tell you our suggestions about the new Administration Interface. I have a suggestion and a question:</i>

<b>1) Suggestion about Javascript:</b>

I'm totally agree about 'not misuse Javascript to make a "fancy/flashy" GUI'.

As ez Publish is not only a CMS but en excellent framework, I ask you to inlcude an coherent Javascript API in order tu implement all the dynamic functions of the new Administration Interface.

I think that this API will simplify you the development and it will serve us as a javascript framework for custom development over the ez publish CMF.

There is a lot of Javascript API. The most stable, fast and complete one I saw, and the API I recomend is Dynapi. It's all object oriented and open source. You can found it at http://dynapi.sourceforge.net/dynapi/

I think that it's impossible to use this kind of heavy javascripts API for the end-user site, but I think it can be very useful for the administration interface because it can be cached at the client browser.

<b>2) Questions about possibilities of extend the Administration Interface:</b>

I think that right now, with the version 3.3, it's quite dificult to modify the Administrator Interface because if I change or overwrite the default admin templates I can have problems to upgrade it to futures versions.

Can it be possible to include some kind of pre-fixed hooks at the code where we can include new-version-safe new functionalities?

What do you mean at the news when say: "Upgrade/update/extend the GUI (by making use of classes, etc.)"?

Thanks, Cesar.

Thursday 15 April 2004 8:14:18 am

Hi,
All comments so far didn't really focus on the usability part of the new interface. I will try to add my 2 cents by stepping through the document with the focus on usability.
Starting with the eight goals (Create a consistent ... etc) formulated, I'd rather restructure these usability goals in general and more specific ones:
<b>1) Consistent </b>
interface/framework
<b>2) Easier (smoother)</b>
navigation
editing/publishing
use of images and links
<b>3) Intuitive (smooth out learning curve)</b>
<b>4) Reduce information load</b>
create well arranged layout

Additionally, guidelines like these http://www.useit.com/papers/heuristic/heuristic_list.html might be helpful for evaluation of the new interface/framework.

<b>Logo/banner</b>
The search mechanism contains two radio buttons, so users are able to instantly narrow down their search. Although this function can be very useful, it directly conflicts with the 3th and 4th goal, smooth out learning curve and reduce information load: at least the first time a user wants to search for something, he needs read the text next to radio buttons, think about what the text means and decide whether he should click on one of radio buttons. Certainly, most of the users can perform these steps in just a second, but adding such functionality will increase the complexity of the interface while it benefits only a small group of users. And many of these useful functions will require many seconds (and effort) of the user.
As an alternative for the radio buttons I would suggest to group the search results or show links to filters on the result page, for example. (I'm sorry for the crappy layout, try the search engines on microsoft.com and apple.com to roughly see what I mean)
<b>Grouping search results:</b>
Results in another_sub_node:
1. blabla
2. blabla
3. blabla...
[link]more results in another_sub_node
Results in all content
1. blabla
2. blabla
3. blabla....
[link]more results in all content

<b>Search results with filters:</b>
Seach results
1. blabla
2. blabla
3. blabla....
[link]results in another_sub_node

Basically, the 'filter mechanism' is moved to the result page. But by using one of these methods, the radio buttons are not needed, which will cleaning up the main interface. Secondly, if the search results are good, the user doesn't need look at the 'filter links', because he already satisfied his goal (finding a certain item)

<b>Main menu</b>
The old labels are somewhat confusing. Especially 'media' and 'content', because media can be content and content can be media. The suggested labels are much better, but also longer. To keep it the labels as short as possible it would suggest to use 'content structure', 'library', 'users' (next label suggests it's about user accounts), 'my account' (very common used terminology)

<b>Location/path block and Left bar</b>
A major problems of browser interfaces is the risk of 'getting lost' in the huge amount of information. At some point a user of the interface will ask himself 'Where am I? How can I get to... What am I doing here etc.'. The excellent pretty names in ezp-urls provide some clue about the current location, but using the browser url for navigation isn't very comfortable. The url can't be easily edited by hand for example. In other words: the location block is a good idea.

<b>Main area</b>
no comments

<b>left/right bar</b>
Creating both a left bar and a right bar, will take a lot of horizontal space on the screen. Leaving only a small portion left for the real content (in the main area). Users with a small browser window or a low screen resolution won't have much 'main area' left. In practice, lots of people (with a non-it profession) are using a small browser window. (800x600 or so)
Secondly, adding two bars conflict conflicts with goal nr 4: reducing information load. Is all this information really needed? Every single feature that is added to the bars, will clutter the interface and distract from the main tasks. (posting a news item, adding a user etc.)
I would suggest to use just one bar (on the left) which can be customised. The default (the not customised) version of this bar should only show a few information items. There are several ways to create a bar which can be customized, for example with expandable panels (like in XP explorer), tabs (gnome nautilus) and/or via a menu settings. This mostly depend on how much javascript magic is used.

<b>contents of (left/right) bar</b>
Generally, it would be the best to focus on limiting the amount of information shown in the bar. Most users probably aren't interested in seeing the creation date, modification date, review date ... every single time they access an object.
For sake of consistency with other websites (goal 1) the logout button should preferably be located somewhere in the upper-right corner.

<b>Advanced and simple mode</b>
There have been conducted several experiments with different interface modes/user levels. Most of the interfaces failed. Some of the problems are:
*The interface is not consistent (goal 1)
*How do you know what kind of user you are? (not intuitive, goal 3)
*It's often used as an excuse to litter the most advanced interface (goal 4)
In other words: please don't implement this. As an alternative, 'profiles' could be used, possibly in combination with roles. Like computer administrators can strip windows/gnome/kde for use in internetcafe's. Because the admin knows exactly what a certain group of users, news editors for example, are allowed to do he can strip down the interface to not show and disallow certain features.

<b>footer</b>
no comments

<b>content class icons</b>
Icons enables people to recognize certain elements in the interface. (consistent, easy, intuitive). I suggest to use a generic icon for missing icons. A question mark might be interpreted as if something is wrong with the object.
Naturally, the icon-class associations are stored in a ini file. But since administrators might not want to spend days on investigating ini-files, I suggest to create a UI for this.

<b>Logical states/modes</b>
The different logical states seem to be fair. However, for sake of consistency the appearance of the interface should indicate 1)what the users is doing (what state) 2) what he can do next (confirm selection/cancel action). Be sure the user can't accidentally mix up different states.

<b>Navigation mode</b>
The functionality of a folder tree has some overlap with the location bar. I suggest not to show it at as default (goal 4). A tree can be very useful, but it requires lots of screen space to avoid horizontal scrolling. In usability-land, horizontal scrolling is generally considered to be A Bad Thing (c)
[The usability of the contents of the main area depends a lot on the actual implementation and design. Therefore, I will not comment on it now.]

<b>Javascript in the UI</b>
I'm convinced that if technology can solve a usability problem, it should be used. Creating cross-browser compatible javascript and non-javascript alternatives can be very difficult, but the result might prove to be very easy to use for end users. And that happens to be one of the interface project goals.

<b>Edit</b>
Generate link feature: This feature requires end-users to understand XML! I strongly suggest not to implement a link feature this way. It not easy (goal 2) for end users to understand a low-level computer language. If javascript is going to be used, it should be used here, to hide the XML.
I'm not judging ez systems business model, but from usability point of view something like the online editor shouldn't be optional.
The procedure described for adding/relating objects to a current object is a nice example of how to create an easy to use interface: the software makes it easy for you by automating predictable steps. (goal 2)

<b>Some general remarks on features in the main area:</b>
- Be sure extra features can be found (goal 3). Intuitive also means predictable. If the interface doesn't make it clear how the pop-up menu can be activated, it should also be possible to access the menu items in some other way.
- Use human language. Most people don't see pages, images, sounds as being objects. If UML language can be avoided, it should be. If an object happens to be a page, just call it 'a page'. Imagine what a user thinks when he/she sees this: http://ez.no/i_dont_exist Kernel error? Module not found? Siteaccess name?

Please don't get scared by this lengthy, critical, reply. :-) I think the administration interface proposal written by ez systems is a big improvement over to current one. But still, there a lot of room for improvement left. Hopefully my comments will help ezp filling this gap.
Feel free to ask if I need to clarify some things.