Feb 212011

LGUS4G: well-designed URL (aka URL structure, what WordPress calls Permalink type/structure), especially what a site (such a Web 2.0 site) can choose.

  1. LGUS6S: There are a wide variety of URL patterns one can choose from

    1. LGUS89: especially with Web 2.0 sites, where typically now the backend is a database not a file system.
    2. LGUS9T: WordPress Permalink type/structure plus gives an excellent example of the options available , and, impressively, WordPress even allows this (and subdomain/subfolders) to be changed on the fly.
  2. LGUSNB: URL components

    1. LGUSQC: Table
      component example and/or WordPress term required? Include in URL? & if so How/where & how much?
      LGUTPG: site implementation/version ID “2” 0 Yes, as in “2.LoveRules.Info” says AI
      LGUTMS: organization domain “LoveRules.Info” 1 LGUTZ5: yes (and no choice) LGUTZO: It’s standard spot.
      LGUSYH: blog/group ID “myblog” in
      “myblog.JotHere.com” or “JotHere.com/myblog”
      sometimes as
      in WordPress MU/MS
      says AI: No, as long as appropriate precautions are taken
      LGUSF9: date (of 1st post) “2006/12/08” 0 says AI: No
      LGUSIQ: post name (or subject/topic) %postname% 0 says AI: No
      LGUSLI: category(s) %category% 0 says AI: No
      LGUSO3: author(s) %author% 0 says AI: No, as long as appropriate precautions are taken
      LGUW4E: content ID %postid% 0 (can also be done with AJAX & frames) Yes, absolutely include, says AI
      LGUW9Y: anchor to particular content within page “#conclusion” 0 unless the content can’t be broken out
    2. LGUSEU: about
      1. LGUSDC: for each, I ask
        1. LGUSE5:Include in URL?” (ideally with “Why?” & “Why not?”) and
        2. LGUSED:How/where & how much?
      2. LGUU35: WordPress term
        1. LGUU4Q: Here they’re listed at http://codex.wordpress.org/Using_Permalinks
      3. LGUT3M: speaker
        1. LGUT4P: possibilities include:
          1. LGUT5E: AI=AnytimeInnovator
      4. LGYCZG: Considerations:
        1. LGYCZR: How search engines pick up keywords.
          1. LGYD0H: Today’s search engines place a high/top value on keywords placed in the URL of a page –I’ve heard & it would seem
            1. LGYD2R: This is probably from the Web 1.0 days when, yes, the URL path contained folder path, and since that was then the leading-often-only way to organize the site’s content, the folders would be given good names so would often be a great source of keywords (if it was itended) and there often weren’t meta-tags in pages giving keywords.
            2. LGYD6D: Consequently to get top rankings, this probably explains why putting keywords in URLs Today this is a common goal despite no longer the need (in Web 2.0) and the drawbacks as column LGY72S details.
          2. LGYDBZ: Search engines also get key keywords from meta-tags plus the document title & headings.
          3. LGYDL7: it is possible search engines will change and place less value on the keywords in the URL, at least when sufficient keywords are found in the meta-data, title, & heading
            1. LGYDNZ: Motivations search engine makers could have for doing this include:
              1. LGYDPP: the fact in “Include keywords (as title, date, author, & more) into the URL, possibly many”
                1. LGYDT9: In Web 2.0 this is no longer necessary.
                2. LGYDON: the drawbacks  as column LGY72S details.
              2. LGYDU0: For Just short, static content ID, the widespread possibility now plus the advantages column LGY6A0 details.
            2. LGYDWZ: Says AI, for these reasons, too, hope search engines change. —AI
            3. LGYDZT: And worth note, search engines DO adjust their indexing.
              1. LGYE0V: SEO experts used to say “Never put your menus & navigation in JavaScript” as search engines won’t see it.  But now they process JavaScript and do see these things.
      5. LGY680: Table
        ID LGY694: LGY6GX: LGY6EF: LGY72S: LGY72S LGY6A0: LGY6A0 LGY7GZ:
        LGY69F: feature importance in general importance to AI “Include keywords (as title, date, author, & more) into the URL, possibly many” Just short, static content ID append-optional-comment
        LGY7BN: URL never exposes mistakes & secrets medium no typically yes IF comment not used
        LGY6PR: Stable URL medium high no yes yes
        LGY6HH: Short URLs Increasing demand, for Tweets & SMS medium no, definitely not yes, possibly very short yes as comment can always be omitted
        LGY6MG: Meaningful URLs high no yes, indeed can include the full title no, except for possibly root domain yes IF comment used
        LGY731: Initial ranking on today’s search engines high medium high medium or low medium, maybe high.
        LGYCO4: consequential choice “Include keywords (as title, date, author, & more) into the URL, possibly many” append-optional-comment
      6. LGY6IS: Features
        1. LGY1G8: Short URLs
        2. LGY1OM: Meaningful URLs
          1. LGY1H8: When the user ISN’T given a meaningful URL
            1. LGY1HP: a fix is to have the user, when saving the URL (say in other HTML), to have the user turn this into a meaningful link (as to copy the page  title as the display, and the underlying cryptic URL probably be hidden.
              1. LGY834: The key problems here are that:
                1. LGY83N: Users may not know how to do this.
                2. LGY845: Doing this may take some time.
              2. LGYBTZ: further fixes are possible, starting with having the link already ready (as it is at the end of any LGWEB3 writing). @@to be continued.

          LGY77Y: URL never exposes mistakes & secrets

        3. LGY1PL: Stable URL as Corrections are rarely necessary to the URL
          1. LGY6QM: Meetup & especially WordPress  (& surely others) have gone enormous strides to fix broken URLs by having a redirect engine which automatically redirects the prior URL to the new one when ever a change is made.  This ISN’T a full fix, as still source links are probably not updated mostly and if the old URL is needed for some other purpose, it seemingly will be re-used without warning.  But it certainly feels like it fixes 80% of the problem.
      7. LGY15W: Possibilities:
        1. LGY19H: “Include keywords (as title, date, author, & more) into the URL, possibly many”
          1. LGY1BN: Today this is a common goal, indeed whole SEO plugins have been developed to do it.
          2. LGY1CS: Pros thru cons:
            1. LGY1DN: Currently search engines  DO use this information significantly as part of ranking that page for these keywords
        2. LGY7N8: Just short, static content ID:
          1. LGY7UB: Make URL be just the domain name plus a static constant ID
            1. LGY7UN: In WordPress, this would typically be a Permalink structure of just “%postid%”
          2. LGY174: “Don’t include any info in a URL which may change.”
            1. LGY191: Pros thru cons:
              1. BIG PRO:
        3. LGY1KJ: append-optional-comment
          1. LGY7IM: as a fix to a solution as a Just short, static content ID, append to the URL an optional comment with all the details that you want,
            1. LGYCSE: as “?cmt=All+about+domestic+cat+care” (obvious that its added) or
            2. LGYCSY: even “/All/about/domestic/cat/care” (not obvious it’s added, but present search engines will more likely pick it up it up).  In 2011 I AI think I may have seen some site doing this.
          2. LGYCR7: As 2010 (perhaps earlier) this is my AI‘s invention.
      8. LGYEON: Conclusions:
        1. LGYEP5: For including anything but minimal in URL
          1. LGYEQG: (as I have for years), says AI: No, for reasons as mentioned in Says AI, for these reasons, too, hope search engines change.
    3. LGUTGX: component
      1. LGUV7G: site implementation/version ID
        1. LGUVM5: about
          1. LGUZG8: what it is?
            1. LGUVMG: Occasionally one needs to move a site from one hosting platform to another, such as a move I oversaw from a blogger blog to a WordPress blog, or another I’ve overseen from Sharepoint to WordPress. Or experiment with another implementation. Each implementation of a site is given this, a different site implementation/version ID.
              1. LGUVUI: If a site move can be done instantaneously, then users can just see site reappear under the prior URL, with hopefully all the URLs still working else redirected, but
              2. LGUVV3: that’s a big IF:
                1. LGUVVK: different hosting platforms structure their URLs differently, and the new site may not be able to properly redirect the old site’s URL.
          2. LGUZMI: If the site implementation/version ID is included  the standard URLs for a site (as in 2.LoveRules.Info), then
            1. LGUZT5: normally the base URL for the service (LoveRules.Info) is redirected whatever implementation is current (as to 2.LoveRules.Info if that’s the current one).
            2. LGUZTJ: otherwise it has its own page for a human to choose which site to go, but seemingly, if ever done, this would only happen during a transition period.
          3. LGUZCP: Why include it in the URL, pros thru cons?
            1. LG480O: BIG PRO:
              1. LGV086: Doing:
                1. LGV08H: This enables both sites (prior & replacement), indeed any number of variant implementations, to be online & operational at the same time so
                  1. LGUTQP: Makes migrations easier, including facilitates gradual transitions
                  2. LGV00L: allows for easy back-out-if-new-site-doesn’t work.
                2. LGV096: When the UI changes on the user (from changing the underlying implementation) the URL changes, too, so probably less upsetting & more explained to the user.
                3. LGV0BG: It may enable the user him/herself to gradually transition between the sites.
              2. LGV03J: NOT doing this
                1. LGV0DB: Requires to suddenly redirect everything from the same URL, which then requires tricky under-the-hood potentially non-standard sysadmin re-mapping (which could then go wrong)
                2. LGV0H6: Would seemingly require a full & instantaneous switchover, which then would probably be stressful & risky.
            2. LGV01R: NOTABLE CON: For all users, makes content URLs a bit longer & more complex (as http://2.loverules.info/82 instead of just http://loverules.info/82)
          4. LGUYV7: Where to place the ID?
            1. LGV12C: Possibilities:
              1. LGUTT1: Make the ID a subdomain
                1. LGUYZT: so each implementation of a site (of any complexity) has it’s own subdomain URL then have the main/base URL redirect to whatever one is current.
                  1. LG47YT: Real example: http://LoveRules.Info currently redirects to http://blogger.LoveRules.Info (in Blogger) but will soon redirect to http://2.LoveRules.Info (in WordPress)
                  2. LG47WH: this is my AI’s idea from years ago (says AI) when CommuniDB.com was registered and then its subdomains as sp1.CommuniDB.com (for it’s first implementation via Sharepoint) were my idea.
                2. LGUZB7: a subdomain (as opposed to a directory) gives maximum flexibility for changing hosting
              2. LGV0WN: Make the ID a subdirectory at the path root
                1. LGV0Y1: This is often possible but somewhat web-server dependent.
              3. LGV0YR: Put the ID in the URL in some other way
                1. LGV0ZK: This is highly web-server & platform (as WordPress vs. Drupal) dependent so probably should not be done unless very good reason.
          5. LGV131: What to name the ID?
            1. LGV13F: Possibilities:
              1. LGV19B: Use a symbolic short name, as SP1.CommuniDB.com (1st Sharepoint, which was also 1st implementation)
              2. LGV15H: Use a universal ID, as http://l5bwwp.SelfTrans.com
              3. LGUTRB: Use 1,2,3, for each implementation. Example: http://2.LoveRules.Info
        2. LGUVKG: Says AI
          1. LGUVBW: Yes, as in “2.LoveRules.Info” says AI: this is my AI’s idea from years ago, and here choosing (my recent preference Use 1,2,3, for each implementation) and (my always-preference Make the ID a subdomain).
      2. LGUV54: blog/group ID
        1. LGUTDD: this identifies the group responsible for & generally owning the info
          1. LGUTEV: at least in (in WordPress MU and in other blog sites)
        2. LGUTFE: Include in URL?
          1. LGUUP7: What leading sites are doing (table)
            LGUUQ9: name Alexis rank site doing it & if so how
            LGUUQR: on Docs.Google Docs.Google.com no, probably chiefly because of problems expanding access
            LGXKXL: at least some services on Zoho.com yes, but in the form of author(s)
            LGXKZO: wiki.Zoho.com yes, as a subdirectory of the root domain
            LGUUVQ: Sites.Google.com yes, as a subdirectory of the root domain
            LGUURI: WordPress MU/Multisite yes, as a subdomain or subdirectory of the root domain
            LGUUTL: Meetup.com yes, as a subdirectory of the root domain
            LGUUXE: Blogspot.com yes, as a subdomain of the root domain
            LGUUZC: Facebook.com ?
          2. LGUQN8: Pros thru cons
            1. LGURFJ: SIGNIFICANT PRO: establishes very simply who’s responsible for it & the authority on it and probably who’s the owner (by putting it under a subfolder and definitely under a domain (as a subdomain)).
              1. LGURO1: on the bigger scale (which doesn’t now apply here but seemingly potentially could)
                1. LGURPA: this is key to all Internet security: have I reached a domain name I know. and
                2. LGURQA: Programs (such as the JavaScript sandbox) depend on this to operate
              2. LGXOHT: Without this nor appropriate alternative provisions, some serious problems could arise & likely eventually will: from “just” failing to give credit where credit is due and confusion over who’s responsible, to repudiation and phishing & other impersonation.
                1. LGXKQO: And this is how: for a document on a site which didn’t put blog/group ID nor author(s) in the URL, one would have to first look at the content of the site itself to find who the participants of the document would be (owner, author, readers, group).
                  1. Fortunately on most multi-author and other Web 2.0 sites (as popular forums & blogs, wikis, but notably not always on Docs.Google), if, besides administrators, there can be one author, it will be displayed (on say the post or comment) or if there can be multiple authors (as on a wiki) they will all be displayed. But:
                    1. LGXMF0: administrators can typically edit without leaving a trace of who exactly did it that at least ordinary readers can see, which causes problems (at least it causes problems when say on a http://Meetup.com group, a group organizer edits/deletes content or removes a member and Meetup tells no trace of which one did it).
                    2. LGXMMI: On most many, including WordPress & Meetup but not Mediawiki I think, a user can freely change his/her display name, even to that to match another user so impersonate another user. Phishing or other impersonation, plus repudiation, on popular web sites/hosting goes into how this could be done & prevented.
                2. LGY0NZ:The bottom line is problems here seem to preventable, so long as appropriate steps are taken by website designers & administrators.”
            2. LGUOCM: BIG CON: notable problems changing who can access (just this item, or a subset of such items within it’s blog/group ID) as it changes its/their URL, so creating notable problems as broken links, maintenance issues, confusion.  (LGUODI: Here are some mostly real-world examples)
              1. LGUQT8: problems expanding access. If a person or a private group develops some document/text privately and then want to expand its accessibility to other persons, groups, or even the public, they can’t unless they to release it privately to other groups they can’t unless they either
                1. LGX0M9: do what they probably end up doing: get a new URL for it (which IS accessible to these other people) and either
                  1. LGXKBR: copy it there (but then have sync problems between the copies)
                    1. LGUOE6: Adds to information overload & significantly to maintenance. As in event management. Many Meetup events are cross-posted due to the lack of duplication; example this party listing says “there’s currently 9 Meetup groups listing this party, –the largest cross-posting of any Meetup event…”. As well as organizers having to (manually) maintain those different listings to keep them in sync, respondents also have a hard time seeing the big picture of everyone coming (can just see from their group); and for every group to which one belongs which is listing the event, one gets an email about that same event. Moreover Meetup provides no master URL for “the event” (unless organizers think to designate one which they rarely do else rarely announce), and even if one was designated, it would always be tied to one group (via the URL) even if it was being put on equally by multiple groups. Clearly in this multiple listings contribute to info overload  This has not been a big complaint but is clearly a concern.
                  2. LGXKB0: move the text there (but then likely loose the text history there and break any existing links they had to the document)
                2. LGX0OJ: open everything in their group (or give the individual’s password!) to the other people, which they probably wouldn’t end up doing.

                neither are good!

              2. LGURS6: Mostly CON: Handing over to another owner changes its URL, breaking links & confusing people.  I write mostly because
              3. LGX0VV: Problems limiting access.  If a group of people had access to a document and one or more were not turning out constructive here, one couldn’t limit access to this document without giving it a new URL (and the problems that brings to all other uses of the document) else limiting those person(s) access to the whole group of documents they had access to (probably the unfortunate choice which would result, as while it would probably disrupt those person(s) too much, at least that doesn’t disrupt the other assessors).  This probably won’t be as big a problem as the problems expanding access, but still would be a problem sometimes.
          3. LGYEDB: Conclusions
            1. LGUR26: (for all years before this) says AI: NoAI
            2. LGUT0H: Now says AI: I am mixed, now realizing the establishes very simply who’s responsible for it & the authority on it and probably who’s the ownerAI
            3. LGY12K: Now says AI: No, as long as appropriate precautions are taken to identify & non-reputably content participants to avoid the mentioned problems (as impersonation, confusion, etc)  —AI
        3. LGXKVY: author(s)
          1. LGY13A: The problems here are similar to the problems of blog/group ID due to the fact that author(s) also reveal participants, something which may change.
        4. LGUWKD: content ID
          1. LGUWQ6: What type of ID?
            1. LGUWQE: Possibilities:
              1. LGUWUX: Have the path to the page (else final page name/ID) be a somewhat globally unique ID which stays the same even if the page is moved to a different site
              2. LGUWVF: %postid%
              3. and others
          2. LGUWOM: Says AI
            1. LGUW5T: Yes, absolutely include, says AI
              1. LGUWXM: In order to reference this exact page you definitely want to include this. It’s a royal pain-in-the ass for sites which use frames or (use AJAX but (unlike maps.google) don’t provide a way to get a link to that page).
        5. LGUWCL: anchor to particular content within page
          1. LGUWD2: see also Put anchor(s) in the content which are globally unique IDs and
    4. .
  3. LGYMHK: Category[URL LGYMHK] -using this ID

    1. LGYMJK: parent category[Uncategorized] -using this ID
    2. LGYMNI: category[well-designed URL LGYMJK] -using this ID

    3. LGYMNU: I created in http://2.LoveRules.com/category
  4. LGYMGX: Section Well-designed URL end.