|
Author
|
Message
|
|
Knut Urdalen
Moderated by: Nicolas Pastorino
|
Wednesday 14 November 2007 7:01:14 am
One feature I miss in eZ Publish is "content class description" and "content class attribute description" in the admin-interface. This would be really helpful to create a more descriptive inline comments, an hence lighten the learning curve a bit. As a developer you could describe the classes and attributes as part of the setup so it's much clearer to the authors and editors what the various fields are actually used for.
Examples:
- "Short title - used in menus"
- "Valid from - the offer is only valid from this date"
- "Image - Max file size: 16 MB"
- "Alternative text - used for search engine optimization and for people with screen readers (set it to the same as the title)"
- "Banner URL - where to go when you click on the banner, please use an absolute URL" You get the idea :) I see now that this could be done in the title of the field, but I think it's best to seperate the title and description so you can have more lines of description. I'm wondering if this is a solution that could be custom made or has to be built in to the core.
|
|
André R.
|
Wednesday 14 November 2007 2:51:50 pm
I have suggested this internally before but forgotten about it.
It' shouldn't be to hard to implement, so I suggest you write a enhancement issue on it and get people to vote on it. However my suggestion also included a way to categorize attributes. For instance you always have a lot of meta attributes that are not meant to be shown on the front end(show_children,allow_comments), and some 'class_meta' attributes shouldn't even be shown to editors while editing (number_of_children). Basically allowing us to use far more generic templates and control a lot more with classes and the role system..
eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom
|
|
Heath
|
Wednesday 14 November 2007 3:10:17 pm
This is a great suggestion in general and I really like André R.'s specific views on the topic. <i>@Knut</i> Please file an enhancement request and publish the link to the issue you file here back in this forum thread for others to promote, subscribe and vote for ...
Cheers,
Heath
Brookins Consulting | http://brookinsconsulting.com/
Certified | http://auth.ez.no/certification/verify/380350
Solutions | http://projects.ez.no/users/community/brookins_consulting
eZpedia community documentation project | http://ezpedia.org
|
|
Sylvain Bannier
|
Thursday 15 November 2007 12:21:07 am
Hi,
I'm insterested in this feature too.
It would be great to display forms labels, tooltips and to export documentation about classes.
I've submited an ehancement request #011932
http://issues.ez.no/IssueView.php?Id=11932&activeItem=1 Hope you don't mind.
http://www.smile.fr
|
|
André R.
|
Thursday 15 November 2007 1:57:19 am
eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom
|
|
Knut Urdalen
|
Thursday 15 November 2007 6:12:46 am
Usability wise I suggest that the attribute description should be displayed inline after the actual input fields (see http://www.urdalen.com/ez/attribute_description.png ). It's secondary information for those who care, but it should not be hidden and require additional user interaction to see it.
Attribute groups would be a nice addition for complex classes. When composing a new content class with attribute groups you would have some attribute groups that include required fields and should be expanded by default and some groups that contain additional information and could be collapsed by default so the user don't get scared about all the input he need to fill out (see
http://www.urdalen.com/ez/attribute_groups.png ).
|
|
André R.
|
Thursday 15 November 2007 7:56:17 am
I agree, but aren't those screenshoots taken in drupal?
Bless you!</joke>
eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom
|
|
Knut Urdalen
|
Thursday 15 November 2007 1:11:44 pm
That's correct. Just used them to explain what I had in mind ;)
|
|
Heath
|
Thursday 15 November 2007 1:33:52 pm
@Knut I don't mind where they came from :) I studied these before some time ago yet hesitated stepping up to make the very suggestion you have. I think using them as examples of just one possible improved default design / solution is valid. In the end these are valuable features which I think are worth incorporating into future versions of eZ Publish and so do a number of others silently agreeing with you. This exact example might not be needed by everyone but in general we would prefer to have these features (which we could omit or disable ourselves as needed later).
Cheers,
Heath
Brookins Consulting | http://brookinsconsulting.com/
Certified | http://auth.ez.no/certification/verify/380350
Solutions | http://projects.ez.no/users/community/brookins_consulting
eZpedia community documentation project | http://ezpedia.org
|
|
André R.
|
Thursday 31 January 2008 1:28:32 pm
Some more discussion about class enhancements:
http://ez.no/developer/forum/suggestions/integrity_flag_element_in_the_class_definition
eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom
|
|
Mark Marsiglio
|
Thursday 31 January 2008 9:14:56 pm
How about the Attribute Help Text extension? I use this all the time and it does pretty much exactly what is described above. http://ez.no/developer/contribs/hacks/attribute_help_text
http://www.thinkcreative.com
Turning Ideas Into Strategic Solutions
|
|
André R.
|
Friday 01 February 2008 12:25:56 am
Looks like a fine extensions, but I think this suggestion aims at using the db instead of ini files for the description text. It's also a requirement that the helper text is translatable. And while on it the default values on ezstring and some other datatypes should also be translatable.
eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom
|
|
Piotrek Karaś
|
Wednesday 30 July 2008 9:24:52 pm
Sylvain wrote: I've submited an ehancement request #011932
http://issues.ez.no/IssueView.php?Id=11932&activeItem=1
This issue seems to be closed... why? I'd also would like to support this class/attribute extra info idea. While I like other suggestions as well, this one seems very easy to implement, carries little risks and in my opinion brings the biggest value around. Also, when it comes to extra information, here's my thoughts on the subject: There should actually be two extra text fields per class and per attribute. One user-dedicated translatable extra info/hint/help-like attribute that was discussed that could be used for inline or popup suggesions, help, hints etc. Second, translatable or not - not sure, admin/developer-dedicated for stored implementation documentation, that would never be visible for end-users. While managing attributes is meant to be easy in eZ, it is actually not trivial if you change some settings in class definition and may lead as far as loosing data or turning the site upside down. It would be great to make an implementation doc in the classes, first for having them there to read before any change, second for being able to export/print a documentation when the implementation is ready. What do you think about it? It would great if those features (especially those easy ones) could make it into 4.1... ;)
--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu
|
|
Kristof Coomans
|
Thursday 31 July 2008 12:36:44 am
Hi Piotr This specific issue you refer to was closed as a duplicate, because it was requested before. The original enhancement request is linked to, check under "Links". Cheers
independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org
|
|
Pascal von Büren
|
Thursday 31 July 2008 2:09:57 am
Hi everybody, we have solved this problem (at least for our needs) by creating a new datatype, that doesn't store anything on object attribute level, only on class attribute level. So you can easily add a new attibute above (or below) an other attribute that needs some explanation. The rest is up to the template you create for the edit interface.
Screenshot of the class edit interface (notice the <b>Infoelement</b> Attibute:
http://snapcat.ch/var/storage/images/supplynet/companies/snapcat/eigene_objekte/benutzer/benutzer/pascal/demo_bilder/class_level/61733-1-ger-DE/class_level.png
Screenshot of the obejct edit interface (notice the yellow boxes):
http://snapcat.ch/var/storage/images/supplynet/companies/snapcat/eigene_objekte/benutzer/benutzer/pascal/demo_bilder/object_level/61749-1-ger-DE/object_level.png If this could help anybody, I'm free to share this as a contribution, just ask...
|
|
Piotrek Karaś
|
Thursday 31 July 2008 6:05:51 am
we have solved this problem (at least for our needs) by creating a new datatype, that doesn't store anything on object attribute level, only on class attribute level.
Yup, that's definitely doable, it's just slightly against good practices in my opinion - provided you want all of your attributes documented or hint-wise, you double your DB's attribute table row count... That considerably nice solution for occasional use, I agree, but rather not as a standard documentation or hint tool. Actually, you could move your solution out of the class definition, and simply bind a manageable dictionary to attribute IDs + prepare an operator or fetch that would check if there's anything available. It would be less intuitive, but less overheadish. Still, nowhere near solutions suggested above... ;)
Cheers,
Piotrek Edit: It's all about not having to come up with solutions that are expected to be out of the box by many ;)
--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu
|
|
Andreas Kaiser
|
Wednesday 29 April 2009 6:22:23 am
Sorry for opening this old thread... but perhaps this new project can be used in case of needing contextual help / attribute description: http://projects.ez.no/cjw_contexthelp
eZ Partner in Madrid (Spain)
Web: http://www.atela.net/
|
|
jac lee
|
Sunday 07 November 2010 4:17:00 am
One user-dedicated translatable extra info/hint/help-like attribute that was discussed that could be used for inline or popup suggesions, help, hints etc. Second, translatable or not - not sure, admin/developer-dedicated for stored implementation documentation, that would never be visible for end-users, wholesale nike shoes.
|