This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Edge 520 Grievances

Former Member over 9 years ago

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

0 Former Member over 9 years ago

237

* the map page, while a great addition over the 510 has many UX problems:
** is there really no scale? How can I estimate the distance to the next "feature" on the map, if there is no scale shown? Here's my suggestion for a scale: don't show grids; don't show a scale bar at the bottom. Simply show a number giving the height of the screen in kilometres. From this, a fraction can be easily estimated, e.g. "it's about 1/3 of the screen or 1/3 of the number shown"
** map zooming needs to be improved. There is simply too many button presses required to zoom in and out. Firstly, I don't know what "auto zoom" does - it's not documented in the manual, and I haven't really seen it do anything while riding. What I do want to do frequently is change the zoom so that I can e.g. see an intersection detail in front of me, or quickly get an overview of the next 50 km. Currently this takes 6 or more button presses. One simple suggestion: move the "Set Zoom Level" menu item to be a top level context menu item at the top of the list. Then a quick double press of the "enter" button gets you into zoom mode. But we can do even better; more later.
** on the map page, there is frequently a large arrow, which I think is showing some kind of virtual partner. I could not find a way to turn this off. (I have turned off the virtual partner data page in all profiles.) This arrow frequently obscures my own position making it very difficult to see where I am in relation to the map.
** drop the "saving" of the zoom level (you can see this in effect when you change the zoom level, then hit the back button). This is simply not required. This frees up the enter button to do something more useful; perhaps double duty as a zoom in button. (Think about how you have to change hand position every time you wish to push a button on the opposite side to the one pushed previously).
** "North Up" orientation has the arrow (showing the current location) positioned more than 60% of the screen height from the bottom of the screen. This means that if you are traveling north, you can see much more of where you have been than where you are going. I don't think this best utilises the screen real estate. I'm not actually sure of the solution to this one. The only thing I can think of is that the arrow moves around the perimeter of a square slightly smaller than the map size. Thus if you are traveling East, the arrow is positioned left edge of the square, centred vertically. If you traveling North-West, the arrow is positioned on the bottom right corner. The point is to show as much map "in front of you" as possible, at all times. Ideally, this would be "course aware" and could use upcoming course deviations to enhance the above algorithm.

* "map page toggle": why is the only way to enable or disable the map page buried about 10 button presses deep. On my main training profile, I mostly don't need to see a map, and don't want it in the way when I cycle pages. But occasionally I get lost and need a map. This would be simply solved by putting a map toggle in the context menu. (Further, context menu items like "Set ELevation" which are surely rarely used operations could be removed). Or even better than a toggle would be a menu item to simply "show map". This does not "enable" the map in the sense that is becomes part of the page cycle; it will disappear as soon as you press an arrow button.

* maps in general really need a pan function for when you're lost. Here's a possibility: arrow keys either zoom, pan left/right, or pan up/down, and the mode is toggled by the either the light or back button (yes, re-purpose them just for this use case; no, it doesn't matter that the icons won't match).

* why is the map shown for viewing a course (Training -> Courses-> <a course>) not zoom-able or pan-able?

* why is the map shown for viewing a location (Training -> Locations -> <a location>) not zoom-able or pan-able?

* there is a bug when viewing a course in the map view where sometimes only part of the course is visible. One theory is that the map is already at maximum zoom-out. A pan function would solve this.

