
|
If you were logged in you would be able to see more operations.
|
|
|
Time Tracking:
Issue & Sub-Tasks
Issue Only
Issue & Sub-Tasks
Issue Only
|
|
|
|
Issue Links:
|
Related
|
|
This issue related:
|
|
|
WORK-494 Inline Editing and Default (editable) Values for new content objects in order to pre-populate a new blank page
|
|
|
|
 |
|
|
|
|
|
WORK-387 Action menu and other visual optimization of the edit mode
|
|
|
|
|
|
|
|
|
This task is linked to work-387 of the generic UI WG#2. However there are clearly impacts on the template sets as it also concern modifications of action menus, fade-in/outing options (DIV), default text labels and their translations, etc...
The Jahia in-context edit mode is the heart of the product as Jahia does not (still) have any back-end oriented content management system. However we are usually not spending a lot of development time trying to address most common author needs while they are browsing the edit mode sometimes several hours a day.
Such a project should then include brainstormings on:
- Action Menus (do we want to divide them into different UI components; what is the difference between an action and an AES button? Could a workflow state be considered as an action menu?...)
- Rendering of (colored and informative) fieldsets around editable content objects (e.g in order to immediately display to the author information such as locked content or compliant and pastable area (for objects in the clipboard))
- Impact of inline editing on the rendering of the edit mode
- Fade-out and fade-in effect on a page in order to visually highlight for instance editable areas (similar to Mediasurface for instance)
- New "layers": Currently we are mixing information we want to display on a page (e.g: ACL icon; TBP icon; Workflow icons;...) and editing "layers" (inline editing with perhaps a new toolbar; a lock view in order to immediately display all locks on a page,...). Such "layers" could for instance implement the previous CSS oriented fade-in and fade-out options. So for instance an editor could turn on the "Pastable Area" layer. Automatically all compliant areas would be highlighted in transparant red. Another inline editing layer would automatically grey out all non-editable areas (at the place of having to click in all containers in order to know if you can edit it or not), etc...
Quite rapidly without too much investments I think we could really improve the edit mode (without having to fully AJAX the whole edit mode). Better management of CSS could really help us offer a better usage and experience of the product for editors.
|
|
Description
|
This task is linked to work-387 of the generic UI WG#2. However there are clearly impacts on the template sets as it also concern modifications of action menus, fade-in/outing options (DIV), default text labels and their translations, etc...
The Jahia in-context edit mode is the heart of the product as Jahia does not (still) have any back-end oriented content management system. However we are usually not spending a lot of development time trying to address most common author needs while they are browsing the edit mode sometimes several hours a day.
Such a project should then include brainstormings on:
- Action Menus (do we want to divide them into different UI components; what is the difference between an action and an AES button? Could a workflow state be considered as an action menu?...)
- Rendering of (colored and informative) fieldsets around editable content objects (e.g in order to immediately display to the author information such as locked content or compliant and pastable area (for objects in the clipboard))
- Impact of inline editing on the rendering of the edit mode
- Fade-out and fade-in effect on a page in order to visually highlight for instance editable areas (similar to Mediasurface for instance)
- New "layers": Currently we are mixing information we want to display on a page (e.g: ACL icon; TBP icon; Workflow icons;...) and editing "layers" (inline editing with perhaps a new toolbar; a lock view in order to immediately display all locks on a page,...). Such "layers" could for instance implement the previous CSS oriented fade-in and fade-out options. So for instance an editor could turn on the "Pastable Area" layer. Automatically all compliant areas would be highlighted in transparant red. Another inline editing layer would automatically grey out all non-editable areas (at the place of having to click in all containers in order to know if you can edit it or not), etc...
Quite rapidly without too much investments I think we could really improve the edit mode (without having to fully AJAX the whole edit mode). Better management of CSS could really help us offer a better usage and experience of the product for editors.
|
Show » |
Sort Order:
| There are no comments yet on this issue.
|
|