Liam Ball Creative Technology

Finding a ride on Pilgrim

This is the process of a new user signing up as a Pilgrim user and finding a ride.

Splash screen

While the app loads, a splash screen image is displayed

Log in screen

Because the user does not have a Pilgrim account, they select the signup button at the bottom of the screen

Sign up screen

The user is presented with a form where they enter account detail On submitting, the app creates an account with the app using only a client secret as authentication Once the account has been created, the app automatically logs the user in, this time using the username and password and receives an access token to use in later requests The 'register account' server route is the only one that does not require an access token

Find map

This is the 'Find' map, as indicated by the title at the top of the screen. The toggle switch in the top right corner changes between the 'Find' and 'Share' map modes This map shows all current rides by placing a marker on their destination.

Side drawer menu

The user then opens the drawer menu by pressing the 'burger' button in the top left hand corner this displays the user's full name, profile picture (currently blank) and their rating out of 5 stars The menu provides four navigation buttons:    - My Rides:        Shows the user's current rides, both those they have shared and have joined    -History:        Shows past rides    -Settings:        Currently only shows the Pilgrim App Version (v0.1) and a "Log out" button    -Register Vehicle        This is a dynamic button that changes depening on the user's information

       If a user does not have a registered vehicle, it will prompt the user to set one up        Clicking it in this mode will redirect the user to the 'register vehicle' screen flow        This flow uses the CarJam API to get vehicle details from its license plate

       if the user had already registerd a vehicle then it will display "Vehicle details" where the user can review or remove their current vehicle

My Rides

This drawer menu screen shows rides the user has created ("My shared rides") and rides that the user has signed onto as a passenger ("Rides I'm On") Currently, both lists are empty as the user has done neither.

Ride Viewer

The user has selected a map marker on the find map. This screen displays information about the selected ride, in this case a trip from Auckland CBD to Piha beach The user reviews the ride information and decides to close the rideView with the button in the top right, returning them to FindMap

On the next ride selected, the user can contact the driver by calling them directly from the Pilgrim app. The user joins the ride and is taken to the "Set pickup" screen

SetPickup

here the user can select where they would like to be picked up by the driver. as they move their desired pickup the navigation route adapts to find the best route for the driver to their destination via this passenger. This is done via the Google Maps directions API with the user's selected location as a waypoint. After submitting they are returned to the findMap screen

My Rides

To create the Pilgrim mobile app, we chose to use the React Native framework (Reactnativecom. 2018). React Native allows you to write code in JavaScript (Javascriptcom. 2018) that compiles down to native binaries to run on either iOS (Applecom. 2018) or Android (Androidcom. 2018) devices without having to rewrite the entire codebase from scratch.

React Native (Reactnativecom. 2018) also includes a visual component framework for creating user interfaces. The way that a button component communicates with its parent screen has been well created specifically for making user interfaces, instead of general purpose programming. React combines JavaScript (Javascriptcom. 2018) logic and HTML tag (W3schoolscom. 2018) style visual layout, which is useful as both of those are familiar and established methods. It also uses JSX (Reactjsorg. 2018) to add dynamic content into otherwise static HTML.

The Pilgrim app uses Redux (Reduxjsorg. 2018) to manage application state, a library that not only changes how you can share data between components and up the hierarchy, but also can be used to create a much more stable and predictable app. Redux effectively creates a global state that all components can access. However the state cannot be directly modified. Instead, Redux uses a system of actions, action types, and reducers that maintain the predictable nature of the app and allow you to step backwards through the actions sent to establish the cause of a bug.

