build usable, fast, nice-looking and correct open source apps

[derhuerst]

There are many apps, but many lack one or more of the following factors:

• usable – The app should serve its target audience in the best way. This usually means to have several apps covering different use cases.
  • tourists: they usually don't bother about some details and lack the local context (such as confusing line names)
  • citizens
  • commuters: they know their way to work very well. they usually care about delays and disruptions and may want to have shortcut/customisable features.
• fast – Especially many (semi)commercial sacrifice practicality by being too slow.
• correct & detailed – The app should ideally contain all information that's necessary to navigate. This includes local context and tiny details that people from an area expect.

[derhuerst]

Many apps & suffer also suffer from the fact that upstream datasets/APIs don't fit together. They often either only cover one region or are not detailed enough.

[derhuerst]

Some target audiences that are often not served (well):

• mobility-impaired people
• visually impaired & hearing-impaired people
• illiterate people & people with Dyslexia
• tourists: they usually don't bother about some details and lack the local context (such as confusing line names)
• commuters: they know their way to work very well. they usually care about delays and disruptions and may want to have shortcut/customisable features.

[derhuerst]

Some handy features that the KakaoMetro app has:

• in the station info view, it shows
  • all exits (which have a number)
  • which facilities (such as ticket office, rest room, elevators, etc) it has
  • per line:
    • the adjacent stations
    • realtime departures in their directions
• in the journey view, it
  • shows which carriage of a train to enter, depending on where to get off
  • allows for each leg to be taken later
• the transfer time is calculated based on the actual walking distance and the chosen walking speed
• it offers both fast and simple routing methods
• it does routing on a metro map (see vbb-map-routing for an OSS example)
• it can remind you to get off a train

[derhuerst]

the TFL journey planner has options to

• adjust the maximum walking time
• adjust the walking speed (slow, medium, fast)
• pick faster routes if they require more walking
• work in one of the following modes:
  • compute the fastest routes
  • compute routes with the fewest changes
  • compute routes with the least amounts or walking

Also, it supports the following levels of accessibility:

• No accessibility requirement
• Use escalators, not stairs
• Use stairs, not escalators
• Step-free to platform only
• Full step-free access

[derhuerst]

Citymapper

• will tell you which is the best carriage to enter
• tells you wether the journey (not just departures) is based on realtime data
• will notify you when to leave or get off the train
• will notify you about disruptions on selected lines of selected means of transport

[juliuste]

Should support multiple languages* by default.

*spoken languages, not programming languages 😛

[derhuerst]

https://mobile.twitter.com/dcmetrohero/status/992076450282041345 https://dcmetrohero.com/performance?byTimeOfDay=true&endDate=4%2F26%2F18&lineCodes=RD%2COR%2CSV%2CBL%2CYL%2CGR&servicePeriods=AM%20Rush&startDate=4%2F26%2F18

[kiliankoe]

https://news.ycombinator.com/item?id=17005924

I just had a discussion about this with a friend of mine, Jaffar Salih (we studied Interaction Design together so topics like this fascinate us), and what he remarked is that navigation apps could actually be educational tools for learning to navigate yourself. They just need to add clear markers of landmarks in their route descriptions. Even more interesting: since Google already keeps track of where you are very often, it could use your favourite shawarma place or regular bus stop as a "personalised landmark". to give you things to orient by and help you connect the dots and fill in the gaps. Same thing with familiar routes.

[derhuerst]

an interactive route map for Austin

[Bertware]

Target audiences are often not served (well): ...

• tourists: they usually don't bother about some details and lack the local context (such as confusing line names)
• commuters: they know their way to work very well. they usually care about delays and disruptions and may want to have shortcut/customisable features.

I'd say these are two completely different target audiences, which would be best served with their own apps. A commuter has a yearly subscription so doesn't need tickets, has a lot of context, wants detail, and can make his own choices, knows of alternatives. Tourists don't need to know train numbers, but want to easily find the best ticket. Tourists might not know the names of stop areas, while commuters might be better served with the quickest possible auto-complete to enter the stop name which they know the name of.

Some more examples on how these 2 groups can have different needs:

As a commuter, I want a shortcut on my home screen to make a search for my Home -> work route (or for all departures from my home station). As a tourist, it's easier to just search whatever you need for those few days.

As a tourist, I don't know about the local operators. As a commuter, I know exactly which public transport agencies operate in the area, and which operators I can use with my ticket/subscriptions.

As a tourist, I want to see all routes and tickets for them. I might already have a ticket, in which case I want to highlight the routes I can take. As a commuter, I already have a ticket/subscription and I want to see all routes with my ticket. I am not interested at all in tickets.

[derhuerst]

KDE Itinerary aims to build a Google-Now-like travel assistant app for the KDE mobile OS environment.

The library assembling all the required data is kpublictransport. It could be bundled in more ways, e.g. as an Android or iOS app, or run as a daemon on desktop OS, so that other client apps can integrate the data it provides.