gmane.comp.web.zope.plone.teams.framework

Re: [Plone-developers] Plone framework team meeting minutes, May 8

David Glick (GW — 2012-05-09T21:39:40

On May 9, 2012, at 2:24 PM, Elizabeth Leddy wrote:


It's currently at https://github.com/plone/plone.app.users/blob/plip10959/plone/app/users/tests/plugins.txt



----------
David Glick
 Web Developer
 davidglick-jwYafjbudsc+uJoB2kUjGw< at >public.gmane.org
 206.286.1235x32

Are you engaging? Find out! Use our free engagement benchmarking tool.

http://groundwire.org/labs/engagement-strategy/diy-benchmarking-survey

Re: [Plone-developers] Plone framework teammeeting minutes, May 8

Elizabeth Leddy — 2012-05-09T21:24:34

On May 8, 2012, at 4:36 PM, David Glick wrote:


For me, the test case and upgrade steps should definitely be handled. I'm more concerned about the documentation as a test case than anything (I can't find it anymore actually...). I *think* this should be in the community dev manual.

Liz

Re: [Plone-developers] Plone framework team meeting minutes, May 8

David Glick — 2012-05-08T23:36:02

Hey Dylan. I'm sorry we've been dropping the ball on your PLIP since 
Ross stepped down from being its champion. (In the case of today's 
meeting, we accidentally overlooked a section of our spreadsheet which 
included this PLIP.)

I just familiarized myself with the code, past reviews and conversation, 
and my personal feeling is that this is a good change and while there 
are reasonable concerns raised in the reviews, we shouldn't let the 
perfect be the enemy of the good.

To touch on some of the specific items that were outstanding in the reviews:
* Yiorgis raised the issue of the initial generated password not 
necessarily being compliant with the validation, but you pointed out 
that this is not a problem because the user never sees the initial 
password. That makes sense to me, so I think this concern is resolved.
* Yiorgis and Ross both raised concerns about whether the PAS API should 
be extended (to support limits on password age, say, or to support 
providing more specific help text for the password field on a 
registration form). I agree these are ideas worth considering, but they 
are outside the scope of this PLIP (which is just a tiny change in Plone 
to make use of the existing PAS API), orthogonal to it, and should not 
be blockers.
* Ross said he hadn't tested to make sure the validation is applied 
during the password reset process. Can you or someone else please verify 
that this works?
* Ross mentioned a test failure in CMFPlone (testGeneratePassword). This 
looks trivial to fix if it hasn't been already so we can handle it 
during merge.
* Vincent brought up an i18n concern at 
https://github.com/plone/plone.app.users/pull/2/files#L1R250 which looks 
valid to me. Can you fix that?
* I think you still need to add an upgrade step to plone.app.upgrade to 
install the plugin for upgraded sites.

Any opinions from the rest of you FWT folks?  This seems like too much 
of an easy win to me to let it drag out longer.
David


----------
David Glick
 Web Developer
 davidglick-jwYafjbudsc+uJoB2kUjGw< at >public.gmane.org
 206.286.1235x32

Are you engaging? Find out! Use our free engagement benchmarking tool.

http://groundwire.org/labs/engagement-strategy/diy-benchmarking-survey

Plone framework team meeting minutes, May 8

David Glick — 2012-05-08T18:40:20

May 8 Framework team meeting
Present: Eric Steele, Alec Mitchell, David Glick, Liz Leddy; Absent: 
Craig Haynal, Ross Patterson, Martijn Pieters, Laurence Rowe, Rob Gietema.

- There has a been a pattern of the European team members missing 
meetings as of late. Do we need to reschedule the call for a better 
time? Is it time to issue a call for new team members and ask inactive 
ones to step down?
- Plone 4.2 update: Eric is releasing rc1 today!
- With the finalization of Plone 4.2, we have set cutoff dates for Plone 
4.3 PLIPs:
   1. Implementations should be done by May 31.
   2. Reviews and merging should be done by June 11.
   3. PLIPs not meeting these deadlines will be considered for 4.4.
