Responsive image

Connect your time with others'
on Tiscus. And time is LIFE .

I initiated this year-long project, Tiscus, to build an innovative calendar-based social medium. More than ten designers and programmers joined my team, and we've developed the frontend prototype and some backend features.


BACK







Problem & Core Needs

In the first week I became a student in UCSD, our Residential Assistant asked the 6 students in my apartment to figure out a meeting time. We first pulled out our class schedules and discussed for 20min, but we couldn’t bring up a time that works. Then we used the platform “when2meet”, spending 10min checking and clicking all our available time slots.

30min later, we eventually figured out a time for the meeting. But everyone felt annoyed.

Later, I came across more scheduling problems, either for meetings or social hangouts. Scheduling was always hard, and I wanted to resolve this. I recruited 4 designers who were interested in this issue, and we interviewed 15 UCSD students about their methods to schedule (group) meetings or hangouts, and here’s the competitive audit we summarized based on the interview result.


In my view, designers create different features to approach users’ core needs, but those features ≠ core needs. I further analyzed the interview result and defined 3 core needs:

I. Quick insert of schedule

None of our 15 interviewees complained about the manual insertion of calendar, but it raised my interest that some of them collected screenshots for scheduling. I asked them why.


Based on what they said, a slow or difficult schedule insertion will lead to the failure of generating useful results and the high exit rate on the product (users don’t want to continue).

For those 8 interviewees (53%) who complained about the back-and-forth process of Message Apps, one of their root needs is actually the quick insert (another one is their preferences, which will be addressed in our advanced feature). The essence of “quick insert” grants rapid access to sufficient information. Only with sufficient information can we smoothly move on to useful results. Essentially, the feature “import calendar data” also serves for this need by reducing the effort of insertion. Maybe we can design the insertion to be faster.

II. Privacy Concern

3 out of 15 (20%) interviewees said that they shared Google Calendar to schedule hangouts. Interestingly, all the three interviewees only did that with their partners. This result indicates users’ privacy concerns.

When2meet does a good job on this core need by: 1) Making it hard to see the complete availability of a certain person 2) The free/busy time slots don’t have personal/event details. Doodle also emphasizes this concern on their landing page. On Doodle, users cannot access each other’s calendar even when they fill in the same meeting poll. Privacy is a core need that existing apps have covered pretty well, and we should learn from these designs.

III. Quick & Clear Result

The goal of “scheduling” is not to enjoy this process, but to get a quick and clear result.

Both When2meet and Doodle provide real-time reports, and the paid version of Doodle provides email notification when everyone fills out the poll. From When2meet and Doodle, we learned that “Quick” manifests in 2 perspectives: 1) Once the information is sufficient, the result should be generated. 2) Users should be immediately notified when (1) becomes true.

Regarding the clarity of result, When2Meet(left) performs worse than Doodle; when more than 5 participants fill out the poll, the result looks obscure. Users need to hover on a certain block to verify who’s available and who’s not. Doodle provides calendar view and table view to display the results. In the calendar view(middle), users can clearly see the options with the highest votes. In the table view(right), users can verify the availability of each participant.


So we summarized how When2meet and Doodle approach "Clear" results: 1) The time slots with highest votes should be salient 2) Users should be able to check who’s available or not on each option

Point (2) raised my interest. Why do users want to know about that? If there are N participants, and the best option has N-1 votes, perhaps users would ask that unavailable person to make accommodations. Therefore, point (2) can be modified as “When there exists >=1 time slot(s) that everyone’s free, cut out all the unnecessary information about worse time slots; otherwise, display worse time options.”

Conclusion

Our design should cover these considerations:
1) Quick insert of schedule
2) Privacy concern
3) As long as the information is sufficient, the result should be quickly generated
4) Users should be quickly notified when (3) becomes true
5) The time slots with highest votes should be salient
6) When there exists >=1 time slot(s) that everyone’s free, cut out all the unnecessary information about worse time slots; otherwise, display worse time options

Because (2) - (5) are roughly covered by existing products, and (6) only provides a cleaner design that removes some distraction for users... Our unique competitiveness should come from (1), Quick insert of schedule. How “quick” do users want? As quick as sending a screenshot? What if users only need to upload a screenshot of their schedule, and our app inserts everything for them?

With this in mind, I faced two choices. Do I want to simply develop an “image-to-calendar” plug-in for existing calendar apps, or do I want to design a whole app that brings greater impacts? My choice would determine this product’s design direction, and that’s why I considered this question at this point. Conceiving the market potential of “time”, I decided to create an innovative app.


