Skip to content
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

Closed
Wisdawn opened this issue Nov 26, 2024 · 8 comments · Fixed by #25
Closed

Lack of a "Save" button/link #24

Wisdawn opened this issue Nov 26, 2024 · 8 comments · Fixed by #25
Assignees
Labels
documentation Improvements or additions to documentation enhancement New feature or request

Comments

@Wisdawn
Copy link

Wisdawn commented Nov 26, 2024

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.

@i2van
Copy link
Owner

i2van commented Nov 26, 2024

I can add Save this timer on close checkbox to the close confirmation dialog (see screenshot) and add corresponding setting to the advanced settings menu and command line option.

image

It's not clear what the explicit Save command should do; current implementation allows timer window either open or saved and not both.

Saving timers by stopping and restarting, or in any other way, is strange and misleading in the original design of Hourglass

Timer is actually ticking when being closed if non-stopped or paused.

image

I agree that this is strange. Maybe instead of Save Preserve should have been used.

@i2van
Copy link
Owner

i2van commented Nov 26, 2024

Checklist

  • On Exit timers should be saved regardless of option.

@i2van i2van added documentation Improvements or additions to documentation enhancement New feature or request labels Nov 26, 2024
@i2van i2van self-assigned this Nov 26, 2024
@Wisdawn
Copy link
Author

Wisdawn commented Nov 28, 2024

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."

@i2van
Copy link
Owner

i2van commented Nov 28, 2024

FAQ describes original intention which needs no explicit Save.

Saving is adding to the Saved Timers list, and it should be be done only by a clear button or link called "Save."

When application exits all timers are saved unconditionally to be resumed on startup if requested.

How Save should work from user perspective?

  1. User clicks Save.
  2. Timer is added to Saved timers.

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 Save is to go back to the existing timer meanwhile, thus it can be either opened or saved and not both, otherwise opening saved timers on startup will be messed up greatly.

@Wisdawn
Copy link
Author

Wisdawn commented Nov 28, 2024

"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 .txt file or something; just a container of text to retrieve, and its contents are basically the timer title and the last time entered for the timer. If a copy of this Saved Timer is running, this doesn't affect the saved copy at all; the only two things that would affect or change the saved copy of the timer are: 1. Changing the title, or 2. Changing the time or countdown. Doing either of those two things, would change the static contents of this Saved Timer.

@i2van
Copy link
Owner

i2van commented Nov 28, 2024

Also, what if the user doesn't exit the app, like they restart the operating system or the system crashes?

Restart is fully addressed in my version, system crashing - partially.

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.

You don't need to save timer explicitly, it is saved automatically when closed (1. which is quite similar to Recent Files in editors, 2. I'll add checkbox Save this timer to the close dialog), and opened only if corresponding option is specified (yes, this is messed up for now).

Similarly, a Saved Timer should be a static copy of a timer, almost like a .txt file or something
The only two things that would affect or change the saved copy of the timer are: 1. Changing the title, or 2. Changing the time or countdown. Doing either of those two things, would change the static contents of this Saved Timer.

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 Recent inputs menu which keeps only time entered by user.

So, I'm going to improve the close timer dialog, update FAQ and that's probably it.

@i2van
Copy link
Owner

i2van commented Dec 28, 2024

@i2van i2van linked a pull request Dec 29, 2024 that will close this issue
@i2van
Copy link
Owner

i2van commented Jan 1, 2025

Fixed in 1.15.44

@i2van i2van closed this as completed Jan 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants