Saturday 17 April 2004 6:17:23 pm

As the person responsible for setting up content classes in most of my eZ installations, I think it would be great to be able to offer end user conten administrators some clues as to what each datatype (field) is intended to be used for when they are adding content. This could be accomplished with something similar to the <acronym> tag in HTML. When they mouse over the name of the field, it would offer a tip about what text/info should be entered there.

Alternately, a "?" help icon next to the datatype name could lead to some clues about where the content will be used, and how. This would eliminate much of the training that is required for a custom site built on the eZ framework.

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

Wednesday 28 April 2004 9:46:22 pm

Help files as you suggest is a good idea for those of us who care to learn more, often though, as can be judged by any support forum on the net, people don't use the documentation, nor even the search engine...

They all crave personal attention by a mentor.

--
http://www.vogol.com/user/spdyvkng/blog/

Friday 30 April 2004 11:22:41 am

Tony Wood rightfully addresses the need to take a step back and look at the fundamental issues of the administration interface. Ideally, usability engineering is tightly integrated in the development process of a product. Mainly because the the technical design of a product will depend on the user interface design and vice versa. At this time there already is a fully functional system, and now the administration interface is to be redesigned. This redesign is really needed and it think it's a good idea, but remember a proper redesign might also require painful architectural changes in the underlying system.
Because of the lack of responses on the previous discussions about the new admin interface, Balazs Halasy did a good thing to just publish a concrete proposal. At least there is some discussion right now. However, if we take a step back there are several fundamental questions to be answered first, before an actual design should be created. Some of these questions are:
What is the purpose of the interface? - Why does ez-publish need an administration interface?
Who are the users? - What are their characteristics (skills, roles, numbers etc.) and why should they use the interface?
What kind of tasks are the users going to perform? - What steps need to be taken to complete a task?
What kind of scenarios are possible to happen?
Which interface requirements can be formulated?
Which lessons can be learned from experiences with the previous interface? (As Tony Wood also noted)
Only by answering such questions first, you can be sure you know exactly what you're doing when you're actually designing and writing xhtml code. And therefor, I think the discussion should be on this kind of level first. We shouldn't discuss now whether the radio buttons next to the search field are useful or not. Later on in the process however, we should discuss about whether the related 'search' scenario fits the interface goals, targeted user group and requirements.
Just starting to put buttons, texts and boxes on a page is as structured as starting to code a software program without creating a single flowchart or uml-diagram in advance. Maybe Balazs Halasy and his colleagues already went trough a more or less extensive usability design process. If true, it would be useful if they published some of the documents or a summary of the underlying design. It would certainly take this discussion to a higher level and I would be happy to contribute!

Cheers,
Huib Kleinhout

Saturday 01 May 2004 1:48:16 am

Huib,

<i>I'm not sure whether this it is fair to compare the whole Internet to a single website. Ultimately, one or more admins should have some control over the structure of their website. In my opinion you're not very much of a good administrator if you can't create a proper information structure.</i> (Huib Kleinhout)

I agree, the point was a stretch. I should clarify; the directory structure does work for small/medium amounts of classifiable information. The problem comes when large (1000s) of pieces of information are required. An example of this type of information would be the BBC site http://news.bbc.co.uk/.
I agree again that a good administrator can logically classify information for storage and update purposes. But the real strength of information should be that it can be viewed in the way the "user" chooses not in the easiest storage method. This means that information needs to exist in many locations. So maybe we should classify what folders are; search crtieria based on a category. If we change folders so they can also become searchs. We will then have a more powerful system that enables us to have many pieces of informaiton in many locations without the "location-grind" of adding loads of locations to our articles.

Thoughts?

--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

Tuesday 04 May 2004 12:33:10 am

I must admit I'm not entirely certain how the search on eZ publish works, I tried it just now and "eZ publish" didn't return anything, but "pkej" and "eZTrade" did, unfortunately I don't have a very large eZ publish site with a wide variety of content to test it on, but I'll try to explain what is needed.

Searches are the quickest way to find info on a site. How the search assists you in this is alfa and omega. As this thread has been suggesting filters and searches, I thought I'd just point out how a search <i>could</i> work.

The main idea is to give the top ranked content, and exact matches. If I search for an author (of a book for sale, for example at Amazon) it would be efficient if the search engine placed the author result very high up, especially when it is an exact match. Imdb ( http://imdb.com ) is a site where this is excellently implemented. Amazon ( http://www.amazon.com ) seems to have the same functionality, but in a much more cluttered interface.

Folders aren't entirely a waste, it all depends on how the user perceives the site. For example, Amazon uses a hierarchical layout of their books. Drilling down is easy, and for each sub-category there are more info about news in that section, top sellers, popular authors etc. Unfortunately we don't have access to the usage statistics of Amazon, so we can't know if it is datanerds using the folders, or the user levels of those using them.

That they do exist, and continue to exist, is a good pointer towards what Amazon thinks is best. I usually say "emulate Amazon whereevery you can". It isn't neccessarily the best way to do things, but it is the de facto standard.

What is needed though, and others have remarked upon it, is some actual user testing and reports from them. I'd also like to see some verbatim description of what exactly you guys think about when you say search and filters. How will that impact the site design? How will it impact navigation? How will it impact complexity? I guess it isn't an either or proposition, but I'd like to see some sites implementing what you're talking about in order to better understand it.

--
http://www.vogol.com/user/spdyvkng/blog/

Tuesday 04 May 2004 8:02:07 am

This may be a bit long, please forgive me for re-hashing earlier posts, but I am using this to think out loud and hope people will point out the weak spots in my thinking. :) Paul F. and Tony, as I am re-stating ideas that you were kind enough to provide me, please point out any mistakes I may be making.

