+1-888-365-2779
Try Now
More in this section

Forums / Sitefinity UX / Radeditor improvements

Radeditor improvements

11 posts, 0 answered
  1. Jochem Bökkers
    Jochem Bökkers avatar
    787 posts
    Registered:
    13 Aug 2007
    26 Sep 2011
    Link to this post
    Inherited configfile.xml
    The ability to group certain RadEditors together with custom theme/styling. Ideally this would be done in Administration where you'd have a base config and you could define sub-sections. For instance, if nothing is set the 'global' config is used. But an admin would be able to create a config 'actual' and assign a different configfile.xml to the content types news and blogs so authors and editors would have a limited/alternative set of controls/styles. 

    This way one can for instance make sure that no flash/video/etc is incorporated in news/blog items or apply a subset (stricter) set of paragraph styles so users can easier style the content.

    ---

    Role/User based RadTools.xml
    This will allow us to for instance enable the HTML tab for Editors/Admins while Authors wouldn't be allowed to see/access that tab.

    ---

    Auto assign dictionary based on selected language. 
    I understand that 'officially' only en, de & fr are supported by Telerik but there are many more RadEditor dictionaries available. It would be great if these could be included in language pack downloads.
    (If my website is NL, I'm probably not gonna need the included RadSpell files but manually need to find and include the Dutch one).

    Ideally we'd be able to set in administration to which one would be allowed and then based on which localized content is being edited that is the suggested (while not limited) spellchecker.

    ---

    Extended preview functionality.
    Most often the content:placeholder where a content block is placed in will be encapsulated inside a div which adds additional styling to it. This styling however isn't visible when editing in the RadEditor. A 'Preview' pane which inherits the upper class from the parent <div> would be great.

    Imagine an aside with a header/image/content. It has fixed/alternate styling to ensure proper looks/width/height. The header may have a background red with text set to white styled in the enclosing div while the general style is set to red text on a white background. 

    While editing in the RadEditor, you don't see the background red/text white applied because it's un-aware of it's enclosing class.

    Enhancing the preview pane with something like (parentNode.className) would be awesome...


  2. Markus
    Markus avatar
    2763 posts
    Registered:
    25 Nov 2005
    29 Sep 2011
    Link to this post
    I for one would love an Admin section that has the following

    Bold  checkbox (basic) checkbox (advanced)
    Italic checkbox (basic) checkbox (advanced)
    haeder checkbox (basic) chekbox (advanced)

    start bacic (true, false)

    so a admin could with simply checking checkboxes decide if a tool would be shown in basic, advanced or both modes.

    -----------------------
    css files

    a) Link to css styles to be shown under styles
    b) maybe another link for the css styles in the editor area to be used.

    ------------
    Dictionaries.

    I have stated this so many times. Include all backend languages by default. Make them checkbox selectable. No hassle to extra import, add and stuff

    Add all dictionaries for the enabled backend languages to rad editor.

    Maybe again an option like above

    EN dictionary (checkbox, yes, no)
    DE dictionary (checkbox. yes, no)
    ------------

    If all that fails at last move the headres to basic!!! If this has not happened on 4.2 SP1 thats an old request I am sure 95% of the users would vote yes!

    Markus

  3. Georgi
    Georgi avatar
    3583 posts
    Registered:
    20 Sep 2016
    29 Sep 2011
    Link to this post
    Hi guys,

    Thanks for the suggestions! I'll share what our plans are at the moment.

    We believe that the RadEditor settings are not something that you change on daily basis, even more - once you set it up, it stays like this until the next CMS comes :) At least this is what our experience shows. For example, the RadEditor on telerik.com's backend is not changed since the first launch of the web site. Even after web sites rework in form of new themes, the CSS is the only thing that is modified, but often designers tend to change the .css files themselves, they do not touch the editor. 

    So in general, there are two main editor instances - one for the content creation and one for the comments. Why not provide the people a way to quickly change them? Then of course, someone may want a specific instance of the RadEditor to behave differently, so we need a way to create a configuration and assign in to any instance. This is a rare case compared to the to main editor instances (content creation and comments), so this can be advanced setting. Every custom configuration could have its own name so the assigning of the instance to the configuration is easy.

    Based on this assumptions, the attachment shows what we are planning to have in the first version of the feature. We also assume that the configurations will be done by technical people - the content creator won't be able to set styles in the Paragraph dropdown since he lacks in web design skills. As for the Bold/Italic/Etc buttons, they are required for absolutely every editor. What do you think?

    I am moving the discussion in the UX forum.
     
    Regards,
    Georgi
    the Telerik team
    Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
  4. Markus
    Markus avatar
    2763 posts
    Registered:
    25 Nov 2005
    29 Sep 2011
    Link to this post
    Dear Georgi

    a) Even for technical experianced people its quicker to have checkboxes then do change code in an xml file  
    -> Telerik does once a xml creation with checkboxes and we will benefit from it for the next 2 years :-)

    b) For me I like the Basic / Advanced settings. I was not talking about removing Bold or so more like haveing the ability to have things in Basic or Advanced mode. Like Headings.

    Looking forward to it in 4.??

    Markus

  5. Jochem Bökkers
    Jochem Bökkers avatar
    787 posts
    Registered:
    13 Aug 2007
    29 Sep 2011
    Link to this post
    @Georgi

    I love this! Both the RadEditor improvements you're already planning and the 'architectual/roadmap' discussion... 

    I'm really missing that because they're not adressed in either partner/dev or business webinars and it's great to catch glimpses of the future and talking about them.

    ---

    This looks to me a perfect start, the ability to set custom xml file was no 1 on my list and this implementation looks even better with a seperate part for comments. 

    You're talking about a 'configuration xml' so I'm assuming you're talking about a configuration.xml and not a radtools.xml file correct? So in this case we can set the toolbar and language in one setting and inside the tools.xml you have a reference to the css file applied. So that's point 1 and 3 off the table :)

    I had user/role based radtools.xml on the wishlist, which is wrong because the html/preview tab is set in the configuration.xml. And I understand it would become really complex to maintain custom configurations in combination with permissions and it would break RadControls compatibility if you adopt to a custom xml file.

    Perhaps we can set up global override for the Radeditor views (design/html/preview) ?

    If in the admin section you create an option for role based panes (independent of the config files) where you can set it to inherit (from the config file) or override (for instance admin/editor has html, author has not) and call that directly from the  <telerik:RadEditor EditModes="Design,Preview" ConfigFile="~/whatever.xml">
    inside the code, that should work without making it to complex to maintain and without breaking RadControls compatibility no?

    The HTML tab may not seem as a big issue, but I've always thought of it as a dangerous pane for people who don't understand what they're doing but indispensable for a pixelperfect idiot like myself.

    Perhaps we can take a vote on it somewhere? To really see how important it is?

    ---

    @Markus
    On this issue, I have to disagree with you, a standard xml file is way more valuable and easier to drop in a new project than manually setting 20 checkboxes for each new project. Drop me a mail on a desired toolbar configuration you'd like and I'll gladly send it back...

    Jochem.
  6. Antoaneta
    Antoaneta avatar
    258 posts
    Registered:
    02 Nov 2015
    30 Sep 2011
    Link to this post
    Hi Jochem, Markus,

    Thank you very much for the feedback. Please take a look at the attached screenshot from the Rad Editor settings wireframe. In this screen the labels are slightly changed and we will be happy to hear  what do you think.

    Kind regards,
    Antoaneta
    the Telerik team
    Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
  7. Jochem Bökkers
    Jochem Bökkers avatar
    787 posts
    Registered:
    13 Aug 2007
    30 Sep 2011
    Link to this post
    Hey Antoaneta,

    Looks more intuitive with a big 'default' on top.

    Personally I'm more inclined to the word 'configuration' than tools set, but that depends on what you're storing.

    The word 'configuration' lead me to believe some sort of RadEditor standard 'configfile.xml' the word 'tool set' gives me the idea you're gearing up for a 'radtoolsfile.xml'.

    In the config scenario we'd have the ability to set dictionary language, view-modes and tools. If you're opting for the toolsfile scenario we'd not be able to set those.

    I understand that a 'config scenario' adds complexity to the system, because it would mean developers would still have to manually set the radtoolsfile.xml and inside that you'd point to the class.css but it would allow for far greater flexibility.

    In my opinion, go for flexibility and offer a default configfile.xml and radtoolsfile.xml on a file basis (not embedded). Then even 'novice' developers can copy paste those and make the alternations.

    But it allows more complex scenario's to be handled out-of-the-box without coding/overriding the base editor and having to keep your fingers crossed with every upgrade.

    ---

    If you're still rooting for the 'radtoolsfile.xml' scenario, I'd still change "tool set"  to "editor set" or something equivalent to make it clear its the toolbar+classes css. The term 'tool' is to much linked to the toolboxes configurations.

    J.
  8. Steve
    Steve avatar
    3037 posts
    Registered:
    03 Dec 2008
    30 Sep 2011
    Link to this post
    I for one...am excited by that wireframe :D
  9. Antoaneta
    Antoaneta avatar
    258 posts
    Registered:
    02 Nov 2015
    04 Oct 2011
    Link to this post
    Hi Steve, Jochem,

    Thank you very much for the valuable feedback and comments. We will discuss the labels once again internally and will take in mind all the suggestions you gave.

    Best wishes,
    Antoaneta
    the Telerik team
    Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
  10. Markus
    Markus avatar
    2763 posts
    Registered:
    25 Nov 2005
    08 Nov 2011
    Link to this post
    Has this been implemented in 4.3 or is it planned for 4.4?

    http://www.sitefinity.com/ClientsFiles/303637_RadEditor-settings-2.png

    Markus
  11. Antoaneta
    Antoaneta avatar
    258 posts
    Registered:
    02 Nov 2015
    11 Nov 2011
    Link to this post
    Hello Markus,

    This feature is in the plans but it is not scheduled yet and we cannot tell you for sure whether it will be included in the 4.4 release or not.

    Best wishes,
    Antoaneta
    the Telerik team
    Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
11 posts, 0 answered