May 2017 - xwiki-users@xwiki.org

[xwiki-users] Macro Toolbar Option Greyed Out
by Rolf Bernau 16 May '17

16 May '17

Hi, In Xwiki 9.1.2 I have enabled the xwiki-marco toolbar option for the Wysiwig editor, and indeed there is a button shown in the toolbar now. However, this button is greyed out for some reason that I don't know. Would appreciate some help with this. Thanks Rolf

2 4

[xwiki-users] [XWiki Forum] Categories Brainstorming
by Clément Aubin 16 May '17

16 May '17

Hi, What do you think of a «Feedback» category ? I think that if we present a dedicated part of this forum that allows the user to post his feedback, he (the end user) will be more prompt to report any issue / good surprise he had when using the platform. Also, the «Feedback» category is used on https://discuss.gradle.org/. We can also use Tags in the «Help / Discuss» category in order to mark feedback posts. Thanks --- [Visit Topic](https://discourse.xwiki.org/t/categories-brainstorming/23/11) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discourse.xwiki.org/email/unsubscribe/9bba6bdeff443fccc6cf2e5….

2 1

[xwiki-users] Navigation Panel
by Timo Dachs-Wegmann 16 May '17

16 May '17

Hello all, I installed the latest version of XWiki (9.3.1) and I want to get a new navigation panel since my old is a little bit buggy and outdated. I would like to have something like the document tree macro generates with this command: {{velocity}} #panelheader('Navi3') {{documentTree showTranslations="false" showAttachments="false" compact="true" showSpaces="true" limit=20/}} #panelfooter() {{/velocity}} But the problem there is, that I can't blacklist the spaces I don't want to be shown in this list... There was a ticket already with this topic and I posted a comment there, so hopefully they add this "feature" (yes for me it is a needed feature) but I thought maybe you guys have a navigation bar that is generated dynamicly and will work for me. (It should be a tree panel). Something like this: http://test.xwiki.org/xwiki/bin/view/Panels%20Tests/Navigation%20Panel#Atta… Link to the JIRA ticket: https://jira.xwiki.org/browse/XWIKI-12895 Mit freundlichen Grüßen Timo Dachs-Wegmann -EDV- ------------------------------------- PROCITEC GmbH Rastatter Strasse 41 D-75179 Pforzheim Fon: +49 7231 15561-29 Fax: +49 7231 15561-11 Mailto: t.wegmann(a)procitec.de Mannheim HRB 504702 Geschäftsführer: Dipl.-Ing. (FH) Dipl.-Inf. (FH) Jens Heyen

2 2

[xwiki-users] [XWiki Forum] [Help / Discuss] Users (Local or Global) cannot authenticate / log into a new Sub-wiki site
by Michael Dockham 16 May '17

16 May '17

Establishing a multi-instance wiki environment. We successfully setup the first wiki and now setup another one in the same environment and that is where we are having issues. Expectation is that we setup an additional wiki site that can have users log in directly but that does not work - when you attempt to log in with a valid user ID it provides no error message it just prompts you to log in again. We setup another wiki on our instance and we are unable to get any users to authenticate to the site. The workaround is to create users as a Global user and add them to the sub-wiki site's XWikiAllGroup. The use case is to establish another Wiki that we can add outside partner's users to it and segregate them from the main wiki site. The configuration we have for the sub-wiki is as follows: * Any global user can request to join but an admin must accept Main Wiki is setup for LDAP - the sub-wiki is NOT. xwiki.cfg #-# The following line is used to enable LDAP. See the LDAP section for more detail. xwiki.cfg:322 xwiki.authentication.authclass=org.xwiki.contrib.ldap.XWikiLDAPAuthServiceImpl LDAP Enable or not LDAP authentication for this wiki. If enabled and configured properly, a local user will be created whenever a LDAP user visit this wiki for the first time. Yes TRY LOCAL LOGIN If ldap authentication fails for any reason, try XWiki DB authentication with the same credentials. Default is yes Yes List of Installed Software xwiki-enterprise-web-9.3.1 jetty-distribution-9.4.4.v20170414 openjdk version "1.8.0_121" mysql-connector-java-5.1.41 mysqld Ver 5.5.54 for Linux on x86_64 (MySQL Community Server (GPL)) Amazon Linux AMI (https://aws.amazon.com/amazon-linux-ami/2017.03-release-notes/) Apache/2.2.31 (Unix) OpenLDAP 2.4.40-12.30.amzn1 Question is - did we miss a configuration step to authenticate the users for the sub-wiki for basic authentication? What configuration files should we look at and what sections of those may have a clue for how this should be configured and function as expected? Thanks --- [Visit Topic](https://discourse.xwiki.org/t/users-local-or-global-cannot-authentic… to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discourse.xwiki.org/email/unsubscribe/2a966ef071dd63c45aa28bf….

