Can eZPublish 3 > ever be userfriendly?

Tuesday 24 June 2003 6:51:41 am

Hi,

For those of you who haven’t seen it, eZPublish 2.2 and 3.0 were just recently compared in an article over at SitePoint. Check it out if you've got the time:

http://www.sitepoint.com/article/1157

At first, I thought “What a strange thing to do: comparing an old and a new version of an application. Of course the new version must be better”. But after having skimmed through the conclusions of the various chapters, I understood the reason for the discussion. As the article author concluded, and as I’m sure many will agree, version 2.2 is more userfriendly, while version 3 is more powerful and cusomizable.

Though I've seen some usability improvements in the beta of v. 3.1, eZP still has a long way to go before it will be as userfriendly as the old version. That is, if that is at all possible.

The way I see it, the greatest advantage of v. 3 is also its greatest disadvantage, meaning the flexible structure upon which it is built.

To achieve full customazation, the eZP developers had to rethink the entire application structure when developing v. 3. They couldn't call a hammer a hammer and leave it at that. For the structure to be expandible, they had to say that the hammer was a kind of tool, and that a tool is a kind of thing.

If you are a seasoned web developer/programmer, you are of course familiar with this way of structuring information, and most of you would probably argue (myself included) that this is the best structure for an application like eZP, having taken growth and expandation into consideration. The problem is, however, that ordinary people (read: non-programmrs) don’t think this way.

Ordinary people are used to seeing hammers and thinking that they are great for hitting nails and other objects that need hitting. A programmer, on the other hand, would see the hammer, but instead of labeling it “Hammer”, he would put it in a box labeled “tools”, and put that box in an even bigger one labeled “things”.

I’ve been confronted head-on with this different way of thinking while considering customizing eZPublish (3.x) to work as a general purpose CMS for a non-programmers. Recently, I’m starting to question if that is at all possible. I don’t think I’ll ever be able to convince my mother (or the other people that will be using the software) that an infopage and a product are actually two pieces of the same pie, namely the “Class Pie”.

I do realize, of course, that this aspect of programming doesn’t apply to eZP alone, but rather programming and development in general. Still, I would like to know the thoughts of the ez community on this subject, and most of all, the developers.

Thanks in advance for joining the discussion!

Tuesday 24 June 2003 8:20:32 am

Hi Karsten,

Thanks for joining the discussion. If I may, I'd like to comment some of your statements.

[quote]
Now, here is my answer to your opening post. First and foremost, I think eZ publish will always be targeted at programmers-at-heart and not at what you could call "WYSIWYG" admins. There are different CMSes for different purposes and this is good. The fact that you have at one point considered modifying eZ publish to be a general purpose CMS shows that it _does_ appeal to you and many others. The open data structure and framework type flexiblity is appealing and encouraging.
[/quote]

Yes, eZPublish has appealed to me. At least inititally.

However, having examined the app more closely these last couple of weeks, I'm having a hard time trying to understand where modifications are appropriate. You have, of course, the layers very close to the surface like the templates and the settings-files. But let's say that I downloaded version 3.0, and found out that creating new content objects was less than intuitive. So I decided to modify the message that appears when I have selected a content class and clicked the "New" button.

Now, had I done that, I'm guessing that my new message would have been overwritten in v. 3.1 where this message has, in fact, been modified to a more userfriendly message. Or wouldn't it?

This is where I tend to loose my grip: which layers can be modified without suffering new-version headaches.

These are of course not valid considarations for WYSIWYG admins, but while I'm at it, I'd like answers to them all the same. :)

[quote]
The fact that you like many others have discovered that in its current form it is not user-friendly for those that come from a non-programming background does not mean that it cannot be at some point in the future.
[/quote]

But don't you agree that the structure upon which the new eZP is built, makes it hard to create a userfriendly interface?

[quote]
However, I'd like to add that for me, I probably would not spend much time in this, as there are easy to use open source CMS out there that probably would appeal to the user group you are referring to.
[/quote]

Any suggestions that I should consider?

[quote]
I believe that one should not try to do all in one. You could start a different project that uses eZ publish as its base and pops user-friendly extensions and wizards on top of that, much like what the Windows GUI was in DOS times [...]
[/quote]

That's sort of what I'm planning to do, but I don't want to program myself away from the possibility of having the kernel and other fundamentals of eZP upgraded. But then there's these darn layers again... :)

- Eirik

Saturday 28 June 2003 8:44:21 am

I understand the initial concern - but I think that it is up to YOU to make templates that your mother understands.

You don't need to let her ever SEE that there is something called a node. Eg. the 'create new class' dropdown - who is to say that you don't replace that with a select box whose content is dependent on the parent node (create new: receipe) ?

I agree that it would be exciting to see an opensource effort that mainly focused on template building with the goal of making a more accessible version of eZPublish.

eZPub is a framework - it's like a new layer between the traditional 'low-level' and 'user-level' layers - and if you get to know it - it could significantly speed up you application development cycle. At least that is why I am investigating it right now :)