Thanks Vincent, it’s no problem and thanks again to you and the others working on the project. I’ve been meaning to email you back and might do that soon regarding a couple of specific issues.
I agree with this point.
The default is that when somebody creates a new page it can easy be a few words and with international users also non-ascii can be used. We now have instructions telling our users to start creating a new page with a camelCase word and then change the title to what they want in a second step.
We also know that 90% of our users are not aware of the URL (or page-name), they only care about the title. and Sometimes about the bread-crumb.
My proposal would be that you can set a configuration where one setting would be Generate Name of page based on a name-construction algorithm; e.g. camelCase, or _setting (best_page) or -setting
The current naming algorithm could be another option
Thanks @gerritjankoekkoek for your message. I’d like to make sure I understand it though. When you said:
What point exactly do you agree with?
The proposal you suggest seems to be what is already currently implemented (but with the ability to change the auto-naming algorithm, right now users enter the title and we have page name = title).
Thanks
Sorry, I thought I had replied to a topic.
The proposal was to do something about name and url.
Your suggesties was to show the url that Would be created.
It was my impression (or opinion) that we should look at title, name and url as all belonging together.
We had sometimes names created by the system that were impossible to retrieve as a doc : user had used Reading symbols like “ or ‘ or é or .
It seems that replying to a topic doesn’t work in the sense that it doesn’t do anything visible…
Could you elaborate on this? By belonging together you mean make the 3 concepts visible and have the user the ability to change the 3 when creating a page? Right now, we show title proeminently and allow users to change the page name if they know what they’re doing. But we’re not showing the URL ATM.
Thx
(I’m digging out this post, bc I don’t know if a new post is welcome about it)
I still use SpaceIndex macro on my main WebHome pages (I use xwiki 8.4.6 and going to 9.x LTS). I customized it to display all the children page.
@vmassol recommend to overwrite it with treeview but I’m not agree with that (maybe I’m wrong anyway 
)
My main reasons is:
- user can already select his doc in the treeview of the breadcrumb.
- js is slower than spaceindex
- my spaceIndex list all children page of current space in a flat way and sort them by date update (recents doc are first)
- by “in a flat way” I mean that myspaceIndex list all docs even if this doc is on 3 level under
- user see all recent docs and have only 1 click to open it
Ty
Pascal B
Hi Pascal,
Just so that I understand, since this thread is about usability pain points, are you saying that the Document Tree is a usability pain point?
What you’ve implemented is a Recently Modified widget. And for such a widget it makes sense to have a flat structure. In essence you’ve done the same as the Activity Stream but with a different presentation.
The goal of the Document Tree is not to do that 
It’s to list all children under a given root. We also have a tabular way of viewing the same info with the {{document}} macro which uses a LT.
Could you explain what you want to discuss here (I’m not sure :))? Thx
No the Document Tree is a great improvment.
I post here because I understand you will remove spaceIndex macro from xwiki (but probably I missunderstood that)
Ah yes for sure, actually I thought it was already removed. We’re lagging behind in the removal
What you could do (that would be great! :)) is contribute a new extension: a recently modified pages macro that implements what you’re doing.
But we cannot keep “spaceindex” as it is since the notion of “space” has been removed from the UI and the spaceindex macro is listing just spaces with the ability to create spaces too, and that doesn’t make sense anymore.
Just FTR the document tree macro has the root and showRoot parameters for this.
Yes but with tree view I can not list my recents docs, like @vmassol said " the same as the Activity Stream but with a different presentation."
Of course by space I mean parent now.
ParentIndex? a feature who list all recent docs (children and sub parent) of all sublevels of current parent?
{{recentPages}} ?
hum one parameter could be modify sort order: ie page name | creation date | update date … then recentPages 
I was just wondering if the XWiki team have given any further consideration to this issue with the spaces in URLs showing as %20.
I am pretty sure there was a conversation started about this on the mailing list, just before this forum was created (and probably continued here actually).
But basically as we create more and more documents, and want to share the document URL in our internal chat, emails, and references from other documents (not necessarily on XWiki), the more frustrating and annoying it becomes to see that %20 in the URL.
I completely understand that XWiki automatically turns the user defined title into the URL, and that the user has the option to click on Edit Location, and then change the name. But these few extra steps would be unnecessary if XWiki could just have an admin configured option to replace spaces with another character (or one of the other options mentioned by @gerritjankoekkoek)
What would be required to get the XWiki team to seriously consider this feature? Or is there a way to write a plugin/macro to do this?
Right now nobody I know of is working on this topic. So you have 2 ways to get things moving that I know of:
- To sponsor the work. You could contact one of the companies sponsoring the development of XWiki and tell them you’re interested in sponsoring the development of this feature. See http://www.xwiki.org/xwiki/bin/view/Main/Support#HProfessionalSupport
- To participate and create a PR for it.
Yes and I believe this was already mentioned a few times.
I can think of 2 solutions:
- You simply override the proper template (vm file) in a custom skin to perform the page name replacement (easy)
- You configure a servlet filter to do rewriting so transform some character into spaces and vice-versa for the output. See http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/ShortURLs/#HUrlRewriteFilter
Note that I don’t mean to say that the xwiki developers don’t care about this. It’s just that there are so many things to do that it’s hard to do them all so the devs focus on their own itches and also what they think is the most important.
So I guess another way is to show the xwiki devs that this is more important than the other stuff planned in the roadmap that they’re working on.
The sponsoring I mentioned is a way of saying that you’re willing to pay to modify the roadmap in some sense.
Thanks. I’ve tried to look for the correct file and thought it was createinline.vm but any changes I make in there to $name and then attach the edited file to our custom skin does not result in any changes.
I am probably doing it wrong. Let me know if I should create a new post to get a bit more help with this. Thanks.
Yes please open a new thread, I don’t know the name of the template file by heart and someone would need to help you if you can’t find the right place.
This is a minor thing ui annoyance, but when working with an “App in Minutes” application, the “Add New Entry” link causes a little input dialog to pop up (Entry name:). After typing in the entry name, we have click on the (+) green circular icon to the right of the input box.
It would be really nice if this dialog box could accept pressing “enter” as the submit.
and now that I think about it, pressing Escape to close the dialog box would make it complete.