- PLIP 12235 (batching): Merged.
- PLIP 11773 (Dexterity): Merged.
- PLIP 11838 (z3c.form portlets): Still ready for merge.
- PLIP 12110 (ignoring accents in search): Still ready for merge.
- PLIP 12227 (theme editor): A group from UCLA has volunteered to help 
review it. Martin is finishing tweaks.
- PLIP 12266 (css class for portlets): Alec has asked implementers for a 
review buildout.
- PLIP 12844 (update TinyMCE): David tried to review but had trouble; 
has asked for instructions on getting it set up to review.
- PLIP 10886 (plone.app.event): We're assuming this one won't make 4.3 
at this point. But we like surprises.
- PLIP 12350 (jquery ui): Eric will check in with Steve.
- PLIP 12776 (remove kupu): Done. (But needs to be documented.)
- PLIP 12870 (PlonePAS portrait updates): Approved for core. Liz is 
champion.
- Eric asked whether people are using inline editing. If we can drop it, 
it will simplify the task of removing our use of KSS.



----------
David Glick
 Web Developer
 davidglick-jwYafjbudsc+uJoB2kUjGw< at >public.gmane.org
 206.286.1235x32

Are you engaging? Find out! Use our free engagement benchmarking tool.

http://groundwire.org/labs/engagement-strategy/diy-benchmarking-survey

Conference call updates

Eric Steele — 2012-05-08T16:32:44

There wound up being multiple occurrences of our call in Calliflower. I've deleted the duplicates (which is why you've all received a cancellation message or 5). Call is happening today, normal time. 

Eric

Fwd: minutes of Plone framework team meeting,April 24

David Glick — 2012-05-06T21:05:19

