hsldevcom / digitransit-ui Goto Github PK

Now it seems that search are is little bit too large for mobile.

• In some cases locationing timeout does not work?
• When user does "relocationing" by clicking transparent bar, it "flashes" old address.
• We should not use browser location cache when user clicks on transparent location bar. Transparent location should always fetch current location. Rest of the application can use 1min cache.

• Remove OSM attributation from small map (We will only show it on full screen map)
• Use better marker with animation defined in HSLdevcom/digitransit#64
• Link to full screen map. Whole small map area works as a link. We still put "fullscreen icon" on bottom right corner of small map
• Show user's location as now. If there are stops on map area, show them on small map with reittiopas stop icon. User cannot click on stops, click opens map into fullscreen mode.
• Small map cannot be moved nor zoomed
• When user's location is changing, map shall move with him
• Animated location icon

• Use same logic as in front page
• Ui should be as defined in concept
• After changing time new routes will be calculated
• Should we also implement front page time at the same time?

• Use active area plugin
• Show user's location with svg marker
• Remove copyright text from map. If this is not allowed accorind to terms, make "less visible"
• when we got location, zoom closer

It is always visible. Browser: chrome

• Show stop's name, address and code as defined in concept
• Show next departures as defined in concept
• Line will take user to line page
• Info icon will open info page
• Set as favourite works. If stop is favourite, show icon in pink
• back button takes user to previous page
• We only show x amount of departures when page loads. x = what can be fit on page
• Infinite scroll to fetch more departures. When date changes, put small separator and a date in format "la 11.3.".
• Stop page is accessible through url

Out of scope for this:

• Map

Just a static map

• Update location when user comes to front page
• We can keep "no location panel" visible while locationing is in progress
• If locationing takes over 10 seconds show error "Paikannus ei onnistunut. Yritä uudelleen tai kirjoita lähtöpiste"
• if locationing is disabled show message: "Lähtöosoite linja tai pysäkki"
• When locationing is in progress user must not be able to enter location manually. Disable control

• Current offcanvas implementation is not working for us. Come up with a better solution.

Currently for developing geocoder and UI locally, the geocoder URL needs to be changed at multiple hardcoded places.

now search still contains old text

• Map will take whole page as defined in concept
• When map is opened in full screen, set zoom level so that every stopcard stop is visible on map
• Map can be zoomed and panned
• Show stops on map
• When user clicks on stop, it will open popup as defined in HSLdevcom/digitransit#63 If we are missing design, we shall use leaflet default popup as a popup
• Show stop name next to stop (PO want's to see how this looks)

When user clicks either logo or "reittiopas" text, he will be taken to front page.

Architecture changes:

• Switch Flex implementation
• Refactor stores to better support favourites and nearest stops

Features:

• Show 5 next departures per stop card
• Show those lines at the bottom of stop card that don't fit into five first departures
• By clicking "star" stop will be set as favourite
• If stop is in favourites "star" should remain highlighted
• Open stop page when stop card is clicked
• Disable masonry on mobile
• "Search more" button shall fetch more stops when clicked

"Lisäksi linjat 818, 818"

• select unit testing framework
• write tests for search

• Show stop on map with stop icon
• Show user's location on map if it fits in with current zoom level. Zoom level should be so close that street names are visible.
• Map cannot be zoomed or panned
• Whole map works as a link to full screen map and click opens full screen map
• All stops are shown on map that are inside current map view

Come up with a solution, maybe use saucelabs?

• React + Flux

• Add coffeescript support
• Maybe use webpack
• React support

Design:
https://projects.invisionapp.com/share/MY2F0CQ2W#/screens/67568727?maintainScrollPosition=false

• Show user's selected start location
• Show user's selected destination
• Show 3 route alternatives
• Show route alternatives on map
• By clicking route alternative user will be taken into "route dummy page"
• Top right corner icon opens route defining "dummy page"
• Use OTP basic algorithm
• For each trip ui shows those fields that fit into view. Prioritizing for fields:
  • 1. Walk icon, vehicle icon + vehicle number, waiting time icon
  • 1. travel start time
  • 1. travel end time
  • 2. vehicle start time
  • 2. Walking length. Round to 0.1 km. note that time is not shown for walking
  • 3. vehicle end time
  • 4. vehicle stop name (see current reittiopas)
  • 5. waiting time in minutes if it is more than 3min.

Out of scope for this task:

• Offcanvas contents
• Searching more than 3 alternatives

• Start and stop address works like frontpage search
• After changing start or stop address user initiates search by mobile browser keyboard search button
• Search can be initiated with "magnifying class" icon as specified in concept
• Logic for search boxes should be similar to front page

• Validate our flux implementation. Should we use some other?
• come up with radius that defines when user has moved (e.g. 10m)
• When location changes, update stop cards
• When time passes, update start times on stop cards

Shoud we use http://susy.oddbird.net/ instead of Foundation grid?

• now front end build takes too long
• consider webpack

• Use LIJ interface
• Departure must show whether this is realtime or timetable information
• requires also changes to navigator server

Autocomplete logic for searches:

"kirkkotie" ->

• Kirkkotie, Espoo
• Kirkkotie, Kauniainen
• Kirkkotie, Kirkkonummi
• Kirkkotie (E6081)
• Vanha Kirkkotie, espoo

"kirkkotie " (Space at the end) ->

• Kirkkotie, Espoo
• Kirkkotie, Kauniainen
• Kirkkotie, Kirkkonummi

"0070" ->

• Helsinki (0070), Helsinki

"kirkkotie 1" ->

• Kirkkotie 1, Espoo
• Kirkkotie 10, Kauniainen
• Kirkkotie 1, Kirkkonummi

"Urho ke" ->

• Urho Kekkosen katu, Helsinki

"Roihuvuori" ->

• Roihuvuori (kaup. osa), Helsinki
• Roihuvuori (osa-alue), Helsinki

General order of results:

1. Address
2. POI (e.g. Finlandia house, Tampere)
3. Service (e.g. Library)
4. Stop

When User:

• Moves autosuggest cursor:
  • Selection is street name: Move Map to Street name {min number} location
  • Selection is any other: Move Map to element location
• Selects autosuggest and no location is set:
  • Selection is street name: Use Street name {min number} as start point
  • Selection is any other: Use suggestion location as start point
• Selects autosuggest and start location is set:
  • Selection is street name: Use Street name {min number} as end point
  • Selection is any other: Use suggestion location as end point

Datastores:

• Use all that are available through geocoder

Resolve city by stop code prefix:

• e = Espoo
• v = Vantaa
• po = Porvoo
• pn = Pornainen
• ka = Kauniainen
• hy = Hyvinkää
• jä = Järvempää
• ke = Kerava
• ki = Kirkkonummi
• la = Lahti
• mä = Mäntsälä
• ri = Riihimäki
• si = Sipoo
• so = Siuntio
• tu = Tuusula
• starts with number = Helsinki
• any other = -

• Application name = "Digitransit demo"
• Remove hsl logo

If no location is set:

• When user searches for address, set location = "address 1"
• When user searches for stop, set location = stop koordinates

Now Google page speed gives score 58/100 for mobile implementation
https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fmatka.hsl.fi%2Fopenjourneyplanner-ui%2F

We should improve "above the fold" speed and at least try:

• Rendering templates on serverside