that actually sounds pretty good - keeping the user in the same are when
he/she edits will be a major win with clients.
Ruben
On 8/12/2010 12:40 AM, Philipp Bärfuss wrote:
Thanks! this reflects exactly our opinion. Inline editing is a nice goody and
should only enrich the 'normal' editing. What confuses the user in todays page
editing is that we open new browser windows and that you loose the context
easily. To increase the user experience we will:
- open the dialog in the page (no extra window)
- make the dialog modal: one dialog only
There are many other things to be improved before we go for the inline editing:
- executing actions in the page: activate, create subpage, proceed workflow if
the page is in the workflow, ...
- show extra information in the toolbox: activation status, paragraph names, ..
- paragraph selection with preview icon, separate advanced paragraphs to a
different tab, ...
How to implement Inline editing:
- HTML5 will make all this much easier
- see neat example: http://html5demos.com/contenteditable
- very well possible that inline editing will just be supported in modern
browsers (as I said as a nice goody ;-)
Philipp
Just wanted to give feedback concerning inline-editing, since this topic has
popped up in the architecture discussion:
In our experience, Magnolia has it exactly right - use the layout to navigate
the content, but edit in separate dialogs.
Inline editing sounds nice, but in actuality it produces far too many problems:
- how to edit invisible attributes/elements/non-displaying content
- editing controls often don't have space in the layout at the right position
- editing controls interfere with the layout (this admittedly happens with
magnolia's approach sometimes too)
The magnolia system is very intuitive and easy to understand for the users - I
think real inline editing would be harder, not easier, to understand for the
users, and much harder to implement for the template developers.
Regards from Vienna,
Richard Unger
-----Ursprüngliche Nachricht-----
Von: [email protected] [mailto:[email protected]]
Im Auftrag von Ruben Reusser
Gesendet: Dienstag, 10. August 2010 15:22
An: Magnolia User-List
Betreff: Re: [magnolia-user] Magnolia 5.0 - architecture - survey and final
decision | Community ecosystem
I know Magnolia wants to keep the dialogs for editing going. In my
experience, this confuses the users a bit and it would be better to be
able to edit directly on the page instead. So a change like this would
bring the admin interface into the webpage or has at least the potential
to, While this type of editing is not a design goal of magnolia as far
as I understand, it would be good to have an architecture in place that
could support this in the future.
Ruben
Jörg von Frantzius wrote:
Personally I was aware that this architectural choice only affects
the admin interface, but I also wasn't sure whether everybody else was ;)
We did use GWT in the admin interface, and we made good experiences
with it. All I wrote previously about performance was meant to refer
to the admin interface, which is being used heavily e.g. by editors.
If you work 8h per day on a system that gives you sluggish performance
or bad usability, or when you know it could be faster, this can drive
you nuts (at least me it would).
From our experience, the decision for a CMS system often is heavily
influenced by the actual users of the admin interface, such as
editors. And that's with good reason, because it's them who eventually
must work with it for years every day.
On 10.08.2010 10:22, Nils Breunese wrote:
Mrinal Kanti wrote:
I feel that the community ecosystem was a bit underestimated in the
evaluation where Ext/JS was considered above GWT. I would be
considering the overall architecture which supports a wider
community involvement - not just from a polished UI perspective but
from a social participation perspective.
I feel strongly about the potential of OpenSocial platform
(http://www.opensocial.org) and support for other applications like
- My Space, Orkut, Google Wave etc. Since Vaadin follows an entirely
different architectural approach, I do not know how far it can
collaborate with these platforms/applications. Needless to say, that
any product architecture which encourages (and has a potential for)
developing a community ecosystem would be a first choice regardless
of a rich component library or polished UI. I am not bashing Vaadin
in general, but it seems it does not have the sufficient advantage
to be among the core components of a CMS especially considering the
architectural impact/alienation.
I'm not sure if everyone in this thread realizes that the choice for
a UI framework for Magnolia 5 is (AFAIK) only a choice for the
framework used to build the new *admin* interface. I believe this
will have zero impact on your websites. Or am I misunderstanding the
complaints?
Nils Breunese.
De informatie vervat in deze e-mail en meegezonden bijlagen is
uitsluitend bedoeld voor gebruik door de geadresseerde en kan
vertrouwelijke informatie bevatten. Openbaarmaking,
vermenigvuldiging, verspreiding en/of verstrekking van deze
informatie aan derden is voorbehouden aan geadresseerde. De VPRO
staat niet in voor de juiste en volledige overbrenging van de inhoud
van een verzonden e-mail, noch voor tijdige ontvangst daarvan.
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to:<[email protected]>
----------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to:<[email protected]>
----------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to:<[email protected]>
----------------------------------------------------------------
Cheers
- Philipp
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to:<[email protected]>
----------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
