Problem with Wiki Title Logic

Bug #928429 reported by Nat Katin-Borland
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
KARL3
Won't Fix
Low
Unassigned

Bug Description

This one is a bit confusing, but I'll try my best to explain what's going on. You can't have 2 wiki pages with the same name in the same community. The logic behind this is a bit confusing though. For example, I can create ((Page 1)), then go back later and Edit the title to Page 2. Now if I try to create a new page ((Page 1)) I will be prevented from doing so because the slug ((Page 1)) is already taken. It's confusing for the user because it's not clear that ((Page 1)) already exists. If I search for Page 1 in the wiki index, it's not there because the title was subsequently changed to Page 2. So as a user, I have no idea why I'm being blocked from creating a page titled ((Page 1)). Now if I try to create a new wiki page called ((Page 2)) KARL will automatically link to the existing page that has the Page 2 (even though the URL slug for that page is 'page-1' because that was the original name of the page). So sometimes the logic relies on the URL slug and sometimes the logic relies on the title. It seems to me that we can clean up the logic on this. Right now from a user perspective it's very confusing.

I've tried to explain this as clearly as I can, but let me know if there are questions.

Revision history for this message
Paul Everitt (paul-agendaless) wrote :

I'll do my best to explain, then you and Robert can talk about any policy changes going forward.

Let's introduce a new word called "name" (aka ID). The "name" of the page is the part that appears at the end of the URL. It is the unique identifier on a page, file, or any other kind of resource. It has to be unique in its container/folder...in this case, the entire wiki.

We like to have names that are readable in a URL. We could make up some long, opaque thing like "X932VS2". Those though aren't useful when doing things like reading over the phone, sending by email, looking up in browser history, etc.

How do we get that original name? We could make the user provide it. But most of the time, people don't care. So we just use the title, lowercase all the words, replace spaces with dashes, and use that as the name. If there's already a name, we postpend a -1 or -2.

Now on to your complaint. It appears that you'd like changes to the "title" to lead to changes in the "name". If we did that, links would break, URLs would break, bookmarks, links in email invitations, etc.

If we allowed ((Page 1)) to be re-used, then links to the original WikiPage would go to the new one, instead of the original, newly-re-titled one.

So while we could clean up one particular mess, we'd make a mess in another area, unless we find some solutions.

Changed in karl3:
assignee: nobody → Nat Katin-Borland (nborland)
Revision history for this message
Nat Katin-Borland (nborland) wrote : RE: [Bug 928429] Re: Problem with Wiki Title Logic
Download full text (3.8 KiB)

We don't seem to be postpending a -1, -2, etc. for wikis though. We do that for Files and Blogs, but not Wikis. This is part of the reason why it's so confusing. If we were just creating the page and adding a -1, then we would be all good...

--
Nathaniel Katin-Borland
Support Specialist
Knowledge Management Initiative
KARL Support Team

Open Society Foundations - New York Office
400 West 59th Street
New York, NY 10019
Email: <email address hidden>
Phone: 212-547-6984
http://www.soros.org/
http://www.karlproject.org
-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Paul Everitt
Sent: Wednesday, February 08, 2012 7:10 AM
To: Nathaniel Katin-Borland
Subject: [Bug 928429] Re: Problem with Wiki Title Logic

I'll do my best to explain, then you and Robert can talk about any policy changes going forward.

Let's introduce a new word called "name" (aka ID). The "name" of the page is the part that appears at the end of the URL. It is the unique identifier on a page, file, or any other kind of resource. It has to be unique in its container/folder...in this case, the entire wiki.

We like to have names that are readable in a URL. We could make up some long, opaque thing like "X932VS2". Those though aren't useful when doing things like reading over the phone, sending by email, looking up in browser history, etc.

How do we get that original name? We could make the user provide it. But most of the time, people don't care. So we just use the title, lowercase all the words, replace spaces with dashes, and use that as the name. If there's already a name, we postpend a -1 or -2.

Now on to your complaint. It appears that you'd like changes to the "title" to lead to changes in the "name". If we did that, links would break, URLs would break, bookmarks, links in email invitations, etc.

