Direction search usability

[adrium]

Please reduce the clicks needed to adjust the search parameters in the direction search.

A bit of back story... I have been using this app since its first release on F-Droid when it was called Liberario. I love the app and a big thanks to grote and all the contributors! 😊

My first reaction to the new GUI of version 2 was that I did not like it and I found #462 very quickly. However, I am aware that most GUI changes do not resonate well in the beginning, so I refrained from commenting and kept using the app.

In the last few weeks I had to travel more often. Although I knew the city, I did not know the public transport lines beyond the central area and hence, used the app extensively. The GUI has not grown on me. ort163's comment about its usability is spot on.

I finally decided to create a new ticket, because of this comment in the issue mentioned above (and got convinced to do it now, because it will get a nice number 😉):

This are all for the directions search mask and should be a dedicated ticket I think.

Bringing back the GUI of version 1 would be an improvement because of the following reasons:

• Setting the time and arr/dep should be considered as a basic functionality and should be very visible.
  • For example, if you go to a location, you maybe need to set a specific arrival time.
  • If you go home on the other hand, you want to depart now.
  • So you may have to change those parameters for every new search.
• Better visibility should reduce the number of clicks needed and hence, improve the overall user experience.
• The display of the parameters is neither confusing or distracting, nor using up too much screen space.

Of course, we can only speculate about the usefulness for the majority of users. Unless there is a poll. However, the reactions to #462 indicate that there is significant interest. I propose that the reactions to this post should be considered as a primary source when evaluating the usefulness.

• I am aware that Transportr is mostly developed by one person in their unpaid spare time.
• I can help myself to get this feature implemented or know someone who wants to do it.

I hope I could address all the topics in the feature request template.

[grote]

@adrium something like this? #548 (comment)

[adrium]

Absolutely, thanks! 😊

Additionally, let me propose two additional options in the settings menu as a minor enhancement.

1. Set departure based on location which is checked by default and corresponds to the current behaviour. If it is unchecked, the From field should be left blank for new searches.
2. Default view where the user can choose between the options Directions Search and Map View. The chosen view should be shown when the main launcher icon is clicked.

[ialokim]

@grote What happened with the idea of rearranging some icons in the directions search form as shown here? Was there any work left to do or why did you decide to revert this change?

I quite liked the look and I think this could also be used to display the selected means of transports directly and thus targeting the problem mentioned in #484 (comment):

If more than half of the means of transport are selected, I would display the deactivated ones (e.g. with a red cross on top of them), so that at most four icons would be shown.

[grote]

This work is somewhere in a branch, almost but not completely ready. Now if I only could find that branch...

[grote]

I thought it is https://github.com/grote/Transportr/tree/directions-form but this seems to be already merged!?

[ialokim]

Well, you wanted me to revert this commit back then in #572 as we wanted to publish a new version with some bugfixes quickly.

almost but not completely ready

Is there something I could do to finish it?

[grote]

Ah that is why it is shown as merged in the UI.

Well, as a start lets make a list of things that are needed to get this into a release state.

If more than half of the means of transport are selected, I would display the deactivated ones (e.g. with a red cross on top of them), so that at most four icons would be shown.

I don't think there's space on small screens for displaying several means there. Also don't do red crosses. Use material design way of crossing through things.
My plan was to have a little red dot on the products button if the user did not select all. So clicking this button would bring up the selection dialog.

If I remember right, the main problem is that the design is ugly. It isn't really up to Transportr's standards. It is just a bunch of icons, not all of them self-explanatory thrown together at the end. There's no separators for example. I am not sure it is good to expose all users to that extra complexity. One idea was to have two modes. The old one and this one.

[ialokim]

Use material design way of crossing through things.

Sure, I would have to look into this, but should be no problem.

I don't think there's space on small screens for displaying several means there. (...) My plan was to have a little red dot on the products button if the user did not select all.

That's true, but on bigger screens there would be space so why not combining both ideas: Show a little red dot and one symbol for small screens and several buttons if several are (de-)selected for bigger screens.

I am not sure it is good to expose all users to that extra complexity. One idea was to have two modes. The old one and this one.

