Re: [Plone-UI] PLIP 12227: In-Plone Theme Editor
On 6 March 2012 08:55, Denys Mishunov <denys.mishunov@...> wrote:
> Hi Martin,
>
> On Tue, Mar 6, 2012 at 9:38 AM, Martin Aspeli
<optilude+lists@...> wrote:
>
>> I obviously believe this is a very important feature. It is not,
>> though, something every end user of Plone will use: it's
>> admin/integrator/designer/developer UI only.
>
> Thank you for pushing this. I totally agree that this might be a
> game-changer for the approachability of Plone among the front-end
> developers. But even though I am excited about the visual editor for
> Diazo, I am not comfortable with letting yet another tool "built by
> developers for developer so that even developers don't like it" in. We
> have plenty of those. If we spoil the tool and tell people — you
> *just* need to hack around in order to understand how the thing works,
> it will not do any good neither for Plone nor for Diazo. It's my
> personal opinion.
That wasn't the point. All I'm saying is that we don't have anything
equivalent in Plone that we can borrow UI from (apart from maybe in
the ZMI). The content management UI is at best a partial fit. It needs
to be functional and easy to understand. I'm not sure it needs to be
consistent with the way you edit a content item.
> The main points to me are (and these are just on the surface — I
> didn't review the UI yet):
> - having a visual editor is great. I am all for that.
> - having visual editor that works weird, unexpected and gives
> unpredictable results is worse than not having a visual editor at all.
> And this part is not about prettier/more consistent with the content
> management UI for sure. It's about proper UI and UX decisions.
> - the editor should be very well separated from the rest of the
> Plone in order to not leak it's stuff to the public interface on the
> running sites — this editor is something you use while developing.
> Maybe some times, very rarely, when you need to tweak something. But
> not more. So it has to be pretty well isolated from the public
> interfaces.
> - if some features or UI elements/ideas are not ready for a
> prime-time it's better to strip them out for the release than shipping
> them raw and hope for a fix after the release.
I don't disagree with any of those points.
> Once again, I don't know how does the PLIP stand against these points.
> The only thing I saw about the editor in action is the screencast. I
> know that partially the UI flaws that might be here are because of the
> UI team being inactive after you have asked for a review. Sorry for
> this.
Note that Alex at least was involved in some of the decisions, and
Nathan did a lot of the work on the file manager, so it's not like
no-one has looked at it with a UI focus.
> That being said, I will do my best to give my review of the PLIP from
> UI perspective as soon as possible.
I hope you will. :)
See also the PLIP comments, where Rob has suggested some areas for
improvement/concern.
My main concerns are:
- That we don't end up waiting "indefinitely" for some UI
review/suggestions that then stops us from shipping something
potentially useful.
- That we don't end up with a list of subjective comments. Actionable
and constructive criticism only, please.
- That we don't demand 'perfection' if we can ship something that is
'good enough' to add value.
- That we don't heave this off as something that "could be an
add-on". I don't believe much of the target audience here will be
installing add-ons and running buildouts. They'll only use this if it
ships with Plone.
To get there, I hope someone in the community will step up and help
with some of the UX/CSS elements. I also hope (and had some takers,
who've since gone quiet) we can ship with a better skeleton/base theme
than the super-simple one that's there now, which is really just a
technology demo.
Martin
RSS Feed