On Wed, Sep 12, 2012 at 10:54 AM, Martin Aspeli <optilude+li...@gmail.com>wrote:

> Hi,
>
> I've attached some screenshots with a few annotations on them. Not really
> my area of strength, but hopefully useful.
>
> On 11 September 2012 14:45, Nathan Van Gheem <vangh...@gmail.com> wrote:
>
>>
>>> My very, very quick first impression:
>>>
>>>  - we really want this
>>>  - we may want some way to tie it more closely to the Dexterity TTW
>>> editor
>>>
>>  - the UI is confusing ;)
>>>
>> I know...
>>
>>
>>> There's a *lot* going on, and buttons and toolbars all over the place.
>>> The colours are also fairly non-standard in a Plone context.
>>>
>> It's actually bootstrap. We had it more plone-like originally and it was
>> worse. Think we should go for something much more plain?
>>
>
> It was mostly things like buttons and colours I balked at. Looked quite
> different to everything else in Plone, which is confusing.
>
>  - Text in the overlays is very small and form layout looks broken
>>>
>> I believe that's default plone styles. Overlay font-size is 80% but yah,
>> we can make that 100% for this.
>>
>
> Yeah, you need to do something in the CSS (the plone.app.theming does it,
> for example) to get this back to normal size on the control panel template.
>
>>
>>
>  - The toolbar looks too similar to the list of states/transitions
>>> underneath
>>>
>> Should we do a completely different color?
>>
>
> Maybe look at how the p.a.theming theme mapper did it and try to be
> consistent?
>
>
>>  - I didn't notice the twiddles to open/close the state/transition bars
>>> up for more details
>>>
>> Yah, need a better way for users to notice those open up or open one up
>> by default.
>>
>
> I think if you open one up by default, people won't find the other ones,
> they'll be down below the scroll. More obvious buttons (like "Change
> settings....") may help.
>
>
>>  - The "states/transitions" switch looks like links inside the toolbar,
>>> but they behave more like how tabs behave elsewhere in Plone's UI
>>>
>>   - The tooltip hover help is great, though it doesn't look very Ploney
>>>
>> Not much of this is "Ploney." Yah, it needs some styling. The plone UI
>> needs to eventually have a standard tooltip...
>>
>
> The buttons/tabs thing isn't really about visual style, it's about what
> you expect from buttons vs. tabs.
>
>
>>  - It feels like I can affect the state-transition relationship from both
>>> ends (e.g. "source state" on a transition), which makes it hard for me to
>>> understand what affects what
>>>
>> Yes, you can. That was a "feature" :)
>>
>
> Not a bad one, maybe, but it feels a bit backwards.
>
>
>> Okay, I'll try thinking about it more. I really appreciate the feedback.
>>> It's been so long since anyone has even said anything critical and I feel
>>> like I am too familiar with the current state to properly be critical of
>>> the UI.
>>>
>>
> That's how I felt about the theme mapper after a while. ;)
>
>
>>  Maybe we can generate some kind of state chart graph for them?
>>>
>> If graphviz is installed, there is a button activated that'll generate a
>> graph for you. Or do you mean something different?
>>
>
> Will people have graphviz installed? There are JS libaries that can
> visualise things like this, which may be better.
>
> My overarching thought is that we should start with:
>
>  - A list of workflows (including existing ones, shown, but readonly)
>
>  - Buttons on each like "copy", "delete", "edit" (see the new p.a.theming
> UI for this)
>

>  - Once you open one up, some kind of in-HTML representation of states and
> transitions and how they relate to each other (like a directed graph).
> Maybe that's a graph drawn (in JS on canvas, say) to show states and
> transitions, and you click on each to bring up an overlay with editing
> options. You'd have an "add state" button next to this map to add a new
> state, and maybe an "add transition" button when editing a state, which
> would let you choose an existing transition, or create a new one". Bonus
> for some kind of drag-draw-an-arrow thing, but not necessary.
>
I actually went down this path long ago when we were thinking through this.
This visual representative workflow UI is nice for small workflows but for
complicated workflow, it really breaks down and becomes difficult to
handle--hence, using the ordered list of states and transitions. I'll think
about it though. Perhaps there is some sort of hybrid way we can work out.


>
> I think the mental model required to understand "there's a list of states,
> and there's a list of transitions, then once you've built those two lists,
> you link them together here and here, and then you have workflow" is really
> confusing.
>
I do agree with this... It's a nasty, complicated UI when you're introduced
to it. I guess we never really tried to shy away from nastiness as we were
only ever targeting power users.


> The two feel very disparate (also in the ZMI version of this, of course,
> and to an extent in the code behind it all). I'm compelled to try to draw
> it out on a piece of paper when I look at it, which is probably not quite
> right.
>
> If we managed to get something to pull it all together, then I think the
> rest of the feedback is all just about details of layout and text.
>
> Martin
>
_______________________________________________
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Reply via email to