Hi devs,
We've had several complaints from users about the Navigation Panel. The 3 big needs that I’ve heard are:
1) Semi-automated by having the ability to blacklist items
2) Better performance ("It’s slow to load and reloads every time you navigate to a new page”)
3) Ability to sort entries
See for ex:
* https://forum.xwiki.org/t/your-xwiki-usability-pain-points/440/11
* https://jira.xwiki.org/browse/XWIKI-12895
Point 1
======
That Panel is critical since it’s what users see the most (without navigating anywhere) and it’s important that users be able to customize it (while keeping the automated aspect, e.g. adding a new page should add it to the tree by default as it’s done now).
Marius mentioned that adding blacklisting doesn’t make sense because we would then have different behaviors between the Navigation Panel and:
• the breadcrumb trees
• the page index tree
• the location picker tree used on create/copy/rename page
• the location picker tree used by the CKEditor link and image dialogs
• anywhere we use a tree in XWiki default user interface
However I don’t fully agree about this. If you check the Applications Panel, it’s not listing all Apps that exist. It’s only listing Apps that the admin want his/her users to see by default. To see all apps there’s the App Index. Similarly the Navigation Panel on the left should be listing what the admin wants his/her users to see, and going to the Page Index should list all pages.
In short I really believe we need to allow customizing the panel with an Admin UI that allows to blacklist some nodes).
Does anyone see a better idea to fulfill our user’s needs?
Point 2
======
The main answer I see is to implement the doc title cache so that we don’t have to load documents.
Do you see anything else?
Point 3
======
I think this is kind of already implemented with “showDocumentTitle”, right?
Thanks
-Vincent
Hi GSOC students,
This is a reminder that there’s a deadline approaching soon:
"August 21-29: Students submit their work product (code) and a final evaluation of their Mentor”
On my side, I’m mentoring 2 projects:
* The Glossary Application project. Unfortunately this one failed the first review since not enough work was done. However Sarthak mentioned to me that he wanted to continue but he probably lost faith since I haven’t seen any work done. Sarthak, could you confirm that you dropped the topic altogether?
* The RedPen integration. There’s been several commits done and several status emails sent but it seems it’s lagging behind quite substantially since we’ve yet to see any working prototype. Desheng, it’s really important that you release ASAP a first working version on extensions.xwiki.org (that’s a condition of success) that we can try and install in our own XWiki instances.
Thanks
-Vincent
Hi devs,
We have several pages requiring PR and we’re not doing much about them.
This is a major pain, for example on myxwiki.org where, every time some admin update their wikis they break features. It’s not showing XWiki in good light neither.
I’ve found at least those pages requiring PR:
* XWiki.AllAttachmentsResults
* XWiki.DeletedDocumentsJSON
* AppWithinMinutes.DynamicMessageTool
* AnnotationCode.Style
* XWiki.DeletedDocuments
* AppWithinMinutes.LiveTableEditSheet
* AppWithinMinutes.ClassEditSheet
* XWiki.DeletedAttachments
* Main.Activity
* AnnotationCode.Script
(see http://jira.xwiki.org/browse/XWIKI-10446?focusedCommentId=83579&page=com.at… )
And FTR we keep adding more over time. For example in 2012, AWM introduced a PR: https://github.com/xwiki/xwiki-platform/commit/ae09194f83b9fe1f75778e0a2501…
I’d like to propose to do a PR-fixing day for the next non-BFD day, i.e. in 2 weeks.
WDYT?
Thanks
-Vincent
Hello XWiki team!
I just write to brag a bit about *Extension Repository Connector - NPM*
that I created in 3rd phase of GSoC ;)
You can read about it here:
http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension%20Repository…
and
test it if you wish (there's an example to follow).
As before - any feedback highly appreciated :)
Have a nice day!
Best,
Krzysztof
The XWiki development team is proud to announce the availability of XWiki
9.7.
This release brings small improvements to currently established features.
The code viewer now provides a blame view by default and the notification
center now allows the user to enable or disable notifications globally on
an application, as well as toggling default notification filters provided
by the platform.
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.7/
Thanks for your support
-The XWiki dev team
The XWiki development team is proud to announce the availability of
XWiki 9.7RC1!
This release brings small improvements to currently established
features. The code viewer now provides a blame view by default and the
notification center now allows the user to enable or disable
notifications globally on an application, as well as toggling default
notification filters provided by the platform.
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.7RC1
Thanks for your support
-The XWiki dev team
Hi devs,
While thinking about what features a Technical Documentation Flavor [1]
should have, I came up with some ideas that we could integrate inside
xwiki.org in order to make it a better documentation website:
- navigation tree in the left panel, see
--
http://design.xwiki.org/xwiki/bin/download/Proposal/Flavors/TechnicalDocume…
compared to
-- http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Installation
- simpler skin (at least remove the comments area - lots of deprecated
questions/answers and we have now the forum for that)
- simpler menu (less entries + merge with the navbar if technical possible
now, otherwise wait for newer version)
- simpler footer area by removing the number of links displayed (we need to
look at mouseflow)
Would be great also to upgrade XWiki.org to a newer version.
There were all sorts of ideas in the past like:
- displaying 'Edit' also for unregistered in order to encourage edits
- display 'Register'/'Log-in' links in the navbar in order to encourage
edits
these are not part of the current proposal, but keep the ideas coming :) we
will try to implement them when we can.
Of course it would be great if we would had time to:
- update the docs content
- reorganize pages
- update the blog styling
- etc.
but I guess small changes will come in time.
Let me know what you think,
Caty
[1]
http://design.xwiki.org/xwiki/bin/view/Proposal/Flavors/TechnicalDocumentat…
Hi devs,
I’d like to raise a pain point.
Environment:
* myxwiki.org
* lescastcodeurs wiki
What happened:
* We upgraded myxwiki.org
* Emmanuel (an Admin user of the lescastcodeurs wiki) got the Distribution Wizard and followed it to upgrade the wiki
The problem:
* Several features are broken. For example AppWithinMinutes (some pages display red boxes saying that the last author didn’t have script rights)
The reason:
* Emmanuel was admin but didn’t have script rights (after some xwiki upgrade that caused existing users to not have script rights if not set explicitly)
* For ex on the AppWithinMinutes space: https://www.evernote.com/l/AHcaXGYEzdZJXLTQEy2Vbohcfzu5vMbxkBM
Brainstorming:
1) What should we do to not have this problem?
2) What solution do we offer to fix it easily?
Re 2) we have:
* http://extensions.xwiki.org/xwiki/bin/view/Extension/Change%20Content%20Aut…
* http://extensions.xwiki.org/xwiki/bin/view/Extension/Change%20creator%2C%20…
However none are good for me without changes since they either change all pages in the wiki (which is not what I want) or they change only a single page.
Any idea?
Thanks
-Vincent