3 2

[xwiki-users] Users (Local or Global) cannot log into a new Sub-wiki site
by Michael Dockham 15 May '17

15 May '17

Expectation is that we setup an additional wiki site that can have users log in directly but that does not work - when you attempt to log in with a valid user ID it provides no error message it just prompts you to log in again. We setup another wiki on our instance and we are unable to get any users to authenticate to the site. The workaround is to create users as a Global user and add them to the sub-wiki site's XWikiAllGroup. The use case is to establish another Wiki that we can add outside partner's users to it and segregate them from the main wiki site. *The configuration we have for the sub-wiki is as follows:* * Any global user can request to join but an admin must accept Main Wiki is setup for LDAP - the sub-wiki is NOT. xwiki.cfg #-# The following line is used to enable LDAP. See the LDAP section for more detail. xwiki.cfg:322 xwiki.authentication.authclass=org.xwiki.contrib.ldap.XWikiLDAPAuthServiceImpl LDAP Enable or not LDAP authentication for this wiki. If enabled and configured properly, a local user will be created whenever a LDAP user visit this wiki for the first time. Yes TRY LOCAL LOGIN If ldap authentication fails for any reason, try XWiki DB authentication with the same credentials. Default is yes Yes List of Installed Software xwiki-enterprise-web-9.3.1 jetty-distribution-9.4.4.v20170414 openjdk version "1.8.0_121" mysql-connector-java-5.1.41 mysqld Ver 5.5.54 for Linux on x86_64 (MySQL Community Server (GPL)) Amazon Linux AMI ( https://aws.amazon.com/amazon-linux-ami/2017.03-release-notes/) Apache/2.2.31 (Unix) OpenLDAP 2.4.40-12.30.amzn1 Question is - did we miss a configuration step to authenticate the users for the sub-wiki for basic authentication? What configuration files should we look at and what sections of those may have a clue for how this should be configured and function as expected? Thanks

1 0

[xwiki-users] XWiki Docker in Prod
by Lester Marc Dizon (ITX) 12 May '17

12 May '17

