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

[Martin Aspeli]

H Denys,

On 8 March 2012 09:38, Denys Mishunov <denys.mishunov at gmail.com> wrote:
> On Thu, Mar 8, 2012 at 10:18 AM, Martin Aspeli <optilude+lists at gmail.com>
wrote:
>> One request, though: you said the structure of the theme mapper is "a
>> mess". Could you perhaps do a quick mock-up (low-fidelity is fine) of
>> the type of structure you think would work better? I didn't quite
>> follow the textual description.
>
> Sure, I was thinking about it myself (I know my textual descriptions
> can get really messy as well ;)) just didn't quite have time at
> 01:30AM :-P Will see what I can come up with today in the evening.
> Will try to so some Balsamiq mockups for the start

Awesome!

I'm going to copy your review here and respond a bit - trac isn't very
inclusive for this type of discussion.

Create theme tab

   - When on "Create theme" tab it should allow me to upload the theme
   right there wihout switching tabs back and forth. This is important — the
   form doesn't allow me to create completely new theme from scratch so it has
   to allow me to upload a theme here.

Great idea! Of course, this assumes some kind of pre-step where we build
locally and then upload. I think that's one workflow. I think others,
especially those mainly tinkering/playing with Plone, will want to do
everything inside Plone.

   - Having some pre-installed themes out-of-the-box is confusing. I have
   no idea what are those. If you want to provide a demo theme it should be
   only one. Not 2. And should probably be renamed to something simple like
   "Demo theme".

The idea is that starting completely from scratch (needing to manually add
the rules file, or having a blank one) is going to be a steep learning
curve. We want to encourage some good practices as well and help people
make good choices. So, the idea was to have a skeleton/starting point theme
that made some useful choices about theme structure and provided a way to
start.

Of course, the current one is a complete throwaway for testing. One of the
final steps identified before we can ship this is to come up with a good
skeleton/starting point theme. Some people volunteered, but nothing has
been done yet.

   - If we ship with a demo theme, it should at minimum resemble a
   real-life theme and look completely different from Plone. The bundled
   examples look like either plain HTML or not finished Plone. If you want, I
   could come up with a basic boilerplate theme or we could take one of the
   GPL ones.

I was thinking something really minimal, boilerplate-like, possibly based
on Twitter Bootstrap or similar. If you could do it, fantastic! I think it
should be thought of more as a template/skeleton than a demo, so hence I
wasn't too keen on the 'rich' GPL themes.

Manage theme files view

   - After I put the basic information about my theme I get a screen with
   the file browser for a theme. The theme, most probably, has been finished
   in my desktop application.

I'm not sure that's always the case, especially for people tinkering with
Plone ("how do I theme this thing?"), rather than designers. We want to
support both use cases, though.

   - So there is no need to give me the file browser for a thing I have
   already finished in a much friendlier environment. I would like just 2
   buttons — "Manage theme files", "Map the theme". Or, even better, go
   straight to the mapping process. This is important — if there is no ability
   to create a theme from scratch, this means the theme should have been
   completed in a desktop application. This means I don't need file browser
   for my theme. Ideally, after I fill out title and description for the
   theme, I need the tool to add rules.xml, manifest.cfg to my theme in the
   background (if they are still not there) and let me map the theme
   immediately after that.

The idea is you create a theme from scratch by starting from the skeleton
theme unless you explicitly choose another starting point to copy.

However, I like the idea of having that intermediary step and making the
choice more explicit.

   - If we will give the ability to edit the theme itself TTW is it
   possible, to let people preview the theme (not the mapped content + theme
   result, but the plain theme itself) after the changes they've made?

Yeah. You can do that in the mapper, but there was a suggestion to have a
preview in the file manager too. Any UI suggestions/mockups on how that
would look? You'd need to pick which HTML file to start from, since there
could be multiple to preview.
Theme mapping view

   - Map theme view is a mess. It should have much better and prominent
   structure. Text should be consistent. If we call a panel "The Diazo rules"
   in the description, the corresponding panel should have this exact title
   and not just "Rules". Would be great instead of the page description have a
   short paragrpah with explanation and an unordered list of in-page links to
   the panels for easieer navigation.


Mockup appreciated, as I said.

   - Content and Theme panels should come first in my opinion. Moreover
   they should be layed out with some logic. For example

Theme → Content

Rules → Preview

