Cities nowadays provide a unique social and economical landscape. Main services of cities are the creation of jobs, basic services for a dense living population including affordable housing, transporation and transport safety, recreation areas, sanitation, water and food supply, science, culture and education and innovation. In this century the amount of people in cities will increase to around 70–80% (Bannister 2007). This means that the cities infrastructures are challenged by the growth of the population.One problem among others is the increasing need for flexible mobility. People need a cheap way to move around in a city. Good city planning can improve to build up or establish sustainable short circuit economies where distances of travel by the habitants are minimized. Bicycle sharing offers can dramatically improve the transportation within such socioeconomical spaces (Collier et al. 2013). This way the goal of strengthening environmental, social and cultural amenities can be reached. Ahern et al. also describes how bicycle routes are well combinable with strategies to improve the resilience and sustainability of cities. They are a good example for the implementation of multifunctionality in cities where greenways can be included and therefore improve habitat restoration leading to benefit for urban biodiversity (Ahern 2013). An answer to many calls for environmental friendly transportation systems strengthened by the global debate about climated change could also be mitigated by using sharing bicycle economies (Ahern 2013, Kenworthy 2006).
Zahran (2008) shows that income has an influence on the use of bicycle in the US and Sietchiping et al. (2012) describes how motocycles and bicycles are the main mode of transportation in rapid growing sub-saharian cities. The main winner there is probably the motocycle where the world bank review describes that cheap and functional transportation is demanded by the people. This leads to the use of motocycles because they need much less space in the bustling and dense urban places then bicycles. Although bicycle also tackle this space problem they are less used because of the lower power as a transportation vehicle (World Bank 2002). But Zahran et al. (2008) also describes that in the US the use of bicycle decreases with the increase of hazardous air pollutants (Zahran 2008). This raises the question if in other countries like the ones described by Sietchiping et al. people also consider such things or if more people are at risk to be affected by harmful pollutants. Another harmful factor which is present in the US aswell as the subsaharian countries is the risk of being involved in an accident. Compared to european countries the risk of being killed or injured as a cyclist or pedestrian is high. Therefore another need for encouraging people to use bicycle as a form of transportation is public safety. Compared to other countries some european countries have changed from road planning to safe pedestrian and bicycle planning. The third important variable besides the ecological and social benefits, which underlines the importance of bikes as a partial mode of transportation systems is the simple health benefit of cycling. As the paper of Pucher et al. (2003) states: "Several articles and editorials in the leading medical and public health journals have explicitly advocated more walking and cycling for daily travel as the most affordable, feasible, and dependable way for people to get the additional exercise they need" (Pucher et al. 2003). Overall we see that a lot of factors influencing the use of bicycles as a part of public transportation and that these factors are highly dependant on the local properties. But with respect to the SDG's a lot of problems in any big city of the world could be mitigated by sharing bicycle systems.
The importance of sustainable, eco friendly and cheap or lets say fair transportation is undoubtedly important aswell as the benefitial effects on each habitants living quality for example by increasing personal health. Questions therefore remain on how exactly sucessfull bicycle sharing projects can be implemented. Findings in the literature show that short circuit economies, pollution, the physical and social environment, socioeconomical factors and some cultural, historic background can explain the amount of bicycle-users in urban places. Therefore we visualize one case where such a transportation system is widely used (New York City) and how it can substantially contribute to a sustainable city. The visualization therefore can help to optimize such systems and furthermore help to estimate what the potential or problems of bike sharing can be for other cities around the globe. It investigates patterns of users and combines it with the spatial relation of the city. Although bicycle transportation of course cannot replace all kind of transportation systems and we have to be aware of the specific social, economical and cultural background of a city it can mitigate to the challenges of the 21st century.

Layout The application is split into three main parts: (1) Control panel on the left, (2) Main map in the center and (3) the statistics panel on the right (for mobile users the application is rendered different, showing the parts one after the other when scrolling down).
The idea here is, that all the controls (change pie chart data, change background layers, filter for specific times and dates, …) are close together, located in the left/topleft region which is the area where most readers/users would look first. As the main attention should be focussing on the map we placed it in the center, which also helps dividing the control (left) and the statistics (right) panel.