Hi, We are currently testing XWiki. I have a test environment for XWiki running in Docker. I would like to know if it's ok to run it as is in Prod (intranet)? Also, I'm trying to connect it to LDAP with no success (tried with http://extensions.xwiki.org/xwiki/bin/view/Extension/LDAP/Authenticator/ and http://extensions.xwiki.org/xwiki/bin/view/Extension/LDAP/Application/ ). Is it because I'm running it in Docker? Is there a log where I can check what's wrong? Any help is appreciated. Thanks, Lester

4 14

[xwiki-users] xwiki war deploy issue
by viktor 10 May '17

10 May '17

Hi All, I have some issues with the xwiki war deploy. I downloaded the XWiki 9.3.1 war file and wanted to deploy to wildfly-10.1.0.Final (also tried to deploy to 11.0.0.Alpha1), but the deploy fails. In the past days google did not tell me any wise thing how I should solve the issue (it can be that i asked wrong....). Does anyone have an idea what i missed or how i can get it work? Thanks a lot for the help,Vik XWiki: 9.3.1WildFly: wildfly-10.1.0.Final (also 11.0.0.Alpha1)JAVA:java version "1.8.0_131" Java(TM) SE Runtime Environment (build 1.8.0_131-b11) Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode) Install instructions which I followed: http://platform.xwiki.org/xwiki/bin/view/AdminGuide/InstallationWAR - Added the mysql connector - Created the database and actualized the database settings in WEB-INF/hibernate.cfg.xml - Added the "META-INF/jboss-all.xml" as it is written on the fix link. (http://platform.xwiki.org/xwiki/bin/view/AdminGuide/InstallationJBoss) This is the error message which I receive on the web interface:Cannot upload deployment: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"xwiki-enterprise-web-9.3.1.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"xwiki-enterprise-web-9.3.1.war\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"xwiki-enterprise-web-9.3.1.war\" Caused by: java.lang.RuntimeException: WFLYSRV0177: Error getting reflective information for class com.codahale.metrics.jetty9.InstrumentedHandler$7 with ClassLoader ModuleClassLoader for Module \"deployment.xwiki-enterprise-web-9.3.1.war:main\" from Service Module Loader Caused by: java.lang.NoClassDefFoundError: Failed to link com/codahale/metrics/jetty9/InstrumentedHandler (Module \"deployment.xwiki-enterprise-web-9.3.1.war:main\" from Service Module Loader): org/eclipse/jetty/server/handler/HandlerWr apper"},"WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"xwiki-enterprise-web-9.3.1.war\".POST_MODULE"],"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined} In the server log this is what has been generated: 17:39:22,675 WARN [org.jboss.modules] (MSC service thread 1-7) Failed to define class com.codahale.metrics.jetty9.InstrumentedHandler in Module "deployment.xwiki-enterprise-web-9.3.1.war:main" from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link com/codahale/metrics/jetty9/InstrumentedHandler (Module "deployment.xwiki-enterprise-web-9.3.1.war:main" from Service Module Loader): org/eclipse/jetty/server/handler/HandlerWrapper at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:446) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:78) at org.jboss.modules.Module.loadModuleClass(Module.java:606) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) at java.lang.Class.getDeclaredFields0(Native Method) at java.lang.Class.privateGetDeclaredFields(Class.java:2583) at java.lang.Class.getDeclaredFields(Class.java:1916) at org.jboss.as.server.deployment.reflect.ClassReflectionIndex.<init>(ClassReflectionIndex.java:72) at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:66) at org.jboss.as.ee.metadata.MethodAnnotationAggregator.runtimeAnnotationInformation(MethodAnnotationAggregator.java:57) at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.handleAnnotations(InterceptorAnnotationProcessor.java:106) at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:91) at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:76) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748)17:39:22,677 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."xwiki-enterprise-web-9.3.1.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."xwiki-enterprise-web-9.3.1.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "xwiki-enterprise-web-9.3.1.war" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.RuntimeException: WFLYSRV0177: Error getting reflective information for class com.codahale.metrics.jetty9.InstrumentedHandler$7 with ClassLoader ModuleClassLoader for Module "deployment.xwiki-enterprise-web-9.3.1.war:main" from Service Module Loader at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:70) at org.jboss.as.ee.metadata.MethodAnnotationAggregator.runtimeAnnotationInformation(MethodAnnotationAggregator.java:57) at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.handleAnnotations(InterceptorAnnotationProcessor.java:106) at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:91) at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:76) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) ... 5 more Caused by: java.lang.NoClassDefFoundError: Failed to link com/codahale/metrics/jetty9/InstrumentedHandler (Module "deployment.xwiki-enterprise-web-9.3.1.war:main" from Service Module Loader): org/eclipse/jetty/server/handler/HandlerWrapper at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:446) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:78) at org.jboss.modules.Module.loadModuleClass(Module.java:606) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) at java.lang.Class.getDeclaredFields0(Native Method) at java.lang.Class.privateGetDeclaredFields(Class.java:2583) at java.lang.Class.getDeclaredFields(Class.java:1916) at org.jboss.as.server.deployment.reflect.ClassReflectionIndex.<init>(ClassReflectionIndex.java:72) at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:66) ... 10 more17:39:22,679 ERROR [org.jboss.as.controller.management-operation] (External Management Request Threads -- 5) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "xwiki-enterprise-web-9.3.1.war")]) - failure description: { "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"xwiki-enterprise-web-9.3.1.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"xwiki-enterprise-web-9.3.1.war\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"xwiki-enterprise-web-9.3.1.war\" Caused by: java.lang.RuntimeException: WFLYSRV0177: Error getting reflective information for class com.codahale.metrics.jetty9.InstrumentedHandler$7 with ClassLoader ModuleClassLoader for Module \"deployment.xwiki-enterprise-web-9.3.1.war:main\" from Service Module Loader Caused by: java.lang.NoClassDefFoundError: Failed to link com/codahale/metrics/jetty9/InstrumentedHandler (Module \"deployment.xwiki-enterprise-web-9.3.1.war:main\" from Service Module Loader): org/eclipse/jetty/server/handler/HandlerWrapper"}, "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"xwiki-enterprise-web-9.3.1.war\".POST_MODULE"], "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined } 17:39:22,682 ERROR [org.jboss.as.server] (External Management Request Threads -- 5) WFLYSRV0021: Deploy of deployment "xwiki-enterprise-web-9.3.1.war" was rolled back with the following failure message: { "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"xwiki-enterprise-web-9.3.1.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"xwiki-enterprise-web-9.3.1.war\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"xwiki-enterprise-web-9.3.1.war\" Caused by: java.lang.RuntimeException: WFLYSRV0177: Error getting reflective information for class com.codahale.metrics.jetty9.InstrumentedHandler$7 with ClassLoader ModuleClassLoader for Module \"deployment.xwiki-enterprise-web-9.3.1.war:main\" from Service Module Loader Caused by: java.lang.NoClassDefFoundError: Failed to link com/codahale/metrics/jetty9/InstrumentedHandler (Module \"deployment.xwiki-enterprise-web-9.3.1.war:main\" from Service Module Loader): org/eclipse/jetty/server/handler/HandlerWrapper"}, "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"xwiki-enterprise-web-9.3.1.war\".POST_MODULE"], "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined }

1 0

Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons
by Ecaterina Moraru (Valica) 10 May '17

10 May '17

On Tue, May 9, 2017 at 11:20 PM, Olivier Seres <oseres(a)gmail.com> wrote: > Caty, > Thanks for this work! > We should also consider that there could be other options to be added in > the future, like "Allow realtime" radio button, or introduced by some > forecoming extensions > Ideal we could also remove options :) and make it more simpler :) On mobile the options will go on 2 rows, so we currently have this problems. Thanks, Caty > In order to avoid messing up the layout (in beeing be obliged to placing > the option in some weird places - like underneath because there is no other > options), it might be wise to think to an elegant design solution within > this bottom bar to take their growth into account. > Currently thinking to an unfolding menu, but I'm sure there are many other > ways. > > > > Olivier > > > On Tue, May 9, 2017 at 6:13 PM, Ecaterina Moraru (Valica) < > valicac(a)gmail.com> wrote: > >> Hi, >> >> The initial proposal was about the fixed bottom position. For that we will >> have https://jira.xwiki.org/browse/XWIKI-14162 issue >> In order to have a bottom bar, we compacted the save options, for that we >> will have the https://jira.xwiki.org/browse/XWIKI-14267 >> >> Thanks to everyone who responded in the survey. The results are available >> at >> https://docs.google.com/forms/d/1DM74hlXQQ22WVdqhYbGWyITWXTH >> 5qgmKSMIrS3eHDKE/viewanalytics >> >> The proposal we will implement is >> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisi >> bleSave/proposal9xCK.png >> >> Initially I wanted to remove some buttons and reduce their number, but the >> feedback was mixed, so this has been postponed, until we gather more usage >> data or feedback. >> >> Some conclusions: >> - "Save & View" received 12 votes as used most often. Since it's also an >> action that changes modes (takes the user to view) and is a final action, >> it will be marked with primary state (blue). >> - "Save" was also voted and voters were against remove it. Since it >> received 12 votes and is related to save, it will be the next action. We >> simplified the name from "Save&Continue" to "Save". >> - "Preview" received just 4 votes, but we consider this action to be >> directed towards newcomer users that need to be comfortable with their >> changes and be able to preview them. >> - "Cancel" was kept near the other actions in order to be consistent with >> the other layout we have across XWiki. It will be displayed outside of the >> button group. >> >> Thanks, >> Caty >> >> On Thu, Apr 27, 2017 at 4:29 PM, Ecaterina Moraru (Valica) < >> valicac(a)gmail.com> wrote: >> >> > Sorry. The link was https://goo.gl/forms/QyG5eOM44rBkd3qk2 >> > >> > On Thu, Apr 27, 2017 at 4:23 PM, Ecaterina Moraru (Valica) < >> > valicac(a)gmail.com> wrote: >> > >> >> I've created this form to gather data about the buttons usage, in order >> >> to make a proposal for the buttons location >> >> https://docs.google.com/forms/d/e/1FAIpQLSeQwjxlFl321Ap97xKlYRcf >> -39wlG- >> >> cJXXqM1nududfjo3KHQ/viewanalytics >> >> >> >> Hope everyone is comfortable with Google Forms. >> >> Thanks, >> >> Caty >> >> >> >> >> >> On Thu, Apr 27, 2017 at 12:56 PM, Denis GERMAIN <dt.germain(a)gmail.com> >> >> wrote: >> >> >> >>> Great proposition ! I like it. >> >>> >> >>> I see that the subject has also diverted to the fact that you can >> "save >> >>> and >> >>> continue" and "save and view". Some of our users are lost the first >> time >> >>> as >> >>> they click "save and continue" and don't understand why they are >> still in >> >>> edit mode. Clarifying this would indeed be a good idea, even though >> they >> >>> usually get the distinction quickly after that. >> >>> >> >>> Regards, >> >>> Denis >> >>> >> >>> 2017-04-26 17:01 GMT+02:00 Ecaterina Moraru (Valica) < >> valicac(a)gmail.com >> >>> >: >> >>> >> >>> > On Wed, Apr 26, 2017 at 5:41 PM, Craig Wright <crw+xwiki(a)crw.xyz> >> >>> wrote: >> >>> > >> >>> > > Hi Caty, >> >>> > > >> >>> > > I am a fan of “B”. >> >>> > > >> >>> > > I like the idea of putting the changelog and autosave options >> above >> >>> on a >> >>> > > preceding row. I would argue that for most users, their eyes only >> >>> see the >> >>> > > leftmost buttons as the functionally useful area. Thus putting >> >>> Cancel on >> >>> > > the far right effectively “hides” the button. >> >>> > > >> >>> > >> >>> > Yes, the most visible buttons are the ones on the left side and >> that's >> >>> the >> >>> > purpose. We need people to see the Save button :) >> >>> > Now, 'summary' functionality is not mandatory when editing and can >> >>> also be >> >>> > disabled from Administration - Editing. >> >>> > Having it on a separate line is not an option since we initial idea >> of >> >>> the >> >>> > thread is to provide a fixed bottom bar, when the viewport is >> small. So >> >>> > there are all on a single bar in order to be compact. >> >>> > >> >>> > >> >>> > > >> >>> > > For the purposes of mobile, I think it is acceptable to hide the >> >>> > changelog >> >>> > > and autosave options on small-screen resolutions. (Such as when I >> am >> >>> > > editing from iPhone, I am highly unlikely to leave a changelog >> >>> message >> >>> > > anyway.) >> >>> > > >> >>> > >> >>> > I haven't iterated much on the mobile version, but the mockup I >> have is >> >>> > http://design.xwiki.org/xwiki/bin/download/Proposal/ >> >>> > IdeaVisibleSave/mobile.png >> >>> > It can be improved, and as you said we could decide that on mobile >> we >> >>> can >> >>> > hide some functionality, but again hard to have stats to justify >> what >> >>> is >> >>> > used/needed or not. >> >>> > >> >>> > Thanks, >> >>> > Caty >> >>> > >> >>> > >> >>> > > FWIW, taborder should be the following: >> >>> > > >> >>> > > 1. Edit input >> >>> > > 2. Changelog input >> >>> > > 3. Save button >> >>> > > 4. Preview button >> >>> > > 5. Cancel button >> >>> > > 6. Autosave option >> >>> > > >> >>> > > My $0.02. :) >> >>> > > >> >>> > > Thanks, >> >>> > > Craig >> >>> > > >> >>> > > > On Apr 26, 2017, at 2:20 PM, Ecaterina Moraru (Valica) < >> >>> > > valicac(a)gmail.com> wrote: >> >>> > > > >> >>> > > > Hi, >> >>> > > > >> >>> > > > On Wed, Apr 26, 2017 at 2:39 PM, Craig Wright < >> crw+xwiki(a)crw.xyz >> >>> > > <mailto:crw+xwiki@crw.xyz>> wrote: >> >>> > > > >> >>> > > >> Overall I like these changes. A couple of suggestions: >> >>> > > >> >> >>> > > >> No one in my community understands “Save and Continue” versus >> >>> “Save >> >>> > and >> >>> > > >> View”. Dropping the “and Continue” is a great step, but I >> would go >> >>> > > farther >> >>> > > >> and give “Save and View” the emphasis color (blue, in this >> case). >> >>> That >> >>> > > is >> >>> > > >> the more highly understood behavior. “Save” (and continue >> >>> editing) is >> >>> > > >> useful but not as generally useful as “Save and View”. >> Especially >> >>> if >> >>> > you >> >>> > > >> are dropping Preview. >> >>> > > >> >> >>> > > >> FWIW, I use Preview more often from WYSIWYG mode since there is >> >>> not a >> >>> > > 1:1 >> >>> > > >> translation of editor view to page view. Whereas, when I am >> >>> editing >> >>> > > source, >> >>> > > >> I can predict how it will look most of the time. :) >> >>> > > >> >> >>> > > >> I would also move the Cancel button over next to the other >> >>> buttons. >> >>> > If I >> >>> > > >> had to rate which buttons I use the most frequently, “Cancel” >> >>> would be >> >>> > > at >> >>> > > >> the top, followed by “Save and View,” followed very very >> >>> distantly by >> >>> > > “Save >> >>> > > >> and Continue." >> >>> > > >> >> >>> > > >> >> >>> > > > This is very interesting behavior. I would love to be able to >> have >> >>> some >> >>> > > > usage stats, but with XWiki being installable and independently >> >>> hosted, >> >>> > > > stats are always hard to get by. >> >>> > > > >> >>> > > > Personally I use "Save" a lot (I like to save often in order to >> not >> >>> > lose >> >>> > > > stuff), but I usually use the keyboard shortcut, not necessarily >> >>> the >> >>> > > > button. It is true that 'Preview' in WYSIWYG has its usages, >> >>> especially >> >>> > > > when using macros or nested macros, since the result is not >> >>> accurate. >> >>> > > > >> >>> > > > Regarding "Save & View" I always do it as a final step, while I >> >>> never >> >>> > use >> >>> > > > "Cancel" - i just navigate away or hit the browser's 'Back'. >> >>> > > > >> >>> > > > Also in terms of functionality the "Autosave" can be used >> instead >> >>> of >> >>> > the >> >>> > > > "Save", so we can remove 'Save' (especially in case of advanced >> >>> users). >> >>> > > > >> >>> > > > So the only stats I have are from the http://playground.xwiki. >> org >> >>> < >> >>> > > http://playground.xwiki.org/> from the >> >>> > > > past 2 months. These are the top 3 pages edited, see >> >>> > > > http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisi >> >>> bleSave/ >> >>> > > UsageFebApr2017.png <http://design.xwiki.org/ >> >>> > xwiki/bin/download/Proposal/ >> >>> > > IdeaVisibleSave/UsageFebApr2017.png> >> >>> > > > >> >>> > > > Now let's see the heatmaps: >> >>> > > > - Sandbox.WebHome: >> >>> > > > http://design.xwiki.org/xwiki/bin/download/Proposal/ >> >>> > > IdeaVisibleSave/Sandbox-Home.png <http://design.xwiki.org/ >> >>> > > xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-Home.png> >> >>> > > > - Sandbox.TestPage1: >> >>> > > > http://design.xwiki.org/xwiki/bin/download/Proposal/ >> >>> > > IdeaVisibleSave/Sandbox-TestPage1.png <http://design.xwiki.org/ >> >>> > > xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-TestPage >> 1.png> >> >>> > > > - Sandbox.Test.WebHome: >> >>> > > > http://design.xwiki.org/xwiki/bin/download/Proposal/ >> >>> > > IdeaVisibleSave/Sandbox-Test.png <http://design.xwiki.org/ >> >>> > > xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-Test.png> >> >>> > > > >> >>> > > > From these heatmaps we see that 'Preview' has the most usage and >> >>> after >> >>> > is >> >>> > > > "Save&View", with no usage for "Save & Continue" and "Cancel". >> >>> > > > Not we need to take into account 2 aspects: Sandbox is used by >> >>> > first-time >> >>> > > > users of XWiki and they usually are afraid to mess things up so >> the >> >>> > > Preview >> >>> > > > is comforting for them. Also in the current layout 'Preview' is >> the >> >>> > first >> >>> > > > button from left-to-right, so it's assumed as the primary >> action. >> >>> > > > >> >>> > > > So if the initial proposal was 'varA', what do you think about >> >>> 'varB'? >> >>> > > > - var A [Save; Save & View]: >> >>> > > > http://design.xwiki.org/xwiki/bin/download/Proposal/ >> >>> > > IdeaVisibleSave/varA.png <http://design.xwiki.org/ >> >>> > > xwiki/bin/download/Proposal/IdeaVisibleSave/varA.png> >> >>> > > > - var B [Save & View; Preview]: >> >>> > > > http://design.xwiki.org/xwiki/bin/download/Proposal/ >> >>> > > IdeaVisibleSave/varB.png <http://design.xwiki.org/ >> >>> > > xwiki/bin/download/Proposal/IdeaVisibleSave/varB.png> >> >>> > > > - var C [Save & View; Save]: >> >>> > > > http://design.xwiki.org/xwiki/bin/download/Proposal/ >> >>> > > IdeaVisibleSave/varC.png <http://design.xwiki.org/ >> >>> > > xwiki/bin/download/Proposal/IdeaVisibleSave/varC.png> >> >>> > > > >> >>> > > > Note: users that went to 'Preview', usually come back to the >> >>> previous >> >>> > > view, >> >>> > > > see >> >>> > > > http://design.xwiki.org/xwiki/bin/download/Proposal/ >> >>> > > IdeaVisibleSave/Sandbox-Test-preview.png < >> http://design.xwiki.org/ >> >>> > > xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-Test-pre >> >>> view.png> >> >>> > > > >> >>> > > > I left 'Cancel' at the end, in order to be the last button and >> have >> >>> > > > visibility (not get lost in all the other options). Users need >> to >> >>> use >> >>> > it >> >>> > > as >> >>> > > > an 'escape' route, so it's better to find it fast and always >> have a >> >>> > > static >> >>> > > > position = last. For this usually the first and last positions >> are >> >>> > best. >> >>> > > > >> >>> > > > My initial rationale to remove 'Preview' from the WYSIWYG editor >> >>> was >> >>> > that >> >>> > > > WYSIWYG does life preview, so I though not many users use it, >> >>> since I >> >>> > > never >> >>> > > > used it. Seeing the stats for newcomers is impressive, still it >> >>> would >> >>> > be >> >>> > > > great if more advanced / long-term users of XWiki would >> summaries >> >>> a bit >> >>> > > > their button usage, so we could take a more informed decision. >> >>> XWiki >> >>> > > needs >> >>> > > > to accommodate both newcomers, but also long term users. >> >>> > > > >> >>> > > > Thanks, >> >>> > > > Caty >> >>> > > > >> >>> > > > >> >>> > > >> Nice work! >> >>> > > >> >> >>> > > >> Craig >> >>> > > >> >> >>> > > >> >> >>> > > >>> On Apr 25, 2017, at 6:21 PM, Ecaterina Moraru (Valica) < >> >>> > > >> valicac(a)gmail.com> wrote: >> >>> > > >>> >> >>> > > >>> Hi, >> >>> > > >>> >> >>> > > >>> We had some users complaining that the first time they edit a >> >>> page >> >>> > they >> >>> > > >>> don't know how to save it. Depending on the screen resolution, >> >>> the >> >>> > save >> >>> > > >>> buttons since they are at the bottom of the page are not >> visible >> >>> and >> >>> > > some >> >>> > > >>> users don't know they need to scroll in order to see them. >> >>> > > >>> >> >>> > > >>> We want to make some changes to XWiki, that: >> >>> > > >>> - Display the save buttons in a fixed bottom bar, when they >> are >> >>> out >> >>> > of >> >>> > > >> the >> >>> > > >>> viewport, see >> >>> > > >>> http://design.xwiki.org/xwiki/bin/download/Proposal/ >> >>> > > >> IdeaVisibleSave/bottomBar.png >> >>> > > >>> - When the user scroll, the buttons go into their position, >> see >> >>> > > >>> http://design.xwiki.org/xwiki/bin/download/Proposal/ >> >>> > > >> IdeaVisibleSave/after.png >> >>> > > >>> - We compacted the bottom functionalities (summary, minor, >> >>> > auto-save), >> >>> > > >> see >> >>> > > >>> before: >> >>> > > >>> http://design.xwiki.org/xwiki/bin/download/Proposal/ >> >>> > > >> IdeaVisibleSave/before.png >> >>> > > >>> after: >> >>> > > >>> http://design.xwiki.org/xwiki/bin/download/Proposal/ >> >>> > > >> IdeaVisibleSave/smallViewPort.png >> >>> > > >>> >> >>> > > >>> What do you think about this proposal? Would it improve the >> >>> > visibility >> >>> > > of >> >>> > > >>> the buttons? Do you have other ideas? Is it something we >> should >> >>> > > >> implement? >> >>> > > >>> >> >>> > > >>> Thanks, >> >>> > > >>> Caty >> >> > >