If we allowed ((Page 1)) to be re-used, then links to the original WikiPage would go to the new one, instead of the original, newly-re- titled one.

So while we could clean up one particular mess, we'd make a mess in another area, unless we find some solutions.

** Changed in: karl3
     Assignee: (unassigned) => Nat Katin-Borland (nborland)

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/928429

Title:
  Problem with Wiki Title Logic

Status in KARL3:
  New

Bug description:
  This one is a bit confusing, but I'll try my best to explain what's
  going on. You can't have 2 wiki pages with the same name in the same
  community. The logic behind this is a bit confusing though. For
  example, I can create ((Page 1)), then go back later and Edit the
  title to Page 2. Now if I try to create a new page ((Page 1)) I will
  be prevented from doing so because the slug ((Page 1)) is already
  taken. It's confusing for the user because it's not clear that ((Page
  1)) already exists. If I search for Page 1 in the wiki index, it's
  not there because the title was subsequently changed to Page 2. So as
  a user, I have no idea why I'm being blocked from creating a page
  titled ((Page 1)). Now if I try to c...

Read more...

Revision history for this message
Paul Everitt (paul-agendaless) wrote : Re: [Bug 928429] Problem with Wiki Title Logic
Download full text (6.2 KiB)

I just sent an email to osi-dev about it. It might prove hard to find a satisfactory solution.

The reason it works in Blogs is that the user is allowed to type the title on the Add Blog Entry screen. In our case, we're coming from the + sign on a wiki page which embeds the prospective title in the URL.

Here's an oddity I found when researching this.

a. On Page A I add ((Page 1)).

b. I click the plus sign and make a "Page 1" at /wiki/page-1

c. I reload Page A and a link to "Page 1" which goes to /wiki/page-1

d. I edit page-1 and change its title to "Page 2". Its name is still /wiki/page-1

e. I reload Page A. The link now says "Page 2" and goes to /wiki/page-1

In fact, in going through all of this, I've completely lost the plot on what's happening. We'll have to talk through it.

--Paul

On Feb 8, 2012, at 10:06 AM, Nat Katin-Borland wrote:

> We don't seem to be postpending a -1, -2, etc. for wikis though. We do
> that for Files and Blogs, but not Wikis. This is part of the reason why
> it's so confusing. If we were just creating the page and adding a -1,
> then we would be all good...
>
> --
> Nathaniel Katin-Borland
> Support Specialist
> Knowledge Management Initiative
> KARL Support Team
>
> Open Society Foundations - New York Office
> 400 West 59th Street
> New York, NY 10019
> Email: <email address hidden>
> Phone: 212-547-6984
> http://www.soros.org/
> http://www.karlproject.org
> -----Original Message-----
> From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Paul Everitt
> Sent: Wednesday, February 08, 2012 7:10 AM
> To: Nathaniel Katin-Borland
> Subject: [Bug 928429] Re: Problem with Wiki Title Logic
>
> I'll do my best to explain, then you and Robert can talk about any
> policy changes going forward.
>
> Let's introduce a new word called "name" (aka ID). The "name" of the
> page is the part that appears at the end of the URL. It is the unique
> identifier on a page, file, or any other kind of resource. It has to be
> unique in its container/folder...in this case, the entire wiki.
>
> We like to have names that are readable in a URL. We could make up some
> long, opaque thing like "X932VS2". Those though aren't useful when doing
> things like reading over the phone, sending by email, looking up in
> browser history, etc.
>
> How do we get that original name? We could make the user provide it. But
> most of the time, people don't care. So we just use the title, lowercase
> all the words, replace spaces with dashes, and use that as the name. If
> there's already a name, we postpend a -1 or -2.
>
> Now on to your complaint. It appears that you'd like changes to the
> "title" to lead to changes in the "name". If we did that, links would
> break, URLs would break, bookmarks, links in email invitations, etc.
>
> If we allowed ((Page 1)) to be re-used, then links to the original
> WikiPage would go to the new one, instead of the original, newly-re-
> titled one.
>
> So while we could clean up one particular mess, we'd make a mess in
> another area, unless we find some solutions.
>
> ** Changed in: karl3
> Assignee: (unassigned) => Nat Katin-Borland (nborland)
>
> --
> You received this bug notif...

