[xwiki-users] display page title and name(url) while creating a page
I want to display Page Name field only while page creation. By default currently it is shown as: <http://xwiki.475771.n2.nabble.com/file/n7603546/Screenshot_2017-04-20-10-45-56-615_org.png> It is creating a lot of confusion for my users between Title and Name, and I don't suppose to explain it to them all. They couldn't understand this complexity.. 1) I wish to remove the Title field from this Page creation dialog and display url field instead. Currently, by clicking the pencil/edit icon, the parent and name fields are displayed. <http://xwiki.475771.n2.nabble.com/file/n7603546/Screenshot_2017-04-20-10-46-13-434_org.png> 2) Is there any way to set this edit icon by default to display these fields? 3) And can I rename Name field to URL/Link to clear the confusions?? -- View this message in context: http://xwiki.475771.n2.nabble.com/display-page-title-and-name-url-while-crea... Sent from the XWiki- Users mailing list archive at Nabble.com.
Hi Vishal, That’s an interesting feedback. We’ve tried to already solve this issue in recent versions of XWiki by having a simplified Page Creation UI but apparently you think there’s still a problem so we need to discuss that to try to find a solution.
On 20 Apr 2017, at 07:31, Vishal <[email protected]> wrote:
I want to display Page Name field only while page creation. By default currently it is shown as: <http://xwiki.475771.n2.nabble.com/file/n7603546/Screenshot_2017-04-20-10-45-56-615_org.png>
Note that on this screenshot the only thing that the use fills is “Title”. Why is that causing a confusion? Technically we have both notions: Page name and Title. But in the UI shown to the users they only see Title (and internally set the page name to be that title). So they don’t need to know about the Page name concept. I’m curious to know why your users know about the page name concept.
It is creating a lot of confusion for my users between Title and Name, and I don't suppose to explain it to them all. They couldn't understand this complexity..
You just need to explain to them the title concept. I’m referring to simple users of your wiki. Of course if you also have developers doing scripting in the wiki then they probably need to understand both concepts. Now if you really want to explain the difference between the 2: * Page name is to control the URL displayed, so that you can hand-craft nice URLs for SEO reasons or other * Title is simply what gets displayed in the UI when you view a page
1) I wish to remove the Title field from this Page creation dialog and display url field instead. Currently, by clicking the pencil/edit icon, the parent and name fields are displayed. <http://xwiki.475771.n2.nabble.com/file/n7603546/Screenshot_2017-04-20-10-46-13-434_org.png>
Only advanced users have the options to click this pencil button. And our rationale is that advanced users know the difference between page name and title.
2) Is there any way to set this edit icon by default to display these fields?
I’m lost here. You’re saying that there’s a confusion and you want to always show both fields? :)
3) And can I rename Name field to URL/Link to clear the confusions??
If you’re prepared to bring changes to your instance, you can modify everything in xwiki. You can do this by creating a custom skin and overriding the createinline.vm template. But first I’d like that we find an agreement about what would be best for XWiki since maybe there’s something we need to do on our side to clear any confusion. Thanks -Vincent
-- View this message in context: http://xwiki.475771.n2.nabble.com/display-page-title-and-name-url-while-crea... Sent from the XWiki- Users mailing list archive at Nabble.com.
Thanks Vincent for your thorough reply.. You guessed it right. We intend to have clean and short urls for SEO reasons. Current scheme creates two problems: 1) The Page name is fetched automatically from the Title. Often the titles have spaces which translate as *percent characters *in url which makes it somewhat unclean :) 2) Secondly, to have the shorter url, we use only the short forms of complete title. Ex. For title 'Pune University' we use name PU. Otherwise in this hierarchy of pages, the url would be much longer. Ex. We have page 'Electronics and Telecommunications' branch under page 'Pune University'. We should not have such a long url. Instead here we need PU/ENTC or Pune-University/ENTC To avoid all this, what we currently do: 1) On create page dialog, use PU as title.. This will create url as PU. If full name is used here as title, we need to use - instead of spaces to avoid percent characters in url. 2) While in edit mode, change the title back to Pune University. Remove any - characters to make title clean. This is where confusion creeps in. If these two terms create confusion, why I need to show them both: I guess the *confusion is due to term Name*. It doesn't reflect actual usage of the term. URL or weblink or link or web address would be more apt terms to use to instead of Name. My users can differentiate between Title and URL. But the whole procedure we follow is certainly not understandable by all. And we definitely need to follow this whole long procedure, just to have short and clean urls. So, by showing both fields at the first place itself, I would like to shorten the procedure and url length. -- View this message in context: http://xwiki.475771.n2.nabble.com/Page-Title-and-Name-confusion-tp7603546p76... Sent from the XWiki- Users mailing list archive at Nabble.com.
Hi Vishal, Ok, I misunderstood you in your first email. I understood the opposite. I thought you were complaining that have 2 notions (page name + page title) was confusing but it’s actually the opposite! What you find confusing is the fact that it’s not easy for your users to set both the page name and page titles! It’s funny (or not :)) since this is exactly what we had in past versions of XWiki and we had several complaints that it was confusing to have the 2 notions and this is why he hid the page name only for advanced users. See below.
On 20 Apr 2017, at 14:20, Vishal <[email protected]> wrote:
Thanks Vincent for your thorough reply.. You guessed it right. We intend to have clean and short urls for SEO reasons. Current scheme creates two problems:
1) The Page name is fetched automatically from the Title. Often the titles have spaces which translate as *percent characters *in url which makes it somewhat unclean :)
Indeed you’re right. By hiding the page name we’re now incitating to have longer URLs and encoded characters showing up in URLs which is not nice I agree. Maybe one solution is to do something similar to what we do in AWM, i.e. generate automatically the URL from the title entered by the user and show the resulting URL to the user and give the user the opportunity to change the URL. See http://extensions.xwiki.org/xwiki/bin/download/Extension/App%20Within%20Minu...
2) Secondly, to have the shorter url, we use only the short forms of complete title. Ex. For title 'Pune University' we use name PU.
Hey, you’re from Pune? :) I’ve been there about 15 times! That was in a previous job where my company and KPIT Cummins were partners.
Otherwise in this hierarchy of pages, the url would be much longer. Ex. We have page 'Electronics and Telecommunications' branch under page 'Pune University'. We should not have such a long url. Instead here we need PU/ENTC or Pune-University/ENTC
To avoid all this, what we currently do: 1) On create page dialog, use PU as title.. This will create url as PU. If full name is used here as title, we need to use - instead of spaces to avoid percent characters in url. 2) While in edit mode, change the title back to Pune University. Remove any - characters to make title clean. This is where confusion creeps in.
If these two terms create confusion, why I need to show them both: I guess the *confusion is due to term Name*. It doesn't reflect actual usage of the term. URL or weblink or link or web address would be more apt terms to use to instead of Name.
Regarding Page name vs Page URL. A bit of history: The reason we used page name and not page URL originally is because what the user is creating is a document in the database and initially it was called Document Name. Since that was a bit confusing for users, we had decided to call it Page Name. It just happened that the URL used was directly derived from the document/page name. In practice the 3 concepts could have different values: * a value for the document’s name in the DB * another value for the document’s title * yet another value used in the URL. We’ve had discussions so that we could let the user provide shorter URLs for pages in the future. Now for the time being and since we don’t have this ATM, I think I agree with you that we could decide to display to the user the URL that will be generated (the encoded URL) and allow the user to change it. Internally the user would change the document name.
My users can differentiate between Title and URL. But the whole procedure we follow is certainly not understandable by all. And we definitely need to follow this whole long procedure, just to have short and clean urls.
Yes, if you’re asking your users to care about the URLs that get generated, right now they need to be advanced users to be able to edit the page name in the Create Page UI (since changing the title afterwards is too cumbersome).
So, by showing both fields at the first place itself, I would like to shorten the procedure and url length.
I’m in agreement with you. Let’s see what others think. Thanks for this interesting discussion! -Vincent
-- View this message in context: http://xwiki.475771.n2.nabble.com/Page-Title-and-Name-confusion-tp7603546p76... Sent from the XWiki- Users mailing list archive at Nabble.com.
On 20 Apr 2017, at 22:51, Vincent Massol <[email protected]> wrote:
Hi Vishal,
Ok, I misunderstood you in your first email. I understood the opposite. I thought you were complaining that have 2 notions (page name + page title) was confusing but it’s actually the opposite! What you find confusing is the fact that it’s not easy for your users to set both the page name and page titles!
It’s funny (or not :)) since this is exactly what we had in past versions of XWiki and we had several complaints that it was confusing to have the 2 notions and this is why he hid the page name only for advanced users.
Actually, if I remember well, what we were doing was to ask for the page name and we were setting the title to the same as the page name by default and then the user could edit the title before saving the page. We’ve now done the opposite (user deciding on the title and page name being derived from it) but leading to the issue you’re raising about URL SEO… Thanks -Vincent
See below.
On 20 Apr 2017, at 14:20, Vishal <[email protected]> wrote:
Thanks Vincent for your thorough reply.. You guessed it right. We intend to have clean and short urls for SEO reasons. Current scheme creates two problems:
1) The Page name is fetched automatically from the Title. Often the titles have spaces which translate as *percent characters *in url which makes it somewhat unclean :)
Indeed you’re right. By hiding the page name we’re now incitating to have longer URLs and encoded characters showing up in URLs which is not nice I agree.
Maybe one solution is to do something similar to what we do in AWM, i.e. generate automatically the URL from the title entered by the user and show the resulting URL to the user and give the user the opportunity to change the URL.
See http://extensions.xwiki.org/xwiki/bin/download/Extension/App%20Within%20Minu...
2) Secondly, to have the shorter url, we use only the short forms of complete title. Ex. For title 'Pune University' we use name PU.
Hey, you’re from Pune? :) I’ve been there about 15 times! That was in a previous job where my company and KPIT Cummins were partners.
Otherwise in this hierarchy of pages, the url would be much longer. Ex. We have page 'Electronics and Telecommunications' branch under page 'Pune University'. We should not have such a long url. Instead here we need PU/ENTC or Pune-University/ENTC
To avoid all this, what we currently do: 1) On create page dialog, use PU as title.. This will create url as PU. If full name is used here as title, we need to use - instead of spaces to avoid percent characters in url. 2) While in edit mode, change the title back to Pune University. Remove any - characters to make title clean. This is where confusion creeps in.
If these two terms create confusion, why I need to show them both: I guess the *confusion is due to term Name*. It doesn't reflect actual usage of the term. URL or weblink or link or web address would be more apt terms to use to instead of Name.
Regarding Page name vs Page URL.
A bit of history: The reason we used page name and not page URL originally is because what the user is creating is a document in the database and initially it was called Document Name. Since that was a bit confusing for users, we had decided to call it Page Name. It just happened that the URL used was directly derived from the document/page name.
In practice the 3 concepts could have different values: * a value for the document’s name in the DB * another value for the document’s title * yet another value used in the URL.
We’ve had discussions so that we could let the user provide shorter URLs for pages in the future.
Now for the time being and since we don’t have this ATM, I think I agree with you that we could decide to display to the user the URL that will be generated (the encoded URL) and allow the user to change it. Internally the user would change the document name.
My users can differentiate between Title and URL. But the whole procedure we follow is certainly not understandable by all. And we definitely need to follow this whole long procedure, just to have short and clean urls.
Yes, if you’re asking your users to care about the URLs that get generated, right now they need to be advanced users to be able to edit the page name in the Create Page UI (since changing the title afterwards is too cumbersome).
So, by showing both fields at the first place itself, I would like to shorten the procedure and url length.
I’m in agreement with you. Let’s see what others think.
Thanks for this interesting discussion! -Vincent
-- View this message in context: http://xwiki.475771.n2.nabble.com/Page-Title-and-Name-confusion-tp7603546p76... Sent from the XWiki- Users mailing list archive at Nabble.com.
Let's see what variants we have: 1. Instead of displaying "Title", display the "Name" instead. This won't solve anything. There is no difference between Page Name and Page Title for the normal users. Seeing "Name" instead of "Title", will not stop the users to enter spaces if they want, so the URL will still have those spaces. We don't force the Page Names to trim spaces. One quick solution here is indeed to use "URL" label instead of "Name". For the reasons Vincent mentioned this might not end up in the product for now, so you will need to do some custom development (changing some translations) to have this change. If you want to be "hackish" you can even change the translation for "Title" to "URL" instead and hope that your users will enter shorter URLs (since we generate the name from the title). Displaying just Name / URL, means users will still have to go and change the title manually. The only way to cut a step in the flow is to autogenerate the page names (which we currently do). But for your use case you shoyld write a shorting/trimming algorithm, but this is custom, since you mentioned you want just the initials and no spaces, etc. 2. Displaying both "Title" and "Name". This will create confusion and need for explanations. That's why we display these options just for advanced and long-time users of XWiki, since they are used to the concepts. ----- IMO what you are describing is advanced user behavior. Normal users don't generally care about their URLs and SEO. But the beauty of XWiki is that you can customize it locally to perfectly match your needs. Vincent mentioned something about AWM. I don't see much difference from the Create Page. We generate the names from title here too. We display them in the breadcrumb, but in a more simple way. Displaying the "localhost"/server part is not simple user behavior. AWM is more complex. ----- So I would not change anything on the product side, since I believe these should be solved as custom changes for your instance. We want to encourage users to use page titles (with spaces in them since they are more readable and supported), while we are preserving the page name behavior for advances users (but we don't enforce it). If users made mistakes they can always change the title or rename the page. On the product side the only change I would like us to do is using the URL naming, but this was debated in the past and dropped for Vincent's reasons. Thanks, Caty On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol <[email protected]> wrote:
On 20 Apr 2017, at 22:51, Vincent Massol <[email protected]> wrote:
Hi Vishal,
Ok, I misunderstood you in your first email. I understood the opposite. I thought you were complaining that have 2 notions (page name + page title) was confusing but it’s actually the opposite! What you find confusing is the fact that it’s not easy for your users to set both the page name and page titles!
It’s funny (or not :)) since this is exactly what we had in past versions of XWiki and we had several complaints that it was confusing to have the 2 notions and this is why he hid the page name only for advanced users.
Actually, if I remember well, what we were doing was to ask for the page name and we were setting the title to the same as the page name by default and then the user could edit the title before saving the page.
We’ve now done the opposite (user deciding on the title and page name being derived from it) but leading to the issue you’re raising about URL SEO…
Thanks -Vincent
See below.
On 20 Apr 2017, at 14:20, Vishal <[email protected]> wrote:
Thanks Vincent for your thorough reply.. You guessed it right. We intend to have clean and short urls for SEO reasons. Current scheme creates two problems:
1) The Page name is fetched automatically from the Title. Often the titles have spaces which translate as *percent characters *in url which makes it somewhat unclean :)
Indeed you’re right. By hiding the page name we’re now incitating to have longer URLs and encoded characters showing up in URLs which is not nice I agree.
Maybe one solution is to do something similar to what we do in AWM, i.e. generate automatically the URL from the title entered by the user and show the resulting URL to the user and give the user the opportunity to change the URL.
See http://extensions.xwiki.org/xwiki/bin/download/Extension/ App%20Within%20Minutes%20Application/AppWithinMinutes-Step1.png
2) Secondly, to have the shorter url, we use only the short forms of complete title. Ex. For title 'Pune University' we use name PU.
Hey, you’re from Pune? :) I’ve been there about 15 times! That was in a previous job where my company and KPIT Cummins were partners.
Otherwise in this hierarchy of pages, the url would be much longer. Ex. We have page 'Electronics and Telecommunications' branch under page 'Pune University'. We should not have such a long url. Instead here we need PU/ENTC or Pune-University/ENTC
To avoid all this, what we currently do: 1) On create page dialog, use PU as title.. This will create url as PU. If full name is used here as title, we need to use - instead of spaces to avoid percent characters in url. 2) While in edit mode, change the title back to Pune University. Remove any - characters to make title clean. This is where confusion creeps in.
If these two terms create confusion, why I need to show them both: I guess the *confusion is due to term Name*. It doesn't reflect actual usage of the term. URL or weblink or link or web address would be more apt terms to use to instead of Name.
Regarding Page name vs Page URL.
A bit of history: The reason we used page name and not page URL originally is because what the user is creating is a document in the database and initially it was called Document Name. Since that was a bit confusing for users, we had decided to call it Page Name. It just happened that the URL used was directly derived from the document/page name.
In practice the 3 concepts could have different values: * a value for the document’s name in the DB * another value for the document’s title * yet another value used in the URL.
We’ve had discussions so that we could let the user provide shorter URLs for pages in the future.
Now for the time being and since we don’t have this ATM, I think I agree with you that we could decide to display to the user the URL that will be generated (the encoded URL) and allow the user to change it. Internally the user would change the document name.
My users can differentiate between Title and URL. But the whole procedure we follow is certainly not understandable by all. And we definitely need to follow this whole long procedure, just to have short and clean urls.
Yes, if you’re asking your users to care about the URLs that get generated, right now they need to be advanced users to be able to edit the page name in the Create Page UI (since changing the title afterwards is too cumbersome).
So, by showing both fields at the first place itself, I would like to shorten the procedure and url length.
I’m in agreement with you. Let’s see what others think.
Thanks for this interesting discussion! -Vincent
-- View this message in context: http://xwiki.475771.n2.nabble. com/Page-Title-and-Name-confusion-tp7603546p7603551.html Sent from the XWiki- Users mailing list archive at Nabble.com.
Hi Caty,
On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) <[email protected]> wrote:
Let's see what variants we have:
1. Instead of displaying "Title", display the "Name" instead. This won't solve anything. There is no difference between Page Name and Page Title for the normal users. Seeing "Name" instead of "Title", will not stop the users to enter spaces if they want, so the URL will still have those spaces. We don't force the Page Names to trim spaces.
One quick solution here is indeed to use "URL" label instead of "Name". For the reasons Vincent mentioned this might not end up in the product for now,
What did I mention? :) What’s preventing us from having it in the product rather soon than later (except workload ofc)?
so you will need to do some custom development (changing some translations) to have this change. If you want to be "hackish" you can even change the translation for "Title" to "URL" instead and hope that your users will enter shorter URLs (since we generate the name from the title).
Displaying just Name / URL, means users will still have to go and change the title manually.
This could be better (with URL name) since when you create a page you’re offered the ability to change the title after you click Create.
The only way to cut a step in the flow is to autogenerate the page names (which we currently do). But for your use case you shoyld write a shorting/trimming algorithm, but this is custom, since you mentioned you want just the initials and no spaces, etc.
2. Displaying both "Title" and "Name". This will create confusion and need for explanations.
This is not exactly what is suggested either by Vishal nor by me :) What we suggested is to let the user enter the URL name and title. Actually and to be more precise what I was suggesting was to continue to let the user enter the title but to show the generated URL as it’s done in AWM. And, importantly to allow the user to change the last part of the URL (it would change the page name).
That's why we display these options just for advanced and long-time users of XWiki, since they are used to the concepts.
Yes but URLs don't need an advanced user to understand the concept and I agree with Vishal that we’re now causing a very large number of pages to have %25 in their URLs by default which is quite bad… Of course someone can spend their time monitoring what users are doing and renaming pages thereafter or educate their users to do that but we’re not helping and we’re making it difficult.
-----
IMO what you are describing is advanced user behavior. Normal users don't generally care about their URLs and SEO.
I don’t fully agree with you. I have the feeling (can’t prove it) that a good number of our users care about the generated URLs. Also I think that simple users may care about URL without being advanced users. Making them advanced users will expose them to a lot more complexity than they need to know.
But the beauty of XWiki is that you can customize it locally to perfectly match your needs.
That’s not exactly true (and it’s far from being easy, just check createinline.vm): It means overriding large portions of vm code and having to do manual merges whenever you upgrade. A major PITA.
Vincent mentioned something about AWM. I don't see much difference from the Create Page. We generate the names from title here too. We display them in the breadcrumb, but in a more simple way. Displaying the "localhost"/server part is not simple user behavior. AWM is more complex.
-----
So I would not change anything on the product side, since I believe these should be solved as custom changes for your instance. We want to encourage users to use page titles (with spaces in them since they are more readable and supported), while we are preserving the page name behavior for advances users (but we don't enforce it).
I don’t agree with this sentence: We definitely don’t want to encourage users to use titles in URLs.
If users made mistakes they can always change the title or rename the page. On the product side the only change I would like us to do is using the URL naming, but this was debated in the past and dropped for Vincent's reasons.
What reasons, I don’t remember a discussion about using URL name instead of page name? So our main disagreement is that I consider that favouring encoded characters in URLs is not a good thing while you think it’s not a large enough problem to do something about it. Would it make our UI too complex to use for simple users if we were showing a URL and the ability to change the last part of it? IMO what’s complex is when we have Page name and Page Title. But I don’t feel there’d be confusion between URL and Page title. What do others think? Thanks -Vincent
Thanks, Caty
On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol <[email protected]> wrote:
On 20 Apr 2017, at 22:51, Vincent Massol <[email protected]> wrote:
Hi Vishal,
Ok, I misunderstood you in your first email. I understood the opposite. I thought you were complaining that have 2 notions (page name + page title) was confusing but it’s actually the opposite! What you find confusing is the fact that it’s not easy for your users to set both the page name and page titles!
It’s funny (or not :)) since this is exactly what we had in past versions of XWiki and we had several complaints that it was confusing to have the 2 notions and this is why he hid the page name only for advanced users.
Actually, if I remember well, what we were doing was to ask for the page name and we were setting the title to the same as the page name by default and then the user could edit the title before saving the page.
We’ve now done the opposite (user deciding on the title and page name being derived from it) but leading to the issue you’re raising about URL SEO…
Thanks -Vincent
See below.
On 20 Apr 2017, at 14:20, Vishal <[email protected]> wrote:
Thanks Vincent for your thorough reply.. You guessed it right. We intend to have clean and short urls for SEO reasons. Current scheme creates two problems:
1) The Page name is fetched automatically from the Title. Often the titles have spaces which translate as *percent characters *in url which makes it somewhat unclean :)
Indeed you’re right. By hiding the page name we’re now incitating to have longer URLs and encoded characters showing up in URLs which is not nice I agree.
Maybe one solution is to do something similar to what we do in AWM, i.e. generate automatically the URL from the title entered by the user and show the resulting URL to the user and give the user the opportunity to change the URL.
See http://extensions.xwiki.org/xwiki/bin/download/Extension/ App%20Within%20Minutes%20Application/AppWithinMinutes-Step1.png
2) Secondly, to have the shorter url, we use only the short forms of complete title. Ex. For title 'Pune University' we use name PU.
Hey, you’re from Pune? :) I’ve been there about 15 times! That was in a previous job where my company and KPIT Cummins were partners.
Otherwise in this hierarchy of pages, the url would be much longer. Ex. We have page 'Electronics and Telecommunications' branch under page 'Pune University'. We should not have such a long url. Instead here we need PU/ENTC or Pune-University/ENTC
To avoid all this, what we currently do: 1) On create page dialog, use PU as title.. This will create url as PU. If full name is used here as title, we need to use - instead of spaces to avoid percent characters in url. 2) While in edit mode, change the title back to Pune University. Remove any - characters to make title clean. This is where confusion creeps in.
If these two terms create confusion, why I need to show them both: I guess the *confusion is due to term Name*. It doesn't reflect actual usage of the term. URL or weblink or link or web address would be more apt terms to use to instead of Name.
Regarding Page name vs Page URL.
A bit of history: The reason we used page name and not page URL originally is because what the user is creating is a document in the database and initially it was called Document Name. Since that was a bit confusing for users, we had decided to call it Page Name. It just happened that the URL used was directly derived from the document/page name.
In practice the 3 concepts could have different values: * a value for the document’s name in the DB * another value for the document’s title * yet another value used in the URL.
We’ve had discussions so that we could let the user provide shorter URLs for pages in the future.
Now for the time being and since we don’t have this ATM, I think I agree with you that we could decide to display to the user the URL that will be generated (the encoded URL) and allow the user to change it. Internally the user would change the document name.
My users can differentiate between Title and URL. But the whole procedure we follow is certainly not understandable by all. And we definitely need to follow this whole long procedure, just to have short and clean urls.
Yes, if you’re asking your users to care about the URLs that get generated, right now they need to be advanced users to be able to edit the page name in the Create Page UI (since changing the title afterwards is too cumbersome).
So, by showing both fields at the first place itself, I would like to shorten the procedure and url length.
I’m in agreement with you. Let’s see what others think.
Thanks for this interesting discussion! -Vincent
-- View this message in context: http://xwiki.475771.n2.nabble. com/Page-Title-and-Name-confusion-tp7603546p7603551.html Sent from the XWiki- Users mailing list archive at Nabble.com.
This is quite an interesting discussion and I'd like to add a few points if you don't mind. When we first started using XWiki, our users did comment about the really long URLs that were being generated from the Title. But as our XWiki is internal only for documentation, I kind of brushed it off with "That's just the way it works". But I agree that in some cases it would be good to be able to edit the resulting URL. Both for us, and obviously for other users. :-) In regards of how to achieve this, I'd like to propose a half-way house/compromise. Firstly, create an Admin option in the Admin control panel to the effect of: "Allow users to edit the Page URL when creating new pages" - Always - Optional - Never (Default) Then on the create page, you would have the following "minor" changes (I say minor because changes are always minor to the person who is not doing the programming ;-) ) If the Admin option is "Never" then the create page remains as it is. If the Admin option is "Optional" then there should be a link/button under Title that is called "Edit Page URL". This would be an extra button on the current create page form. When the user clicks the button/link, they then get another text box in which to specify the URL parameter. If the Admin option is "Always" then the create page will show "Page Title" (as it is currently) and will also show the "Page URL" text box. Ideally, this Page URL text box should be auto-populated with the proposed auto-generated name from the title (unless the Page URL is edited before the Page Title). Obviously you'll have to do a few other checks to make sure it's a valid entry for a URL in both cases (but you may have this already from the old version where both options always showed). I also recommend that the current description text for Title is changed from the very short "Title of the new page" to "This is Title Heading shown at the top of the document when viewed. The Page URL is auto-generated from this title" Kind regards, Mahomed Hussein Custodian Data Centre Email: [email protected] http://www.CustodianDC.com -----Original Message----- From: users [mailto:[email protected]] On Behalf Of Vincent Massol Sent: 21 April 2017 12:16 To: XWiki Users <[email protected]> Subject: Re: [xwiki-users] display page title and name(url) while creating a page Hi Caty,
On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) <[email protected]> wrote:
Let's see what variants we have:
1. Instead of displaying "Title", display the "Name" instead. This won't solve anything. There is no difference between Page Name and Page Title for the normal users. Seeing "Name" instead of "Title", will not stop the users to enter spaces if they want, so the URL will still have those spaces. We don't force the Page Names to trim spaces.
One quick solution here is indeed to use "URL" label instead of "Name". For the reasons Vincent mentioned this might not end up in the product for now,
What did I mention? :) What’s preventing us from having it in the product rather soon than later (except workload ofc)?
so you will need to do some custom development (changing some translations) to have this change. If you want to be "hackish" you can even change the translation for "Title" to "URL" instead and hope that your users will enter shorter URLs (since we generate the name from the title).
Displaying just Name / URL, means users will still have to go and change the title manually.
This could be better (with URL name) since when you create a page you’re offered the ability to change the title after you click Create.
The only way to cut a step in the flow is to autogenerate the page names (which we currently do). But for your use case you shoyld write a shorting/trimming algorithm, but this is custom, since you mentioned you want just the initials and no spaces, etc.
2. Displaying both "Title" and "Name". This will create confusion and need for explanations.
This is not exactly what is suggested either by Vishal nor by me :) What we suggested is to let the user enter the URL name and title. Actually and to be more precise what I was suggesting was to continue to let the user enter the title but to show the generated URL as it’s done in AWM. And, importantly to allow the user to change the last part of the URL (it would change the page name).
That's why we display these options just for advanced and long-time users of XWiki, since they are used to the concepts.
Yes but URLs don't need an advanced user to understand the concept and I agree with Vishal that we’re now causing a very large number of pages to have %25 in their URLs by default which is quite bad… Of course someone can spend their time monitoring what users are doing and renaming pages thereafter or educate their users to do that but we’re not helping and we’re making it difficult.
-----
IMO what you are describing is advanced user behavior. Normal users don't generally care about their URLs and SEO.
I don’t fully agree with you. I have the feeling (can’t prove it) that a good number of our users care about the generated URLs. Also I think that simple users may care about URL without being advanced users. Making them advanced users will expose them to a lot more complexity than they need to know.
But the beauty of XWiki is that you can customize it locally to perfectly match your needs.
That’s not exactly true (and it’s far from being easy, just check createinline.vm): It means overriding large portions of vm code and having to do manual merges whenever you upgrade. A major PITA.
Vincent mentioned something about AWM. I don't see much difference from the Create Page. We generate the names from title here too. We display them in the breadcrumb, but in a more simple way. Displaying the "localhost"/server part is not simple user behavior. AWM is more complex.
-----
So I would not change anything on the product side, since I believe these should be solved as custom changes for your instance. We want to encourage users to use page titles (with spaces in them since they are more readable and supported), while we are preserving the page name behavior for advances users (but we don't enforce it).
I don’t agree with this sentence: We definitely don’t want to encourage users to use titles in URLs.
If users made mistakes they can always change the title or rename the page. On the product side the only change I would like us to do is using the URL naming, but this was debated in the past and dropped for Vincent's reasons.
What reasons, I don’t remember a discussion about using URL name instead of page name? So our main disagreement is that I consider that favouring encoded characters in URLs is not a good thing while you think it’s not a large enough problem to do something about it. Would it make our UI too complex to use for simple users if we were showing a URL and the ability to change the last part of it? IMO what’s complex is when we have Page name and Page Title. But I don’t feel there’d be confusion between URL and Page title. What do others think? Thanks -Vincent
Thanks, Caty
On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol <[email protected]> wrote:
On 20 Apr 2017, at 22:51, Vincent Massol <[email protected]> wrote:
Hi Vishal,
Ok, I misunderstood you in your first email. I understood the opposite. I thought you were complaining that have 2 notions (page name + page title) was confusing but it’s actually the opposite! What you find confusing is the fact that it’s not easy for your users to set both the page name and page titles!
It’s funny (or not :)) since this is exactly what we had in past versions of XWiki and we had several complaints that it was confusing to have the 2 notions and this is why he hid the page name only for advanced users.
Actually, if I remember well, what we were doing was to ask for the page name and we were setting the title to the same as the page name by default and then the user could edit the title before saving the page.
We’ve now done the opposite (user deciding on the title and page name being derived from it) but leading to the issue you’re raising about URL SEO…
Thanks -Vincent
See below.
On 20 Apr 2017, at 14:20, Vishal <[email protected]> wrote:
Thanks Vincent for your thorough reply.. You guessed it right. We intend to have clean and short urls for SEO reasons. Current scheme creates two problems:
1) The Page name is fetched automatically from the Title. Often the titles have spaces which translate as *percent characters *in url which makes it somewhat unclean :)
Indeed you’re right. By hiding the page name we’re now incitating to have longer URLs and encoded characters showing up in URLs which is not nice I agree.
Maybe one solution is to do something similar to what we do in AWM, i.e. generate automatically the URL from the title entered by the user and show the resulting URL to the user and give the user the opportunity to change the URL.
See http://extensions.xwiki.org/xwiki/bin/download/Extension/ App%20Within%20Minutes%20Application/AppWithinMinutes-Step1.png
2) Secondly, to have the shorter url, we use only the short forms of complete title. Ex. For title 'Pune University' we use name PU.
Hey, you’re from Pune? :) I’ve been there about 15 times! That was in a previous job where my company and KPIT Cummins were partners.
Otherwise in this hierarchy of pages, the url would be much longer. Ex. We have page 'Electronics and Telecommunications' branch under page 'Pune University'. We should not have such a long url. Instead here we need PU/ENTC or Pune-University/ENTC
To avoid all this, what we currently do: 1) On create page dialog, use PU as title.. This will create url as PU. If full name is used here as title, we need to use - instead of spaces to avoid percent characters in url. 2) While in edit mode, change the title back to Pune University. Remove any - characters to make title clean. This is where confusion creeps in.
If these two terms create confusion, why I need to show them both: I guess the *confusion is due to term Name*. It doesn't reflect actual usage of the term. URL or weblink or link or web address would be more apt terms to use to instead of Name.
Regarding Page name vs Page URL.
A bit of history: The reason we used page name and not page URL originally is because what the user is creating is a document in the database and initially it was called Document Name. Since that was a bit confusing for users, we had decided to call it Page Name. It just happened that the URL used was directly derived from the document/page name.
In practice the 3 concepts could have different values: * a value for the document’s name in the DB * another value for the document’s title * yet another value used in the URL.
We’ve had discussions so that we could let the user provide shorter URLs for pages in the future.
Now for the time being and since we don’t have this ATM, I think I agree with you that we could decide to display to the user the URL that will be generated (the encoded URL) and allow the user to change it. Internally the user would change the document name.
My users can differentiate between Title and URL. But the whole procedure we follow is certainly not understandable by all. And we definitely need to follow this whole long procedure, just to have short and clean urls.
Yes, if you’re asking your users to care about the URLs that get generated, right now they need to be advanced users to be able to edit the page name in the Create Page UI (since changing the title afterwards is too cumbersome).
So, by showing both fields at the first place itself, I would like to shorten the procedure and url length.
I’m in agreement with you. Let’s see what others think.
Thanks for this interesting discussion! -Vincent
-- View this message in context: http://xwiki.475771.n2.nabble. com/Page-Title-and-Name-confusion-tp7603546p7603551.html Sent from the XWiki- Users mailing list archive at Nabble.com.
On Fri, Apr 21, 2017 at 2:16 PM, Vincent Massol <[email protected]> wrote:
Hi Caty,
On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) <[email protected]> wrote:
Let's see what variants we have:
1. Instead of displaying "Title", display the "Name" instead. This won't solve anything. There is no difference between Page Name and Page Title for the normal users. Seeing "Name" instead of "Title", will not stop the users to enter spaces if they want, so the URL will still have those spaces. We don't force the Page Names to trim spaces.
One quick solution here is indeed to use "URL" label instead of "Name". For the reasons Vincent mentioned this might not end up in the product for now,
What did I mention? :) What’s preventing us from having it in the product rather soon than later (except workload ofc)?
so you will need to do some custom development (changing some translations) to have this change. If you want to be "hackish" you can even change the translation for "Title" to "URL" instead and hope that your users will enter shorter URLs (since we generate the name from the title).
Displaying just Name / URL, means users will still have to go and change the title manually.
This could be better (with URL name) since when you create a page you’re offered the ability to change the title after you click Create.
The only way to cut a step in the flow is to autogenerate the page names (which we currently do). But for your use case you shoyld write a shorting/trimming algorithm, but this is custom, since you mentioned you want just the initials and no spaces, etc.
2. Displaying both "Title" and "Name". This will create confusion and need for explanations.
This is not exactly what is suggested either by Vishal nor by me :) What we suggested is to let the user enter the URL name and title.
Actually and to be more precise what I was suggesting was to continue to let the user enter the title but to show the generated URL as it’s done in AWM. And, importantly to allow the user to change the last part of the URL (it would change the page name).
That's why we display these options just for advanced and long-time users of XWiki, since they are used to the concepts.
Yes but URLs don't need an advanced user to understand the concept and I agree with Vishal that we’re now causing a very large number of pages to have %25 in their URLs by default which is quite bad… Of course someone can spend their time monitoring what users are doing and renaming pages thereafter or educate their users to do that but we’re not helping and we’re making it difficult.
If your web site is not in English then you're forced to use special characters like diacritics which makes it hard to avoid URL encoded characters (the browser location bar displays the URL nicely but if you copy the URL the result is not nice).
-----
IMO what you are describing is advanced user behavior. Normal users don't generally care about their URLs and SEO.
I don’t fully agree with you. I have the feeling (can’t prove it) that a good number of our users care about the generated URLs.
Also I think that simple users may care about URL without being advanced users. Making them advanced users will expose them to a lot more complexity than they need to know.
But the beauty of XWiki is that you can customize it locally to perfectly match your needs.
That’s not exactly true (and it’s far from being easy, just check createinline.vm): It means overriding large portions of vm code and having to do manual merges whenever you upgrade. A major PITA.
Vincent mentioned something about AWM. I don't see much difference from the Create Page. We generate the names from title here too. We display them in the breadcrumb, but in a more simple way. Displaying the "localhost"/server part is not simple user behavior. AWM is more complex.
-----
So I would not change anything on the product side, since I believe these should be solved as custom changes for your instance. We want to encourage users to use page titles (with spaces in them since they are more readable and supported), while we are preserving the page name behavior for advances users (but we don't enforce it).
I don’t agree with this sentence: We definitely don’t want to encourage users to use titles in URLs.
If users made mistakes they can always change the title or rename the page. On the product side the only change I would like us to do is using the URL naming, but this was debated in the past and dropped for Vincent's reasons.
What reasons, I don’t remember a discussion about using URL name instead of page name?
So our main disagreement is that I consider that favouring encoded characters in URLs is not a good thing while you think it’s not a large enough problem to do something about it.
Would it make our UI too complex to use for simple users if we were showing a URL and the ability to change the last part of it? IMO what’s complex is when we have Page name and Page Title. But I don’t feel there’d be confusion between URL and Page title.
What do others think?
Thanks -Vincent
Thanks, Caty
On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol <[email protected]>
wrote:
On 20 Apr 2017, at 22:51, Vincent Massol <[email protected]> wrote:
Hi Vishal,
Ok, I misunderstood you in your first email. I understood the opposite. I thought you were complaining that have 2 notions (page name + page
title)
was confusing but it’s actually the opposite! What you find confusing is the fact that it’s not easy for your users to set both the page name and page titles!
It’s funny (or not :)) since this is exactly what we had in past
versions of XWiki and we had several complaints that it was confusing to have the 2 notions and this is why he hid the page name only for advanced users.
Actually, if I remember well, what we were doing was to ask for the page name and we were setting the title to the same as the page name by default and then the user could edit the title before saving the page.
We’ve now done the opposite (user deciding on the title and page name being derived from it) but leading to the issue you’re raising about URL SEO…
Thanks -Vincent
See below.
On 20 Apr 2017, at 14:20, Vishal <[email protected]> wrote:
Thanks Vincent for your thorough reply.. You guessed it right. We intend to have clean and short urls for SEO reasons. Current scheme creates two problems:
1) The Page name is fetched automatically from the Title. Often the titles have spaces which translate as *percent characters *in url which makes it somewhat unclean :)
Indeed you’re right. By hiding the page name we’re now incitating to have longer URLs and encoded characters showing up in URLs which is not nice I agree.
Maybe one solution is to do something similar to what we do in AWM, i.e. generate automatically the URL from the title entered by the user and show the resulting URL to the user and give the user the opportunity to change the URL.
See http://extensions.xwiki.org/xwiki/bin/download/Extension/ App%20Within%20Minutes%20Application/AppWithinMinutes-Step1.png
2) Secondly, to have the shorter url, we use only the short forms of complete title. Ex. For title 'Pune University' we use name PU.
Hey, you’re from Pune? :) I’ve been there about 15 times! That was in a previous job where my company and KPIT Cummins were partners.
Otherwise in this hierarchy of pages, the url would be much longer. Ex. We have page 'Electronics and Telecommunications' branch under page 'Pune University'. We should not have such a long url. Instead here we need PU/ENTC or Pune-University/ENTC
To avoid all this, what we currently do: 1) On create page dialog, use PU as title.. This will create url as PU. If full name is used here as title, we need to use - instead of spaces to avoid percent characters in url. 2) While in edit mode, change the title back to Pune University. Remove any - characters to make title clean. This is where confusion creeps in.
If these two terms create confusion, why I need to show them both: I guess the *confusion is due to term Name*. It doesn't reflect actual usage of the term. URL or weblink or link or web address would be more apt terms to use to instead of Name.
Regarding Page name vs Page URL.
A bit of history: The reason we used page name and not page URL originally is because what the user is creating is a document in the database and initially it was called Document Name. Since that was a bit confusing for users, we had decided to call it Page Name. It just happened that the URL used was directly derived from the document/page name.
In practice the 3 concepts could have different values: * a value for the document’s name in the DB * another value for the document’s title * yet another value used in the URL.
We’ve had discussions so that we could let the user provide shorter URLs for pages in the future.
Now for the time being and since we don’t have this ATM, I think I agree with you that we could decide to display to the user the URL that will be generated (the encoded URL) and allow the user to change it. Internally the user would change the document name.
My users can differentiate between Title and URL. But the whole procedure we follow is certainly not understandable by all. And we definitely need to follow this whole long procedure, just to have short and clean urls.
Yes, if you’re asking your users to care about the URLs that get generated, right now they need to be advanced users to be able to edit the page name in the Create Page UI (since changing the title afterwards is too cumbersome).
So, by showing both fields at the first place itself, I would like to shorten the procedure and url length.
I’m in agreement with you. Let’s see what others think.
Thanks for this interesting discussion! -Vincent
-- View this message in context: http://xwiki.475771.n2.nabble. com/Page-Title-and-Name-confusion-tp7603546p7603551.html Sent from the XWiki- Users mailing list archive at Nabble.com.
Hi Mahomed,
On 21 Apr 2017, at 13:50, Mahomed Hussein <[email protected]> wrote:
This is quite an interesting discussion and I'd like to add a few points if you don't mind.
When we first started using XWiki, our users did comment about the really long URLs that were being generated from the Title. But as our XWiki is internal only for documentation, I kind of brushed it off with "That's just the way it works".
But I agree that in some cases it would be good to be able to edit the resulting URL. Both for us, and obviously for other users. :-)
In regards of how to achieve this, I'd like to propose a half-way house/compromise.
Firstly, create an Admin option in the Admin control panel to the effect of:
"Allow users to edit the Page URL when creating new pages" - Always - Optional - Never (Default)
Thanks for participating to the discussion! :) We need the max # of users to provide an opinion. The fact that the default would be “Never” in your proposal above wouldn’t help that much since by default users wouldn’t be able to control the URLs and thus you’d need to educate everyone that they need to turn this on. It’s quite similar to telling your users to be Advanced users. Now, what could be done is having some Admin settings for the defaults when a user account is created in your wiki. It’s just a bit more work and the Admin would still to know about this and thus it’s extra knowledge/complexity to use XWiki. Now we would need to do something like this if we cannot agree that in all cases it’s ok to have the URL displayed in the Create page. If we agree that it’s fine then this config option is not required. Thanks -Vincent
Then on the create page, you would have the following "minor" changes (I say minor because changes are always minor to the person who is not doing the programming ;-) )
If the Admin option is "Never" then the create page remains as it is.
If the Admin option is "Optional" then there should be a link/button under Title that is called "Edit Page URL". This would be an extra button on the current create page form. When the user clicks the button/link, they then get another text box in which to specify the URL parameter.
If the Admin option is "Always" then the create page will show "Page Title" (as it is currently) and will also show the "Page URL" text box. Ideally, this Page URL text box should be auto-populated with the proposed auto-generated name from the title (unless the Page URL is edited before the Page Title). Obviously you'll have to do a few other checks to make sure it's a valid entry for a URL in both cases (but you may have this already from the old version where both options always showed).
I also recommend that the current description text for Title is changed from the very short "Title of the new page" to "This is Title Heading shown at the top of the document when viewed. The Page URL is auto-generated from this title"
Kind regards,
Mahomed Hussein Custodian Data Centre Email: [email protected] http://www.CustodianDC.com
-----Original Message----- From: users [mailto:[email protected]] On Behalf Of Vincent Massol Sent: 21 April 2017 12:16 To: XWiki Users <[email protected]> Subject: Re: [xwiki-users] display page title and name(url) while creating a page
Hi Caty,
On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) <[email protected]> wrote:
Let's see what variants we have:
1. Instead of displaying "Title", display the "Name" instead. This won't solve anything. There is no difference between Page Name and Page Title for the normal users. Seeing "Name" instead of "Title", will not stop the users to enter spaces if they want, so the URL will still have those spaces. We don't force the Page Names to trim spaces.
One quick solution here is indeed to use "URL" label instead of "Name". For the reasons Vincent mentioned this might not end up in the product for now,
What did I mention? :) What’s preventing us from having it in the product rather soon than later (except workload ofc)?
so you will need to do some custom development (changing some translations) to have this change. If you want to be "hackish" you can even change the translation for "Title" to "URL" instead and hope that your users will enter shorter URLs (since we generate the name from the title).
Displaying just Name / URL, means users will still have to go and change the title manually.
This could be better (with URL name) since when you create a page you’re offered the ability to change the title after you click Create.
The only way to cut a step in the flow is to autogenerate the page names (which we currently do). But for your use case you shoyld write a shorting/trimming algorithm, but this is custom, since you mentioned you want just the initials and no spaces, etc.
2. Displaying both "Title" and "Name". This will create confusion and need for explanations.
This is not exactly what is suggested either by Vishal nor by me :) What we suggested is to let the user enter the URL name and title.
Actually and to be more precise what I was suggesting was to continue to let the user enter the title but to show the generated URL as it’s done in AWM. And, importantly to allow the user to change the last part of the URL (it would change the page name).
That's why we display these options just for advanced and long-time users of XWiki, since they are used to the concepts.
Yes but URLs don't need an advanced user to understand the concept and I agree with Vishal that we’re now causing a very large number of pages to have %25 in their URLs by default which is quite bad… Of course someone can spend their time monitoring what users are doing and renaming pages thereafter or educate their users to do that but we’re not helping and we’re making it difficult.
-----
IMO what you are describing is advanced user behavior. Normal users don't generally care about their URLs and SEO.
I don’t fully agree with you. I have the feeling (can’t prove it) that a good number of our users care about the generated URLs.
Also I think that simple users may care about URL without being advanced users. Making them advanced users will expose them to a lot more complexity than they need to know.
But the beauty of XWiki is that you can customize it locally to perfectly match your needs.
That’s not exactly true (and it’s far from being easy, just check createinline.vm): It means overriding large portions of vm code and having to do manual merges whenever you upgrade. A major PITA.
Vincent mentioned something about AWM. I don't see much difference from the Create Page. We generate the names from title here too. We display them in the breadcrumb, but in a more simple way. Displaying the "localhost"/server part is not simple user behavior. AWM is more complex.
-----
So I would not change anything on the product side, since I believe these should be solved as custom changes for your instance. We want to encourage users to use page titles (with spaces in them since they are more readable and supported), while we are preserving the page name behavior for advances users (but we don't enforce it).
I don’t agree with this sentence: We definitely don’t want to encourage users to use titles in URLs.
If users made mistakes they can always change the title or rename the page. On the product side the only change I would like us to do is using the URL naming, but this was debated in the past and dropped for Vincent's reasons.
What reasons, I don’t remember a discussion about using URL name instead of page name?
So our main disagreement is that I consider that favouring encoded characters in URLs is not a good thing while you think it’s not a large enough problem to do something about it.
Would it make our UI too complex to use for simple users if we were showing a URL and the ability to change the last part of it? IMO what’s complex is when we have Page name and Page Title. But I don’t feel there’d be confusion between URL and Page title.
What do others think?
Thanks -Vincent
Thanks, Caty
On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol <[email protected]> wrote:
On 20 Apr 2017, at 22:51, Vincent Massol <[email protected]> wrote:
Hi Vishal,
Ok, I misunderstood you in your first email. I understood the opposite. I thought you were complaining that have 2 notions (page name + page title) was confusing but it’s actually the opposite! What you find confusing is the fact that it’s not easy for your users to set both the page name and page titles!
It’s funny (or not :)) since this is exactly what we had in past versions of XWiki and we had several complaints that it was confusing to have the 2 notions and this is why he hid the page name only for advanced users.
Actually, if I remember well, what we were doing was to ask for the page name and we were setting the title to the same as the page name by default and then the user could edit the title before saving the page.
We’ve now done the opposite (user deciding on the title and page name being derived from it) but leading to the issue you’re raising about URL SEO…
Thanks -Vincent
See below.
On 20 Apr 2017, at 14:20, Vishal <[email protected]> wrote:
Thanks Vincent for your thorough reply.. You guessed it right. We intend to have clean and short urls for SEO reasons. Current scheme creates two problems:
1) The Page name is fetched automatically from the Title. Often the titles have spaces which translate as *percent characters *in url which makes it somewhat unclean :)
Indeed you’re right. By hiding the page name we’re now incitating to have longer URLs and encoded characters showing up in URLs which is not nice I agree.
Maybe one solution is to do something similar to what we do in AWM, i.e. generate automatically the URL from the title entered by the user and show the resulting URL to the user and give the user the opportunity to change the URL.
See http://extensions.xwiki.org/xwiki/bin/download/Extension/ App%20Within%20Minutes%20Application/AppWithinMinutes-Step1.png
2) Secondly, to have the shorter url, we use only the short forms of complete title. Ex. For title 'Pune University' we use name PU.
Hey, you’re from Pune? :) I’ve been there about 15 times! That was in a previous job where my company and KPIT Cummins were partners.
Otherwise in this hierarchy of pages, the url would be much longer. Ex. We have page 'Electronics and Telecommunications' branch under page 'Pune University'. We should not have such a long url. Instead here we need PU/ENTC or Pune-University/ENTC
To avoid all this, what we currently do: 1) On create page dialog, use PU as title.. This will create url as PU. If full name is used here as title, we need to use - instead of spaces to avoid percent characters in url. 2) While in edit mode, change the title back to Pune University. Remove any - characters to make title clean. This is where confusion creeps in.
If these two terms create confusion, why I need to show them both: I guess the *confusion is due to term Name*. It doesn't reflect actual usage of the term. URL or weblink or link or web address would be more apt terms to use to instead of Name.
Regarding Page name vs Page URL.
A bit of history: The reason we used page name and not page URL originally is because what the user is creating is a document in the database and initially it was called Document Name. Since that was a bit confusing for users, we had decided to call it Page Name. It just happened that the URL used was directly derived from the document/page name.
In practice the 3 concepts could have different values: * a value for the document’s name in the DB * another value for the document’s title * yet another value used in the URL.
We’ve had discussions so that we could let the user provide shorter URLs for pages in the future.
Now for the time being and since we don’t have this ATM, I think I agree with you that we could decide to display to the user the URL that will be generated (the encoded URL) and allow the user to change it. Internally the user would change the document name.
My users can differentiate between Title and URL. But the whole procedure we follow is certainly not understandable by all. And we definitely need to follow this whole long procedure, just to have short and clean urls.
Yes, if you’re asking your users to care about the URLs that get generated, right now they need to be advanced users to be able to edit the page name in the Create Page UI (since changing the title afterwards is too cumbersome).
So, by showing both fields at the first place itself, I would like to shorten the procedure and url length.
I’m in agreement with you. Let’s see what others think.
Thanks for this interesting discussion! -Vincent
-- View this message in context: http://xwiki.475771.n2.nabble. com/Page-Title-and-Name-confusion-tp7603546p7603551.html Sent from the XWiki- Users mailing list archive at Nabble.com.
On 21 Apr 2017, at 13:52, Marius Dumitru Florea <[email protected]> wrote:
On Fri, Apr 21, 2017 at 2:16 PM, Vincent Massol <[email protected]> wrote:
Hi Caty,
On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) <[email protected]> wrote:
Let's see what variants we have:
1. Instead of displaying "Title", display the "Name" instead. This won't solve anything. There is no difference between Page Name and Page Title for the normal users. Seeing "Name" instead of "Title", will not stop the users to enter spaces if they want, so the URL will still have those spaces. We don't force the Page Names to trim spaces.
One quick solution here is indeed to use "URL" label instead of "Name". For the reasons Vincent mentioned this might not end up in the product for now,
What did I mention? :) What’s preventing us from having it in the product rather soon than later (except workload ofc)?
so you will need to do some custom development (changing some translations) to have this change. If you want to be "hackish" you can even change the translation for "Title" to "URL" instead and hope that your users will enter shorter URLs (since we generate the name from the title).
Displaying just Name / URL, means users will still have to go and change the title manually.
This could be better (with URL name) since when you create a page you’re offered the ability to change the title after you click Create.
The only way to cut a step in the flow is to autogenerate the page names (which we currently do). But for your use case you shoyld write a shorting/trimming algorithm, but this is custom, since you mentioned you want just the initials and no spaces, etc.
2. Displaying both "Title" and "Name". This will create confusion and need for explanations.
This is not exactly what is suggested either by Vishal nor by me :) What we suggested is to let the user enter the URL name and title.
Actually and to be more precise what I was suggesting was to continue to let the user enter the title but to show the generated URL as it’s done in AWM. And, importantly to allow the user to change the last part of the URL (it would change the page name).
That's why we display these options just for advanced and long-time users of XWiki, since they are used to the concepts.
Yes but URLs don't need an advanced user to understand the concept and I agree with Vishal that we’re now causing a very large number of pages to have %25 in their URLs by default which is quite bad… Of course someone can spend their time monitoring what users are doing and renaming pages thereafter or educate their users to do that but we’re not helping and we’re making it difficult.
If your web site is not in English then you're forced to use special characters like diacritics which makes it hard to avoid URL encoded characters (the browser location bar displays the URL nicely but if you copy the URL the result is not nice).
Agreed. So I’d say it’s even more important to allow the user to be able to easily view and change the resulting URL when they’re not in English. Thanks -Vincent
-----
IMO what you are describing is advanced user behavior. Normal users don't generally care about their URLs and SEO.
I don’t fully agree with you. I have the feeling (can’t prove it) that a good number of our users care about the generated URLs.
Also I think that simple users may care about URL without being advanced users. Making them advanced users will expose them to a lot more complexity than they need to know.
But the beauty of XWiki is that you can customize it locally to perfectly match your needs.
That’s not exactly true (and it’s far from being easy, just check createinline.vm): It means overriding large portions of vm code and having to do manual merges whenever you upgrade. A major PITA.
Vincent mentioned something about AWM. I don't see much difference from the Create Page. We generate the names from title here too. We display them in the breadcrumb, but in a more simple way. Displaying the "localhost"/server part is not simple user behavior. AWM is more complex.
-----
So I would not change anything on the product side, since I believe these should be solved as custom changes for your instance. We want to encourage users to use page titles (with spaces in them since they are more readable and supported), while we are preserving the page name behavior for advances users (but we don't enforce it).
I don’t agree with this sentence: We definitely don’t want to encourage users to use titles in URLs.
If users made mistakes they can always change the title or rename the page. On the product side the only change I would like us to do is using the URL naming, but this was debated in the past and dropped for Vincent's reasons.
What reasons, I don’t remember a discussion about using URL name instead of page name?
So our main disagreement is that I consider that favouring encoded characters in URLs is not a good thing while you think it’s not a large enough problem to do something about it.
Would it make our UI too complex to use for simple users if we were showing a URL and the ability to change the last part of it? IMO what’s complex is when we have Page name and Page Title. But I don’t feel there’d be confusion between URL and Page title.
What do others think?
Thanks -Vincent
Thanks, Caty
On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol <[email protected]>
wrote:
On 20 Apr 2017, at 22:51, Vincent Massol <[email protected]> wrote:
Hi Vishal,
Ok, I misunderstood you in your first email. I understood the opposite. I thought you were complaining that have 2 notions (page name + page
title)
was confusing but it’s actually the opposite! What you find confusing is the fact that it’s not easy for your users to set both the page name and page titles!
It’s funny (or not :)) since this is exactly what we had in past
versions of XWiki and we had several complaints that it was confusing to have the 2 notions and this is why he hid the page name only for advanced users.
Actually, if I remember well, what we were doing was to ask for the page name and we were setting the title to the same as the page name by default and then the user could edit the title before saving the page.
We’ve now done the opposite (user deciding on the title and page name being derived from it) but leading to the issue you’re raising about URL SEO…
Thanks -Vincent
See below.
On 20 Apr 2017, at 14:20, Vishal <[email protected]> wrote:
Thanks Vincent for your thorough reply.. You guessed it right. We intend to have clean and short urls for SEO reasons. Current scheme creates two problems:
1) The Page name is fetched automatically from the Title. Often the titles have spaces which translate as *percent characters *in url which makes it somewhat unclean :)
Indeed you’re right. By hiding the page name we’re now incitating to have longer URLs and encoded characters showing up in URLs which is not nice I agree.
Maybe one solution is to do something similar to what we do in AWM, i.e. generate automatically the URL from the title entered by the user and show the resulting URL to the user and give the user the opportunity to change the URL.
See http://extensions.xwiki.org/xwiki/bin/download/Extension/ App%20Within%20Minutes%20Application/AppWithinMinutes-Step1.png
2) Secondly, to have the shorter url, we use only the short forms of complete title. Ex. For title 'Pune University' we use name PU.
Hey, you’re from Pune? :) I’ve been there about 15 times! That was in a previous job where my company and KPIT Cummins were partners.
Otherwise in this hierarchy of pages, the url would be much longer. Ex. We have page 'Electronics and Telecommunications' branch under page 'Pune University'. We should not have such a long url. Instead here we need PU/ENTC or Pune-University/ENTC
To avoid all this, what we currently do: 1) On create page dialog, use PU as title.. This will create url as PU. If full name is used here as title, we need to use - instead of spaces to avoid percent characters in url. 2) While in edit mode, change the title back to Pune University. Remove any - characters to make title clean. This is where confusion creeps in.
If these two terms create confusion, why I need to show them both: I guess the *confusion is due to term Name*. It doesn't reflect actual usage of the term. URL or weblink or link or web address would be more apt terms to use to instead of Name.
Regarding Page name vs Page URL.
A bit of history: The reason we used page name and not page URL originally is because what the user is creating is a document in the database and initially it was called Document Name. Since that was a bit confusing for users, we had decided to call it Page Name. It just happened that the URL used was directly derived from the document/page name.
In practice the 3 concepts could have different values: * a value for the document’s name in the DB * another value for the document’s title * yet another value used in the URL.
We’ve had discussions so that we could let the user provide shorter URLs for pages in the future.
Now for the time being and since we don’t have this ATM, I think I agree with you that we could decide to display to the user the URL that will be generated (the encoded URL) and allow the user to change it. Internally the user would change the document name.
My users can differentiate between Title and URL. But the whole procedure we follow is certainly not understandable by all. And we definitely need to follow this whole long procedure, just to have short and clean urls.
Yes, if you’re asking your users to care about the URLs that get generated, right now they need to be advanced users to be able to edit the page name in the Create Page UI (since changing the title afterwards is too cumbersome).
So, by showing both fields at the first place itself, I would like to shorten the procedure and url length.
I’m in agreement with you. Let’s see what others think.
Thanks for this interesting discussion! -Vincent
-- View this message in context: http://xwiki.475771.n2.nabble. com/Page-Title-and-Name-confusion-tp7603546p7603551.html Sent from the XWiki- Users mailing list archive at Nabble.com.
Hi, let me enter into this conversion. Some time ago I've asked for help how to solve problem with diacritics (or accents) in page names when creating new pages so that the have url-friendly names. You can search for "strip accents from page name used in url" in xwiki users mailing list. I've got no hint or solution from xwiki community till today. I've come with solution that ensures for simple users, creating url-friendly names without requiring them to think about the concept of the page name or page title. They simple enter the desired human readably page name, and in the code behind of the page creation, I have made some modifications in createinline.vm to hook into page creation process. The modifications are mainly javascript based, where I've attache to submit event of the "form#create", where I replace the entered "title" with the one for url-friendly. And for url-friendly name I've used this javascript based solution on https://pid.github.io/speakingurl/. I've integrated this principle also into page creation process of FAQ and Blog applications, which we are using in our xwiki installation. It would be nice if you could integrate this principle into xwiki so that everyone can have nice url-friendly urls without worring about it. It is also suitable for english speaking users. You don't have to worry about entering spaces or other non-url allowed characters, which make url look ugly. Thank you Best regards Miroslav Galajda On 21 April 2017 at 14:02, Vincent Massol <[email protected]> wrote:
On 21 Apr 2017, at 13:52, Marius Dumitru Florea < [email protected]> wrote:
On Fri, Apr 21, 2017 at 2:16 PM, Vincent Massol <[email protected]> wrote:
Hi Caty,
On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) <[email protected]
wrote:
Let's see what variants we have:
1. Instead of displaying "Title", display the "Name" instead. This won't solve anything. There is no difference between Page Name and Page Title for the normal users. Seeing "Name" instead of "Title", will
not
stop the users to enter spaces if they want, so the URL will still have those spaces. We don't force the Page Names to trim spaces.
One quick solution here is indeed to use "URL" label instead of "Name". For the reasons Vincent mentioned this might not end up in the product for now,
What did I mention? :) What’s preventing us from having it in the product rather soon than later (except workload ofc)?
so you will need to do some custom development (changing some translations) to have this change. If you want to be "hackish" you can even change the translation for "Title" to "URL" instead and hope that your users will enter shorter URLs (since we generate the name from the title).
Displaying just Name / URL, means users will still have to go and change the title manually.
This could be better (with URL name) since when you create a page you’re offered the ability to change the title after you click Create.
The only way to cut a step in the flow is to autogenerate the page names (which we currently do). But for your use case you shoyld write a shorting/trimming algorithm, but this is custom, since you mentioned you want just the initials and no spaces, etc.
2. Displaying both "Title" and "Name". This will create confusion and need for explanations.
This is not exactly what is suggested either by Vishal nor by me :) What we suggested is to let the user enter the URL name and title.
Actually and to be more precise what I was suggesting was to continue to let the user enter the title but to show the generated URL as it’s done in AWM. And, importantly to allow the user to change the last part of the URL (it would change the page name).
That's why we display these options just for advanced and long-time users of XWiki, since they are used to the concepts.
Yes but URLs don't need an advanced user to understand the concept and I agree with Vishal that we’re now causing a very large number of pages to have %25 in their URLs by default which is quite bad… Of course someone can spend their time monitoring what users are doing and renaming pages thereafter or educate their users to do that but we’re not helping and we’re making it difficult.
If your web site is not in English then you're forced to use special characters like diacritics which makes it hard to avoid URL encoded characters (the browser location bar displays the URL nicely but if you copy the URL the result is not nice).
Agreed. So I’d say it’s even more important to allow the user to be able to easily view and change the resulting URL when they’re not in English.
Thanks -Vincent
-----
IMO what you are describing is advanced user behavior. Normal users
don't
generally care about their URLs and SEO.
I don’t fully agree with you. I have the feeling (can’t prove it) that a good number of our users care about the generated URLs.
Also I think that simple users may care about URL without being advanced users. Making them advanced users will expose them to a lot more complexity than they need to know.
But the beauty of XWiki is that you can customize it locally to perfectly match your needs.
That’s not exactly true (and it’s far from being easy, just check createinline.vm): It means overriding large portions of vm code and having to do manual merges whenever you upgrade. A major PITA.
Vincent mentioned something about AWM. I don't see much difference from the Create Page. We generate the names from title here too. We display them in the breadcrumb, but in a more simple way. Displaying the "localhost"/server part is not simple user behavior. AWM is more complex.
-----
So I would not change anything on the product side, since I believe these should be solved as custom changes for your instance. We want to encourage users to use page titles (with spaces in them since they are more readable and supported), while we are preserving the page name behavior for advances users (but we don't enforce it).
I don’t agree with this sentence: We definitely don’t want to encourage users to use titles in URLs.
If users made mistakes they can always change the title or rename the page. On the product side the only change I would like us to do is using the URL naming, but this was debated in the past and dropped for Vincent's reasons.
What reasons, I don’t remember a discussion about using URL name instead of page name?
So our main disagreement is that I consider that favouring encoded characters in URLs is not a good thing while you think it’s not a large enough problem to do something about it.
Would it make our UI too complex to use for simple users if we were showing a URL and the ability to change the last part of it? IMO what’s complex is when we have Page name and Page Title. But I don’t feel there’d be confusion between URL and Page title.
What do others think?
Thanks -Vincent
Thanks, Caty
On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol <[email protected]>
wrote:
On 20 Apr 2017, at 22:51, Vincent Massol <[email protected]> wrote:
Hi Vishal,
Ok, I misunderstood you in your first email. I understood the
opposite.
I thought you were complaining that have 2 notions (page name + page title) was confusing but it’s actually the opposite! What you find confusing is the fact that it’s not easy for your users to set both the page name and page titles!
It’s funny (or not :)) since this is exactly what we had in past
versions of XWiki and we had several complaints that it was confusing to have the 2 notions and this is why he hid the page name only for advanced users.
Actually, if I remember well, what we were doing was to ask for the page name and we were setting the title to the same as the page name by default and then the user could edit the title before saving the page.
We’ve now done the opposite (user deciding on the title and page name being derived from it) but leading to the issue you’re raising about URL SEO…
Thanks -Vincent
See below.
> On 20 Apr 2017, at 14:20, Vishal <[email protected]> wrote: > > Thanks Vincent for your thorough reply.. > You guessed it right. We intend to have clean and short urls for SEO > reasons. > Current scheme creates two problems: > > 1) The Page name is fetched automatically from the Title. Often the titles > have spaces which translate as *percent characters *in url which makes it > somewhat unclean :)
Indeed you’re right. By hiding the page name we’re now incitating to have longer URLs and encoded characters showing up in URLs which is not nice I agree.
Maybe one solution is to do something similar to what we do in AWM, i.e. generate automatically the URL from the title entered by the user and show the resulting URL to the user and give the user the opportunity to change the URL.
See http://extensions.xwiki.org/xwiki/bin/download/Extension/ App%20Within%20Minutes%20Application/AppWithinMinutes-Step1.png
> 2) Secondly, to have the shorter url, we use only the short forms of > complete title. > Ex. For title 'Pune University' we use name PU.
Hey, you’re from Pune? :) I’ve been there about 15 times! That was in a previous job where my company and KPIT Cummins were partners.
> Otherwise in this hierarchy of pages, the url would be much longer. > Ex. We have page 'Electronics and Telecommunications' branch under page > 'Pune University'. We should not have such a long url. Instead here we need > PU/ENTC or Pune-University/ENTC > > To avoid all this, what we currently do: > 1) On create page dialog, use PU as title.. This will create url as PU. > If full name is used here as title, we need to use - instead of spaces to > avoid percent characters in url. > 2) While in edit mode, change the title back to Pune University. Remove any > - characters to make title clean. > This is where confusion creeps in. > > If these two terms create confusion, why I need to show them both: > I guess the *confusion is due to term Name*. It doesn't reflect actual usage > of the term. URL or weblink or link or web address would be more apt terms > to use to instead of Name.
Regarding Page name vs Page URL.
A bit of history: The reason we used page name and not page URL originally is because what the user is creating is a document in the database and initially it was called Document Name. Since that was a bit confusing for users, we had decided to call it Page Name. It just happened that the URL used was directly derived from the document/page name.
In practice the 3 concepts could have different values: * a value for the document’s name in the DB * another value for the document’s title * yet another value used in the URL.
We’ve had discussions so that we could let the user provide shorter URLs for pages in the future.
Now for the time being and since we don’t have this ATM, I think I agree with you that we could decide to display to the user the URL that will be generated (the encoded URL) and allow the user to change it. Internally the user would change the document name.
> My users can differentiate between Title and URL. But the whole procedure we > follow is certainly not understandable by all. And we definitely need to > follow this whole long procedure, just to have short and clean urls.
Yes, if you’re asking your users to care about the URLs that get generated, right now they need to be advanced users to be able to edit the page name in the Create Page UI (since changing the title afterwards is too cumbersome).
> So, by showing both fields at the first place itself, I would like to > shorten the procedure and url length.
I’m in agreement with you. Let’s see what others think.
Thanks for this interesting discussion! -Vincent
> -- > View this message in context: http://xwiki.475771.n2.nabble. com/Page-Title-and-Name-confusion-tp7603546p7603551.html > Sent from the XWiki- Users mailing list archive at Nabble.com.
Hi Miroslav,
On 21 Apr 2017, at 15:05, Miroslav Galajda <[email protected]> wrote:
Hi, let me enter into this conversion. Some time ago I've asked for help how to solve problem with diacritics (or accents) in page names when creating new pages so that the have url-friendly names. You can search for "strip accents from page name used in url" in xwiki users mailing list. I've got no hint or solution from xwiki community till today.
I've come with solution that ensures for simple users, creating url-friendly names without requiring them to think about the concept of the page name or page title. They simple enter the desired human readably page name, and in the code behind of the page creation, I have made some modifications in createinline.vm to hook into page creation process. The modifications are mainly javascript based, where I've attache to submit event of the "form#create", where I replace the entered "title" with the one for url-friendly. And for url-friendly name I've used this javascript based solution on https://pid.github.io/speakingurl/. I've integrated this principle also into page creation process of FAQ and Blog applications, which we are using in our xwiki installation.
It would be nice if you could integrate this principle into xwiki so that everyone can have nice url-friendly urls without worring about it. It is also suitable for english speaking users. You don't have to worry about entering spaces or other non-url allowed characters, which make url look ugly.
That looks very nice! One way forward I could think about: * We provide some Create script service to return a URL-friendly string. We introduce a component role for this. We refactor createinline.vm to use it and to display the URL. * You could then contribute your code as an extension that we make available on extensions.xwiki.org for users to install * We decide later on if we want to bundle it by default If we don’t agree about displaying the URL by default all the time then an option is to introduce a UIX in createinline.vm for that. And this could be implemented in your extension too for example or by default in XWiki (possibly with an Admin setting). WDYT? Thanks -Vincent
Thank you
Best regards Miroslav Galajda
On 21 April 2017 at 14:02, Vincent Massol <[email protected]> wrote:
On 21 Apr 2017, at 13:52, Marius Dumitru Florea < [email protected]> wrote:
On Fri, Apr 21, 2017 at 2:16 PM, Vincent Massol <[email protected]> wrote:
Hi Caty,
On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) <[email protected]
wrote:
Let's see what variants we have:
1. Instead of displaying "Title", display the "Name" instead. This won't solve anything. There is no difference between Page Name and Page Title for the normal users. Seeing "Name" instead of "Title", will
not
stop the users to enter spaces if they want, so the URL will still have those spaces. We don't force the Page Names to trim spaces.
One quick solution here is indeed to use "URL" label instead of "Name". For the reasons Vincent mentioned this might not end up in the product for now,
What did I mention? :) What’s preventing us from having it in the product rather soon than later (except workload ofc)?
so you will need to do some custom development (changing some translations) to have this change. If you want to be "hackish" you can even change the translation for "Title" to "URL" instead and hope that your users will enter shorter URLs (since we generate the name from the title).
Displaying just Name / URL, means users will still have to go and change the title manually.
This could be better (with URL name) since when you create a page you’re offered the ability to change the title after you click Create.
The only way to cut a step in the flow is to autogenerate the page names (which we currently do). But for your use case you shoyld write a shorting/trimming algorithm, but this is custom, since you mentioned you want just the initials and no spaces, etc.
2. Displaying both "Title" and "Name". This will create confusion and need for explanations.
This is not exactly what is suggested either by Vishal nor by me :) What we suggested is to let the user enter the URL name and title.
Actually and to be more precise what I was suggesting was to continue to let the user enter the title but to show the generated URL as it’s done in AWM. And, importantly to allow the user to change the last part of the URL (it would change the page name).
That's why we display these options just for advanced and long-time users of XWiki, since they are used to the concepts.
Yes but URLs don't need an advanced user to understand the concept and I agree with Vishal that we’re now causing a very large number of pages to have %25 in their URLs by default which is quite bad… Of course someone can spend their time monitoring what users are doing and renaming pages thereafter or educate their users to do that but we’re not helping and we’re making it difficult.
If your web site is not in English then you're forced to use special characters like diacritics which makes it hard to avoid URL encoded characters (the browser location bar displays the URL nicely but if you copy the URL the result is not nice).
Agreed. So I’d say it’s even more important to allow the user to be able to easily view and change the resulting URL when they’re not in English.
Thanks -Vincent
-----
IMO what you are describing is advanced user behavior. Normal users
don't
generally care about their URLs and SEO.
I don’t fully agree with you. I have the feeling (can’t prove it) that a good number of our users care about the generated URLs.
Also I think that simple users may care about URL without being advanced users. Making them advanced users will expose them to a lot more complexity than they need to know.
But the beauty of XWiki is that you can customize it locally to perfectly match your needs.
That’s not exactly true (and it’s far from being easy, just check createinline.vm): It means overriding large portions of vm code and having to do manual merges whenever you upgrade. A major PITA.
Vincent mentioned something about AWM. I don't see much difference from the Create Page. We generate the names from title here too. We display them in the breadcrumb, but in a more simple way. Displaying the "localhost"/server part is not simple user behavior. AWM is more complex.
-----
So I would not change anything on the product side, since I believe these should be solved as custom changes for your instance. We want to encourage users to use page titles (with spaces in them since they are more readable and supported), while we are preserving the page name behavior for advances users (but we don't enforce it).
I don’t agree with this sentence: We definitely don’t want to encourage users to use titles in URLs.
If users made mistakes they can always change the title or rename the page. On the product side the only change I would like us to do is using the URL naming, but this was debated in the past and dropped for Vincent's reasons.
What reasons, I don’t remember a discussion about using URL name instead of page name?
So our main disagreement is that I consider that favouring encoded characters in URLs is not a good thing while you think it’s not a large enough problem to do something about it.
Would it make our UI too complex to use for simple users if we were showing a URL and the ability to change the last part of it? IMO what’s complex is when we have Page name and Page Title. But I don’t feel there’d be confusion between URL and Page title.
What do others think?
Thanks -Vincent
Thanks, Caty
On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol <[email protected]>
wrote:
> On 20 Apr 2017, at 22:51, Vincent Massol <[email protected]> wrote: > > Hi Vishal, > > Ok, I misunderstood you in your first email. I understood the
opposite.
I thought you were complaining that have 2 notions (page name + page title) was confusing but it’s actually the opposite! What you find confusing is the fact that it’s not easy for your users to set both the page name and page titles! > > It’s funny (or not :)) since this is exactly what we had in past versions of XWiki and we had several complaints that it was confusing to have the 2 notions and this is why he hid the page name only for advanced users.
Actually, if I remember well, what we were doing was to ask for the page name and we were setting the title to the same as the page name by default and then the user could edit the title before saving the page.
We’ve now done the opposite (user deciding on the title and page name being derived from it) but leading to the issue you’re raising about URL SEO…
Thanks -Vincent
> See below. > >> On 20 Apr 2017, at 14:20, Vishal <[email protected]> wrote: >> >> Thanks Vincent for your thorough reply.. >> You guessed it right. We intend to have clean and short urls for SEO >> reasons. >> Current scheme creates two problems: >> >> 1) The Page name is fetched automatically from the Title. Often the titles >> have spaces which translate as *percent characters *in url which makes it >> somewhat unclean :) > > Indeed you’re right. By hiding the page name we’re now incitating to have longer URLs and encoded characters showing up in URLs which is not nice I agree. > > Maybe one solution is to do something similar to what we do in AWM, i.e. generate automatically the URL from the title entered by the user and show the resulting URL to the user and give the user the opportunity to change the URL. > > See http://extensions.xwiki.org/xwiki/bin/download/Extension/ App%20Within%20Minutes%20Application/AppWithinMinutes-Step1.png > >> 2) Secondly, to have the shorter url, we use only the short forms of >> complete title. >> Ex. For title 'Pune University' we use name PU. > > Hey, you’re from Pune? :) I’ve been there about 15 times! That was in a previous job where my company and KPIT Cummins were partners. > >> Otherwise in this hierarchy of pages, the url would be much longer. >> Ex. We have page 'Electronics and Telecommunications' branch under page >> 'Pune University'. We should not have such a long url. Instead here we need >> PU/ENTC or Pune-University/ENTC >> >> To avoid all this, what we currently do: >> 1) On create page dialog, use PU as title.. This will create url as PU. >> If full name is used here as title, we need to use - instead of spaces to >> avoid percent characters in url. >> 2) While in edit mode, change the title back to Pune University. Remove any >> - characters to make title clean. >> This is where confusion creeps in. >> >> If these two terms create confusion, why I need to show them both: >> I guess the *confusion is due to term Name*. It doesn't reflect actual usage >> of the term. URL or weblink or link or web address would be more apt terms >> to use to instead of Name. > > Regarding Page name vs Page URL. > > A bit of history: The reason we used page name and not page URL originally is because what the user is creating is a document in the database and initially it was called Document Name. Since that was a bit confusing for users, we had decided to call it Page Name. It just happened that the URL used was directly derived from the document/page name. > > In practice the 3 concepts could have different values: > * a value for the document’s name in the DB > * another value for the document’s title > * yet another value used in the URL. > > We’ve had discussions so that we could let the user provide shorter URLs for pages in the future. > > Now for the time being and since we don’t have this ATM, I think I agree with you that we could decide to display to the user the URL that will be generated (the encoded URL) and allow the user to change it. Internally the user would change the document name. > >> My users can differentiate between Title and URL. But the whole procedure we >> follow is certainly not understandable by all. And we definitely need to >> follow this whole long procedure, just to have short and clean urls. > > Yes, if you’re asking your users to care about the URLs that get generated, right now they need to be advanced users to be able to edit the page name in the Create Page UI (since changing the title afterwards is too cumbersome). > >> So, by showing both fields at the first place itself, I would like to >> shorten the procedure and url length. > > I’m in agreement with you. Let’s see what others think. > > Thanks for this interesting discussion! > -Vincent > >> -- >> View this message in context: http://xwiki.475771.n2.nabble. com/Page-Title-and-Name-confusion-tp7603546p7603551.html >> Sent from the XWiki- Users mailing list archive at Nabble.com.
Hi, the solution I've described is javascript based and runs on client-side.
From what I know, the component-based solution, which you propose, would require to have url-friendly conversion component usable in java and not as javascript code. Am I right?
On 21 April 2017 at 15:28, Vincent Massol <[email protected]> wrote:
Hi Miroslav,
On 21 Apr 2017, at 15:05, Miroslav Galajda <[email protected]> wrote:
Hi, let me enter into this conversion. Some time ago I've asked for help how to solve problem with diacritics (or accents) in page names when creating new pages so that the have url-friendly names. You can search for "strip accents from page name used in url" in xwiki users mailing list. I've got no hint or solution from xwiki community till today.
I've come with solution that ensures for simple users, creating url-friendly names without requiring them to think about the concept of the page name or page title. They simple enter the desired human readably page name, and in the code behind of the page creation, I have made some modifications in createinline.vm to hook into page creation process. The modifications are mainly javascript based, where I've attache to submit event of the "form#create", where I replace the entered "title" with the one for url-friendly. And for url-friendly name I've used this javascript based solution on https://pid.github.io/speakingurl/. I've integrated this principle also into page creation process of FAQ and Blog applications, which we are using in our xwiki installation.
It would be nice if you could integrate this principle into xwiki so that everyone can have nice url-friendly urls without worring about it. It is also suitable for english speaking users. You don't have to worry about entering spaces or other non-url allowed characters, which make url look ugly.
That looks very nice!
One way forward I could think about: * We provide some Create script service to return a URL-friendly string. We introduce a component role for this. We refactor createinline.vm to use it and to display the URL. * You could then contribute your code as an extension that we make available on extensions.xwiki.org for users to install * We decide later on if we want to bundle it by default
If we don’t agree about displaying the URL by default all the time then an option is to introduce a UIX in createinline.vm for that. And this could be implemented in your extension too for example or by default in XWiki (possibly with an Admin setting).
WDYT?
Thanks -Vincent
Thank you
Best regards Miroslav Galajda
On 21 April 2017 at 14:02, Vincent Massol <[email protected]> wrote:
On 21 Apr 2017, at 13:52, Marius Dumitru Florea < [email protected]> wrote:
On Fri, Apr 21, 2017 at 2:16 PM, Vincent Massol <[email protected]> wrote:
Hi Caty,
On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) <
wrote:
Let's see what variants we have:
1. Instead of displaying "Title", display the "Name" instead. This won't solve anything. There is no difference between Page Name
and
Page Title for the normal users. Seeing "Name" instead of "Title", will not stop the users to enter spaces if they want, so the URL will still have those spaces. We don't force the Page Names to trim spaces.
One quick solution here is indeed to use "URL" label instead of "Name". For the reasons Vincent mentioned this might not end up in the product for now,
What did I mention? :) What’s preventing us from having it in the product rather soon than later (except workload ofc)?
so you will need to do some custom development (changing some translations) to have this change. If you want to be "hackish" you can even change the translation for "Title" to "URL" instead and hope that your users will enter shorter URLs (since we generate the name from the title).
Displaying just Name / URL, means users will still have to go and change the title manually.
This could be better (with URL name) since when you create a page you’re offered the ability to change the title after you click Create.
The only way to cut a step in the flow is to autogenerate the page names (which we currently do). But for your use case you shoyld write a shorting/trimming algorithm, but this is custom, since you mentioned you want just the initials and no spaces, etc.
2. Displaying both "Title" and "Name". This will create confusion and need for explanations.
This is not exactly what is suggested either by Vishal nor by me :) What we suggested is to let the user enter the URL name and title.
Actually and to be more precise what I was suggesting was to continue to let the user enter the title but to show the generated URL as it’s done in AWM. And, importantly to allow the user to change the last part of the URL (it would change the page name).
That's why we display these options just for advanced and long-time users of XWiki, since they are used to the concepts.
Yes but URLs don't need an advanced user to understand the concept and I agree with Vishal that we’re now causing a very large number of pages to have %25 in their URLs by default which is quite bad… Of course someone can spend their time monitoring what users are doing and renaming pages thereafter or educate their users to do that but we’re not helping and we’re making it difficult.
If your web site is not in English then you're forced to use special characters like diacritics which makes it hard to avoid URL encoded characters (the browser location bar displays the URL nicely but if you copy the URL the result is not nice).
Agreed. So I’d say it’s even more important to allow the user to be able to easily view and change the resulting URL when they’re not in English.
Thanks -Vincent
-----
IMO what you are describing is advanced user behavior. Normal users
don't
generally care about their URLs and SEO.
I don’t fully agree with you. I have the feeling (can’t prove it) that a good number of our users care about the generated URLs.
Also I think that simple users may care about URL without being advanced users. Making them advanced users will expose them to a lot more complexity than they need to know.
But the beauty of XWiki is that you can customize it locally to perfectly match your needs.
That’s not exactly true (and it’s far from being easy, just check createinline.vm): It means overriding large portions of vm code and having to do manual merges whenever you upgrade. A major PITA.
Vincent mentioned something about AWM. I don't see much difference from the Create Page. We generate the names from title here too. We display them in the breadcrumb, but in a more simple way. Displaying the "localhost"/server part is not simple user behavior. AWM is more complex.
-----
So I would not change anything on the product side, since I believe these should be solved as custom changes for your instance. We want to encourage users to use page titles (with spaces in them since they are more readable and supported), while we are preserving the page name behavior for advances users (but we don't enforce it).
I don’t agree with this sentence: We definitely don’t want to encourage users to use titles in URLs.
If users made mistakes they can always change the title or rename the page. On the product side the only change I would like us to do is using the URL naming, but this was debated in the past and dropped for Vincent's reasons.
What reasons, I don’t remember a discussion about using URL name instead of page name?
So our main disagreement is that I consider that favouring encoded characters in URLs is not a good thing while you think it’s not a large enough problem to do something about it.
Would it make our UI too complex to use for simple users if we were showing a URL and the ability to change the last part of it? IMO what’s complex is when we have Page name and Page Title. But I don’t feel there’d be confusion between URL and Page title.
What do others think?
Thanks -Vincent
Thanks, Caty
On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol <[email protected]
wrote:
> >> On 20 Apr 2017, at 22:51, Vincent Massol <[email protected]>
wrote:
>> >> Hi Vishal, >> >> Ok, I misunderstood you in your first email. I understood the opposite. > I thought you were complaining that have 2 notions (page name + page title) > was confusing but it’s actually the opposite! What you find confusing is > the fact that it’s not easy for your users to set both the page name and > page titles! >> >> It’s funny (or not :)) since this is exactly what we had in past > versions of XWiki and we had several complaints that it was confusing to > have the 2 notions and this is why he hid the page name only for advanced > users. > > Actually, if I remember well, what we were doing was to ask for the page > name and we were setting the title to the same as the page name by default > and then the user could edit the title before saving the page. > > We’ve now done the opposite (user deciding on the title and page name > being derived from it) but leading to the issue you’re raising about URL > SEO… > > Thanks > -Vincent > >> See below. >> >>> On 20 Apr 2017, at 14:20, Vishal <[email protected]> wrote: >>> >>> Thanks Vincent for your thorough reply.. >>> You guessed it right. We intend to have clean and short urls for SEO >>> reasons. >>> Current scheme creates two problems: >>> >>> 1) The Page name is fetched automatically from the Title. Often the > titles >>> have spaces which translate as *percent characters *in url which makes > it >>> somewhat unclean :) >> >> Indeed you’re right. By hiding the page name we’re now incitating to > have longer URLs and encoded characters showing up in URLs which is not > nice I agree. >> >> Maybe one solution is to do something similar to what we do in AWM, i.e. > generate automatically the URL from the title entered by the user and show > the resulting URL to the user and give the user the opportunity to change > the URL. >> >> See http://extensions.xwiki.org/xwiki/bin/download/Extension/ > App%20Within%20Minutes%20Application/AppWithinMinutes-Step1.png >> >>> 2) Secondly, to have the shorter url, we use only the short forms of >>> complete title. >>> Ex. For title 'Pune University' we use name PU. >> >> Hey, you’re from Pune? :) I’ve been there about 15 times! That was in a > previous job where my company and KPIT Cummins were partners. >> >>> Otherwise in this hierarchy of pages, the url would be much longer. >>> Ex. We have page 'Electronics and Telecommunications' branch under page >>> 'Pune University'. We should not have such a long url. Instead here we > need >>> PU/ENTC or Pune-University/ENTC >>> >>> To avoid all this, what we currently do: >>> 1) On create page dialog, use PU as title.. This will create url as PU. >>> If full name is used here as title, we need to use - instead of spaces > to >>> avoid percent characters in url. >>> 2) While in edit mode, change the title back to Pune University. Remove > any >>> - characters to make title clean. >>> This is where confusion creeps in. >>> >>> If these two terms create confusion, why I need to show them both: >>> I guess the *confusion is due to term Name*. It doesn't reflect actual > usage >>> of the term. URL or weblink or link or web address would be more apt > terms >>> to use to instead of Name. >> >> Regarding Page name vs Page URL. >> >> A bit of history: The reason we used page name and not page URL > originally is because what the user is creating is a document in the > database and initially it was called Document Name. Since that was a bit > confusing for users, we had decided to call it Page Name. It just happened > that the URL used was directly derived from the document/page name. >> >> In practice the 3 concepts could have different values: >> * a value for the document’s name in the DB >> * another value for the document’s title >> * yet another value used in the URL. >> >> We’ve had discussions so that we could let the user provide shorter URLs > for pages in the future. >> >> Now for the time being and since we don’t have this ATM, I think I agree > with you that we could decide to display to the user the URL that will be > generated (the encoded URL) and allow the user to change it. Internally the > user would change the document name. >> >>> My users can differentiate between Title and URL. But the whole > procedure we >>> follow is certainly not understandable by all. And we definitely need to >>> follow this whole long procedure, just to have short and clean urls. >> >> Yes, if you’re asking your users to care about the URLs that get > generated, right now they need to be advanced users to be able to edit the > page name in the Create Page UI (since changing the title afterwards is too > cumbersome). >> >>> So, by showing both fields at the first place itself, I would like to >>> shorten the procedure and url length. >> >> I’m in agreement with you. Let’s see what others think. >> >> Thanks for this interesting discussion! >> -Vincent >> >>> -- >>> View this message in context: http://xwiki.475771.n2.nabble. > com/Page-Title-and-Name-confusion-tp7603546p7603551.html >>> Sent from the XWiki- Users mailing list archive at Nabble.com.
On 21 Apr 2017, at 15:36, Miroslav Galajda <[email protected]> wrote:
Hi, the solution I've described is javascript based and runs on client-side. From what I know, the component-based solution, which you propose, would require to have url-friendly conversion component usable in java and not as javascript code. Am I right?
Yes you’re right but: 1) There’s also a Java API, see https://github.com/slugify/slugify 2) If we also offer a UIX then it can be implemented in a wiki page for example and you can use JS. Thanks -Vincent
On 21 April 2017 at 15:28, Vincent Massol <[email protected]> wrote:
Hi Miroslav,
On 21 Apr 2017, at 15:05, Miroslav Galajda <[email protected]> wrote:
Hi, let me enter into this conversion. Some time ago I've asked for help how to solve problem with diacritics (or accents) in page names when creating new pages so that the have url-friendly names. You can search for "strip accents from page name used in url" in xwiki users mailing list. I've got no hint or solution from xwiki community till today.
I've come with solution that ensures for simple users, creating url-friendly names without requiring them to think about the concept of the page name or page title. They simple enter the desired human readably page name, and in the code behind of the page creation, I have made some modifications in createinline.vm to hook into page creation process. The modifications are mainly javascript based, where I've attache to submit event of the "form#create", where I replace the entered "title" with the one for url-friendly. And for url-friendly name I've used this javascript based solution on https://pid.github.io/speakingurl/. I've integrated this principle also into page creation process of FAQ and Blog applications, which we are using in our xwiki installation.
It would be nice if you could integrate this principle into xwiki so that everyone can have nice url-friendly urls without worring about it. It is also suitable for english speaking users. You don't have to worry about entering spaces or other non-url allowed characters, which make url look ugly.
That looks very nice!
One way forward I could think about: * We provide some Create script service to return a URL-friendly string. We introduce a component role for this. We refactor createinline.vm to use it and to display the URL. * You could then contribute your code as an extension that we make available on extensions.xwiki.org for users to install * We decide later on if we want to bundle it by default
If we don’t agree about displaying the URL by default all the time then an option is to introduce a UIX in createinline.vm for that. And this could be implemented in your extension too for example or by default in XWiki (possibly with an Admin setting).
WDYT?
Thanks -Vincent
Thank you
Best regards Miroslav Galajda
On 21 April 2017 at 14:02, Vincent Massol <[email protected]> wrote:
On 21 Apr 2017, at 13:52, Marius Dumitru Florea < [email protected]> wrote:
On Fri, Apr 21, 2017 at 2:16 PM, Vincent Massol <[email protected]> wrote:
Hi Caty,
> On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) <
wrote: > > Let's see what variants we have: > > 1. Instead of displaying "Title", display the "Name" instead. > This won't solve anything. There is no difference between Page Name
and
> Page Title for the normal users. Seeing "Name" instead of "Title", will not > stop the users to enter spaces if they want, so the URL will still have > those spaces. We don't force the Page Names to trim spaces. > > One quick solution here is indeed to use "URL" label instead of "Name". For > the reasons Vincent mentioned this might not end up in the product for now,
What did I mention? :) What’s preventing us from having it in the product rather soon than later (except workload ofc)?
> so you will need to do some custom development (changing some translations) > to have this change. If you want to be "hackish" you can even change the > translation for "Title" to "URL" instead and hope that your users will > enter shorter URLs (since we generate the name from the title). > > Displaying just Name / URL, means users will still have to go and change > the title manually.
This could be better (with URL name) since when you create a page you’re offered the ability to change the title after you click Create.
> The only way to cut a step in the flow is to > autogenerate the page names (which we currently do). But for your use case > you shoyld write a shorting/trimming algorithm, but this is custom, since > you mentioned you want just the initials and no spaces, etc. > > 2. Displaying both "Title" and "Name". This will create confusion and need > for explanations.
This is not exactly what is suggested either by Vishal nor by me :) What we suggested is to let the user enter the URL name and title.
Actually and to be more precise what I was suggesting was to continue to let the user enter the title but to show the generated URL as it’s done in AWM. And, importantly to allow the user to change the last part of the URL (it would change the page name).
> That's why we display these options just for advanced and > long-time users of XWiki, since they are used to the concepts.
Yes but URLs don't need an advanced user to understand the concept and I agree with Vishal that we’re now causing a very large number of pages to have %25 in their URLs by default which is quite bad… Of course someone can spend their time monitoring what users are doing and renaming pages thereafter or educate their users to do that but we’re not helping and we’re making it difficult.
If your web site is not in English then you're forced to use special characters like diacritics which makes it hard to avoid URL encoded characters (the browser location bar displays the URL nicely but if you copy the URL the result is not nice).
Agreed. So I’d say it’s even more important to allow the user to be able to easily view and change the resulting URL when they’re not in English.
Thanks -Vincent
> ----- > > IMO what you are describing is advanced user behavior. Normal users
don't
> generally care about their URLs and SEO.
I don’t fully agree with you. I have the feeling (can’t prove it) that a good number of our users care about the generated URLs.
Also I think that simple users may care about URL without being advanced users. Making them advanced users will expose them to a lot more complexity than they need to know.
> But the beauty of XWiki is that > you can customize it locally to perfectly match your needs.
That’s not exactly true (and it’s far from being easy, just check createinline.vm): It means overriding large portions of vm code and having to do manual merges whenever you upgrade. A major PITA.
> Vincent mentioned something about AWM. I don't see much difference from the > Create Page. We generate the names from title here too. We display them in > the breadcrumb, but in a more simple way. Displaying the "localhost"/server > part is not simple user behavior. AWM is more complex. > > ----- > > So I would not change anything on the product side, since I believe these > should be solved as custom changes for your instance. > We want to encourage users to use page titles (with spaces in them since > they are more readable and supported), while we are preserving the page > name behavior for advances users (but we don't enforce it).
I don’t agree with this sentence: We definitely don’t want to encourage users to use titles in URLs.
> If users made > mistakes they can always change the title or rename the page. > On the product side the only change I would like us to do is using the URL > naming, but this was debated in the past and dropped for Vincent's reasons.
What reasons, I don’t remember a discussion about using URL name instead of page name?
So our main disagreement is that I consider that favouring encoded characters in URLs is not a good thing while you think it’s not a large enough problem to do something about it.
Would it make our UI too complex to use for simple users if we were showing a URL and the ability to change the last part of it? IMO what’s complex is when we have Page name and Page Title. But I don’t feel there’d be confusion between URL and Page title.
What do others think?
Thanks -Vincent
> > Thanks, > Caty > > > On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol <[email protected]
wrote: > >> >>> On 20 Apr 2017, at 22:51, Vincent Massol <[email protected]> wrote: >>> >>> Hi Vishal, >>> >>> Ok, I misunderstood you in your first email. I understood the opposite. >> I thought you were complaining that have 2 notions (page name + page title) >> was confusing but it’s actually the opposite! What you find confusing is >> the fact that it’s not easy for your users to set both the page name and >> page titles! >>> >>> It’s funny (or not :)) since this is exactly what we had in past >> versions of XWiki and we had several complaints that it was confusing to >> have the 2 notions and this is why he hid the page name only for advanced >> users. >> >> Actually, if I remember well, what we were doing was to ask for the page >> name and we were setting the title to the same as the page name by default >> and then the user could edit the title before saving the page. >> >> We’ve now done the opposite (user deciding on the title and page name >> being derived from it) but leading to the issue you’re raising about URL >> SEO… >> >> Thanks >> -Vincent >> >>> See below. >>> >>>> On 20 Apr 2017, at 14:20, Vishal <[email protected]> wrote: >>>> >>>> Thanks Vincent for your thorough reply.. >>>> You guessed it right. We intend to have clean and short urls for SEO >>>> reasons. >>>> Current scheme creates two problems: >>>> >>>> 1) The Page name is fetched automatically from the Title. Often the >> titles >>>> have spaces which translate as *percent characters *in url which makes >> it >>>> somewhat unclean :) >>> >>> Indeed you’re right. By hiding the page name we’re now incitating to >> have longer URLs and encoded characters showing up in URLs which is not >> nice I agree. >>> >>> Maybe one solution is to do something similar to what we do in AWM, i.e. >> generate automatically the URL from the title entered by the user and show >> the resulting URL to the user and give the user the opportunity to change >> the URL. >>> >>> See http://extensions.xwiki.org/xwiki/bin/download/Extension/ >> App%20Within%20Minutes%20Application/AppWithinMinutes-Step1.png >>> >>>> 2) Secondly, to have the shorter url, we use only the short forms of >>>> complete title. >>>> Ex. For title 'Pune University' we use name PU. >>> >>> Hey, you’re from Pune? :) I’ve been there about 15 times! That was in a >> previous job where my company and KPIT Cummins were partners. >>> >>>> Otherwise in this hierarchy of pages, the url would be much longer. >>>> Ex. We have page 'Electronics and Telecommunications' branch under page >>>> 'Pune University'. We should not have such a long url. Instead here we >> need >>>> PU/ENTC or Pune-University/ENTC >>>> >>>> To avoid all this, what we currently do: >>>> 1) On create page dialog, use PU as title.. This will create url as PU. >>>> If full name is used here as title, we need to use - instead of spaces >> to >>>> avoid percent characters in url. >>>> 2) While in edit mode, change the title back to Pune University. Remove >> any >>>> - characters to make title clean. >>>> This is where confusion creeps in. >>>> >>>> If these two terms create confusion, why I need to show them both: >>>> I guess the *confusion is due to term Name*. It doesn't reflect actual >> usage >>>> of the term. URL or weblink or link or web address would be more apt >> terms >>>> to use to instead of Name. >>> >>> Regarding Page name vs Page URL. >>> >>> A bit of history: The reason we used page name and not page URL >> originally is because what the user is creating is a document in the >> database and initially it was called Document Name. Since that was a bit >> confusing for users, we had decided to call it Page Name. It just happened >> that the URL used was directly derived from the document/page name. >>> >>> In practice the 3 concepts could have different values: >>> * a value for the document’s name in the DB >>> * another value for the document’s title >>> * yet another value used in the URL. >>> >>> We’ve had discussions so that we could let the user provide shorter URLs >> for pages in the future. >>> >>> Now for the time being and since we don’t have this ATM, I think I agree >> with you that we could decide to display to the user the URL that will be >> generated (the encoded URL) and allow the user to change it. Internally the >> user would change the document name. >>> >>>> My users can differentiate between Title and URL. But the whole >> procedure we >>>> follow is certainly not understandable by all. And we definitely need to >>>> follow this whole long procedure, just to have short and clean urls. >>> >>> Yes, if you’re asking your users to care about the URLs that get >> generated, right now they need to be advanced users to be able to edit the >> page name in the Create Page UI (since changing the title afterwards is too >> cumbersome). >>> >>>> So, by showing both fields at the first place itself, I would like to >>>> shorten the procedure and url length. >>> >>> I’m in agreement with you. Let’s see what others think. >>> >>> Thanks for this interesting discussion! >>> -Vincent >>> >>>> -- >>>> View this message in context: http://xwiki.475771.n2.nabble. >> com/Page-Title-and-Name-confusion-tp7603546p7603551.html >>>> Sent from the XWiki- Users mailing list archive at Nabble.com.
Jumping abord conversation, the URL friendly links part looks promising ! Users in my company tend to add a lot of special characters in their pages, and having an option to strip those would really be useful for us. I'm afraid I've not read the rest of the conversation so I won't bother you further ;-) Regards Denis GERMAIN 2017-04-21 16:00 GMT+02:00 Vincent Massol <[email protected]>:
On 21 Apr 2017, at 15:36, Miroslav Galajda <[email protected]> wrote:
Hi, the solution I've described is javascript based and runs on client-side. From what I know, the component-based solution, which you propose, would require to have url-friendly conversion component usable in java and not as javascript code. Am I right?
Yes you’re right but:
1) There’s also a Java API, see https://github.com/slugify/slugify 2) If we also offer a UIX then it can be implemented in a wiki page for example and you can use JS.
Thanks -Vincent
On 21 April 2017 at 15:28, Vincent Massol <[email protected]> wrote:
Hi Miroslav,
On 21 Apr 2017, at 15:05, Miroslav Galajda <[email protected]
wrote:
Hi, let me enter into this conversion. Some time ago I've asked for help how to solve problem with diacritics
(or
accents) in page names when creating new pages so that the have url-friendly names. You can search for "strip accents from page name used in url" in xwiki users mailing list. I've got no hint or solution from xwiki community till today.
I've come with solution that ensures for simple users, creating url-friendly names without requiring them to think about the concept of the page name or page title. They simple enter the desired human readably page name, and in the code behind of the page creation, I have made some modifications in createinline.vm to hook into page creation process. The modifications are mainly javascript based, where I've attache to submit event of the "form#create", where I replace the entered "title" with the one for url-friendly. And for url-friendly name I've used this javascript based solution on https://pid.github.io/speakingurl/. I've integrated this principle also into page creation process of FAQ and Blog applications, which we are using in our xwiki installation.
It would be nice if you could integrate this principle into xwiki so that everyone can have nice url-friendly urls without worring about it. It is also suitable for english speaking users. You don't have to worry about entering spaces or other non-url allowed characters, which make url look ugly.
That looks very nice!
One way forward I could think about: * We provide some Create script service to return a URL-friendly string. We introduce a component role for this. We refactor createinline.vm to use it and to display the URL. * You could then contribute your code as an extension that we make available on extensions.xwiki.org for users to install * We decide later on if we want to bundle it by default
If we don’t agree about displaying the URL by default all the time then an option is to introduce a UIX in createinline.vm for that. And this could be implemented in your extension too for example or by default in XWiki (possibly with an Admin setting).
WDYT?
Thanks -Vincent
Thank you
Best regards Miroslav Galajda
On 21 April 2017 at 14:02, Vincent Massol <[email protected]> wrote:
On 21 Apr 2017, at 13:52, Marius Dumitru Florea < [email protected]> wrote:
On Fri, Apr 21, 2017 at 2:16 PM, Vincent Massol <[email protected]> wrote:
> Hi Caty, > >> On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) <
> wrote: >> >> Let's see what variants we have: >> >> 1. Instead of displaying "Title", display the "Name" instead. >> This won't solve anything. There is no difference between Page Name
and
>> Page Title for the normal users. Seeing "Name" instead of "Title", will > not >> stop the users to enter spaces if they want, so the URL will still have >> those spaces. We don't force the Page Names to trim spaces. >> >> One quick solution here is indeed to use "URL" label instead of "Name". > For >> the reasons Vincent mentioned this might not end up in the product for > now, > > What did I mention? :) What’s preventing us from having it in the product > rather soon than later (except workload ofc)? > >> so you will need to do some custom development (changing some > translations) >> to have this change. If you want to be "hackish" you can even change the >> translation for "Title" to "URL" instead and hope that your users will >> enter shorter URLs (since we generate the name from the title). >> >> Displaying just Name / URL, means users will still have to go and change >> the title manually. > > This could be better (with URL name) since when you create a page you’re > offered the ability to change the title after you click Create. > >> The only way to cut a step in the flow is to >> autogenerate the page names (which we currently do). But for your use > case >> you shoyld write a shorting/trimming algorithm, but this is custom, since >> you mentioned you want just the initials and no spaces, etc. >> >> 2. Displaying both "Title" and "Name". This will create confusion and > need >> for explanations. > > This is not exactly what is suggested either by Vishal nor by me :) What > we suggested is to let the user enter the URL name and title. > > Actually and to be more precise what I was suggesting was to continue to > let the user enter the title but to show the generated URL as it’s done in > AWM. And, importantly to allow the user to change the last part of the URL > (it would change the page name). > >> That's why we display these options just for advanced and >> long-time users of XWiki, since they are used to the concepts. > >
> Yes but URLs don't need an advanced user to understand the concept and I > agree with Vishal that we’re now causing a very large number of pages to > have %25 in their URLs by default which is quite bad… Of course someone can > spend their time monitoring what users are doing and renaming pages > thereafter or educate their users to do that but we’re not helping and > we’re making it difficult. >
If your web site is not in English then you're forced to use special characters like diacritics which makes it hard to avoid URL encoded characters (the browser location bar displays the URL nicely but if you copy the URL the result is not nice).
Agreed. So I’d say it’s even more important to allow the user to be able to easily view and change the resulting URL when they’re not in English.
Thanks -Vincent
> >> ----- >> >> IMO what you are describing is advanced user behavior. Normal users
don't
>> generally care about their URLs and SEO. > > I don’t fully agree with you. I have the feeling (can’t prove it) that a > good number of our users care about the generated URLs. >
> Also I think that simple users may care about URL without being advanced > users. Making them advanced users will expose them to a lot more complexity > than they need to know. > >> But the beauty of XWiki is that >> you can customize it locally to perfectly match your needs. > > That’s not exactly true (and it’s far from being easy, just check > createinline.vm): It means overriding large portions of vm code and having > to do manual merges whenever you upgrade. A major PITA. > >> Vincent mentioned something about AWM. I don't see much difference from > the >> Create Page. We generate the names from title here too. We display them > in >> the breadcrumb, but in a more simple way. Displaying the > "localhost"/server >> part is not simple user behavior. AWM is more complex. >> >> ----- >> >> So I would not change anything on the product side, since I believe these >> should be solved as custom changes for your instance. >> We want to encourage users to use page titles (with spaces in them since >> they are more readable and supported), while we are preserving the page >> name behavior for advances users (but we don't enforce it). > > I don’t agree with this sentence: We definitely don’t want to encourage > users to use titles in URLs. > >> If users made >> mistakes they can always change the title or rename the page. >> On the product side the only change I would like us to do is using the > URL >> naming, but this was debated in the past and dropped for Vincent's > reasons. > > What reasons, I don’t remember a discussion about using URL name instead > of page name? > > So our main disagreement is that I consider that favouring encoded > characters in URLs is not a good thing while you think it’s not a large > enough problem to do something about it. > > Would it make our UI too complex to use for simple users if we were > showing a URL and the ability to change the last part of it? IMO what’s > complex is when we have Page name and Page Title. But I don’t feel there’d > be confusion between URL and Page title. > > What do others think? > > Thanks > -Vincent > >> >> Thanks, >> Caty >> >> >> On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol < [email protected]
> wrote: >> >>> >>>> On 20 Apr 2017, at 22:51, Vincent Massol <[email protected]> wrote: >>>> >>>> Hi Vishal, >>>> >>>> Ok, I misunderstood you in your first email. I understood the opposite. >>> I thought you were complaining that have 2 notions (page name + page > title) >>> was confusing but it’s actually the opposite! What you find confusing is >>> the fact that it’s not easy for your users to set both the page name and >>> page titles! >>>> >>>> It’s funny (or not :)) since this is exactly what we had in past >>> versions of XWiki and we had several complaints that it was confusing to >>> have the 2 notions and this is why he hid the page name only for > advanced >>> users. >>> >>> Actually, if I remember well, what we were doing was to ask for the page >>> name and we were setting the title to the same as the page name by > default >>> and then the user could edit the title before saving the page. >>> >>> We’ve now done the opposite (user deciding on the title and page name >>> being derived from it) but leading to the issue you’re raising about URL >>> SEO… >>> >>> Thanks >>> -Vincent >>> >>>> See below. >>>> >>>>> On 20 Apr 2017, at 14:20, Vishal <[email protected]> wrote: >>>>> >>>>> Thanks Vincent for your thorough reply.. >>>>> You guessed it right. We intend to have clean and short urls for SEO >>>>> reasons. >>>>> Current scheme creates two problems: >>>>> >>>>> 1) The Page name is fetched automatically from the Title. Often the >>> titles >>>>> have spaces which translate as *percent characters *in url which makes >>> it >>>>> somewhat unclean :) >>>> >>>> Indeed you’re right. By hiding the page name we’re now incitating to >>> have longer URLs and encoded characters showing up in URLs which is not >>> nice I agree. >>>> >>>> Maybe one solution is to do something similar to what we do in AWM, > i.e. >>> generate automatically the URL from the title entered by the user and > show >>> the resulting URL to the user and give the user the opportunity to > change >>> the URL. >>>> >>>> See http://extensions.xwiki.org/xwiki/bin/download/Extension/ >>> App%20Within%20Minutes%20Application/AppWithinMinutes-Step1.png >>>> >>>>> 2) Secondly, to have the shorter url, we use only the short forms of >>>>> complete title. >>>>> Ex. For title 'Pune University' we use name PU. >>>> >>>> Hey, you’re from Pune? :) I’ve been there about 15 times! That was in a >>> previous job where my company and KPIT Cummins were partners. >>>> >>>>> Otherwise in this hierarchy of pages, the url would be much longer. >>>>> Ex. We have page 'Electronics and Telecommunications' branch under > page >>>>> 'Pune University'. We should not have such a long url. Instead here we >>> need >>>>> PU/ENTC or Pune-University/ENTC >>>>> >>>>> To avoid all this, what we currently do: >>>>> 1) On create page dialog, use PU as title.. This will create url as > PU. >>>>> If full name is used here as title, we need to use - instead of spaces >>> to >>>>> avoid percent characters in url. >>>>> 2) While in edit mode, change the title back to Pune University. > Remove >>> any >>>>> - characters to make title clean. >>>>> This is where confusion creeps in. >>>>> >>>>> If these two terms create confusion, why I need to show them both: >>>>> I guess the *confusion is due to term Name*. It doesn't reflect actual >>> usage >>>>> of the term. URL or weblink or link or web address would be more apt >>> terms >>>>> to use to instead of Name. >>>> >>>> Regarding Page name vs Page URL. >>>> >>>> A bit of history: The reason we used page name and not page URL >>> originally is because what the user is creating is a document in the >>> database and initially it was called Document Name. Since that was a bit >>> confusing for users, we had decided to call it Page Name. It just > happened >>> that the URL used was directly derived from the document/page name. >>>> >>>> In practice the 3 concepts could have different values: >>>> * a value for the document’s name in the DB >>>> * another value for the document’s title >>>> * yet another value used in the URL. >>>> >>>> We’ve had discussions so that we could let the user provide shorter > URLs >>> for pages in the future. >>>> >>>> Now for the time being and since we don’t have this ATM, I think I > agree >>> with you that we could decide to display to the user the URL that will > be >>> generated (the encoded URL) and allow the user to change it. Internally > the >>> user would change the document name. >>>> >>>>> My users can differentiate between Title and URL. But the whole >>> procedure we >>>>> follow is certainly not understandable by all. And we definitely need > to >>>>> follow this whole long procedure, just to have short and clean urls. >>>> >>>> Yes, if you’re asking your users to care about the URLs that get >>> generated, right now they need to be advanced users to be able to edit > the >>> page name in the Create Page UI (since changing the title afterwards is > too >>> cumbersome). >>>> >>>>> So, by showing both fields at the first place itself, I would like to >>>>> shorten the procedure and url length. >>>> >>>> I’m in agreement with you. Let’s see what others think. >>>> >>>> Thanks for this interesting discussion! >>>> -Vincent >>>> >>>>> -- >>>>> View this message in context: http://xwiki.475771.n2.nabble. >>> com/Page-Title-and-Name-confusion-tp7603546p7603551.html >>>>> Sent from the XWiki- Users mailing list archive at Nabble.com.
Hi, the slugify is different component than speakingurl, but currently it doesn't matter on this. Ok, how would we solve this globally? Not only in default page creation process but also in custom applications, that create pages in their own. For example the FAQ uses this code to redirect to new FAQ page after entering question name: #set ($newFAQReference = $services.model.createDocumentReference('', '', "$question")) $response.sendRedirect($xwiki.getURL($newFAQReference, 'inline', "$!{request.queryString}&title=${escapetool.url($question)}")) The solution you propose will be transparent for this code or will it require som modifications? On 21 April 2017 at 16:00, Vincent Massol <[email protected]> wrote:
On 21 Apr 2017, at 15:36, Miroslav Galajda <[email protected]> wrote:
Hi, the solution I've described is javascript based and runs on client-side. From what I know, the component-based solution, which you propose, would require to have url-friendly conversion component usable in java and not as javascript code. Am I right?
Yes you’re right but:
1) There’s also a Java API, see https://github.com/slugify/slugify 2) If we also offer a UIX then it can be implemented in a wiki page for example and you can use JS.
Thanks -Vincent
On 21 April 2017 at 15:28, Vincent Massol <[email protected]> wrote:
Hi Miroslav,
On 21 Apr 2017, at 15:05, Miroslav Galajda <[email protected]
wrote:
Hi, let me enter into this conversion. Some time ago I've asked for help how to solve problem with diacritics
(or
accents) in page names when creating new pages so that the have url-friendly names. You can search for "strip accents from page name used in url" in xwiki users mailing list. I've got no hint or solution from xwiki community till today.
I've come with solution that ensures for simple users, creating url-friendly names without requiring them to think about the concept of the page name or page title. They simple enter the desired human readably page name, and in the code behind of the page creation, I have made some modifications in createinline.vm to hook into page creation process. The modifications are mainly javascript based, where I've attache to submit event of the "form#create", where I replace the entered "title" with the one for url-friendly. And for url-friendly name I've used this javascript based solution on https://pid.github.io/speakingurl/. I've integrated this principle also into page creation process of FAQ and Blog applications, which we are using in our xwiki installation.
It would be nice if you could integrate this principle into xwiki so that everyone can have nice url-friendly urls without worring about it. It is also suitable for english speaking users. You don't have to worry about entering spaces or other non-url allowed characters, which make url look ugly.
That looks very nice!
One way forward I could think about: * We provide some Create script service to return a URL-friendly string. We introduce a component role for this. We refactor createinline.vm to use it and to display the URL. * You could then contribute your code as an extension that we make available on extensions.xwiki.org for users to install * We decide later on if we want to bundle it by default
If we don’t agree about displaying the URL by default all the time then an option is to introduce a UIX in createinline.vm for that. And this could be implemented in your extension too for example or by default in XWiki (possibly with an Admin setting).
WDYT?
Thanks -Vincent
Thank you
Best regards Miroslav Galajda
On 21 April 2017 at 14:02, Vincent Massol <[email protected]> wrote:
On 21 Apr 2017, at 13:52, Marius Dumitru Florea < [email protected]> wrote:
On Fri, Apr 21, 2017 at 2:16 PM, Vincent Massol <[email protected]> wrote:
> Hi Caty, > >> On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) <
> wrote: >> >> Let's see what variants we have: >> >> 1. Instead of displaying "Title", display the "Name" instead. >> This won't solve anything. There is no difference between Page Name
and
>> Page Title for the normal users. Seeing "Name" instead of "Title", will > not >> stop the users to enter spaces if they want, so the URL will still have >> those spaces. We don't force the Page Names to trim spaces. >> >> One quick solution here is indeed to use "URL" label instead of "Name". > For >> the reasons Vincent mentioned this might not end up in the product for > now, > > What did I mention? :) What’s preventing us from having it in the product > rather soon than later (except workload ofc)? > >> so you will need to do some custom development (changing some > translations) >> to have this change. If you want to be "hackish" you can even change the >> translation for "Title" to "URL" instead and hope that your users will >> enter shorter URLs (since we generate the name from the title). >> >> Displaying just Name / URL, means users will still have to go and change >> the title manually. > > This could be better (with URL name) since when you create a page you’re > offered the ability to change the title after you click Create. > >> The only way to cut a step in the flow is to >> autogenerate the page names (which we currently do). But for your use > case >> you shoyld write a shorting/trimming algorithm, but this is custom, since >> you mentioned you want just the initials and no spaces, etc. >> >> 2. Displaying both "Title" and "Name". This will create confusion and > need >> for explanations. > > This is not exactly what is suggested either by Vishal nor by me :) What > we suggested is to let the user enter the URL name and title. > > Actually and to be more precise what I was suggesting was to continue to > let the user enter the title but to show the generated URL as it’s done in > AWM. And, importantly to allow the user to change the last part of the URL > (it would change the page name). > >> That's why we display these options just for advanced and >> long-time users of XWiki, since they are used to the concepts. > >
> Yes but URLs don't need an advanced user to understand the concept and I > agree with Vishal that we’re now causing a very large number of pages to > have %25 in their URLs by default which is quite bad… Of course someone can > spend their time monitoring what users are doing and renaming pages > thereafter or educate their users to do that but we’re not helping and > we’re making it difficult. >
If your web site is not in English then you're forced to use special characters like diacritics which makes it hard to avoid URL encoded characters (the browser location bar displays the URL nicely but if you copy the URL the result is not nice).
Agreed. So I’d say it’s even more important to allow the user to be able to easily view and change the resulting URL when they’re not in English.
Thanks -Vincent
> >> ----- >> >> IMO what you are describing is advanced user behavior. Normal users
don't
>> generally care about their URLs and SEO. > > I don’t fully agree with you. I have the feeling (can’t prove it) that a > good number of our users care about the generated URLs. >
> Also I think that simple users may care about URL without being advanced > users. Making them advanced users will expose them to a lot more complexity > than they need to know. > >> But the beauty of XWiki is that >> you can customize it locally to perfectly match your needs. > > That’s not exactly true (and it’s far from being easy, just check > createinline.vm): It means overriding large portions of vm code and having > to do manual merges whenever you upgrade. A major PITA. > >> Vincent mentioned something about AWM. I don't see much difference from > the >> Create Page. We generate the names from title here too. We display them > in >> the breadcrumb, but in a more simple way. Displaying the > "localhost"/server >> part is not simple user behavior. AWM is more complex. >> >> ----- >> >> So I would not change anything on the product side, since I believe these >> should be solved as custom changes for your instance. >> We want to encourage users to use page titles (with spaces in them since >> they are more readable and supported), while we are preserving the page >> name behavior for advances users (but we don't enforce it). > > I don’t agree with this sentence: We definitely don’t want to encourage > users to use titles in URLs. > >> If users made >> mistakes they can always change the title or rename the page. >> On the product side the only change I would like us to do is using the > URL >> naming, but this was debated in the past and dropped for Vincent's > reasons. > > What reasons, I don’t remember a discussion about using URL name instead > of page name? > > So our main disagreement is that I consider that favouring encoded > characters in URLs is not a good thing while you think it’s not a large > enough problem to do something about it. > > Would it make our UI too complex to use for simple users if we were > showing a URL and the ability to change the last part of it? IMO what’s > complex is when we have Page name and Page Title. But I don’t feel there’d > be confusion between URL and Page title. > > What do others think? > > Thanks > -Vincent > >> >> Thanks, >> Caty >> >> >> On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol < [email protected]
> wrote: >> >>> >>>> On 20 Apr 2017, at 22:51, Vincent Massol <[email protected]> wrote: >>>> >>>> Hi Vishal, >>>> >>>> Ok, I misunderstood you in your first email. I understood the opposite. >>> I thought you were complaining that have 2 notions (page name + page > title) >>> was confusing but it’s actually the opposite! What you find confusing is >>> the fact that it’s not easy for your users to set both the page name and >>> page titles! >>>> >>>> It’s funny (or not :)) since this is exactly what we had in past >>> versions of XWiki and we had several complaints that it was confusing to >>> have the 2 notions and this is why he hid the page name only for > advanced >>> users. >>> >>> Actually, if I remember well, what we were doing was to ask for the page >>> name and we were setting the title to the same as the page name by > default >>> and then the user could edit the title before saving the page. >>> >>> We’ve now done the opposite (user deciding on the title and page name >>> being derived from it) but leading to the issue you’re raising about URL >>> SEO… >>> >>> Thanks >>> -Vincent >>> >>>> See below. >>>> >>>>> On 20 Apr 2017, at 14:20, Vishal <[email protected]> wrote: >>>>> >>>>> Thanks Vincent for your thorough reply.. >>>>> You guessed it right. We intend to have clean and short urls for SEO >>>>> reasons. >>>>> Current scheme creates two problems: >>>>> >>>>> 1) The Page name is fetched automatically from the Title. Often the >>> titles >>>>> have spaces which translate as *percent characters *in url which makes >>> it >>>>> somewhat unclean :) >>>> >>>> Indeed you’re right. By hiding the page name we’re now incitating to >>> have longer URLs and encoded characters showing up in URLs which is not >>> nice I agree. >>>> >>>> Maybe one solution is to do something similar to what we do in AWM, > i.e. >>> generate automatically the URL from the title entered by the user and > show >>> the resulting URL to the user and give the user the opportunity to > change >>> the URL. >>>> >>>> See http://extensions.xwiki.org/xwiki/bin/download/Extension/ >>> App%20Within%20Minutes%20Application/AppWithinMinutes-Step1.png >>>> >>>>> 2) Secondly, to have the shorter url, we use only the short forms of >>>>> complete title. >>>>> Ex. For title 'Pune University' we use name PU. >>>> >>>> Hey, you’re from Pune? :) I’ve been there about 15 times! That was in a >>> previous job where my company and KPIT Cummins were partners. >>>> >>>>> Otherwise in this hierarchy of pages, the url would be much longer. >>>>> Ex. We have page 'Electronics and Telecommunications' branch under > page >>>>> 'Pune University'. We should not have such a long url. Instead here we >>> need >>>>> PU/ENTC or Pune-University/ENTC >>>>> >>>>> To avoid all this, what we currently do: >>>>> 1) On create page dialog, use PU as title.. This will create url as > PU. >>>>> If full name is used here as title, we need to use - instead of spaces >>> to >>>>> avoid percent characters in url. >>>>> 2) While in edit mode, change the title back to Pune University. > Remove >>> any >>>>> - characters to make title clean. >>>>> This is where confusion creeps in. >>>>> >>>>> If these two terms create confusion, why I need to show them both: >>>>> I guess the *confusion is due to term Name*. It doesn't reflect actual >>> usage >>>>> of the term. URL or weblink or link or web address would be more apt >>> terms >>>>> to use to instead of Name. >>>> >>>> Regarding Page name vs Page URL. >>>> >>>> A bit of history: The reason we used page name and not page URL >>> originally is because what the user is creating is a document in the >>> database and initially it was called Document Name. Since that was a bit >>> confusing for users, we had decided to call it Page Name. It just > happened >>> that the URL used was directly derived from the document/page name. >>>> >>>> In practice the 3 concepts could have different values: >>>> * a value for the document’s name in the DB >>>> * another value for the document’s title >>>> * yet another value used in the URL. >>>> >>>> We’ve had discussions so that we could let the user provide shorter > URLs >>> for pages in the future. >>>> >>>> Now for the time being and since we don’t have this ATM, I think I > agree >>> with you that we could decide to display to the user the URL that will > be >>> generated (the encoded URL) and allow the user to change it. Internally > the >>> user would change the document name. >>>> >>>>> My users can differentiate between Title and URL. But the whole >>> procedure we >>>>> follow is certainly not understandable by all. And we definitely need > to >>>>> follow this whole long procedure, just to have short and clean urls. >>>> >>>> Yes, if you’re asking your users to care about the URLs that get >>> generated, right now they need to be advanced users to be able to edit > the >>> page name in the Create Page UI (since changing the title afterwards is > too >>> cumbersome). >>>> >>>>> So, by showing both fields at the first place itself, I would like to >>>>> shorten the procedure and url length. >>>> >>>> I’m in agreement with you. Let’s see what others think. >>>> >>>> Thanks for this interesting discussion! >>>> -Vincent >>>> >>>>> -- >>>>> View this message in context: http://xwiki.475771.n2.nabble. >>> com/Page-Title-and-Name-confusion-tp7603546p7603551.html >>>>> Sent from the XWiki- Users mailing list archive at Nabble.com.
<quote> The fact that the default would be “Never” in your proposal above wouldn’t help that much since by default users wouldn’t be able to control the URLs and thus you’d need to educate everyone that they need to turn this on. It’s quite similar to telling your users to be Advanced users. </quote> Sorry, I think I wasn't clear. I meant that it would be a Wiki-wide setting (hence being a setting in the XWiki Administration). So changing this option would apply the same option to every user. Kind regards, Mahomed Hussein Custodian Data Centre Email: [email protected] http://www.CustodianDC.com -----Original Message----- From: users [mailto:[email protected]] On Behalf Of Vincent Massol Sent: 21 April 2017 12:59 To: XWiki Users <[email protected]> Subject: Re: [xwiki-users] display page title and name(url) while creating a page Hi Mahomed,
On 21 Apr 2017, at 13:50, Mahomed Hussein <[email protected]> wrote:
This is quite an interesting discussion and I'd like to add a few points if you don't mind.
When we first started using XWiki, our users did comment about the really long URLs that were being generated from the Title. But as our XWiki is internal only for documentation, I kind of brushed it off with "That's just the way it works".
But I agree that in some cases it would be good to be able to edit the resulting URL. Both for us, and obviously for other users. :-)
In regards of how to achieve this, I'd like to propose a half-way house/compromise.
Firstly, create an Admin option in the Admin control panel to the effect of:
"Allow users to edit the Page URL when creating new pages" - Always - Optional - Never (Default)
Thanks for participating to the discussion! :) We need the max # of users to provide an opinion. The fact that the default would be “Never” in your proposal above wouldn’t help that much since by default users wouldn’t be able to control the URLs and thus you’d need to educate everyone that they need to turn this on. It’s quite similar to telling your users to be Advanced users. Now, what could be done is having some Admin settings for the defaults when a user account is created in your wiki. It’s just a bit more work and the Admin would still to know about this and thus it’s extra knowledge/complexity to use XWiki. Now we would need to do something like this if we cannot agree that in all cases it’s ok to have the URL displayed in the Create page. If we agree that it’s fine then this config option is not required. Thanks -Vincent
Then on the create page, you would have the following "minor" changes (I say minor because changes are always minor to the person who is not doing the programming ;-) )
If the Admin option is "Never" then the create page remains as it is.
If the Admin option is "Optional" then there should be a link/button under Title that is called "Edit Page URL". This would be an extra button on the current create page form. When the user clicks the button/link, they then get another text box in which to specify the URL parameter.
If the Admin option is "Always" then the create page will show "Page Title" (as it is currently) and will also show the "Page URL" text box. Ideally, this Page URL text box should be auto-populated with the proposed auto-generated name from the title (unless the Page URL is edited before the Page Title). Obviously you'll have to do a few other checks to make sure it's a valid entry for a URL in both cases (but you may have this already from the old version where both options always showed).
I also recommend that the current description text for Title is changed from the very short "Title of the new page" to "This is Title Heading shown at the top of the document when viewed. The Page URL is auto-generated from this title"
Kind regards,
Mahomed Hussein Custodian Data Centre Email: [email protected] http://www.CustodianDC.com
-----Original Message----- From: users [mailto:[email protected]] On Behalf Of Vincent Massol Sent: 21 April 2017 12:16 To: XWiki Users <[email protected]> Subject: Re: [xwiki-users] display page title and name(url) while creating a page
Hi Caty,
On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) <[email protected]> wrote:
Let's see what variants we have:
1. Instead of displaying "Title", display the "Name" instead. This won't solve anything. There is no difference between Page Name and Page Title for the normal users. Seeing "Name" instead of "Title", will not stop the users to enter spaces if they want, so the URL will still have those spaces. We don't force the Page Names to trim spaces.
One quick solution here is indeed to use "URL" label instead of "Name". For the reasons Vincent mentioned this might not end up in the product for now,
What did I mention? :) What’s preventing us from having it in the product rather soon than later (except workload ofc)?
so you will need to do some custom development (changing some translations) to have this change. If you want to be "hackish" you can even change the translation for "Title" to "URL" instead and hope that your users will enter shorter URLs (since we generate the name from the title).
Displaying just Name / URL, means users will still have to go and change the title manually.
This could be better (with URL name) since when you create a page you’re offered the ability to change the title after you click Create.
The only way to cut a step in the flow is to autogenerate the page names (which we currently do). But for your use case you shoyld write a shorting/trimming algorithm, but this is custom, since you mentioned you want just the initials and no spaces, etc.
2. Displaying both "Title" and "Name". This will create confusion and need for explanations.
This is not exactly what is suggested either by Vishal nor by me :) What we suggested is to let the user enter the URL name and title.
Actually and to be more precise what I was suggesting was to continue to let the user enter the title but to show the generated URL as it’s done in AWM. And, importantly to allow the user to change the last part of the URL (it would change the page name).
That's why we display these options just for advanced and long-time users of XWiki, since they are used to the concepts.
Yes but URLs don't need an advanced user to understand the concept and I agree with Vishal that we’re now causing a very large number of pages to have %25 in their URLs by default which is quite bad… Of course someone can spend their time monitoring what users are doing and renaming pages thereafter or educate their users to do that but we’re not helping and we’re making it difficult.
-----
IMO what you are describing is advanced user behavior. Normal users don't generally care about their URLs and SEO.
I don’t fully agree with you. I have the feeling (can’t prove it) that a good number of our users care about the generated URLs.
Also I think that simple users may care about URL without being advanced users. Making them advanced users will expose them to a lot more complexity than they need to know.
But the beauty of XWiki is that you can customize it locally to perfectly match your needs.
That’s not exactly true (and it’s far from being easy, just check createinline.vm): It means overriding large portions of vm code and having to do manual merges whenever you upgrade. A major PITA.
Vincent mentioned something about AWM. I don't see much difference from the Create Page. We generate the names from title here too. We display them in the breadcrumb, but in a more simple way. Displaying the "localhost"/server part is not simple user behavior. AWM is more complex.
-----
So I would not change anything on the product side, since I believe these should be solved as custom changes for your instance. We want to encourage users to use page titles (with spaces in them since they are more readable and supported), while we are preserving the page name behavior for advances users (but we don't enforce it).
I don’t agree with this sentence: We definitely don’t want to encourage users to use titles in URLs.
If users made mistakes they can always change the title or rename the page. On the product side the only change I would like us to do is using the URL naming, but this was debated in the past and dropped for Vincent's reasons.
What reasons, I don’t remember a discussion about using URL name instead of page name?
So our main disagreement is that I consider that favouring encoded characters in URLs is not a good thing while you think it’s not a large enough problem to do something about it.
Would it make our UI too complex to use for simple users if we were showing a URL and the ability to change the last part of it? IMO what’s complex is when we have Page name and Page Title. But I don’t feel there’d be confusion between URL and Page title.
What do others think?
Thanks -Vincent
Thanks, Caty
On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol <[email protected]> wrote:
On 20 Apr 2017, at 22:51, Vincent Massol <[email protected]> wrote:
Hi Vishal,
Ok, I misunderstood you in your first email. I understood the opposite. I thought you were complaining that have 2 notions (page name + page title) was confusing but it’s actually the opposite! What you find confusing is the fact that it’s not easy for your users to set both the page name and page titles!
It’s funny (or not :)) since this is exactly what we had in past versions of XWiki and we had several complaints that it was confusing to have the 2 notions and this is why he hid the page name only for advanced users.
Actually, if I remember well, what we were doing was to ask for the page name and we were setting the title to the same as the page name by default and then the user could edit the title before saving the page.
We’ve now done the opposite (user deciding on the title and page name being derived from it) but leading to the issue you’re raising about URL SEO…
Thanks -Vincent
See below.
On 20 Apr 2017, at 14:20, Vishal <[email protected]> wrote:
Thanks Vincent for your thorough reply.. You guessed it right. We intend to have clean and short urls for SEO reasons. Current scheme creates two problems:
1) The Page name is fetched automatically from the Title. Often the titles have spaces which translate as *percent characters *in url which makes it somewhat unclean :)
Indeed you’re right. By hiding the page name we’re now incitating to have longer URLs and encoded characters showing up in URLs which is not nice I agree.
Maybe one solution is to do something similar to what we do in AWM, i.e. generate automatically the URL from the title entered by the user and show the resulting URL to the user and give the user the opportunity to change the URL.
See http://extensions.xwiki.org/xwiki/bin/download/Extension/ App%20Within%20Minutes%20Application/AppWithinMinutes-Step1.png
2) Secondly, to have the shorter url, we use only the short forms of complete title. Ex. For title 'Pune University' we use name PU.
Hey, you’re from Pune? :) I’ve been there about 15 times! That was in a previous job where my company and KPIT Cummins were partners.
Otherwise in this hierarchy of pages, the url would be much longer. Ex. We have page 'Electronics and Telecommunications' branch under page 'Pune University'. We should not have such a long url. Instead here we need PU/ENTC or Pune-University/ENTC
To avoid all this, what we currently do: 1) On create page dialog, use PU as title.. This will create url as PU. If full name is used here as title, we need to use - instead of spaces to avoid percent characters in url. 2) While in edit mode, change the title back to Pune University. Remove any - characters to make title clean. This is where confusion creeps in.
If these two terms create confusion, why I need to show them both: I guess the *confusion is due to term Name*. It doesn't reflect actual usage of the term. URL or weblink or link or web address would be more apt terms to use to instead of Name.
Regarding Page name vs Page URL.
A bit of history: The reason we used page name and not page URL originally is because what the user is creating is a document in the database and initially it was called Document Name. Since that was a bit confusing for users, we had decided to call it Page Name. It just happened that the URL used was directly derived from the document/page name.
In practice the 3 concepts could have different values: * a value for the document’s name in the DB * another value for the document’s title * yet another value used in the URL.
We’ve had discussions so that we could let the user provide shorter URLs for pages in the future.
Now for the time being and since we don’t have this ATM, I think I agree with you that we could decide to display to the user the URL that will be generated (the encoded URL) and allow the user to change it. Internally the user would change the document name.
My users can differentiate between Title and URL. But the whole procedure we follow is certainly not understandable by all. And we definitely need to follow this whole long procedure, just to have short and clean urls.
Yes, if you’re asking your users to care about the URLs that get generated, right now they need to be advanced users to be able to edit the page name in the Create Page UI (since changing the title afterwards is too cumbersome).
So, by showing both fields at the first place itself, I would like to shorten the procedure and url length.
I’m in agreement with you. Let’s see what others think.
Thanks for this interesting discussion! -Vincent
-- View this message in context: http://xwiki.475771.n2.nabble. com/Page-Title-and-Name-confusion-tp7603546p7603551.html Sent from the XWiki- Users mailing list archive at Nabble.com.
On 21 Apr 2017, at 16:19, Miroslav Galajda <[email protected]> wrote:
Hi, the slugify is different component than speakingurl, but currently it doesn't matter on this.
Ok, how would we solve this globally? Not only in default page creation process but also in custom applications, that create pages in their own. For example the FAQ uses this code to redirect to new FAQ page after entering question name: #set ($newFAQReference = $services.model.createDocumentReference('', '', "$question")) $response.sendRedirect($xwiki.getURL($newFAQReference, 'inline', "$!{request.queryString}&title=${escapetool.url($question)}"))
The solution you propose will be transparent for this code or will it require som modifications?
My proposal is to do 2 things: 1) Introduce some new Component in XWiki Platform. I don’t know where. It could be inside some existing modules in https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core or introduce a new one in there. So a Component + a Script Service so that it can be accessed from wiki pages inside scripts (velocity, groovy, etc). This should cater for the need to be able to use it from anywhere. It’s basically a clean up/transformation of String into something human-readable. 2) Introduce a UIXP inside createinline.vm to allow extenders to contribute some sections in the Create UI. Actually the current “Location” section could even be refactored to be implemented using a UIX for this UIXP. Several UIX could be contributed with an order and they’d appear in the defined order. For more on UIXP, see http://extensions.xwiki.org/xwiki/bin/view/Extension/UIExtension%20Module and to see existing ones see http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/ 3) You could then implement an optional UIX to introduce a new URL section that would use 1) to display what URL would be used for example. It could also let the user modify the last part of the URL. What I haven’t thought about yet is how this UIX will pass back the document name to createinline.vm. Maybe these UIX would be allowed to modify variables in the Velocity/Script context and that would be enough. It probably needs to be brainstormed a bit more but this is the idea I have so far. I’d also like to have @Caty’s POV on the UI aspect/Layout of such a UIXP concept. WDYT Miroslav? Thanks -Vincent
On 21 April 2017 at 16:00, Vincent Massol <[email protected]> wrote:
On 21 Apr 2017, at 15:36, Miroslav Galajda <[email protected]> wrote:
Hi, the solution I've described is javascript based and runs on client-side. From what I know, the component-based solution, which you propose, would require to have url-friendly conversion component usable in java and not as javascript code. Am I right?
Yes you’re right but:
1) There’s also a Java API, see https://github.com/slugify/slugify 2) If we also offer a UIX then it can be implemented in a wiki page for example and you can use JS.
Thanks -Vincent
On 21 April 2017 at 15:28, Vincent Massol <[email protected]> wrote:
Hi Miroslav,
On 21 Apr 2017, at 15:05, Miroslav Galajda <[email protected]
wrote:
Hi, let me enter into this conversion. Some time ago I've asked for help how to solve problem with diacritics
(or
accents) in page names when creating new pages so that the have url-friendly names. You can search for "strip accents from page name used in url" in xwiki users mailing list. I've got no hint or solution from xwiki community till today.
I've come with solution that ensures for simple users, creating url-friendly names without requiring them to think about the concept of the page name or page title. They simple enter the desired human readably page name, and in the code behind of the page creation, I have made some modifications in createinline.vm to hook into page creation process. The modifications are mainly javascript based, where I've attache to submit event of the "form#create", where I replace the entered "title" with the one for url-friendly. And for url-friendly name I've used this javascript based solution on https://pid.github.io/speakingurl/. I've integrated this principle also into page creation process of FAQ and Blog applications, which we are using in our xwiki installation.
It would be nice if you could integrate this principle into xwiki so that everyone can have nice url-friendly urls without worring about it. It is also suitable for english speaking users. You don't have to worry about entering spaces or other non-url allowed characters, which make url look ugly.
That looks very nice!
One way forward I could think about: * We provide some Create script service to return a URL-friendly string. We introduce a component role for this. We refactor createinline.vm to use it and to display the URL. * You could then contribute your code as an extension that we make available on extensions.xwiki.org for users to install * We decide later on if we want to bundle it by default
If we don’t agree about displaying the URL by default all the time then an option is to introduce a UIX in createinline.vm for that. And this could be implemented in your extension too for example or by default in XWiki (possibly with an Admin setting).
WDYT?
Thanks -Vincent
Thank you
Best regards Miroslav Galajda
On 21 April 2017 at 14:02, Vincent Massol <[email protected]> wrote:
> On 21 Apr 2017, at 13:52, Marius Dumitru Florea < [email protected]> wrote: > > On Fri, Apr 21, 2017 at 2:16 PM, Vincent Massol <[email protected]> wrote: > >> Hi Caty, >> >>> On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) <
> >> wrote: >>> >>> Let's see what variants we have: >>> >>> 1. Instead of displaying "Title", display the "Name" instead. >>> This won't solve anything. There is no difference between Page Name and >>> Page Title for the normal users. Seeing "Name" instead of "Title", will >> not >>> stop the users to enter spaces if they want, so the URL will still have >>> those spaces. We don't force the Page Names to trim spaces. >>> >>> One quick solution here is indeed to use "URL" label instead of "Name". >> For >>> the reasons Vincent mentioned this might not end up in the product for >> now, >> >> What did I mention? :) What’s preventing us from having it in the product >> rather soon than later (except workload ofc)? >> >>> so you will need to do some custom development (changing some >> translations) >>> to have this change. If you want to be "hackish" you can even change the >>> translation for "Title" to "URL" instead and hope that your users will >>> enter shorter URLs (since we generate the name from the title). >>> >>> Displaying just Name / URL, means users will still have to go and change >>> the title manually. >> >> This could be better (with URL name) since when you create a page you’re >> offered the ability to change the title after you click Create. >> >>> The only way to cut a step in the flow is to >>> autogenerate the page names (which we currently do). But for your use >> case >>> you shoyld write a shorting/trimming algorithm, but this is custom, since >>> you mentioned you want just the initials and no spaces, etc. >>> >>> 2. Displaying both "Title" and "Name". This will create confusion and >> need >>> for explanations. >> >> This is not exactly what is suggested either by Vishal nor by me :) What >> we suggested is to let the user enter the URL name and title. >> >> Actually and to be more precise what I was suggesting was to continue to >> let the user enter the title but to show the generated URL as it’s done in >> AWM. And, importantly to allow the user to change the last part of the URL >> (it would change the page name). >> >>> That's why we display these options just for advanced and >>> long-time users of XWiki, since they are used to the concepts. >> >> > >> Yes but URLs don't need an advanced user to understand the concept and I >> agree with Vishal that we’re now causing a very large number of pages to >> have %25 in their URLs by default which is quite bad… Of course someone can >> spend their time monitoring what users are doing and renaming pages >> thereafter or educate their users to do that but we’re not helping and >> we’re making it difficult. >> > > If your web site is not in English then you're forced to use special > characters like diacritics which makes it hard to avoid URL encoded > characters (the browser location bar displays the URL nicely but if you > copy the URL the result is not nice).
Agreed. So I’d say it’s even more important to allow the user to be able to easily view and change the resulting URL when they’re not in English.
Thanks -Vincent
> > >> >>> ----- >>> >>> IMO what you are describing is advanced user behavior. Normal users don't >>> generally care about their URLs and SEO. >> >> I don’t fully agree with you. I have the feeling (can’t prove it) that a >> good number of our users care about the generated URLs. >> > >> Also I think that simple users may care about URL without being advanced >> users. Making them advanced users will expose them to a lot more complexity >> than they need to know. >> >>> But the beauty of XWiki is that >>> you can customize it locally to perfectly match your needs. >> >> That’s not exactly true (and it’s far from being easy, just check >> createinline.vm): It means overriding large portions of vm code and having >> to do manual merges whenever you upgrade. A major PITA. >> >>> Vincent mentioned something about AWM. I don't see much difference from >> the >>> Create Page. We generate the names from title here too. We display them >> in >>> the breadcrumb, but in a more simple way. Displaying the >> "localhost"/server >>> part is not simple user behavior. AWM is more complex. >>> >>> ----- >>> >>> So I would not change anything on the product side, since I believe these >>> should be solved as custom changes for your instance. >>> We want to encourage users to use page titles (with spaces in them since >>> they are more readable and supported), while we are preserving the page >>> name behavior for advances users (but we don't enforce it). >> >> I don’t agree with this sentence: We definitely don’t want to encourage >> users to use titles in URLs. >> >>> If users made >>> mistakes they can always change the title or rename the page. >>> On the product side the only change I would like us to do is using the >> URL >>> naming, but this was debated in the past and dropped for Vincent's >> reasons. >> >> What reasons, I don’t remember a discussion about using URL name instead >> of page name? >> >> So our main disagreement is that I consider that favouring encoded >> characters in URLs is not a good thing while you think it’s not a large >> enough problem to do something about it. >> >> Would it make our UI too complex to use for simple users if we were >> showing a URL and the ability to change the last part of it? IMO what’s >> complex is when we have Page name and Page Title. But I don’t feel there’d >> be confusion between URL and Page title. >> >> What do others think? >> >> Thanks >> -Vincent >> >>> >>> Thanks, >>> Caty >>> >>> >>> On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol < [email protected]
>> wrote: >>> >>>> >>>>> On 20 Apr 2017, at 22:51, Vincent Massol <[email protected]> wrote: >>>>> >>>>> Hi Vishal, >>>>> >>>>> Ok, I misunderstood you in your first email. I understood the opposite. >>>> I thought you were complaining that have 2 notions (page name + page >> title) >>>> was confusing but it’s actually the opposite! What you find confusing is >>>> the fact that it’s not easy for your users to set both the page name and >>>> page titles! >>>>> >>>>> It’s funny (or not :)) since this is exactly what we had in past >>>> versions of XWiki and we had several complaints that it was confusing to >>>> have the 2 notions and this is why he hid the page name only for >> advanced >>>> users. >>>> >>>> Actually, if I remember well, what we were doing was to ask for the page >>>> name and we were setting the title to the same as the page name by >> default >>>> and then the user could edit the title before saving the page. >>>> >>>> We’ve now done the opposite (user deciding on the title and page name >>>> being derived from it) but leading to the issue you’re raising about URL >>>> SEO… >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> See below. >>>>> >>>>>> On 20 Apr 2017, at 14:20, Vishal <[email protected]> wrote: >>>>>> >>>>>> Thanks Vincent for your thorough reply.. >>>>>> You guessed it right. We intend to have clean and short urls for SEO >>>>>> reasons. >>>>>> Current scheme creates two problems: >>>>>> >>>>>> 1) The Page name is fetched automatically from the Title. Often the >>>> titles >>>>>> have spaces which translate as *percent characters *in url which makes >>>> it >>>>>> somewhat unclean :) >>>>> >>>>> Indeed you’re right. By hiding the page name we’re now incitating to >>>> have longer URLs and encoded characters showing up in URLs which is not >>>> nice I agree. >>>>> >>>>> Maybe one solution is to do something similar to what we do in AWM, >> i.e. >>>> generate automatically the URL from the title entered by the user and >> show >>>> the resulting URL to the user and give the user the opportunity to >> change >>>> the URL. >>>>> >>>>> See http://extensions.xwiki.org/xwiki/bin/download/Extension/ >>>> App%20Within%20Minutes%20Application/AppWithinMinutes-Step1.png >>>>> >>>>>> 2) Secondly, to have the shorter url, we use only the short forms of >>>>>> complete title. >>>>>> Ex. For title 'Pune University' we use name PU. >>>>> >>>>> Hey, you’re from Pune? :) I’ve been there about 15 times! That was in a >>>> previous job where my company and KPIT Cummins were partners. >>>>> >>>>>> Otherwise in this hierarchy of pages, the url would be much longer. >>>>>> Ex. We have page 'Electronics and Telecommunications' branch under >> page >>>>>> 'Pune University'. We should not have such a long url. Instead here we >>>> need >>>>>> PU/ENTC or Pune-University/ENTC >>>>>> >>>>>> To avoid all this, what we currently do: >>>>>> 1) On create page dialog, use PU as title.. This will create url as >> PU. >>>>>> If full name is used here as title, we need to use - instead of spaces >>>> to >>>>>> avoid percent characters in url. >>>>>> 2) While in edit mode, change the title back to Pune University. >> Remove >>>> any >>>>>> - characters to make title clean. >>>>>> This is where confusion creeps in. >>>>>> >>>>>> If these two terms create confusion, why I need to show them both: >>>>>> I guess the *confusion is due to term Name*. It doesn't reflect actual >>>> usage >>>>>> of the term. URL or weblink or link or web address would be more apt >>>> terms >>>>>> to use to instead of Name. >>>>> >>>>> Regarding Page name vs Page URL. >>>>> >>>>> A bit of history: The reason we used page name and not page URL >>>> originally is because what the user is creating is a document in the >>>> database and initially it was called Document Name. Since that was a bit >>>> confusing for users, we had decided to call it Page Name. It just >> happened >>>> that the URL used was directly derived from the document/page name. >>>>> >>>>> In practice the 3 concepts could have different values: >>>>> * a value for the document’s name in the DB >>>>> * another value for the document’s title >>>>> * yet another value used in the URL. >>>>> >>>>> We’ve had discussions so that we could let the user provide shorter >> URLs >>>> for pages in the future. >>>>> >>>>> Now for the time being and since we don’t have this ATM, I think I >> agree >>>> with you that we could decide to display to the user the URL that will >> be >>>> generated (the encoded URL) and allow the user to change it. Internally >> the >>>> user would change the document name. >>>>> >>>>>> My users can differentiate between Title and URL. But the whole >>>> procedure we >>>>>> follow is certainly not understandable by all. And we definitely need >> to >>>>>> follow this whole long procedure, just to have short and clean urls. >>>>> >>>>> Yes, if you’re asking your users to care about the URLs that get >>>> generated, right now they need to be advanced users to be able to edit >> the >>>> page name in the Create Page UI (since changing the title afterwards is >> too >>>> cumbersome). >>>>> >>>>>> So, by showing both fields at the first place itself, I would like to >>>>>> shorten the procedure and url length. >>>>> >>>>> I’m in agreement with you. Let’s see what others think. >>>>> >>>>> Thanks for this interesting discussion! >>>>> -Vincent >>>>> >>>>>> -- >>>>>> View this message in context: http://xwiki.475771.n2.nabble. >>>> com/Page-Title-and-Name-confusion-tp7603546p7603551.html >>>>>> Sent from the XWiki- Users mailing list archive at Nabble.com.
Hi, this seems to be quite complicated and not complete. This url-friendly problem does arise not only in page creation process but also in page renaming. The other thing is that custom applications that are creating pages would require to use different approax and will need to be customized separately. The UIXP doesn't seems to solve the problem globally and I think currently this is not the main/core part of the problem. I would like if this was built-in and deeply integrated into xwiki and not to have it "only" optional. This is probably hard to quickly find the solution right now. As I said, the best solution would be built-in support such that it will transparently replace user-entered page name with URL-friendly name. The proposed first point, to have component and a script service for converting strings to url-friendly strings, is the must have. This is what I strongly agree about. And it should provide some configuration in xwiki and it should take into account the language in which the page is being created. The speakingurl, aforementioned solution, works with language and provides quite a lot of customization. Then this script service could be directly used in createinline.vm and other .vm files. Don't know about generally solving url-friendly thing in the custom applications. Best regards Miroslav Galajda On 21 April 2017 at 16:45, Vincent Massol <[email protected]> wrote:
On 21 Apr 2017, at 16:19, Miroslav Galajda <[email protected]> wrote:
Hi, the slugify is different component than speakingurl, but currently it doesn't matter on this.
Ok, how would we solve this globally? Not only in default page creation process but also in custom applications, that create pages in their own. For example the FAQ uses this code to redirect to new FAQ page after entering question name: #set ($newFAQReference = $services.model.createDocumentReference('', '', "$question")) $response.sendRedirect($xwiki.getURL($newFAQReference, 'inline', "$!{request.queryString}&title=${escapetool.url($question)}"))
The solution you propose will be transparent for this code or will it require som modifications?
My proposal is to do 2 things:
1) Introduce some new Component in XWiki Platform. I don’t know where. It could be inside some existing modules in https://github.com/xwiki/ xwiki-platform/tree/master/xwiki-platform-core or introduce a new one in there.
So a Component + a Script Service so that it can be accessed from wiki pages inside scripts (velocity, groovy, etc).
This should cater for the need to be able to use it from anywhere.
It’s basically a clean up/transformation of String into something human-readable.
2) Introduce a UIXP inside createinline.vm to allow extenders to contribute some sections in the Create UI. Actually the current “Location” section could even be refactored to be implemented using a UIX for this UIXP. Several UIX could be contributed with an order and they’d appear in the defined order.
For more on UIXP, see http://extensions.xwiki.org/ xwiki/bin/view/Extension/UIExtension%20Module and to see existing ones see http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/
3) You could then implement an optional UIX to introduce a new URL section that would use 1) to display what URL would be used for example. It could also let the user modify the last part of the URL.
What I haven’t thought about yet is how this UIX will pass back the document name to createinline.vm. Maybe these UIX would be allowed to modify variables in the Velocity/Script context and that would be enough.
It probably needs to be brainstormed a bit more but this is the idea I have so far. I’d also like to have @Caty’s POV on the UI aspect/Layout of such a UIXP concept.
WDYT Miroslav?
Thanks -Vincent
On 21 April 2017 at 16:00, Vincent Massol <[email protected]> wrote:
On 21 Apr 2017, at 15:36, Miroslav Galajda <[email protected]
wrote:
Hi, the solution I've described is javascript based and runs on
client-side.
From what I know, the component-based solution, which you propose, would require to have url-friendly conversion component usable in java and not as javascript code. Am I right?
Yes you’re right but:
1) There’s also a Java API, see https://github.com/slugify/slugify 2) If we also offer a UIX then it can be implemented in a wiki page for example and you can use JS.
Thanks -Vincent
On 21 April 2017 at 15:28, Vincent Massol <[email protected]> wrote:
Hi Miroslav,
On 21 Apr 2017, at 15:05, Miroslav Galajda < [email protected]
wrote:
Hi, let me enter into this conversion. Some time ago I've asked for help how to solve problem with
diacritics (or
accents) in page names when creating new pages so that the have url-friendly names. You can search for "strip accents from page name used in url" in xwiki users mailing list. I've got no hint or solution from xwiki community till today.
I've come with solution that ensures for simple users, creating url-friendly names without requiring them to think about the concept of the page name or page title. They simple enter the desired human readably page name, and in the code behind of the page creation, I have made some modifications in createinline.vm to hook into page creation process. The modifications are mainly javascript based, where I've attache to submit event of the "form#create", where I replace the entered "title" with the one for url-friendly. And for url-friendly name I've used this javascript based solution on https://pid.github.io/speakingurl/. I've integrated this principle also into page creation process of FAQ and Blog applications, which we are using in our xwiki installation.
It would be nice if you could integrate this principle into xwiki so that everyone can have nice url-friendly urls without worring about it. It is also suitable for english speaking users. You don't have to worry about entering spaces or other non-url allowed characters, which make url look ugly.
That looks very nice!
One way forward I could think about: * We provide some Create script service to return a URL-friendly string. We introduce a component role for this. We refactor createinline.vm to use it and to display the URL. * You could then contribute your code as an extension that we make available on extensions.xwiki.org for users to install * We decide later on if we want to bundle it by default
If we don’t agree about displaying the URL by default all the time then an option is to introduce a UIX in createinline.vm for that. And this could be implemented in your extension too for example or by default in XWiki (possibly with an Admin setting).
WDYT?
Thanks -Vincent
Thank you
Best regards Miroslav Galajda
On 21 April 2017 at 14:02, Vincent Massol <[email protected]>
wrote:
> >> On 21 Apr 2017, at 13:52, Marius Dumitru Florea < > [email protected]> wrote: >> >> On Fri, Apr 21, 2017 at 2:16 PM, Vincent Massol <
> wrote: >> >>> Hi Caty, >>> >>>> On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) < [email protected] >> >>> wrote: >>>> >>>> Let's see what variants we have: >>>> >>>> 1. Instead of displaying "Title", display the "Name" instead. >>>> This won't solve anything. There is no difference between Page Name and >>>> Page Title for the normal users. Seeing "Name" instead of "Title", will >>> not >>>> stop the users to enter spaces if they want, so the URL will still have >>>> those spaces. We don't force the Page Names to trim spaces. >>>> >>>> One quick solution here is indeed to use "URL" label instead of "Name". >>> For >>>> the reasons Vincent mentioned this might not end up in the product for >>> now, >>> >>> What did I mention? :) What’s preventing us from having it in the > product >>> rather soon than later (except workload ofc)? >>> >>>> so you will need to do some custom development (changing some >>> translations) >>>> to have this change. If you want to be "hackish" you can even change > the >>>> translation for "Title" to "URL" instead and hope that your users will >>>> enter shorter URLs (since we generate the name from the title). >>>> >>>> Displaying just Name / URL, means users will still have to go and > change >>>> the title manually. >>> >>> This could be better (with URL name) since when you create a page you’re >>> offered the ability to change the title after you click Create. >>> >>>> The only way to cut a step in the flow is to >>>> autogenerate the page names (which we currently do). But for your use >>> case >>>> you shoyld write a shorting/trimming algorithm, but this is custom, > since >>>> you mentioned you want just the initials and no spaces, etc. >>>> >>>> 2. Displaying both "Title" and "Name". This will create confusion and >>> need >>>> for explanations. >>> >>> This is not exactly what is suggested either by Vishal nor by me :) What >>> we suggested is to let the user enter the URL name and title. >>> >>> Actually and to be more precise what I was suggesting was to continue to >>> let the user enter the title but to show the generated URL as it’s done > in >>> AWM. And, importantly to allow the user to change the last part of the > URL >>> (it would change the page name). >>> >>>> That's why we display these options just for advanced and >>>> long-time users of XWiki, since they are used to the concepts. >>> >>> >> >>> Yes but URLs don't need an advanced user to understand the concept and I >>> agree with Vishal that we’re now causing a very large number of pages to >>> have %25 in their URLs by default which is quite bad… Of course someone > can >>> spend their time monitoring what users are doing and renaming pages >>> thereafter or educate their users to do that but we’re not helping and >>> we’re making it difficult. >>> >> >> If your web site is not in English then you're forced to use special >> characters like diacritics which makes it hard to avoid URL encoded >> characters (the browser location bar displays the URL nicely but if you >> copy the URL the result is not nice). > > Agreed. So I’d say it’s even more important to allow the user to be able > to easily view and change the resulting URL when they’re not in English. > > Thanks > -Vincent > >> >> >>> >>>> ----- >>>> >>>> IMO what you are describing is advanced user behavior. Normal users > don't >>>> generally care about their URLs and SEO. >>> >>> I don’t fully agree with you. I have the feeling (can’t prove it) that a >>> good number of our users care about the generated URLs. >>> >> >>> Also I think that simple users may care about URL without being advanced >>> users. Making them advanced users will expose them to a lot more > complexity >>> than they need to know. >>> >>>> But the beauty of XWiki is that >>>> you can customize it locally to perfectly match your needs. >>> >>> That’s not exactly true (and it’s far from being easy, just check >>> createinline.vm): It means overriding large portions of vm code and > having >>> to do manual merges whenever you upgrade. A major PITA. >>> >>>> Vincent mentioned something about AWM. I don't see much difference from >>> the >>>> Create Page. We generate the names from title here too. We display them >>> in >>>> the breadcrumb, but in a more simple way. Displaying the >>> "localhost"/server >>>> part is not simple user behavior. AWM is more complex. >>>> >>>> ----- >>>> >>>> So I would not change anything on the product side, since I believe > these >>>> should be solved as custom changes for your instance. >>>> We want to encourage users to use page titles (with spaces in them > since >>>> they are more readable and supported), while we are preserving the page >>>> name behavior for advances users (but we don't enforce it). >>> >>> I don’t agree with this sentence: We definitely don’t want to encourage >>> users to use titles in URLs. >>> >>>> If users made >>>> mistakes they can always change the title or rename the page. >>>> On the product side the only change I would like us to do is using the >>> URL >>>> naming, but this was debated in the past and dropped for Vincent's >>> reasons. >>> >>> What reasons, I don’t remember a discussion about using URL name instead >>> of page name? >>> >>> So our main disagreement is that I consider that favouring encoded >>> characters in URLs is not a good thing while you think it’s not a large >>> enough problem to do something about it. >>> >>> Would it make our UI too complex to use for simple users if we were >>> showing a URL and the ability to change the last part of it? IMO what’s >>> complex is when we have Page name and Page Title. But I don’t feel > there’d >>> be confusion between URL and Page title. >>> >>> What do others think? >>> >>> Thanks >>> -Vincent >>> >>>> >>>> Thanks, >>>> Caty >>>> >>>> >>>> On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol < [email protected]
>>> wrote: >>>> >>>>> >>>>>> On 20 Apr 2017, at 22:51, Vincent Massol <[email protected]> wrote: >>>>>> >>>>>> Hi Vishal, >>>>>> >>>>>> Ok, I misunderstood you in your first email. I understood the > opposite. >>>>> I thought you were complaining that have 2 notions (page name + page >>> title) >>>>> was confusing but it’s actually the opposite! What you find confusing > is >>>>> the fact that it’s not easy for your users to set both the page name > and >>>>> page titles! >>>>>> >>>>>> It’s funny (or not :)) since this is exactly what we had in past >>>>> versions of XWiki and we had several complaints that it was confusing > to >>>>> have the 2 notions and this is why he hid the page name only for >>> advanced >>>>> users. >>>>> >>>>> Actually, if I remember well, what we were doing was to ask for the > page >>>>> name and we were setting the title to the same as the page name by >>> default >>>>> and then the user could edit the title before saving the page. >>>>> >>>>> We’ve now done the opposite (user deciding on the title and page name >>>>> being derived from it) but leading to the issue you’re raising about > URL >>>>> SEO… >>>>> >>>>> Thanks >>>>> -Vincent >>>>> >>>>>> See below. >>>>>> >>>>>>> On 20 Apr 2017, at 14:20, Vishal <[email protected]> wrote: >>>>>>> >>>>>>> Thanks Vincent for your thorough reply.. >>>>>>> You guessed it right. We intend to have clean and short urls for SEO >>>>>>> reasons. >>>>>>> Current scheme creates two problems: >>>>>>> >>>>>>> 1) The Page name is fetched automatically from the Title. Often the >>>>> titles >>>>>>> have spaces which translate as *percent characters *in url which > makes >>>>> it >>>>>>> somewhat unclean :) >>>>>> >>>>>> Indeed you’re right. By hiding the page name we’re now incitating to >>>>> have longer URLs and encoded characters showing up in URLs which is > not >>>>> nice I agree. >>>>>> >>>>>> Maybe one solution is to do something similar to what we do in AWM, >>> i.e. >>>>> generate automatically the URL from the title entered by the user and >>> show >>>>> the resulting URL to the user and give the user the opportunity to >>> change >>>>> the URL. >>>>>> >>>>>> See http://extensions.xwiki.org/xwiki/bin/download/Extension/ >>>>> App%20Within%20Minutes%20Application/AppWithinMinutes-Step1.png >>>>>> >>>>>>> 2) Secondly, to have the shorter url, we use only the short forms of >>>>>>> complete title. >>>>>>> Ex. For title 'Pune University' we use name PU. >>>>>> >>>>>> Hey, you’re from Pune? :) I’ve been there about 15 times! That was > in a >>>>> previous job where my company and KPIT Cummins were partners. >>>>>> >>>>>>> Otherwise in this hierarchy of pages, the url would be much longer. >>>>>>> Ex. We have page 'Electronics and Telecommunications' branch under >>> page >>>>>>> 'Pune University'. We should not have such a long url. Instead here > we >>>>> need >>>>>>> PU/ENTC or Pune-University/ENTC >>>>>>> >>>>>>> To avoid all this, what we currently do: >>>>>>> 1) On create page dialog, use PU as title.. This will create url as >>> PU. >>>>>>> If full name is used here as title, we need to use - instead of > spaces >>>>> to >>>>>>> avoid percent characters in url. >>>>>>> 2) While in edit mode, change the title back to Pune University. >>> Remove >>>>> any >>>>>>> - characters to make title clean. >>>>>>> This is where confusion creeps in. >>>>>>> >>>>>>> If these two terms create confusion, why I need to show them both: >>>>>>> I guess the *confusion is due to term Name*. It doesn't reflect > actual >>>>> usage >>>>>>> of the term. URL or weblink or link or web address would be more apt >>>>> terms >>>>>>> to use to instead of Name. >>>>>> >>>>>> Regarding Page name vs Page URL. >>>>>> >>>>>> A bit of history: The reason we used page name and not page URL >>>>> originally is because what the user is creating is a document in the >>>>> database and initially it was called Document Name. Since that was a > bit >>>>> confusing for users, we had decided to call it Page Name. It just >>> happened >>>>> that the URL used was directly derived from the document/page name. >>>>>> >>>>>> In practice the 3 concepts could have different values: >>>>>> * a value for the document’s name in the DB >>>>>> * another value for the document’s title >>>>>> * yet another value used in the URL. >>>>>> >>>>>> We’ve had discussions so that we could let the user provide shorter >>> URLs >>>>> for pages in the future. >>>>>> >>>>>> Now for the time being and since we don’t have this ATM, I think I >>> agree >>>>> with you that we could decide to display to the user the URL that will >>> be >>>>> generated (the encoded URL) and allow the user to change it. > Internally >>> the >>>>> user would change the document name. >>>>>> >>>>>>> My users can differentiate between Title and URL. But the whole >>>>> procedure we >>>>>>> follow is certainly not understandable by all. And we definitely > need >>> to >>>>>>> follow this whole long procedure, just to have short and clean urls. >>>>>> >>>>>> Yes, if you’re asking your users to care about the URLs that get >>>>> generated, right now they need to be advanced users to be able to edit >>> the >>>>> page name in the Create Page UI (since changing the title afterwards > is >>> too >>>>> cumbersome). >>>>>> >>>>>>> So, by showing both fields at the first place itself, I would like > to >>>>>>> shorten the procedure and url length. >>>>>> >>>>>> I’m in agreement with you. Let’s see what others think. >>>>>> >>>>>> Thanks for this interesting discussion! >>>>>> -Vincent >>>>>> >>>>>>> -- >>>>>>> View this message in context: http://xwiki.475771.n2.nabble. >>>>> com/Page-Title-and-Name-confusion-tp7603546p7603551.html >>>>>>> Sent from the XWiki- Users mailing list archive at Nabble.com. > >
Hi again,
On 21 Apr 2017, at 17:33, Miroslav Galajda <[email protected]> wrote:
Hi,
this seems to be quite complicated and not complete. This url-friendly problem does arise not only in page creation process but also in page renaming.
The other thing is that custom applications that are creating pages would require to use different approax and will need to be customized separately. The UIXP doesn't seems to solve the problem globally and I think currently this is not the main/core part of the problem.
I would like if this was built-in and deeply integrated into xwiki and not to have it "only" optional. This is probably hard to quickly find the solution right now. As I said, the best solution would be built-in support such that it will transparently replace user-entered page name with URL-friendly name.
Yes there are 2 aspects. The built-in part is easy by doing 1) and having a default implementation that doesn’t do any transformation. Then an extension can contribute a new component overriding the default one to use a different algorithm. And this new API can be used in different places of XWiki (Create page, rename page, AWM-generated entries, etc). That’s mostly what I meant by 1) below. But for me this is not enough we also need to show the generated URL in the create page UI for example and that’s 2). Right now we don’t have an agreement from all xwiki devs that they’re ok to go with showing the generated URL hence the UIXP idea. If everyone agrees then the problem goes away and it can be built in the default UIs. There’s still the question of allowing the user to edit the last part of the URL but let’s consider it as a detail FTM.
The proposed first point, to have component and a script service for converting strings to url-friendly strings, is the must have. This is what I strongly agree about. And it should provide some configuration in xwiki and it should take into account the language in which the page is being created. The speakingurl, aforementioned solution, works with language and provides quite a lot of customization.
Yep.
Then this script service could be directly used in createinline.vm and other .vm files. Don't know about generally solving url-friendly thing in the custom applications.
Thanks -Vincent
Best regards Miroslav Galajda
On 21 April 2017 at 16:45, Vincent Massol <[email protected]> wrote:
On 21 Apr 2017, at 16:19, Miroslav Galajda <[email protected]> wrote:
Hi, the slugify is different component than speakingurl, but currently it doesn't matter on this.
Ok, how would we solve this globally? Not only in default page creation process but also in custom applications, that create pages in their own. For example the FAQ uses this code to redirect to new FAQ page after entering question name: #set ($newFAQReference = $services.model.createDocumentReference('', '', "$question")) $response.sendRedirect($xwiki.getURL($newFAQReference, 'inline', "$!{request.queryString}&title=${escapetool.url($question)}"))
The solution you propose will be transparent for this code or will it require som modifications?
My proposal is to do 2 things:
1) Introduce some new Component in XWiki Platform. I don’t know where. It could be inside some existing modules in https://github.com/xwiki/ xwiki-platform/tree/master/xwiki-platform-core or introduce a new one in there.
So a Component + a Script Service so that it can be accessed from wiki pages inside scripts (velocity, groovy, etc).
This should cater for the need to be able to use it from anywhere.
It’s basically a clean up/transformation of String into something human-readable.
2) Introduce a UIXP inside createinline.vm to allow extenders to contribute some sections in the Create UI. Actually the current “Location” section could even be refactored to be implemented using a UIX for this UIXP. Several UIX could be contributed with an order and they’d appear in the defined order.
For more on UIXP, see http://extensions.xwiki.org/ xwiki/bin/view/Extension/UIExtension%20Module and to see existing ones see http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/
3) You could then implement an optional UIX to introduce a new URL section that would use 1) to display what URL would be used for example. It could also let the user modify the last part of the URL.
What I haven’t thought about yet is how this UIX will pass back the document name to createinline.vm. Maybe these UIX would be allowed to modify variables in the Velocity/Script context and that would be enough.
It probably needs to be brainstormed a bit more but this is the idea I have so far. I’d also like to have @Caty’s POV on the UI aspect/Layout of such a UIXP concept.
WDYT Miroslav?
Thanks -Vincent
On 21 April 2017 at 16:00, Vincent Massol <[email protected]> wrote:
On 21 Apr 2017, at 15:36, Miroslav Galajda <[email protected]
wrote:
Hi, the solution I've described is javascript based and runs on
client-side.
From what I know, the component-based solution, which you propose, would require to have url-friendly conversion component usable in java and not as javascript code. Am I right?
Yes you’re right but:
1) There’s also a Java API, see https://github.com/slugify/slugify 2) If we also offer a UIX then it can be implemented in a wiki page for example and you can use JS.
Thanks -Vincent
On 21 April 2017 at 15:28, Vincent Massol <[email protected]> wrote:
Hi Miroslav,
> On 21 Apr 2017, at 15:05, Miroslav Galajda < [email protected]
wrote: > > Hi, let me enter into this conversion. > Some time ago I've asked for help how to solve problem with diacritics (or > accents) in page names when creating new pages so that the have > url-friendly names. You can search for "strip accents from page name used > in url" in xwiki users mailing list. I've got no hint or solution from > xwiki community till today. > > I've come with solution that ensures for simple users, creating > url-friendly names without requiring them to think about the concept of the > page name or page title. They simple enter the desired human readably page > name, and in the code behind of the page creation, I have made some > modifications in createinline.vm to hook into page creation process. The > modifications are mainly javascript based, where I've attache to submit > event of the "form#create", where I replace the entered "title" with the > one for url-friendly. And for url-friendly name I've used this javascript > based solution on https://pid.github.io/speakingurl/. > I've integrated this principle also into page creation process of FAQ and > Blog applications, which we are using in our xwiki installation. > > It would be nice if you could integrate this principle into xwiki so that > everyone can have nice url-friendly urls without worring about it. It is > also suitable for english speaking users. You don't have to worry about > entering spaces or other non-url allowed characters, which make url look > ugly.
That looks very nice!
One way forward I could think about: * We provide some Create script service to return a URL-friendly string. We introduce a component role for this. We refactor createinline.vm to use it and to display the URL. * You could then contribute your code as an extension that we make available on extensions.xwiki.org for users to install * We decide later on if we want to bundle it by default
If we don’t agree about displaying the URL by default all the time then an option is to introduce a UIX in createinline.vm for that. And this could be implemented in your extension too for example or by default in XWiki (possibly with an Admin setting).
WDYT?
Thanks -Vincent
> > Thank you > > Best regards > Miroslav Galajda > > On 21 April 2017 at 14:02, Vincent Massol <[email protected]> wrote: > >> >>> On 21 Apr 2017, at 13:52, Marius Dumitru Florea < >> [email protected]> wrote: >>> >>> On Fri, Apr 21, 2017 at 2:16 PM, Vincent Massol < [email protected]> >> wrote: >>> >>>> Hi Caty, >>>> >>>>> On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) < [email protected] >>> >>>> wrote: >>>>> >>>>> Let's see what variants we have: >>>>> >>>>> 1. Instead of displaying "Title", display the "Name" instead. >>>>> This won't solve anything. There is no difference between Page Name and >>>>> Page Title for the normal users. Seeing "Name" instead of "Title", will >>>> not >>>>> stop the users to enter spaces if they want, so the URL will still have >>>>> those spaces. We don't force the Page Names to trim spaces. >>>>> >>>>> One quick solution here is indeed to use "URL" label instead of "Name". >>>> For >>>>> the reasons Vincent mentioned this might not end up in the product for >>>> now, >>>> >>>> What did I mention? :) What’s preventing us from having it in the >> product >>>> rather soon than later (except workload ofc)? >>>> >>>>> so you will need to do some custom development (changing some >>>> translations) >>>>> to have this change. If you want to be "hackish" you can even change >> the >>>>> translation for "Title" to "URL" instead and hope that your users will >>>>> enter shorter URLs (since we generate the name from the title). >>>>> >>>>> Displaying just Name / URL, means users will still have to go and >> change >>>>> the title manually. >>>> >>>> This could be better (with URL name) since when you create a page you’re >>>> offered the ability to change the title after you click Create. >>>> >>>>> The only way to cut a step in the flow is to >>>>> autogenerate the page names (which we currently do). But for your use >>>> case >>>>> you shoyld write a shorting/trimming algorithm, but this is custom, >> since >>>>> you mentioned you want just the initials and no spaces, etc. >>>>> >>>>> 2. Displaying both "Title" and "Name". This will create confusion and >>>> need >>>>> for explanations. >>>> >>>> This is not exactly what is suggested either by Vishal nor by me :) What >>>> we suggested is to let the user enter the URL name and title. >>>> >>>> Actually and to be more precise what I was suggesting was to continue to >>>> let the user enter the title but to show the generated URL as it’s done >> in >>>> AWM. And, importantly to allow the user to change the last part of the >> URL >>>> (it would change the page name). >>>> >>>>> That's why we display these options just for advanced and >>>>> long-time users of XWiki, since they are used to the concepts. >>>> >>>> >>> >>>> Yes but URLs don't need an advanced user to understand the concept and I >>>> agree with Vishal that we’re now causing a very large number of pages to >>>> have %25 in their URLs by default which is quite bad… Of course someone >> can >>>> spend their time monitoring what users are doing and renaming pages >>>> thereafter or educate their users to do that but we’re not helping and >>>> we’re making it difficult. >>>> >>> >>> If your web site is not in English then you're forced to use special >>> characters like diacritics which makes it hard to avoid URL encoded >>> characters (the browser location bar displays the URL nicely but if you >>> copy the URL the result is not nice). >> >> Agreed. So I’d say it’s even more important to allow the user to be able >> to easily view and change the resulting URL when they’re not in English. >> >> Thanks >> -Vincent >> >>> >>> >>>> >>>>> ----- >>>>> >>>>> IMO what you are describing is advanced user behavior. Normal users >> don't >>>>> generally care about their URLs and SEO. >>>> >>>> I don’t fully agree with you. I have the feeling (can’t prove it) that a >>>> good number of our users care about the generated URLs. >>>> >>> >>>> Also I think that simple users may care about URL without being advanced >>>> users. Making them advanced users will expose them to a lot more >> complexity >>>> than they need to know. >>>> >>>>> But the beauty of XWiki is that >>>>> you can customize it locally to perfectly match your needs. >>>> >>>> That’s not exactly true (and it’s far from being easy, just check >>>> createinline.vm): It means overriding large portions of vm code and >> having >>>> to do manual merges whenever you upgrade. A major PITA. >>>> >>>>> Vincent mentioned something about AWM. I don't see much difference from >>>> the >>>>> Create Page. We generate the names from title here too. We display them >>>> in >>>>> the breadcrumb, but in a more simple way. Displaying the >>>> "localhost"/server >>>>> part is not simple user behavior. AWM is more complex. >>>>> >>>>> ----- >>>>> >>>>> So I would not change anything on the product side, since I believe >> these >>>>> should be solved as custom changes for your instance. >>>>> We want to encourage users to use page titles (with spaces in them >> since >>>>> they are more readable and supported), while we are preserving the page >>>>> name behavior for advances users (but we don't enforce it). >>>> >>>> I don’t agree with this sentence: We definitely don’t want to encourage >>>> users to use titles in URLs. >>>> >>>>> If users made >>>>> mistakes they can always change the title or rename the page. >>>>> On the product side the only change I would like us to do is using the >>>> URL >>>>> naming, but this was debated in the past and dropped for Vincent's >>>> reasons. >>>> >>>> What reasons, I don’t remember a discussion about using URL name instead >>>> of page name? >>>> >>>> So our main disagreement is that I consider that favouring encoded >>>> characters in URLs is not a good thing while you think it’s not a large >>>> enough problem to do something about it. >>>> >>>> Would it make our UI too complex to use for simple users if we were >>>> showing a URL and the ability to change the last part of it? IMO what’s >>>> complex is when we have Page name and Page Title. But I don’t feel >> there’d >>>> be confusion between URL and Page title. >>>> >>>> What do others think? >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> >>>>> Thanks, >>>>> Caty >>>>> >>>>> >>>>> On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol < [email protected] > >>>> wrote: >>>>> >>>>>> >>>>>>> On 20 Apr 2017, at 22:51, Vincent Massol <[email protected]> wrote: >>>>>>> >>>>>>> Hi Vishal, >>>>>>> >>>>>>> Ok, I misunderstood you in your first email. I understood the >> opposite. >>>>>> I thought you were complaining that have 2 notions (page name + page >>>> title) >>>>>> was confusing but it’s actually the opposite! What you find confusing >> is >>>>>> the fact that it’s not easy for your users to set both the page name >> and >>>>>> page titles! >>>>>>> >>>>>>> It’s funny (or not :)) since this is exactly what we had in past >>>>>> versions of XWiki and we had several complaints that it was confusing >> to >>>>>> have the 2 notions and this is why he hid the page name only for >>>> advanced >>>>>> users. >>>>>> >>>>>> Actually, if I remember well, what we were doing was to ask for the >> page >>>>>> name and we were setting the title to the same as the page name by >>>> default >>>>>> and then the user could edit the title before saving the page. >>>>>> >>>>>> We’ve now done the opposite (user deciding on the title and page name >>>>>> being derived from it) but leading to the issue you’re raising about >> URL >>>>>> SEO… >>>>>> >>>>>> Thanks >>>>>> -Vincent >>>>>> >>>>>>> See below. >>>>>>> >>>>>>>> On 20 Apr 2017, at 14:20, Vishal <[email protected]> wrote: >>>>>>>> >>>>>>>> Thanks Vincent for your thorough reply.. >>>>>>>> You guessed it right. We intend to have clean and short urls for SEO >>>>>>>> reasons. >>>>>>>> Current scheme creates two problems: >>>>>>>> >>>>>>>> 1) The Page name is fetched automatically from the Title. Often the >>>>>> titles >>>>>>>> have spaces which translate as *percent characters *in url which >> makes >>>>>> it >>>>>>>> somewhat unclean :) >>>>>>> >>>>>>> Indeed you’re right. By hiding the page name we’re now incitating to >>>>>> have longer URLs and encoded characters showing up in URLs which is >> not >>>>>> nice I agree. >>>>>>> >>>>>>> Maybe one solution is to do something similar to what we do in AWM, >>>> i.e. >>>>>> generate automatically the URL from the title entered by the user and >>>> show >>>>>> the resulting URL to the user and give the user the opportunity to >>>> change >>>>>> the URL. >>>>>>> >>>>>>> See http://extensions.xwiki.org/xwiki/bin/download/Extension/ >>>>>> App%20Within%20Minutes%20Application/AppWithinMinutes-Step1.png >>>>>>> >>>>>>>> 2) Secondly, to have the shorter url, we use only the short forms of >>>>>>>> complete title. >>>>>>>> Ex. For title 'Pune University' we use name PU. >>>>>>> >>>>>>> Hey, you’re from Pune? :) I’ve been there about 15 times! That was >> in a >>>>>> previous job where my company and KPIT Cummins were partners. >>>>>>> >>>>>>>> Otherwise in this hierarchy of pages, the url would be much longer. >>>>>>>> Ex. We have page 'Electronics and Telecommunications' branch under >>>> page >>>>>>>> 'Pune University'. We should not have such a long url. Instead here >> we >>>>>> need >>>>>>>> PU/ENTC or Pune-University/ENTC >>>>>>>> >>>>>>>> To avoid all this, what we currently do: >>>>>>>> 1) On create page dialog, use PU as title.. This will create url as >>>> PU. >>>>>>>> If full name is used here as title, we need to use - instead of >> spaces >>>>>> to >>>>>>>> avoid percent characters in url. >>>>>>>> 2) While in edit mode, change the title back to Pune University. >>>> Remove >>>>>> any >>>>>>>> - characters to make title clean. >>>>>>>> This is where confusion creeps in. >>>>>>>> >>>>>>>> If these two terms create confusion, why I need to show them both: >>>>>>>> I guess the *confusion is due to term Name*. It doesn't reflect >> actual >>>>>> usage >>>>>>>> of the term. URL or weblink or link or web address would be more apt >>>>>> terms >>>>>>>> to use to instead of Name. >>>>>>> >>>>>>> Regarding Page name vs Page URL. >>>>>>> >>>>>>> A bit of history: The reason we used page name and not page URL >>>>>> originally is because what the user is creating is a document in the >>>>>> database and initially it was called Document Name. Since that was a >> bit >>>>>> confusing for users, we had decided to call it Page Name. It just >>>> happened >>>>>> that the URL used was directly derived from the document/page name. >>>>>>> >>>>>>> In practice the 3 concepts could have different values: >>>>>>> * a value for the document’s name in the DB >>>>>>> * another value for the document’s title >>>>>>> * yet another value used in the URL. >>>>>>> >>>>>>> We’ve had discussions so that we could let the user provide shorter >>>> URLs >>>>>> for pages in the future. >>>>>>> >>>>>>> Now for the time being and since we don’t have this ATM, I think I >>>> agree >>>>>> with you that we could decide to display to the user the URL that will >>>> be >>>>>> generated (the encoded URL) and allow the user to change it. >> Internally >>>> the >>>>>> user would change the document name. >>>>>>> >>>>>>>> My users can differentiate between Title and URL. But the whole >>>>>> procedure we >>>>>>>> follow is certainly not understandable by all. And we definitely >> need >>>> to >>>>>>>> follow this whole long procedure, just to have short and clean urls. >>>>>>> >>>>>>> Yes, if you’re asking your users to care about the URLs that get >>>>>> generated, right now they need to be advanced users to be able to edit >>>> the >>>>>> page name in the Create Page UI (since changing the title afterwards >> is >>>> too >>>>>> cumbersome). >>>>>>> >>>>>>>> So, by showing both fields at the first place itself, I would like >> to >>>>>>>> shorten the procedure and url length. >>>>>>> >>>>>>> I’m in agreement with you. Let’s see what others think. >>>>>>> >>>>>>> Thanks for this interesting discussion! >>>>>>> -Vincent >>>>>>> >>>>>>>> -- >>>>>>>> View this message in context: http://xwiki.475771.n2.nabble. >>>>>> com/Page-Title-and-Name-confusion-tp7603546p7603551.html >>>>>>>> Sent from the XWiki- Users mailing list archive at Nabble.com. >> >>
I was just mocking up some samples of my recommendation (which I think possibly lines up with Vincent's points 2 and 3), when I realised that there already exists the UI to edit the Page URL. It's just not called that and I didn't remember seeing it. But I see that's probably what Caty was referring to :-) I feel like I am just catching up to the conversation :-) So just to re-cap 1) You can currently edit the location, but this is only for advanced users. (Maybe this can be a Wiki-wide setting instead of being tied to advanced users, even if it can only be set in the config file - screenshot https://snag.gy/vS4f3j.jpg). Personally I don't see why this needs to be an advanced user only feature, because if a user can create a page and decide what its parent page is, why can't they decide on the URL name? A wiki-wide setting will allow the Admin to make this decision on an all or nothing basis (rather than just the "nothing" option we have now). 2) The word "Name" and the description "Name of the new page" are not very clear. (I have made a recommendation in this screenshot - https://snag.gy/dlUK96.jpg) 3) I love the speakingurl suggestion and I hope you do implement it. I think it will give the best of both worlds. It will generate nicer URLs. I also agree with Vincent, many of the users *do* care about the URL. For example, we share URLs in emails and chat etc. and cross reference in documentation. This is one of the many uses where a nice URL is actually useful. Slightly off-topic, it's nice to see you (the XWiki devs) actually taking this seriously and discussing it here. It's very refreshing. So just wanted to say thanks for that. Kind regards, Mahomed Hussein Custodian Data Centre Email: [email protected] http://www.CustodianDC.com -----Original Message----- From: users [mailto:[email protected]] On Behalf Of Vincent Massol Sent: 21 April 2017 16:56 To: XWiki Users <[email protected]> Subject: Re: [xwiki-users] display page title and name(url) while creating a page Hi again,
On 21 Apr 2017, at 17:33, Miroslav Galajda <[email protected]> wrote:
Hi,
this seems to be quite complicated and not complete. This url-friendly problem does arise not only in page creation process but also in page renaming.
The other thing is that custom applications that are creating pages would require to use different approax and will need to be customized separately. The UIXP doesn't seems to solve the problem globally and I think currently this is not the main/core part of the problem.
I would like if this was built-in and deeply integrated into xwiki and not to have it "only" optional. This is probably hard to quickly find the solution right now. As I said, the best solution would be built-in support such that it will transparently replace user-entered page name with URL-friendly name.
Yes there are 2 aspects. The built-in part is easy by doing 1) and having a default implementation that doesn’t do any transformation. Then an extension can contribute a new component overriding the default one to use a different algorithm. And this new API can be used in different places of XWiki (Create page, rename page, AWM-generated entries, etc). That’s mostly what I meant by 1) below. But for me this is not enough we also need to show the generated URL in the create page UI for example and that’s 2). Right now we don’t have an agreement from all xwiki devs that they’re ok to go with showing the generated URL hence the UIXP idea. If everyone agrees then the problem goes away and it can be built in the default UIs. There’s still the question of allowing the user to edit the last part of the URL but let’s consider it as a detail FTM.
The proposed first point, to have component and a script service for converting strings to url-friendly strings, is the must have. This is what I strongly agree about. And it should provide some configuration in xwiki and it should take into account the language in which the page is being created. The speakingurl, aforementioned solution, works with language and provides quite a lot of customization.
Yep.
Then this script service could be directly used in createinline.vm and other .vm files. Don't know about generally solving url-friendly thing in the custom applications.
Thanks -Vincent
Best regards Miroslav Galajda
On 21 April 2017 at 16:45, Vincent Massol <[email protected]> wrote:
On 21 Apr 2017, at 16:19, Miroslav Galajda <[email protected]> wrote:
Hi, the slugify is different component than speakingurl, but currently it doesn't matter on this.
Ok, how would we solve this globally? Not only in default page creation process but also in custom applications, that create pages in their own. For example the FAQ uses this code to redirect to new FAQ page after entering question name: #set ($newFAQReference = $services.model.createDocumentReference('', '', "$question")) $response.sendRedirect($xwiki.getURL($newFAQReference, 'inline', "$!{request.queryString}&title=${escapetool.url($question)}"))
The solution you propose will be transparent for this code or will it require som modifications?
My proposal is to do 2 things:
1) Introduce some new Component in XWiki Platform. I don’t know where. It could be inside some existing modules in https://github.com/xwiki/ xwiki-platform/tree/master/xwiki-platform-core or introduce a new one in there.
So a Component + a Script Service so that it can be accessed from wiki pages inside scripts (velocity, groovy, etc).
This should cater for the need to be able to use it from anywhere.
It’s basically a clean up/transformation of String into something human-readable.
2) Introduce a UIXP inside createinline.vm to allow extenders to contribute some sections in the Create UI. Actually the current “Location” section could even be refactored to be implemented using a UIX for this UIXP. Several UIX could be contributed with an order and they’d appear in the defined order.
For more on UIXP, see http://extensions.xwiki.org/ xwiki/bin/view/Extension/UIExtension%20Module and to see existing ones see http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/
3) You could then implement an optional UIX to introduce a new URL section that would use 1) to display what URL would be used for example. It could also let the user modify the last part of the URL.
What I haven’t thought about yet is how this UIX will pass back the document name to createinline.vm. Maybe these UIX would be allowed to modify variables in the Velocity/Script context and that would be enough.
It probably needs to be brainstormed a bit more but this is the idea I have so far. I’d also like to have @Caty’s POV on the UI aspect/Layout of such a UIXP concept.
WDYT Miroslav?
Thanks -Vincent
On 21 April 2017 at 16:00, Vincent Massol <[email protected]> wrote:
On 21 Apr 2017, at 15:36, Miroslav Galajda <[email protected]
wrote:
Hi, the solution I've described is javascript based and runs on
client-side.
From what I know, the component-based solution, which you propose, would require to have url-friendly conversion component usable in java and not as javascript code. Am I right?
Yes you’re right but:
1) There’s also a Java API, see https://github.com/slugify/slugify 2) If we also offer a UIX then it can be implemented in a wiki page for example and you can use JS.
Thanks -Vincent
On 21 April 2017 at 15:28, Vincent Massol <[email protected]> wrote:
Hi Miroslav,
> On 21 Apr 2017, at 15:05, Miroslav Galajda < [email protected]
wrote: > > Hi, let me enter into this conversion. > Some time ago I've asked for help how to solve problem with diacritics (or > accents) in page names when creating new pages so that the have > url-friendly names. You can search for "strip accents from page > name used > in url" in xwiki users mailing list. I've got no hint or > solution from > xwiki community till today. > > I've come with solution that ensures for simple users, creating > url-friendly names without requiring them to think about the > concept of the > page name or page title. They simple enter the desired human > readably page > name, and in the code behind of the page creation, I have made > some modifications in createinline.vm to hook into page creation process. The > modifications are mainly javascript based, where I've attache to submit > event of the "form#create", where I replace the entered "title" > with the > one for url-friendly. And for url-friendly name I've used this javascript > based solution on https://pid.github.io/speakingurl/. > I've integrated this principle also into page creation process > of FAQ and > Blog applications, which we are using in our xwiki installation. > > It would be nice if you could integrate this principle into > xwiki so that > everyone can have nice url-friendly urls without worring about > it. It is > also suitable for english speaking users. You don't have to > worry about > entering spaces or other non-url allowed characters, which make > url look > ugly.
That looks very nice!
One way forward I could think about: * We provide some Create script service to return a URL-friendly string. We introduce a component role for this. We refactor createinline.vm to use it and to display the URL. * You could then contribute your code as an extension that we make available on extensions.xwiki.org for users to install * We decide later on if we want to bundle it by default
If we don’t agree about displaying the URL by default all the time then an option is to introduce a UIX in createinline.vm for that. And this could be implemented in your extension too for example or by default in XWiki (possibly with an Admin setting).
WDYT?
Thanks -Vincent
> > Thank you > > Best regards > Miroslav Galajda > > On 21 April 2017 at 14:02, Vincent Massol <[email protected]> wrote: > >> >>> On 21 Apr 2017, at 13:52, Marius Dumitru Florea < >> [email protected]> wrote: >>> >>> On Fri, Apr 21, 2017 at 2:16 PM, Vincent Massol < [email protected]> >> wrote: >>> >>>> Hi Caty, >>>> >>>>> On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) < [email protected] >>> >>>> wrote: >>>>> >>>>> Let's see what variants we have: >>>>> >>>>> 1. Instead of displaying "Title", display the "Name" instead. >>>>> This won't solve anything. There is no difference between >>>>> Page Name and >>>>> Page Title for the normal users. Seeing "Name" instead of "Title", will >>>> not >>>>> stop the users to enter spaces if they want, so the URL will still have >>>>> those spaces. We don't force the Page Names to trim spaces. >>>>> >>>>> One quick solution here is indeed to use "URL" label instead >>>>> of "Name". >>>> For >>>>> the reasons Vincent mentioned this might not end up in the product for >>>> now, >>>> >>>> What did I mention? :) What’s preventing us from having it in >>>> the >> product >>>> rather soon than later (except workload ofc)? >>>> >>>>> so you will need to do some custom development (changing >>>>> some >>>> translations) >>>>> to have this change. If you want to be "hackish" you can >>>>> even change >> the >>>>> translation for "Title" to "URL" instead and hope that your >>>>> users will >>>>> enter shorter URLs (since we generate the name from the title). >>>>> >>>>> Displaying just Name / URL, means users will still have to >>>>> go and >> change >>>>> the title manually. >>>> >>>> This could be better (with URL name) since when you create a >>>> page you’re >>>> offered the ability to change the title after you click Create. >>>> >>>>> The only way to cut a step in the flow is to autogenerate >>>>> the page names (which we currently do). But for your use >>>> case >>>>> you shoyld write a shorting/trimming algorithm, but this is custom, >> since >>>>> you mentioned you want just the initials and no spaces, etc. >>>>> >>>>> 2. Displaying both "Title" and "Name". This will create >>>>> confusion and >>>> need >>>>> for explanations. >>>> >>>> This is not exactly what is suggested either by Vishal nor by >>>> me :) What >>>> we suggested is to let the user enter the URL name and title. >>>> >>>> Actually and to be more precise what I was suggesting was to continue to >>>> let the user enter the title but to show the generated URL as >>>> it’s done >> in >>>> AWM. And, importantly to allow the user to change the last >>>> part of the >> URL >>>> (it would change the page name). >>>> >>>>> That's why we display these options just for advanced and >>>>> long-time users of XWiki, since they are used to the concepts. >>>> >>>> >>> >>>> Yes but URLs don't need an advanced user to understand the >>>> concept and I >>>> agree with Vishal that we’re now causing a very large number >>>> of pages to >>>> have %25 in their URLs by default which is quite bad… Of >>>> course someone >> can >>>> spend their time monitoring what users are doing and renaming pages >>>> thereafter or educate their users to do that but we’re not >>>> helping and >>>> we’re making it difficult. >>>> >>> >>> If your web site is not in English then you're forced to use special >>> characters like diacritics which makes it hard to avoid URL >>> encoded characters (the browser location bar displays the URL >>> nicely but if you >>> copy the URL the result is not nice). >> >> Agreed. So I’d say it’s even more important to allow the user >> to be able >> to easily view and change the resulting URL when they’re not in English. >> >> Thanks >> -Vincent >> >>> >>> >>>> >>>>> ----- >>>>> >>>>> IMO what you are describing is advanced user behavior. >>>>> Normal users >> don't >>>>> generally care about their URLs and SEO. >>>> >>>> I don’t fully agree with you. I have the feeling (can’t prove >>>> it) that a >>>> good number of our users care about the generated URLs. >>>> >>> >>>> Also I think that simple users may care about URL without >>>> being advanced >>>> users. Making them advanced users will expose them to a lot >>>> more >> complexity >>>> than they need to know. >>>> >>>>> But the beauty of XWiki is that you can customize it locally >>>>> to perfectly match your needs. >>>> >>>> That’s not exactly true (and it’s far from being easy, just >>>> check >>>> createinline.vm): It means overriding large portions of vm >>>> code and >> having >>>> to do manual merges whenever you upgrade. A major PITA. >>>> >>>>> Vincent mentioned something about AWM. I don't see much difference from >>>> the >>>>> Create Page. We generate the names from title here too. We display them >>>> in >>>>> the breadcrumb, but in a more simple way. Displaying the >>>> "localhost"/server >>>>> part is not simple user behavior. AWM is more complex. >>>>> >>>>> ----- >>>>> >>>>> So I would not change anything on the product side, since I believe >> these >>>>> should be solved as custom changes for your instance. >>>>> We want to encourage users to use page titles (with spaces >>>>> in them >> since >>>>> they are more readable and supported), while we are >>>>> preserving the page >>>>> name behavior for advances users (but we don't enforce it). >>>> >>>> I don’t agree with this sentence: We definitely don’t want to encourage >>>> users to use titles in URLs. >>>> >>>>> If users made >>>>> mistakes they can always change the title or rename the page. >>>>> On the product side the only change I would like us to do is using the >>>> URL >>>>> naming, but this was debated in the past and dropped for Vincent's >>>> reasons. >>>> >>>> What reasons, I don’t remember a discussion about using URL >>>> name instead >>>> of page name? >>>> >>>> So our main disagreement is that I consider that favouring >>>> encoded characters in URLs is not a good thing while you >>>> think it’s not a large >>>> enough problem to do something about it. >>>> >>>> Would it make our UI too complex to use for simple users if >>>> we were >>>> showing a URL and the ability to change the last part of it? >>>> IMO what’s >>>> complex is when we have Page name and Page Title. But I don’t >>>> feel >> there’d >>>> be confusion between URL and Page title. >>>> >>>> What do others think? >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> >>>>> Thanks, >>>>> Caty >>>>> >>>>> >>>>> On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol < [email protected] > >>>> wrote: >>>>> >>>>>> >>>>>>> On 20 Apr 2017, at 22:51, Vincent Massol >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> Hi Vishal, >>>>>>> >>>>>>> Ok, I misunderstood you in your first email. I understood >>>>>>> the >> opposite. >>>>>> I thought you were complaining that have 2 notions (page >>>>>> name + page >>>> title) >>>>>> was confusing but it’s actually the opposite! What you find confusing >> is >>>>>> the fact that it’s not easy for your users to set both the >>>>>> page name >> and >>>>>> page titles! >>>>>>> >>>>>>> It’s funny (or not :)) since this is exactly what we had >>>>>>> in past >>>>>> versions of XWiki and we had several complaints that it was confusing >> to >>>>>> have the 2 notions and this is why he hid the page name >>>>>> only for >>>> advanced >>>>>> users. >>>>>> >>>>>> Actually, if I remember well, what we were doing was to ask >>>>>> for the >> page >>>>>> name and we were setting the title to the same as the page >>>>>> name by >>>> default >>>>>> and then the user could edit the title before saving the page. >>>>>> >>>>>> We’ve now done the opposite (user deciding on the title and >>>>>> page name >>>>>> being derived from it) but leading to the issue you’re >>>>>> raising about >> URL >>>>>> SEO… >>>>>> >>>>>> Thanks >>>>>> -Vincent >>>>>> >>>>>>> See below. >>>>>>> >>>>>>>> On 20 Apr 2017, at 14:20, Vishal >>>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> Thanks Vincent for your thorough reply.. >>>>>>>> You guessed it right. We intend to have clean and short >>>>>>>> urls for SEO >>>>>>>> reasons. >>>>>>>> Current scheme creates two problems: >>>>>>>> >>>>>>>> 1) The Page name is fetched automatically from the Title. Often the >>>>>> titles >>>>>>>> have spaces which translate as *percent characters *in >>>>>>>> url which >> makes >>>>>> it >>>>>>>> somewhat unclean :) >>>>>>> >>>>>>> Indeed you’re right. By hiding the page name we’re now incitating to >>>>>> have longer URLs and encoded characters showing up in URLs >>>>>> which is >> not >>>>>> nice I agree. >>>>>>> >>>>>>> Maybe one solution is to do something similar to what we >>>>>>> do in AWM, >>>> i.e. >>>>>> generate automatically the URL from the title entered by >>>>>> the user and >>>> show >>>>>> the resulting URL to the user and give the user the >>>>>> opportunity to >>>> change >>>>>> the URL. >>>>>>> >>>>>>> See >>>>>>> http://extensions.xwiki.org/xwiki/bin/download/Extension/ >>>>>> App%20Within%20Minutes%20Application/AppWithinMinutes-Step1 >>>>>> .png >>>>>>> >>>>>>>> 2) Secondly, to have the shorter url, we use only the >>>>>>>> short forms of >>>>>>>> complete title. >>>>>>>> Ex. For title 'Pune University' we use name PU. >>>>>>> >>>>>>> Hey, you’re from Pune? :) I’ve been there about 15 times! >>>>>>> That was >> in a >>>>>> previous job where my company and KPIT Cummins were partners. >>>>>>> >>>>>>>> Otherwise in this hierarchy of pages, the url would be >>>>>>>> much longer. >>>>>>>> Ex. We have page 'Electronics and Telecommunications' >>>>>>>> branch under >>>> page >>>>>>>> 'Pune University'. We should not have such a long url. >>>>>>>> Instead here >> we >>>>>> need >>>>>>>> PU/ENTC or Pune-University/ENTC >>>>>>>> >>>>>>>> To avoid all this, what we currently do: >>>>>>>> 1) On create page dialog, use PU as title.. This will >>>>>>>> create url as >>>> PU. >>>>>>>> If full name is used here as title, we need to use - >>>>>>>> instead of >> spaces >>>>>> to >>>>>>>> avoid percent characters in url. >>>>>>>> 2) While in edit mode, change the title back to Pune University. >>>> Remove >>>>>> any >>>>>>>> - characters to make title clean. >>>>>>>> This is where confusion creeps in. >>>>>>>> >>>>>>>> If these two terms create confusion, why I need to show >>>>>>>> them both: >>>>>>>> I guess the *confusion is due to term Name*. It doesn't reflect >> actual >>>>>> usage >>>>>>>> of the term. URL or weblink or link or web address would >>>>>>>> be more apt >>>>>> terms >>>>>>>> to use to instead of Name. >>>>>>> >>>>>>> Regarding Page name vs Page URL. >>>>>>> >>>>>>> A bit of history: The reason we used page name and not >>>>>>> page URL >>>>>> originally is because what the user is creating is a >>>>>> document in the >>>>>> database and initially it was called Document Name. Since >>>>>> that was a >> bit >>>>>> confusing for users, we had decided to call it Page Name. >>>>>> It just >>>> happened >>>>>> that the URL used was directly derived from the >>>>>> document/page name. >>>>>>> >>>>>>> In practice the 3 concepts could have different values: >>>>>>> * a value for the document’s name in the DB >>>>>>> * another value for the document’s title >>>>>>> * yet another value used in the URL. >>>>>>> >>>>>>> We’ve had discussions so that we could let the user >>>>>>> provide shorter >>>> URLs >>>>>> for pages in the future. >>>>>>> >>>>>>> Now for the time being and since we don’t have this ATM, I think I >>>> agree >>>>>> with you that we could decide to display to the user the >>>>>> URL that will >>>> be >>>>>> generated (the encoded URL) and allow the user to change it. >> Internally >>>> the >>>>>> user would change the document name. >>>>>>> >>>>>>>> My users can differentiate between Title and URL. But the whole >>>>>> procedure we >>>>>>>> follow is certainly not understandable by all. And we definitely >> need >>>> to >>>>>>>> follow this whole long procedure, just to have short and >>>>>>>> clean urls. >>>>>>> >>>>>>> Yes, if you’re asking your users to care about the URLs >>>>>>> that get >>>>>> generated, right now they need to be advanced users to be >>>>>> able to edit >>>> the >>>>>> page name in the Create Page UI (since changing the title afterwards >> is >>>> too >>>>>> cumbersome). >>>>>>> >>>>>>>> So, by showing both fields at the first place itself, I >>>>>>>> would like >> to >>>>>>>> shorten the procedure and url length. >>>>>>> >>>>>>> I’m in agreement with you. Let’s see what others think. >>>>>>> >>>>>>> Thanks for this interesting discussion! >>>>>>> -Vincent >>>>>>> >>>>>>>> -- >>>>>>>> View this message in context: http://xwiki.475771.n2.nabble. >>>>>> com/Page-Title-and-Name-confusion-tp7603546p7603551.html >>>>>>>> Sent from the XWiki- Users mailing list archive at Nabble.com. >> >>
Hi Mahomed/all,
On 21 Apr 2017, at 19:02, Mahomed Hussein <[email protected]> wrote:
I was just mocking up some samples of my recommendation (which I think possibly lines up with Vincent's points 2 and 3), when I realised that there already exists the UI to edit the Page URL. It's just not called that and I didn't remember seeing it. But I see that's probably what Caty was referring to :-)
Yep, that’s available for advanced users only, see: http://platform.xwiki.org/xwiki/bin/view/Features/DocumentLifecycle#HByusing...
I feel like I am just catching up to the conversation :-)
So just to re-cap
1) You can currently edit the location, but this is only for advanced users. (Maybe this can be a Wiki-wide setting instead of being tied to advanced users, even if it can only be set in the config file - screenshot https://snag.gy/vS4f3j.jpg). Personally I don't see why this needs to be an advanced user only feature, because if a user can create a page and decide what its parent page is, why can't they decide on the URL name? A wiki-wide setting will allow the Admin to make this decision on an all or nothing basis (rather than just the "nothing" option we have now).
The reason it’s advanced was explained in this thread earlier on. In short Page name and Page title were too confusing. As I mentioned if rename Page name into Page URL, I feel it would be less confusing for users and we could remove the need to be advanced user.
2) The word "Name" and the description "Name of the new page" are not very clear. (I have made a recommendation in this screenshot - https://snag.gy/dlUK96.jpg)
Yes, it’s better. I would go further and display the generated URL in the UI as we do for AWM (see http://extensions.xwiki.org/xwiki/bin/download/Extension/App%20Within%20Minu...). I would also display the last part of the URL in an input text so that the user can change it simply. Thus without being an advanced user. I would keep the pencil icon for advanced users and maybe even keep the page name field there but have it in sync with the URL to show that the page name is used in the URL (again only for advanced users).
3) I love the speakingurl suggestion and I hope you do implement it. I think it will give the best of both worlds. It will generate nicer URLs.
It may generate nicer urls but they’re not perfect either. They’re a bit longish from what I see and IMO we still need to give more control to the user if they want shorter URLs for example.
I also agree with Vincent, many of the users *do* care about the URL. For example, we share URLs in emails and chat etc. and cross reference in documentation. This is one of the many uses where a nice URL is actually useful.
Slightly off-topic, it's nice to see you (the XWiki devs) actually taking this seriously and discussing it here. It's very refreshing. So just wanted to say thanks for that.
Cool :) I’d love to see more xwiki devs provide their opinion! Thanks -Vincent
Kind regards,
Mahomed Hussein Custodian Data Centre Email: [email protected] http://www.CustodianDC.com
-----Original Message----- From: users [mailto:[email protected]] On Behalf Of Vincent Massol Sent: 21 April 2017 16:56 To: XWiki Users <[email protected]> Subject: Re: [xwiki-users] display page title and name(url) while creating a page
Hi again,
On 21 Apr 2017, at 17:33, Miroslav Galajda <[email protected]> wrote:
Hi,
this seems to be quite complicated and not complete. This url-friendly problem does arise not only in page creation process but also in page renaming.
The other thing is that custom applications that are creating pages would require to use different approax and will need to be customized separately. The UIXP doesn't seems to solve the problem globally and I think currently this is not the main/core part of the problem.
I would like if this was built-in and deeply integrated into xwiki and not to have it "only" optional. This is probably hard to quickly find the solution right now. As I said, the best solution would be built-in support such that it will transparently replace user-entered page name with URL-friendly name.
Yes there are 2 aspects. The built-in part is easy by doing 1) and having a default implementation that doesn’t do any transformation. Then an extension can contribute a new component overriding the default one to use a different algorithm.
And this new API can be used in different places of XWiki (Create page, rename page, AWM-generated entries, etc).
That’s mostly what I meant by 1) below.
But for me this is not enough we also need to show the generated URL in the create page UI for example and that’s 2).
Right now we don’t have an agreement from all xwiki devs that they’re ok to go with showing the generated URL hence the UIXP idea.
If everyone agrees then the problem goes away and it can be built in the default UIs. There’s still the question of allowing the user to edit the last part of the URL but let’s consider it as a detail FTM.
The proposed first point, to have component and a script service for converting strings to url-friendly strings, is the must have. This is what I strongly agree about. And it should provide some configuration in xwiki and it should take into account the language in which the page is being created. The speakingurl, aforementioned solution, works with language and provides quite a lot of customization.
Yep.
Then this script service could be directly used in createinline.vm and other .vm files. Don't know about generally solving url-friendly thing in the custom applications.
Thanks -Vincent
Best regards Miroslav Galajda
On 21 April 2017 at 16:45, Vincent Massol <[email protected]> wrote:
On 21 Apr 2017, at 16:19, Miroslav Galajda <[email protected]> wrote:
Hi, the slugify is different component than speakingurl, but currently it doesn't matter on this.
Ok, how would we solve this globally? Not only in default page creation process but also in custom applications, that create pages in their own. For example the FAQ uses this code to redirect to new FAQ page after entering question name: #set ($newFAQReference = $services.model.createDocumentReference('', '', "$question")) $response.sendRedirect($xwiki.getURL($newFAQReference, 'inline', "$!{request.queryString}&title=${escapetool.url($question)}"))
The solution you propose will be transparent for this code or will it require som modifications?
My proposal is to do 2 things:
1) Introduce some new Component in XWiki Platform. I don’t know where. It could be inside some existing modules in https://github.com/xwiki/ xwiki-platform/tree/master/xwiki-platform-core or introduce a new one in there.
So a Component + a Script Service so that it can be accessed from wiki pages inside scripts (velocity, groovy, etc).
This should cater for the need to be able to use it from anywhere.
It’s basically a clean up/transformation of String into something human-readable.
2) Introduce a UIXP inside createinline.vm to allow extenders to contribute some sections in the Create UI. Actually the current “Location” section could even be refactored to be implemented using a UIX for this UIXP. Several UIX could be contributed with an order and they’d appear in the defined order.
For more on UIXP, see http://extensions.xwiki.org/ xwiki/bin/view/Extension/UIExtension%20Module and to see existing ones see http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/
3) You could then implement an optional UIX to introduce a new URL section that would use 1) to display what URL would be used for example. It could also let the user modify the last part of the URL.
What I haven’t thought about yet is how this UIX will pass back the document name to createinline.vm. Maybe these UIX would be allowed to modify variables in the Velocity/Script context and that would be enough.
It probably needs to be brainstormed a bit more but this is the idea I have so far. I’d also like to have @Caty’s POV on the UI aspect/Layout of such a UIXP concept.
WDYT Miroslav?
Thanks -Vincent
On 21 April 2017 at 16:00, Vincent Massol <[email protected]> wrote:
On 21 Apr 2017, at 15:36, Miroslav Galajda <[email protected]
wrote:
Hi, the solution I've described is javascript based and runs on
client-side.
From what I know, the component-based solution, which you propose, would require to have url-friendly conversion component usable in java and not as javascript code. Am I right?
Yes you’re right but:
1) There’s also a Java API, see https://github.com/slugify/slugify 2) If we also offer a UIX then it can be implemented in a wiki page for example and you can use JS.
Thanks -Vincent
On 21 April 2017 at 15:28, Vincent Massol <[email protected]> wrote:
> Hi Miroslav, > >> On 21 Apr 2017, at 15:05, Miroslav Galajda < [email protected]
> wrote: >> >> Hi, let me enter into this conversion. >> Some time ago I've asked for help how to solve problem with diacritics > (or >> accents) in page names when creating new pages so that the have >> url-friendly names. You can search for "strip accents from page >> name used >> in url" in xwiki users mailing list. I've got no hint or >> solution from >> xwiki community till today. >> >> I've come with solution that ensures for simple users, creating >> url-friendly names without requiring them to think about the >> concept of > the >> page name or page title. They simple enter the desired human >> readably > page >> name, and in the code behind of the page creation, I have made >> some modifications in createinline.vm to hook into page creation process. The >> modifications are mainly javascript based, where I've attache to submit >> event of the "form#create", where I replace the entered "title" >> with the >> one for url-friendly. And for url-friendly name I've used this javascript >> based solution on https://pid.github.io/speakingurl/. >> I've integrated this principle also into page creation process >> of FAQ and >> Blog applications, which we are using in our xwiki installation. >> >> It would be nice if you could integrate this principle into >> xwiki so that >> everyone can have nice url-friendly urls without worring about >> it. It is >> also suitable for english speaking users. You don't have to >> worry about >> entering spaces or other non-url allowed characters, which make >> url look >> ugly. > > That looks very nice! > > One way forward I could think about: > * We provide some Create script service to return a URL-friendly string. > We introduce a component role for this. We refactor > createinline.vm to use > it and to display the URL. > * You could then contribute your code as an extension that we > make available on extensions.xwiki.org for users to install > * We decide later on if we want to bundle it by default > > If we don’t agree about displaying the URL by default all the > time then an > option is to introduce a UIX in createinline.vm for that. And > this could be > implemented in your extension too for example or by default in > XWiki (possibly with an Admin setting). > > WDYT? > > Thanks > -Vincent > >> >> Thank you >> >> Best regards >> Miroslav Galajda >> >> On 21 April 2017 at 14:02, Vincent Massol <[email protected]> wrote: >> >>> >>>> On 21 Apr 2017, at 13:52, Marius Dumitru Florea < >>> [email protected]> wrote: >>>> >>>> On Fri, Apr 21, 2017 at 2:16 PM, Vincent Massol < [email protected]> >>> wrote: >>>> >>>>> Hi Caty, >>>>> >>>>>> On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) < > [email protected] >>>> >>>>> wrote: >>>>>> >>>>>> Let's see what variants we have: >>>>>> >>>>>> 1. Instead of displaying "Title", display the "Name" instead. >>>>>> This won't solve anything. There is no difference between >>>>>> Page Name > and >>>>>> Page Title for the normal users. Seeing "Name" instead of "Title", > will >>>>> not >>>>>> stop the users to enter spaces if they want, so the URL will still > have >>>>>> those spaces. We don't force the Page Names to trim spaces. >>>>>> >>>>>> One quick solution here is indeed to use "URL" label instead >>>>>> of > "Name". >>>>> For >>>>>> the reasons Vincent mentioned this might not end up in the product > for >>>>> now, >>>>> >>>>> What did I mention? :) What’s preventing us from having it in >>>>> the >>> product >>>>> rather soon than later (except workload ofc)? >>>>> >>>>>> so you will need to do some custom development (changing >>>>>> some >>>>> translations) >>>>>> to have this change. If you want to be "hackish" you can >>>>>> even change >>> the >>>>>> translation for "Title" to "URL" instead and hope that your >>>>>> users > will >>>>>> enter shorter URLs (since we generate the name from the title). >>>>>> >>>>>> Displaying just Name / URL, means users will still have to >>>>>> go and >>> change >>>>>> the title manually. >>>>> >>>>> This could be better (with URL name) since when you create a >>>>> page > you’re >>>>> offered the ability to change the title after you click Create. >>>>> >>>>>> The only way to cut a step in the flow is to autogenerate >>>>>> the page names (which we currently do). But for your use >>>>> case >>>>>> you shoyld write a shorting/trimming algorithm, but this is custom, >>> since >>>>>> you mentioned you want just the initials and no spaces, etc. >>>>>> >>>>>> 2. Displaying both "Title" and "Name". This will create >>>>>> confusion and >>>>> need >>>>>> for explanations. >>>>> >>>>> This is not exactly what is suggested either by Vishal nor by >>>>> me :) > What >>>>> we suggested is to let the user enter the URL name and title. >>>>> >>>>> Actually and to be more precise what I was suggesting was to continue > to >>>>> let the user enter the title but to show the generated URL as >>>>> it’s > done >>> in >>>>> AWM. And, importantly to allow the user to change the last >>>>> part of the >>> URL >>>>> (it would change the page name). >>>>> >>>>>> That's why we display these options just for advanced and >>>>>> long-time users of XWiki, since they are used to the concepts. >>>>> >>>>> >>>> >>>>> Yes but URLs don't need an advanced user to understand the >>>>> concept > and I >>>>> agree with Vishal that we’re now causing a very large number >>>>> of pages > to >>>>> have %25 in their URLs by default which is quite bad… Of >>>>> course > someone >>> can >>>>> spend their time monitoring what users are doing and renaming pages >>>>> thereafter or educate their users to do that but we’re not >>>>> helping and >>>>> we’re making it difficult. >>>>> >>>> >>>> If your web site is not in English then you're forced to use special >>>> characters like diacritics which makes it hard to avoid URL >>>> encoded characters (the browser location bar displays the URL >>>> nicely but if you >>>> copy the URL the result is not nice). >>> >>> Agreed. So I’d say it’s even more important to allow the user >>> to be able >>> to easily view and change the resulting URL when they’re not in English. >>> >>> Thanks >>> -Vincent >>> >>>> >>>> >>>>> >>>>>> ----- >>>>>> >>>>>> IMO what you are describing is advanced user behavior. >>>>>> Normal users >>> don't >>>>>> generally care about their URLs and SEO. >>>>> >>>>> I don’t fully agree with you. I have the feeling (can’t prove >>>>> it) > that a >>>>> good number of our users care about the generated URLs. >>>>> >>>> >>>>> Also I think that simple users may care about URL without >>>>> being > advanced >>>>> users. Making them advanced users will expose them to a lot >>>>> more >>> complexity >>>>> than they need to know. >>>>> >>>>>> But the beauty of XWiki is that you can customize it locally >>>>>> to perfectly match your needs. >>>>> >>>>> That’s not exactly true (and it’s far from being easy, just >>>>> check >>>>> createinline.vm): It means overriding large portions of vm >>>>> code and >>> having >>>>> to do manual merges whenever you upgrade. A major PITA. >>>>> >>>>>> Vincent mentioned something about AWM. I don't see much difference > from >>>>> the >>>>>> Create Page. We generate the names from title here too. We display > them >>>>> in >>>>>> the breadcrumb, but in a more simple way. Displaying the >>>>> "localhost"/server >>>>>> part is not simple user behavior. AWM is more complex. >>>>>> >>>>>> ----- >>>>>> >>>>>> So I would not change anything on the product side, since I believe >>> these >>>>>> should be solved as custom changes for your instance. >>>>>> We want to encourage users to use page titles (with spaces >>>>>> in them >>> since >>>>>> they are more readable and supported), while we are >>>>>> preserving the > page >>>>>> name behavior for advances users (but we don't enforce it). >>>>> >>>>> I don’t agree with this sentence: We definitely don’t want to > encourage >>>>> users to use titles in URLs. >>>>> >>>>>> If users made >>>>>> mistakes they can always change the title or rename the page. >>>>>> On the product side the only change I would like us to do is using > the >>>>> URL >>>>>> naming, but this was debated in the past and dropped for Vincent's >>>>> reasons. >>>>> >>>>> What reasons, I don’t remember a discussion about using URL >>>>> name > instead >>>>> of page name? >>>>> >>>>> So our main disagreement is that I consider that favouring >>>>> encoded characters in URLs is not a good thing while you >>>>> think it’s not a > large >>>>> enough problem to do something about it. >>>>> >>>>> Would it make our UI too complex to use for simple users if >>>>> we were >>>>> showing a URL and the ability to change the last part of it? >>>>> IMO > what’s >>>>> complex is when we have Page name and Page Title. But I don’t >>>>> feel >>> there’d >>>>> be confusion between URL and Page title. >>>>> >>>>> What do others think? >>>>> >>>>> Thanks >>>>> -Vincent >>>>> >>>>>> >>>>>> Thanks, >>>>>> Caty >>>>>> >>>>>> >>>>>> On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol < [email protected] >> >>>>> wrote: >>>>>> >>>>>>> >>>>>>>> On 20 Apr 2017, at 22:51, Vincent Massol >>>>>>>> <[email protected]> > wrote: >>>>>>>> >>>>>>>> Hi Vishal, >>>>>>>> >>>>>>>> Ok, I misunderstood you in your first email. I understood >>>>>>>> the >>> opposite. >>>>>>> I thought you were complaining that have 2 notions (page >>>>>>> name + page >>>>> title) >>>>>>> was confusing but it’s actually the opposite! What you find > confusing >>> is >>>>>>> the fact that it’s not easy for your users to set both the >>>>>>> page name >>> and >>>>>>> page titles! >>>>>>>> >>>>>>>> It’s funny (or not :)) since this is exactly what we had >>>>>>>> in past >>>>>>> versions of XWiki and we had several complaints that it was > confusing >>> to >>>>>>> have the 2 notions and this is why he hid the page name >>>>>>> only for >>>>> advanced >>>>>>> users. >>>>>>> >>>>>>> Actually, if I remember well, what we were doing was to ask >>>>>>> for the >>> page >>>>>>> name and we were setting the title to the same as the page >>>>>>> name by >>>>> default >>>>>>> and then the user could edit the title before saving the page. >>>>>>> >>>>>>> We’ve now done the opposite (user deciding on the title and >>>>>>> page > name >>>>>>> being derived from it) but leading to the issue you’re >>>>>>> raising about >>> URL >>>>>>> SEO… >>>>>>> >>>>>>> Thanks >>>>>>> -Vincent >>>>>>> >>>>>>>> See below. >>>>>>>> >>>>>>>>> On 20 Apr 2017, at 14:20, Vishal >>>>>>>>> <[email protected]> > wrote: >>>>>>>>> >>>>>>>>> Thanks Vincent for your thorough reply.. >>>>>>>>> You guessed it right. We intend to have clean and short >>>>>>>>> urls for > SEO >>>>>>>>> reasons. >>>>>>>>> Current scheme creates two problems: >>>>>>>>> >>>>>>>>> 1) The Page name is fetched automatically from the Title. Often > the >>>>>>> titles >>>>>>>>> have spaces which translate as *percent characters *in >>>>>>>>> url which >>> makes >>>>>>> it >>>>>>>>> somewhat unclean :) >>>>>>>> >>>>>>>> Indeed you’re right. By hiding the page name we’re now incitating > to >>>>>>> have longer URLs and encoded characters showing up in URLs >>>>>>> which is >>> not >>>>>>> nice I agree. >>>>>>>> >>>>>>>> Maybe one solution is to do something similar to what we >>>>>>>> do in AWM, >>>>> i.e. >>>>>>> generate automatically the URL from the title entered by >>>>>>> the user > and >>>>> show >>>>>>> the resulting URL to the user and give the user the >>>>>>> opportunity to >>>>> change >>>>>>> the URL. >>>>>>>> >>>>>>>> See >>>>>>>> http://extensions.xwiki.org/xwiki/bin/download/Extension/ >>>>>>> App%20Within%20Minutes%20Application/AppWithinMinutes-Step1 >>>>>>> .png >>>>>>>> >>>>>>>>> 2) Secondly, to have the shorter url, we use only the >>>>>>>>> short forms > of >>>>>>>>> complete title. >>>>>>>>> Ex. For title 'Pune University' we use name PU. >>>>>>>> >>>>>>>> Hey, you’re from Pune? :) I’ve been there about 15 times! >>>>>>>> That was >>> in a >>>>>>> previous job where my company and KPIT Cummins were partners. >>>>>>>> >>>>>>>>> Otherwise in this hierarchy of pages, the url would be >>>>>>>>> much > longer. >>>>>>>>> Ex. We have page 'Electronics and Telecommunications' >>>>>>>>> branch under >>>>> page >>>>>>>>> 'Pune University'. We should not have such a long url. >>>>>>>>> Instead > here >>> we >>>>>>> need >>>>>>>>> PU/ENTC or Pune-University/ENTC >>>>>>>>> >>>>>>>>> To avoid all this, what we currently do: >>>>>>>>> 1) On create page dialog, use PU as title.. This will >>>>>>>>> create url > as >>>>> PU. >>>>>>>>> If full name is used here as title, we need to use - >>>>>>>>> instead of >>> spaces >>>>>>> to >>>>>>>>> avoid percent characters in url. >>>>>>>>> 2) While in edit mode, change the title back to Pune University. >>>>> Remove >>>>>>> any >>>>>>>>> - characters to make title clean. >>>>>>>>> This is where confusion creeps in. >>>>>>>>> >>>>>>>>> If these two terms create confusion, why I need to show >>>>>>>>> them both: >>>>>>>>> I guess the *confusion is due to term Name*. It doesn't reflect >>> actual >>>>>>> usage >>>>>>>>> of the term. URL or weblink or link or web address would >>>>>>>>> be more > apt >>>>>>> terms >>>>>>>>> to use to instead of Name. >>>>>>>> >>>>>>>> Regarding Page name vs Page URL. >>>>>>>> >>>>>>>> A bit of history: The reason we used page name and not >>>>>>>> page URL >>>>>>> originally is because what the user is creating is a >>>>>>> document in the >>>>>>> database and initially it was called Document Name. Since >>>>>>> that was a >>> bit >>>>>>> confusing for users, we had decided to call it Page Name. >>>>>>> It just >>>>> happened >>>>>>> that the URL used was directly derived from the >>>>>>> document/page name. >>>>>>>> >>>>>>>> In practice the 3 concepts could have different values: >>>>>>>> * a value for the document’s name in the DB >>>>>>>> * another value for the document’s title >>>>>>>> * yet another value used in the URL. >>>>>>>> >>>>>>>> We’ve had discussions so that we could let the user >>>>>>>> provide shorter >>>>> URLs >>>>>>> for pages in the future. >>>>>>>> >>>>>>>> Now for the time being and since we don’t have this ATM, I think I >>>>> agree >>>>>>> with you that we could decide to display to the user the >>>>>>> URL that > will >>>>> be >>>>>>> generated (the encoded URL) and allow the user to change it. >>> Internally >>>>> the >>>>>>> user would change the document name. >>>>>>>> >>>>>>>>> My users can differentiate between Title and URL. But the whole >>>>>>> procedure we >>>>>>>>> follow is certainly not understandable by all. And we definitely >>> need >>>>> to >>>>>>>>> follow this whole long procedure, just to have short and >>>>>>>>> clean > urls. >>>>>>>> >>>>>>>> Yes, if you’re asking your users to care about the URLs >>>>>>>> that get >>>>>>> generated, right now they need to be advanced users to be >>>>>>> able to > edit >>>>> the >>>>>>> page name in the Create Page UI (since changing the title afterwards >>> is >>>>> too >>>>>>> cumbersome). >>>>>>>> >>>>>>>>> So, by showing both fields at the first place itself, I >>>>>>>>> would like >>> to >>>>>>>>> shorten the procedure and url length. >>>>>>>> >>>>>>>> I’m in agreement with you. Let’s see what others think. >>>>>>>> >>>>>>>> Thanks for this interesting discussion! >>>>>>>> -Vincent >>>>>>>> >>>>>>>>> -- >>>>>>>>> View this message in context: http://xwiki.475771.n2.nabble. >>>>>>> com/Page-Title-and-Name-confusion-tp7603546p7603551.html >>>>>>>>> Sent from the XWiki- Users mailing list archive at Nabble.com. >>> >>> > >
Hi all.. Thanks for taking the issue this much seriously. Hi Vincent..
Hey, you’re from Pune? :) I’ve been there about 15 times! Hey, you are welcome again.. I would expect you to drop me an email while visiting Pune next time :)
Normal users don't generally care about their URLs and SEO. Hi Caty.. You are definitely correct about SEO as simple users don't even know what SEO is. But I am very sure that even simple users do care about URLs. For instance, we share all our educational articles on our wiki in chats, like in WhatsApp, Facebook, Gmail, and what not. And they often ask me to clean the encoded URLs for them. In last 15 days for instance, I had to rename about 250 pages.. I don’t fully agree with you. I have the feeling (can’t prove it) And I guess this is what Vincent felt but couldn't prove.
But for your use case you shoyld write a shorting/trimming algorithm, but this is custom Yes I agree. It should be custom because not all will want such trimming of URLs.
It may generate nicer urls but they’re not perfect either. They’re a bit longish from what I see I think we can't and shouldn't force anyone to have short URLs. Long URL doesn't seem a problem for us, but inability to shorten them in the first place indeed is. I disagree with having any shortening algorithm as even we do use full names in URLs at certain places. e.g. /Pune-University
My Proposal: I strongly agree with Vincent about Create Page UI like AWM. This is what we think will be most user friendly. (Sorry, couldn't upload images but rough layout) *Title: (Tip: Title as shown on Page/Document) [Title Textbox] URL: (Tip: this is a webaddress) [Non editable initial part of URL][Textbox for last part of URL] Location: (Tip: location of page in wiki) [Documents tree/Parent]* In above layout, we could use algorithm at URL section just to make them more readable (removing ecoded characters), nothing else. And it would be nice to have this universally editable, no need of any options like ALWAYS, NEVER, etc. Also no need to restrict it to just advanced users, because mostly users who could create a page would know about URLs. Very much thanks for this wonderful discussion. Regards, Vishal -- View this message in context: http://xwiki.475771.n2.nabble.com/Page-Title-and-Name-confusion-tp7603546p76... Sent from the XWiki- Users mailing list archive at Nabble.com.
Hi, Users can change the URL anytime after the page creation, and that is using the "Rename" action, although I agree that simple users might not really see the connection between Rename, URLs and Titles. So yes it would be ideal to provide the ability to select (reserve) the URL from the creation page step (for steps optimization purposes). Now, some important mention is the use case. From what I can assume from your answers, the majority of you have Wikis / Knowledge Bases. For this flavor the URLs are important and I quite get the need. The issue is for users that use XWiki for Groupware / Applications use case. When your instance is using heavily applications, you don't care about the URL is generating, you don't care about the nesting, etc. We had users that requested to never see the Page Name part and actually the ability to auto-generate the URL with some random numbers that they shouldn't see. That's why the subject is a bit problematic, because some users want to see/alter the Page Name/ URL; while others don't care it exists. I also don't like the configuration proposal, since it's always hard to test all combinations of configurations and we need to decide on the default. Not sure about changing it in the Base Flavor, since not all Flavors users might need it. The UIX could be a solution in order to use it just by some Flavors. What is really interesting and good to know is that indeed the Page Name / URL are important for Knowledge Bases (KB). Still in KBs the content creators are not that many (compared to readers) and they usually are the wiki gardeners, and they tend to be 'advanced' users. The smallest / simplest changes would indeed be in the labels wording and descriptions. Also the 'URL' mention instead of Page Name. Thanks, Caty On Sun, Apr 23, 2017 at 8:23 AM, Vishal <[email protected]> wrote:
Hi all.. Thanks for taking the issue this much seriously.
Hi Vincent..
Hey, you’re from Pune? :) I’ve been there about 15 times! Hey, you are welcome again.. I would expect you to drop me an email while visiting Pune next time :)
Normal users don't generally care about their URLs and SEO. Hi Caty.. You are definitely correct about SEO as simple users don't even know what SEO is. But I am very sure that even simple users do care about URLs. For instance, we share all our educational articles on our wiki in chats, like in WhatsApp, Facebook, Gmail, and what not. And they often ask me to clean the encoded URLs for them. In last 15 days for instance, I had to rename about 250 pages.. I don’t fully agree with you. I have the feeling (can’t prove it) And I guess this is what Vincent felt but couldn't prove.
But for your use case you shoyld write a shorting/trimming algorithm, but this is custom Yes I agree. It should be custom because not all will want such trimming of URLs.
It may generate nicer urls but they’re not perfect either. They’re a bit longish from what I see I think we can't and shouldn't force anyone to have short URLs. Long URL doesn't seem a problem for us, but inability to shorten them in the first place indeed is. I disagree with having any shortening algorithm as even we do use full names in URLs at certain places. e.g. /Pune-University
My Proposal: I strongly agree with Vincent about Create Page UI like AWM. This is what we think will be most user friendly. (Sorry, couldn't upload images but rough layout)
*Title: (Tip: Title as shown on Page/Document) [Title Textbox]
URL: (Tip: this is a webaddress) [Non editable initial part of URL][Textbox for last part of URL]
Location: (Tip: location of page in wiki) [Documents tree/Parent]*
In above layout, we could use algorithm at URL section just to make them more readable (removing ecoded characters), nothing else.
And it would be nice to have this universally editable, no need of any options like ALWAYS, NEVER, etc. Also no need to restrict it to just advanced users, because mostly users who could create a page would know about URLs.
Very much thanks for this wonderful discussion. Regards, Vishal
-- View this message in context: http://xwiki.475771.n2.nabble. com/Page-Title-and-Name-confusion-tp7603546p7603588.html Sent from the XWiki- Users mailing list archive at Nabble.com.
On Fri, Apr 21, 2017 at 8:02 PM, Mahomed Hussein <[email protected]> wrote:
I was just mocking up some samples of my recommendation (which I think possibly lines up with Vincent's points 2 and 3), when I realised that there already exists the UI to edit the Page URL. It's just not called that and I didn't remember seeing it. But I see that's probably what Caty was referring to :-)
I feel like I am just catching up to the conversation :-)
So just to re-cap
1) You can currently edit the location, but this is only for advanced users. (Maybe this can be a Wiki-wide setting instead of being tied to advanced users, even if it can only be set in the config file - screenshot https://snag.gy/vS4f3j.jpg). Personally I don't see why this needs to be an advanced user only feature, because if a user can create a page and decide what its parent page is, why can't they decide on the URL name? A wiki-wide setting will allow the Admin to make this decision on an all or nothing basis (rather than just the "nothing" option we have now).
2) The word "Name" and the description "Name of the new page" are not very clear. (I have made a recommendation in this screenshot - https://snag.gy/dlUK96.jpg)
3) I love the speakingurl suggestion and I hope you do implement it. I think it will give the best of both worlds. It will generate nicer URLs. I also agree with Vincent, many of the users *do* care about the URL. For example, we share URLs in emails and chat etc. and cross reference in documentation. This is one of the many uses where a nice URL is actually useful.
Slightly off-topic, it's nice to see you (the XWiki devs) actually taking this seriously and discussing it here. It's very refreshing. So just wanted to say thanks for that.
Off-topic: I'm quite thrilled with the number or replies and opinions on this thread. Maybe we should send / discuss more topics on the users list (we usually discuss the UI proposals/changes on the devs list). Thanks, Caty
Kind regards,
Mahomed Hussein Custodian Data Centre Email: [email protected] http://www.CustodianDC.com
-----Original Message----- From: users [mailto:[email protected]] On Behalf Of Vincent Massol Sent: 21 April 2017 16:56 To: XWiki Users <[email protected]> Subject: Re: [xwiki-users] display page title and name(url) while creating a page
Hi again,
On 21 Apr 2017, at 17:33, Miroslav Galajda <[email protected]> wrote:
Hi,
this seems to be quite complicated and not complete. This url-friendly problem does arise not only in page creation process but also in page renaming.
The other thing is that custom applications that are creating pages would require to use different approax and will need to be customized separately. The UIXP doesn't seems to solve the problem globally and I think currently this is not the main/core part of the problem.
I would like if this was built-in and deeply integrated into xwiki and not to have it "only" optional. This is probably hard to quickly find the solution right now. As I said, the best solution would be built-in support such that it will transparently replace user-entered page name with URL-friendly name.
Yes there are 2 aspects. The built-in part is easy by doing 1) and having a default implementation that doesn’t do any transformation. Then an extension can contribute a new component overriding the default one to use a different algorithm.
And this new API can be used in different places of XWiki (Create page, rename page, AWM-generated entries, etc).
That’s mostly what I meant by 1) below.
But for me this is not enough we also need to show the generated URL in the create page UI for example and that’s 2).
Right now we don’t have an agreement from all xwiki devs that they’re ok to go with showing the generated URL hence the UIXP idea.
If everyone agrees then the problem goes away and it can be built in the default UIs. There’s still the question of allowing the user to edit the last part of the URL but let’s consider it as a detail FTM.
The proposed first point, to have component and a script service for converting strings to url-friendly strings, is the must have. This is what I strongly agree about. And it should provide some configuration in xwiki and it should take into account the language in which the page is being created. The speakingurl, aforementioned solution, works with language and provides quite a lot of customization.
Yep.
Then this script service could be directly used in createinline.vm and other .vm files. Don't know about generally solving url-friendly thing in the custom applications.
Thanks -Vincent
Best regards Miroslav Galajda
On 21 April 2017 at 16:45, Vincent Massol <[email protected]> wrote:
On 21 Apr 2017, at 16:19, Miroslav Galajda <[email protected]> wrote:
Hi, the slugify is different component than speakingurl, but currently it doesn't matter on this.
Ok, how would we solve this globally? Not only in default page creation process but also in custom applications, that create pages in
their own.
For example the FAQ uses this code to redirect to new FAQ page after entering question name: #set ($newFAQReference = $services.model.createDocumentReference('', '', "$question")) $response.sendRedirect($xwiki.getURL($newFAQReference, 'inline', "$!{request.queryString}&title=${escapetool.url($question)}"))
The solution you propose will be transparent for this code or will it require som modifications?
My proposal is to do 2 things:
1) Introduce some new Component in XWiki Platform. I don’t know where. It could be inside some existing modules in https://github.com/xwiki/ xwiki-platform/tree/master/xwiki-platform-core or introduce a new one in there.
So a Component + a Script Service so that it can be accessed from wiki pages inside scripts (velocity, groovy, etc).
This should cater for the need to be able to use it from anywhere.
It’s basically a clean up/transformation of String into something human-readable.
2) Introduce a UIXP inside createinline.vm to allow extenders to contribute some sections in the Create UI. Actually the current “Location” section could even be refactored to be implemented using a UIX for this UIXP. Several UIX could be contributed with an order and they’d appear in the defined order.
For more on UIXP, see http://extensions.xwiki.org/ xwiki/bin/view/Extension/UIExtension%20Module and to see existing ones see http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/
3) You could then implement an optional UIX to introduce a new URL section that would use 1) to display what URL would be used for example. It could also let the user modify the last part of the URL.
What I haven’t thought about yet is how this UIX will pass back the document name to createinline.vm. Maybe these UIX would be allowed to modify variables in the Velocity/Script context and that would be enough.
It probably needs to be brainstormed a bit more but this is the idea I have so far. I’d also like to have @Caty’s POV on the UI aspect/Layout of such a UIXP concept.
WDYT Miroslav?
Thanks -Vincent
On 21 April 2017 at 16:00, Vincent Massol <[email protected]> wrote:
On 21 Apr 2017, at 15:36, Miroslav Galajda <[email protected]
wrote:
Hi, the solution I've described is javascript based and runs on
client-side.
From what I know, the component-based solution, which you propose, would require to have url-friendly conversion component usable in java and not as javascript code. Am I right?
Yes you’re right but:
1) There’s also a Java API, see https://github.com/slugify/slugify 2) If we also offer a UIX then it can be implemented in a wiki page for example and you can use JS.
Thanks -Vincent
On 21 April 2017 at 15:28, Vincent Massol <[email protected]> wrote:
> Hi Miroslav, > >> On 21 Apr 2017, at 15:05, Miroslav Galajda < [email protected]
> wrote: >> >> Hi, let me enter into this conversion. >> Some time ago I've asked for help how to solve problem with diacritics > (or >> accents) in page names when creating new pages so that the have >> url-friendly names. You can search for "strip accents from page >> name used >> in url" in xwiki users mailing list. I've got no hint or >> solution from >> xwiki community till today. >> >> I've come with solution that ensures for simple users, creating >> url-friendly names without requiring them to think about the >> concept of > the >> page name or page title. They simple enter the desired human >> readably > page >> name, and in the code behind of the page creation, I have made >> some modifications in createinline.vm to hook into page creation process. The >> modifications are mainly javascript based, where I've attache to submit >> event of the "form#create", where I replace the entered "title" >> with the >> one for url-friendly. And for url-friendly name I've used this javascript >> based solution on https://pid.github.io/speakingurl/. >> I've integrated this principle also into page creation process >> of FAQ and >> Blog applications, which we are using in our xwiki installation. >> >> It would be nice if you could integrate this principle into >> xwiki so that >> everyone can have nice url-friendly urls without worring about >> it. It is >> also suitable for english speaking users. You don't have to >> worry about >> entering spaces or other non-url allowed characters, which make >> url look >> ugly. > > That looks very nice! > > One way forward I could think about: > * We provide some Create script service to return a URL-friendly string. > We introduce a component role for this. We refactor > createinline.vm to use > it and to display the URL. > * You could then contribute your code as an extension that we > make available on extensions.xwiki.org for users to install > * We decide later on if we want to bundle it by default > > If we don’t agree about displaying the URL by default all the > time then an > option is to introduce a UIX in createinline.vm for that. And > this could be > implemented in your extension too for example or by default in > XWiki (possibly with an Admin setting). > > WDYT? > > Thanks > -Vincent > >> >> Thank you >> >> Best regards >> Miroslav Galajda >> >> On 21 April 2017 at 14:02, Vincent Massol <[email protected]> wrote: >> >>> >>>> On 21 Apr 2017, at 13:52, Marius Dumitru Florea < >>> [email protected]> wrote: >>>> >>>> On Fri, Apr 21, 2017 at 2:16 PM, Vincent Massol < [email protected]> >>> wrote: >>>> >>>>> Hi Caty, >>>>> >>>>>> On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) < > [email protected] >>>> >>>>> wrote: >>>>>> >>>>>> Let's see what variants we have: >>>>>> >>>>>> 1. Instead of displaying "Title", display the "Name" instead. >>>>>> This won't solve anything. There is no difference between >>>>>> Page Name > and >>>>>> Page Title for the normal users. Seeing "Name" instead of "Title", > will >>>>> not >>>>>> stop the users to enter spaces if they want, so the URL will still > have >>>>>> those spaces. We don't force the Page Names to trim spaces. >>>>>> >>>>>> One quick solution here is indeed to use "URL" label instead >>>>>> of > "Name". >>>>> For >>>>>> the reasons Vincent mentioned this might not end up in the product > for >>>>> now, >>>>> >>>>> What did I mention? :) What’s preventing us from having it in >>>>> the >>> product >>>>> rather soon than later (except workload ofc)? >>>>> >>>>>> so you will need to do some custom development (changing >>>>>> some >>>>> translations) >>>>>> to have this change. If you want to be "hackish" you can >>>>>> even change >>> the >>>>>> translation for "Title" to "URL" instead and hope that your >>>>>> users > will >>>>>> enter shorter URLs (since we generate the name from the title). >>>>>> >>>>>> Displaying just Name / URL, means users will still have to >>>>>> go and >>> change >>>>>> the title manually. >>>>> >>>>> This could be better (with URL name) since when you create a >>>>> page > you’re >>>>> offered the ability to change the title after you click Create. >>>>> >>>>>> The only way to cut a step in the flow is to autogenerate >>>>>> the page names (which we currently do). But for your use >>>>> case >>>>>> you shoyld write a shorting/trimming algorithm, but this is custom, >>> since >>>>>> you mentioned you want just the initials and no spaces, etc. >>>>>> >>>>>> 2. Displaying both "Title" and "Name". This will create >>>>>> confusion and >>>>> need >>>>>> for explanations. >>>>> >>>>> This is not exactly what is suggested either by Vishal nor by >>>>> me :) > What >>>>> we suggested is to let the user enter the URL name and title. >>>>> >>>>> Actually and to be more precise what I was suggesting was to continue > to >>>>> let the user enter the title but to show the generated URL as >>>>> it’s > done >>> in >>>>> AWM. And, importantly to allow the user to change the last >>>>> part of the >>> URL >>>>> (it would change the page name). >>>>> >>>>>> That's why we display these options just for advanced and >>>>>> long-time users of XWiki, since they are used to the concepts. >>>>> >>>>> >>>> >>>>> Yes but URLs don't need an advanced user to understand the >>>>> concept > and I >>>>> agree with Vishal that we’re now causing a very large number >>>>> of pages > to >>>>> have %25 in their URLs by default which is quite bad… Of >>>>> course > someone >>> can >>>>> spend their time monitoring what users are doing and renaming pages >>>>> thereafter or educate their users to do that but we’re not >>>>> helping and >>>>> we’re making it difficult. >>>>> >>>> >>>> If your web site is not in English then you're forced to use special >>>> characters like diacritics which makes it hard to avoid URL >>>> encoded characters (the browser location bar displays the URL >>>> nicely but if you >>>> copy the URL the result is not nice). >>> >>> Agreed. So I’d say it’s even more important to allow the user >>> to be able >>> to easily view and change the resulting URL when they’re not in English. >>> >>> Thanks >>> -Vincent >>> >>>> >>>> >>>>> >>>>>> ----- >>>>>> >>>>>> IMO what you are describing is advanced user behavior. >>>>>> Normal users >>> don't >>>>>> generally care about their URLs and SEO. >>>>> >>>>> I don’t fully agree with you. I have the feeling (can’t prove >>>>> it) > that a >>>>> good number of our users care about the generated URLs. >>>>> >>>> >>>>> Also I think that simple users may care about URL without >>>>> being > advanced >>>>> users. Making them advanced users will expose them to a lot >>>>> more >>> complexity >>>>> than they need to know. >>>>> >>>>>> But the beauty of XWiki is that you can customize it locally >>>>>> to perfectly match your needs. >>>>> >>>>> That’s not exactly true (and it’s far from being easy, just >>>>> check >>>>> createinline.vm): It means overriding large portions of vm >>>>> code and >>> having >>>>> to do manual merges whenever you upgrade. A major PITA. >>>>> >>>>>> Vincent mentioned something about AWM. I don't see much difference > from >>>>> the >>>>>> Create Page. We generate the names from title here too. We display > them >>>>> in >>>>>> the breadcrumb, but in a more simple way. Displaying the >>>>> "localhost"/server >>>>>> part is not simple user behavior. AWM is more complex. >>>>>> >>>>>> ----- >>>>>> >>>>>> So I would not change anything on the product side, since I believe >>> these >>>>>> should be solved as custom changes for your instance. >>>>>> We want to encourage users to use page titles (with spaces >>>>>> in them >>> since >>>>>> they are more readable and supported), while we are >>>>>> preserving the > page >>>>>> name behavior for advances users (but we don't enforce it). >>>>> >>>>> I don’t agree with this sentence: We definitely don’t want to > encourage >>>>> users to use titles in URLs. >>>>> >>>>>> If users made >>>>>> mistakes they can always change the title or rename the page. >>>>>> On the product side the only change I would like us to do is using > the >>>>> URL >>>>>> naming, but this was debated in the past and dropped for Vincent's >>>>> reasons. >>>>> >>>>> What reasons, I don’t remember a discussion about using URL >>>>> name > instead >>>>> of page name? >>>>> >>>>> So our main disagreement is that I consider that favouring >>>>> encoded characters in URLs is not a good thing while you >>>>> think it’s not a > large >>>>> enough problem to do something about it. >>>>> >>>>> Would it make our UI too complex to use for simple users if >>>>> we were >>>>> showing a URL and the ability to change the last part of it? >>>>> IMO > what’s >>>>> complex is when we have Page name and Page Title. But I don’t >>>>> feel >>> there’d >>>>> be confusion between URL and Page title. >>>>> >>>>> What do others think? >>>>> >>>>> Thanks >>>>> -Vincent >>>>> >>>>>> >>>>>> Thanks, >>>>>> Caty >>>>>> >>>>>> >>>>>> On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol < [email protected] >> >>>>> wrote: >>>>>> >>>>>>> >>>>>>>> On 20 Apr 2017, at 22:51, Vincent Massol >>>>>>>> <[email protected]> > wrote: >>>>>>>> >>>>>>>> Hi Vishal, >>>>>>>> >>>>>>>> Ok, I misunderstood you in your first email. I understood >>>>>>>> the >>> opposite. >>>>>>> I thought you were complaining that have 2 notions (page >>>>>>> name + page >>>>> title) >>>>>>> was confusing but it’s actually the opposite! What you find > confusing >>> is >>>>>>> the fact that it’s not easy for your users to set both the >>>>>>> page name >>> and >>>>>>> page titles! >>>>>>>> >>>>>>>> It’s funny (or not :)) since this is exactly what we had >>>>>>>> in past >>>>>>> versions of XWiki and we had several complaints that it was > confusing >>> to >>>>>>> have the 2 notions and this is why he hid the page name >>>>>>> only for >>>>> advanced >>>>>>> users. >>>>>>> >>>>>>> Actually, if I remember well, what we were doing was to ask >>>>>>> for the >>> page >>>>>>> name and we were setting the title to the same as the page >>>>>>> name by >>>>> default >>>>>>> and then the user could edit the title before saving the page. >>>>>>> >>>>>>> We’ve now done the opposite (user deciding on the title and >>>>>>> page > name >>>>>>> being derived from it) but leading to the issue you’re >>>>>>> raising about >>> URL >>>>>>> SEO… >>>>>>> >>>>>>> Thanks >>>>>>> -Vincent >>>>>>> >>>>>>>> See below. >>>>>>>> >>>>>>>>> On 20 Apr 2017, at 14:20, Vishal >>>>>>>>> <[email protected]> > wrote: >>>>>>>>> >>>>>>>>> Thanks Vincent for your thorough reply.. >>>>>>>>> You guessed it right. We intend to have clean and short >>>>>>>>> urls for > SEO >>>>>>>>> reasons. >>>>>>>>> Current scheme creates two problems: >>>>>>>>> >>>>>>>>> 1) The Page name is fetched automatically from the Title. Often > the >>>>>>> titles >>>>>>>>> have spaces which translate as *percent characters *in >>>>>>>>> url which >>> makes >>>>>>> it >>>>>>>>> somewhat unclean :) >>>>>>>> >>>>>>>> Indeed you’re right. By hiding the page name we’re now incitating > to >>>>>>> have longer URLs and encoded characters showing up in URLs >>>>>>> which is >>> not >>>>>>> nice I agree. >>>>>>>> >>>>>>>> Maybe one solution is to do something similar to what we >>>>>>>> do in AWM, >>>>> i.e. >>>>>>> generate automatically the URL from the title entered by >>>>>>> the user > and >>>>> show >>>>>>> the resulting URL to the user and give the user the >>>>>>> opportunity to >>>>> change >>>>>>> the URL. >>>>>>>> >>>>>>>> See >>>>>>>> http://extensions.xwiki.org/xwiki/bin/download/Extension/ >>>>>>> App%20Within%20Minutes%20Application/AppWithinMinutes-Step1 >>>>>>> .png >>>>>>>> >>>>>>>>> 2) Secondly, to have the shorter url, we use only the >>>>>>>>> short forms > of >>>>>>>>> complete title. >>>>>>>>> Ex. For title 'Pune University' we use name PU. >>>>>>>> >>>>>>>> Hey, you’re from Pune? :) I’ve been there about 15 times! >>>>>>>> That was >>> in a >>>>>>> previous job where my company and KPIT Cummins were partners. >>>>>>>> >>>>>>>>> Otherwise in this hierarchy of pages, the url would be >>>>>>>>> much > longer. >>>>>>>>> Ex. We have page 'Electronics and Telecommunications' >>>>>>>>> branch under >>>>> page >>>>>>>>> 'Pune University'. We should not have such a long url. >>>>>>>>> Instead > here >>> we >>>>>>> need >>>>>>>>> PU/ENTC or Pune-University/ENTC >>>>>>>>> >>>>>>>>> To avoid all this, what we currently do: >>>>>>>>> 1) On create page dialog, use PU as title.. This will >>>>>>>>> create url > as >>>>> PU. >>>>>>>>> If full name is used here as title, we need to use - >>>>>>>>> instead of >>> spaces >>>>>>> to >>>>>>>>> avoid percent characters in url. >>>>>>>>> 2) While in edit mode, change the title back to Pune University. >>>>> Remove >>>>>>> any >>>>>>>>> - characters to make title clean. >>>>>>>>> This is where confusion creeps in. >>>>>>>>> >>>>>>>>> If these two terms create confusion, why I need to show >>>>>>>>> them both: >>>>>>>>> I guess the *confusion is due to term Name*. It doesn't reflect >>> actual >>>>>>> usage >>>>>>>>> of the term. URL or weblink or link or web address would >>>>>>>>> be more > apt >>>>>>> terms >>>>>>>>> to use to instead of Name. >>>>>>>> >>>>>>>> Regarding Page name vs Page URL. >>>>>>>> >>>>>>>> A bit of history: The reason we used page name and not >>>>>>>> page URL >>>>>>> originally is because what the user is creating is a >>>>>>> document in the >>>>>>> database and initially it was called Document Name. Since >>>>>>> that was a >>> bit >>>>>>> confusing for users, we had decided to call it Page Name. >>>>>>> It just >>>>> happened >>>>>>> that the URL used was directly derived from the >>>>>>> document/page name. >>>>>>>> >>>>>>>> In practice the 3 concepts could have different values: >>>>>>>> * a value for the document’s name in the DB >>>>>>>> * another value for the document’s title >>>>>>>> * yet another value used in the URL. >>>>>>>> >>>>>>>> We’ve had discussions so that we could let the user >>>>>>>> provide shorter >>>>> URLs >>>>>>> for pages in the future. >>>>>>>> >>>>>>>> Now for the time being and since we don’t have this ATM, I think I >>>>> agree >>>>>>> with you that we could decide to display to the user the >>>>>>> URL that > will >>>>> be >>>>>>> generated (the encoded URL) and allow the user to change it. >>> Internally >>>>> the >>>>>>> user would change the document name. >>>>>>>> >>>>>>>>> My users can differentiate between Title and URL. But the whole >>>>>>> procedure we >>>>>>>>> follow is certainly not understandable by all. And we definitely >>> need >>>>> to >>>>>>>>> follow this whole long procedure, just to have short and >>>>>>>>> clean > urls. >>>>>>>> >>>>>>>> Yes, if you’re asking your users to care about the URLs >>>>>>>> that get >>>>>>> generated, right now they need to be advanced users to be >>>>>>> able to > edit >>>>> the >>>>>>> page name in the Create Page UI (since changing the title afterwards >>> is >>>>> too >>>>>>> cumbersome). >>>>>>>> >>>>>>>>> So, by showing both fields at the first place itself, I >>>>>>>>> would like >>> to >>>>>>>>> shorten the procedure and url length. >>>>>>>> >>>>>>>> I’m in agreement with you. Let’s see what others think. >>>>>>>> >>>>>>>> Thanks for this interesting discussion! >>>>>>>> -Vincent >>>>>>>> >>>>>>>>> -- >>>>>>>>> View this message in context: http://xwiki.475771.n2.nabble . >>>>>>> com/Page-Title-and-Name-confusion-tp7603546p7603551.html >>>>>>>>> Sent from the XWiki- Users mailing list archive at Nabble.com. >>> >>> > >
On 24 Apr 2017, at 12:31, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi,
Users can change the URL anytime after the page creation, and that is using the "Rename" action, although I agree that simple users might not really see the connection between Rename, URLs and Titles. So yes it would be ideal to provide the ability to select (reserve) the URL from the creation page step (for steps optimization purposes).
Now, some important mention is the use case. From what I can assume from your answers, the majority of you have Wikis / Knowledge Bases. For this flavor the URLs are important and I quite get the need. The issue is for users that use XWiki for Groupware / Applications use case. When your instance is using heavily applications, you don't care about the URL is generating, you don't care about the nesting, etc. We had users that requested to never see the Page Name part and actually the ability to auto-generate the URL with some random numbers that they shouldn't see.
Which shows that they do care about the URL ;) I don’t think that the need to be careful about your urls is related to any use case/flavor. Of course if you’re using XWiki as a public web site you care even more for the SEO reasons but even for internal use cases you do care about URLs. For the simple reason that you often need to copy paste URLs in emails, chat rooms, etc. FTR I remember a lot more users asking to control URLs than users asking to have random numbers in the URL (AFAIK that one happened only once) so if we had to choose a default, I’d go with the ability to control URLs by default. Actually, as mentioned in earlier replies, I’d go about introducing a Component role for generating the part of the URL related to the document and have a default implementation just serializing the document name as we do now. And provide a config option to change that so that if someone wanted, he could implement an extension to change the algorithm and generate a unique ID instead for ex.
That's why the subject is a bit problematic, because some users want to see/alter the Page Name/ URL; while others don't care it exists.
Even those who don’t care about changing the URL know the concept of a URL and they know that XWiki has URLs. So it’s not because we would show it in the create page URL that they would get confused. Thanks -Vincent
I also don't like the configuration proposal, since it's always hard to test all combinations of configurations and we need to decide on the default. Not sure about changing it in the Base Flavor, since not all Flavors users might need it. The UIX could be a solution in order to use it just by some Flavors.
What is really interesting and good to know is that indeed the Page Name / URL are important for Knowledge Bases (KB). Still in KBs the content creators are not that many (compared to readers) and they usually are the wiki gardeners, and they tend to be 'advanced' users. The smallest / simplest changes would indeed be in the labels wording and descriptions. Also the 'URL' mention instead of Page Name.
Thanks, Caty
On Sun, Apr 23, 2017 at 8:23 AM, Vishal <[email protected]> wrote:
Hi all.. Thanks for taking the issue this much seriously.
Hi Vincent..
Hey, you’re from Pune? :) I’ve been there about 15 times! Hey, you are welcome again.. I would expect you to drop me an email while visiting Pune next time :)
Normal users don't generally care about their URLs and SEO. Hi Caty.. You are definitely correct about SEO as simple users don't even know what SEO is. But I am very sure that even simple users do care about URLs. For instance, we share all our educational articles on our wiki in chats, like in WhatsApp, Facebook, Gmail, and what not. And they often ask me to clean the encoded URLs for them. In last 15 days for instance, I had to rename about 250 pages.. I don’t fully agree with you. I have the feeling (can’t prove it) And I guess this is what Vincent felt but couldn't prove.
But for your use case you shoyld write a shorting/trimming algorithm, but this is custom Yes I agree. It should be custom because not all will want such trimming of URLs.
It may generate nicer urls but they’re not perfect either. They’re a bit longish from what I see I think we can't and shouldn't force anyone to have short URLs. Long URL doesn't seem a problem for us, but inability to shorten them in the first place indeed is. I disagree with having any shortening algorithm as even we do use full names in URLs at certain places. e.g. /Pune-University
My Proposal: I strongly agree with Vincent about Create Page UI like AWM. This is what we think will be most user friendly. (Sorry, couldn't upload images but rough layout)
*Title: (Tip: Title as shown on Page/Document) [Title Textbox]
URL: (Tip: this is a webaddress) [Non editable initial part of URL][Textbox for last part of URL]
Location: (Tip: location of page in wiki) [Documents tree/Parent]*
In above layout, we could use algorithm at URL section just to make them more readable (removing ecoded characters), nothing else.
And it would be nice to have this universally editable, no need of any options like ALWAYS, NEVER, etc. Also no need to restrict it to just advanced users, because mostly users who could create a page would know about URLs.
Very much thanks for this wonderful discussion. Regards, Vishal
-- View this message in context: http://xwiki.475771.n2.nabble. com/Page-Title-and-Name-confusion-tp7603546p7603588.html Sent from the XWiki- Users mailing list archive at Nabble.com.
Hi all.. Thanks for taking the issue this much seriously. Hi Vincent..
Hey, you’re from Pune? :) I’ve been there about 15 times! Hey, you are welcome again.. I would expect you to drop me an email while visiting Pune next time :)
Normal users don't generally care about their URLs and SEO. Hi Caty.. You are definitely correct about SEO as simple users don't even know what SEO is. But I am very sure that even simple users do care about URLs. For instance, we share all our educational articles on our wiki in chats, like in WhatsApp, Facebook, Gmail, and what not. And they often ask me to clean the encoded URLs for them. In last 15 days for instance, I had to rename about 250 pages.. I don’t fully agree with you. I have the feeling (can’t prove it) And this is what Vincent felt but couldn't prove.
But for your use case you shoyld write a shorting/trimming algorithm, but this is custom Yes I agree. It should be custom because not all will want such trimming of URLs.
It may generate nicer urls but they’re not perfect either. They’re a bit longish from what I see I think we can't and shouldn't force anyone to have short URLs. Long URL doesn't seem a problem for us, but inability to shorten them in the first place indeed is. I disagree with having any shortening algorithm as even we do use full names in URLs at certain places. e.g. /Pune-University
My Proposal: I strongly agree with Vincent about Create Page UI like AWM. This is what we think will be most user friendly. (Sorry, couldn't upload images but rough layout) *Title: (Tip: Title as shown on Page/Document) [Title Textbox] URL: (Tip: this is a webaddress) [Textbox for last part of URL] Location: (Tip: location of page in wiki) [Documents tree/Parent]* In above layout, we could use algorithm at URL section just to make them more readable (removing ecoded characters), nothing else. And it would be nice to have this universally editable, no need of any options like ALWAYS, NEVER, etc. Also no need to restrict it to just advanced users, because mostly users who could create a page would know about URLs. Very much thanks for this wonderful discussion. Regards, Vishal -- View this message in context: http://xwiki.475771.n2.nabble.com/Page-Title-and-Name-confusion-tp7603546p76... Sent from the XWiki- Users mailing list archive at Nabble.com.
participants (7)
-
Denis GERMAIN -
Ecaterina Moraru (Valica) -
Mahomed Hussein -
Marius Dumitru Florea -
Miroslav Galajda -
Vincent Massol -
Vishal