I kind of disagree here, because I think there are also problems with the old design not being really intuitive (e.g. changing time as departure or arrival hidden into some submenu, means of transport not shown at the first glance). I think we should agree on one design instead of maintaining both as this could also lead to confusion (e.g. after a new install or when seeing a different UI on a friend's phone etc.).
Why not adding a new "onboarding help" once we agree on a design explaining the several icons for new users (similar to what there is already for mentioning the submenu in the directions form)?

It is just a bunch of icons, not all of them self-explanatory thrown together at the end. There's no separators for example.

What do you think of this regrouping? Everything related to from, to, via in the top-right corner, everything related to time bottom-left and means of transport bottom-right.
Not sure though whether vertical dividers are considered good-practice in Material Design.

[grote]

Show a little red dot and one symbol for small screens and several buttons if several are (de-)selected for bigger screens.

As the one having to maintain the app so far, I always refrained from adding different layouts and functionality for different screen sizes to keep the maintenance overhead as low as possible.

Why not adding a new "onboarding help" once we agree on a design explaining the several icons for new users (similar to what there is already for mentioning the submenu in the directions form)?

That could help, but there probably shouldn't be more than one onboarding per screen.

What do you think of this regrouping?

That's a step in the right direction. But it doesn't solve the design issue. For example, there's a prominent separator at the top, but only between star and expand. Why not between other icons?
To be honest, I don't think the separator works. I had tried that as well, but it looks even worse. Could we maybe have some sort of negative elevation for the buttons, so they are laid inside the red top sheet and visibly buttons?

[ialokim]

Another one, trying to reduce the number of icons:

I'd propose to move the departure/arrival selection into the time picker as following:

[ialokim]

I've also considered moving the textfield related icons to the right of the screen, but I'm still not really convinced:

[grote]

I like this one: #600 (comment)
but maybe move the expand icon all the way to the right?
If I remember this right, I didn't add the arrival/departure info to the time/date picker, because there was no way to fit it on very small screens. Maybe a ScrollView inside the dialog fragment would help?

I feel that this option #600 (comment) is wasting too much horizontal space and the empty space behind the location fields looks strange.

[ialokim]

I like this one: #600 (comment)
but maybe move the expand icon all the way to the right?

So like this?

If I remember this right, I didn't add the arrival/departure info to the time/date picker, because there was no way to fit it on very small screens. Maybe a ScrollView inside the dialog fragment would help?

Or couldn't we just limit the height of the datepicker depending on the screen size so that it always fits? What sizes of screen did you consider?

[grote]

So like this?

👍

Or couldn't we just limit the height of the datepicker depending on the screen size so that it always fits?

That wasn't possible when I tried.

What sizes of screen did you consider?

It should ideally work on all phones out there. It helps to have a test phone with a small screen, but you should also be able to use an emulator with 320x480 for example.

[nlgranger]

About the wasted horizontal space in #600 (comment) you can move the swap button over in-between the address fields. it make its purpose very obvious and doesn't take much space:

The french SNCF app has the same and I believe older version of google maps used to have it as well.

[ialokim]

About the wasted horizontal space in #600 (comment) you can move the swap button over in-between the address fields.

Nice idea, but I guess it would not really play well with the "clear" buttons at the right side of the adress-fields in Transportr. Any ideas on how to deal with this? (Moving them to the left inside the fields would lead to the same "wasted" space.)

[nlgranger]

Good remark, I just checked the SNCF app and the swap button is hidden when editing the addresses. It's not really useful at that moment anyways.

[ialokim]

True, that makes sense and may also work in Transportr like this. Perhaps @grote could tell us whether such an on-top, kind-of-floating button would fit into Transportr's design 😄

[grote]

Even though I think material design does not really have this kind of overlapping button, the solution could work. A few reservations I have about it:

• it will be tricky to get get state changes right and display all views correctly when states change, roboelectric testing could help here to convince us that it was implemented correctly
• finding a design and implementing the animation when the Via location gets shown is still unsolved and will be also tricky

All in all, I think @ialokim's current solution will be easier and faster to implement with less potential for bugs.