eZ Community » Forums » Suggestions » 2 years ago...
expandshrink

2 years ago...

2 years ago...

Monday 19 January 2009 3:36:18 am - 49 replies

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

Monday 19 January 2009 9:58:39 am

I think most people will agree happy.gif Emoticon

Modified on Monday 19 January 2009 6:03:21 pm by Ivo Luka─Ź

Monday 19 January 2009 10: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

Monday 19 January 2009 6:03:19 pm

Hi

Thanks for a very thought through answer. Got some very good points there.

We, and our clients very much appreciate the maturity and stability of the eZ Publish interface. We actually very rarely have any problems with the way its suppose to work.

But, as I see it it should be possible to maintain this stability and at the same time manage to squeeze in a few new goodies now and then.

As a start for the discussion about features in the admin I can start with the things we have added ourselves:

1. Tabbed edit interface, makes it A LOT easier to get an overview
2. JQuery based date pickers
3. More prominent create new dropdown
4. jQuery based tooltips in edit mode
5. Help section with demo movies directly in admin
6. Support and live support as a toolbar
7. Easier datatypes for images allowing for both create new and use from media library
8. Multiple file upload with support for flash 10

We would like to see more are features directly aimed at the people working with eZ as there daily tool. Not the one buying it, not the IT manager. The one actually having to move 35 objects one by one happy.gif Emoticon

A few shortcuts for making there work easier would be:

1. Less page reloads. Common, reload for hiding a toolbox?
2. Page tree in different languages
3. Drag and drop for reorder etc, i know i know, but the clients they like it
4. Crop functionality based on certain image ratios
5. A My Page, desktop area with shortcuts etc

I personally think there is a lot that can be done with quite small resources. Just the small things that makes the users go ohh thats nice. And lets face it, Oracle support does not make anyone go.. Ohh that is neat...

Regarding the frontend editing toolbar we are all for it. I think an easier front-end editing for editors together with the more complete backend for admins is the way to go.

Only problem for us is that the current editor is dependent on a more or less "boxy" design. It also becomes "part"of the site and therefor needs to be styled for every project. Have you tried adding the standard solution to a black site with a narrow content area?

Not sure how to tackle this but the best solution for us would be to implement it in a way that is separate from the actual site. Could be using overlays aka lightboxes? Not sure...

Well, thats more than anyone will care to read already so...

Over and out

Fredrik

Modified on Monday 19 January 2009 6:08:13 pm by Fredrik Ardmar

Monday 19 January 2009 6:54:23 pm

Hi Fredrik

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

Tony

Tuesday 20 January 2009 2:51:34 am

Sounds great...

I our experience eZ Publish is a easy sale when talking to the IT Manager but its getting less attractive when talking to the managers doing the daily work.

I would say this is only partly due to slow implementation progress for new admin features but maybe more due to the fact that people use more web based applications such as Facebook, Gmail etc. These applications has raised the bar on what is expected from web based applications.

Fredrik

Tuesday 20 January 2009 1:38:15 pm

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.

Wednesday 21 January 2009 10:37:57 am

A few tips about building a spanking-new admin interface:

- it is very important for eZ that the default admin interface is WAI compliant, or it will not be used in public administration intranets/websites. This makes it very hard to build a moder, web 3.0 interface. But if we think of having the 2 interfaces developed in parallel, it could actually be a boon: keep an accessible one and a flashy one with less burden on retro-compatibility

- its is most likely going to be hard to seriously improve the admin interface working on templates alone. Most of the underlying modules/views would need to have parameters added, code modified etc. And the impact of those changes is much deeper, so a lot of testing would have to be done. Or the new interface is done in 100% template, replicating a lot of the business logic from views within the templates themselves (bleagh). Or a new set of modules/views is developed, leading to a massive code duplication (urgh)...

- there are about a thousand feat. requests on the issue tracker about improvements to the admin interface. A good starting place for requirements

Wednesday 21 January 2009 11: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?/ar...the-eZ-Ecosystem-Survey-results.html

Thursday 22 January 2009 3:11:09 am

I must admit that we have not been as active in the community as we could/should. We are a relatively small company and constantly swamped with work. Due to this I am not so well informed on how the process for the work within eZ is put together. But seems like that is well covered by other posters.

We have done a lot of design and HTML for for different admins before. Mostly ecommerce systems but also CMS. This work is mostly categorized in 3 types.

1. Same HTML, only changes to CSS allowed. Very limited possibilities.
2. Same code, API. Changes to HTML allowed but overall structure same.
3. Completely new. We make a new admin based on requirements without limitations due to API or code.

