10 Jun
2011
10 Jun
'11
5:49 p.m.
Hi Marius,
Some feedback received about the WYSIWYG Administration:
- some people tough that "Application" is not the best place for this
settings, suggested "Content" or "Configuration" - near the "Edit
mode
Settings". The Idea was that the WYSIWYG is not actually an application but
something that is basic to XWiki and deep embedded in it.
- although they had an auto-complete for the plugins and the menu bar, they
wanted a link to the documentation (something like we have for the
"Registration") were they could see all the existing plugins (also mention
the dependencies between plugin and toolbar). The problem was that they
didn't knew what letter the plugin name was starting - so that the
auto-suggest to be activate. Another solution is to automatically show the
suggest if the user stagnates in the input more than 2 second.
- another comment was that they expected to see the "Font-family" and
"Font-size" activated (if you are able to configure it, you are able to use
it - without the need to add the plugins, etc). This can be solved by
enabling the features by default (someone especially said they wanted the
Font-family - in order to behave more like Word).
- also would be very nice - if the user selects in the toolbar "fontsize" to
automatically activate the plugin, without the need to put it manually (or
read the documentation). First I tough I need to restart the server in order
for the changes to be activated (and wanted to suggest that you need to give
me a warning that I need to restart the server - but after that I remembered
that I need to combine the fields and activate the plugin).
As a general feedback everyone liked the way the settings look, are
organized and behave and they want to make it a standard for the other
Administration sections.
Thanks,
Caty
On Thu, Dec 23, 2010 at 16:49, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
On 12/23/2010 10:39 AM, Marius Dumitru Florea wrote:
Indeed, my bad. The current title is good, but the hint should be changed.
Didn't see an autosuggest when I tried it, so I assumed there isn't one.
I tried typing "a" and waited for suggestions, but nothing popped up. I
tried now with "s" and indeed I got some suggestions. So, to make it
better, we should try to fix the bug with the down arrow (tried that as
well but it didn't work), and maybe display a "no results" when there
aren't any items that match the current input.
http://incubator.myxwiki.org/xwiki/bin/Standards/FormVerticalUsage#HFormExa…
OK, this is the best approach. I did the same for the sharepage feature.
Hi Sergiu,
On 12/23/2010 05:14 AM, Sergiu Dumitriu wrote:
> On 12/21/2010 02:45 PM, Marius Dumitru Florea wrote:
>> Hi devs,
>>
>> Following
>> http://lists.xwiki.org/pipermail/devs/2010-November/021012.html I made
>> some improvements and now I have this
>>
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/WysiwygEditorConfig
. I'd like to include it in XE 3.0.
WDYT?
Some nitpicking:
Enable or disable the WYSIWYG/Source tabs. [ ]
Yes [ ] No
^ This isn't a yes/no question. How about:
1. [ ] Enable the Source tab
2. [ ] Display WYSIWYG/Source tabs
1 says that only the WYSIWYG mode is enabled, while 2 says that both
modes are enabled, just that there's no UI to switch between them, but
either one can still be displayed by other means (JS scripting or field
configuration). Personally I prefer the wording of 1, even if 2 is the
actual implementation, since it's more user friendly.
The actual configuration name is "Source editor enabled". Isn't this
equivalent to "Enable the Source tab" you are proposing? I avoided
"tab"
in configuration name because (1) it refers to an UI implementation
detail and (2) it can also mean the white space "tab" character.
"Enable or disable the WYSIWYG/Source tabs" is the hint. "Display the
WYSIWYG/Source tabs" sounds indeed better.
Inputs: I'm not sure a text input is the best element here, can't a
select be used?
plugin, menu bar and tool bar inputs are autosuggest enabled. You should
be able to open the list with all the suggestions by pressing down arrow
key but there is a bug in scriptaculous that prevents this. I have a
patch for it. I can't replace the tool bar input with a
select because you can place
macro shortcuts like "macro:foo" on the tool bar and "foo" macro
might
not be available when you configure the WYSIWYG editor.
OK.
Lists: I think that "Drag and drop to change the order" is not a very
useful tooltip, is it possible to have an item description instead? If
not possible yet, something to keep in mind for the future.
I agree that this is something to add in the next iterations. Right now
the editor doesn't support plugin/feature description.
>
> Yes/No radio buttons: Usually checkboxes are better for this. You can
> see this proposed in the forms standard as well:
>
Using checkboxes was my initial intent but:
* display method generates a PRE tag which is a block level element thus
technically invalid inside a DT (promoted by the form standard)
This MUST be fixed in the platform.
* I wanted to write the class sheet using only
wiki syntax, i.e. without
HTML and for checkboxes, unlike for the rest of the input fields, the
use of the LABEL HTML element is kind of required (you should be able
check/uncheck by clinking on the label).
Well, we should use labels for all the fields anyway. It fails WCAG
validation if inputs don't have an associated label. In the future we
should have a {{field}} macro which generates the right syntax.
For the moment I'd say that you should use the {{html}} macro, keeping
in mind that once the platform advances it should be refactored.
Font sizes: I agree that pt is the better unit here. Even though px is
the standard unit on the web, the WYSIWYG is mostly trying to emulate
Office applications, where the pt is the preferred unit.
Overall, this looks very nice. +1 for committing it.
Referring to the other thread about committing the forms standard in the
platform, I'm planning to do that in the coming days. How do we make
sure we're not overlapping?
I copied the form styles in a style sheet extension object. I can drop
this object after you commit the form styles in the skin. Something we need to take care is the class name
on the form element. In
some cases the form element is not accessible (edit and inline modes)
and thus we can't add the "xform" class name. I must have the form
styles applied on my class sheet when in inline edit mode.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs