Hi Mahomed/all, > On 21 Apr 2017, at 19:02, Mahomed Hussein <maho...@custodiandc.com> 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#HByusingtheAddPageaction > 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%20Minutes%20Application/AppWithinMinutes-Step1.png). 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: maho...@custodiandc.com > http://www.CustodianDC.com > > -----Original Message----- > From: users [mailto:users-boun...@xwiki.org] On Behalf Of Vincent Massol > Sent: 21 April 2017 16:56 > To: XWiki Users <users@xwiki.org> > 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 <miroslav.gala...@gmail.com> >> 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 <vinc...@massol.net> wrote: >> >>> >>>> On 21 Apr 2017, at 16:19, Miroslav Galajda >>>> <miroslav.gala...@gmail.com> >>> 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 <vinc...@massol.net> wrote: >>>> >>>>> >>>>>> On 21 Apr 2017, at 15:36, Miroslav Galajda >>>>>> <miroslav.gala...@gmail.com >>>> >>>>> 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 <vinc...@massol.net> wrote: >>>>>> >>>>>>> Hi Miroslav, >>>>>>> >>>>>>>> On 21 Apr 2017, at 15:05, Miroslav Galajda < >>> miroslav.gala...@gmail.com >>>>>> >>>>>>> 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 <vinc...@massol.net> >>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>>> On 21 Apr 2017, at 13:52, Marius Dumitru Florea < >>>>>>>>> mariusdumitru.flo...@xwiki.com> wrote: >>>>>>>>>> >>>>>>>>>> On Fri, Apr 21, 2017 at 2:16 PM, Vincent Massol < >>> vinc...@massol.net> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Caty, >>>>>>>>>>> >>>>>>>>>>>> On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) < >>>>>>> vali...@gmail.com >>>>>>>>>> >>>>>>>>>>> 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 < >>>>> vinc...@massol.net >>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 20 Apr 2017, at 22:51, Vincent Massol >>>>>>>>>>>>>> <vinc...@massol.net> >>>>>>> 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 >>>>>>>>>>>>>>> <thewikinote...@gmail.com> >>>>>>> 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. >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> >
