KDE Goals - Call For Submissions
blogs.kde.org
In 2015, some members of the KDE community began a conversation about where KDE was heading and how it would get there. That conversation became the seed of what is now KDE Goals - a community initiative to help guide KDE's efforts around shared objectives.
  • folekaule
    7·
    16 hours ago

    I would settle for checked-by-default “sync and wait” option. That way I can choose whether to cause a sync or not.

    • vinnymac
      5·
      14 hours ago

      Often this is the correct pragmatic power user solution in UX design. Trying to solve it by default for everyone is much harder and will ultimately alienate some user.

      But when people get bothered by an experience it is much easier for them to find the hidden setting that makes them happy again. It also preserves the existing experience, while allowing for greater customization in the long term.

      Once a decent compromise is identified, that’s when it’s time to flip which setting gets to be the default.

      • folekaule
        4·
        14 hours ago

        My motivation for calling for it to be the default was that it’s safer (in terms of data).

        Another UX principle is that of least surprise. I think it’s reasonable to assume that most users will expect the copy to be fully complete when the dialog closes, and that they will be surprised when their files are corrupted. Changing the behavior in the desktop to delay closing the dialog until any copying to removable media is complete should not be a controversial change.

        We’re seeing an influx of novice users to Linux. I don’t think we need a bunch “Linux ate my files” incidents if it can be avoided by a simple change, which itself can be easily reversed if you didn’t like it.