Market Potential

Obviously, the market of scheduling/time management is not pristine. Many apps and services already exist. However, almost all those apps focus on enterprise or productivity.

In my view, time is not just about work and achievement; it’s also about the quality time we spend with people, the participation in our favorite communities or missions, the effort we put in for our mental and physical health, and many other aspects. Because time is life.

Nowadays, sharing economy is a popular term; what if my app, Tiscus, can help people share their time/life with each other in a better way? For example, instead of clicking “likes” on our friends’ social media, users can journalize their quality time with each friend on Tiscus; instead of giving up learning to dance or reading a whole book, users can find people who want to do the same thing and pursue their goals together...

With the calendar data as a foundation, users can go beyond the virtual closeness on existing social media, connecting with each other in Tiscus through their time, their life. I tried to draw an “adventurous” blueprint for Tiscus:

I. Feature Customization

The base of Tiscus is a calendar app. However, by clicking the “menu”, users have access to a list of features that might connect their life in diverse ways. You might ask, “Are you squeezing tons of features into one app? Won’t it prompt some users to replace it with a cleaner/lighter app?” But in Tiscus, users can customize the features they subscribe to. The technology constraint on this idea has been overcome by WeChat, where every mini program(feature) is developed with HTML5 (websites) and the WeChat APIs.


Users can access these "mini programs" whenever they want, and they don’t need to download anything or create new accounts. WeChat is a message-based social medium in China, so in the short term it won’t become a competitor to Tiscus, which will be a calendar-based platform that helps users spend meaningful time with each other.

II. Multiple Profit Channels

The first two profit channels of Tiscus are advertising and subscription income. In Tiscus, most features will have Basic (free) and Pro (paid) versions, and the advertisements are displayed in the Basic version. For example, the income from “Scheduling” feature might have the segments below:


Another profit channel is the calendar data of users. Currently, the popular method of gathering users’ interests is measuring their clicks on different types of contents; however, Tiscus will obtain the time (length) that users spend on different events, which might be a better proxy on certain types of interests. We don’t want to make profit from selling people’s privacy, but we can make use of the data to benefit the users more.

III. Market Expansion Plan

Although the blueprint is adventurous, we would start from solving the problem of “scheduling” by developing img-to-calendar technique over the UCSD webreg page . So our SOM (serviceable and obtainable market) is the students and faculties in UCSD, especially those who have orgs or group projects. There are 550+ student orgs and 100+ courses in UCSD that involve group projects, so the estimated market size of SOM is at least 2500 users.

Our SAM (serviceable available market) might be reached when we improve our img-to-calendar technique to process diverse types of images/pdf, or when we come up with other feature(s) that attract more undergrad or graduate students in the US. Hence, the estimated market size of SAM is around 20 million users. We target students because they have relatively low willingness to pay and few startups might become our competitors due to the lack of profits; as a social medium, a large user base is crucial for our mission, so we prioritize user acquisition over profits during this expansion phase.

After we adapt with cardinal features that realize our mission, Tiscus will become an innovative time-based social medium that connects people’s life with each other. Our TAM (total addressable market) includes everyone who uses social media in the US, estimated to be over 244 million users. And then we can continue to expand our market worldwide, acquiring social media users from different countries. Hence, our PAM (potential available market) is estimated to be over 3.8 billion users.

So... what now?

In our first stage, our target users are UCSD students and faculties. We want to design a better scheduling experience for them, and our core competitiveness is “quick insert of schedule”. What specific scenarios and goals do they have? What are their current pain points?

Creating personas and storyboards would help us approach the answer.


Personas & Storyboards

Based on the interview results, we created 3 personas to empathize with:


Our proposal of a better scheduling experience directly applied to Joe and Kate, but it might only indirectly help Megan by helping her students. From our interviews, we learned that Megan could resolve current pain points by allowing absence or postponing the meeting, while Joe and Kate have no effective current solution.

Therefore, we defined Joe and Kate as our primary personas, leaving Megan as our secondary persona. This was also because our MVP(minimal viable product) aimed to provide the highest benefits with the lowest cost or complexity of design. To illustrate how Tiscus might benefit Joe and Kate, we tried to create two storyboards corresponding to their scenarios:


The storyboards helped us refine our design considerations in contexts, instead of in abstract methodologies. Hence, we developed a better understanding of what might encourage or prohibit our target users to start using Tiscus in real-life scenarios.

