-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lack of a "Save" button/link #24
Comments
I can add It's not clear what the explicit
Timer is actually ticking when being closed if non-stopped or paused. I agree that this is strange. Maybe instead of |
Checklist
|
Regardless of the technical details in the background, in the visible UI, a user should never see a word like "Preserve" because it's alien and never used in software. "Save," on the other hand, is a universal term used in almost every known app and software. Most users intuitively understand what "saving" means. Moreover, Hourglass already has these menu options: "Saved timers," "Open all saved timers," and "Clear saved timers." So, the proposed "Save" link basically adds this timer to the "Saved timers" list; and this should be the only way a user can get a timer added to the "Save timers" list, because, as I said, adding timers to that list by stopping, closing, or restarting is bizarre and misleading. Regarding closing and minimizing, I don't think they need to be changed or added, because a user can user the built-in Windows feature of clicking X to close and clicking the dash to minimize each counter window. And as expected, close will just close and dismiss that timer, regardless of whether it's been added to the Save Timers list or not. Minimizing will also just hide the counter, regardless of anything else. If a user tries to close the window of an active timer (non-paused or non-stopped), then yeah, maybe in this case, a pop-up prompt can ask the user what they actually want to do because that timer is active. Regardless of what the user chooses to do, as I indicated, Pausing, Starting, Stopping, Closing, and Minimizing timers or their windows should all be separate from Saving a timer or counter. Saving is adding to the Saved Timers list, and it should be be done only by a clear button or link called "Save." |
FAQ describes original intention which needs no explicit
When application exits all timers are saved unconditionally to be resumed on startup if requested. How
What should happen to this timer afterwards? Should it still be opened? If so, then there would be the two "the same" timers - the one opened and the one saved and both are ticking. It's like fork in Unix. However, intended purpose of |
"When application exits all timers are saved unconditionally to be resumed on startup if requested." This is unideal, even clearly outright undesirable, because it forces multi-timer users to be meticulous about closing each non-repeatable timer before they exit the app. Also, what if the user doesn't exit the app, like they restart the operating system or the system crashes? Moreover, I still haven't tested your version thoroughly, but I wish that was how the original saving functionality of Hourglass exclusively works — it doesn't. The app clearly saves timers with various other ways, not just by leaving them up while exiting the app. For example, I'm certain that clicking "Stop" saves the timer. Not sure if "Start" also saves the timer, but it probably does. I'm certain of this because after restarting my operating system and running Hourglass days ago, it opened with multiple duplicate copies of the same timers! Again, all this is about the original Hourglass, not your improved version. "What should happen to this timer afterwards? Should it still be opened?" Yes, because shutting down or closing the timer should be done by closing the timer's window, like closing any window. That's at least how I'd think of it as an average user. "If so, then there would be the two "the same" timers - the one opened and the one saved and both are ticking." This sounds like a very bizarre concept! And I know you're talking about the original Hourglass. I'm just wondering why on earth would be a "saved" timer be ticking?! That's definitely not even remotely my idea of saving a timer or a saved timer. From my perspective, a saved timer is a static timer or constant "container;" it just has a timer title and the last time saved, and that's it, but it's not ticking. The reasons a user would save it is that they want to see it open automatically when they run the app the next time, or they want to easily open its window from the Saved Timers list. If this helps, as an average user, I definitely do not expect Saved Timers to be ticking or to open ticking (open in a ticking state, whether opened manually after closing their windows or opening automatically when the app is run for the first time after an operating system restart or so). My idea of saving is just like saving a document in Microsoft Word: If you save a Microsoft Word document, then you don't get two copies, one open and one saved, at least not in practice or as far as the human user is concerned. It's just one copy of the document, and it happens to be saved. If the document isn't open, then it's static and not changing at all. Similarly, a Saved Timer should be a static copy of a timer, almost like a |
Restart is fully addressed in my version, system crashing - partially.
You don't need to save timer explicitly, it is saved automatically when closed (1. which is quite similar to
CLI covers all that (that why I chose Hourglass in the first place); one can create scripts for often used timers or use something like LINQPad script. Also there is a very limited So, I'm going to improve the close timer dialog, update FAQ and that's probably it. |
Fixed in 1.15.44 |
Thank you very much for improving Hourglass. I can already see you implemented many improvements to the functionality and UI.
Please also remove the automatic saving functionality in any way, then restrict it to a new "Save" button or link.
Saving timers by stopping and restarting, or in any other way, is strange and misleading in the original design of Hourglass.
The text was updated successfully, but these errors were encountered: