Closed Bug 665699 Opened 13 years ago Closed 12 years ago

Kuma: Easily link to articles within the site

Categories

(developer.mozilla.org Graveyard :: Wiki pages, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: openjck, Unassigned)

References

Details

(Whiteboard: u=contributor c=wiki p=2)

Attachments

(2 files)

      No description provided.
Assignee: nobody → lcrouch
Version: unspecified → Kuma
Assignee: lcrouch → nobody
Target Milestone: 1.0 alpha → ---
Target Milestone: --- → 0.9.9
Whiteboard: [u: user] [c: wiki] → u=user c=wiki p=
Using the link button in the toolbar.
Summary: Kuma: Easily link to articles within the site, as well as to anchors → Kuma: Easily link to articles within the site
Whiteboard: u=user c=wiki p= → u=user c=wiki p=2
Priority: -- → P1
Assignee: nobody → lcrouch
Sheppy, what's the ideal interface and what's passable interface?

By default, ckeditor gives us a link command to easily enter a URL and/or anchor with link options.

The MindTouch plugin command adds wiki browsing but it's pretty clumsy - do you actually use it much?

Kitsune gives a simple pop-up widget that creates wiki markup - no use to us.

To keep this at 2 points we'll need to keep this simple. Browsing or searching docs in the link dialog will make this 3 points or more. Can you think of a simple or easy way to do this that will hit 80% of the use cases?
We really want wiki browsing for linking. Having to enter a URL is really lame and tedious, and discourages people from creating links.

What we want is a title search, basically. Highlight text, get a list of potential title matches on that text, hit a button to add the link to the selected page.

Bonus points for adding a "Replace text with this title and add link," so you can replace not-quite-right article title text in your article with the correct title.
Thanks for the insight, Sheppy!

How about we split this into two different tickets, one for manual linking and one for the title search? Would it make sense to do this from a technical point of view or would the two features need to be built very differently?
Yeah, that might be a good idea.
Attached image How pbwiki does links
I haven't looked into the difficulty here, but here's how PBWiki does links
for dev, the big part of this feature is just enabling the search system - we haven't touched it at all. that alone is a 3-point story and I think it blocks this bug.

so, if we don't want to compromise on the feature, we need to bump this bug from 0.9.9 sprint and make a new c=search p=3 bug - "kuma: Enable sphinx search"
(In reply to comment #4)
> Thanks for the insight, Sheppy!
> 
> How about we split this into two different tickets, one for manual linking
> and one for the title search? Would it make sense to do this from a
> technical point of view or would the two features need to be built very
> differently?

Thinking about the PBWiki example, I'd say this bug could be broken into a few progressive tasks:

- Link assist popup, inserts sample text (eg. [New Link]), accepts wiki page name or URL (p=2)
- Auto-complete wiki title search for link assist popup (p=2)
- Link assist popup to wrap selected text in link (p=1)
- Optionally replace highlighted text with link to selected wiki page title (p=1)
(In reply to comment #8)

> - Auto-complete wiki title search for link assist popup (p=2)

(Oh, yeah, and like Luke said, this would also assume we have a search system in place that can find wiki pages with partial title matches)
lorchard: nice break-down. I think the first bug is more like "change the link popup to accept wiki slug or url."
sheppy, if you and jay agree on les and I's breakdown, let me know and I'll file additional bugs as blockers to this one to make this the umbrella bug.

then I'll bump this one and pull a couple of its sub-bugs into the current sprint.
That sounds about right, although I'd like to see some mockups before actual implementation begins, to be sure my understanding of Les's analysis matches what everyone else thinks. This is a fairly critical bit of interface to get right, IMHO.
morgamic, whom do we ask for mockups now that Chowse is gone?! ;)
Here's a really basic sketch of what the modified ckeditor link box could look like.
Depends on: 673508
Assignee: lcrouch → nobody
Target Milestone: 0.9.9 → 1.0
Depends on: 673513
I added new dependency bugs for this one. I kept one of them in 0.9.9 but bumped this one and the others while we discuss and prioritize.
Target Milestone: 1.0 → ---
I love that dialog box, fwiw.
I say it's worth a lot!

Thanks for the feedback, Sheppy. Please keep it coming, as we want to be sure you are pleased with the final product.
Sheppy had some great feedback on Deki's "insert link" dialog in my recent user interview with him.

Sheppy mentioned that he is frustrated with our need to disable indexing. Without this, it is impossible for users to search for pages and page sections directly in the "insert link" dialog. Instead, users must navigate to pages some other way and enter URLs by hand, which often leads to inaccurate links or discourages people from creating links altogether. However, Sheppy did mention his appreciation that the dialog (when it works) allows users to browse by hierarchy ("JavaScript... sleep()... oh, here's that section I want").

Reading between the lines, it seems that accurate search is very important for this. Sheppy noted how easy it is to find the right documentation using the "insert link" dialog. If the search results provided in the dialog were not as accurate, I doubt he would find the dialog to be very useful at all.
Whiteboard: u=user c=wiki p=2 → [user-interview] u=user c=wiki p=2
Target Milestone: --- → 1.1
100% agree. At first we'll use Sphinx to power the search behind this dialog box, but eventually we can move to Elastic Search which should give us the full power of Lucene relevance scoring.

I really like search systems so I'm sure I'll be neck-deep in this feature.
Target Milestone: 1.1 → 1.2
All-hands de-reailed 1.2. Bumping to 1.3.
Target Milestone: 1.2 → 1.3
Can't do until sphinx is up on kuma-stage.
Target Milestone: 1.3 → 1.4
Target Milestone: 1.4 → 1.5
Whiteboard: [user-interview] u=user c=wiki p=2 → [user-interview] u=contributor c=wiki p=2
Target Milestone: 1.5 → 1.6
Whiteboard: [user-interview] u=contributor c=wiki p=2 → u=contributor c=wiki p=2
Target Milestone: 1.6 → ---
Blocks: 757255
Depends on: 757260
Depends on: 757264
Blocks: 756263
I want to say this is done now, thanks to davidwalsh. There's a link dialog now, with a search function that goes through page titles
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Version: Kuma → unspecified
Component: Website → Landing pages
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: