transittalk / transit-talk Goto Github PK

Certain stops, especially on bus lines, only hit certain stops at certain times. For the sake of simplicity the app should indicate that these stops are not always hit on a route.

This means we need to improve route generation to pick up on more stops than just the last one, but moving over to using transitland might help in this regard

Transit-Network is missing unit tests. Unit tests allow contributors to more rapidly develop and iterate because these tests allow them to test their code often in order to make sure they did not break anything. Database tests need to be made in order to verify data is read in correctly specifically. Here is a good document on how to write unit test for Ruby on Rails. Remember to document your tests so that others know what each test is testing and add potential fixes where possible.

You can report issues by looking at a line and then hitting the plus on the issue, or by doing the same in search. However, you cannot view issues on a stop without favoriting it or being near the stop. You should probably be able to click the stop and see the issues for it.

Before we can let other people create their own Transit Network sites, we need to figure out the mechanism through which we will do that. Are we going to make a Ruby gem? Have people clone our app and change it (like this Rails boilerplate)?

Things to consider:

• Would the solution we suggest allow for code changes?
• Do we want to be able to roll out updates to all Transit Network sites if we add new features or fix bugs?
• How technically skilled are the people spinning up new Transit Network apps?

Putting all of these questions out in the air, it seems to be me that creating a default app with a good amount of settings would be the best way to go, then letting developers fork/clone the app to customize it. This would mean that people could do pull requests back into the app and stay updated with our changes (as long as they did a fork), or choose to start with what we have and go on their own path if they clone the repository. Depending on how we want to make the license, we can decide whether people have to share improvements with us or not.

The "All Lines" page only differentiates between bus and train lines, with no other sorting. This means that the hundreds of buses have no particular ordering on the page, and makes browsing difficult and confusing.

On favorites or nearby stops, which are the two places you can view issues on a stop, stops with no issues have a strange line that shows up:

This issue is particularly visible on the CTA, which has bus numbers and bus names. You should be able to sort by either.

Original report from UX review last week:

Bus menu should have the option to sort by alpha or numeric

Right now, the display of the stops closest to a user is based on a hard-coded radius, set to 0.5 miles as of f726f3f. However, this radius is far too high to be useful in dense areas of the city, and far too low near the city's edges and in transit valleys. Instead of hard-coding a distance, we should instead switch to an n-nearest-stops display with the ability to expand the list of stops (perhaps using infinite scrolling or discrete pagination) from that point.

Original report from UX review last week:

Top menu should include the options to view Issues page, and to report an issue.

Certain buses, like the CTA 79 bus, have schedules that change over time. Our stop to line pairing system takes the first trip of the day to get stops on a line, and since this bus line (and probably others) do not hit all stops in their first trip. Check out the 79 bus schedule to check out the this issue

On CTA, this means adding the ability to view by bus or train. We should investigate to see if transit.land makes those system types clear, as in GTFS data it is only an integer field (meaning it may well be CTA specific which number corresponds to train v. bus).

Original report from UX review last week:

Top menu should include options to view by bus or train

Create a map view for viewing issues, along with settings for manipulating the map. A version of this view with default settings will be included on the top of the homepage (#73). Settings include time frame of issue display (most likely based on increments of backwards time for the MVP), region of display, and filters for the types of issues one wishes to view (including vehicle types).

More detailed information to come in further discussions, but this is an MVP component.

We are aware of a few commercial platforms that seek to enact similar goals to ours. Let's look into their features, and what distinguishes us as an open source project and a platform:

• Moovit
• Swiftly
• HopStop

In CONTRIBUTING.md, make all links to markdown documents relative links (rather than absolute ones that assume this is the repository being used). That way forks and clones have their links work properly.

Our first step in communications with administration should be to outline exactly what we want to communicate to the authorities we are trying to assist as well as flush out the questions we have for them. We can then decide exactly at what stage in our process would a first meeting be most impactful and be sure that that meeting would productive.

Continuing in our aim to make this repository into a generic platform from which location-specific apps are forked, we should remove all information and code that is related specifically to the Chicago Transit Authority (CTA) or other Chicago-based transit systems.

Specify whether the user is signed in or not. Homepage needs to have a way for user to log in in order to view Favorites.

The rake files that are used to read in the data are too narrow for the scope of the project. The rake files need to be updated to accommodate a large number of naming conventions and data styles. Here is a resource that talks about rake files and what to do about them.

In order to display the position of transit vehicles in real time, Transit-Network must be hooked into Google Maps API. The stations should be rendered onto the map to allow the end user to use this web framework to not only learn about issues, but also navigate the city. There are some good blogs and there are also a few good Ruby on Rails gems that could be useful for implementing the API: Google Maps for Rails and google-maps-services-ruby.

Using Chicago Transit Authority data on the yellow line, for example, duplicate stops appear due to them being marked with different GPS coordinates. We need to figure out a better algorithm to create stop links and mark duplicates.

These buttons are too close together and are very small. Here's a screenshot:

Original report from UX review last week:

The star/favorite button and the + button are too close together and too small (fat fingering is problematic) --> maybe put the star and + buttons on the row below the bus line

Users might see an issue, and not have the time they need to write down what occurred. Users should be able to start a new issue and save a draft, which will store their GPS coordinates when they made the issue draft, and record when the draft was made.

Essentially, this would involve adding issue drafts that might contain only a location or only a stop & line, and a timestamp for when you started them.

Credits to @Sluker for coming up with this idea.

1. Add the distance from user to nearest stop
2. Sort the nearest stops by distance (closest to farthest)
3. Would be super cool if there was an option to visualize the stops on a map.

(Edit: The above are not considered primary issues/enhancements. The distance function is a helpful feature, but not essential. The issues listed below have much higher priority.)

We want to provide a visualization format for live transit vehicle tracking to be built with. We need to settle on a data presentation for this, and figure out how to create it in skeleton fashion without fully implementing it for a system.

As discussed on 2/20, 2/26, and 2/27, orient the homepage around a vertical split: the top two thirds of the page will include a display of recent issues, and the bottom third will display a prompt to create a new issue report.

More detailed guidance on this is pending further UI/UX prototyping and discussion, but it is part of the MVP.

Favoriting a stop redirects you to the favorites page, which takes you away from any page you might have been on. Favoriting should probably fire an AJAX request instead or at worst refresh the current page.

Original report from UX review last week:

When clicking on the Favorite button, it automatically takes me to the Favorites page (which I don't necessarily want).

The homepage should have a way to filter by Bus or Train immediately under Nearby Stops. This is related to issue #42 - once filtered by Bus or Train, the lines should be sorted alphabetically or numerically.

Add functionality to allow administrative users to delete existing issues and user accounts. This functionality should let admins see which user created each issue, so that patterns in erroneous or malicious issue reporting can be discovered.

Our first step to outreach should be to define exactly what we want from our outreach team and how we would present that to them. (Asking for polls, asking for simple tasks such as posting about what we are, and generally creating awareness.) Next we should research and compile a list of groups/events that we can present to/at.

Considering that the current Transit Network site is not going to be the homepage of the Transit Network project, we need to create a site that pitches Transit Network as a platform, showcasing its benefits and walking developers through the step by step instructions for how to spin up a Transit Network instance for any transit system described by GTFS data.

We should discuss what we want on the site (a basic spec) and how we want the site to look (design) before implementing (in that order).

The site would probably work well if it was hosted on GitHub Pages and powered by Jekyll.

All issues say that they are from 10 minutes ago, which seems a bit unlikely. Here's a screenshot:

The responsible code is (from app/views/stops/_show_with_issues.html.erb:9):
<span class="issue-time"><%= time_ago_in_words(DateTime.now - 10.minute) %> ago</span>

Clarify documentation to walk through how to load GTFS data locally for someone with little to no prior knowledge or familiarity of GTFS data.

1. Wheelchair accessibility data is not pulled at the stop/station level. Transitland data on wheelchair accessibility indicates only whether the vehicle (train or bus itself) is wheelchair accessible.
2. Wheelchair accessibility data needs to be added for transfers between two lines, i.e. Jackson blue/red line.

This should fix #19 and #17 ideally. Or at least help with it.

Talk about what it would be like to have our application send notifications to users as they approach stops with current issues or concerns. This would encourage users to keep the app and to continue to be active in using it. If people can be notified in real time if there is an issue at a stop close to them it could certainly help keep people safe.

Example: If someone reports violence at a stop, people coming in on the next train could know right away that they should be looking out for a potential threat or concern.

As of now, there are multiple views in which TransitNetwork still loads up location.js, even when nothing on the page needs it. This would be harmless in most circumstances, yet this file populates and reloads a page with coordinates as soon as the original view is loaded. This starts becoming an issue for pages that explicitly need parameters defined for its own page only (or items that require form data submitted and processed through params). Most noticeably, however, users can have trouble navigating back/forward pages due to the fairly rapid reload of pages.

For example, when CTA data is populated at the Transit Network Heroku app, visit https://transit-network.herokuapp.com/lines/1322. The page will immediately pass in parameters for latitude and longitude. Going back with a single click will effectively accomplish nothing here. While navigating back twice isn't the end of the world for some users, it certainly isn't something we should expect them to do here.

This has been a bug almost since the inception of location services in general. As a result, I'll be adding myself to this issue since I wrote location.js, but am open to any discussion on handling random loads outside of inhibiting the loading of said script as well. (To clarify, I'm not suggesting against this method...it's just the one that I will likely use if nobody says anything.)

When running locally using development or test, SQLite is called upon for database management. However, this leads to problems with another gem in the project, Geokit, and the way it calculates distance within a one mile radius to nearby stops. Much like with other platforms that Geokit breaks on, the least() function is called when trying to complete this operation. However, since this method does not exist in SQLite (but does exist in MySQL2, and thus does not break on production), an error occurs on the majority of dashboard loads. Attached below is a screenshot at 360x640 resolution of the error's appearance.

Certain types of issues are best described with a picture, so allowing photo attachment to issues would be very useful.

Look into the proposal put forward by Arnold Kasemsarn at the University of Chicago four years ago (sent to me via email, and will be added to this issue soon) for a platform similar to ours.

Nearby stops shouldn't be a text list, it should be a map so you can easily see where you are and pick a stop you want.

Original report from UX review last week:

I want to see nearby stops on a map

After using the Transit Network interface on mobile, our team suggested we increase the mobile font size. We should start a discussion here to determine a more specific change.

Original report from UX review last week:

Make all the text larger

The database being used right now does not support any real-time tracking of any vehicles. One feature that needs to be completed is adding these fields so that development in this area can go forward. The current data base uses SQLite during the development and testing cycle and it uses MySQL on release.

Reorient the report creation process around the screen-by-screen flow discussed on 2/20 and 2/27. This flow is as follows, provided by @jannielung in the notes from our 2/20 meeting at Chi Hack Night.

UI/UX decision tree:
-Homepage displays issue visualization and Create an Issue Report button
-Create real-time or past issue?

Create a real-time issue:

1. App will pull up nearest stops and possible train/bus lines for user to select (based on GPS coordinates)
2. User selects category of issue
3. User inputs issue via freeform text

Create a past issue:

1. User selects time and date
2. User selects bus/train line
3. User selects station/stop
4. User selects category of issue
5. User inputs issue via freeform text

Styling of this will be determined through further UI/UX conversation and prototyping, but the logic can begin being implemented immediately.

The issues page does not work well on mobile, and should be fixed

Original report from UX review last week:

The "Issues" page does not display well on an Android. The text does not wrap around and one must scroll to the right to see all the information. The alignment of the columns is also awkward.

Look into Travic, a system that currently tracks transit movement of systems around the world.

This is the last step for implementing real-time transit tracking. This is useful for end users as it allows them to plan their time around where the transit is at any time. This goal is important to work towards because it increases the amount of use the framework will get as it will allow users to gather more information from it. Here is an example of a website that integrates google maps well. The Transit-Network's goal is to cover as many uses as possible, so it is important to keep all implementations broad and usable in as many locations as possible.

It's hard to make sense of the nearby stops without knowing how close those stops are. Related to #47, which suggests showing nearby stops via a map.

Original report from UX review last week:

I want to see actual distance the nearby stop is from my location

We need an admin panel for a site admin so that you can customize a Transit Network site. This includes changing the main color of the site (should change theme color and header color), change the name of the site, and change any images that we use.

This should partially answer #38.

have common issues available to choose and an option 'other'.