GNOME Bugzilla – Bug 740786
Redesign
Last modified: 2021-06-01 22:44:45 UTC
Allan Day has come up with some great wireframes for a new clocks design: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/clocks/alt/clocks-wireframes-2.png This new design would fix at least some of the currently open bugs for clocks and brings some fresh air to it. I opened this bug to: a) Discuss the wires b) Track the overall state of the redesign implementation I would love to help on this, I can imagine to do the implementation. (Though I might need help since I've never done much of the graphical stuff.) Some thoughts on the wires: Timer creation: * The timer creation looks a bit gray and empty to me. Though I don't know how to solve this. * I'm still not convinced about the label. Still think it should be buttonier, indicate to the user that its clickable. Alarms: * Also a bit gray IMO. Maybe we can colorize (or appropriate background images) it according to daytime of the alarm? World Clock: * I love the conversion design * I think we wanted the autogenerated clock (from location) non-deletable. In the third row the first-left mockup has still a close button for this kind of clock. * We still need to figure out what to do if we have too many clocks for our row. I'd go for several rows in this case - this way we have vertical scrolling. Stop Watch: * Design missing. New Alarm/Change Alarm Dialog: * Alignment could be better. Meaning: * Right-align the "Repeat" and "Every Day" labels * Align the center where the "Repeat" and "Every Day" labels meet with the boolean boxes to the center of the window, thus with the center of the elements above * I'm not sure whether it may make sense to hide the weekday buttons plus the every day control if the repeat control is set to false. New World Clock Dialog: * In the upper-left version no time-zone information is displayed. I suppose you mean to show more information when there are less then N entries in the box? I would rather go for showing it at every time. * In the other two versions you have the time-zone information which is great because you could e.g. use Ctrl+N, 'b', 'e', ESC if you just want to really fast check the timezone information of berlin without adding it to Clocks. In order to support this use-case even more and make the timezone information a bit more clear I'd rather do the entry as follows: +-----------------------------------------------+ | Berlin | | 20:17 | | Central European Time (UTC+1) | +-----------------------------------------------+ (While berlin is bigger as well as the time on the right side.) Please note also that I'd rather write UTC+1 in the brackets instead of just +1. Otherwise it is not clear if it means CET+1 or UTC+1 for me. I hope this helps.
Some bugs that could be taken into account for the redesign: * https://bugzilla.gnome.org/show_bug.cgi?id=697659 * https://bugzilla.gnome.org/show_bug.cgi?id=739021 * https://bugzilla.gnome.org/show_bug.cgi?id=702403#c34 * https://bugzilla.gnome.org/show_bug.cgi?id=689266 * https://bugzilla.gnome.org/show_bug.cgi?id=694709 * https://bugzilla.gnome.org/show_bug.cgi?id=688360 (Maybe we we could talk about a "Map" view?) I also added some bugs that would be fixed by the redesign to "see also".
Created attachment 292010 [details] New Mockup I took the existing mockup and changed the following things: * New world clock dialog * New/Change Alarm alignment * Added example for too many clocks * Make add label button buttonier Any feedback would be greatly appreciated.
Hi Lasse, it is great to see that you are still interested in helping out with Clocks. I am sorry for not replying sooner, but I did not have much time lately to work on gnome... Before commenting on the mockup itself, here are some more generic suggestions on how to move forward. 1) Clocks is made of four separate sub-applications (World, Alarms, Stopwatch and Timer). Obviously we must try use a consistent "language" among them, but when diving into the details I would suggest to split the mockups into 4 different proposals and also split this bug into four separate reports so that it is easier to follow the discussion on each of the components. 2) Somehow related to the previous point, I'd leverage the modularity of Clocks to focus on one thing at a time, both for design and implementation. Personally I think that Alarms and World are the two components more in need of a design iteration, but if you are personally more motivated to work on Timer to address some of your personal pet-peeves then work on it by all means! 3) While visual mockups are oviously very useful, they must be evaluated in relation to the goals we want to achieve. I think we should list what are the problems and limitations we are trying to address and maybe even more importantly which are the ones that we are not trying to address because we consider them out of scope. For instance the ability to convert a time to another timezone, or the ability to have multiple timers are features that are not available today. We should have a clear list of things we want to add and why. Once we have that, we can evaluate the designs in relation to those goals. 4) As a follow up to the previous point, we should go through the list of open issues in bugzilla, decide which one should be addressed by the new design and mark them as blockers (incidentally it would not be a bad idea to add world/alarms/stopwatch/timer to the bugzilla component of this product and categorize the bugs a bit)
I'll start by commenting on the Timer mockup, since from the blog post that seems to be what you would like to tackle first. I think there are two features we may want to add when redesigning the timer: 1) the ability to store favorites named timer (e.g. "boiled egg") so that one can just reset the timer to one of the values he used previously. When considering this, we could even come up with a few timers to ship by default so that the app could come prepolated instead of empty. 2) the ability to run multiple timers at the same time. To be honest I am not 100% sold on this feature... simple real-life kitchen timers usually just let you set one time, but if the design team agrees it is a good feature to have and if we come up with a design that does not hinder the main use case, then I am all for it. The proposed mockup accomodates the second, but (at least from what can be seen) it does not address the first. A possibility would be that the "New" button would show a popover or dialog list with previously tagged timers plus a "new timer" item (a bit like the "Open" button in gedit), though that would make usage less immediate. Another possibility would be to add a way to reach the "labelled timers list" from the setup page. From a visual point of view, I must admit I am kind of attached to the current design with the circle in the setup page that fades into the timer progress... I find it elegant and makes the setup page a bit less dull than the plain spinners. If we want to keep it, a way to represent multiple timers could be to show concentric circles while the number would show the most urgent timer.
*** Bug 688360 has been marked as a duplicate of this bug. ***
I added a subbug for the timer component because you already started. I'll proceed with the other components the same so this bug is merely an umbrella bug plus a place to hold discussions related to all components (-> Consistency) or the UI around them. Speaking of consistency I'd suggest to first write down and fix all requirements for all components itself, then make a mockup for all of them before starting implementation so we can take a critical look on consistency between them.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/gnome-clocks/-/issues/ Thank you for your understanding and your help.