Microcosm Feature Suggestions

You need to put that in a nice MS Paint drawing for anyone to be able to take the suggestion seriously.

Rep^

Reported.

lol

I've said it before somewhere, but a simple MS paint style drawing applet would be amazing; especially for things like explaining stuff in the mechanics forum, or for ed to draw cocks.

Something like this: http://mudcu.be/sketchpad/

Might be an idea... we have a lot of work and other priorities before we could even begin to get to something like that.

Or even more simply... http://mudcu.be/sketch-js/

And that is open source: https://github.com/PortlandRTC/Sketch.js

Two things that are a most probably quite minor at this time in development, but are really meaningful once you start to use the forum.

1. Part feature request, part question:
   · Meaningful, human-parsable URIs for threads/pages/microcosms.
   · What's the best way of attacking this, what are the problems with it, and is having threads with the same name (and a numbered suffix) a problem, per domain?
   
   

(tell me if/why I'm wrong about this, by the way).

1. For when sending out subscription-based emails:
   · have nice, well-formatted HTML (including images — or quick links to images), with a text-only fallback. (or even better, let the user choose between plain text and HTML).
   

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.

URL best practice is a changeable thing. Here's what I currently recommend to those with the luxury of choosing their own URL pattern:

As a general rule URLs should be usable as an API - that's as human-readable/memorable as they need to be. Whether you do that by numbers (as long as they are short enough) or words is up to you. As you say, once you go multi-lingual, words can be problematic.

https://lfgss.microcosm.app/conversations/1/?offset=25 is less memorable due to the query string. If you can use routing on the back-end and the history api on the front end to allow something like
https://lfgss.microcosm.app/conversations/1/25 then you a) hide your back-end technology a bit more, and b) make more memorable URIs.

With identifiers, it helps to make them alphanumeric, and if possible to split them up into groups of 4 or less, (with slashes or dots). Your routing should process the same identifier with and without the dividing characters, and be case insensitive, so that people can speak URLs and be understood. (that's also why dots or slashes are better than hyphens or underscores)

Amazon do all the things Velocio described - for example
"http://www.amazon.co.uk/gp/product/B0093XXFZM/" will take you to the product but they add all sorts of tracking and metrics stuff as a query string, so if I click it from the homepage I get
the same link but with a whole load of crap after it as a query string. Clearly their routing only goes so far
And if you search through their page source code you find
which must only exist for Google, because I couldn't find a way of getting that link by sharing or anything, It doesn't work without the alphanumeric ID.

(now I've done that Amazon are convinced I want a load of James Bond DVDs)

With pagination, incidentally, copy search engines and go with start offset and number of items to fetch. This is easier to code and doesn't back you into a corner with defining 'pages' of certain sizes, and you can also use it internally for infinite scrolling and JSON calls.

Pagination is already using the offset model for the API: http://microcosm-cc.github.io/#basics-pagination

Though we're still wondering whether we'll also support timestamps and offset... so that it's possible to query items from a moment in time (last time a client checked) really easily.

I agree with much of the above, but I think URLs shouldn't be a law unto themselves and should be balanced with other parts of the application, protocols, etc.

I end up thinking that as HTTP very clearly defines how to use query strings and page fragments that these things should never be coded into the page/resource part of the URL.

For example LFGSS does this:
https://www.lfgss.com/thread100073-2.html

And I think that should be:
https://www.lfgss.com/thread100073.html?offset=50

Or:
https://www.lfgss.com/thread100073.html?page=2

The URL is for the thread, which part of the thread is a query upon the thread.

I really think there is a balance between the requirements and rules of every part, and trying to perfect a URL by breaking other parts is not the right thing.

I also don't think that using a URL correctly exposes anything about the backend system.

Of the 3 then the middle one would be my choice, because it would be nice to give the user control over how many items they want on each page, and offset allows that.

Ideally it would be nice to have http://www.lfgss.com/thread/100073?offset=50 or perhaps http://www.lfgss.com/thread/100073/offset/50

I was originally coming from the "put the thread title in the URL" camp, but given both of your extremely well detailed posts, I completely agree.

VB, do you have a reference in the w3c or similar for resource/query string usage?
Just read through your API.

Perhaps the problem I was thinking about was looking at a link to a thread cross posted in another thread. It's often said as ~"see this thread: lfgss.com/thread10023.html".

Perhaps this is more about hinting, inline with the link, about which thread it points to. E.g.:

http://www.lfgss.com/attachment.php?attachmentid=69954&stc=1&d=1372713673

to

http://www.lfgss.com/attachment.php?attachmentid=69955&stc=1&d=1372713673

(quick mockup, but perhaps useful?) It does mean more API calls.

2 Attachments

VB, do you have a reference in the w3c or similar for resource/query string usage?

It's in the RFC: http://tools.ietf.org/html/rfc3986

And there's no reason we can't make sense out of URLs, but I wouldn't want to make a URL not a URL either... but providing more context seems a helpful thing and sensible to do.

help.microcosm.app seems to have vanished, was it supposed to have done?

I was going to ask if the sage concept could be included, maybe more explictly than in other places, something like a tick box that says 'don't bump this thread' or similar

It's gone to http://meta.microcosm.app

What is the sage concept?

Sage, from 4chan (or that's where I've seen it). If you want to post to a thread, but not bump it, you pop sage in the email address field, it stops a thread being bumped, effectively ignoring that post from the last posted time in a time based sort.

Obviously it wouldn't work quite like that here, as microcosm doesn't have the same fields, but a 'sage' field might in some places be helpful.

I had mostly thought of it in relation to things like this thread - https://www.lfgss.com/thread109089.html where anyone explaining to the person in the thread about how and why he's 'breaking the rules' simply gives him the free bumps that he's wanting. Sage would allow you to post to it, and not give the desired bump.

That wouldn't be a hard thing to do. One small addition to a table and that's it.

Put the suggestion on http://meta.microcosm.app and we'll come back to it in the future.

In Jive community forums you have the ability to @mention other forum members when talking about them in the posts. They then depending on their notification settings, recieve an alert, message or email about the activity.

Ive always wondered what the point of the 'spotted' tread is without this feature.

In Jive community forums you have the ability to @mention other forum members when talking about them in the posts. They then depending on their notification settings, recieve an alert, message or email about the activity.

Ive always wondered what the point of the 'spotted' tread is without this feature.

Minus the notifications bit, this is built already.

Whats the point of the @xxx without the notification feature?

I would guess the notification system is yet to be built, as opposed to not happening?

Whats the point of the @xxx without the notification feature?

Hashtag-like search.

But the notifications are an important part too.

I would guess the notification system is yet to be built, as opposed to not happening?

Most of the back-end is already built, but there is no useful place to surface this data yet and it has dependencies on other features we needed to have built (such as actually sending emails, having permissions protect the notifications, etc).