Multiple calendar entries - there has to be a better way..!

#1

Hi All - I’m wondering if there might be a better way to organise the calendar bookings? Today for example there are four separate entries with different times, which makes it a bit clunky as one has to look across each of them. If they overlap, should we then make a booking on each corresponding to the times that host has specified?

  • 05:00Space Open + X1 Carbon Booking

  • 09:00 Space open + laser booking

  • 19:00 Big CNC + MIG + Woodshop induction 7pm

  • 11:00 Space open 11-1

Wouldn’t it make more sense to have one single entry for each day, then the hosts/shutter access people put at the top the times they are in? Then it’s straightforward to see what times are available. Sorry if this has already been discussed and this is the agreed approach.

3 Likes
#2

Hiya!

Yea, the booking system is not great…

I was also thinking we should try one entry per day - but definitely open to suggestions on other ways to do it that don’t involve a ton of custom software development!

Cheers,
Andy

2 Likes
#3

With the present system, I’m sold on Andy’s suggestion of one per day and I started doing it that way. e.g. yesterday I was hosting in the morning and tacked that onto an existing hosting in the afternoon. It’s much much better and much easier for people to see when equipment is booked that day.

1 Like
#4

adding 2 cents here - the last one is starting 6 hours before it’s been added, which should be prohibited by software tbh, it’s extremely misleading

#5

I found this forum post which I presume is @Martyn_Thomas: https://meta.discourse.org/t/use-case-question-room-equipment-booking/287071/2

Is it still true that we’re unable to upgrade to the latest Discourse release because of Pavilion’s Events plugin? Do we use https://github.com/discourse/discourse-calendar for our calendar?

And is the aversion to custom software development to avoid the space having to own/manage that long term?

#6

We can upgrade to the latest -1 (the most recent release doesn’t support the Events plugin) - which we’re working on doing soon.

We use Pavilion Events plugin because the standard discourse calendar plugin is missing key features we need.

The aversion to custom software is cost and maintenance. If anyone knows EmberJS and want to help the Pavilion Events plugin or Discourse Calendar plugin…fork thier distros and have a go :slight_smile:

4 Likes
#7

@Martyn_Thomas What version of discourse do we run right now? v3.1.2 or previous?

The thread where someone took a stab at updating discouse-eventslook like it stalled out, I’ll give it a try. Would be nice for us to be able to stay on the latest version of Discourse if possible so we can benefit from that.

#8

We are on an older version - we will upgrade soon, just waiting on the @directors to work their magic on the back end.

The current plugin we use works on the latest-1 version of Discourse so we’ll be upgrading to that.

As soon as the plugin supports the latest version (or we find a suitable replacement) we’ll upgrade to the latest version, as we want to stay upto to date as much as we can

#9

Sounds good. If there’s any way I can help with that I would gladly spend the time.

In the meantime I’ll get Pavilion Events functional on the latest discourse and send them a PR

2 Likes
#10

At this stage - we’re pretty much ready to go…just waiting on a server move.

The thing that would be a big help is finding suitable alternatives for the booking process (ether Pavilion, or something else)

(If you want to poke with tools that might last/be officially supported - check out the calendar plug in, it’s missing a few features that would make it a suitable replacement for Pavilion - https://meta.discourse.org/t/discourse-calendar-and-event/97376/412?u=martyn_thomas )

1 Like
#11

One of those bookings is mine. Let me explain myself: usually, I do not know when I will be in the space with much foresight, but to still help others know when I will be in and the space will be open I make bookings even last minute (perhaps what others with similar story can try to do? re: Shutter Access - use it or lose it). Usually, they do not overlap with others but are adjecent to one; also they tend to span across days as I like to use the 3D printer overnight when there is least possibility of me using it when others need/want to. The booking you mentioned was different though, it spanned over the two other bookings present at the time. At the time I saw couple of possibilities:

  1. Dice up my booking into sections that fill the gaps between the other bookings (I thought this would be even worse than this; not to mention cumbersome).
  2. Delete the other bookings in favour of mine and transfer all the tool bookings appropriatelly. I decided no to do this because it was a) quite late and I was lazy; b) I thought some might perceive it as rude.

