Open URLs stored in the Location field

[kristjan]

Calendar events now often contain URLs to video meetings from Zoom, etc. Those are no use to look up on a map, so open them directly instead.

[deanishe]

Calendar events now often contain URLs to video meetings from Zoom, etc.

Good idea, but I'm not a fan of the implementation.

If the workflow should support opening URLs in events, then it should support them well.

I'm sorry, but I won't accept the PR as-is because it appears to be thrown together (compiling a static regexp in a loop???) to support the particular way you use Google Calendar (HTTPS URLs in the Location field).

If I accept the PR, other people will submit follow-up feature requests ("My URL is HTTP", "My URL is in another field", etc.), and I'll be left to deal with them.

[kristjan]

Good feedback, thanks! Sorry about compiling in a loop, when I put this next to the other Location code I didn't look enough at the context.

All the extensions I've seen that add video meetings to an event use the Location field, though Google Meet appears to use a more native implementation. We can also look at the Description, but I think we'll need a known list of meeting domains (Zoom, Bluejeans, etc.) to do that, since it could contain all sorts of non-meeting URLs.

What do you think of this approach?

• Check first for a Meet ID in Google's native fields
• Fall back to a URL in Location
• Fall back to a URL in Description matching a known video host

I think that'll be a relatively simple approach that covers most use cases.

[deanishe]

since it could contain all sorts of non-meeting URLs.

Why is that a problem? There's nothing special about videoconferencing URLs, is there? If the event has a URL somewhere, the workflow could offer to open it. I don't see any reason to put in a bunch of extra work just to limit URL support only to videoconferencing.

Location handling does need fixing to open URLs in your browser instead of passing them to Google/Apple Maps, but why not add a separate "Open URL" action that's available if there's a URL in a field?

Check first for a Meet ID in Google's native fields

Yeah, that would need to be special-cased. I wonder if it should be handled as a URL or as a Location. I'd say "URL" because I could imagine some people holding Meet videoconferences in a meeting room and putting that in the Location field.

[kristjan]

If the event has a URL somewhere, the workflow could offer to open it

True! I'm thinking more that there could be a link to an agenda and a link to the conference, and we probably want to prefer the conference link. It seems more important to get you in front of coworkers than to show you what they're talking about.

When there are multiple, we could also give you the choice, but that adds another layer of menu and some of these systems put a few URLs in that all point to effectively the same thing. Below is a rather robust example with two documents, two Zoom links (but only one is the meeting), and a whole bunch of linked telephone numbers (that are tel: and can be filtered).

a separate "Open URL" action that's available if there's a URL in a field

That sounds good 👍 It looks like Alt and Ctrl currently activate searches (though with nulls), so maybe using Shift?

I'd say "URL" because I could imagine some people holding Meet videoconferences in a meeting room and putting that in the Location field.

Agreed. At least in my head, the distinction is a virtual place vs a physical one, so that could make a nice split when you have a team with individual members doing one or the other.

---

[deanishe]

It looks like Alt and Ctrl currently activate searches (though with nulls)

Those are Alfred defaults if the workflow doesn't define any actions of its own.

The workflow only uses ⌘, and then only if a Location is set. I would use ⌥ for the Open URL action, as there's an option key on each side of the keyboard, and ⇧ can be used to open the Quicklook preview.

When there are multiple, we could also give you the choice

Fixing the Quicklook preview to render HTML in data fields would be one solution to that (and probably needs doing anyway—I'll create a separate issue for that). IIRC, links aren't clickable in Quicklook by default, but there's a hidden option to turn that on.

Rather than adding a submenu for all URLs (which might not be very meaningful without the surrounding text to give them context), I'd suggest adding an "Open URL" action to ⌥↩ to open the first URL found that isn't the same as the one in the Location field (which would be handled via the Location code and ⌘↩).

There's also the question of whether such links always use http(s), or application-specific URL schemes (e.g. zoom://...).

[kristjan]

That all sounds great! I'll get on it

There's also the question of whether such links always use http(s), or application-specific URL schemes (e.g. zoom://...).

All the ones I've seen so far open a browser first, and then either load the web client or bounce you into the app if you have it installed. I'm pretty sure we'll be ok starting with just http(s), and I'm happy to help you field support and updates if people pop up with more.