For the designs of the actual sites we constantly do new designs to override the standard design for our websites. As I see it it should be possible to do exactly the same with the admin? Actually we are already doing that to achieve the tabbed inferface, tooltips etc..
With this approach, maybe placed in an extension I would think a alot could be achieved.

Would that be a possible, fast track?
Negative aspects?

Our biggest concern when doing changes to the admin is that they will become obsolete in the future due to changes in the "real" admin. This challenge also needs to be addressed i guess.

Regards

Fredrik

Modified on Thursday 22 January 2009 3:13:10 am by Fredrik Ardmar

Thursday 22 January 2009 4:41:28 am

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 coreblunk.gif Emoticon

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

Modified on Thursday 22 January 2009 4:42:49 am by Bruce Morrison

Thursday 22 January 2009 2:44:19 pm

To rewrite or not to rewrite, that is the question happy.gif Emoticon

I partly agree with Bruce, a total rewrite will be a lot more time consuming, and we end up with two different admins that we can't merge changes for back and forth. On the other hand there is some parts of the current admin that very ancient code wise (the javascripts).

So Fredrik: What do aim for? A total rewrite to do everything in ajax, or ajax / usability enhancements to the current admin?

Friday 23 January 2009 7:46:56 am

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.

Wednesday 28 January 2009 4:27:57 am

As mentioned above we have only limited experience with the actual contribution to eZ and from the discussion above there seems to be a lot of structural and organizational challenges to this issue.

So some of the following points might have been discussed or settled before:

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

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

3. Wouldn't it be possible to get a small group together and implement these tasks?

That, for me, seems like the easiest way to get going.

Looking forward to comments and better ideas

Fredrik

Wednesday 28 January 2009 10: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

Modified on Wednesday 28 January 2009 2:52:11 pm by Gaetano Giunta

Wednesday 28 January 2009 1:31:12 pm

Hi Gaetano

There are many challenges... I remember about 1 year and 7 months ago at the Conference 2007, there was a developer day, where there were interesting discussions:

- promote eZ Projects by using it for our own stuff, move existing core extensions to there... so far, ezwebin, ezflow, ezoe (formerly called ezdhtml), ezodf still remain in the extensions repository. Only some new eZ Systems extensions have been started with in eZ Projects

- closing the old contribution section at ez.no... I probably don't have to say what the current status of that action point is

- wIT is too complicated and some things in it don't work well at all (might be configuration issues on this specific instance)... I already mentioned it several times that we need a better issue tracker for eZ Publish, with SVN integration, still we're stuck with the same solution as we were then

- easier download/installation/upgrade of extensions/packages, a very basic prototype I wrote was shown. Xrow has enhanced this a little bit in the meantime (http://projects.ez.no/remotepackages)

I can sum up a few other things... but I think you got my point with the list above happy.gif Emoticon

(Disclaimer: as always, what I write here is solely my individual opinion, as a private person and not as an employee)

Friday 15 May 2009 4:32:51 pm

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

Thursday 18 June 2009 6:23:12 am

The roadmap released 12th June 2009 says there will be a new admin interface in 4.3 (eZ Publish 4.3 release - March 30th, 2010): http://ez.no/ezpublish/roadmap

Friday 19 June 2009 12:08:55 pm

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

Friday 19 June 2009 12:32:31 pm

"And one important decision, using ONE JavaScript framework."

I / We agree, this has been wanted for quite some time, and the alternatives where jquery or yui. Prototype where not considered, by the plain fact that it is not as unobtrusive, is older (witch shows) and is not as modular and popular as the others (its popular on rails, but then again its bundled there and has been from the start).

The latest status is currently:
http://projects.ez.no/ezyui

As for the redesign, I don't think the plan is to completely redesign everything(as in recode everything), I think it makes more sense to be evolutionary here, maybe with something like this as a starting point:
http://projects.ez.no/rbgadmin

And of course redo the JavaScript in there to make i more flexible and modern.

Friday 19 June 2009 1:04:36 pm

Can we create the User journeys for the admin interface and share / incoprotate the community.

* Quick edit/add
* Long article edit/add
* Managing Users (for 5 ranging to 100,000 +)
* Updating images
etc...

This would help us get the front end and back end matching the user needs for small and large editorial teams.

This information would need to come from editors and partners who can gather the requirement over time. All we need a single survey form and we can collate the results. A kind of "if you contribute" you get the "UX report" kind of thing.

Maybe we can find some time to discuss at the conference. We need a rocking admin interface that fulfils the needs of the editor and publishing teams.

Note: A single field front end editor would just make my day.

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from