2 years ago...

Sunday 18 January 2009 6:36:18 pm

We, Area Digital has been working with eZ Publish now for more than 2 years. We have been overall very pleased with the quality and flexibility of the code. We have the freedom to make any kind of site in a short period of development.

Now our clients are asking when we are updating the admin interface? And I would like to ask the community the same question?

The number of visual changes to the admin interface the latest 2 years can easily be counted on not too many fingers.

As we see it the interface badly needs an update for a more web2 look and more importantly web2 functionality. Now ajax is limited to the tree menu. Hmm... Not very cutting edge..

Our clients are getting used to facebook, gmail, google analytic etc.. They all have a rich and easy to use Ajax driven interface. In eZ we still reload the page for every small task.

Anyone else have an opinion on this? Are we missing anything here?

Kind regards

Fredrik

http://www.areadigital.org

Custom google maps with eZ Publish

http://www.meresverige.dk
http://dsbfirst.meresverige.dk

Monday 19 January 2009 1:45:57 am

Hi Fredrick,

This is a very interesting point.

<b>Stability</b>
On one hand not changing the admin interface ensures a sense of stability and means editorial teams do not need to be retrained.

The admin interface currently does a good job of managing articles in a small to medium size article base. Once you start getting into larger offering the admin interface tree menu view breaks down and editors then need to use the newer front end interface.

<b>Future growth</b>
Times have changed and a evolution of how people manage information is changing. eZ Publish needs to integrate with other external systems and manage more information form the interface that just eZ Content.
We need a faster interface that allows great control over information. What those changes are is a bigger subject and I am sure that eZ will talk to the editors and developers before they make changes.

<b>Thought</b>
eZ Flow/Online Editor are both new features which allows greater control and fast access to information. For example the search element in the Online Editor saves hours!. So eZ are on the right track. I am thinking they want to get eZ solid as a rock and scalable before changing the admin interface which still handles 80% of the tasks.

What do you think? What would you like to see in the Admin interface? Lets list them here.

Reference: http://www.visionwt.com/training-ezpublish-online-editor has an overview of the new online editor

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

Monday 19 January 2009 9:54:23 am

Hi Fredrik

Nice list... I'll raise the issue at the international partner meeting in a week or so.

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 20 January 2009 4:38:15 am

As the admin interface is more or less design work, this could be an excellent candidate for a community project.

If so, then we should probably define 'rules' for projects like this which needs a certain level of collaboration. Including the need for a design document before any coding is done and coding standards to follow.
Such a project would also need a project leader (or several) to split up work between the ones that want to contribute, make sure they have signed a CLA and making sure the 'rules' of the project are followed. This person(s) should probably also be the only one(s) that have access to merge changes from 'trunk' (where everyone can commit) to stable branches (used for download packages and potentially included in eZ Publish at a later stage..).

So why do I purpose that such a project is handled as a community project?*
* eZ Publish is a complex product, and eZ doesn't not have the resources to do everything we/partners/community want within a short time frame(and the wish list is very long).
* Faster development: since more skilled community members have access to contribute directly.
* Community involvement: I personally think this community needs to be able to contribute more then it is allowed to today, to be able to grow and be more active.

Tools needed**:
* Tighter integration between the projects pages and the developer/community pages.
* Separation of svn access for 'trunk' and 'stable'
* Optional: Tool for commit/patch approval that handles merges from 'trunk' to 'stable'

Does something like this sound good? Something to add?

* Disclaimer: This is personal opinions.
** The 'tools needed' is already discussed internally, and is on our todo list for stuff we want to do after 4.1 is out.

eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom

Wednesday 21 January 2009 2:38:15 am

My proposal of using a distributed version control system (my preference: GIT) is motivated exactly by this topic, to give partners the opportunity of getting more involved in eZPublish development. I proposed a short talk on GIT for the developer conference in two weeks and hope for an interesting discussion afterwards.

http://koch.ro/blog/index.php?/archives/96-GIT-for-the-eZ-Ecosystem.html
http://koch.ro/blog/index.php?/archives/104-GIT-for-the-eZ-Ecosystem-Survey-results.html