Our updated design considerations based on that empathy:
1) Quick insert of schedule -> Quick insert with a screenshot of Webreg page (UCSD)
2) Privacy concern -> Display the results without personal info
3&4) As long as the information is sufficient, the result should be quickly generated, and users should be quickly notified -> Start algorithm when nobody is pending; In-app notification when results come out
5&6) Salient display of best options; hide the worse options when the best ones exist -> Also allow users to choose from the best options
7) New: A friendly/social vibe. So users would like to schedule hangouts besides meetings
8) New: Enable “import from (other) calendar”. So users can easily switch over


Using these design considerations as our guideline, we start prototyping.


Prototype & 1st User Test

The first challenge we “gave” ourselves was… could we design and develop in ONE framework for both desktop and mobile versions?

This thought was adventurous, but if we found such a solution, we would be able to design and develop the desktop and mobile versions at the same time, greatly reducing the workload. With some background in html/css/js, I came up with a possible design solution that fits both.

On the desktop view, users will open a side page if they click “Features” or “Account”, and they can operate within that page as if they’re using their phone. On the mobile view, the side page will occupy the whole screen, just like a normal mobile app. Technology wise, we could simply set the @media css of any side page to “width: 100%; height: 100%; z-index: 900+” to achieve this.

Only the desktop view of this solution is new, so we’d focus on the UI of the desktop view and test out if users have difficulty operating on this new design. The red highlights (not displayed to testers) indicate the entrances to our target features, and the total operations to enter each feature is 2 clicks from the homescreen.

Before we conducted our 1st round of user interviews to test the design above, we also prototyped the UX flow and program logic of “Img-to-calendar” and “Scheduling” features. Based on the UX flow, we then sketched UIs for testing.


Since the UX flow for “Img-to-Cal” is simple, we only provided one operation for error recovery: when users click “<” on the top left, they’ll go back to the “Account” page where the entrance of this feature is located. We also allow users to manually edit the calendar information before they confirm, in case that our img-to-calendar processing is not accurate enough.


The unique UX flow of Tiscus is marked with a red border, while the other parts of UX flow are relatively common in other apps. Hence, we chose to focus on the design of the red-border part for testing. Below are our UI sketches: the 1st image with blue arrows indicate the ideal UX flow, and the 2nd image with red arrows indicates error recoveries.


Then we interviewed 15 UCSD students and asked them to perform these tasks:
1) Insert your classes with a screenshot
2) Use TcMeet to schedule a study jam with Amy and Ben
3) You remember having an argument with Ben (remove Ben) so you schedule with Amy only
4) Before you hit “Tc”, you decide to add Ben back because he’s your friend anyway
5) Finally you “Tc” both Amy and Ben for a 2-hour study jam

While they worked on the tasks, we encouraged them to think out loud so we could take notes of their actions and thoughts. Based on the testing result, we made some iterations.


Iterations & 2nd User Test

I. Modify Home Screen & Feature Entrance

After conducting 5 interviews, we realized that all the 5 interviewees couldn’t easily notice the buttons at the bottom; some shared with us that “usually buttons are on the top for desktop view”. Hence, we moved the bottom buttons to the top for easier recognition. Also, we changed the “feature” icon to a regular “menu” icon. Originally we wanted to use the strange icon as a highlight of our app, but most interviewees felt confused; now that we used “menu” instead, and we would see how the other 10 interviewees felt.


In the following 10 interviews, all could easily see the buttons and open the side pages. Only 1 out of 10 interviewees commented that the “menu” icon made her confused, so we would keep the “menu” icon before having a better solution. Other than that, all the 10 interviewees had very small learning curves to work with the side pages, so we decided to adopt our cross-platform design for desktop view.

67% (10 out of 15) interviewees felt confused about our icon for Screenshot Insert. To lower users’ cognitive load, we replaced our icon with the text indication. With this indication, we also made our feature more salient than “import from Google Calendar”, highlighting our uniqueness and competitiveness.


20% (3 out of 15) interviewees asked what TcMeet means, so we decided to include an introduction page for the TcMeet feature. Since the social aspect is lacking in most apps, we wanted to emphasize this aspect with an emotional quote. The term “Tc”, derived from Tiscus, is a verb that refers to participant-centered scheduling; in future, we can promote “Tc” as a cultural trend to advertise our uniqueness.


II. Modify TcMeet

