This post is about utilizing a Raspberry Pi with a touchscreen to build a ±80€ productivity dashboard that provides relevant information right on your desk by the blink of an eye.
table of contents
The Raspberry Pi Productivity Dashboard is a small touchscreen computer that sits on top of your desk providing you with relevant information and productivity tools while keeping you main computer screen free of any destracting widgets or unnecessary browser tabs.
The goal is to build a small device that will boot up automatically whenever you plug in the power source and load a clutter free website which you can design according to your own needs.
The dashboard consists of the two main parts: physical components and the dashboard website (front- and backend). This tutorial will show you how to set up all the needed physical components, configure all relevant settings and show you the main concepts of my personal dashboard and its components. Since the screen real estate is pretty low and everybody is using different services to boost up his or her own productivity (and I am by no means a web developer), I will not provide source code to my dashboard (at least at this point of time). However, I will describe the interaction of different components, how you can utilize your smartphone, web services, databases and APIs in order to gather all relevant information for your personal productivity dashboard.
This is not a project where I allocate my personal ressources rather than an ongoing task for me. Therefor this article will be updated infrequently with my latest additions of features and services.
The main components of the dashboard are the Raspberry Pi and the TFT touchscreen that sits right on the GPIO pins. Both fit well in one of these standard acrylic cases when the top of the case is being replaced with the screen during assembly. You can also still use the standard heat sinks (cooling pieces that are glued on top of the processing units). Here is a full list of the components that I use for my two variants of the dashboard (one being powered with the Raspberry Pi 2 Model B and one with the Raspberry Pi 3):
- Raspberry Pi (current version 3 Model B, previous version 2 Model B without WLAN an Bluetooth)
- TFT Touchscreen Display (incl. Case) 480 x 320 pixel resolution
- MicroSD Card (min. 8GB recommended)
- micro USB power supply
- USB WIFI Dongle (only needed for Raspberry Pi 2, a WIFI Module is already included on the Raspberry Pi 3)
- acrylic stand (optional)
- micro push buttons (optional)
- jumper cables (optional)
- pin headers (optional)
- drilling and cutting tools, soldering components, isolating tape (optional)
- USB connected Keyboard and mouse for configuration or basic SSH knowledge to SSH into your Raspberry Pi to remote control it.
Assemble the case components as shown in the description that where shipped along with the case. Mace sure to leave the top off and replace it with the screen. The screen is attached to the Raspberry Pi by sticking it on the GPIO pins that also hold the screen in place – no screws etc. needed.
Next up is the operating system and all the settings in the dashboard that will be described in detail in the next section.
operating system & system settings
The Rasberry Pi is running Raspbian as ist operating system. Since the small touchscreens will be shipped with a minidisc that stores an image of raspbian which natively supports the touchscreen and there is hardly any other solution in getting the screens to work properly with another image, I recommend installing the image on that is shipped on the disk.
The first step we need to make is the standard update & upgrade procedure that you are most likely familiar with, if you are using your Raspberry Pi already. Hook up the Screen to the Raspberry, insert the micro SD card with the Noobs image installed, plugin a USB corded keyboard and mouse and plugin the micro USB power source.
The Raspberry will boot and you get the chance to configure the basic operating system settings. After that you will be taken to the either the command line (where you type “startx” to get to the GUI of the operating system) or you will be taken directly to the graphical user interface of Noobs.
At first the file system needs to be expanded, in order to use the full space capacity of the microSD card and avoid the often occurring black screen problem:
Open the terminal by clicking on Start > Utilities > Terminal. A blank terminal window will open, where you can type the following command to enter the Raspberry Pi Config menu:
Choose “Expand File System” and follow the intuitive steps on the screen.
As a next step the internet connection needs to be configured in order to download ressources from webservers and later also display the dashbiard’s website. If you are running on a Raspberry Pi 2 or earlier, you need to either plugin a USB Wifi dongle or an Ethernet cable.
Head over to the top right corner of the screen with the Wifi symbol, click on it, choose your preferred network and enter the password credentials to establish a connection.
Next, head back to a blank terminal window where you can start the update & upgrade procedure.
sudo apt-get update
followed by hitting enter and then running
sudo apt-get upgrade
both commands will take a while to update all the components (depending on when the image on the micro disc was built).
If you are not running the dashboard on a small TFT screen that is attached to the Pi but on a screen connected via HDMI, you will notice the black border around the displayed content on the screen. Head over to the “run”-command line and enter
in order to run the text editor with superadmin rights. This is necessary for saving the file that needs not be touched in the next step.
Navigate to the boot folder and uncomment the last line of the config.txt file so that
will not be commented out. Save the file and close the text editor. The changes will be present after the next reboot.
While displaying the dashboard, the interruption of the screensaver will become annoying. Switch off the screensaver by opening the autostart file with the following command in the terminal window:
sudo nano /etc/xdg/lxsession/LXDE-pi/autostart
add the following lines at the end of the file:
xset s off # don't activate screensaver xset -dpms # disable DPMS (Energy Star) features. xset s noblank # don't blank the video device
After finishing the basic setups of the operating system, it is time to install the best webbrowser available for the Raspbian OS.
Even though Raspbian comes preinstalled with the Empiphany browser, I had some trouble from time to time with various aspects of this bootstrapped browser. Therefor I recommend installing the latest version of the Chromium browser.
Once again, head over to the terminal window and run the following command to install the Chromium browser on your Raspberry:
sudo apt-get install chromium-browser
In order to run chromium in fullscreen mode (aka Kiosk Mode) after the boot up procedure, we need to add some lines to the autostart file. Open the terminal window and open the file in the nano text editor with the following command:
sudo nano /etc/xdg/lxsession/LXDE-pi/autostart
At the end of the file the following two lines need to be added so that an incognito window of the browser will be opened on start up in full screen (aka „kiosk“) mode. We choose the incognito window here to prevent unwanted login and error messages to show up:
@unclutter -idle 1
@chromium-browser --incognito --kiosk https://www.domain.com
In case you are using an htaccess and htpasswd file to protext your site with simple username-password credentials, you need to add those credentials to the last line and modify it like shown here:
@chromium-browser --incognito --kiosk https://username:email@example.com
shutdown hardware button
The first thing I was wondering about when using the Raspberry Pi for the first time was the missing power off button. If you are running an operating system like linux on it, you most likely want to properly shut down your computer in order not to risk destroying any of your system. I was searching around the web to find a hardware solution which seemed to be almost impossible to find at a reasonable price. So I decided to just ad a simple push button to the GPIO pins that runs a shutdown script that I found at instructables.com.
At first, you need to get the above mentions little push buttons, wire them up with jumper cables using a little bit of soldering and isolation tape. Measure the diameter of the button, drill a whole of that size in the case (watch for a location that provides enough space behind the case) and attach the button to the case.
After the button was connected to the case, you need to connect it to the GPIO pins that remain unused after attaching the screen, e.g. pin 32. Make sure to get jumper cables with small plastic heads that will fit under the screen. The one I chose and linked above work just fine. Attache one cable to physical GPIO pin 32 and the other to physical ground pin 30 (check the layout here under the „physical layout“ section).
On your Raspberry Pi create a new folder fr your scripts. I chose the path „/home/pi/myUserName“.
Open the text editor paste this code and save the file as „button.py“:
#!/usr/bin/python from time import sleep import RPi.GPIO as GPIO GPIO.setmode(GPIO.BOARD) Import os button1=32 GPIO.setup(button1,GPIO.IN,pull_up_down=GPIO.PUD_UP) while(1): if GPIO.input(button1)==0: os.system('halt -h') sleep(1)
This script will shut down your system properly („halt -h“) when the button was pressed once. If you choose a different pin to connect the button to, change the „32“ in the script to whatever pin you are using on your Raspi by referring to the numbering layout provided under the section „physical numbering“ at raspberrypi.org.
In the same folder you now need to safe a bash script that pulls in the python script, name it „button.sh“:
#!/bin/sh cd / cd home/pi/myUserName sudo python buttons.py cd /
To make sure that the bash file will by loaded on startup so that after each re-/boot your power-off button is functioning, a cron job needs to be added. In the terminal enter:
sudo crontab -e
Then add the following line at the end of the file to configure the job (make sure to use the path where your stored the previously created python and bash file):
@reboot sh /home/pi/myUserName/button.sh
That’s it! You now have a functioning power off button, that will properly shut down your Raspberry Pi.
restart / reboot hardware button
You can also add a simple reboot button that restarts your Raspberry Pi wth a click of a physical button. This is not needed at all for the dashboard, since I completely unplug it from the power source and store it in my desk drawer whenever I am not using it. In case you are mounting your Raspy behind a big screen or in a location that is hard to reach to reconnect the power cord in order to boot the system, you might want to simply add this hardware button.
The Raspberry Pi comes with a P6 header to do this job without the need of any coding. You simply need to solder two pins to these two connectors, wire them up with the two jumper cables and a button. Every time you connect the two contacts by pressing the button, the Raspberry Pi gets rebooted.
In the picture below you can see the two pins I soldered to the board that will hold the two female jumper cables which are soldered to the physical push button:
Now that the hardware is set up, let’s get into the software part. Before we start, I want to point out a few general software architecture preconditions which constitute the foundation of all upcoming services and KPIs.
database & API endpoints
The dashboard is a single website that is being displayed on the Raspberry’s screen. It is hosted on a regular web hosting service – nothing special here. Bundled with the web services comes a MariaDB database (MySQL or the like would work just the same for this project).
The idea is use API endpoints to store all relevant information in the database that would get lost otherwise. On the other hand, I need API endpoints to retrieve the data from the database and from web services that provide proper APIs which allocate exactly the data I need without the need of storing (e.g. transportation information).
This allows me to switch the services that I use in the future without needing to recode everything. For example: If I want to switch from Trello as my primary to-do-list to let’s say the rindle app, I can easily do so. All I need is adjusting the code of the API endpoint that stores the data to the database. All the scripts retrieving and working with the data will stay the same.
This leads me to the following technical architecture:
location based information
Regarding the displayed dashboard itself, we first need to consider where it is being used. I have a setup of the dashboard on both my personal and my office desk. Therefore, the displayed information varies based on my current location. I wanted to only work on one code base thus it is relevant for me to know my current location for most of the services (e.g. travel/commute information, accomplished tasks).
Since my smartphone is the best digital internet connected device I carry along with my most of the time, its location makes up for a good indicator of my personal whereabouts. I set up a table in my database that gets updated every time I enter a specific geo fence. Currently I have two geo fences, one for my home area and one for my office. The update process is triggered by an IFTTT applet that runs upon entering the area and then calls an API endpoint with the „maker channel“ to update the timestamp when I have last entered the location. I chose the update process rather than an appending logging system because I currently don’t need to know how often and when I have entered the area, I just need to know, which area has been entered last, reveling my current location.
The location update process of the database works as shown in the graphic below:
clock, date, calendar week, week day
The pomodoro technique is a time management method that helps you keep focusing on a single task at the time. Using intervals of 25 minutes where you are committing yourself to that one task helps me to avoid inefficient multitasking. I usually start my day by checking my Trello To-Dos, bringing them in order and then start the pomodoro timer to get shit done. Here are the four simple steps of the pomodoro technique:
- choose the task you want to focus on
- start the pomodoro time (25 minutes)
- work on that single task exclusively until the time is up
- take a short break (max 5 minutes) and repeat the steps again from the beginning
After you have finished four pomodori, you are traditionally allowed to reward yourself with a longer break. Since a 25 minute pomodoro combined with a 5-minute break sums up to a solid half hour, it is easy to preschedule your whole day with pomodoro intervals.
On my dashboard the timer is displayed with big numerals as well as a large status bar on the top of the screen. The status bar starts green, turns orange when only 5 minutes are left and finally warns me with a red color during the last 3 remaining minutes. When the timer is finished the whole bar turns blue with an animation that catches my attention so that I always know when to pick up a new pomodoro timer.
See the video below for a 1-minute time laps version of the timer including the color indicator of the progress bar:
Also check out the extraction of the code I am using on my dashboard at JSFiddle:
In case you are searching for a quick solution to get started with the pomodoro technique you can either use a kitchen alarm clock, your phone’s timer or tomightly, which is my favorite MacOS and Windows friendly pomodoro timer (incl. break management) that sits all-time-visible right in your taskbar.
RescueTime productivity score
Having a single number or a percentage that tells me how productive I am, was the main idea of the productivity dashboard. Knowing that I can be more productive for the rest of the day than you have been the pervious hours of the day, challenges me to accomplish this goal. But how can you determine how productive you are?
This is where Rescuetime enters the stage: Rescuetime is a small software that you install on your computers (Windows and/or Mac) and your mobile devices (Android only). It keeps track of the programs/apps you use (have actively open) and logs the amount of time you spend in each of these programs. The browser extension even tracks the domains (or even URLs) that you are visiting (yeah, you can turn off safe browsing and adult sites, no worries :D). Rescuetime than categorizes each activity to be either very unproductive / unproductive / neutral / productive / very productive. You can always edit the productivity level of each program or website (e.g. if you are a social media manager you might not want facebook to show up as very unproductive).
The mobile app will also let you add offline activities. Upon turning to the paid version, you can also add offline activities in the online dashboard and you will additionally be prompted with a popup window on your computer that asks you to add offline time when you were away from your keyboard for a certain amount of time.
Based on the amount of time you spend in each productivity category an overall productivity score will be calculated for all activities of the current day.
The amount of time you spend in each productivity category is available through the Rescuetime API and will be updated frequently. All you have to do is calculating the productivity score out of the percentages for each productivity category as shown in the example below: time spent in each productivity level * (productivity level score value / time spent in total). Keep in mind that Rescuetime does not round to the next integer but rather floors the score.
|productivity level||productivity level score value||time spent||score calculation|
|very productive||100||20||20*(100/100) = 20|
|productive||75||10||10*(75/100) = 7.5|
|neutral||50||50||50*(50/100) = 25|
|unproductive||25||10||10*(25/100) = 2.5|
|very unproductive||0||10||10*(0/100) = 0|
|Σ 100||Σ 55|
Now we have a productivity score that we can try to keep on a high level or even steadily increase during the day. But to be honest, this gets really boring on the one hand and on the other hand it will not leverage the full potential. It is like driving in your car for ours and only checking the average liters of gas you burn per 100km (or mileage you can drive per gallon). On the first kilometers, you will see the figures change a lot based on your driving behavior but after a couple hours of driving you will not even notice the impact of a small drag race at the next red traffic sign any more.
So how about comparing the overall daily score with my recent productivity level? Luckily in addition to the daily productivity score the API also provides a productivity score for the last 30 minutes. Surprisingly this API endpoint is not well documented, but I found out about it after searching around the API knowledge base forum and even asked the support for it. Use this API endpoint:
Perfect! Now The dashboard displays the current productivity score based on the last 30 minutes that I try to keep above the daily productivity score to always ensure that I will increase my productivity and stay on a very productive level. The color indicators also tell me the percentage I have spent in each category and it indicates the productivity color of my current productivity (which is also provided via the API). The data will be updated every minute and will be requested directly via the Rescuetime API as shown below:
In case you would also like see your current productivity score (of the last 30min) if you are on the go with your MacBook, I highly recommend checking out bitbar. It is a tiny app that makes displaying KPI right within your status bar very easy. I wrote a little php-script that fetches your RescueTime productivity scores and displays them in your status bar. The values will be refreshed every minute automatically.
In the Trello section the finished tasks of the day are being displayed. I am using two main boards that I track: One for my work tasks in the office and one for my private tasks. They are structured in different lists but they all share a „done“ list at the end. This is where all the cards will be moved to whenever a task is completely finished:
Whenever a task is moved to the „done“ list, a IFTTT applet is fired to call my API endpoint to log a timestamp and the Trello board in my database. Consequently, I can query that database for the amount of tasks I have completed on my current location and the overall amount of tasks that I have finished today already. Constantly trying to increase the number of today’s finished tasks keeps me motivated.
Usually private tasks take a lot less time than work tasks. By only displaying the amount of tasks completed at the current location I am staying at („work board“ when in the office, „private board“ when at home), I avoid cheating at myself.
The schematic workflow looks like the one displayed below:
For my personal purposes, Trello is currently the best app to choose for well structured to-do lists with external integrations and useful features. If you are searching for more ways on how to analyze your Trello-based data like „burndown-charts“ (how many cards do you have to finish working on in order to get everything done in time?) , „card velocity“ (at what speed are you working on your cards) and more detailed insights based on your labels, check out Corrello – an app that you can directly power-up from the Trello integrations.
However, for your own dashboard you can also have a look at the following to-do list tools:
transportation & health
When is the best time to leave the office in order to not miss the bus by seconds and wait for the next subway for hours? Should I take the bike or will I get caught in the rain, when I leave the office by now? These questions will be answered on the transportation panel with the information and APIs described in the following paragraphs.
You might wonder what the current weather has to do with transportation. Do you like to walk in the rain or ride the bike during a snow storm? Me neither!
The weather indicator displays the worst weather condition within the next 45-minute time slot. This is exactly the amount of time I need to get myself ready to leave the house and either go to work or return back home. If the weather conditions are good, I take the bike or walk. Thus, it helps me decide, whether I am walking to work/back home by foot or use a bike or better take the public transport/ a car if it is raining/snowing.
I know, I could take a look out of the window but believe me, I got hit by heavy rain during my walk back home once too often, so this weather indicator is really helpful.
The most reliable weather forecast (at least for my currently used locations in Hamburg, Germany) are provided by DarkSky.net (formerly forecast.io). Their API can return daily, hourly and even minutely weather forecast data. I take the worst condition (temperature and weather) for the next 45 minutes and display it directly on the dashboard as shown in this workflow:
A very detailed set of weather icons that work perfectly together with a Bootstrap based website are provided by Erik Flowers over on Github.
Netatmo air quality
Do you know when the amount of CO2 in your room is hitting a too high level? There are several air quality sensors out there on the market already, however most of them are pretty useless unless you constantly have an eye on their build-in display. Other devices – like the Netatmo Weather Station I am using – are syncing their data over the web to a database. The data can be visualized in a smartphone app or their online dashboard. The reason I chose Netatmo for measuring my room temperature, noise level, air quality (just CO2 level), humidity and air pressure, is the simple fact, that I don’t want to check an app all the time but rather use their detailed and well documented API (inkl. SDKs and Source Code Examples in several languages) to implement the data in my dashboard.
In the latest version of my Raspberry Pi dashboard I am fetching the room’s temperature and air quality data and display it on my dashboard. The air quality value serves as the metric to highlight the weather panel on my main tab with a color indicator so that I can directly see whether it is time to open my window to let some fresh air inside before I start losing my concentration or even notice the extreme low air quality myself. In fact, the air quality decreases a lot faster than I have expected before measuring it.
The Netatmo integration is the first step of my switch from PHP to Node.js since the backend for this API is built on Node and Express as well as a Netatmo npm package for authentication. Find a simple solution to build your own quick API for your dashboard by using this script provided in my Gist. You can easily spin this script up on a Digital Ocean Droplet, an Heroku Dyno or a Lambda Function at Amazon.
If the weather conditions are good, I might either choose to walk back home or rent a city bike at the closest station next to my home/office. Luckily, they are both in a super short walking distance and it reduces my commute by more than half.
Unfortunately, the call a bike provider in Hamburg (Stadtrad) is not publicly sharing their data. However, there is this nifty website called citybik.es that combines a ton of worldwide services in one simple API using a python based library „pybikes“ that you can check out directly on github. This will prevent me from getting my IP address blocked from the Stadtrad servers as well as struggling with markup changes on their website or their xml files when scraping the data manually.
The citibik.es API will be requested every minute by a small php script, which parses the free bikes for my closest stations and returns them as a handy JSON object over one of my own API endpoints so that it can be grabbed and handled easily from an AJAX request:
For most Cities the citybik.es API should work just fine. However for the German System of „DB Rent“ and the Hamburg Version „Stadtrad“ you will have to fiddle with the requests made to load the marker detail data on the ressources linked on this page page of the „Transparenz Portal“. An answer for my request of an official API is still pending.
bus / subway / train
Whenever the weather conditions are bad (e.g. snow, hail, rain, too cold) I prefer to take the bus to get to work and back home. During the morning it is leaving almost in 5 minute intervals, making it convenient to just put my shoes on and grab the next bus without thinking of any departure schedules. However, if I leave my office, I sometimes have to wait more than 10 minutes for the next bus. This is where I initially wanted to safe time and be more informed about departure times.
When I heard that the company running the public transportation in my city was adding real time data to their API, I thought is was time to ask for an account. The data in my region unfortunately is not available to the public by default (unlike the Transport for London API, which is also providing a nice Postman collection to quickly run some first tests). I had to contact them through their website, answer some questions about my use of their data before I was granted access to their testing servers. After two months of usage and testing, I am now finally directly querying their production servers.
This procedure also comes with great benefits: First, the API is run by a separate company, where I have direct contact partners that where able to answer some questions I had with the unusual authentication method. And second, there is a very well structured documentation of the API with a lot of example queries and responses.
The API itself is focused on applications that help to navigate a person from A to B. When I am requesting departure data from a specific bus or train station, I need to manually filter the direction (since I am obviously only interested in vehicles driving in the direction I want to travel, not the opposite direction). In addition, the HVV/Geofox API also lets me filter by certain types of express buses that I am not permitted to use with my current ticket.
After pulling the relevant departure times, a calculation of the estimated time of departure has to be done by subtracting the delay time to the planned departure time, order the calculated times descending and displaying the next three times on my display:
Be aware of the fact that sometimes busses seem to get stuck for a long time, resulting in a hugh delay. Therefore the departureTime – delay results in a negative timeOffset – you should better filter negative values because these busses are not really likely to show up at all (check this example API response).
details on tabbed navigation
What if you would like to get some more insights than just the aggregated values? Just click on the corresponding tab to get to the detailed view of the main KPIs!
For some KPIs I have already made some detailed tabs with more information including highchart charts that display the weekly changes in little line charts, etc. However, this feature is still work in progress and will be updated infrequently whenever I have some spare time. 🙂
Amazon Alexa skill integration
As a small companion Amazon Alexa skill, I have recently added a JSON endpoint to my personal daily flash briefing that reads out some of the main productivity KPI from the previous day to keep me motivated to outperform those today.
I am currently working on a personal custom skill that lets me trigger the pomodoro timer, which will be finalized with the web socket implementation of the new Node.js based setup. Stay tuned!
Since this is not a „project“ for me (fixed time and human resources, final goal to achieve), I will constantly improve this dashboard a little further (and might already have as you are reading this). Therefore I highly encourage you to add your ideas in the comment section, send me a message or a link of your productivity techniques and Raspberry Pi related ideas that help you boost your productivity.
Here are some of the features I would like to add in the future or changes I plan to make to the dashboard (hardware & software):
Node.js & mongoDB
doesn’t Node.js and mongoDB sound more „hipster“ than PHP and mMySQL? 😉 Other than that I like the vast availability of packages and the idea to only use one coding language for both the backend and the frontend. This also means that I will switch from a regular webspace to a digital ocean droplet to also learn some more server configuration and maintaining procedures.
Some of the integrations are still implemented by relying on a third party service like IFTTT or Zapier. This means that I am bound to their queue/execution cycles of up to 15 minutes. Needless to say that this is far away from a real time app. Tools like Trello offer webhooks with advanced information passed on in the request bodies that I would like to use and keep track of in the future.
Wouldn’t it be perfect to have the pomodoro timer run synchronously on multiple devices, trigger my Philips Hue lights at home with a click of a button right from my desk or receive information instantly on my dashboard? Or get noticed when the CO2 level measured by my Netatmo station is too high so that I should better open a window to let some fresh air inside? This is where websockets (e.g. with socket.io) will become very handy (let’s be honest: who really likes websockets in php anyway?).
I am currently experimenting with exist.io where I connected a couple of services I use in order to find out, what else I could do with all my data. I will keep you updated on this!
This section of retired functionalities of the dashboard will be expanded over time. I might also find old screenshots of previous features and versions of the dashboard that I might add, when it creates any added value to this post.
I used to have a small food logging functionality back when the dashboard was not displayed on a touchscreen Raspy but rather on an always-open pinned tab in my browser. This is where I logged the food I ate (preconfigured list of oprions like „soup“, „salad“, „veggies & filling side dish“, etc.) in the canteen for lunch to evaluate the following aspects:
- cost-benefit ratio (aka „value for money“)
- personal wellbeing (did I end up with a heart attack after a greasy meal?)
After only a couple of weeks the result was pretty clear:
- soup had the best cost-benefit ratio (since it was the cheapest dish and kept filling my stomach)
- salad was by far the best choice, inasmuch as it is my favorite meal anyway and it is comparably light in relation to all the other served meals
Because I was continuously getting the same results and because tracking data based on manual input, I stopped recording my meals.
Job done, constant results, got the info that I wanted = R.I.P. food log!
car2go & DriveNow
To be honest: I am not really sure about the final use of this tab. This is why this view never made it to final production and went from the „What’s next!?“- section directly to the „retired functionalities“.
It displays available car2go and DriveNow in the surrounding depending on my current location. I came up with the idea, when I first saw that there is finally a public car2go API. There is no DriveNow API so far, but after playing around with postman for a couple of minutes using the information provided in this blog post (URL and X-API-Key Header), you can easily get a very handy list of all available cars. But without the possibility to book a car with a single touch on the screen, this information is pretty useless. I still have to get my phone out and book the car via the app. In addition to that, I am trying to increase my daily step count which is in stark contrast to increasing the convenience of driving a car.