From the wiki: "general efforts to not expose the save concept to the user where possible". I do not think that's correct: what we are trying to hide to the user is the concept of saving *to a file* which is not the case here.

With that said, I am not saying that we should expose explicit saving, as a matter of fact what I had in mind is to automatically store previous named timers plus a finite amount of recent unnamed timers and then have a way to quickly pick one of these timers in the setup page.

I do not like having all previous persistent timers on screen since I think goes against the principle of hiding as much irrelevant information as possible: I still think the *primary* use case is using one single timer at a time, and when I start boiling eggs I'd much rather see one big timer with my timeout instead of 6 timers, 5 of which are stopped

(In reply to comment #1)
> From the wiki: "general efforts to not expose the save concept to the user
> where possible". I do not think that's correct: what we are trying to hide to
> the user is the concept of saving *to a file* which is not the case here.
> 
> With that said, I am not saying that we should expose explicit saving, as a
> matter of fact what I had in mind is to automatically store previous named
> timers plus a finite amount of recent unnamed timers and then have a way to
> quickly pick one of these timers in the setup page.
> 
> I do not like having all previous persistent timers on screen since I think
> goes against the principle of hiding as much irrelevant information as
> possible: I still think the *primary* use case is using one single timer at a
> time, and when I start boiling eggs I'd much rather see one big timer with my
> timeout instead of 6 timers, 5 of which are stopped

If I understand you correctly, you want to be able to access predefined/custom defined timers without having to have them persistent on the screen. I agree that this would be nice.

I can imagine a combination of all the three possibilities:
 * History: The last n timers are saved and accessible during timer creation so the user can avoid typing too much. This concept does not offer named timers.
 * Saved timers: No concept present yet. I'm not in favor of this one because it leads against our general efforts to not expose the save concept to the user where possible.
 * Persistent timers: When a timer is created it just remains there until it is deleted. It can also be named.

What do you think about the following specification:
 * If a user starts a timer it remains visible in the view until he explicitly deletes it. The user has the full control.
 * If a user deletes a timer he shall be able to undo this operation easily.
 * When creating new timers the user shall be able to access his saved templates and optionally a history of the last timers he started. However timers that are equal to saved timers, thus redundant information, shall be hidden. Templates and history elements shall be easily deleteable.
 * A user shall be able to save a timer to a template that is visible in the view.

> 
> What do you think about the following specification:
>  * If a user starts a timer it remains visible in the view until he explicitly
> deletes it. The user has the full control.

Not sure what this means exactly to be honest :-)

>  * If a user deletes a timer he shall be able to undo this operation easily.

I do not think this matters much, timer are very easy to recreate

>  * When creating new timers the user shall be able to access his saved
> templates and optionally a history of the last timers he started. However
> timers that are equal to saved timers, thus redundant information, shall be
> hidden. Templates and history elements shall be easily deleteable.

yes

>  * A user shall be able to save a timer to a template that is visible in the
> view.

I would not phrase it that way, I think a user should be able to tag a timer with one (or maybe even multiple?) labels. The act of labelling a timer makes it persistent in the history/list of templates

(In reply to comment #3)
> > What do you think about the following specification:
> >  * If a user starts a timer it remains visible in the view until he explicitly
> > deletes it. The user has the full control.
> 
> Not sure what this means exactly to be honest :-)

It means the timer doesnt vanish if it times up or if one closes the app. It also implies that if you create a timer it will not override the existent one. For our primary usecase (one timer) the easiest way would be to change the existent timer.

At least to me a non-persistent timer doesn't make much sense.

> >  * If a user deletes a timer he shall be able to undo this operation easily.
> 
> I do not think this matters much, timer are very easy to recreate

Its a trivial thing but I like having an undo operation for destructive operations in general. The default GNOME 3 way.

> >  * A user shall be able to save a timer to a template that is visible in the
> > view.
> 
> I would not phrase it that way, I think a user should be able to tag a timer
> with one (or maybe even multiple?) labels. The act of labelling a timer makes
> it persistent in the history/list of templates

Thats better. I changed the wiki page to mirror that.

(In reply to comment #3)
> 
> 
> > 
> > What do you think about the following specification:
> >  * If a user starts a timer it remains visible in the view until he explicitly
> > deletes it. The user has the full control.
> 
> Not sure what this means exactly to be honest :-)
> 
> >  * If a user deletes a timer he shall be able to undo this operation easily.
> 
> I do not think this matters much, timer are very easy to recreate
> 
> >  * When creating new timers the user shall be able to access his saved
> > templates and optionally a history of the last timers he started. However
> > timers that are equal to saved timers, thus redundant information, shall be
> > hidden. Templates and history elements shall be easily deleteable.
> 
> yes

I'm a little nervous about this talk of templates. It sounds rather complex and like work for the user. Let's not over-complicate things.

It's appropriate that timers are persistent, since someone will often want to re-run a timer within a short space of time, or they will often have a small number of presets which they use often.

And if timers are persistent, then the problem of "saving" is resolved in a simple and straightforward manner.

Yes, I assumed the use of "templates" was just a wording issue.

I think we all agree that the use case we want to address is giving easy access to a bunch of previously used timers and that we want to manage this set of timers automatically without exposing a way of "saving" them.

The design proposed in the mockups addresses these requirements, but I do not particularly like it because it means keeping visible in a very prominent way timers that are not currently active. Beside I do not think it scales well to more than a few timers. I do not think that scaling up to a lot of timers is very important, but if we leave the current design just to support that I think we may as well try.