1 0

[xwiki-users] [Proposal][UX] Feedback for Visible Save buttons
by Ecaterina Moraru (Valica) 09 May '17

09 May '17

Hi, We had some users complaining that the first time they edit a page they don't know how to save it. Depending on the screen resolution, the save buttons since they are at the bottom of the page are not visible and some users don't know they need to scroll in order to see them. We want to make some changes to XWiki, that: - Display the save buttons in a fixed bottom bar, when they are out of the viewport, see http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/bottomB… - When the user scroll, the buttons go into their position, see http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/after.p… - We compacted the bottom functionalities (summary, minor, auto-save), see before: http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/before.… after: http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/smallVi… What do you think about this proposal? Would it improve the visibility of the buttons? Do you have other ideas? Is it something we should implement? Thanks, Caty

5 11

[xwiki-users] Search icon disappeared in the menu
by genevieve.aubut＠telmatik.com 09 May '17

09 May '17

Do you know how I can add the search icon in the menu? The Search Suggest is enable in the configuration. The Search is visible in the main wiki but not in the sub-wiki site. <http://xwiki.475771.n2.nabble.com/file/n7603805/Capture.png> Thanks -- View this message in context: http://xwiki.475771.n2.nabble.com/Search-icon-disappeared-in-the-menu-tp760… Sent from the XWiki- Users mailing list archive at Nabble.com.

2 3