Hi all, I'd like to investigate the possibility of doing some UI improvements to the Zope Management Interface. Is there someone that is considered the godfather of the current Zope user interface that I should coordinate with? The things I want to fix are tiny, but important things. I'm not planning to rewrite any logic, most of what I want to do is to clean up structures, more logically organize things (but leave them on the same page), fix annoying consistency issues and scary behaviour (Update Catalog button right next to the Clear Catalog button, anyone?) - but leave everything else alone. How would I approach this, process-wise? I assume I cut a branch and work off that, but I'd like to not do too much work that doesn't get used - hence, I'd like to know whether people have special attachments to the current way things work and are laid out before I invest time in improving things. -- _____________________________________________________________________ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _____________________________________________________________________ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone
--On 18. November 2005 06:27:38 -0800 Alexander Limi <limi@plone.org> wrote:
How would I approach this, process-wise? I assume I cut a branch and work off that, but I'd like to not do too much work that doesn't get used - hence, I'd like to know whether people have special attachments to the current way things work and are laid out before I invest time in improving things.
In general such changes should be made on the HEAD (for next 2.10 release). I assume you want to change templates here and there ...so your changes won't affect major parts of the core. Depending on the number of changes a branch might make sense, possibly not when the changes are isolated. Do you have checkin permissions on svn.zope.org? Andreas
On Fri, 18 Nov 2005 06:56:32 -0800, Andreas Jung <lists@andreas-jung.com> wrote:
In general such changes should be made on the HEAD (for next 2.10 release).
OK. I was aiming for a quick sprint to get some small changes into 2.9 before release (ie. no actual code changes, just moving text and eliminating HappyTalk™ to make the interface usage clearer).
I assume you want to change templates here and there ...so your changes won't affect major parts of the core. Depending on the number of changes a branch might make sense, possibly not when the changes are isolated. Do you have checkin permissions on svn.zope.org?
I think so, I got ChrisM to help me update my public key at the Plone sprint in San Jose. I'll give it a shot later. Please note that I'm not promising anything at this point (my workday is hectic enough as it is), but just making sure I don't do anything stupid once I get around to actually doing something. Can't say I'm looking forward to editing DTML, though - but I guess I'll just have to hold my nose for the greater good. ;) -- _____________________________________________________________________ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _____________________________________________________________________ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone
On 18 Nov 2005, at 23:19, Alexander Limi wrote:
On Fri, 18 Nov 2005 06:56:32 -0800, Andreas Jung <lists@andreas- jung.com> wrote:
In general such changes should be made on the HEAD (for next 2.10 release).
OK. I was aiming for a quick sprint to get some small changes into 2.9 before release (ie. no actual code changes, just moving text and eliminating HappyTalk™ to make the interface usage clearer).
IMHO if this is just UI changes that improve usability it should be OK to flout the rules a bit. The rules are there to ensure code quality and stability in a release branch - I doubt small UI changes endanger those. jens
Jens Vagelpohl wrote:
IMHO if this is just UI changes that improve usability it should be OK to flout the rules a bit. The rules are there to ensure code quality and stability in a release branch - I doubt small UI changes endanger those.
Beware the slippery slope to hell, paved with good intentions ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Mon, 21 Nov 2005 06:47:34 -0800, Chris Withers <chris@simplistix.co.uk> wrote:
Jens Vagelpohl wrote:
IMHO if this is just UI changes that improve usability it should be OK to flout the rules a bit. The rules are there to ensure code quality and stability in a release branch - I doubt small UI changes endanger those.
Beware the slippery slope to hell, paved with good intentions ;-)
I can assure you that I have no good intentions whatsoever, just a desire to see the "I clicked the Clear Catalog button, now what do I do" questions on plone-users decrease. Pure annoyance-driven development. ;) -- _____________________________________________________________________ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _____________________________________________________________________ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone
Alexander Limi wrote:
I can assure you that I have no good intentions whatsoever, just a desire to see the "I clicked the Clear Catalog button, now what do I do" questions on plone-users decrease.
I thought that was how you got a Plone upgrade to work in less than a day ;-) (...and then Find stuff back into the catalog afterwards...)
Pure annoyance-driven development. ;)
Indeed, but my comment wasn't so much about this particular change, it was about the principle of it. If 2.9 is already feature-frozen, then we're setting a dangerous precedent for allowing feature changes on it. "well, if he did it, why can't I? My changes are just as small" etc... There's also something to be said for keeping the UI as consistent as possible once a branch is feature frozen, no matter how bad it is. How do others feel about this? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Alexander Limi schrieb:
On Fri, 18 Nov 2005 06:56:32 -0800, Andreas Jung <lists@andreas-jung.com> wrote:
In general such changes should be made on the HEAD (for next 2.10 release).
OK. I was aiming for a quick sprint to get some small changes into 2.9 before release (ie. no actual code changes, just moving text and eliminating HappyTalk™ to make the interface usage clearer).
I got a small UI patch to have product icons in the add-dropdown which turns out to reduce the mistakes on klicking on the wrong product to add to a minimum. Maybe you like to include it too? http://www.zope.org/Members/tino/PatchObjectManager-1.0/view It could even get some improvements - grouping factories by product could even help if the list is very long. Just some thoughts. ++Tino
--On 22. November 2005 09:11:13 +0100 Tino Wildenhain <tino@wildenhain.de> wrote:
Alexander Limi schrieb:
On Fri, 18 Nov 2005 06:56:32 -0800, Andreas Jung <lists@andreas-jung.com> wrote:
In general such changes should be made on the HEAD (for next 2.10 release).
OK. I was aiming for a quick sprint to get some small changes into 2.9 before release (ie. no actual code changes, just moving text and eliminating HappyTalk™ to make the interface usage clearer).
I got a small UI patch to have product icons in the add-dropdown which turns out to reduce the mistakes on klicking on the wrong product to add to a minimum. Maybe you like to include it too?
http://www.zope.org/Members/tino/PatchObjectManager-1.0/view
It could even get some improvements - grouping factories by product could even help if the list is very long.
Since 2.9 is delayed until Zope 3.2 is ready for beta 1 you could commit it to the HEAD and 2.9 branch. -aj
Andreas Jung schrieb:
--On 22. November 2005 09:11:13 +0100 Tino Wildenhain <tino@wildenhain.de> wrote:
Alexander Limi schrieb:
On Fri, 18 Nov 2005 06:56:32 -0800, Andreas Jung <lists@andreas-jung.com> wrote:
In general such changes should be made on the HEAD (for next 2.10 release).
OK. I was aiming for a quick sprint to get some small changes into 2.9 before release (ie. no actual code changes, just moving text and eliminating HappyTalk™ to make the interface usage clearer).
I got a small UI patch to have product icons in the add-dropdown which turns out to reduce the mistakes on klicking on the wrong product to add to a minimum. Maybe you like to include it too?
http://www.zope.org/Members/tino/PatchObjectManager-1.0/view
It could even get some improvements - grouping factories by product could even help if the list is very long.
Since 2.9 is delayed until Zope 3.2 is ready for beta 1 you could commit it to the HEAD and 2.9 branch.
Fine. Is this yet part of the discussion "yes, we want that" or "well, if you cant hold it..."? ;) Some +1 on the matters could motivate :-) Here is the list w/ "improvements" ante portas: 1) Icons for add-dropdown list 2) History + History compare for all objects and more useable diff 3) warning when commiting stale edit forms in ZPT, python script (expect hight discussion here ;)
Tino Wildenhain wrote:
Here is the list w/ "improvements" ante portas:
1) Icons for add-dropdown list
+1
2) History + History compare for all objects and more useable diff
+10 ...but how does this work when the objects can't sensible show history or be compared?
3) warning when commiting stale edit forms in ZPT, python script (expect hight discussion here ;)
-0 cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers schrieb:
Tino Wildenhain wrote:
Here is the list w/ "improvements" ante portas:
1) Icons for add-dropdown list
+1
2) History + History compare for all objects and more useable diff
+10
...but how does this work when the objects can't sensible show history or be compared?
Not sure which objects would fall in this category. All Objects in ZODB have their history - they just dont show it by default. Comparison is of course specific to a class. Historycopy is of course another thing. It works for all objects but especially folders are a bit sensible if some subobjects got renamed - thats why I dont support history copy on folders.
3) warning when commiting stale edit forms in ZPT, python script (expect hight discussion here ;)
-0
Not so hight as expectted ;)
Tino Wildenhain wrote:
Not sure which objects would fall in this category. All Objects in ZODB have their history - they just dont show it by default. Comparison is of course specific to a class.
Indeed, how will this work?
Historycopy is of course another thing. It works for all objects but especially folders are a bit sensible if some subobjects got renamed - thats why I dont support history copy on folders.
OK. So, how's this coming? ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers schrieb:
Tino Wildenhain wrote:
Not sure which objects would fall in this category. All Objects in ZODB have their history - they just dont show it by default. Comparison is of course specific to a class.
Indeed, how will this work?
Historycopy is of course another thing. It works for all objects but especially folders are a bit sensible if some subobjects got renamed - thats why I dont support history copy on folders.
OK.
So, how's this coming? ;-)
You can check the principle with my old monkey-patch proof of concept. Due to changes of the extensionclasses, it only works with 2.7. I've got working code for 2.8 here, but I dont want to maintain it as monkey patch anymore. http://www.zope.org/Members/tino/PatchHistory/view Regards Tino
On 18 Nov 2005, at 09:27, Alexander Limi wrote:
I'd like to investigate the possibility of doing some UI improvements to the Zope Management Interface. Is there someone that is considered the godfather of the current Zope user interface that I should coordinate with?
I don't think there is any specific person to coordinate with, I'm sure your changes can be described in words and just put in front of the list to get feedback :) jens
participants (5)
-
Alexander Limi -
Andreas Jung -
Chris Withers -
Jens Vagelpohl -
Tino Wildenhain