(In reply to comment #5)
> I'm a little nervous about this talk of templates. It sounds rather complex and
> like work for the user. Let's not over-complicate things.
> 
> It's appropriate that timers are persistent, since someone will often want to
> re-run a timer within a short space of time, or they will often have a small
> number of presets which they use often.
> 
> And if timers are persistent, then the problem of "saving" is resolved in a
> simple and straightforward manner.

(In reply to comment #6)
> The design proposed in the mockups addresses these requirements, but I do not
> particularly like it because it means keeping visible in a very prominent way
> timers that are not currently active.

With the current requirements I was trying to reach a compromise between those two opinions. Let me try to phrase the consequences from them:

1) Timers are persistent
2) Timers can be labelled
  2.1) Any labelled timer _internally_ will automatically have a template. This involves no UI so it doesn't add complexity yet.
3) When the user creates a new timer he can access those templates and a history. I imagine this similar to what happens in the gedit open dialog.

If you want you could say, lets not speak about templates but about having a ranked history of timers available at creation where the labelled ones have a preferred position. Also if the user doesn't want to clutter the UI with old timers and sees that he can access previous times fastly without having to reenter the data he can just delete them and have those things in the view that matter to him.

(In reply to comment #6)
...
> The design proposed in the mockups addresses these requirements, but I do not
> particularly like it because it means keeping visible in a very prominent way
> timers that are not currently active. ...

It really depends on how you anticipate people using the timer. My impression is that timer reuse is common. As such, having them persist is the most helpful thing we can do. Otherwise, it will be really annoying if you have to recreate a timer over and over again.

(In reply to comment #8)
> It really depends on how you anticipate people using the timer. My impression
> is that timer reuse is common. As such, having them persist is the most helpful
> thing we can do. Otherwise, it will be really annoying if you have to recreate
> a timer over and over again.

I guess we need to collect some data about this, but for my personal experience reuse is high but having them around all the time would be annoying: on my phone I basically use the timer when cooking a few dishes (e.g. eggs, 2 or 3 types of pasta, rice) and then for a couple of things like remembering to go upstair to check if the washing machine finished. Let's say I have 5 recurring timers. I basically never use two of them at the same time.

My ideal use would be

1) open timer app
2) easily pick "egg" (without having to google "boiled egg time" each time like I do now! :)
3) start the timer and easily check the progress even at a glance


I would not like having 4 timers stopped and just one running on the screen using just 1/5 of the screen space to show the info I am actually interested in.

Even worse if instead of 5 the recurring timers are 8 or 10 I would find just clicking new and typing "egg" much handier than scrolling through 10 persistent timers that do not fit in a screen

Hi,

I've created a new mockup based on the requirements and your comments. It's embedded on the wiki page.

https://wiki.gnome.org/Apps/Clocks/TimerRedesign

I'd love a few comments.

I've gone through the conversations and I guess I agree with Paolo Borelli that we should have a history list of recently used timers and we should be able to open the app and simply pick one of the timers. Plus what I think in the case where multiple timers are running that we may show the timers according to their remaining times. Like if there are 4 timers for 4 different times then we can show the one which has the least remaining time and we can generate some sound when 2-3 seconds are left and as soon as timer is inactive, we can replace it with the timer which has the least remaining time and if there is none then we can simply show the window which is shown currently when there is no timer is running.

May be it is complex or odd but we can manage multiple timers without flooding the screen with multiple timers case. Plus we can also show 2 or 3 timers with least remaining time at one time on the window instead of only one timer if we want to.

It is just my personal opinion. I'm not sure if it is helpful.

   I rethought and I got that the idea that I mentioned above is not good in case where user wants to pause a timer or wants to know remaining time in between and may be many more things. I only thought of solving screen flooding problem but that is creating other problems so the above idea is not feasible.

Hello, I'd like to have two simultaneous timers running, and I found this redesign discussion. It's been a while since the last comment, so I don't know how useful my input is, but let's try anyway.

My main suggestion regarding the current mockup on https://wiki.gnome.org/Apps/Clocks/TimerRedesign is to not use a dialog on the New button, but instead put the selection of previous timers on the "start view" (where the HH:MM:SS is selected for the timer). So the New button would be used only when needing another simultaneous timer (i.e. very rarely). That way the window doesn't become crowded by old inactive timers. The disadvantage is that the start view would be more complicated.

The start view should probably have two lists: a few recently used timers (using only the time as the label) and named timers (those that the user has explicitly saved). There would then need to be also a "Remember this timer" or "Name this timer" button for adding new named timers and a way to delete items from the named timer list. Apparently not everyone likes an explicit saving concept, but I find it better than requiring the creation of a new timer pane every time the user wants to recall a previous timer.

A question: since I personally only need the ability to have two timers running simultaneously and don't care that much about remembering old timers, is it possible to only make an incremental improvement that adds the simple Add button and the 'x' to close a timer pane? Or is it a requirement that the timer remembering functionlity has an approved design before any code is written?

(In reply to Tanu Kaskinen from comment #13)
> A question: since I personally only need the ability to have two timers
> running simultaneously and don't care that much about remembering old
> timers, is it possible to only make an incremental improvement that adds the
> simple Add button and the 'x' to close a timer pane? Or is it a requirement
> that the timer remembering functionlity has an approved design before any
> code is written?

I should add: I may try writing the code myself, so I'm not suggesting that someone else should do that. But don't count on me, I will pretty likely lose interest before completing anything useful.

A redesign happened.