Read more...

Revision history for this message
Nat Katin-Borland (nborland) wrote :
Download full text (8.6 KiB)

Now you can understand my confusion!

--
Nathaniel Katin-Borland
Support Specialist
Knowledge Management Initiative
KARL Support Team

Open Society Foundations - New York Office
400 West 59th Street
New York, NY 10019
Email: <email address hidden>
Phone: 212-547-6984
http://www.soros.org/
http://www.karlproject.org

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Paul Everitt
Sent: Wednesday, February 08, 2012 1:51 PM
To: Nathaniel Katin-Borland
Subject: Re: [Bug 928429] Problem with Wiki Title Logic

I just sent an email to osi-dev about it. It might prove hard to find a satisfactory solution.

The reason it works in Blogs is that the user is allowed to type the title on the Add Blog Entry screen. In our case, we're coming from the + sign on a wiki page which embeds the prospective title in the URL.

Here's an oddity I found when researching this.

a. On Page A I add ((Page 1)).

b. I click the plus sign and make a "Page 1" at /wiki/page-1

c. I reload Page A and a link to "Page 1" which goes to /wiki/page-1

d. I edit page-1 and change its title to "Page 2". Its name is still
/wiki/page-1

e. I reload Page A. The link now says "Page 2" and goes to /wiki/page-1

In fact, in going through all of this, I've completely lost the plot on what's happening. We'll have to talk through it.

--Paul

On Feb 8, 2012, at 10:06 AM, Nat Katin-Borland wrote:

> We don't seem to be postpending a -1, -2, etc. for wikis though. We
> do that for Files and Blogs, but not Wikis. This is part of the
> reason why it's so confusing. If we were just creating the page and
> adding a -1, then we would be all good...
>
> --
> Nathaniel Katin-Borland
> Support Specialist
> Knowledge Management Initiative
> KARL Support Team
>
> Open Society Foundations - New York Office
> 400 West 59th Street
> New York, NY 10019
> Email: <email address hidden>
> Phone: 212-547-6984
> http://www.soros.org/
> http://www.karlproject.org
> -----Original Message-----
> From: <email address hidden> [mailto:<email address hidden>] On Behalf
> Of Paul Everitt
> Sent: Wednesday, February 08, 2012 7:10 AM
> To: Nathaniel Katin-Borland
> Subject: [Bug 928429] Re: Problem with Wiki Title Logic
>
> I'll do my best to explain, then you and Robert can talk about any
> policy changes going forward.
>
> Let's introduce a new word called "name" (aka ID). The "name" of the
> page is the part that appears at the end of the URL. It is the unique
> identifier on a page, file, or any other kind of resource. It has to
> be unique in its container/folder...in this case, the entire wiki.
>
> We like to have names that are readable in a URL. We could make up
> some long, opaque thing like "X932VS2". Those though aren't useful
> when doing things like reading over the phone, sending by email,
> looking up in browser history, etc.
>
> How do we get that original name? We could make the user provide it.
> But most of the time, people don't care. So we just use the title,
> lowercase all the words, replace spaces with dashes, and use that as
> the name. If there's...

Read more...

Revision history for this message
Paul Everitt (paul-agendaless) wrote :

Tres, this bud's for you. The diagnosis was pretty complex, as I certainly had the existing behavior misunderstood. I made a narrated screencast demonstrating the issue and suggesting a fix:

  http://www.screencast.com/t/FuFS7B1i

Namely:

- On the wikipage add form, change the validator to catch the case where the name-ified title being passed in already exists

- If so, duplify the name, e.g. for a passed in title of "Page 1", make a name/id of page-1-1.

- I suppose the validator should whine if Page 1 exists, but not if page-1 exists

Changed in karl3:
assignee: Nat Katin-Borland (nborland) → Tres Seaver (tseaver)
importance: Undecided → Low
milestone: none → m91
Revision history for this message
Tres Seaver (tseaver) wrote :

