Nice idea, but seems to lack timezone awareness, which puts me off completely.
Maybe that's being developed, but the American date format with no timezone being described as "English textual" (say what?!) seems to be ignoring all the standards for date and time (eg. RFC3339[1]), yet other parts of the docs clearly show awareness of RFCs!
If you're pushing events to people, presumably you know exactly when they're going to happen, but with this API you're saying "here's an event, just pick your own timezone!"
Nice idea though, it'll be interesting to see how it develops.
Yes, I don't understand american/English dates and time. I don't know when "04/06/2019 09:00 PM" is. Is it April or June? 0900 or 2100? Let me send an ISO8601 time as all other APIs accept.
"09:00 PM" almost universally (is there any case or format or app that does it differently?) means 21:00 in 24-hour clock format. Not 09:00 (in 24-hour clock).
PM means post meridiem. That's Latin, but you don't have to remember it. If you simply remember the P means 'post', and the 'M' means the exact middle of the day (12 noon) then you know 12 PM is 12.00 (after noon hence afternoon) and 12 AM is after midnight or 0.00 (the hour after previous day's 23.00 / 11 PM). Then you just need to remember morning is AM, afternoon is PM, evening is PM, and night is AM. That's it. Yeah, I find 24H system easier, but its what my native locale uses, so I am biased... (as is everyone else)
This is in fact so simple to remember that street signs in San Francisco, where AM/PM is native, use 11:59am/pm or 12:01 and never 12:00 to avoid ambiguity. Street cleaning from 12:01am to 3:00am, for example.
Only thing to remember there is: .00 means new hour. Which the number before .00 denotes.
Caters to lowest common denominator.
I had all this explained on elementary school (which was boring and slow as fuck) during English class, and we don't even use 12H system in The Netherlands. It is quite frankly as simple to remember as a logic (tho not necessarily common) grammar rule.
Yes, I'm not trying to claim that AM/PM is ambiguous, but that me as a person not used to the system (basically everyone except US and a few other countries) have no idea which is which. :)
A native Floridian once told me that the New Year's fireworks display would be starting at “12 PM”. Confused about why they’d be shooting off fireworks in the middle of the day I said, “12 PM!?” She rolled her eyes and made air quotes with her fingers and said, “Well, AM”, as if I was being extremely pedantic. To her, AM meant morning and PM meant night.
Having worked on the UI of an event-related service, I can say the error rate is much lower if you go with the ‘11:59’ workaround. In addition to the confusion about whether 12 PM is 00:00 or 12:00, there’s confusion about which calendar day 12 AM falls on. When does a Friday midnight movie start? 99.9% of people will show up at the end of Friday, but in a literal user interface you’d have to choose 12 AM Saturday. I thought of fireworks girl very frequently when I worked on that UI.
"Midnight" doesn't solve the second part of GP's problem:
> In addition to the confusion about whether 12 PM is 00:00 or 12:00, there’s confusion about which calendar day 12 AM falls on. When does a Friday midnight movie start? 99.9% of people will show up at the end of Friday, but in a literal user interface you’d have to choose 12 AM Saturday.
Americans use DD/MM/YYYY (regardless of delimiter being e.g. / or - or .). We Dutch use MM/DD/YYYY. The latter results in sorting correct on month if its annual data. Over multiple years it breaks. ISO 8601 has my preference, though in MS Office I need to set to Japanese cause my version lacks the setting.
9.00 PM is very clear to mean 21.00 in 24H format. What isn't clear is if 9.00 is 12H or 24H format. 9.00 AM or 9.00 PM is. However if you may reasonably assume the user uses 24H format, it is clear. It always takes up less space to use 24H format, though 12H format is always clear. Except for TZ (timezone), both all time suffers from that.
[EDIT]Oops I messed up, and that's why I dislike these and prefer ISO8601. Although one nice thing about DD/MM/YYYY is that its little endian (which is easy to remember for laymen as going from small to big). Keeping rest of comment as is.[/EDIT]
American software engineers use ISO8601 or RFC3339 ... I just wrote 20210108 in my journal this morning (referring to a podcast episode published yesterday).
I'll admit I might be annoying to others ... my wife is specifically irritated when I write a time in military format (but my son has no problem reading it from my phone).
> I am pretty sure that most of South East Asia (dunno about India and Nepal) use YYYY/MM/DD.
I think you might have meant East Asia. I know Japan primarily uses YYYY/MM/DD.
Singapore, Malaysia, Indonesia, Thailand, Vietnam, Cambodia, Laos, Myanmar, etc (South East Asia) conventionally use DD/MM/YYYY. Interestingly, the Philippines seems to use MM/DD/YYYY.
Thank you for your comment. There is indeed the possibility to specify the timezone, but the documentation is obviously not detailed enough on that. I'll clarify that.
You may not want to offer a free version. Freeloaders don't convert and they become a support burden whether or not you offer support to them. Once you want to shut off the free version, which you will, you're going to make those people who used your thing and didn't value it enough to pay you for it mad. They wont convert, they'll just get toxic, because they'll feel entitled to your free service. A free option isn't worth it.
Free users help making a robust product avoiding having tones of bugs/lacks discovered by paid users. Running an ecommerce warehouse integration platform, is not easy to come forward with all business cases / use cases beforehand. Just look below, a dude says it lacks timezone support. Valuable information. Value provided!
I agree with this advice for SaaS in general, but there are exceptions. Eg Typeform and Calendly and Dropbox all grew virally through their free tier. Given that this product is a bit similar to Calendly, perhaps a similar effect can be achieved.
Thank you for your comment. Defining the price and associated features was really not easy for me; I hesitated for a long time but you gave me some very good leads!
^^ This the kind of user you don't want. Someone who uses your service but thinks you're charging too much. You have to ignore customers like this who demand that you charge something that won't feed your employees, because there will be enough customers that will pay what you want, or you just don't have product market fit.
And with that logic you will be stuck at a small size because if you ever want to go after a larger audience you will have to cut prices to your existing customers which will be hard after you get fat and happy by over-charging.
Are you speaking from experience? Free users don't provide publicity, and them not converting isn't a problem with the service. You told them exactly how you valued your service and that's what they expect to pay for it. Nothing.
They're going to be toxic to you, in emails and on your support chat or @'ing you. They're going to drain your energy and make you upset. Nothing good will come from it.
Basically any popular SaaS in the wild today would disagree with your "Nothing good will come from it" comment as 99% of them offer some sort of free plan.
It's really hard to start a service from 0 and get users to join the platform when it's new. Imagine then that there is no way for users to try out the platform before subscribing to it, uptake will be even lower.
You don't have to reply to every chat and communication channel, especially if it's clear that you've already tried to help the user and it's not enough for them. Ignoring is a powerful tool many forget.
I may be naive in this, but aren't most people not assholes? Including free users. I would guess that most free users are nice enough and would appreciate the work you do. Also, making a product free is nice because if it is really cool, users will advertise for you. If I love a product I will share it. Simple.
Maybe OP is jaded because a couple of bad free users trashed his work.
I hear you, we have different experiences for sure, which is why the issue is not black or white. I also have around 10 years of experience and would guess neither of my projects nor the projects I work on would be successful unless we had a free tier.
If you’re looking for an alternative approach, I built this Add To Calendar Ruby Gem[0] which generates URLs for all the common Calendar platforms. There’s also this reference repo[1] which helps explains how to build your own and lists some other libraries in various languages.
Thank you! Yeah, the ics / iCalendar part of it has a spec[0] and is reasonably easy to deal with. But Google, Yahoo and Outlook Web/Office 365 all have their own take on URL construction which can be painful!
(There also is outdated pricing information in your docs)
One thing that would make this really useful is a frontend widget that abstracts away many of the common complexities that arise and right now still have to be learned by everyone using this API. E.g. learning how to correctly construct recurring events and implementing a minimal UI for it would still be a pain even with this API. Algolia and their instantsearch.js (and React, etc.) packages are a great example for that where you get the faceting display logic for free.
{"error":true,"message":"SQLSTATE[42803]: Grouping error: 7 ERROR: column \"activities.created_at\" must appear in the GROUP BY clause or be used in an aggregate function\nLINE 1: ...NTH FROM created_at) as month, EXTRACT (YEAR FROM created_at...\n
I love calendar tools and my friends can attest to that. I think I've built at least one calendar app every year for the past however long.
I love the idea of a calendar API (another example is Nylas - https://www.nylas.com/products/calendar-api/) b/c it means I could build for EVERYONE and not just a gsuite specific app (which is what I tend to do for simplicity of APIs). The problem I've seen with these is an inability to grow / monetize at the rate startups need to, and, while I love this, things I'm curious about are:
1. How big is this market?
2. Has anyone innovated on pricing here?
3. Are there really well-adopted calendar APIs you need to design for other than Exchange and GSuite?
I wish this existed years ago when I had to figure out how to programmatically send out calendar invites. There were some quirks with how Outlook handled them vs Google Calendar and it was a time-consuming trial-and-error process.
Wonderful article. It's very useful. As a home tuition service provider, I really appreciate your post. Thanks for sharing this with us.
I find a very good website for the <a href="https://singaporetuitionteachers.com">Singapore Tutors</a>, You can visit this site.
Amazing, just something I was looking for recently. Would love to see a little "Update requests" on developer plan though and maybe a few more requests per month as that'd allow building an end to to end product with some headroom for developer testing.
Agree with above comments about price point being high. $9/month is high given the 500 requests limit per month
2) Timezone and localization support has to be spot-on, and right upfront. Might I suggest having the backend only speak UTC and the frontend has a thin layer of JS that turns all UTC into the local browser time in the onload- This design worked for me in a recent app.
Wonderful article. It's very useful. As a home tuition service provider, I really appreciate your post. Thanks for sharing this with us.
https://singaporetuitionteachers.com
This is a great concept! Best of all you have an obvious exit strategy: Twilio and its competitors would love to add this feature set to their portfolio: imagine a txt message that not only offers to sign you up for an event, but adds it to your calendar!
To be clear: the exit strategy would be to be acquired by twilio or a competitor. One will have the foresight to add this feature then the others will feel obligated to add it too. You can position yourself to be acquired in the first round or the second.
Any chance you could convert pricing to $X per 1000 requests? My previous company needed something like this (we ended up building it our selves at a whooping cost) but our needs were 50k+/mo of calendar invites.
The existing tiers seem fine to me -- but I would change the name of Enterprise and make a top Enterprise tier which simply charges 1c/request, perhaps with a minimum of $50 or $100/month billed.
Not to put the project down or anything, but if you already have the ability to send transactional email, does this offer anything beyond what you could do with whatever library to generate ics attachments? Or even just generate links for various calendars? https://www.npmjs.com/package/calendar-link
What would make me definitely use this are frontend components too, like a calendar component (e.g. Vuetify's one), or especially a Calendly-like self-scheduler like the ones offered by Nylas or Kloudless, but at that point it's basically a totally different product.
In fact, not all languages have a library as simple as the Node package you are pointing at. Most libraries require you to use the iCalendar standard syntax which, for a single event, is accessible but becomes complicated for a recurring event for example.
But for the Node package you mentioned, you are absolutely right.
Just out of curiosity, can you name one such language that doesn't have a library for generating/parsing iCal? (I assume probably the language you use for your product).
I work mostly in PHP, and when I started this project, most of the libraries were very incomplete. Customer needs led me to develop a more complete library and it's only recently that I proposed this library as an API. But, yes, much more complete and easy-to-use packages have appeared since then, although they still focus on events and don't allow to manage tasks or notes.
Maybe that's being developed, but the American date format with no timezone being described as "English textual" (say what?!) seems to be ignoring all the standards for date and time (eg. RFC3339[1]), yet other parts of the docs clearly show awareness of RFCs!
If you're pushing events to people, presumably you know exactly when they're going to happen, but with this API you're saying "here's an event, just pick your own timezone!"
Nice idea though, it'll be interesting to see how it develops.
[1] https://tools.ietf.org/html/rfc3339