[Plone-UI] PLIP 12227: In-Plone Theme Editor

Martin Aspeli optilude+lists at gmail.com
Mon Jun 25 20:24:39 UTC 2012


On 25 June 2012 16:09, Tseng-Planas, Alice <atseng at it.ucla.edu> wrote:

>  Hi Martin,
>  I have a couple of comments/question on your wireframes:
>   - I see text annotations (yellow boxes corresponding to the red numbers
> on the wireframe) in the PDF on the first slide, but not subsequent ones.
> Is that intentional or has something gone wrong?
>  No – nothing gone wrong. Sorry about that- I just had to stop last night
> because I needed to work on other projects but plan to finish annotations
> later this week.

That's cool. I think it was pretty self-explanatory anyway for the most
part, just wanted to make sure I hadn't missed anything.

> Realized this first pass was taking much longer than I planned for and
> wanted to get something out to you rather than wait. I just went ahead and
> marked all the annotation points so you could see the areas that I thought
> needed further clarification — this is a weakness of wireframes; some of
> this would be easier in conversation and white boarding, me thinks.

I think it's worked pretty well so far, actually.

>   - Would it be better if help was an overlay rather than a separate tab?
> This would allow it to be called up from multiple pages (mapper, file
> manager as well as control panel), and maybe feel a bit less like switching
> back and forth between help view and the control panel proper.
>  Ah right. I think the "help tab" I'm distinguishing as a "global help
> resources page/section" -- I figured since so many of the complaints from
> the survey stemmed from people getting confused by the existing
> documentation they found online — it could be a helpful later feature to
> add a FAQ/tutorial style links so the new user has a one-stop-shop to
> accurate information. This is distinguished from "rules help" which is
> still preserved (your diazo cheat sheet) in the theme mapper as an overlay.
> Wondering if this is confusing — but I agree with you that the cheat sheet
> is better off as an overlay. Does that logic make sense?

Right now, mainly to rationalise work/maintenance of this, I'm leaning
towards the user guide you've seen a first draft of being available to call
up on each screen with deep-links to relevant sections as appropriate.

>  - It may be quite hard to do a theme preview in an efficient,
> cross-browser way. I'll investigate. Do you think it might work to use the
> same basic layout on the control panel home page, but without a preview,
> just title/description?
>  Sure, anything is possible. It's good to know what your real dev
> constraints are — we can rework based on that.

The problem is that a theme is an HTML file, so the only way to render that
in the browser is in an iframe, but scaling it down is virtually
impossible. We could ask theme authors to upload screenshots of their
themes, but I fear they just wouldn't in most cases.

> The mock I sent you was a radical departure to give you another look at
> the problem. I think the core issues that the group discussed was balancing
> 2 tensions: their desire to have everything that is related to a task in
> one place and yet not be overwhelmed by a wall of text data and action
> buttons. Another solution (if that's workable with your constraints) is to
> have some closable panels and drawers to minimize some secondary actions as
> a way to cut down on visual noise. Let me know if the image preview is a
> no-go and I can take another stab at reconfiguring a text-only based output.

I actually like the 'tile' based approach. I think it solves the "row of
buttons" issue with the table layout, which I was never very happy with. I
just think maybe we need the tile to contain just title/description and not
a thumbnail, although I'd like to try to figure out if we can get one in

>  - Drag-and-drop for theme activation is cool, but in case we can't make
> it work easily, is an explicit button action on the tile for each theme OK?
>  Yep. Same as above. I think if you're not concerned with scale (how many
> themes a user may be saving) a simple drop-down list picker or a column of
> radio buttons for selection will work. Or even another action as an inline.
> The deal with inline is that — too many 2ndary inline actions often cause
> users to complain that the interface is cluttered but, again it's a matter
> of scale -- and sometimes layout and whitespace can help a bit.

I kind of imagine people will have at most a few themes, and probably quite
often only one or two. I'm not sure we need to optimise for the case where
people have dozens.

My current thinking is that we start with the tiles layout without
thumbnails, and with an explicit activate/deactivate button that causes the
relevant theme to be highlighted. Drag-and-drop and thumbnailing can then
be future enhancements. That's mainly just to get something shippable in a
reasonable time, as 4.3 merge deadline is drawing near.

