Consider making an even more compact style in the new library, especially for folder display

Yes, I definitely meant it as an option - there are already two styles, this would be third. I should have probably made it more clear.

allow style/view on a per folder basis, then everyone is happy?

Differentiate between folders and tracks/points in style. Slim folders and Full tracks/points.

Actually my original idea was to achieve more compactnes by possibly showing less. I attach a graphical visualization of what I wrote in the original suggestion.

Google guidelines make sense as a default option, but they do not work for everyone. I for one am not a large person, my fingers are quite nimble (I would not be surprised if the Google guidelines were written by a large man, haha, Google employees are not exactly representative of population) and can handle slimmer items.

Seems like this idea got shared somewhere on the forum or something like that as it got quite a few new votes recently.

Hm, better Usability? For one the map preview is smaller and thus harder to see and tap (I often have to long press it to render the track). Also I always appreciated how your app was more useful and efficient than other apps that at first glance may have looked "nicer" but were cumbersome to use. As a software dev I understand your point about using standard controls but that cannot be the guideline if it sacrifices perfect UX over a mediocre one!

George D's comparison makes it sooo obvious that the new design has nothing to do with "getting used to" (the killer argument of all inexperienced designers...). Your use of fonts and colour was waaay better than it is now. I truly regret I updated just before my holiday 🤧

It is hard for me to correctly argue here. After all these years, we still do not have a designer in our team and UI is fully based on practice experience and discussions in team and forum users ... 😶.

Anyway, I've not wrote "getting used to" ... this sounds rude and I do not want to use this languge. My opinion is based on our personal experience in the field, where these changes allows us more precise control and less mistakes. And also, of couse, consistency with the rest of the app (as I already wrote).

Also, with the slim mode, you may see only a little less points and even more tracks than before...

Problem with small size of track previews > yes, I'm well aware of it and it is impossible for me, to make them bigger in current design. I already have in mind third layout style "grid", that will look like a photo gallery with big overviews. But it needs some time.

Thanks for trying to understand.

Dear all,

interesting discussion 🙂 Reading bold parts of my answer is enough to quickly get the points, the remaining is for those interested in details.

I agree to Tomas that Google guidelines as default are fine – so e.g. users first time trying Locus will have a familiar UI and feel at home, or those preferring a consistent UI across all apps over UIs that are optimzed for an app's purpose can have that.

I agree to Menion that "Google UI" brings easier manipulation in the field, allows us more precise control and less mistakes – yes, that extra big padding helps when my mobile is shaken, e.g. while riding my bike or walking. But in majority of cases when I'm using folder view of My Library, I'm planning/researching and standing/sitting/laying so my mobile is in constant position and my interaction is very precise – no need for extra big padding.

Which design is more "polished" or "beautiful" is a matter of personal taste + current trends, so it's difficult as base for discussion, and moreover, these categories are not really important for Locus: Locus is not a background image that only needs to look nice, but a powerful tool – thus I fully second Frank that "good design" is for Locus one that allows to do the work efficiently. For planning/researching with My Library, I want as much information as possible at one glance, so let's look at objective aspects:

• Listing Folders: "Slim" 7 shows folders, "Full" 6.75 and old UI showed 9.5 – so old layout showed 29% more with same displayed details except "Full" showing the amount of sub-folders (i.e. 1 icon and 1 integer number so requiring only little space). Slim is only minimal slimmer than Full, which would be addressed by Tomas' suggestion.
• Listing Points: "Slim" and "Full" show 6, whereas old 10 – so old shows 66% more with same displayed details. I don't consider 66% to be "only a little less/more".
• Listing Tracks: "Slim" 6.5 shows tracks, "Full" 3 and old UI showed 4.25 – so "Full" shows 29% less than old and "Slim" 53% more at the "price" it does not show first part of description (which I usually want to have) and elevation gain – Tomas suggests even less information.
  
• Tracks thumbnail is too small for me. I often cannot even tell apart track line (color coded elevation) from map background within rooms, and that's even worse in bright outdoor, examples in screenshot are 2nd and 3rd track and in left the lowest (2022-03-01) (the dark horizontal line at top is not part of the track). Depending on shape of track, current thumbail is too small to identify a track by shape. Map labels (city/mountain/.... names) don't show up any more, so there's less orientation anchors. These new thumbnails are usually not helping me getting my work done, the old ones usually did.
• In "Full", Dates are often cut, usually the year is missing. Didn't happen in old UI.

My motivation to participate in this topic is gettting a UI allowing efficient use, not about what I am used for years. For example, if you introduced squeeze gesture so users can quickly switch through styles or toggle thumbnail size, I'll certainly use it. If you introduced that Locus uses accelerometer information to dynamically render more or less padding, welcome! If you added possibility to configure which information to display in a folder, it will solve this topic with nearly all desires satisfied and I'll use it (e.g. for tracks, elevation is highly interesting for mountain sports but not sailing or car drives, Tomas had his desired 1-line-per-track-view, and as I have date in title (for export/share/...) I don't need a dedicated field for it but would show average speed).

@"Creating even "more slim" layout is technically more complicated"
Can't you use the existing rendering code of pre-v4.27 with My Library of v4.28+?

"Grid" would be helpful for me only if it not only showing thumbnails but also text, e.g. one really big thumbnail (maybe similar to rendering at top of details screen of one single track) and some text below like many picture managing apps do.

Personally I would not mind if the optional ultraslim view retained the information that it has now but would just be slimmer. Or there could be four - one "minimalist slim" along my suggestion and the other "full slim" retaining the information but slimmer.

I think this is like with all features - they increase the maintanance burden but make the app more useful. Also, I figured out how to add screenshots inline, so here they are (the same ones as above):

For me, thumbail of old library was big enough that I could recognize the track.

In case the thumbail is really only for sake to switch to map, why is it not the same icon as at top right in track details screen to avoid false expectation? 🤷‍♂

Exactly. No need to render a track if it was just to switch to the map.

Also I could perfectly make out the track outline and colour to remind me of the track and chose the right one.
In particular when planning on the tablet.

So, freischneider, other people may have different views than you, literally.

Tjere are literally 8 people who voted for this above, double your "3 or four". And most users do not participate in discussions like these, so there is a lot more people. This is asked for as an option. Most people probably use the default most of the time, that is true. Most people would not use this, also true. But I think most of people change at least one thing. For most of us the things we change is different. So different options increase the usability of the app. There is of course a trade off in terms of maintainbility etc., but as this seems self contained, I think it would be worth it.