▲ | godelski 3 days ago | |||||||||||||||||||||||||
I'll be fair and agree that I'm being a bit facetious here. But let's also admit that if you are unable to dedupe entries in a calendar with identical names then something is fundamentally broken.I did purposefully limit to holiday calendars as an example because this very narrow scope vastly simplifies the problem, yet is a real world example you yourself can verify. You're right that edge cases can add immense complexities but can you really think of a reason it should be difficult to dedupe an event with identical naming and identical time entries, especially with the strong hint that these are holidays? Let's even just limit ourselves to holidays that exclusively fall over full day periods (such as Labor Day). Do you really think we cannot write a quick solution that will cover these cases? The cases that dominate the problem? A solution whose failure mode results in the existing issue (having dupes)? Am I really missing edge cases which require significantly more complex solutions that would interfere with the handling of these exceptionally common cases? Because honestly, this appears like a standard table union problem. With the current result my choices are having triplicate entries, which has major consequences to usability, or the disabling of several calendars, which fails to generalize the problem and also results in missing some minor holidays. Honestly, the problem is so bad I'd be grateful even if I had to manually approve all such dedupes... If not, I'd really like to hear. Because it really means I've greatly mischaracterized the problem and I should not be using this example. Nor the example of a failure to FIND contacts with identical names, nicknames, phone numbers, birthdays, and differ only on an email address and note entry. Because I have really been under the strong impression that the latter is a simple database query where we should return any entry containing matches (failure mode being presenting the user with too many matches rather than a lack of matches. We can sort by number of duplicate fields and display matches in batches if necessary. A cumbersome solution is better than the current state of things...). I'm serious in my request but if I have made a gross mischaracterization then I think you'd understand how silly this all looks. I really do want to know because this is just baffling to me. If I truly am being an idiot, please, I encourage you to treat me like one. But don't make me take it on your word. | ||||||||||||||||||||||||||
▲ | yacthing 3 days ago | parent [-] | |||||||||||||||||||||||||
That's a lot of words, but I think it boils down to: you're making an assumption that two calendar events with identical naming and identical time entries will always have a desired behavior of being deduped. - Maybe you want to separately invite people to the same thing and have different descriptions, now you're increasing the number of things to equate. - Maybe a user creates one event that is simply a title and a time, and they then want to create a second one for another purpose. However, it keeps getting deduped and they don't know why. Now you have a user education problem that you have to solve. - Now you might think: well just make it a toggle in the settings! Okay well now you have to add a new setting and that expands the scope of the project. Do you make it opt-in or opt-out? If it's opt-in, what if no one uses it? Do you maintain the feature if there's a migration? If it's opt-out, you still have the above problems. I could go on. And this is mostly an exercise of not underestimating a "simple" change. Calendars (and anything involving time) in particular can get very complicated. | ||||||||||||||||||||||||||
|