The Pilgrim backend runs on a NodeJS (Nodejs foundation. 2018) server using an SQLite3 Database (Sqliteorg. 2018) for saving and retrieving records. This server handles requests from the client app and responds with database records, data from third party API’s, or a combination of both. API’s used for Pilgrim include Google Directions (Googlecom. 2018), Google Location Autocomplete (Googlecom. 2018), and CarJam developer API (Carjamconz. 2018). These are used to get directions, get information about a location, verify a NZ Driver’s license validity, and confirm a car has its warrant of fitness. Using the app, the user can choose to either find a ride, or share a ride. To find a ride, the user is presented with a map of their wider location and can see ride destinations as markers on the map. Pressing a ride will show the route that the driver is intending to take. After selecting to join the ride, the user sets their pickup location and this adjusts to navigation route accordingly to include them. Once on a ride, both passenger and driver can contact one another by call or text as their phone number is included in their profile.

A user goes through similar process to create a ride. First, the user selects a destination for their ride by typing in a location name. Pilgrim will provide autocomplete options via the Google Location Autocomplete API (Googlecom. 2018). Next, they set up the departure and return date and time, the amount of seats available, where they will be departing from, and their message of intent for the trip. After confirming these details, the ride is then publicly visible on the find ride map.

The pilgrim codebase is stored in a local Git (Git-scmcom. 2018) repository which manages versions of the app. These are then backed up to GitHub (Githubcom. 2018).

This means that every change committed to the files is tracked, and at any point you can revert to an earlier version of the app. This is good for referencing older code or undoing breaking changes. Using Git creates a local repo, and by pushing it to GitHub the code is stored remotely. This allows collaboration and sharing of the code between developers, but also acts a backup so the code is safe even if the hardware it was made on breaks.

Applecom. 2018. Applecom. [Online]. [28 October 2018]. Available from: https://developer.apple.com/app-store/review/guidelines/

Reactjsorg. (2018). Reactjsorg. Retrieved 28 October, 2018, from https://reactjs.org/

Reactnativecom. (2018). Use React Native. Retrieved 28 October, 2018, from http://www.reactnative.com/

Nodejs foundation. (2018). Nodejs. Retrieved 28 October, 2018, from https://nodejs.org/en/about/

Mediumcom. 2018. Medium. [Online]. [28 October 2018]. Available from: https://medium.com/level-up-web/developer-roadmaps-all-in-one-place-75c0402db0e

laviocopescom. (2018). Flaviocopescom. Retrieved 28 October, 2018, from https://flaviocopes.com/node-history/