* contextual menus: a nice addition, but the UX could be improved. How often during a ride do you need to look at the status page? (Assuming that is, that you aren't one of these people that have constant ANT+ dropout issues). Very infrequently. So put it at the bottom of the list. Move the most used items to the top of the list.

* why is the option to enable auto-zoom above the option to change zoom level? How often do people change from auto to manual. And how often might they change the zoom level? The current implementation requires more presses.

* in menus, the ">" arrow is used inconsistently. Normal UI conventions state that if a menu takes an immediate action, then there is just the command text, but if it opens a new dialog, then there is an arrow or ellipsis. Examples breaking this convention: the "Set Elevation" invokes a number picker but doesn't have an arrow, and "Save Ride" immediately saves the ride but does have an arrow.

* why bother with an Ok/Cancel dialog on the "Mark Location" menu item? It's a non-destructive operation, and only likely to be invoked unwittingly perhaps 0.1% of all times invoked. Just mark the location. If it was a mistake, it can be deleted. And when created, add a menu item at the top (above the menu item "Change Name") that says "Done" and returns you back to where you were. I think mostly people will mark locations while riding, and are therefore not going to be entering location names while on the move. The default therefore should be one button press to finish the task.

* many tasks and menu items should return to the live data pages immediately when the back button is pressed, and not back to the menu. It's not likely that you'll be doing two consecutive tasks while you're riding. Here's an example: you're riding along and you want to change the map to auto zoom. You press enter, then enter (on "Zoom Map In/Out") then enter to toggle the auto zoom. Your task is complete, but to get back to the live data pages, you have to press back 2 more times. Why? At the least, one press should be enough, or perhaps even better would be to immediately return after the toggle press, and show a short lived pop-up (a "toast" in Android parlance) with the new value. That's two button presses saved! Similarly, for "Mark Location", it should be one press to activate the menu item, and one press to say "done", and you are back to the data pages. Currently it requires four button presses! There are many other examples.

* Course Dialog: "Navigate to the beginning of the course?" - Ok/Cancel. This cancel is ambiguous. It could mean don't navigate to the beginning of the course, or it could mean don't navigate at all. Better options might be "Yes" and "Not required".

* the "Delete Ride" button should say how many rides it is about to delete (not just "Delete Rides")

* data page MRU toggle suggestion: a way to switch between the two most recently used pages would be very useful. Here's how it would work (and it's essentially the same as any "Most Recently Used (MRU) list" as seen on any current desktop OS). When switching pages, if you don't stay on a page for more than a second, then you haven't "used" the page. Otherwise, it goes on an MRU stack. Now you need a method to switch the top two pages on the stack. What about using "long press" actions? The light button has a long press action. The arrow buttons have long press actions. What about the enter button? This could switch between the last two used pages.

* there is a bug where the "contextual menu" icon flashes on and off 2 or 3 times on the map page

* an improvement to the 5 min sleep mode: the computer should enter a "low energy" mode when paused - back-light off, GPS/sensor sampling rate reduced or turned off, etc. This state might be better triggered by the motion sensor inside the unit, so it only enters this mode when the bike is completely still, and not, e.g. just stopped at the lights.

