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

Tseng-Planas, Alice atseng at it.ucla.edu
Mon Jun 25 15:09:25 UTC 2012

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. 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.

 - 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?

 - 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 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.

 - 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.

 - 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.

 - 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.

 - 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. 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 …

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 …

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.

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


On 25 June 2012 06:05, alicetseng <atseng at it.ucla.edu<mailto:atseng at it.ucla.edu>> wrote:
Hi Martin, Eric, all:

Here's a zip with a set of:

  1.  feedback notes of mine + the groups responses to Martin's wireframes
  2.  a set of wireframes I started, to sketch out some ideas raised by the first set and group responses
  3.  The same survey responses, re-colated into problem patterns and more actionable language

A few disclaimers:
I'd take my wireframes with a huge grain of salt — as due to my workshop at the end of the week I had to have folks email me their responses and I ended up
doing a big dose of interpretation in my wireframes. So .. I'll bring these sketches to them this Thursday to get more feedback but I wanted to get you something
so not to hold you up. I put the other's comments in one section as direct quotes separate from my comments, so in case I got any interpretations wrong — I can reference back with them.They also are not annotated in full — this took much longer than I anticipated!

I tried to group the survey data into some rough patterns with some suggestions for actionable solutions to the issues raised by the surveys.
I saw that in the PLIP there were a lot of lines that weren't "actionable" so this is my attempt at doing some interpretation and pitching some ideas.
It's a super rough pass — and you'd really be better off by getting more user feedback (4 is a very small set) -- but with our small group there seemed to be one clear pattern with 2 types of user stories developing. So … hopefully it's a rough start for you.


> Just a quick follow up. I'm working on parsing through the feedback from
> the workgroup. I'm on a business trip this week and wasn't able to make
> the meeting with folks so they sent me their responses via email
> individually. It's taking me a bit longer to parse through things this way.
> I've got a few other things I need to finish up for work today-and I'll
> get a chance to post something to you guys this weekend.
> Apologies for the delay. I should have a set for you guys by Sunday.
> Cheers,
> alice
UI mailing list
[hidden email]<http://user/SendEmail.jtp?type=node&node=7556446&i=1>

If you reply to this email, your message will be added to the discussion below:
To unsubscribe from PLIP 12227: In-Plone Theme Editor, click here.

[X] Feedback.zip (3M) Download Attachment<http://plone.293351.n2.nabble.com/attachment/7556449/0/Feedback.zip>

View this message in context: Re: PLIP 12227: In-Plone Theme Editor<http://plone.293351.n2.nabble.com/PLIP-12227-In-Plone-Theme-Editor-tp7347100p7556449.html>
Sent from the User Interface & Design mailing list archive<http://plone.293351.n2.nabble.com/User-Interface-amp-Design-f293357.html> at Nabble.com.

UI mailing list
UI at lists.plone.org<mailto:UI at lists.plone.org>

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

More information about the UI mailing list