If we see both content and the theme in 50% of the screen we can not show
the result in 100% — it doesn't match. Moreover it's better to put preview
right below the content to make comparison of the before/after states
easier.


   - Rules field shows that it is re-sizable, but I could not "catch" the
   corner and re-size the field.


Strange. Bug I guess.

   - Any reason the panels have no editor as we had on the theme files
   view? It is very confusing to get different tools for editing the same
   information on these 2 screens.

You do have an editor for theme files, and the rules file, and a readonly
source view of the content. Did it not work for you?

   - The title of the "Preview" panel should be changed. Having "Preview"
   as the title and "preview" as an action is confusing. "Result" as a title
   could be an option.

Good idea.


   - "Hover over an element to see its selector." information should be
   above the panel, not below. Before noticing that, I was wondering whether I
   should constantly switch back and forth between the "Preview" and "Source".

Good idea.


   - "Last saved:" information should be much more prominent after one has
   saved a selector. Something like color highlight that dims down after some
   time. Right now it is using the same font color as the content of a panel
   located on a really light gray background and you should really know where
   to look for in order to notice it.

Good idea. Can you suggest some styling that would be clearer? Or help fix?
;-)

   - The interaction betwen the panels should be more interactive. I have
   saved some elements in the panels without adding a new rule. What do I do
   next with that info? The info is not copied in my copy/paste buffer, the
   information is not copied to my rules file, for example. Probably it's not
   a task for this phase but this experience should be thought through. For
   now at least a toolbox (and the functionality of course) with a hint of
   what should I do now ("Want to create a rule for this selector?") should
   popup. Or we just don't allow selecting the elements outside of the
   add-new-rule process.

Interacting with the copy/paste buffer is a bit tricky if not done by user
action, at least in some browsers.

   - Why do overlays with Diazo help and new rule have such a tiny
   font-size?

CSS bug, I guess.

   - If I tried to add a new rule and then changed my mind there has to be
   a way to cancel the creation like Esc, or some button or click-event
   outside of the panels.

Good idea.

   - If I click "Cancel" on the final stage of adding the new rule I don't
   need the same "Flash" effect as when I have added the rule successfully.
   This makes me stare in the rules panel thinking I have actually added
   something. Harsh stop without any animation or flash is more suitable in
   this case.

Right. The 'flash' is not so much an effect to say something has happened,
but caused by the rules editor coming back into view (it was faded out
during the rule selector operation).

   - On the other hand, when I click "Save" for the rules file, I would
   like to see some feedback from the preview panel like that flash we have
   after adding a rule. Just local for the preview panel. Otherwise, if I work
   with an element in the footer I have no idea whether preview has been
   updated or not — the element I care about is not visible in this case.

Good point. Could you suggest a better feedback mechanism than flashing the
editor? A portal message maybe?


   - Nothing tells me that by changing and saving the rules I make
   permanent changes immediately available on the site. In this case we should
   get rid of all "preview" labels and titles since there is no preview —
   there is an end result in any case. Or I would prefer to somehow keep the
   changes I make and then have a large button "Update the site" or something
   like that that would push the changes to the site.

It does if the theme is currently active. It doesn't need to be.

We should update the text.

Making a 'working copy' model for this is a next-generation feature, I
think. We should do it, but it's probably too much to bite off now.


   - I would eliminate "preview" from "preview/source" toggle and would
   make just a simple 'source' button instead. Preview is the default view
   anyway and it is preview at any moment when it is not source.

Good idea. Would that need to be a modal button, though? Do we have UI
components for this?

   - Is it possible to save selector in the panels on click and not on
   Enter? This would be much more intuitive way of doing things. When I am
   working with applying rules I don't need to interact with content. If I
   need to check other pages I go to the site (that has the theme already
   applied by now) and check it there. Or we can have another button like
   "Interactive mode" for example. It should be disabled by default and no
   interaction should happen.

I thought it worked on click. It's supposed to, certainly - there's JS to
intercept clicks when the rule selector is active. Which browser did you
use?

So, seems like we have a number of tweaks to make, and some flow/layout
things to change. I'm hoping to get some mockups to help guide those as per
the comments above.

My last question is for the FWT: What is the deadline for getting any of
this done? I could help with some of it, but I have realistically only a
few hours a week for hacking these days. I'd really like some help (hint
hint).

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20120308/e60b0c73/attachment-0001.html>