Hi team, this is your friendly nudge to attend to your action items before our next meeting (which I believe is this Tues. May 8, although it's not showing up on my calendar...)
best,
David

-------- Original Message --------
Subject:        minutes of Plone framework team meeting, April 24
Date:   Tue, 24 Apr 2012 12:10:17 -0700
From:   David Glick <davidglick-jwYafjbudsc+uJoB2kUjGw< at >public.gmane.org><mailto:davidglick< at >groundwire.org>
To:     Plone Developers <plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org><mailto:plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org>



April 24, 2012 – Framework Team Meeting
Attending: Eric Steele, David Glick, Ross Patterson, Alec Mitchell,
Craig Haynal, Laurence Rowe, Liz Leddy

- PLIP 11965 (ResourceRegistries resource bundles): Eric merged for 4.2.
Clearing up test failures introduced.

- PLIP 8699 (Published date): framework team has no concerns, go ahead
with implementation.

- Discussion on lists re theme control panels: Agreement that having 2
control panels is non-ideal, but not sure best way to resolve.
Suggestions welcome.

- PLIP 12844 (Switch to new version of TinyMCE): Approved for core. Next
step is review of implementation. davisagli is champion, eleddy will
also review.

- Jens Klein's proposal about handling portraits via property sheets.
Liz will follow up to get him to submit a PLIP

- PLIP 10886 (new event type): still in progress, may not be ready for 4.3.

- PLIP 12110 (plain text searches ignore accents): ready for merge.

- PLIP 10959 (API for password validation policy) and 12521
(Customizable password generation&  validation): Liz will touch base and
ask them to coordinate.

- PLIP 11773 (Dexterity): David will merge soon.

- PLIP 11838 (z3c.form support for portlets): ready for merge.

- PLIP 12024 (Non-inherited portlet assignment context): closed due to
lack of response from author.

- PLIP 12266 (add adjustable css class option on static portlet and
collection portlet): ready for review. Ross and Alex will review.

- PLIP 12350 (Integrate selected portions of jQueryUI - DRAFT): Eric
will ask Steve McMahon to champion. Okay for 4.3 if it's ready but won't
hold up 4.3 for it.

- PLIP 12238 (Add multi-sources personalize form extension): Clarified
that this was rejected some time ago.





David Glick
Web Developer
davidglick-jwYafjbudsc+uJoB2kUjGw< at >public.gmane.org
206.286.1235x32


[http://gw-logo.s3.amazonaws.com/gw-email-signature.png]


Are you engaging? Find out! Use our free engagement benchmarking survey.<http://groundwire.org/labs/engagement-strategy/diy-benchmarking-survey>

Re: [Plone-developers] PlonePAS portrait handling

Radim Novotny — 2012-05-02T15:32:18

Hi all,

I've started Plone Portraits PAS plugin work a long time ago and also 
created a PLIP proposal (which has been closed because of PLIP policy 
change - https://dev.plone.org/ticket/11323 ) It is slightly different 
what Jens is suggesting. It defines new PAS plugin and allows to use eg. 
Gravatar or LDAP. The plugin is backward comaptible with the current 
implementation, because implements ZODBPortraitProvider plugin.

The current implementation is available on 
https://github.com/naro/Products.PlonePAS The example plugins are 
Memberdata 
https://github.com/naro/Products.PlonePAS/blob/master/Products/PlonePAS/plugins/portraits.py 
or Gravatar 
https://github.com/naro/Products.PlonePAS/blob/master/Products/PlonePAS/plugins/gravatar_portrait.py 
or read-only LDAP 
https://github.com/naro/Products.PlonePAS/blob/master/Products/PlonePAS/plugins/portrait_ldap_demo.py

minutes of April 24 framework team meeting

David Glick — 2012-04-24T19:03:33

April 24, 2012 – Framework Team Meeting
Attending: Eric Steele, David Glick, Ross Patterson, Alec Mitchell, 
Craig Haynal, Laurence Rowe, Liz Leddy

- PLIP 11965 (ResourceRegistries resource bundles): Eric merged for 4.2. 
Clearing up test failures introduced.

- PLIP 8699 (Published date): framework team has no concerns, go ahead 
with implementation.

- Discussion on lists re theme control panels: Agreement that having 2 
control panels is non-ideal, but not sure best way to resolve. 
Suggestions welcome.

- PLIP 12844 (Switch to new version of TinyMCE): Approved for core. Next 
step is review of implementation. davisagli is champion, eleddy will 
also review.

- Jens Klein's proposal about handling portraits via property sheets. 
Liz will follow up to get him to submit a PLIP

- PLIP 10886 (new event type): still in progress, may not be ready for 4.3.

- PLIP 12110 (plain text searches ignore accents): ready for merge.

- PLIP 10959 (API for password validation policy) and 12521 
(Customizable password generation & validation): Liz will touch base and 
ask them to coordinate.

- PLIP 11773 (Dexterity): David will merge soon.

- PLIP 11838 (z3c.form support for portlets): ready for merge.

- PLIP 12024 (Non-inherited portlet assignment context): closed due to 
lack of response from author.

- PLIP 12266 (add adjustable css class option on static portlet and 
collection portlet): ready for review. Ross and Alex will review.

- PLIP 12350 (Integrate selected portions of jQueryUI - DRAFT): Eric 
will ask Steve McMahon to champion. Okay for 4.3 if it's ready but won't 
hold up 4.3 for it.

- PLIP 12238 (Add multi-sources personalize form extension): Clarified 
that this was rejected some time ago.



----------
David Glick
 Web Developer
 davidglick-jwYafjbudsc+uJoB2kUjGw< at >public.gmane.org
 206.286.1235x32

GiveBIG is coming! Mark your calendar for May 2 and get ready to give big to Groundwire
on this community-wide day of giving.

http://www.seattlefoundation.org/npos/Pages/Groundwire.aspx

PLIP #11965 (Resource Bundles)

Eric Steele — 2012-04-19T00:47:28

Since this one is relatively minor and has been done for some time, I've made the executive decision to just include it in Plone 4.2. (Doing so allows me to clear up some HTML 5 that snuck into the 4.1 branch) So it's completely on me if I've gone and blown everything up.  

Eric

Re: [Plone-developers] PlonePAS portrait handling

Elizabeth Leddy — 2012-04-12T17:52:58

On Apr 11, 2012, at 2:28 PM, Jens W. Klein wrote:


I would like this but, how would this work? How does the PAS story fit in here?


I'm all for this idea. I feel like a plip would just help with the review process more than anything. I wouldn't mind deprecating the old way either and making a plip would help this happen. I doubt the FWT would say no to this and I know I have a project that could use this functionality.

Liz

Re: Collections portlets

David Glick — 2012-04-10T06:32:33

On 4/1/12 4:04 PM, Eric Steele wrote:
So now that we've got plone.app.collection in 4.2, how do we want to handle collections portlets?

We currently ship with plone.portlet.collection. plone.app.collection adds its own, largely the same (though missing some of the more recent features/fixes added to the other).

Should the p.a.collection version be made the default (and updated for parity with p.portlet.collection) or should p.portlet.collection be updated to handle the newer collections (and remove the portlet functionality from p.a.collection)?

Seems like the latter would be the simpler option.

Fixed.
- The plone.portlet.collection functional test needs to be updated to create a new-style collection instead of a Topic.

Done.
- We need to figure out what to do with the unnecessary portlet in plone.app.collection. (There have been releases of plone.app.collection so it doesn't seem like we should just remove it. A migration will be a pain since it'll have to find all the portlet assignments to update them. If the 2 portlet assignment classes have the same attributes maybe we can use a module alias, but I haven't evaluated that.)

A module alias turned out to work great. So I removed the bulk of the implementation and just left that alias.

David

David Glick
Web Developer
davidglick-jwYafjbudsc+uJoB2kUjGw< at >public.gmane.org
206.286.1235x32

[http://gw-logo.s3.amazonaws.com/gw-email-signature.png]

GiveBIG is coming! Mark your calendar for May 2 and get ready to give big to Groundwire<http://www.seattlefoundation.org/npos/Pages/Groundwire.aspx> as part of this community-wide day of giving.

Re: Collections portlets

David Glick — 2012-04-09T06:00:38

So now that we've got plone.app.collection in 4.2, how do we want to handle collections portlets?

We currently ship with plone.portlet.collection. plone.app.collection adds its own, largely the same (though missing some of the more recent features/fixes added to the other).

Seems like the latter would be the simpler option.

I made some progress toward supporting new-style collections in plone.portlet.collection (by adding a backward-compatible queryCatalog method to the collection class in plone.app.collection...really not too hard except for figuring out how to get non-IContentListing-wrapped results out of the query builder). Remaining tasks:
- The code path for when the 'random order' option is selected is currently broken. To fix it the BBB queryCatalog needs to accept a sort_on parameter and pass it through to where the query is constructed.
- The plone.portlet.collection functional test needs to be updated to create a new-style collection instead of a Topic.
- We need to figure out what to do with the unnecessary portlet in plone.app.collection. (There have been releases of plone.app.collection so it doesn't seem like we should just remove it. A migration will be a pain since it'll have to find all the portlet assignments to update them. If the 2 portlet assignment classes have the same attributes maybe we can use a module alias, but I haven't evaluated that.)

David Glick
Web Developer
davidglick-jwYafjbudsc+uJoB2kUjGw< at >public.gmane.org
206.286.1235x32

[http://gw-logo.s3.amazonaws.com/gw-email-signature.png]

GiveBIG is coming! Mark your calendar for May 2 and get ready to give big to Groundwire<http://www.seattlefoundation.org/npos/Pages/Groundwire.aspx> as part of this community-wide day of giving.

Collections portlets

Eric Steele — 2012-04-01T23:04:33

So now that we've got plone.app.collection in 4.2, how do we want to handle collections portlets? 

We currently ship with plone.portlet.collection. plone.app.collection adds its own, largely the same (though missing some of the more recent features/fixes added to the other). 

Should the p.a.collection version be made the default (and updated for parity with p.portlet.collection) or should p.portlet.collection be updated to handle the newer collections (and remove the portlet functionality from p.a.collection)?

Seems like the latter would be the simpler option.

Eric

FWT Meeting Minutes=?utf-8?Q?=E2=80=93=C2=A0March_?=27, 2012

Eric Steele — 2012-03-27T18:48:28

Been meaning to do this for a while, but got a bit of a kick in the pants this week. Previous meeting minutes are at http://bit.ly/plonefwt. I'll make no guarantees of the quality of the notes taken, but some info is better than none. -- Eric

March 27, 2012 – Framework Team MeetingAttending: Eric Steele, Ross Patterson, Elizabeth Leddy, Alec Mitchell, Craig Haynal
Absent: Martijn Pieters, Rob Gietema, Laurence Rowe
David Glick has offered to rejoin the FWT. All in favor.
4.2 blockers cleared. Eric is fixing some failing tests. RC1 this week, hopefully.
Can we get minutes out to the developers? Yes. We’ll start today.
#12452 (plone.app.jquery) merged into 4.2.
#12350 (Integrate portions of jQuery UI)
Portions (if not all) of this are integrated into the theme editor PLIP
Any objections to this moving forward? None.

#12776 (Remove kupu):
Simple change, largely removed already.
Would be good to pull out tools (link checker, etc) for general use. They’re handy, but this isn’t a requirement.

12110 (Plain text searches ignore accents):
Looks good, but could use review by another with i18n experience.

10959 and 12521: Eric will contact the implementers to see if they’re willing to pool resources
When can we start merging to a 4.3 branch? Eric is trying to keep only 2 active branches going at a time for sanity’s sake. 4.2 is wrapping up now, so will cut a 4.3 branch this week.

Next meeting: Apr 10.

Audio: http://apps.calliflower.com/recording/download/24017?rec_key=bd4fd9981d9eaa2261899e06e59cf18cd3478543

Plone FWT Meeting Minutes: http://bit.ly/plonefwt

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

Martin Aspeli — 2012-03-08T16:53:45

H Denys,

On 8 March 2012 09:38, Denys Mishunov <denys.mishunov-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:
wrote:

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

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

Martin Aspeli — 2012-03-08T11:22:18

Hi,

Ok, so some answers here. I still need to digest Denys' comments.

First off, I think the mockup is great. :)

On 8 March 2012 10:44, Ramon Navarro Bosch <ramon.nb-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

I think it makes sense to show it at the bottom. I am nervous about
hiding it. The Diazo rules syntax is sufficiently flexible that any
scheme to hide this could lead to unexpected behaviour, even broken
themes, with little or no ability for the user to understand.

Making it possible to build themes entirely through point-and-click is
a laudable goal. However, it's going to need to be the next version of
this, and Diazo itself will likely need to evolve somewhat for this to
be possible in a safe way. The mapper is there to *help* you build the
theme, not take away all need to understand Diazo. That's also why we
put in the inline help.


We could add this as text input, maybe, but I don't know how to make a
UI for all the different types of conditions. It also gets complex
because you'd often put conditions on a nested <rules /> element.
Again, this is where you as a themer need to have some understanding
of how Diazo works and make some choices about how you structure your
rules. A system like Plone - and most static web designs - are simply
too complex to make simple point-and-click anything more than a neat
technology demo.


What is 'new static file'?


Maybe an option to temporarily hide it? Or having it appear minimized
but opening when necessary? I want to make it quite clear that there
is that file there, and that the file is very important to how the
theme works.

Martin

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

Martin Aspeli — 2012-03-08T11:13:48

Hi,

Thanks for this! Let me digest more fully in light of Denys' comments as well.

One thing I wanted to say, however: The goal of this is not to
completely hide the XML rules syntax. We want to help people write the
rules file, but we are not, yet, mature enough to be able to make
theming a fully point-and-click experience, and you need to be able to
think about things like conditionals and sequence. If we hide the
output, people will be confused when it doesn't work perfectly as
they'd expected.

I'm not sure if this was clear to the reviewers?

Martin

On 8 March 2012 10:44, Ramon Navarro Bosch <ramon.nb-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

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

Ramon Navarro Bosch — 2012-03-08T10:44:37

I've shown it to our designers in order to recive feedback, they said to me
:

* It's now understable how the mapper works, the feeling that you can
choose the elements on content and theme makes you feel that you can assign
rules only saving the elements and is not easy to understand.

* One suggestion they made is  not showing the rules files by default, just
show the new rules button, then the two screens of origin-theme , with the
result at the end and a option of where you want to store the new rule ( a
list of levels on the rule's xml so you decide to add it on the
visual-wrapper, ... any other point.

* The option to add the rule with conditional

* On the new rule option should be a first option of which kind of rule,
new static file, ...

* There should be an option to see the rules file ( that is on the editor )
so people dont' get messed with it.

I'm sending an image that as we say in catalan: it's more important a image
than 1000 words

Ramon



On 8 March 2012 10:38, Denys Mishunov <denys.mishunov-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

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

Denys Mishunov — 2012-03-08T09:38:13

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

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

Denys Mishunov — 2012-03-08T08:52:20

Hello Martin, all

On Tue, Mar 6, 2012 at 1:54 PM, Martin Aspeli <optilude+lists-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

I have submitted my UI review to the plip ticket. I am not sure
whether I have had to add it somewhere in the buildout though, but I
didn't find Rob's review anywhere on FS, only in the ticket so did the
same. If the review should live somewhere else, please let me know and
I will copy it there.

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

Martin Aspeli — 2012-03-06T13:00:53

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.


I don't disagree with any of those points.


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.


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