12
Basic UserBasic User
12

    Jun 15, 2013#16

    Without disrespect of your view, I do disagree on both points. I suspect I'm not the only one who looks for autorecover to do as it implies it will.

    On config saving, nothing you've written says why it's a bad idea or not worthwhile saving changed settings when the user clicks "ok" or exits that dialog. It's not exactly difficult - the code to do so exists, it's called on app exit anyway, the code to write its updated content can be put into a single function if not already done and called on dialog exit instead, with next to zero work. The most I see in what you write is "only badly written programs would do this" (why?), "It's a hangover from Win Registry" (is it? and what about that makes it bad anyway?), "The dialog doesn't say 'save' " (change it?) and "People don't do that" (harm of doing so is?). Is anyone out there going to go "Oh no, my settings got saved when I clicked OK, and I didn't expect them to be, I was just going to crash the session to stop them being saved"? Of course not. The expectation is they are saved, or if not, it's because they are changed again and then saved.

    I also disagree with dismissing autorecover as a feature. It can be crucial. Not all scenarios afford the safety and stability you expect, not all users start from an assumption "nothing's certain so why care if a given precaution isn't working as it should", and accidents can happen. Multi-layered/first lines of defence are not inappropriate and catch many of the (hopefully few) data loss cases. Power can be unreliable, the cleaner trips over a wire, a colleague makes a mistake, wrong button clicked, OS or hardware crashes - who hasn't had these. Some users (through skill, knowhow or circumstance/fincance/hardware) can't or won't take every precaution you might. It's not unreasonable they trust IDM to have written autorecovery that works for when the issue is a "once-off" and the session can resume. "More fool you for trusting the author of the package" is not a good way to advertise support for customers.

    While I accept you have the philosophy you do, I hope you can accept others may not share it - and that's valid too. Some of us explicitly verify our disk copies (even though HD copy *should* be reliable), checksum our backups, and make sure our working software's data loss prevention also does its job. When using networked devices, one usually chooses multi-layered security, however unlikely a hack attempt might be. When using an application that will cost time and difficulty if data is by accident lost, one uses multi-layer data loss protection. An autorecover function that doesn't autorecover robustly is like an airbag that doesn't reliably inflate, or a parachute that doesn't reliably open. Ideally you'll never need it. If you're cautious, you'll make sure it's reliable and will work in that (hopefully) rare event anyway.

    It's not just personal opinion either. Someone at IDM spent time adding that autorecover function to UE. IDM decided it's worth that time investment. Presumably that person believed that UE sessions were improved or made more reliable with autorecover, or they wouldn't have done that.

    I tend to side with them.

    I accept if you disagree, but hope you understand my view on the importance.

    6,603548
    Grand MasterGrand Master
    6,603548

      Jun 16, 2013#17

      Stilez wrote:On config saving, nothing you've written says why it's a bad idea or not worthwhile saving changed settings when the user clicks "ok" or exits that dialog.
      I have not written that it is a bad idea to save all the settings after closing the configuration dialog(s) with button OK. It is absolutely okay to add code for doing that. I don't do it in my programs as I do not expect that a user modifies a setting and later my application crashes and therefore the modification is lost. The probability of such a scenario is extremly low and therefore implementing and testing a save of all settings immediately after OK was not worth the time for me. And in my applications I would need an extra function for doing that for reasons I don't want to comment on here, although I use a function which saves all changed settings on exit. However, it is absolutely okay if an application saves all the configuration settings on executing Apply or OK in the configuration window. With my previous email I just want to express that users should not expect that Apply or OK results in a save of the configuration settings as this is simply a wrong assumption in many Windows applications.
      Stilez wrote:I also disagree with dismissing autorecover as a feature.
      There is obviously a misunderstanding here. I don't have written that the auto-recovery is not a useful feature. It is a useful feature. And if a feature is not working in a case where it should also work, this case should be analyzed by the responsible developer and the code fixed / improved. For the firmwares I'm responsible in our protective devices I grant that every new release is free of known issues. But I cannot make unfortunately the same statement for the Windows applications i'm responsible for. Although I would like to fix all known issues in those applications as well, it is simply not possible because of not having the time to do so. There are always other things which have a higher priority and I'm not the person who assigns the priorities to the tasks to do, that is done by my boss. Interesting for me was always to see how easily the priority of a task can be changed by money. Make an order of lets say 1000 licenses with the condition that bug X is fixed or feature Y is added and fixing the bug or adding the feature becomes immediately the highest priority.
      Stilez wrote:I accept if you disagree, but hope you understand my view on the importance.
      That's a matter of course. I accept your opinion and the importance for you. I have a different opinion on the importance, but I accept yours.

      Read more posts (-13 remaining)