Clocks 0.1.2 was released in time for GNOME 3.6 beta and it more or less implements the design prototypes available. At the moment I consider it a prototype itself (not something I would rely on to get up on time 
) and some parts are still rough but I think it is in a good state to be tested and evaluated and to make a new design iteration in time to have a nice clock application ready for GNOME 3.8.
What follows are my considerations after playing with the application for the last weeks... some of them are small details, some other could imply completely throwing everything away and start over 
Some of the issues should be discussed in bugzilla (and some of them are already filed), but I started writing this down as a mail and I though it would make sense to have everything in one place.
Features
- I think the current featureset is right and that's what we should work on.
General
- My main problem with the application as it is today is that it feels a bit dull: it is simple and clean and it does (or should do when implementation is completed) all that it is needed, but at the same time it is (imho) not beautiful and compelling... it needs some more character. Is polishing the rough edges and the proper attention to detail enough?
World Clocks
- The main missing ingredient here are the city images. This is surely the most distintive trait of the design mockups and it is probably the main reason behind the feeling of dullness... the problem is, do we have a concrete plan on how to get there in practice? Collecting and shipping a full db of of pictures seems unlikely to happen. Automatic fetching from some service has a whole load of problems: how to make sure the image is relevant? Is the service "free"? How do we work "offline", eg. in an airport?
- We should show more information beside the city name, at least the nation (which "cambridge"?) and maybe the timezone name
- Adding a new clock relies only on the city name is not always nice. Far from scientific user testing, but a couple of users I showed to app to said they expected to pick from a map
Alarms
- I think alarms is the most important feature of the application: if it worked properly it would surely be the one I use more. Maybe because I am used to the app on my phone, but I feel it should be the "first page" of the application (unless we start saving the current page, in which case it becomes less important)
Alarms need to go off at any time with the app closed and provide proper interaction also with gdm running etc. This requires both design and infrastructure. See https://live.gnome.org/GnomeClocks/AlarmsBackend
- The iconview for the alarms is quite ugly right now: the day/night image makes little sense for alarms. Using colors has been proposed, but mockups and design is definitely needed here.
- Is the iconview the right widget for the job? Each alarm does not have an obvious distinctive icon and normally I would expect the user to have very few alarms
- Not all alarms are recurring, we should allow "only once"
- It should be possible to enable/disable an alarm without deleting it (implementation constraint: standalone view can contain a switchbutton, but an iconview cannot)
- Keyboard usability: stopping and snoozing should be possible with a simple keypress
- freedeskop sound theme ring tone is sad. Should we allow per alarm ring tone selection?
Stopwatch
- Design for "laps" is needed: a stopwach without the ability to times is not very useful. Should the list of laps go between the time display and the buttons or below the buttons?
- Keyboard usability: starting/stopping and taking laps should be possible with a keypress
Timer
- Could be nice to have a visual representation of how much time is left
- Minutes spinbutton should be preselected by default so that one can type a number (clutter seems to get in the way though)
- The current "ta da!" notification needs to be replaced
- Do we need something stronger than a plain "ding" sound?