track user interface mess and a possible solution

[joeloc]

The track user interface mess and a possible solution

Firstly, sorry for not using getsatisfaction. It has been a 404 since day one on vodafone spain, simply doesnt work. Now for the real topic:

The user interface for tracks has become quite a big mess over time. We have at least five different places now where you can "do" things with tracks: a popup menu on the map, a popup menu over a track in the track list, some onscreen buttons in the tracklist, then we have the track information window with additional buttons, depening on which tab is selected. wtf...

this is seriously BAD
 
Now let me introduce my idea. A track list and tracks are very much the same stuff as email, user interface wise. The track list equals your list of emails, a single track detail view equals a single email view.

This kind of stuff is very common on android and google offers wonderful APIs for that. Just look at GoogleMail and how beautifully it adapts between horizontal and vertical displays, how it uses side-by-side view on tablets, how you can use swiping gestures, etcpp.

Shouldnt Locus use the exact same API for its tracks? You would get all those features for free and everything would fall into place just beautifully. Users know what to expect, users know how to handle things, no learning required at all, everything works as expected. This is would be much preferable to any kind of "custom ui", even if you now think you can do things "better". In the end, it is always nicer and easier to follow standards.

Now for the track detail view (similar to an email view): Do not use tabs(for altitude chart or whatever), use one long scrolling view instead! Scrolling comes absolutely natural on a phone/tablet and everybody uses it all the time. Why mess this up and try to fit stuff into a "custom made window"? Tracks can have so many different attributes, this can never work properly. Think about <desc> and <cmt> fields for instance. They can be any length, they can be html, they can be whatever. Plus they are quite important to display nicely, many track portals put a route description in there.

I would suggest to format the track detail view internally as HTML and use some HTML class for display. No custom stuff made up from custom UI elements. Using html has the benefit of being able to display html cmt and desc tags easily. Also, users would be able to cut & paste relevant information. It always irritates me to see text on a screen that i can not mark and copy.

Also: Now we have a separate window for editing track details. More unneccessary mess. Why can I not simply edit the data I see in a tracks view right away? There is no need for yet another window with yet another formatting of some parts of a tracks data. This could probably also be easily implemented via FORMs if a tracks detail view was in HTML.

An most importantly: EVERYTHING you can possibly do to a track should be available from this new track detail view. And only there! No other popup menus, not five different places with different actions everywhere. Whenever I click on a track in Locus, regardless if its in the track list or on a track on the map or on a track name box (!) on the map, Locus must take me to the track detail view immediately and let me continue on from there. There must be no difference between clicking on a track in the map or on a track in the list. Its all the same, logically.

I know this is kind of a big change... but in the end, everything will become simple and easy and beautiful. New user will immediately know whats going on.

Obviously, the same paradigm (list & detail view) would then be used for waypoints as well. And your "categories" are exactly the same as mail folders in gmail and could also be displayed and handled alike.

Think about it. Easy, simple, beautiful, powerful, and a lot less messy than the current state of things.

Greetings from the middle of the atlantic ocean... on a ferry from tenerife to cadiz.
Joe.

[joeloc]

I still think its a good idea . Theres no difference from a users point of view between handling email and handling locus tracks. Why have two completely different UIs for this?

[Menion]

I was thinking about it immediately after you wrote it. Anyway I waited for some feedback from users ... nevermind

so, I understand you point of view, but

• cannot agree with list of places where you handle tracks
  
  • popup menu on map - simple menu. Allow to see on which point!! you tap and work exactly with this point!!
  • popup menu in track list - very similar to map. Advantage of this is that I do not need to load whole track from database. So if you want just rename or delete, you can do it immediately without wait till track is loaded. On slow phones with huge tracks - big advantage!
  • bottom menu in track list - allow to work with ALL maps, not with single one
  • track information window - contain only buttons in chart window, and these are only for work with charts!
• locus do not use system like android email at any places. Main usage of this app is in field, not in bed. So main device will be phone, not tablet. On market are stats around 3% for Android 3.x so for me, it still not worth for this work
• and finally, I'm planning to add this firstly to points manager screen, then will come probably adding possibility for categories also for tracks and then finally same system for tracks. Anyway I still think that here's enough time for this. Android tablet expansion seems to be very low compare to iOS, so for me, this have very little priority.

[joeloc]

A track is a track is a track. Oh... and it is also... A TRACK!

Why can I export a track from the track list but not from a track detail view?

Why can I not export a track when I see and click it on the map?

Why can I fill in altitude data from the track list but not from the map?

Why can I not fill in altidute data when I am viewing the altitude chart?

Why can I not enable "guiding" along a track when I see its detail view?

These are just a few examples of dozens of incosistencies with the current UI. You can not fix this by adding more and more points to more and more popup menus in more and more places. Locus has many nice functions but theyre all stowed away in different parts of the program, even though they work on the exact same thing: a track!

I spend ten hours per day with Locus, every single day of my life. I know what I am talking about . Your programs usability could benefit greatly from a simplified approach.

A track is a track is a track. It deserves ONE view with ONE set of menus.  Not a bunch of things accessible from the map and another bunch accesible from the track list and another bunch accessible from the detail view and another bunch accessible from the edit window. It probably seems somehow "logical" to you because thats the way Locus has "grown". But it is not. It is quite a mess in reality.

Just my opinion .

[Menion]

I spend fourteen hours per day with Locus, every single day of my life and I have to say, that this is not so simple . Main thing why track do not directly display same window as points is possibility to manipulate with one single point of track. How to achieve this on small phone screen with your email system? It's not simple possible ... at least I still not yet figure out it

[joeloc]

