rcavaliere commented 1 month ago

The starting UX / UI is the one implemented on mobility.meran.eu.

We need an adaptation of it since:

the open source project we want to use could not so easily adaptable
we have new mobility services to integrate, not considered yet.

In particular, the integration of flight services has to be considered and designed carefully.

Expected UX:

Possibility for user to choose one of the served airports as starting point, destination could just be in South Tyrol. Expected intermodal trip suggestion: flight + local services up to destination (e.g. hotels or other POIs)
Possibility for user to choose one of the served airports as destination point, origin could just be in South Tyrol. Expected intermodal trip suggestion: local services from origin (e.g. hotels or other POIs) + flight

ch-routerank commented 1 week ago

After considering we think that the following two areas are the most important to improve in the current application:

Autocompletion / Search field
Map and map-layers

These two features are the one the user will interact with the most and are very powerful in order to integrate new content or services.

The auto-completion / search field would allow the user to look for various POI/Services and for the application to react differently based on the content selected.

The map allow allow the user to search POI/Services within a specific region or area

Single search field proposal:

The application would start with a fullscreen map and a single searchbox element:

The user could then search for locations, stations, bike stations, airports and other POI.

POI Selection

When a user pick a POI from the search field, the application would react in two ways:,details about this POI would be displayed according to the POI type. And the map would be adjusted according to the POI type.

When a POI is selected it would load the POI details in a side-bar under the searchbox. Depending on the POI type, different information could be displayed: 1.1 For a train station: it could display the next departures as this 1.2 For an airport: the details could show the flight webcomponent from NOI Techpark
When a POI is selected, the map would center on the selected POI. Depending on the type of POI the map could be configured slightly differently. 2.1 For a train station:, the map would zoom on the station and display the different platforms/boarding areas if provided by OTP. Additional layers such as micromobility could be automatically enabled to display bike-sharing in the vicinity or parking options. 2.2 For an airport: the map could zoom out and display the known direct flight routes from and to this airport like this:

POI Selection from the map or through deeplinks

The application should be adapted to allow the user to select POI directly from the various layers integrated on the map. The behavior would then be similar to the POI selection through the autocompletion field. This can be done by interacting with the map and enabling relevant layers or by going through the 'nearby' module.

The application should also allow external applications to easily deeplinks into a POI detail view, the application should then load the poi details with the relevant map behavior.

Trip Planner

In order to search for itineraries from/to POI and addresses, the user would either have to select the trip planning option in the top tabs or could use predefined call for actions within the POI details view such as plan a trip 'From here' and 'To here'

Reasoning

Here's various points that we considered with this proposal that we think are relevant and pros of this approach.

Simple UI/Design

By keeping the map as the main focus of the application, the style/design can be kept to a minimal footprint, this has several advantages. It would reduce the implementation effort and allow us to focus on integrating as many of the services/data as possible and it would help re-use of the application by partners or other websites by being more "neutral" while also opening the door to distributing the application as web-components.

Extension to new services

The approach we proposed in term of interface focus on content and is easily extensible in the future, new mobility services could relatively easily be added in Pelias and the relevant behavior/ POI details view component could be implemented in the application to accommodate for the specifics of the new service.

Some services might not easily be found using text with pelias, for instance car-sharing,and only by exploring the map, these would be better integrated only through the map as a new map-layers either through OTP if provided there or through a separate data service.

In case a service would need to be integrated that isn't easily searchable by text or geographically, such as potentially some on-demand services or weather information, we would suggest then to create a new 'tab' at the top of the application to load a custom view for this service. However we think that most services are either very well integrated by text search or geographical search.

Mobile consideration

We also consider this approach to work very well for mobile integration, as the single search field then open a single POI detail view or map view.

Integration into partners/exiting websites

Another interesting usage of this approach is the potential re-use as a "web-components" to be integrated into external website, especially the 'deeplinks' to specific POI.

Next steps

In order to achieve this goal, some effort should be made on the Pelias geocoding feature, The current version we've tried from the test environement seems relatively lackluster in term of content integrated and multiple services would need to be integrated in it properly. At the very least the stops, stations and data integrated within OTP should be integrated in Pelias with proper attributes/categories or layers in order to differentiate them.

Ideally here the following next steps could be done:

Ensure the relevant airports and stations are properly integrated in pelias geocoding service
Improve existing or implement a new auto-completion field, it should properly display relevant icons for airports, train stations, bus stops. This should support rich-view for the poi proposition in order to display for instance service provider icons or relevant bus lines at the stops
Implement a new home view in the application including the searchbox and the map zooming behavior as well as a basic POI view.

rcavaliere commented 3 days ago

@ch-routerank in general, I like your approach. This is overall the UX / UI approach that is mostly applied, in particular in MaaS applications. I have some general thoughts that I would like to share:

as POI, we could also consider the tourist POI we have in the Open Data Hub. Already used for example by suedtirolmobil, see here:

We could provide you the API call to get these POIs to be considered in the geocoder. This is an important functionality, since a normal user knows famous POIs, addresses, etc. and less the name of the stops

once a POI is selected, what ever it is, we can activate an "around me" box which shows the availability of mobility services near this point, ordered by departure time. Check for example https://mato.muoversiatorino.it/, developed with Digitransit UI. I would make this a little bit different for sharing services, since I would show the stations and indicate the current number of available vehicles.
once a POI is selected, it is immediately considered as origin point, and a second box is opened in order to let the user insert a destination option
in case an airport is selected as origin POI, we can get a visualization like you proposed. We can also select an other airport and check the next flights for the selected O/D route

An open point for me is still to conceive the way we want to visualize car pooling / on-demand services. I will provide you some more input on this

rcavaliere commented 1 day ago

@ch-routerank @nl-routerank @leonardehrenfried some additional thoughts for the visualization of car pooling / on-demand services. This would my idea:

Search through trip planner

Car pooling: actually in OTP we have integrated car pooling trips, which are modeled as normal PT trips. Therefore we should be able, if the router provides this kind of suggestion, to have in the suggested trip results such car pooling trips as well. Of course these should be graphically different from normal PT trips. All available information about suggested trips should be properly presented, incl. a deeplink in case a user (passenger) wants to enter in contact with the other user (driver)
On demand. At present we just support "area" services, e.g. not linked to fixed routes, and just making trips between one (virtual) stops to another one (each trip is defined differently based on the requests of the user). The expectation is that if the user wants to search for a trip connection between A and B, and this is near one of the virtual stops served by the on-demand service, then the router should suggest the easiest (quickest) trip connecting two virtual stops, eventually as just one leg of a more complex trip. This leg could be eventually bookable, i.e. there could be a link to an external service with which the user can try to book exact this trip suggestion.

Map visualization

Car pooling: if we activate the reference layer, we could see the starting points of the trips, as points (similar to stop points, but differently marked). With a filter we could also decide to visualize, as alternative, the final points of the trips. If you click on these points, you can visualize the entire geometry of the trip, up to the destination point
On-demand: as it is now, with visualization of virtual stops and real-time position of the on-demand vehicles

Please note that in short we could also have real-time taxi information! Mainly this will be in the form of real-time positions of taxis. I would suggest to visualize them as a particular on-demand service. Taxis will have reference taxi locations where people find taxis standing, from which they can start a trip. The difference here is that they can serve all points in a specific area, I don't know if we can somehow represent this. Otherwise the concept is similar to on-demand, and data will be modeled in the Open Data Hub also in a similar way. Of course taxi and on-demand should have a different graphical representation and be presented as two different services.