47% (7 out of 15) interviewees had difficulty removing Ben due to the lack of indicator. Hence we added a circle with “-” inside to indicate the removal. Also, one interviewee brought up that if there are more participants to invite, he might forget who he has selected when only seeing a search bar on the page. This was a valuable feedback to lower users’ effort to memorize, and we could easily achieve this by moving the participant list to the top.


The last change we made was to display participants on the event information page. This modification was inspired by the interviewee who brought up the memory issue; in addition to lower users’ memory load, we also wanted to magnify the social aspect of Tiscus: participants are more important than the event itself, and the event time is determined by everyone’s availability.

III. Create a Low-fi Digital Prototype for 2nd User Test

To better simulate the experience of using an app, we created a low-fi digital prototype on Figma before re-testing. During this process, one designer brought up an issue: In when2meet or Doodle, the invitation can be sent through links, so the event initiators don’t need to select participants one-by-one. Will Tiscus’s one-by-one selection of participants trouble those initiators?

By empathizing with our target users, we concluded that this was a valid pain point. To both ensure the simplicity of MVP and satisfy the goal of “quick selection”, we would only allow users to create new groups or add people to an existing group; we won’t provide options to delete/rename/remove people from groups. Below is our prototype for “Group Selection”:


The buttons for groups are deactivated when no participant is selected. If users click the button, the hint message “Select users to add” (for “add to a group”) or “Select users to group” (for “create a group”) will display in the search bar. Users can select multiple participants before creating or adding them to a group.

Then we conducted our 2nd user test with 5 UCSD students, and we asked them to perform the tasks below:
1) Insert classes with screenshots
2) Use TcMeet to select Jim B and Crystal L for scheduling
3) If you mis-select a user, what would you do?
4) Add Jim and Crystal to Study Group
5) Schedule a study jam for 30min

All of the 5 interviewees performed the task smoothly, but 4 out of 5 participants wondered if they had to “create a group / add to a group” instead of directly selecting Jim and Crystal in task 2. When they were asked to group Jim and Crystal, they had no idea why they should group them. This raised my interest: what if users don’t really need the “group selection” tool? How much does this tool matter to them?

Another thing we learned from the 5 interviewees was that they not only want to get the time slots that everyone’s available, but also want to choose their preferred time. Should we work on such a feature? How much does this feature matter to them?

To evaluate how much our proposed features matter, we conducted a quantitative research.


Quantitative Evaluation

In my ECON 176 (Marketing) class, I learned that a product can be viewed as a combination of characteristics. With logistic regression, we can figure out how much profit($) each characteristic might bring forth, thus understanding what we should prioritize in our design. For Tiscus, we had 4 unique characteristics to investigate: Screenshot Insert, TcMeet Basic, Group Selection, and Preferred Time.

In the survey, we first presented each feature to testers via pictures, videos, and texts. In this way, testers can develop a good understanding of our products before evaluating. Knowing that users’ willingness to pay might be very low for a low-fi product, we added some colors and improved the aesthetics (even though it’s still not our final design). After the presentation, we asked users to select what each feature provides, checking if our presentation was clear enough for them to understand.


Then we chose our main competitors (Google Calendar and Message Apps) as the dummy variables with respect to Tiscus, and we provided necessary explanations for testers. The last dummy (in complement to Google, Tiscus, Message Apps) is “no need for scheduling”. To prevent testers from choosing it without thinking, we demonstrated its possible outcome.

Since the usage frequency of “Screenshot Insert” is much lower than other features, we couldn’t measure it with “monthly subscription”. Therefore, we marked it as DF (default feature), which always appears with the dummy variable Tiscus. Due to this perfect correlation, we no longer have a variable for “Screenshot Insert”; but we can still investigate its possible effect via the dummy variable Tiscus. Below is one of our 14 questions in the survey.


At the end of the survey, we also asked the testers how they made their choices. Finally, we received 25*14*4 = 1400 observations from 25 survey takers (link to raw data). And I used STATA to run a logistic regression with the variables below in order to calculate users’ willingness to pay for each feature. The reason I added the interaction variable “Both” (Both = Pref*Group) was that some testers mentioned they “prefer the option with both features” in the last question, which indicated that interactions might exist between the two feature variables. STATA’s report gave me the regression below:

Y = 1.36*Google + 2.00*Tiscus + 1.56*Message + .83*Pref + .46*Group + .23*Both - .66*Price


The coefficients for “Group” and “Both” are not statistically significant on the alpha=0.05 level. If we had time and resources to conduct a more comprehensive research over more testers, we could categorize subjects based on consumer characteristics and obtain more statistical significant references. However, due to the constraints, we would still use the current coefficients to calculate users’ willingness to pay.

Compared with “no need to purchase for scheduling”, people’s willingness to pay per month for Tiscus is -2.004/(-0.659) = $3.04, and for TcMeet Basic is -2.062/(-0.659) = $3.13 (Tiscus and TcMeet are also highly correlated due to a realistic constraint; we won’t expect users to pay for Tiscus without TcMeet feature). For advanced features:
1) Preferred Time: -0.836/(-0.659) = $1.27
2) Group Selection: -0.461/(-0.659) = $0.70
3) Effect of Combination: -0.234/(-0.659) = $0.35

Hence, the estimated value for TcMeet Pro per month is 3.13+1.27+0.70+0.35 = $5.45. We won’t extract all the consumer surplus, so our pricing will be lower than that. From this quantitative research, we realized that users don’t value “Group Selection” that much; however, they value “Preferred Time” feature where they can choose their preferences. Therefore, we should weigh “Preferred Time” more in our design, trying to further simplify “Group Selection”.

Now I realized how the design process is really non-linear… We spent a lot of time designing the “Group Selection” tool, but now we need to let go of our past efforts and design something better.


Iterations & Final Design

We removed the function “Add to a group” and only provided “Create a Group” after simplifying this feature. However, if users really wanted to add people into a group, they can “replace” the old group by inserting the same group name. To indicate this “replace” operation, we provide users with a hint message when they name the group: “An existing group name will replace the old group.”


With the ccore benefit of “no more one-by-one selection”, this feature is just a shortcut for the event initiator to select multiple users. Hence, those groups have nothing to do with the group members, and we could greatly simplify our backend logic: Instead of creating a dynamic group, we only need to generate an array of group mates’ IDs and link it to the group creator’s account (and update the array when this user inserts the same group name).

And for the “Preferred Time”, our competitiveness is that users can select from a list of time where everyone is available, instead of holding back their non-preferred availability and slowing down the scheduling process. As shown in the UX below, TcMeet Pro users can select their preferences only from the time slots where everyone’s available. Here’s a comparison of our UX based on whether certain participant(s) have TcMeet Pro:



We gave the initiator the right to “choose another time”, in case that certain event is really dependent on the initiator. Anyway, every participant can see the preferred result(s) on the event's detail page; if the initiator avoids choosing the preferred one(s) without any reason, this initiator might suffer from peer pressure. This peer pressure helps protect the benefits of TcMeet Pro consumers (initiators have to prioritize those preferences due to our design) without over-limiting initiators’ rights.

After users click “Edit Preference”, they would enter a new page. What should this page look like? We drew some UI sketches and shared our thoughts:
1) Provide the list of all-available slots for users to choose from
2) Display current meeting time & constrained date range; users can first choose a date and then choose preferred time, repeating this if they have preferences over multiple days.
3) Display participants and the list of all-available slots in a calendar grid, and users can select from them.


We went through an empathizing process to narrow down what users actually need on this page: To choose their preferred time, users don’t need to see the current result or the participants; they just need a friendly display of options that help them easily choose preferences. On the technical side, we also want to minimize the algorithm, so we deny the idea of generating a calendar grid. Eventually, we converged the 3 sketches into a new design, where the all-available options are displayed in an organized way, and the algorithm to generate this view is relatively simple. Inspired by this design process, we also modified our display of time slots on the event's detail page, grouping the information in a clearer way.

We moved on to set up design guidelines (css standards) and finalize our high-fi prototype. During this process, we continued to do user testing and found that users thought it’s more intuitive to have both TcMeet and Img-to-Cal on the feature page, so we made changes accordingly, Here's our final design (background "waves" from Vanta.js):



And this is the link to our github repo (in progress). If you're interested in our development progress, feel free to continue reading!


Development Progress

I. Collaboration Model

Since I have courses from two majors and one minor (& most importantly, my 15-20h weekly spiritual cultivation), I can't allocate too much time on this project. Therefore, I tried to design a flexible collaboration model before recruiting any teammate. I called this model ANYWAY.

ANYWAY: a collaboration model that reduces each member’s weekly commitment to 1-3 hours by having many teammates, breaking down the tasks, and facing the challenges together.