---
Thomas Koch | http://koch.ro
YMC - eZ Publish in Switzerland | http://ymc.ch

Wednesday 21 January 2009 7:41:28 pm

Great Topic Fredrik!

I don't think the problem is as great as being stated. There are plenty of "easy" gains to be had by adding some JavaScript on top of the existing admin interface that require minimal changes to the undying HTML code.

During the summer conference in June improving the interface was discussed, and as with this thread there was quite a bit of support.

I'd already made a start of adding some minor improvements to the content object forms (datatypes at this stage) that makes it easier to do things like javascript form validation.

This work occurred in the first half of 08 and really hasn't been touched since. It's available here: http://projects.ez.no/accessibility_improvements & details of the changes to date can be found here http://svn.projects.ez.no/accessibility_improvements/trunk /CHANGELOG

The idea behind the extension is to improve the accessibility & user experience by maximising in browser checking, enhancing the user input elements and increasing accessibility by minimal changes to the underlying html. (major changes to the interface = major retraining costs = bad)

For example the ezuser data has a bunch of validation rules behind it:

Password: If [UserSettings] GeneratePasswordIfEmpty = true empty passwords are allowed and one is generated.  Only comes into play if the password is blank.
Password Length:  Stored in [UserSettings] MinPasswordLength or default to 3 if not present (in ezuser datatype)
Password cannot be set to "password"
Passwords must match

Email: Must be valid email
Email: If the email can be used for Authentication the email address must be unique

Login: must be unique
Login: cannot be empty

Currently <b>ALL</b> these checks happen in the backend and the user only become aware of them after they fail to successfully enter the values. This can be the difference between the user signing up or not! All but the checking for unique emails & login can be done entirely in the browser and these could be added with some simple ajax.

I'm more than happy to commit my time to this project or any project to improve the interface as long as there is some commitment from eZ that they will work with any such project to ensure the changes get committed back into the core in a timely manor. (Happy to improve things not happy to keep a parallel system in sync with the core;)

I can't see any point in eZ building 2 interfaces - build one that works without JavaScript and progressively enhance [1]

There is no need to be too fancy at least at the start, leave the web3.0 ?? stuff to Project V and build it in from the beginning.

Cheers
Bruce

[1] http://en.wikipedia.org/wiki/Progressive_enhancement

My Blog: http://www.stuffandcontent.com/
Follow me on twitter: http://twitter.com/brucemorrison
Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish

Thursday 22 January 2009 10:46:56 pm

I certainly agree that the administration interface needs a refresh. Internally at Quiqcorp we have done this a number of times for clients who had specific administration needs or new functionality that was required.

My biggest concern, is not how a new administration interface is implemented, it can be rewritten, modified, progressively enhanced (add in any extra option, buzz word or woopla here), but instead who will maintain this new interface.

If eZ Systems isn't willing to undertake the administration redesign, which in some ways is good because they are terrible at design, then what will this mean for an open community approach to developing such an interface? Will the old interface remain? Will eZ hold releases on the basis the community interface hasn't been updated to suit changes to eZ Publish? A good example would be template changes required for the implementation of object states on 4.1.

If we rush ahead and build something, convert our clients to it, train them on it... and then find ourselves in a position where critical updates can't be applied because our administration interface will break, be degraded or not be available (requiring us to revert to the old one) then we are in an ugly situation.

If we do proceed with building out such a community project, it would be important to ensure it was continually enhanced, and as such there was some roadmaps and specific goals in mind. The last thing we want to be doing is retraining our clients every 6 months because someone else had a great idea and decided to rearrange everything on us. There is of course ways to resolve this issue, such as the block style approach that Wordpress offers, allowing us the flexibility to layout areas of the administration in an approach most suitable to the type of work our specific clients are undertaking.

I think the biggest issue to be resolved though, is how such an interface would be treated by eZ Systems and ensuring that the project continues to receive the support required to upgrade and improve the interface beyond the first few exciting months.