Visualisations & Statistics The number of possible statistics and visualisations we could show in our statistics panel on the right are endless. We decied to include four relatively general ones: (1) Trip count over selected dates, (2) trip count over selected hour of day, (3) mean user age over hour of day as well as (4) trip count by distance. There is already a lot of interesting patterns, that can be seen in these visualisations: go look for the weekends in the first plot or compare the mean age inbetween Queens and the Upper Eastside. And we should not forget our focus here, sustainable transport. This becomes especially clear if you look at some weekdays in the Midtown Manhattan area, where two massive peaks show the daily commuter activity.
To give some general information that in some ways could be found in the charts, but is very hard to extract, we also included two short sentences in the top that inform the user on the sample size she/he choose with the 'Polygon Draw' tool.

User Interface & Experience Our main focus in designing this application is its usabilty. How can we break our user interface down to the most important controls? What parts can or should we hide and where do we place them?
We solved these questions by grouping our elements by inputs (control panel on the left) and outputs (main map as well as statistics panel on the right). Every input that is not directly related to a specific element (i.e. the 'Y-Axis fix' option for the plots or the 'Remove Polygon(s)' button that is directly tied to the statistics shown) is placed in the left panel. Here you find the category selection for the pie charts, the date/time filters, size controls as well as the option to change the background map. For first time users we also included a very short introduction to our application, although we hope the user interface (UI) is designed in a way that it does not need a lot of explanation or training. Because "a user interface is like a joke. If you have to explain it, it’s not that good" (@martinleblanc, twitter). To get some feedback on our design early prototypes as well as the final application were given to peers and family to play around. We then used their feedback as well as our observations while they were navigating the application, to further improve the user experience (UX).
Several further steps were undertaken to improve the UX. First, our sliders are watched by a javascript that only updates the values if the user lets the slider go. This speeds up performance (as intermediate calcuations for every step are skipped) and reduces the redrawing of plots to a minimum. Second, the viewing area of the map as well as the zoom levels are limited, so the user can not just zoom in or out and get lost somewhere else in the world. In case the user still gets lost, there is a zoom-out button in the map controls that resets the map to the initial view. Third, by hiding controls that can not be used (i.e. the date slider if 'Date & Time Filter' is unchecked) we limit the UI to things that actually have an visible impact on the main map as well as the visualisations. This is also the reason, why the statistics panel on the right only shows data if a polygon has been drawn on the map. As soon as the polygon is deleted, the panel also goes back to blank.

Color All the colors are based on ColorBrewer (colorbrewer2.org) color schemes and sligthly adjusted to match with the overall design. The whole application works for each of the three most common types of color blindness: Deuteranopia, Protanopia and Tritanopia (tested with ColorOracle, colororacle.cartography.ch). As there are no specific colors associated with our variables (i.e. age) we choose green as our main colors in the pie charts, as it is known to be a color that is perceived as 'calm' (at least in the context of the western world).

Pie Chart Instead of focusing on single values (i.e. user age mean) our goal was to also show the distribution within a category (age). By classifying our variables (age, trip duration, trip distance) into four classes for each station we can do exactly this. Two main thoughts went into the design of the pie charts and their associated legend.
First, there is no legend for the size of the pie charts, as this is an interactive tool where users can just click on a pie chart and get detailled information on its class values. The size of the pie charts always shows the total number of bike trips leaving a station at the choosen date and time range. The are of the pie charts is proportional to this count. On purpose we decided to not implement the flannery compensation, following the negative critique of Edward Tufte in 'The Visual Display of Quantitative Information', 1998 that one should "tell the truth about data" (read more here).
Second, the color legend is custom designed and programmed to always show the min/max values of the displayed data and uses all the expected microtypography features (en-dashes in ranges, thousand separators, comma instead of point).