<b>Summary</b>
I think in many ways, we as developers and organizers of information get wrapped up in our previous experiences with the structures used in operating systems and on the Web. A "folder" is merely a grouping of objects or data. Nothing more, nothing less. So, what we are doing with folders is presenting the user (both internal editors and external users) with a grouping of objects whose relationship to each other makes sense. The following list of objects will be used for some examples:

<i>Object One</i>
Color: Red
Size: Large
Keywords: Widget, Sprocket

<i>Object Two</i>
Color: Red
Size: Small
Keywords: Schooner

<i>Object Three</i>
Color: Blue
Size: Small
Keywords: Cog, Gadget

We see that the objects <i>One</i> and <i>Two</i> share a color ('red'), while objects <i>Two</i> and <i>Three</i> share a size ('small'). In the past I have used Locations to show that <i>Object One</i> and <i>Object Two</i> are related, by placing them in the same folder: <i>Red Objects</i>. Extending that further I need to show that <i>Object Three</i> is related to <i>Object Two</i> but is not related to <i>Object One</i>. This second relationship has to be accounted for with the creation of another folder (<i>Small Objects</i>), within which objects <i>Two</i> and <i>Three</i> are located. For smaller sites this is relatively easy to manage. But with a large site the organizing of information and objects becomes much more complicated and time-consuming. This is where I am running into a problem. Adding multiple locations to an item takes a good bit of time. Not only do we have to go through the process of adding a Location in the editor, we have to make sure we see all of the possible relationships between items. In the above example we created two folders, but once we move beyond these three items we might have to create more to account for new relationships: <i>Blue Objects</i>, <i>Large Objects</i>, <i>Green Objects</i>, <i>Large Blue Objects</i> and so on. So many, if not most items will be placed in more than one folder. Now the editor has to go through and add the locations to each object. Not only do they have to go through the process of adding the locations in the editor, they have to understand the reason that the item belongs in that particular location. They have to have a deep understanding of the information architecture and the desired groupings. Again, this is easy with a smaller site which may have a simple structure, but if the site has hundreds of objects this can grow very complicated.

<b>Possible Solution</b>
Much like the concepts of Folders, the term "search" implies that the user is specifying the terms. But there is no reason that has to be the case. We as site creators, can set up pages that display the results of pre-defined searches: display all <i>objects</i> with 'red' as the value of 'color'.

By using searches I hope to get around the need to explicitly state that objects <i>One</i> and <i>Two</i> are related by the use of a Folder or Location. Rather, I would set up a page that presents a search that is filtered to only look for objects of a specific 'color' (in this case 'red'). So, if I add 10 more objects to the site, any items that have 'red' as their color will automatically be included in the search results. As long as I have defined my objects correctly, and filled in all of the information, I will not need to spend any more time categorizing them by adding all of the possible locations to each one. I will simply have a page that fetches and sorts the items that I want to display.

Now let's say that I add the word 'Widget' to the 'Keyword' field for <i>Object Three</i>. I now have a new grouping of <i>Object 1</i> and <i>Object Three</i> without creating a new folder or assigning another location to either object.

This method allows us to harness the strength of search (finding everything that is related, filtering out that which should not be displayed) without losing the strengths of folders (categorization). The displayed results do not have to look like search results, they can look however we want them to. The site design and navigation have just as much flexibility as they would if folders were used. Perhaps more, as we can create new categories very quickly without touching the data. It takes less time to add a fetch that filters on an attribute than it would to add hundreds of objects to a new location. And, if my understanding is correct, the upcoming implementation of view_parameters (http://www.ez.no/community/bug_reports/view_parameters_only_works_with_offset), will allow us to construct new views via URL, so we won't even need to create new fetches. The new category could be created purely by linking to it (http://mysite.com/my/friendly/path/(viewvariable1)/value1/(viewvariable2)/value2/)

All of this doesn't negate the use of a general search, so the user can still use the search engine to find what they want using their own terms.

<b>Additional Benefit</b>
By using this method we may begin to see relationships that may not be obvious from the outset.

I hope this makes sense. It needs to be refined, but it is a start.

Alex

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

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

Wednesday 05 May 2004 11:58:14 am

Small nitpicky item:

on the Editing class page, can the datatype dropdown list box items be sorted by alpha?

Thanks,
Sharon

Thursday 20 May 2004 9:43:14 am

I hope this links are userful for you:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/iuiguidelines.asp
http://www.carlsononlinedesign.com/inductive.htm

I suggest to rethink the Administrator Interface from a standard Content Manager Interface to a Task oriented interface.

The end-user, who frequently adds and changes contents to the site, doesn't know about nodes and folders. He knows about thinks from he work universe. For example add a new product to the site database.

C.