[
Lists Home |
Date Index |
Thread Index
]
FYI, with Jerry's help, we've identified these goals:
-- configure freelinking to automatically create a story page from [[textlinks]] with the path alias automatically entered. (The
Drupal freelinking documentation implies this can be done.)
-- disable camelcase linking. (We have too many camelcase terms throughout the site; we only want the [[ ]] command for creating a
new page.)
If we can't do the above with freelinking, we'll search for other options. We are also still open to using Drupal's taxonomy feature
in addition to a wiki; as soon as Greg has time to investigate and demo it for us, we can evaluate.
Carol
-----Original Message-----
From: Scott Prentice [mailto:sp@leximation.com]
Sent: Tuesday, February 07, 2006 3:47 PM
To: Jerry Silver
Cc: dita-fa-edboard@lists.xml.org
Subject: Re: [dita-fa-edboard] DITA wiki
Hi Jerry...
Thanks for the background (I apparently missed in your earlier post ..
sorry), that does help. The part I was missing was that the destination page was created automatically if it was missing. But,
typically the person who clicks a link is looking for more information, and having an empty page created is not very useful (I
assume it doesn't somehow add content also when creating a page). So, that means that the person who enters a camel case word, would
also need to make sure to create a destination page so the link resolves properly. I do see the benefit of this and would certainly
be willing to give it a try. I agree what this more organic method of linking is better than the the alternate GUI-based method for
making a link (in general the GUIs make me crazy though .. when I make a link I just type the HTML).
What seems like it would be useful is to be able to get a report that lists the "empty" freelinks. That way we could check the site
on a regular basis and add content as needed.
I'm still a little bothered by the auto-linking of camel case words ..
there are cases where it could be useful, but so far it seems to cause more problems that not (unless we can exclude that operation
from hard-coded links). The [[..]] coding seems like a good method to allow easy linking since when you do that you're consciously
making a decision to link and may be more inclined to make sure the destination exists.
OK .. here's a hack but does get around my freelinking in a hard-link problem .. if you wrap the second capitalized letter in a SPAN
tag, it breaks the freelinking for that HREF. For example .. a link to FrameMaker was this ..
<a href="http://www.adobe.com";>FrameMaker</a>
(which gets freelinked and broken). If you make it this ..
<a href="http://www.adobe.com";>Frame<span>M</span>aker</a>
It works fine.
Yes .. not a pretty thing, but it does work.
...scott
Jerry Silver wrote:
>Scott,
>
>CamelCase is just a convention used by some wikis to "markup" a link.
>There are some problems with CamelCase, as we encountered. As an
>alternative, Freelinking supports the double square bracket syntax to
>create a link.
>
>As I pointed out in an earlier post:
>
>Social software like Wikis and Folksonomies succeed because they allow
>the content and tagging to happen more organically. Linking is a case
>in point. One of the defining characteristics of wikis is the
>automatic link handling. To create a link, you just have to type a
>CamelCase phrase, or surround a phrase with some delimiter (usually
>[[...]]). If a page with a matching title already exists, a link is
>automatically created. If the page title is changed, the links are
>automatically updated [although this is not true of Freelinking]. If a
>matching page doesn't exist, it will be automatically created when the
>link is clicked. All very simple, and easily picked up by users.
>
>Contrast this with traditional web page linking (as implemented by
>default in Drupal):
>
>- Add some text
>- Select the text
>- Open a hyperlink dialog
>- Type in a well formed URL (often requiring that you navigate to the
>target page and copy and paste the URL from the address bar)
>
>Four steps (each with several sub-steps) vs. the single step of typing
>a CamelCase or delimited phrase, not to mention that creating a link is
>*also* the way you create a page - much simpler than the default model
>of creating a new story page in Drupal.
>
>I did run across a proposal to disable CamelCase linking in Freelinking
>- see http://drupal.org/node/25986. But it's not clear if that feature
>is available in the version we're using. It seems that the more
>successful Wikis (e.g. Wikipedia, based on MediaWiki) don't use
>CamelCase at all.
>
>Regards,
>
>Jerry
>
>-----Original Message-----
>From: Scott Prentice [mailto:sp@leximation.com]
>Sent: Tuesday, February 07, 2006 9:44 AM
>To: Carol Geyer
>Cc: dita-fa-edboard@lists.xml.org
>Subject: Re: [dita-fa-edboard] DITA wiki
>
>Regarding the Freelinking .. I think I'm just not getting the concept
>(I'm only fundamentally familiar with wikis, so perhaps that's why).
>What makes camel case words more important than other words, and why
>would we expect that there would be a page to link to for every camel
>case word?
>
>Regarding Freelinking in links .. yes, if the first word in a link is
>camel case, it gets freelinked and the intended link is wiped out. But
>if there are camel case words anywhere in a link, those become
>freelinks and you end up with two links (one the intended link and the
>other the freelink), which seems very confusing to me. If possible,
>perhaps we can disallow freelinking within a hard-coded link?
>
>As a side-note .. I've noticed that users can change the "theme" that
>they view the site with. If you change it to "bluemarine," the
>IE-text-selection problem goes away. This could be an option for those
>people that use IE and are bothered by this bug. However, if we provide
>multiple themes for people to select, we should make sure that each is
>branded properly and has reasonable default formatting. (Right now, the
>"bluemarine" theme is still in the default mode with Drupal logo, etc.)
>
>...scott
>
>
>
>Carol Geyer wrote:
>
>
>
>>Okay, I turned freelinking back on, and I have a meeting with Greg at
>>
>>
>2:00 today to discuss our options.
>
>
>>Just so I communicate this correctly, are these assumptions valid:
>>
>>1. The functionality that we're lacking at this point is the ability
>>for users to easily (preferably intuitively) create new pages on the
>>site that are directly linked from other pages. A wiki appears to be
>>the most intuitive way to enable that (people are used to wikis).
>>We're
>>
>>
>willing to consider any solution that will provide this
>functionality--the freelinking module, a different wiki, or another
>Drupal module (taxonomies, etc.)--as long as it's something that can
>easily be understood by users.
>
>
>>2. Freelinking creates a link out of any CamelCase word, but linking
>>
>>
>that word to a new page isn't intuitive.
>
>
>>3. Alternatively with freelinking, you can use the double bracket
>>syntax: [[page title]], which provides an explicit indicator that a
>>
>>
>link is needed, but if you change the title of the target page, the
>links to that page break.
>
>
>>4. When creating a link to an external page, if the first word in the
>>link is CamelCase, the external link gets wiped out and replaced with
>>
>>
>the automated internal link; we need a way to override this.
>
>
>>Anything else?
>>
>>Thanks,
>>Carol
>>
>>______________________________
>>Carol Geyer
>>Director of Communications
>>OASIS
>>Voice: +1.978.667.5115 x209
>>
>>OASIS Symposium: The Meaning of Interoperability, 9-12 May, San
>>Francisco http://www.oasis-open.org/events/symposium_2006/
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>This publicly archived list is provided by OASIS for the use of the
>>Editorial Board of the XML.org DITA Focus Area. Subscription and
>>posting privileges are reserved for members of the Editorial Board;
>>others should contact communications@oasis-open.org for assistance.
>>
>>[Un]Subscribe: dita-fa-edboard-[un]subscribe@lists.xml.org
>>List archives: http://lists.xml.org/archives/dita-fa-edboard
>>Committee homepage: http://www.oasis-open.org/committees/dita
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>---------------------------------------------------------------------
>This publicly archived list is provided by OASIS for the use of the
>Editorial Board of the XML.org DITA Focus Area. Subscription and
>posting privileges are reserved for members of the Editorial Board;
>others should contact communications@oasis-open.org for assistance.
>
>[Un]Subscribe: dita-fa-edboard-[un]subscribe@lists.xml.org
>List archives: http://lists.xml.org/archives/dita-fa-edboard
>Committee homepage: http://www.oasis-open.org/committees/dita
>
>
>
>
>
>
>
---------------------------------------------------------------------
This publicly archived list is provided by OASIS for the use of the Editorial Board of the XML.org DITA Focus Area. Subscription and
posting privileges are reserved for members of the Editorial Board; others should contact communications@oasis-open.org for
assistance.
[Un]Subscribe: dita-fa-edboard-[un]subscribe@lists.xml.org
List archives: http://lists.xml.org/archives/dita-fa-edboard
Committee homepage: http://www.oasis-open.org/committees/dita
|
