Closed
Bug 665699
Opened 14 years ago
Closed 13 years ago
Kuma: Easily link to articles within the site
Categories
(developer.mozilla.org Graveyard :: Wiki pages, defect, P1)
developer.mozilla.org Graveyard
Wiki pages
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: openjck, Unassigned)
References
Details
(Whiteboard: u=contributor c=wiki p=2)
Attachments
(2 files)
No description provided.
Reporter | ||
Updated•14 years ago
|
Assignee: nobody → lcrouch
Reporter | ||
Updated•14 years ago
|
Version: unspecified → Kuma
Updated•14 years ago
|
Assignee: lcrouch → nobody
Updated•14 years ago
|
Target Milestone: 1.0 alpha → ---
Updated•14 years ago
|
Target Milestone: --- → 0.9.9
Reporter | ||
Updated•14 years ago
|
Whiteboard: [u: user] [c: wiki] → u=user c=wiki p=
Comment 1•14 years ago
|
||
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
Updated•14 years ago
|
Priority: -- → P1
Updated•14 years ago
|
Assignee: nobody → lcrouch
Comment 2•14 years ago
|
||
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?
Comment 3•14 years ago
|
||
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.
Reporter | ||
Comment 4•14 years ago
|
||
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?
Comment 5•14 years ago
|
||
Yeah, that might be a good idea.
Comment 6•14 years ago
|
||
I haven't looked into the difficulty here, but here's how PBWiki does links
Comment 7•14 years ago
|
||
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"
Comment 8•14 years ago
|
||
(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)
Comment 9•14 years ago
|
||
(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)
Comment 10•14 years ago
|
||
lorchard: nice break-down. I think the first bug is more like "change the link popup to accept wiki slug or url."
Comment 11•14 years ago
|
||
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.
Comment 12•14 years ago
|
||
See http://cksource.com/forums/viewtopic.php?t=18327 and http://docs.cksource.com/CKEditor_3.x/Developers_Guide/File_Browser_%28Uploader%29/Custom_File_Browser for ideas to customize the ckeditor link dialog.
Comment 13•14 years ago
|
||
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.
Comment 14•14 years ago
|
||
morgamic, whom do we ask for mockups now that Chowse is gone?! ;)
Comment 15•14 years ago
|
||
Here's a really basic sketch of what the modified ckeditor link box could look like.
Updated•14 years ago
|
Assignee: lcrouch → nobody
Target Milestone: 0.9.9 → 1.0
Comment 16•14 years ago
|
||
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.
Updated•14 years ago
|
Target Milestone: 1.0 → ---
Comment 17•14 years ago
|
||
I love that dialog box, fwiw.
Reporter | ||
Comment 18•14 years ago
|
||
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.
Reporter | ||
Comment 19•14 years ago
|
||
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
Comment 20•14 years ago
|
||
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.
Updated•14 years ago
|
Target Milestone: 1.1 → 1.2
Updated•13 years ago
|
Target Milestone: 1.4 → 1.5
Updated•13 years ago
|
Whiteboard: [user-interview] u=user c=wiki p=2 → [user-interview] u=contributor c=wiki p=2
Updated•13 years ago
|
Target Milestone: 1.5 → 1.6
Updated•13 years ago
|
Whiteboard: [user-interview] u=contributor c=wiki p=2 → u=contributor c=wiki p=2
Updated•13 years ago
|
Target Milestone: 1.6 → ---
Comment 23•13 years ago
|
||
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: 13 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•13 years ago
|
Version: Kuma → unspecified
Assignee | ||
Updated•13 years ago
|
Component: Website → Landing pages
Updated•5 years ago
|
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•