Audiotool board archive

Notification dropdown should use the empty inbox principle

Apollo · started 2019-02-21 13:44 · updated 2019-02-26 15:49

The former email client by Google: Inbox for Gmail used the empty inbox
principle to help users keep their inbox clean. By extension, the
notification dropdown for Audiotool should remove read entries upon user
request, like many other platforms already do. This also cuts back on
the amount of content the user needs to load and improves the quality and
load time of the page.

Comments (9)

relative mAJOR
2019-02-21 13:45 · 2019-02-21

i follow over 1k people

Apollo · reply
2019-02-21 13:54 · 2019-02-21

Again... you probably shouldn't, lol

anonymous user
2019-02-26 15:49 · 2019-02-26

There is a limited amount of read messages that we hold for you to read later on. The site will not improve in terms of performance, if we would introduce a 'clear all' function.

Apollo · reply
2019-02-26 15:53 · 2019-02-26

I probably didn't clarify well:
What I mean is to add a menu option to each notification in the inbox (like comments) where the option includes "Remove" or "Mark as Read"

anonymous user · reply
2019-02-26 15:55 · 2019-02-26

You recent requests are fairly confusing and redundant. I can only encourage you to put them into one topic and delete the others, since they are more or less targeting the very same issues > Improving Notification Dropdown

Apollo · reply
2019-02-26 16:00 · 2019-02-26

Fair enough, I was trying something different as all of the related requests are linked in this bug report: https://www.audiotool.com/board/bug_reports/read_notifications
I noticed that devs would sometimes encourage separating feature requests so that discussion is more targeted. But I should've probably taken more time to organize this

anonymous user · reply
2019-02-26 16:03 · 2019-02-26

True, usually we encourage you to keep reports as simple as possible. However it gets tricky if the reports have a lot of cross-references. Especially when the issues are basically all the same. Thanks for understanding.

Apollo · reply
2019-02-26 16:07 · 2019-02-26

Sure thing, I'll try and reorganize this.
And moving forward, I'll definitely be sure to be more intentional about how I submit feedback.

Known As I · reply
2019-02-26 22:15 · 2019-02-26

Side note: @apollo There's a thin line between should-be-split and should-be-merged. You cannot always know which way is better for all cases (even we don't). Just follow your gut-feeling and be prepared that we decide otherwise :)

  • Merging has the advantage of bundling the discussion about related features and addressing conflicts an redundancies.
  • Splitting has the advantage of decoupling the implementation status and being able to assign tasks to different people
    When in doubt, merging them is the better option, I guess. It's our job to tell you (at an early stage!) when something should be split off. (let's see if I withdraw this opinion in near-future ;) (here's an example where I decided differently: https://www.audiotool.com/board/feature_requests/color_blind_mode )