Main Map The main map serves two functions: it is the background for our citi bike stations as well as the spatial queries (with the 'Polygon Draw' tool. We opted for a very simple, low-contrast, greyish map that still contains some color information on green areas and water bodies. If street categories are an important Factor, there is a second basemap that can be activated in the control panel. Last but not least, to give the user some context an interactive inset map as well as a scale bar were integrated.

Having a time slider that goes from 0:00–24:00, because this is what a person would define as a full day, and based on this render plots by hour of day. See the problem? 24:00 is the same as 0:00 of the next day … so how do you filter for this data? Do you even have to include it or do you better limite the time slider to 0:00–23:00? We decided to keep it at 0:00–24:00 and do everything possible to find a solution for our plots. It worked out quite well, except for the mean user age plot. Just set a very short time span, i.e. 3 hours and see what happens. Well, there should always be space for improvement.

Drawing polygons on the map is great to get an area of interest. The problem is only: how could you get rid of them without having to reload the whole map (which would be bad for the user experience)? To solve this, several functions on the server side of our shiny application were implemented. There is a counter for the number of drawn polygons listening for 'draw stop' events, that is set back to 0 as soon as the 'Delete Polygon(s)' button is pressed. Sounds easy, not? But this is just where the real problems start. User drawn content is attached a random uniqe layer id which needs to be known in order to actually delete it. Once again, a function is implementend that gets these ids as soon as a new polygon is drawn and stores them. Now we know how many polygons are visible on the map and by using some javascript (because the drawn shapes are not yet accesible via the leaflet layer manager) we can delete the polygons. Simple task, rather difficult (but still elegant) solution. Unfortunately this is the case with a large number of issues we had to solve. R, leaflet and shiny are great, but only to a certain level, after that, there seems to be only javascript and in some cases html and css (application layout).

User Stories As mentioned in the proposal we built our application according to user stories describing what our user should be able to do with our solution. Evaluating our final product with these shows that all the interactions are covered, except maybe for the 'switching layers on and off', but from a UX perspective it seems to make more sense to always at least show a dot per bike station.

Layout We proposed a two row layout where the first row would feature tabs to switch inbetween controls an statistics. While testing this inital layout we found out, that it is rather confusing for users if the controls just disapear (which makes sense, as these are in the other tab). Therefore we decided to go with a three row layout that always shows every active feature (including controls and statistics) to give the user a nice overview of all the options/outputs. The full layout is of course responsive (although UX on small screens—given the large number of options—is rather bad.

Additional Data We proposed the integration of a heat map showing bike accidents. The reason why we dropped this option is a simple one: we only have start and end station for each bike trip, so the only conclusion one could draw is on the relation of bike stations and accidents. As this would not make too much sense, we just ignored this feature.

Color Scheme To perfectly match the appearance of our application with this website we made some changes to the proposed color schemes.

Clustering By far the most potential lies in the clustering of our bike stations for the different zoom levels. A working solution in terms of data aggregation could be implemented, but not visualized. The used R Package (leaflet.miniCharts) does—by the end of may 2018—not support a method to clear all drawn miniCharts. After countless hours working on this problem, even starting to think about developing it ourselves in javascript, we had to drop this idea. There was just not enough time. Therefore we decided to just make the size of the pie charts scale dependent to partly solve the issue of readabilty.

Performance Wrangling 718'000 bike trips for each user interaction including zoom, pan, change of category or date/time slider(s), takes some time.
Why are we so focused on performance? User experience! The longer one has to wait for something to happen after an interaction (ie change of time slider), the larger is the chance of confusion (why is nothing happening?) and/or frustration (why does it take so long?).

Selecting AOI The user can draw several areas of interest (AOI) and statistics are always shown for the last drawn polygon. We worked on a functionality where the user can click on a formerly drawn AOI which would then trigger the statistics for this particular polygon. This would allow for better comparison inbetween different areas. Unfortunately this was, at least for the time given, over our heads.

Additional Layers As already mentioned, we dropped the idea of an additional layer showing accidents. We still think though, that extra layers could add important information if it comes to finding and interpreting patterns. Possible layers we think might be interesting: Living/working areas, subway lines/stops, bus lines/stops or some sort of indicator for rich/poor neighbourhoods.

Statistics/Visualisations With some more time (and maybe less other modules that also need some attention) we could have implemented many more types of statistics and visualisations. An overview of possible types can be found in the 'Step 3: Data Exploration' section above.