- Show [ Sign in with Google ] button
- Goes to google and select google account. When account is selected, the user is back to [ Sign-up page ]
The user set up the basic settings for using this service.
-
- Choose url
- cal.deno.dev/[user-name]
-
- Select available weekly days and hours
- Click [ OK ] button and goes to [ My Account Page ]
- Lists (appointable) event types
- Default: 30 Minute Meeting
- Can create / modify / delete event types
- Lists available days and hours
- You can modify weekly available days and hours
- You can modify your timezone
- You can change the url of your calendly (deno.land/calendly/[user-name])
- Links to Google calendar
- Copy URL for share
- You can sign out from your account
- You can delete your account
- The page is at the url of
deno.land/calendly/[your-name]
. - Shows available event types (default: 30 minutes meeting)
- When event type is selected, shows calendar with available slots.
- Choose available slot, you can book the event of the selected type.
We should consider avoiding calendly in anything, as it is a trademarked name. I am also not totally sure about cal. A few other suggestions:
Also, wouldn't this go on
deno.com
since it is really about the commercial entity (though we would make the code open), so something likeconfab.deno.com
orhap.deno.com
(as well asconfab.deno.dev
andhap.deno.dev
as we are building it).Do we have to worry about OAuth permissions to access the calendar and the like?
I also assume we might want to consider location based identification of the timezone and/or also read the timezone from the Google Calendar?
This is a good start from the "what pages we need" but we might also want/need user flows to help identify parts of the process that aren't visible. For example, when a meeting is added to their Google Calendar, any slots that overlap with that should be removed from the availability, and those non-user facing processes are missing from this document.