[HN Gopher] Show HN: Convier.me - A Calendar Service for Developers
___________________________________________________________________
Show HN: Convier.me - A Calendar Service for Developers
Author : mikaelcarlavan
Score : 102 points
Date : 2021-01-09 07:26 UTC (15 hours ago)
(HTM) web link (convier.me)
(TXT) w3m dump (convier.me)
| densekernel wrote:
| Very nice! Good luck. Lean site.
| systemvoltage wrote:
| What's the point of that illustration on the right? What purpose
| does it serve?
| supermatt wrote:
| "English textual datetime" as the input date format? What could
| go wrong... For an API this makes literally no sense.
| jabo wrote:
| 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.
|
| Congrats on shipping!
| paraknight wrote:
| 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.
| mikaelcarlavan wrote:
| 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.
| paraknight wrote:
| 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).
|
| For context, we use this in production:
| https://www.npmjs.com/package/ical-generator, but again
| that's NodeJS
| mikaelcarlavan wrote:
| 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.
| johnorourke wrote:
| 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.
|
| [1] https://tools.ietf.org/html/rfc3339
| sverhagen wrote:
| But then in the Event section, there's a timezone ID and some
| talk about local time of the calendar. Maybe the other sections
| are behind :(
|
| https://convier.me/docs/latest/event-component
| matsemann wrote:
| 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.
| Erlich_Bachman wrote:
| "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).
| mikeyjk wrote:
| AM / PM clears up the 0900 vs 2100 ambiguity, but agreed re;
| American date formats.
| matsemann wrote:
| 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. :)
| lazylizard wrote:
| it is. some ppl say 2359 to avoid saying 12am/pm.
| hairofadog wrote:
| 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.
| zeeZ wrote:
| For me it clears it up only 92% of the day. I couldn't tell
| you when 12:xx AM/PM is right now.
| HenrikB wrote:
| FWIW, there's also 00:00 and 24:00 to distinguish
| midnight at the beginning of the day versus the end of
| the day.
| nicwolff wrote:
| The easy way is to remember that the hour _following_ 12
| pm is clearly in the afternoon, so 12 pm must be noon.
| Fnoord wrote:
| 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)
| jcelerier wrote:
| it's really weird tho
|
| 12AM 1AM 2AM 3AM 4AM ... 11AM 12PM 1PM 2PM ... 11PM 12AM
| 1AM
|
| even the way you explain it:
|
| "then you know 12 PM is 12.00 (after noon hence
| afternoon) "
|
| when I read "12 after noon", I understand "noon + 12
| hours" which should give midnight..
| Swizec wrote:
| 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.
| Fnoord wrote:
| 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.
| ryanianian wrote:
| Mnemonic: "AM" is "Always Midnight"
| nicwolff wrote:
| Mnemonic. tsu
| Fnoord wrote:
| 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]
| bigzyg33k wrote:
| This is incorrect, Americans use MM/DD/YYYY, and from my
| understanding most of the rest of the world (I think the
| Netherlands too) use DD/MM/YYYY
| ci5er wrote:
| While I believe that most (?) of Europe uses DD/MM/YYYY,
| I am pretty sure that most of South East Asia (dunno
| about India and Nepal) use YYYY/MM/DD.
| ValentineC wrote:
| > _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.
|
| This looks useful:
| https://en.wikipedia.org/wiki/Date_format_by_country
| illuminati1911 wrote:
| Lot of Asian countries use YYYY/MM/DD like China, Japan,
| South Korea etc.
| smoyer wrote:
| 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).
| arrosenberg wrote:
| I do that too, but I often replace the month with the 3
| letter abbreviation to make it easier for others.
|
| E.g. 2021JAN08.
| mikaelcarlavan wrote:
| 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.
| [deleted]
| sdjcse1 wrote:
| Where will this be useful? I don't understand the use case
| mritchie712 wrote:
| My guess:
|
| Say you had a CRM app where you wanted to let users schedule
| sales appointments. You could use this API to send the events.
| mjgs wrote:
| That's exactly what I was thinking.
|
| My first reaction was 'this sounds like it might be useful' but
| I've read the copy and I still don't fully grok where I would
| use it effectively.
|
| Having the curl example is good, but I feel like a few example
| workflow diagrams that show some cool things you build with it
| would be useful.
| rosywoozlechan wrote:
| 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.
|
| You made a cool thing. Charge for it.
| dexterdog wrote:
| The problem is $9/mo is way too much for something like this
| unless you are using it heavily.
| atian wrote:
| Any publicity is good publicity. If people don't want to pay
| they won't pay, and that's a deeper problem for your product.
| rosywoozlechan wrote:
| 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.
| atian wrote:
| This is in response to toxic users. But supporting
| freeloaders costs money.
|
| I'm saying weigh your conversions. Your comment suggests to
| discount freeloaders entirely.
| rosywoozlechan wrote:
| 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.
| capableweb wrote:
| 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.
| llaolleh wrote:
| 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.
| skrebbel wrote:
| 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.
| mikaelcarlavan wrote:
| 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!
| kimsant wrote:
| 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!
| pmarreck wrote:
| 1) Name is terrible. Sorry.
|
| 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.
| hobofan wrote:
| In the famous words of patio11: Charge more!
|
| (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.
| atymic wrote:
| I've built a free add to calendar link generator tool, and late
| added an API. Costs me about 30c a month on serverless :)
| https://calndr.link
|
| Feel free to ask any questions.
| joefarish wrote:
| This looks super useful - nice job!
| joefarish wrote:
| 3 attendee max/request seems low for $9/month per user.
| multimedial wrote:
| Although I am looking for something like this,convier.me's
| example script didn't work for me:
|
| curl https://convier.me/api/event \ -H 'Authorization: Bearer
| YEAH_SURE...' \ -d 'event[start][date]=05/26/2019 08:00 PM' \ -d
| 'event[end][date]=05/26/2019 11:00 PM' \ -d
| 'event[organizer][name]=Tony Stark' \ -d
| 'event[organizer][email]=ironman@avengers.com' \ -d
| 'event[summary][text]=Endgame premiere' \ -d
| 'event[description][text]=Bring the popcorn.' \ -d
| 'event[attendees][0][email]=MY_EMAIL'
|
| (with API Token and email filled in of course) gives me
|
| HTTP/1.0 402 Payment Required Cache-Control: no-cache, private
| Content-Type: application/json Date: Sat, 09 Jan 2021 12:52:48
| GMT
|
| {"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
| mikaelcarlavan wrote:
| Thank your for your feedback. I fixed that. Sorry about that.
| nicolewhite wrote:
| FYI I wouldn't expose internal details like that via your
| responses
| tomasreimers wrote:
| 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?
| yalooze wrote:
| 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.
|
| [0] https://github.com/jaredlt/add_to_calendar
|
| [1] https://github.com/InteractionDesignFoundation/add-event-
| to-...
| cpursley wrote:
| This looks really useful. Any similar Libs. For Elixir or
| Javascript?
| yalooze wrote:
| The second link I mention has some JavaScript
| implementations, although I have not used them myself.
|
| https://github.com/InteractionDesignFoundation/add-event-
| to-...
| RyJones wrote:
| I commented on one of your issues about all-day events; it's
| interesting what a hack supporting them is.
| yalooze wrote:
| 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!
|
| [0] https://tools.ietf.org/html/rfc5545
| bnt wrote:
| 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.
| mikaelcarlavan wrote:
| Yes. Given the feedback so far, I will probably switch to a
| "pay as you grow" pricing.
| dsr_ wrote:
| 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.
| koirapoika wrote:
| "Check the docs" button link on the landing page seems to be
| broken. All the best to the project!
| mikaelcarlavan wrote:
| Thank you for your comment, I fixed that.
| forks34 wrote:
| It's enterprise not entreprise. Looks interesting though.
| YesThatTom2 wrote:
| 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!
| YesThatTom2 wrote:
| 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.
| cosmodisk wrote:
| Have you submitted to Product Hunt yet?
| mikaelcarlavan wrote:
| Not yet! With the feedbacks I just received, I want to improve
| the API before posting on PH.
| caseyw wrote:
| Looks useful. I'm on mobile though, and the docs aren't mobile
| friendly.
| tiborsaas wrote:
| The "check the docs" button is not working next to the API
| request sample.
| mikaelcarlavan wrote:
| Thank you for your comment, I fixed that.
___________________________________________________________________
(page generated 2021-01-09 23:02 UTC)