Note that this presentation included a lot of discussion with the partners about how they would like to see the interface evolve; this was part of Roland's intention: to engage the community in the process. One question which came up was JQuery versus YUI. See: http://share.ez.no/forums/ez-publish-5-platform/yui-vs-jquery for an amusing continuation.
eZPublish editing interface (Roland)
Process so far:
ez4 = facelift admin interface
Inline editing interface (shown on Github editorial system blender)
Last year (2012) - worked on prototype for new iface
developed in basement, so not properly scoped
Front end only for now, inline editing
New process started, because this was:
focusing on casual user, but we must have a holistic approach
ez needs a mix of admin and editorial tasks, and this focuses on just one type of user
need (mobile, touch friendly) interface
ezexceed people asked to join the project
ez ended up going their own way
task force started to redefine the whole UI, dedicated UI expert
only started late Dec 2012, first round to end in Feb
admin UI to be redone on top of the new Public API (EZPUBLISH6!)
Admin UI and editorial UI split up
Damian Pobel(sp?) working on admin
Worked on 6 basic user narratives (scenarios), from a ultra-simple user, to publisher-level people (power-editors).
Workflow a part of this.
Two kinds of workflow:
Predef workflow (strong, fixed process),
Flex workflow (or "ask people for review if you want to" before your article goes live)
What's in admin vs. editor?
Still work in progress, but will be a clearer division in new UI.
Editor = operations supporting the create/deliver/optimize paradigm
Other stuff in admin
Example: create new site probably not just a node creation. Group had differring opinions on where this goes (editor vs. admin iface).
Editorial - front end or back end?
Considered on both sides. Attempt to bring both together.
Also... there are going to be sites without the front end... mobile apps, etc, stuff used through API.
... then we launched into slides (Roland to share alongside these notes)
Some questions/answers:
No addition of attribute level security yet. (people said it was asked for by our clients)
Treating child pages (true pages vs. helper content) differently? Yes.
Former preview pane: more fixed now. No/reduced ability to modify preview/admin interface.
No inline editing for now. We expose the entire form?
Edit operation now in an overlay dialog.
We showed container object concept. (answer to treating child pages vs. helper content differently).
Search more and more prominent, relies on Solr. (up where tree used to be)
Publishing - changes to that entire process. New concept of revisions.
Editors along the workflow chain can access revisions without touching publishing.
When it's published, we can purge revisions.
State hooked to version.
Editing by Publishers/Approvers? Yes.
Using workflow for event-based actions now. In the future, hooks will take care of a lot of this?
Should be keep content states? Community says yes.
Object states - important vs. non-important (content protection), migrations, workflow
Make object states an editorial item? Some people say yes, but not clear. How do we label what they mean, with so many uses?
Jquery strongly preferred over yui by all devs present.
Theming? Starting HTML point? eZ started, or each dev for themselves?
Inconclusive results, but question not as clear in ez context.
We would prefer a strong ezDemo to base our designs on. (current eZDemo very liked by some here)
Roland: Theming yes, but on admin side. (more of a CSS editor?)
Roland: Would like to make a series of demo sites, and provide starting HTML.
To engage the community, the following to be considered:
1) blogs,
2) online meetups,
3) schedule feedback with power users,
4) prototypes shown and debated,
5) ez5 forums?
Is ez going to do something different than ezdemo? A bit of a wrong question to ask, ez always lets you do what you want.
Even now, there's a ton of templates that we never override (like h1-rendering template).
Maybe focus on picking the technology stack for now? JQuery vs. YUI.
Comments
Comments are closed.
Comments courtesy of Miro Kresonja.
Note that this presentation included a lot of discussion with the partners about how they would like to see the interface evolve; this was part of Roland's intention: to engage the community in the process. One question which came up was JQuery versus YUI. See: http://share.ez.no/forums/ez-publish-5-platform/yui-vs-jquery for an amusing continuation.
eZPublish editing interface (Roland)
Process so far:
ez4 = facelift admin interface
Inline editing interface (shown on Github editorial system blender)
Last year (2012) - worked on prototype for new iface
developed in basement, so not properly scoped
Front end only for now, inline editing
New process started, because this was:
focusing on casual user, but we must have a holistic approach
ez needs a mix of admin and editorial tasks, and this focuses on just one type of user
need (mobile, touch friendly) interface
ezexceed people asked to join the project
ez ended up going their own way
task force started to redefine the whole UI, dedicated UI expert
only started late Dec 2012, first round to end in Feb
admin UI to be redone on top of the new Public API (EZPUBLISH6!)
Admin UI and editorial UI split up
Damian Pobel(sp?) working on admin
Worked on 6 basic user narratives (scenarios), from a ultra-simple user, to publisher-level people (power-editors).
Workflow a part of this.
Two kinds of workflow:
Predef workflow (strong, fixed process),
Flex workflow (or "ask people for review if you want to" before your article goes live)
What's in admin vs. editor?
Still work in progress, but will be a clearer division in new UI.
Editor = operations supporting the create/deliver/optimize paradigm
Other stuff in admin
Example: create new site probably not just a node creation. Group had differring opinions on where this goes (editor vs. admin iface).
Editorial - front end or back end?
Considered on both sides. Attempt to bring both together.
Also... there are going to be sites without the front end... mobile apps, etc, stuff used through API.
... then we launched into slides (Roland to share alongside these notes)
Some questions/answers:
No addition of attribute level security yet. (people said it was asked for by our clients)
Treating child pages (true pages vs. helper content) differently? Yes.
Former preview pane: more fixed now. No/reduced ability to modify preview/admin interface.
No inline editing for now. We expose the entire form?
Edit operation now in an overlay dialog.
We showed container object concept. (answer to treating child pages vs. helper content differently).
Search more and more prominent, relies on Solr. (up where tree used to be)
Publishing - changes to that entire process. New concept of revisions.
Editors along the workflow chain can access revisions without touching publishing.
When it's published, we can purge revisions.
State hooked to version.
Editing by Publishers/Approvers? Yes.
Using workflow for event-based actions now. In the future, hooks will take care of a lot of this?
Should be keep content states? Community says yes.
Object states - important vs. non-important (content protection), migrations, workflow
Make object states an editorial item? Some people say yes, but not clear. How do we label what they mean, with so many uses?
Jquery strongly preferred over yui by all devs present.
Theming? Starting HTML point? eZ started, or each dev for themselves?
Inconclusive results, but question not as clear in ez context.
We would prefer a strong ezDemo to base our designs on. (current eZDemo very liked by some here)
Roland: Theming yes, but on admin side. (more of a CSS editor?)
Roland: Would like to make a series of demo sites, and provide starting HTML.
To engage the community, the following to be considered:
1) blogs,
2) online meetups,
3) schedule feedback with power users,
4) prototypes shown and debated,
5) ez5 forums?
Is ez going to do something different than ezdemo? A bit of a wrong question to ask, ez always lets you do what you want.
Even now, there's a ton of templates that we never override (like h1-rendering template).
Maybe focus on picking the technology stack for now? JQuery vs. YUI.