Relative time… moment.js…
To be fair the clock was down to my dyslexia.
Train/Bus departures board
Already using moment on the backend for… something.
It’s a bit calmer looking. Turns out, when you’re doing Cleverness with busses, they don’t take all that much space up. Also removed the TOC column from the train departures - don’t think it adds much and it makes it wider.
Bearing in mind, it’s late and there’s not many trains right now, there’s some free column space underneath the calendar thingy - which could be used for a picture (and name) of the last person to walk through the door, or something.
1 Like
Looking good, from a design perspective the letter of the stop and the number of the bus are confusing.
Hyperarchically the stop letter is more important as it indicates the start of a section, but area wise it smaller, it’s a bit confusing.
I wonder if the bus numbers need to be reversed out, or just black on white?
As for the TOC I don’t know what that is? Table of contents?
Trains could easily be stacked in the same way as buses I guess.
If you wanted to put it more on brand mirroring the homepage aesthetic, rather than Discourse might make sense, Discourse is hard to style which is why it looks different.
Some people might have privacy issues with this, but I’d love it. There are people in the space that I know have been there a long time and I should know them and I’ve probably been introduced but I’m rubbish at names so a little gentle reminder would be a good thing!
1 Like
I agree about the stop headings - perhaps they need a bit more padding around the top of each one so the stop letter is more obvious? And perhaps make them a smidge bigger? It’d mean we’d have to make all the other headings on the page bigger.
TOC = Train Operating Company (sorry, railway jargon!), i.e. Southeastern or Thameslink. I guess I could stack the trains but… dunno, that feels a bit, wrong? With trains you can better express delays/cancellations than with busses - so you’d loose some of that if you stacked them.
The reason I went for the discourse-like look was because it had the elements I needed - namely a blank space at the top to pop alerts up, and a logo in the corner. Also, I wanted to use Bootstrap 
Well, this was my thought.
I’m hoping that people who have uploaded a picture are happy to have it used on an internal system (literally, internal) like this. At the very least, a name might be good - would members expect to be able to walk through the door without anyone being able to find out who they are?
1 Like
I would hope that as a community we buy into the idea that the more of us who know and are known to each other the better.
Would be useful to know if members have objections to this though. There might be good reasons.
1 Like
This isn’t deployed yet, and we haven’t rigged any proper infrastructure for it’s actual display. Let’s make a page that sells the concept, and then propose the feature.
This has been brought up in the past with good support from members when we were talking about using the LED display.
Exactly. I’ve changed my photo on this site to hopefully better represent what I actually look like.
Also, theme tunes…
2 Likes
Whilst theres’s some discussion about this API, Is It possible for the unknown tag notifications be removed from discourse, and made visible only to admins on the membership system? There’s some problematisation hidden in that process that needs some thought
1 Like
In essence, as usual, all I’m saying here is: ‘we’re always open to feedback and members expressing their views and concerns’. I can’t imagine a good reason for objecting to having your name announced as you enter. That doesn’t mean there aren’t any.
1 Like
I’m happy to discuss what I see a potential vulnerability, but not on the public side of Discourse. @systems? + @Courty
1 Like
Can I suggest @naxxfish be brought into this (edit: above post) discussion. He should be having a hand in making the API do what he needs it to do, etc.
@tobyspark so, I’ve got a lashed up example of how the announcing could work. It’s less than ideal (and involves scraping HTML and cookies and other such nonsense, it’s a tad fragile), but it could be demo’d in the current state without any extra work on the API.
Incidentally, I’m more than happy to help @systems with some of this stuff if their time is contended with other things (as previously mentioned).
Importantly, the scope of said feature should be stated: events would only to be shown on a dashboard available to be seen within the space, and nowhere else. It wouldn’t track you, or log your visits, any more than the membership system already does. Any events obtained via the API would be transient, and would only be displayed for a limited time (say 1 day).
1 Like
@dermot/@tobyspark/@naxxfish I am confused… The API for announcing entry to the space is already in the GitHub and the API was written to Chris’s needs.
The data is already visible to anyone who is in the space by looking at Discourse or the Membership System.
All that is needed for Chris to be able to access the data with a proper API is for someone to figure out the issue that I’ve contributed code as an outsider.
Frankly it seems like ridiculous bureaucracy not to trust me to maintain code I spent weeks writing for free for Makerspace’s benefit.
@peter_hellyer FYI: The Discourse posts that go into that bar at the top come from control-node not the membership system, this will presumably , part of tool control will presumably require that this is replaced but given that systems won’t even reply to me I can’t tell you what they are doing about this.
The original plan I had was for this to be replaced with something based around MQTT.
I still maintain that logging to Discourse isn’t the right solution and we should be moving away from using that feature to just having the membership system create a small page that goes into a window in Discourse, it would fix the issues of delayed event notifications and inaccurate times.
In the latest updates in GitHub it removes members access to update their own tag because this is a security flaw, and I agree from a security perspective it isn’t a good idea to post easily cloned IDs online.
I would argue that going back to my original suggest that unlogged tags go into the events stream and that directors can click to assign a user that tag from there would be best.
I figured that getting that code running live would be a little bit complicated and may take a little while - no bureaucracy my end!
Tell you what, I’ll make it an feature that can be turned on and off - if anyone has a problem with it, we can turn it off. Sound okay?
1 Like
a) there is no slight on your work or ability
b) this isn’t maintenance. this is new features.
it’s plainly sensible that an obviously capable member doing work interrelated with the membership system could start to explore that codebase, at that point.
Er, so anyway…
So I’ve set the coordinates/station code to be near me for testing purposes. Whilst pretty bad for anyone going through London Bridge today, it was a good opportunity for testing edge cases for when there is disruption.
1 Like