Mozillaorg, 1.`. 2018. MDN Web Docs. [Online]. [28 October 2018]. Available from: https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Introductio

Quoracom. 2018. Quoracom. [Online]. [28 October 2018]. Available from: https://www.quora.com/How-does-React-Native-work

Npmjscom. 2018. Npm. [Online]. [28 October 2018]. Available from: https://www.npmjs.com/package/google-maps-react

Reacttrainingcom. 2018. ReactRouterWebsite. [Online]. [28 October 2018]. Available from: https://reacttraining.com/react-router/

Npmjscom. 2018. Npm. [Online]. [28 October 2018]. Available from: https://www.npmjs.com/package/simple-flexbox

Javascriptcom. (2018). Javascriptcom. Retrieved 28 October, 2018, from https://www.javascript.com/

Androidcom. (2018). Android. Retrieved 28 October, 2018, from https://www.android.com/

Applecom. (2018). Applecom. Retrieved 28 October, 2018, from https://developer.apple.com/ios/

W3schoolscom. (2018). W3schoolscom. Retrieved 28 October, 2018, from https://www.w3schools.com/html/

Reactjsorg. (2018). Reactjsorg. Retrieved 28 October, 2018, from https://reactjs.org/docs/introducing-jsx.html

Reduxjsorg. (2018). Reduxjsorg. Retrieved 28 October, 2018, from https://redux.js.org/

Sqliteorg. (2018). Sqliteorg. Retrieved 28 October, 2018, from https://www.sqlite.org/index.html

Googlecom. (2018). Google Developers. Retrieved 28 October, 2018, from https://developers.google.com/maps/documentation/directions/start

Googlecom. (2018). Google Developers. Retrieved 28 October, 2018, from https://developers.google.com/places/web-service/autocomplete

Carjamconz. (2018). Carjamconz. Retrieved 28 October, 2018, from https://dev.carjam.co.nz/

Git-scmcom. (2018). Git-scmcom. Retrieved 28 October, 2018, from https://git-scm.com/

Google Maps 

The core feature of our app is the map - it facilitates all ride creation and finding by representing destinations visually. The map needs to store massive amounts of location information all the way from country scale to individual roads. Obviously creating a solution to this ourselves would be an impossible endeavor. The two main map services we could user are Apple Maps [2] and Google Maps [1]. Apple maps is the native mapping system on iOS devices and is default for the MapView component we’re using. The component can be set to use Google Maps instead, and as it provides more customization for developers we decided to use this option. Google maps allows you to use custom map styles [3], allowing you to tweak almost every visual aspect of a map screen. Using the Google Maps map view is also a free and unlimited service.

GitHub

As the codebase grew and changes were continually being made, it became apparent that keeping just one version of the code would not be viable. Storing the codebase as a single local file meant that breaking changes could literally stop development until (and if) I could ctrl+z or fix the app until it worked again. To make sure this didn’t happen, I used Git [4] and GitHub [5] as a version manager and remote code repository. This means that every change committed to the files is tracked, and at any point you can revert to an earlier version of the app. This is good for referencing older code or undoing breaking changes. Using Git creates a local repo, and by pushing it to GitHub the code is stored remotely. This allows collaboration and sharing of the code between developers, but also acts a backup so the code is safe even if my hardware breaks.

Redux

The React component system is a hierarchy of parent and child components, with data being fed down the line. This works well with a simple app but as Pilgrim became more complex I found that a component might need to send data back to a grand or great grandparent component. To do this, I would thread a callback function through multiple different components before it reached the intended child. This created a confusing mess of similarly named callbacks floating around in components, and I felt that I had reached critical mass and couldn’t continue building Pilgrim like this. This is when I decided to learn Redux, a library that not only changes how you can share data between components and up the hierarchy, but also can be used to create a much more stable and predictable app.

Redux effectively creates a global state that all components can access. However the state cannot be directly modified. Instead, Redux uses a system of actions, action types, and reducers that maintain the predictable nature of the app and allow you to step backwards through the actions sent to establish the cause of a bug.

Third Party API’s:

Pilgrim as a service needs information that we can’t generate or retrieve ourselves. This is where we use third party APIs [7] - a programmatically network interface that allows the pilgrim server to get information necessary to facilitate rides.

CarJam [8]

As our service involves connecting passengers with drivers, we need to know that drivers are legally allowed to drive before we facilitate them picking someone up. For this, a user has to verify their drivers license before they can share a ride. As we don’t have access to New Zealand driver’s licensing records, we will use the CarJam API. CarJam uses records from the NZTA and through this API we can confirm that a user holds a valid full NZ driver’s license.

To start a ride a user also has to register a vehicle by entering the car’s license plate. Through the CarJam API we can retrieve information about the car like its make, model, year, and color. This is useful to give to a passenger being picked up as they can look for a “Red VW Golf”. We can also verify that the car passed its warrant of fitness, another safety measure to ensure the passenger is safe and we are fulfilling our legal and moral obligation as a facilitator.

Google Maps API [1] :

We are using the Google Maps API service to get information about locations, and to retrieve navigation routes between two coordinates with waypoints in between. This would take a large amount of processing power, and all of this work is offloaded to Google’s server. We also use the Google Maps autocomplete API to help the user type in and find locations. When creating a ride, the user can type into a search bar to select their destination. After each character is typed, a request containing the search text is sent to the server, which then sends it to the Google Maps Autocomplete API route. The result is google’s best guess as to what the user was searching for.These results are also biased to New Zealand, rather than sorting global results equally. 

[8] https://dev.carjam.co.nz/

References:

[1]https://cloud.google.com/maps-platform/

[2]https://www.apple.com/nz/ios/maps/

[3]https://mapstyle.withgoogle.com/

[4]https://git-scm.com/

[5] https://github.com/

[6]https://redux.js.org/

For this project, our final outcome is effectively a prototype mobile application. This will take a lot of time and energy, but when we display this in open studio it could fall flat without a solid supporting exhibit. We have also decided to focus on not just creating an app, but creating a community and movement that is facilitated by Pilgrim.

We want to create Pilgrim as a platform to connect people who want to get out there already, and make those connections and trips easier. We also want it to strengthen and enhance the community it was made for, and not come from outside but emerge from within this community of passionate individuals. To include our market in the development of this app and to create a sense of shared ownership, we have created a closed Facebook group of friends to get feedback on proposed features and changes to the platform, as well as share events and news inline with these values. Currently there are 138 members in the group, and it is steadily growing.

One idea we had early on was to host a beach cleanup event. One of Pilgrim’s core value is environmental sustainability. By carpooling, we aim to reduce the amount of cars on the road and therefore the pollution created, and the places in nature that these trips are to also need to be protected. This even also acts as real world customer research as in the event page we asked everyone to work together to share rides. On the day, we had 17 attendees who came in 4 cars.

We contacted Sustainable Coastlines and they supplied us with rubbish bags, gloves, and a needle box to deal with the rubbish found on the beach.

We also reached out to Mexicali Fresh and Coffee Supreme to see if they would be interested in being involved in the project. Both responded to us and helped the cleanup crew with lunch and coffee for free.

For open studio, we wanted to make a lasting impression on people who visited our installation. To do this, we decided to create surf wax - a thematically fitting giveaway that can actually be used, either for surfing or as an sexwax style air freshener.  For the packaging, I created a lasercut stamp design that incorporated Pilgrim’s logo, and more personal location fingerprints. By using the real map contour lines of famous New Zealand surf spots, people could choose their favorite.

I wanted to create a way to create packaging that embodied the ideas behind the product - a surf wax that wants to be associated with travel and adventure, and the fact that the wax is handmade. I thought of making a stamp because it could give an analog and unique feel to each box, and also to reinforce the travel theme by making them resemble passport stamps. Pilgrim is an existing brand concept, and the typeface used for type is the same to keep branding consistent.

One of the core functions of Pilgrim is to allow users to create a ‘ride’ - a planned trip to a destination from a start location, at a certain date. From this information, other users can ask to join this ride, and the driver can pick them up. I have created a (unstyled) prototype of this flow of screens, where a user sets up the ride by entering different pieces of information. The app keeps track of all these different properties, then collects them into one object and sends it to the server when the user confirms.  This information is then saved in the database, and can be sent to a client who wants to see all the rides available. 

The first screen of this process is a reused screen from my last blog post.

This screen has been re-purposed to set a location that the user wants to travel two. As this is a simple prototype, there are only two different options. On selecting either location, the app saves that choice and then changes the screen component being rendered - effectively ‘turning the page’.

Next, the user is prompted to set the departure time of the ride. This screen uses a native ‘Time Picker’ component that is built into the iPhone operating system. Components like this are useful because not only does it save time as I don’t have to spend a week trying to make some 3D time selection spinner, but people are already familiar with how to operate it. 

After confirming the time that they plan to leave for their trip, the user scrolls the map to set the location that they will leave from. This establishes the trip, start to finish location. This will also help potential carpoolers to see if they are close enough to the driver’s route to warrant asking for a lift.

The map screen is set to automatically center on the user’s current location, and from there the user can drag the map to fine tune the start location. The exact coordinates are based on the center of the map, so a floating circle acts as a target to show a user where around them the coordinates displayed correspond to.  The final step of this flow is to review and confirm the details entered. A summary of the ride as interpreted by the app is displayed for the user.

Upon submitting the ride, the user is taken to the ‘rideView’ screen, what another user wanting to join the ride would see.

To build Pilgrim, we decided to use the React Native framework [1]. RN allows you to write code in JavaScript that compiles down to native binaries to run on either iOS or Android devices. 

Both Leo and I are already familiar with the syntax of JavaScript, so it will be easier to begin development

It also means that we can code one app that can compile to run on both android and iOS devices, without having to rewrite the entire codebase from scratch. This is

Also includes good visual component framework for creating user interfaces. The way that a button component communicates with its parent screen has been well created specifically for applications, instead of general purpose programming.

React combines JavaScript logic and HTML tag style visual layout, which is useful as both of those are familiar and established methods. It also uses JSX to add dynamic content into otherwise static HTML.

A React Native application is built of smaller components that perform tasks and render screens. Because an app is not static - it has to react and update depending on inputs, there is a constant render loop. Each component has a lifecycle [2] with built in methods that trigger depending on where in this cycle the component is.

React Native supports modules which can be installed through Node Package Manager (NPM). This allows you to incorporate other people’s code to speed up development.

A module core to Pilgrim is ‘react-native-maps’ [3], which provides a functions and components that interact with the device native maps. Pilgrim will be built around a central map screen, so this module was the first place I started after setting up a simple react native map.

So far I had a simple map display with built in dragging, zooming and rotating based on touch. I also added a simple button component that had two buttons for locations. Each button is linked to a set of coordinates in the component’s state, and when touched it triggers a function that sends the respective coordinates to the map’s animateToRegion() method. This shifts the map view to the location.

The next development on this was to save the coordinates in the database, set up an API route in the server, and when the map component loads it sends a request to the server. The server responds with a JSON object with longitude and latitude which the component then saves in its state. After this information is loaded, the map component is allowed to load and it can access that coordinate data from the state.  In practice, all important data will be stored on server to allow for real time updates of location and other data. If the data was hard-coded into the app, the only way to update it would be to get the user to install an app update through the app store.  The app is effectively an empty display that visualizes information stored in the database, and then can modify and send new data back.

A big step was getting a marker to animate around the map. The icon’s position is based on longitude and latitude, not just screen position, so it can accurately represent a real world location.  Its coordinate information is also retrieved from the server over a network, and on each request the server adds a random number to that last coordinates and sends them. This roughly simulates movement of a user.

References

[1]https://facebook.github.io/react-native/

[2]https://code.likeagirl.io/understanding-react-component-life-cycle-49bf4b8674de

A principle design necessity for a mobile app that can connect users is the ability for clients (instances of the app running on different phones) to be able to communicate and share data.

If you post a ride, other clients need to be aware of that in order for the app to be used. To do this, we will use a central hub that saves all this information, and then sends it to individual clients when asked. This is called a database, and before starting development on Pilgrim I had a very limited understanding on how complex designing one could be. Initially it seemed very simple to just save data somewhere and then send it back, but even during planning how the app would work it became apparent that it would be more complex than I had thought.

With Pilgrim, the database stores lots of different types of data in different categories - each ride, user profile, route, and destination needs to be saved, and saved separately so that they can be retrieved specifically.

Inside the database, these different types of record are saved on different ‘tables’. Similar to an excel spreadsheet, a database is made up of rows of records and columns of properties. [1]

For example, this is a section of the Location table, which saves information on different locations so that a client can load its destination. Each row represents a different location record. In this instance, properties like latitude and longitude are saved to define the location on earth, the name to display to the user, and the delta lat and lon to show the zoom level of the location (A city has a larger delta than an individual house). Each record also has a unique identifier (ID). This is used to reference a specific location, since, as shown above, two different locations can have similar or the same name. ID’s are the only reliable way to know that you’re getting the record you wanted. Generating collision safe IDs is crucial for a useful database, so I did some research into good ways to make IDs when saving new records. I found an article [2] that describes a simple way to create safe IDs, and this method is what I have used in the server to safely save records to the database.

It starts by taking a pseudorandom number from an internal process of the machine it’s running on. Computers have native methods to generate these numbers either through hundreds of complex algorithms or through measuring natural phenomena like the heat of some component. Pseudorandom means that the number is not truly random, but is effectively random and can be used for applications. The pseudorandom number is returned as a string of bytes, which are then cryptographically hashed. A hashing function takes any amount of data and returns a same length number that is unique to every byte of input. Hashes are often used to ensure that software or information has not been tampered with, as even changing a single bit of GB of data will result in a different hash. Using this on the random number adds another level of collision security. Included in the hash is the value of an incrementing counter that increases by one every time a hash is generated. This ensures that no two random numbers can be the same (even though statistically wildly improbable) before they are hashed using the sha256 algorithm [3].

This ensures that each record can be individually selected, but individual records aren’t that useful. If you have the userID of a user and you want to load all their rides, you need to be able to link two pieces of data stored in separate tables. This is where relational database design comes in. The concept is to store the unique ID of a row as an attribute of another row. This links the tables in a database, and these relationships can be show visually by an Entity Relationship Diagram (ERD) [4].

This is the Pilgrim database ERD, showing the six different tables and their relationship to each other. [6] For example, when a user creates a ride, you need to store information like where the ride is going, but you can’t store it in the user table because a user may have many rides, and you can’t dynamically expand the amount of columns in a table. What you can do is have a ride entity in a ride table, and like it to the user by referencing the owner’s unique userId. This is shown by the arrow between the user’s ID field (marked as PK - primary key) and the ride’s ownerId (marked as FK - foreign key). ERD’s also have specific symbols on these connections to show more information about how they relate.

A user may have five rides that they’ve created, or they may have not made any yet. So, the relationship from the user to the ride would be ‘Zero or many’. A ride may only have one owner, and for a ride to exist it must have been created by a user, so from a ride to user is ‘One and only one’.

As the database grew in size and complexity, referring to this diagram, updating it is the database changed, and becoming familiar with these ERD notations helped me to understand what I was building and how each moving part worked inside the database.

Our database is an SQLite3 database, which is one I have used before briefly and is perfect for getting started fast. Unlike database systems like Postgres which require you to create another profile on your PC and uses its own commercial grade network postmaster, SQLite3 simply stores and retrieves information. The Command Line Interface (CLI) is easy to install and was a good choice for the Pilgrim proof of concept.[7] The language used to interact with databases is called SQL (Structured Query Language) is common across most databases, so when we need to migrate the data and database structure to a remote database, we can recreate it exactly using the saved SQL.

[1]http://www.agiledata.org/essays/relationalDatabases.html

[2]http://antirez.com/news/99

[3]https://www.movable-type.co.uk/scripts/sha256.html

[4]https://www.youtube.com/watch?v=QpdhBUYk7Kk&vl=en

[5]https://www.lucidchart.com/pages/ER-diagram-symbols-and-meaning

[6]https://www.bridging-the-gap.com/erd-entity-relationship-diagram/

[1] https://liamcreativetech.tumblr.com/post/175971823711/interactive-technology-and-systems-at-the-auckland

[2] https://liamcreativetech.tumblr.com/post/179168529151/demonstration-of-claw-a-multifunctional-handheld

[3] https://liamcreativetech.tumblr.com/post/179169033366/the-north-sense

[4] https://liamcreativetech.tumblr.com/post/179195824551/tabletop-interactive-technology

[5] https://liamcreativetech.tumblr.com/post/179199468931/traveler-ultimate-distraction-free-writing-tool

[6] https://liamcreativetech.tumblr.com/post/179199647856/auckland-museum-ar-installations

[7] https://liamcreativetech.tumblr.com/post/179197043906/crowd-source-rescue

[8] https://liamcreativetech.tumblr.com/post/179197433861/tangible-media-by-mit

[9] https://liamcreativetech.tumblr.com/post/179197964691/why-people-keep-rear-ending-self-driving-cars

[10] https://liamcreativetech.tumblr.com/post/179198814411/researchers-create-virtual-smells-by-electrocuting

[11] https://liamcreativetech.tumblr.com/post/179199077346/this-autonomous-spray-painting-drone-is-a

As touched upon in my other blog posts, there is an emerging trend of creating devices and technologies that allow or force us to do less. As technology became more and more complex, the devices we carry on us daily have become able to do a lot more. This seems like a positive, but quickly the possibilities became obligations. A phone in your pocket that can do anything insists that you do as much as you can. People feel enslaved by the technology designed to make their lives simpler and easier.  Two good examples of this revolution against the smartphone are light phone 2, and Punkt’s MP02.

Both of these devices are trying to find the perfect balance between ability and simplicity. The light phone’s ethos centers around smart phones feeling ‘heavy’. That the tasks you do all the time are as difficult to do as tasks that you barely ever use, and maybe shouldn’t even be included.  They are both designed with battery life and versatility in mind. Both use matte e-paper/e-ink displays that save battery life to the point of going up to a week without needing to be charged, and also provides great visibility outside and in direct sunlight. 

At the same time, they use 4G data, have bluetooth and GPS - all tenets of the modern ‘heavy’ phone. The difference isn’t the technology, it’s the philosophy.  You can navigate on the light phone 2, but it’s not the same experience as doing it on an iPhone. By selecting one of a handful of your most common destination you can navigate turn by turn. The simplistic display and output streamlines the experience - there aren’t 100 different view options because you don’t really need them.  Developers have made tech consumers into control freaks, people who must have the option to change any part of the experience and have 20 different options on how to do it. This is a symptom of technology’s inherently abstract nature; there is no predefined way of presenting information, so as many variations and options as possible are included. This was impressive when this technology was emerging, it was a brag and a showcase. But now, as the technology and consumer has matured, there is a new understanding of the user experience and how it interacts with a user’s real life. 

Sometimes, less is more. 

https://www.indiegogo.com/projects/light-phone-2#/

The FreeWrite Traveller is a writing tool that is designed to allow writers type without the distractions of using a laptop or other smart device. it markets itself as a modern typewriter, a change of pace from the tech world’s obsession of creating smarter and smarted devices. 

This article is about how the majority of self driving car collisions are caused by human drivers rear-ending the self driving cars.  There are currently around 7 companies testing AI controlled cars on public roads in four states in the US. The promise of AI on the roads is to reduce the amount of car related deaths (currently around 40,000 a year) and to automate road freight movement.  The AI is equipped with a multitude of sensors and can monitor what’s happening around it in 360 degrees. These inputs are then given to a machine learning car that makes decisions based on what it identifies, and learns from those decisions.

because of this, the best way to make safe autonomous vehicles is to test and train them on public roads with other drivers. The more intense and difficult the road terrain is, the faster the cars learn. 

This is a video posted in the google+ community, and it shows a prototype of a surface that allows 3D displays and people to interact with objects without being there. The display is comprised of many extendable cubes and raise and lower dynamically.  The example videos show a couple of different applications for this technology. Graphs are shown in 3D, with colour visualization projected on top.  Over video, a user sees a ball on the display. By moving his hands around remotely, the display reacts and mirrors his hands. Through this method the ball can be rolled around and picked up.

Crowd Source Rescue is a crowed sourced platform for helping victims of natural disasters. When a disaster happens, emergency services are often overloaded and are unable to respond to every call out they receive. Social media platforms have become a place that people turn to to ask for help from those around them. These platforms facilitate conversations and connections in every other aspect of their lives so when they need immediate help, people use social media as well. The problem is that many social media sites and apps are not optimally designed for this purpose. When someone asks for help, it is not prioritized above other posts, ones of less importance regarding life and death or personal safety. Crowd Source Rescuing have created a mobile and web platform that aggregates these requests for help into one place, where civilian volunteers can see these requests on a map. The requests are also broken down into different categories. By using GPS technology, a request is plotted on the map along with contact details of the person in need.