yeah... but do you spend 14 hours with locus while sweating on a moving mountain bike, wearing sunglasses in bright sunshine? or is it 14 hours in the comfort of your living room, where a few extra clicks here and there do not matter...

btw, your map selection things do not work well "in real life". it is all backwards and not very helpful. oruxmaps has that figured better, at least with different maps in different scales. but thats a different topic, lets not get into that here.

anyway, i think we are having an english language barrier here. i never said anything about tracks and points in the same window?! what good would that do?

what i said was mainly that there should be ONE track detail view to do everything from. not a dozen different places for different things like it is now. and that an email program with its folders, subject lists and mail view is just the same as track categories, track list and track detail view. i thought android had an API for exactly that kind of thing because it is very common. and if you use this api, it will magically work "just right", from 1.6 up to ics. meaning you get the actions on the hardware menu button below 3.x and the new action bars or whatever on ics, all without any sort of extra work. much simpler than keeping your "custom stuff" up to date.

but maybe i think too much of android apis and it doesnt really work that easy.

[druki]

It seems to me that the discussion is very emotional, so I would like to come back to the basic question: Is it possible to combine the different views? Because we have several requests involved in the existing solution it's not easy.
Maybe the best way is to note all features and requests and try to figure out how a "better" GUI for tracks could handle all this. Due to the fact, that menion has a lot of work with other high priority issues, I think this is not useful if he gets only general suggestions. To help him, I think it's needed to figure out how the solution could look like and at the same time trying to fullfill all features and requests that the existing solution has. How about some screenshots/drafts to show how it could look like?

P.S.:
Just to clearify my point of view: I can live with the existing track handling. It maybe could be have a straighter line. But the effords of redesigning it are a lot, compared to the needs of the standard user. Or are there other users out there that would give this a higher priority?

Last but not least I would like to thank menion again for his great work for this software and the excelent support!

[joeloc]

ok... lets start with something simple.... just the track detail view, not the whole interface around it. that can be fixed later.

a) do not split up the track detail view in tabs (info/chart). tabs are a thing for desktop machines. mobile phones use scrolling views. so simply use one big scrolling view for everything.

b) include cmt and desc fields in this view (eg from gpx import). both are very important! route portals store route descriptions there. i think locus misses out on that completely right now. note that these can be simple ascii text or also html (by using the cdata tag).

c) make the detail view editable! there is no reason whatsoever to have yet another separate "track edit window" with yet another design and yet another layout. when i see a tracks name in the detail view, i want to click on it and edit it. when i see the description, i want to click it and edit it. kill the separate edit window. simple is beautiful and less mess is always better.

d) make the detail view copy/pastable! nothing is more irritating than seeing textual information on screen that i cannot text select. what if i quickly want to send a tracks name or its length/altitude/whatever details to a friend by email? right now i have to manually type them of the locus screen... yuck :-)

all this should easily be doable by designing the detail view as some sort of HTML internally and simply using an appropriate viewing class for display. that would also allow other funny things later. you could for example include a mini-overview-googlemap with the tracks position in just a few lines of code.

[Starman]

joeloc-

If you "spend ten hours per day with Locus, every single day of my life", "on a moving mountain bike", while gazing at a cellphone screen, you're not going to be around long enough to benefit from all the Locus changes you demand.

[druki]

Hello, thank you for explaining, now I see more preciesly.
Here my comments about the suggestions:

a)
Scrolling (by swiping in the window title) could change the display views like with the tabs. In the window itself, it would "disturb" the scrolling and zooming features in the chart view (which I love the way it is). Or is there an other way to have both functionalities?

b)
IMHO displaying aditional information is a good idea, but maybe the overview could become messy if the fields carry very long information (only show one line? scrollable?). And how can I figure out that html code should be displayed? With the complete code or interpreted?

c)
also a good idea for the suggested fields. Other fields are calculated from the trackpoints and shouldn't be editable.
As I see in the edit area, there are several other information for a track (displaying settings etc.). This edit window (with all editable fields) could be integrated in the track information area. The amount of clicks (2) to get there from the map would be the same.

d)
Copying is a good idea. As I understand, you would paste in an other aplication. Editing/Pasting in fields of calculated values should IMHO not be done in Locus.

We have Maps in Locus and can see tracks with trackpoints there (and select trackpoints for editing). I think this should stay as it is, as editing of trackpoints in an other view doesn't make sense to me.

Let's see what other users and the master think about it.

[Menion]

thanks Druki,
 it's similar how I see this. My comment mainly to first point. You can now see on many windows, like map manager or info screen, where are tabs but you can also change view by swiping fingers to right/left. Same was in "track info" screen but after first try, I had to disable it because of disturbing charts tab as Druki mentioned. Similar issue was in geocaching screen where swiping disturbed "listing" tab.

2. it's probably some issue. On track info screen on first tab is already included html browser for display of description. I'll look at it

3. not agree. Why make it editable? Did you saw somewhere in system that first view is also editable? Try contacts for example. And mainly also as Druki said, "Edit track window" is more for editing style of track then for some other fields (I know, name and description but that's all for now)

4. because all informations aren't web page but normal android components (which is because during track record, they all are updated on the fly!!!), so copy/paste mechanism isn't simple to do

and finally, there is no problem in our English joeloc, it's just I cannot simply display big window when you tap on track!! There is need to be able to work with one single point

[joeloc]

i rest my case. nobody agrees with me that simple is better and that a track is always a track. locus will stay as it is then, basically. a sad day .

[Menion]

you're kidding me right? Because I agree, I wrote it at begin. I agree that system need improvements. Partially as you wrote, partially not, because you still don't accept that you system do not fix current features that locus offer. Anyway I'm sorry, but changing current system isn't so simple and also don't have hight priority. If I'll not do something with it within next 3 months, remind me