Microcosm Feature Suggestions

I agree with a more generic concept of lists, than just events. I tried to do something similar using polls, back in the days of vanilla possibly, perhaps.

The LFGSS cycling club thread was a classic example.

The constant list repetition does nothing to enhance the readability or utility of the conversation

I also agree with the need for bumping.

But, isn't that a more general consideration in the microcosm.app world view of a forum as being about more than just threads?

This thread needs more UML.

Nerged.

IN ORDER TO stop my life disappearing in a meaningless blur,
AS A software engineer,
I WANT to kill UML in the face.

The constant list repetition does nothing to enhance the readability or utility of the conversation

This.

Thread bumps just for adding a name to a list is annoying. Begone!

...

To participate in a conversation... well, what does that mean? Do you have to go through the conversation to find the context for the list of participants and derive meaning?

This is a good point, and perhaps something as simple as allowing the lists to have names or headings would address it:

Events would default to a heading of Attendees.
Other examples would include:

• Interested in joining LFGSS.cc
  
• Willing to assist in the total destruction Ed Scoble
  
• Would group buy rare earth magnets.
  

You're going to destroy Ed with magnets? How does that work?

Willing to assist in the total destruction Ed Scoble

1. snottyotter
   

He doesn't understand how they work.

Like most things.....

There's already a thread for that.
https://www.lfgss.com/thread78723.html

Not willing to assist in the total destruction of Ed Scoble:

1. Oliver Schick
   
2. A owl
   

Well I'm glad I've raised a valid point. And given David more work.

Willing to give Ed Scoble a wink and patronising pat on the head:

1. hippy
   

Or this thread. http://www.lfgss.com/thread3372-13.html

Important thread to have, but 13 pages!

It wouldn't be that long if it was moderated. That's why I edited the first post so the master list can stay there.

Or, shudder, any thread started by GA2G.

Does Event have somekind of superclass ListDriven?

OMG No! I feel dirty just reading that.

First, it's all written in Go and there are no classes, no inheritance, no objects, thus no superclasses as you might imagine or know them.

We have a load of REST interfaces, and these are mappable to URLs and internally some of these endpoints are smart enough to work against multiple parent URLs.

A great example is the attributes stuff: http://microcosm-cc.github.io/#attributes

That allows key:value pairs to be set against pretty much anything.

So you could stuff key:value pairs against a profile: rides = Cannondale, height = 185cm

Or against events: bike hire = available, min age = 18

Now getting back to lists, events has a concept of attendees. And this isn't just a flat list of arbitrary values, it's a list of usernames and only the individual attending or the event organiser can set these. So it's a list of users, with state showing attendance, and permissioned: http://microcosm-cc.github.io/#attendees

It's specialized as we imagine that it has specialized functions in future: Who's attending? I need to send a last minute update via SMS to all attendees, etc.

We could extend the idea of that to other REST endpoints, but at the moment it is a specialized list that serves one function: To indicate attendance of an event.

Now, going back to the question of "Can we add lists". I guess what I wanted to know was how they might be used, what should I bear in mind.

It looks like, from the initial feedback and bearing in mind how I've seen lists used on LFGSS, that you want:

1) The ability for any type of conversation/item to have a list.

2) That the list is made up of who added themselves, and optionally some value along side it.

It's quite likely that such a structure would allow us to implement event attendees in that form (we'd stick the attendance state in the value field), but I can't foresee that event attendees could be extended to that form.

Does that sound like the kind of thing you image... a list of users with an optional value next to the user.

As for the group purchase scenario, the rules around group purchase vary greatly and are usually dictated by suppliers. I can't imagine us being able to mimic the that stuff to any depth, whatever we'd do would be wrong for the vast majority of use-cases.

Some things are best done in a spreadsheet and I'd probably recommend that we just offer embedding of Google Docs.

Bump

List:

1) The ability for any type of conversation/item to have a list.
2) That the list is made up of who added themselves, and optionally some value along side it.
3) TW2

Sounds good.

List:

1) The ability for any type of conversation/item to have a list.
2) That the list is made up of who added themselves, and optionally some value along side it.
3) TW2
4) List of Owls: ["snowy a owl", "tawny a owl", "little a owl"]

That's not a list, that's an array.

It's a list if you program TCL.

I don't see why each list item would have a value alongside it, except perhaps its positional ordinal?

Well, I could imagine use case for such a thing but lfgss doesn't currently abound with them. Hence YAGNI. Is it the group buy situation that you are thinking about, with the value being the quantity interested in?

Also, another thing to note, in line with Oliver's comment is that a list of user names may be too formal. Its really common for humour to be injected into the user names in a list by mutating them in some way that is appropriate to the event or list.

Even the LFGSS CC list has values.

Lists really come in three flavours as I see it:

1) The ToDo list, checkboxes indicating done would be good
2) The participant list, sometimes with additional values
3) The list of random things, but some indication of who added what thing

#2 and #3 appear to be inversions of each other.