You are reading a single comment by @Velocio and its replies.
Click here to read the full conversation.
London Fixed Gear and Single-Speed is a community of predominantly fixed gear and single-speed cyclists in and around London, UK.
This site is supported almost exclusively by donations. Please consider donating a small amount regularly.
@Velocio
On #1 we agree on non-gibberish permanent URLs.
Not sure what your definition of human parsable is.
At the moment the URLs describe the type of thing /events/{id}/ and use the identifier. It's very clear that it's an event, and it's clear that it's event #{id}
But if it's to have the thread titles in the URL then this breaks the goal of permanent URLs as titles can be modified (and frequently are on LFGSS). Such words in URLs may be a good SEO ploy for the English language but it's a really ugly thing when it comes to languages with characters outside of the ASCII range.
Such URLs can also result in confusion and are gamed on some site because of how they work. To make such URLs act like a permanent URLs, both the {id} and the keywords are put in the URL but only the {id} is used to fetch the thread.
Example of what happens on such sites when people make links:
Original URL:
http://it.slashdot.org/story/13/06/27/0047255/hackers-steal-opera-signed-certificate-through-infrastructure-attack
New URL:
http://it.slashdot.org/story/13/06/27/0047255/foo
Silly URL:
http://it.slashdot.org/story/13/06/27/0047255/david-cut-your-hair
It's pretty silly to include bits in a URL that are totally unnecessary just to reach some arbritrary goal that only works in the English language. And it's far nicer to have shorter, highly readable URLs rather than these behemoths.
I also think in their URLs that having a story identifier that is 7 digits long negates the need for the date to be in the URL. If you have the date in the URL then the story identifier could have just been the number of the story that day... /2013/06/27/story17
What I prefer are short URLs, in which every part plays a purpose, that is human-parsable, that works in all languages, that is permanent, that will continue to work when new features are added (we aim to allow microcosms to be shareable across sites, i.e. the Mechanics one on LFGSS could be configured to permit sharing, and Glasgow FGSS could make it appear on their site - thus Mechanics becomes one fantastic resource for all).
And our URLs reflect those things.
https://lfgss.microcosm.app/events/2/
https://lfgss.microcosm.app/conversations/1/
On pagination, currently we are using the offset method in the API, and that is reflected by the web client:
https://lfgss.microcosm.app/conversations/1/?offset=25
We have discussed using ?page=2&count=25 or something on the web client, but don't want to choose a method that has a strict concept of pages. We may later have an interface that doesn't share that concept (such as an infinite scroll for galleries and photos). Consistency is important too. We'll carry on stewing over such things.
On #2
We agree entirely... the HTML version will be a nice and simply presented version of what you might expect to see on the site, with both HTML and text parts.
On emails, we are not yet sure... but what you get might vary according to the thing you are being notified about. If it's a truly private thing, then given that email is plain text, unencrypted and effectively publicly readable, we may only send a notification. Whereas if the thing is a public post on a public part of the forum, then we might send the whole thing and then let you reply by email.