1. 33

    1. 4


    2. 6

      Fun example: somebody sent me a URL containing upload/images/imager/upload/aimages. Heard you liked content management…

      1. 3

        Abso-bally-lutely. Sharepoint links are (1) horrendously long and unreadable, containing AFAICT at least 2 UUID-sized codes, and (2) don’t even use those bits to robustly identify the target. Instead, when a Sharepoint file gets a new name or gets moved to a new folder, your bookmark breaks.

        Contrast this with MediaWiki – a different usecase, sure, but it gets its URL system very right. Especially the redirects and disambiguation pages, which let Wikipedia keep its URL hierarchy flat, and create a web instead of a tree.

        1. 2

          SharePoint user here: I’ve had no problem using meaningful URLs (like https://contoso.com/subsite/Documents/Example.docx) for files and sites/libraries/lists. In the latter case, it can redirect to the appropriate page, and the former is what it usually uses unless you’re using Web Apps. (Since 2013 though, it seems they did change it: https://contoso.com/_layouts/15/start.aspx#/Shared%20Documents/Forms/AllItems.aspx for site pages; because SPA.)

          1. 1

            I think links have worsened again since 2013: here’s the sort of link our install inflicts on me.


            1. 1

              That’s mostly just to preserve what form and view is open - which matters for the hardcore users.

        2. 1

          Reddit and stack overflow do this perfect, give an ID which actually locates the resource but also put the title in the url so you can see what it is before you click. No clue why huge websites like youtube can’t get this right.

          1. 1

            Many years ago when we implemented our CMS, we decided to use urls like example.com/aaaa/bbbb/cccc/dddd (content is structured like a tree). This was terrible idea (obviously). After we let the users in, not only were they easily creating structures ten levels deep, but also constantly moving and renaming items.

            At first we tried some clever tricks to navigate users where necessary even after items were moved/renamed, but it was still terrible pain and had to be rewritten.

            Now the content is still a tree, but urls are like example.com/language-code/id-name where only id is important (similar to SO), name can be whatever (but we redirect you to proper one, if not present/wrong). This has worked very well for many years.

            1. 1

              The tree structure is nice, but it definitely has limits. Could your system have handled that issue by tracking URL changes so that users could be automatically redirected?

              1. 2

                Probably could, but as I said people went crazy with moving and renaming items. Tracking all these changes wouldn’t be impossible, but still at least tidyous. The main issue was still super long urls with like ten levels. Actually I was ashamed when sending link to someone :) We kept tree structure, but it is mainly for organizing items now.