* it seems that when a live Strava segment is activated, I no longer have access to the usual map page, but only the special segment one. That is unfortunate, because the special one does not let me do things like manually zoom the map. If you must put up a special map for Strava segments (which I don't want, by the way), at least leave the standard one around.

* there is a bug where the full-screen "pause icon" can show over the map page when I come out of the map page's zoom editing mode. It seems like this a queued notification that gets shown when I finish "editing". But often that notification happened minutes ago. It seems I am not expected to be spending a lot of time in the zoom editing state.

* the device automatically switches from "USB drive mode" to "On" if you eject the device from your PC. This is acceptable, since you can turn it off at this point manually. But it also turns on when you disconnect the USB cable. This seems unnecessary. I suppose taking something off charge you "left overnight" signifies you're about to use it. But a lot people take it off charge when it's full, and put it away.

* the manual could use some work e.g. the map "auto zoom" is not explained at all - I have no idea what heuristic it uses.

* primary menu: why is "History" above "Training" (the menu is already _not_ in alphabetical order)? Which is more likely to be used more?

* why does viewing a single ride i.e. Rides -> <a ride> not have a "Delete" menu item, while viewing a single course i.e. History -> Courses -> <a course> does. They have otherwise very similar menus.

* there is a bug which stops the device automatically selecting the most recently used (MRU) profile. On my device it always selects "Race" regardless of the last used profile.

...to be continued...

0 Former Member over 9 years ago

* fast profile switching mid-ride: am I the only one who sometimes needs to change profiles while riding, e.g. to switch from a generic profile to one focused on intervals? Currently it's a painful number of clicks. Profile switching could easily be made a top-level context menu. And to reiterate a previous point, don't ask if I want to switch when I click on the new profile; just do it.

* there is a bug related to the loading of Strava Live Segments (at least as loaded via Garmin Express). If two or more segments have the exactly the same name only one randomly selected segment is loaded; the others are ignored.

* Strava Live segments _really_ need a cancel function. And it's easily done. When the "segment approaching" dialog pops up, make it actionable, so a simple button press will cancel the live segment. No button press allows it to happen.

* the UI (at least in English mode) can't show Thai characters (e.g. in a Segment name) and will show nothing at all. At least show a placeholder glyph if the correct one is not available.

* I know I said I wouldn't mention the screen, but it is _really_ bad, which is a real shame. There will be no fixing that with a software update.

That's enough for now. I kept adding to this list, and never posting it, so I will stop here. If Garmin reads this and decides they need a new product manager, I'm available. I can also tell them how to make course elevation data _really_ useful for the rider, in place of the mostly useless elevation page.

Cheers.

0 KBLAIR210 over 9 years ago

Give this guy a job..

0 karlw2000 over 9 years ago

I used to create powerpoint slides for presentations and was told never to put more than a few bullets or you will lose your audience.

Well...you lost me.

Besides, nothing touches the 520 as far as a gps bike computer.

0 L.Rouge over 9 years ago

Give this guy a job..

Make them the boss....

Excellent compilation of issues, while the 520 might be a good bit of hardware you would expect Garmin's years of experience with GPS software and small device UI to be reflected as well but they appear to almost start again with each device.

Software writing and testing is all about getting the tiny details right but increasingly developers attention spans don't seem to be up to it.

Great contribution 40ft, thanks for the considerable effort, unfortunately I am not expecting a positive response from Garmin.

0 Former Member over 9 years ago

Edge 520

Thanks for the great info! After getting no replies using the Garmin Support form I'm tackling this forum's functionality

Does anyone have answers to these questions please?

1. How can the seconds display be maintained on the 24-hour "clock" for ride time after 60 minutes please?

2. Is there any firmware update information that can be read, regardless of the apparent lack of any user-control over such updates?

3. Can the low cadence alert be auto-disabled by the device when it knows I'm coasting downhill? [maybe a product enhancement]

4. What's the most efficient way to switch to interval mode so I can see my stats for the current interval [rather than the ride] please? [e.g. with the Joule GPS I just press and hold the lap button to flip between ride and interval modes, so, when doing intervals the device displays current interval data without having to flip screens]

Thanks for your help, Mark

0 FergalKilkenny over 9 years ago

great listing of issues, I think I agree with all of them!

0 FelipeSerra over 9 years ago

Fix fix fix, lags, pause-play-pause-play-pause,etc, etc.

0 pauloalexneves over 9 years ago

Excellent but to no avail

Excellent post. Agree with almost everything. It really puzzles me that in 2015 the is no way to configure a system to meet your needs in a computer or smart phone and save such configuration.

Bottom line is that Garmin has this market and does the minimum to keep selling sub-par hardware and crappy firmware. Nokia used to do it and... We all know how it ended.

The UI is pretty lame in all respects. Customization is a joke. Main points: why do I need stupid units on fields when I cannot see seconds past one hour ride? Or decimals in km past 100k mark? Or...

They even released a unit that is supposed to take competitive edge through strava segments that has worst functionality than the units that preceded it! (Segment data field personalization).

I come from Polar, were I rode many miles without A single shutdown, never had issues with connections, firmware bugs were solved before new features were implemented. I might just buy a V650 after all my issues with this poor implemented 520...

Just a download of frustrations that no-one at Garmin gives a damn.

Thanks again for your excellent post.

0 Former Member over 9 years ago

You can submit ideas to Garminhere,