Andrew Duck, Executive Director, Quiqcorp Limited
eZ Certified Developer and Trainer.
Member of the Community Project Board
http://quiqcorp.com | http://twitter.com/andrewduck

Wednesday 28 January 2009 1:15:50 am

<i>1. Would it be possible to collect a list of backend features that needs attention?
Is there already such a list?</i>

Just looking at all the existing extensions in projects.ez.no is a good starting place.
Take all admin interface enhancements, then vote on / discuss each one.

<i>2. Could these things be implemented in an extension for starts?
Are there any drawbacks to doing it as an extension?</i>

Extension sprawling and rot. While I really do believe in a healthy ecosystem, the current state of extensions reminds rather of a postnuclear wasteland:
- lots of extensions duplicating each other's functionality, with minor differences
- lots of extensions abandoned, or not updated to the latest ez version
- most of the extensions are not enough documented, in both requirements and usage

Maybe if (a part of) the community really was able to get together and deliver great stuff (not that I question anybody's technical prowess), maybe the first place to start from would be the projects website itself.
It's missing, imho
- the concept of different releases for the same extension
- correct tracking of version-compatibility (so that I can search extensions for my eZ version X)
- a frontend to svn that delivers html, diffs, cahngelogs etc (it's there, really, just hidden away)
- a bug tracking system
- scripts that, via web gui, let extension writers create packages out of their extensions
- scripts that, via web gui, let extension writers check the quality of their code (ezcodesniffer)
- scripts that, via web gui, reverse engineer a mysdql dump and create cross-db .dba definition files
- lots of polish in small details

Principal Consultant International Business
Member of the Community Project Board

Friday 15 May 2009 7:32:51 am

Hey, looks like hijacking this thread with talks about management of extensions and the projects.ez.no site has scared everybody away.

So here's my wishlist for today, all things that are incremental in existing admin interface
- clean up css, with lighter design (less visual clutter, less border around tables and drawn in softer colors)
- more icons for stock content classes
- show content class icon in 'create child' button
- allow changing an object's section without going into edit mode, as it is already possible for changing an object state
- add a context-menu to add a secondary location to a subtree of nodes in a single pass
- add to the bottom of node view page a box listing all collected info relating to the current object
- section admin page: list all content of a given section: do it via a link for every section that sends back to content/search with a filter on the given section (generic mechanism that can be used as well on the classes page to find all content of a given class, as well as in object states page. Allow empty serach must be allowed by default)
- add a js rolldown for top-level menus (at least shop, admin). Useful for navigating faster to specific parts of the admin section
- the same can be done via ajax calls to unfold dynamically the content/media/users menus if needed
- add a generic js-based sorting mechanism for tables/lists of objects, use it everywhere (might need instead to add to existing modules/views a sort_by param besides offset and limit)
- multi-modal node navigation/search mode taken from ezoe to replace the standard navigation used for object relations, moving nodes etc
- allow users to hide completely right column, not only single blocks

Principal Consultant International Business
Member of the Community Project Board

Friday 19 June 2009 3:08:55 am

Hi,

yes, another good idea is:

Ubuntu's "One Hundred Paper Cuts

A project [...] to improve user experience in Ubuntu by identifying 100 small points of pain for users, or "paper cuts", and healing them!"

https://edge.launchpad.net/hundredpapercuts

And one important decision, using ONE JavaScript framework.

My suggestion:
Prototype
http://www.prototypejs.org/
WP: http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework

together with:
script.aculo.us
http://script.aculo.us/
WP: http://en.wikipedia.org/wiki/Scriptaculous

and
Prototype UI
http://prototype-ui.com/

and more Prototype ressources:

http://scripteka.com/

Greetings, ekke

http://www.coolscreen.de - Over 40 years of certified eZ Publish know-how: http://www.cjw-network.com
CJW Newsletter: http://projects.ez.no/cjw_newsletter - http://cjw-network.com/en/ez-publ...w-newsletter-multi-channel-marketing