I shared this model with everyone before they decided to join my team. I also tried to arrange tasks in modules, for example, even if some designers could only help for one quarter, they could still write a valuable case study with systematic user research and iterations. Instead of promising my teammates that our team would “definitely succeed”, I always said “Let’s just try our best to learn and help each other throughout this process!”



The image on the right summarized our overall timeline since last summer. A defect of ANYWAY was that we made progress little by little, but I was comforted when my teammates told me that they learned a lot while having enough time to study and rest.

Lots of thanks to all the wonderful people who joined my team at some point O(∩_∩)O
Business Planners: Benhao Fang, Cindy Tsai, Jesus Osuna-yajimovich
Designers: Angella Zhu, Christine Larios, Damien Cho, Fidella Wu, Kayla Rice, Stacy Kim, Suha Kazi
Developers: Heqi Wang, Jialin Zhang, Larry Qin, Xiangyu Wei, Yan Zhang

In the sections below, I’ll summarize my main contribution to our development.

II. Img-to-Cal

With the free OCR (Online Character Recognition) we found, we could convert the img on the left to the text file on the right. My work was to extract the key information from this text file with python.


I split the text input into a nested array called ‘txt_vals’, and then I use different patterns to extract the information I need. For example, course titles have a unique pattern “AAA(A) 1(11)(A)” where A is alpha and 1 is number, so I used the code on the left to locate the start of a course entry. In the same row, I could locate this course's lecture days (save in reoc) and time (save in start, end).


With similar methods, I could locate the DI (discussion) and FI (final) of a course. I asked my friends to send me the screenshots of their courses, and I realized that some courses don’t have DI or even FI. Therefore I dealt with this issue with a variable called “courseReach” (default value: 0).


The code above resolves the cases where a course without DI or FI occurs in the middle of the list; in case where the last course doesn’t have DI or FI, I append “NaN” based on the length of each array. Eventually, my output is a table with the information I extract.


MUS 173 doesn’t have DI or FI, so its output is correct. However, the data marked in red are problematic, and this was caused by the misrecognization of the free OCR we use. The two courses’ DIreoc days are missed in the output of OCR, and the time “7:00p” was misrecognized as “T:00p”. We couldn’t change the code of the OCR we used. We tried other img-to-text packages, but they performed worse. We proposed to write an OCR by ourselves, but we asked many professors only to realize it’s very hard. We seemed to get stuck.

One teammate tried my code and got perfect result on every screenshot he took. We tried to figure out what made this difference, and it turned out to be the high resolution of his screenshot (his computer is better than mine). This helped us find a new direction: improving the quality of users’ screenshots through image processing. It’s still hard to get perfect recognition after we tried many packages. Anyway, with PIL (Python Imaging Library), the misrecognizations were reduced to 1-2.


We decided to adopt this accuracy for now, and our compensation method is allowing users to manually edit the results. For Img-to-Cal, our next step is learning how to use the OCR API and how to connect this python part with node.js; we’ll see how it goes!

III. Calendar Data Structure

After we started building the webapp with node.js, we soon decided to use mongoose (mongoDB) for database operations. I assigned one teammate to read Google Calendar API document and then shared his ideas for our next step.


He commented that for recurring events, he’s not sure if we had to create instances for every recurring event like Google Calendar. I thought it’s a good concern, because students’ courses reoccur so many times; if one data entry could be enough, why should we create instances for all the recurring ones? I remember Google Calendar allows users to “delete/modify this event” among the recurring ones; is it possible for a single data entry to reach such usability?

I came up with an idea. With the data structure below, we could render the recurring events without multiple instances. For example, if a user wants to view all the events on a certain date, this target date (eg. 08-27-2020) is passed to the backend. For this user’s recurring events (eg. ‘Do baking’), my code will first verify if the target date falls into the recurring range (07-27 to 09-27), and then verify if the reoccur string falls into one of the recurring modes.


I use the “non_occur” string variable to fulfill “delete/modify this event”. When a user deletes a recurring event on a certain date, that date will be added to “non_occur”; with the $not operator in mongoDB, the event won’t be rendered on that date. If users want to modify a single recurring event, we’ll first add that date to “non_occur”, and then insert a new event entry for this ‘modified event’. In this way, a single data entry can also reach this usability.

The defect of my idea is that it increases workload for our TcMeet feature. Due to the lack of real instances, we need to first process the recurring events before finding out the time slots where everyone’s available. Our next step is to consult different professors to see if they have any advice or comments, so we can minimize unnecessary work. We’ll continue to learn and see how things go.

Thanks for reading!