>  - Are you happy with the file preview at the bottom of the file manager
> tree/edit panes? It doesn't appear in the wireframes. Note: you need to
> open an HTML file to see it.
>  Ah yes — I removed those since more than one person from the group
> complained that they didn't see the need for it. I, personally just removed
> it because that interaction and purpose was fuzzy for me and the primary
> complaint from the group was that in the "manage files" and "theme mapper"
> they wanted less not more. They wanted more screen real estate to work with
> the important parts and less clutter. I think more work could be done on
> thinking about ways to solve that issue for both sections. I would need to
> do more looking around at apps for some solutions. Could you clarify for me
> what the core need that html preview serves? Folks from the group said they
> preferred to have just a second browser window open to preview, rather than
> have to scroll.

Right. Maybe we need to optimise for second browser window, i.e. we just
have a preview link that opens a new window/tab? Jon Stahl suggested the
same thing.

I personally think it's quite hard to build HTML and rules without
cross-checking with a preview quite frequently. I also quite like the idea
that when I save the rules (in the mapper) I see the changes right away
(the iframe reloads automatically and shows changes). But maybe that's a
power user thing, I don't know.

>  - In the theme mapper wireframes, where does the rules editor go?
>  Ah right — do you mean the "overlay wizard" that you currently have that
> launches with click of "new rule" or do you mean the rules.xml window at
> the bottom that in your wireframes you had spanning across the page under
> the 2 windows (html mockup and unthemed content)? In either case, I left
> them "as is" in your wireframe and current app (as described above) -- they
> seemed to work fine and I didn't have a better solution to offer.

I meant the rules.xml editor, which is now 1/2 of the mapper and would in
future become 1/2 under the mockup and content panels (1/4 each).

>   - Are you sure you'd like preview in the rules mapper to be an explicit
> action (preview button)? Personally I'd prefer it in a panel underneath the
> rules file editor (as on the file manager), or possibly as something to
> open in a new window/tab. Otherwise, it's always two clicks: edit the rules
> file, then click preview, close the preview, then edit again. Right now, it
> syncs the preview with the content you're viewing in the 'unthemed content'
> pane and reloads the preview automatically on save, which seems more
> efficient to me.
>  I think this could shaped by the fact that my installation isn't working
> 100% on my end. I'm having trouble with that window — the interaction for
> me has been that it isn't instant — I have to click refresh to get the
> updates — so in that case I prefer to have it be a button I click and
> launch a new window than have it take up more screen.

It's probably just buggy still :)

>  But this may change if these issues get resolved and I'm getting that
> seemless sync you are experiencing? I know that another user was
> complaining to me that her install has ajax bugs causing the need to
> hard-refresh often, so  this may be a quirk I'm experiencing. Not sure
> where it's stemming from though …

Again, probably just bugs. I'll need to take a look.

> I am thinking though, that preferences will vary between those who have a
> higher need for efficiency and those who want less clutter in the interface
> — I'm wondering if there is another solution to meet both camps? My hunch
> is that even with seamless sync — I'm probably one of those people who
> prefers "minimal" interfaces over "powerful" ones -- especially when I'm
> learning something new to me. Again — I think you're gonna get these poles
> with these sort of preferences …

I did wonder if maybe we have a consistent mechanism for preview in both
file manager and mapper that is basically a preview pane that you can roll
up or down (probably starting rolled up). So, you click "preview" and it
opens a panel under the rules editor with an iframe preview, but you can
hide it again by rolling that panel back up.

Too fiddly?

> One person suggested that all the windows be collapsible by the user.
> Another suggested that the user be able to decide which windows are primary
> and the ability to re-arrange and move/resize panes to their liking.
>  Perhaps a little more work can go into thinking how to solve this issue —
> if you have the time in your timeline, I can look around for some examples
> this week to see if we can come up with more ideas.

Individual resizing is quite hard to do well in that layout. Right now, the
halfway house is the fullscreen option (also important to be able to test
responsive designs, as Denys pointed out). I'm inclined to think we should
find one layout and stick to it, rather than make it too flexible, which
could get confusing.

> Again, I think I need a better idea of what your hard dev constraints are
> to propose recs that are feasible.

The main constraint is time. The second constraint is that I'm not all that
good at the creative treatment or the graphics/CSS to make it all look
tight. Quite a lot of the proposed changes are relatively simple, though,
so I think we can get pretty close.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-ui/attachments/20120625/4f6e2b1d/attachment-0001.html>

More information about the UI mailing list