I'm confused -- don't we really need to keep slugs and titles in sync
to make ((Wiki Nature)) work? Having more than one page with
near-duplicate titles, coupled with URL names not bound to the titles,
is a ((Wiki Foul)): why would we encourage that?

The classic pattern for handling renames in wikis is to create the new
page (usually with a back-pointer to the original), and then move all
content from the old page to the new, leaving only a pointer behind.
After that, you find and fix references to the old page opportunistically.

Revision history for this message
Paul Everitt (paul-agendaless) wrote :

I think what we're finding is that the customer doesn't think it is a foul, which might indicate that wiki-ness isn't what's desired.

I'm going to assign back to Nat and move this way in the future, giving us time to find out what we really want from wiki. We're already wrapped around the axel. No sense increasing the gap.

--Paul

On Feb 10, 2012, at 4:42 PM, Tres Seaver wrote:

> I'm confused -- don't we really need to keep slugs and titles in sync
> to make ((Wiki Nature)) work? Having more than one page with
> near-duplicate titles, coupled with URL names not bound to the titles,
> is a ((Wiki Foul)): why would we encourage that?
>
> The classic pattern for handling renames in wikis is to create the new
> page (usually with a back-pointer to the original), and then move all
> content from the old page to the new, leaving only a pointer behind.
> After that, you find and fix references to the old page opportunistically.
>
> --
> You received this bug notification because you are subscribed to KARL3.
> https://bugs.launchpad.net/bugs/928429
>
> Title:
> Problem with Wiki Title Logic
>
> Status in KARL3:
> New
>
> Bug description:
> This one is a bit confusing, but I'll try my best to explain what's
> going on. You can't have 2 wiki pages with the same name in the same
> community. The logic behind this is a bit confusing though. For
> example, I can create ((Page 1)), then go back later and Edit the
> title to Page 2. Now if I try to create a new page ((Page 1)) I will
> be prevented from doing so because the slug ((Page 1)) is already
> taken. It's confusing for the user because it's not clear that ((Page
> 1)) already exists. If I search for Page 1 in the wiki index, it's
> not there because the title was subsequently changed to Page 2. So as
> a user, I have no idea why I'm being blocked from creating a page
> titled ((Page 1)). Now if I try to create a new wiki page called
> ((Page 2)) KARL will automatically link to the existing page that has
> the Page 2 (even though the URL slug for that page is 'page-1' because
> that was the original name of the page). So sometimes the logic
> relies on the URL slug and sometimes the logic relies on the title.
> It seems to me that we can clean up the logic on this. Right now from
> a user perspective it's very confusing.
>
> I've tried to explain this as clearly as I can, but let me know if
> there are questions.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/karl3/+bug/928429/+subscriptions

Changed in karl3:
assignee: Tres Seaver (tseaver) → Nat Katin-Borland (nborland)
milestone: m91 → m94
Changed in karl3:
milestone: m94 → m97
Changed in karl3:
milestone: m97 → m100
Changed in karl3:
milestone: m100 → m104
Changed in karl3:
milestone: m104 → m108
Changed in karl3:
milestone: m108 → m112
Revision history for this message
Paul Everitt (paul-agendaless) wrote :

I'm going to leave this one sitting out there, hopefully we can pick it up as part of an Improve Wiki effort in Q3.

Changed in karl3:
milestone: m112 → m114
JimPGlenn (jpglenn09)
Changed in karl3:
milestone: m114 → m115
Changed in karl3:
milestone: m115 → m116
Changed in karl3:
milestone: m116 → m118
JimPGlenn (jpglenn09)
Changed in karl3:
milestone: m118 → m119
Revision history for this message
Paul Everitt (paul-agendaless) wrote :

We need to slow everything down until we get clarity on the Q4 budget.

Changed in karl3:
milestone: m119 → m120
Revision history for this message
Paul Everitt (paul-agendaless) wrote :

8 months of kicking the can down the road on this one. Closing.

Changed in karl3:
assignee: Nat Katin-Borland (nborland) → nobody
milestone: m120 → m999
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.