In retrospect, I should have gone with option 2 and will do so from now on. I agree that sticking to one booking per day where applicable/within reason (I am sure there are places where this won’t make sense) is the best option.

To add my two cents to the Discourse update/replacement discussion. I was talking with @asander1 the other day that I would be keen to have a look for some alternatives that would fit our bill (preferrably free, self-hosted, open-source, easy to setup and maintain) and I must say that I failed. Discourse seems to be the best maintained and supported forum tool. In terms of space/room booking solutions there is nothing that I could find that does not endup being even more cumbersome to use (given that our use case of users being able to ‘open’/‘make available’ a room/the space which enables others to book other room/tools/spaces is rather niche). I think sticking to the latest version of Discourse and agreeing on a good workflow to space bookings is the best option.

1 Like
#12

“Hey Google / Alexa…. book me in at the Makerspace from 11am to 4pm next Tuesday”

Imagine if it was as easy as that…. Could it be?

The member is already logged in - no need to enter the user name which currently have to do several times. We are all in the same time zone. No need to have that mess things up. We can have more that one member hosting at a time, so overlaps are easy. Working out the start and end times for bookings on a day isn’t hard either - the user shouldn’t have to set those.

As it is, it is often a frustrating experience which is really off-putting. That’s a problem because people are put off using it.

There are plenty of JavaScript widgets for setting time which could offer a nice easy to use user friendly interface. One might click one button on the Discourse calendar page to bring up that interface (no need to ‘add a topic’ and then scroll down looking for the booking topic - grrr). User sets the time span and that updates a database or backend, and that makes an update to the calendar. If it’s hard to make that work with the Discourse calendar, then let’s have a separate calendar system that link to via Discourse (with shared authentication/ credentials so only log in once).

I’m suggesting we start with an idea of the ux ui - user experience design and user interface design - and then see how we could get that working so a booking interface and calendar / schedule is easily accessible on Discourse - no need to log into a separate site. There should be some way - XACML, OAUTH or whatever.

#13

Sadly no. Not without a LOT of work and a lot of custom code to maintain.

Ive spent many evenings looking at this and tried doing a widget to help with booking, Discourse does not make it easy and the documentation is awful. After a while I gave up. @Kyle has more experience with Discourse and has an example widget for the basics but last I saw it couldn’t solve the double booking etc issues and it was waiting on the discourse software to be updated.

Ive have also tried looking for alternatives outside of discourse and came to the same conclusion as @potatoman

And if we go with something outside discourse the problem then becomes integrating with Authentication/Authorisation (I am pretty sure discourse does not provide OAUTH). The best option for that is probably using Wordpress as a single sign on system, but I believe there were issues doing that as well? Plus there just aren’t any good options, so it would have to be something custom, which again is a lot to maintain.

Its really not as easy as saying use an existing JS widget.

#14

Thanks for that clarification @tmilner and for putting that time and effort into trying to get something better.

What about a completely separate app for making bookings at the space? Having an extra sign on is something we could live with. We can keep Discourse for everything else.

#15

A separate app is possible, but it would need to be something custom if we want to avoid the current issues, and we would then need to sync the roles and permissions for each user between discourse, wordpress and this new app.

Its achievable, but my understanding is there is no desire to take on a large software project like that. If the maintainer leaves it would become very difficult to keep going.

1 Like
#16

Discourse does have an authentication API:


but as you say, actually making a custom solution is the higher bar!

#17

Hey @carb - Not sure about @Kyle - but I don’t have any time for Systems anymore, so will need to hand this off so I think we can use more help… We are probably waiting on me to do something, but I am not doing it - so maybe we can meet up this week?

Cheers,
Andy

#18

Interesting thanks Tom, I didn’t look too closely as that as I thought an external system was off the table. It would be one less hurdle to deal with if we ever did go down the custom route.

#19

@asander1 Im happy to help when needed with systems, although I am unsure how much time I can actually dedicate to it. If you need extra hands with the server move let me know.

#20

Yes please - @kyle - thoughts on how to proceed?