I have been a 510 user for about 20,000 km. I have been using the 520 for about 2,000 km: all on the 2.60 firmware (for Taiwan I believe). What follows is a series of bug reports, UX grievances, questions, and suggestions for improvements, that have occurred to me in this short time. I don't expect a response from Garmin, but maybe, just maybe, they will see this and heed some of it. The list is not exhaustive and is in no particular order. I understand that some issues may be due to my own misunderstanding, and I will be gladly corrected. I don't really address larger functional issues here such as segment matching tolerance, live tracking dropouts, Connect syncing, poor screen visibility, etc. which could each have their own entire post.
I like many things about the 510 and so far the 520. The GPS stability and accuracy is truly outstanding, in all weather conditions. And, for me at least, the ANT+ stability is near perfect, with very few problems in over 30,000 km. But...the UI and UX flaws tarnish what should easily be a best-in-class experience. Hopefully the following will help to improve the situation.
* the buttons on the side are too hard to press. Given their position, and the years-old design of the Garmin "1/4 turn" mount, I frequently accidentally turn the device in the mount, while trying to press a button, if I don't get my hand position just right. These buttons should be super-light-touch activated; I would have thought capacitive buttons might work well here. Or the arrow buttons should be on the top of the device which then won't then turn the device.
* the annoyance of the hard to press buttons is greatly intensified by the overall "inefficiency of navigation" of the entire UI: simply put, many things require far too many button presses to accomplish. Configuration is painful, but bearable, given that usually it is done off the bike (although how nice would it be to do it on a smart-phone). But "click efficiency" while on the bike is critical, and poorly done. Specific examples will follow.
* why was the behaviour of the back-light button changed compared to the 510? It used to toggle between off/user-configured/full. Now it doesn't toggle anything, but only enters "change the level mode". In other words, functionality was removed from the button, without adding anything else.
* why is a dedicated back-light button even needed? On the 510 I only ever changed the light level very rarely. It seems wasteful to have a button dedicated to that purpose. Suggestion: put the power button on the long press action of the enter button; make the back-light level just another menu item; and you have a free button. Why not make it customisable? There are plenty of potential uses for it.
* the back-light should have an option to change modes when changing from moving to stationary. e.g. I usually ride with the back-light always on, but when I stop at a shop for long periods of time (or even at a red light), the back-light is only wasting battery; I must manually turn it off if I want to maximise battery life. Further, to give an example of click efficiency, to turn off the light from 50% now takes 7 button presses! On the 510 it took on average 2.
* why are the ride auto-pause and auto-unpause and "movement detected" messages modal? There is simply no need. Frequently in the middle of executing a sequence of button presses a message will pop up, effectively "stealing" one of the presses and interrupting the sequence. Further, why don't the arrow buttons dismiss these modal dialogs?
* when "Start Notice" is enabled, and you stop the ride while still rolling to a stop, you immediately get a "movement detected" modal dialog, again stealing the button press you were about to make to save the ride. A few seconds delay is all that's needed here to improve the UX.
* why doesn't the back button choose the "Cancel" option in dialogs. This is standard behaviour in almost all other OSes, usually bound to the escape key. It should never do nothing.
* the current method of identifying which page you are on, i.e. the "tab bar" on the left side of the screen, is not very useful because it disappears. Thus you can only know what page you are on _after_ you push an arrow button. And therefore you don't know how many button presses are required to get to the page you want. Here's am idea: drop the tab bar, and put the page number permanently in the top right corner (in place of the rather unnecessary "context menu" icon). Then you will easily know how many button presses to get to the page you want and can do it without looking.
* the data page transition animations are not helpful. They "jank" (i.e. drop frames) all the time (CPU isn't up to it I suppose) and waste time when I could be looking at data. Drop the transitions, and use the afore-mentioned page number to recognise the page change.
* transitions can also be disorientating when a data field remains in the same position on the next page: it's there, then it slides up, then it's there again. Here's one idea based on my use case: I often have two adjacent pages with the same layout and all the same fields except for one or two. If instead of a transition, just the fields that changed between pages were "flashed", it would be very obvious what happened, e.g. average power switched to lap power.
* more on data page transitions, I often experience "hangs" while riding, i.e. button presses do nothing and sometimes the data stops updating. Sometimes waiting 10 seconds will restore functionality and the button works; sometimes it doesn't, and only "escaping" back to the home page and re-entering the data pages makes it work.
* why is that the 520 has both a physically larger screen, and a higher PPI than the 510, and yet the biggest numbers I can realistically display
on the 520 are _smaller_ than on the 510. This is possibly the most important function of the device: to show numbers in a manner useful to the user. As a racer, I want to see speed and power in big, bold numbers, such that I can see them when I'm bent over the handlebars with sweat pouring into my eyes; but I still want to have HR, Cadence, and others on the same page. The 510 supported a 6 field layout which had 2 big numbers at the top, and 4 small numbers at the bottom. With the 520, the 5, 6, 7, and 8 field layouts all have small numbers only. The only way to get numbers as big as the 510 is to go down to 4 fields, which simply isn't enough.
* there really needs to be more thought put into the way field names and units are displayed, to better utilise the screen real estate, and improve the UX:
** I almost never need to see units displayed on the fields. I happen to know that my speed field is being shown in km/h and my heart rate in beats per minute. If screen real estate wasn't at a premium, it wouldn't matter so much, but it is.
** field layouts with 1, 2, 3, and 4 data fields all have the same size numbers. Why? What's the point of going from 3 to 2 if the numbers don't increase in size. There is too much white space.
** when units are displayed next to the numbers, the two combined are centred in the display port. This means the numbers are off-centre by varying amounts. That is simply wrong. Again, de-emphasize, or remove, the units, and make the numbers front and centre.
** field names are placed _on top_ of the numbers! They are also considerable bigger than on the 510. Looking at my 520 in front of me, there is at least 40% white space on the screen, due to the fact that the field display port is much wider than it is high. What a waste. Again, there is limited screen real estate to show as much effective information as possible. The current implementation could be greatly improved.
** here is one solution: stop displaying units, and move the field names (abbreviated) to be right-justified and vertical; centre all the numbers in their display ports; and add more page layout options, e.g. two side by side fields, in the top third of the screen
** field naming is inconsistent, e.g.:
*** "Pwr. Last Lap" vs "Last Lap Spd." vs "HR - Last lap"
*** "Pwr. 3s" vs. "Lap Pwr."
*** "Current Lap": no mention of time, and no units displayed
** if the units potentially change on a given field, e.g. from m to km, just use decimals! There is no need to say 450 m when .450 will suffice.
* the new lap information page: why can you only see one field in the lap list? I want to see speed and power. Not enough room? Maybe make it two lines per entry? Or leave off the units. Again, I know my average speed is in units of km/h and my average power is in Watts.
* there is a bug in the lap information page which makes it unusable - it takes a long time to show the list of laps, and the time is directly proportional to the number of laps (I have mine showing power, if that is relevant). This obviously should be cached and very quick to display, but it raises a bigger issue regarding event loops. Every page should have an early exit available in its event loop so that a second button press will immediately terminate any work being done for that page and move onto the next page. As it stands with this bug, I might have to wait 10s or more, before I can change the page again.
...to be continued...
