Have a sandbox environment to play with the app before a full deployment #326
Comments
|
Current thoughts on the two requirements:
It is not clear if this is the flow that would work best, and it would definitely need some significant testing, but I am documenting this for the record. Hopefully @PatGendre + the FabMob team will put in their thoughts as they get feedback from other deployers. |
|
Hi @shankari, thanks for creating the issue, we don't if/when can do this but we consider it a good way of promoting e-mission and facilitate testing and adoption with limited resources to start with.
|
You can of course, choose whatever method you want to accomplish this, but the idea behind the UI channels was to have an easy way to customize all this. Basically, you can publish a white label app and then have people select the channel that customizes color, logo, server, auth, etc. |
|
@shankari I add here the description of a potential project and your remarks inline. With our experience from last year at fabmob, our idea would be to release a public app focused entirely on self data : we've found the private beta app quite cumbersome to manage. The terms of use would state that the app editor would not send the data to any one, nor use it for any purpose. So there should not be many privacy issues, even if there is a server and even if data is not fully encrypted. The goal would be : -2- to work towards standardizing diary trips data and developing nice tools (online or libs) for looking at it (or even editing it) : the users wishing to do so would be invited to upload some of their data as public tracks on a server where they could visualise the tracks in various ways, much like you can uploads tracks on openstreetmap.org For the moment it is only an idea (already dating from a few months), the project would have no commercial goals so it should be quite limited on resources.
|
|
@PatGendre @nlehuby @lefterav @laem I am going to spend some time on this in the next couple of weeks to have something to showcase as I start talking to cities about Agile Urban Planning. Can we brainstorm a bit about what this should actually involve? High level decisions:
UX questions:
Thoughts? |
|
Hi @shankari
Yes that would be great if DFKI can host it. I'd have question: if we get a lot of users (sometimes we can have good surprises;-), what can we do : limit the max number of users? limit the number of days a user can have an account? scale up the server?
at least we should have a default UI, which existing UI would it be? Would it need to be adapted?
Definitely it would a nice feature to be able to choose the server, either for the user, or by changing the UI (scanning a new qr code)
Yes, so we wouldn't have to re-apply to the Stores for a new app. I fear there is a risk of being rejected when applying for an app with a modifiable UI if the editor is not a well known academy such as UC Berkeley.
I don't have the expertise to solve this issue, actually I don't even see the issue : the server could send the data by email to the user, why would this not work? maybe because if we have an openid / auth0 solution we don't need the user e-mail ?
Yes I agree, we should really inspire trust that this a purely "self data" app. In that respect, I suggest that we deactivate features using other people's data : in the dashboard, not show the aggregated scores (at least for the basic UI), and on the server, deactivate the heatmap. |
|
@PatGendre Thanks for the feedback!
@lefterav communicated with me offline and agreed in principle to hosting the server as long as I maintained it. I replied and committed to maintaining the server as long as the committee felt that the sandbox was needed.
This is a great question, and one that is responsible for my delay in replying. I have gone back and forth multiple times on this, but right now, I think that the answer is to limit the number of days that a user has data for. The goal of setting up this server is to allow the maximum number of users to experiment with this kind of data collection and the insights it can enable. Really enthusiastic users can download their own data, both raw and analysed.
Why? With emTripLog, the default UI asks you to scan a QR code to select a UI.
Since we want to allow users to change the UI, we should have the default server be the DFKI server, but also potentially allow users to manually type out the URL of their own server. I may back off on this if it turns out to be too complicated.
emTripLog has been registered by me. See the author - it is "K. Shankari". I will also pay for the Ionic Channels for now. I do want to publish a new version of emTripLog with some native code bug fixes, internationalized native code error messages, supporting app store updates etc. I am still working with NREL on how best I can do this as part of my NREL work.
If you are talking about the existing "Download JSON dump", it is not easily automateable via a script. If we want to potentially keep only a limited amount of user data, it would be good to also give users a script that would allow them to download their data automatically to their own computer, and potentially upload it to their own nextcloud, etc. The easiest way to support such a script is by having the user type in a secret that they know.
I agree that we should deactivate the heatmap. Not sure if we should also deactivate the comparisons with other users - let's see what the rest of the committee says.
So by "serverless", do you mean that the analysis pipeline should run without storing the data, or that the analysis pipeline should never run? The manual sync option (e-mission/cordova-server-sync#39) should enable the second mode. But in order to get the benefits of the analysis pipeline, such as section segmentation and mode inference, the analysis pipeline needs to run and it currently runs only on the server. If people want to port the python-based analysis pipeline to run natively on android and iOS, that would be great, but I won't be able to work on it myself unless it is an Agile Urban Planning priority. |
|
@shankari thanks for the answers, great if DFKI can host the server :-)
Ok, got it.
Ok, that seems reasonable.
Ok I meant which UI (i.e. default QR code) could proposed by default to the user to select? It would the NREL flavour of the app? Which features would this UI include?
I meant "never run the analysis pipeline" because it would be much simpler to deploy, and could be good enough for certain basic use cases. But manual sync can be useful too. |
|
I will probably get to this only next week because this week all my technical time will go to adding license information to all the files and submitting the project to the Berkeley Technology Transfer Office to get formal approval of the license. That is required to get formal approval from NREL to publish the apps through NREL. Paperwork, paperwork! |
I'm not sure about this from the user perspective. Having to "configure" the app, even if it's just selecting the server from a menu, would be strange, I've never seen something like this except for developers. The app would have a different name than the city or organisation prompting the user to download it, it looks confusing (but I don't really know how UI channels work :) ). Why not upload to the store a single and simple UI, that would serve as a demo for those interested in the project that whish to see it running, and a mainstream application if by chance more people start downloading it ? I've installed EmTripLog from Google Play, and those are my notes as a user that is happy to move again and see some "self data" after being locked for 3 months 😄 :
Today : 🚲9km 🚶♂️2km
Not sure it's great looking, but I've sketched this website for a similar app that I had in mind : https://kilometre.app. It's a very simple React open source website, and I'd be happy to see it used / forked. Sorry, the content is in french 😅 . @shankari what do you think about the name, kilometre.app, from the french "kilomètre" ? Is it understandable by a native english speaker, or is "tre" considered a mistake, "ter" being the only understood terminaison ?
As a user I don't feel the need to have my data kept if I uninstall the app, or if I loose or change my phone : a simple id would suffice. If I loose my records, well I'll start logging them again and build data today, tomorrow, etc :) If people love the app and request an account, it could be added later. Think of whatsapp : this app downloaded billions of times, looses your data by default when you loose access to your phone. You need to setup backups later in the experience, if you want to.
Yes ! I believe it would be a great way to build trust and accomadate with the fact that some users don't care at all about privacy, while some others would be ready to write a blog post about how wrong it is to collect location data. The message could be :
@shankari what's the best ressource for me to start looking into this ? Is there a summary of all the steps that would not be easy to port (e.g. needs a numpy function hence numpy would need to be pacakaged in the app; needs an overpass request, etc.). Should I explore the entry.py ?
Data, once processed, would only weight a few mb per user, right ? If so, I'd advise not to erase data, at least while the user is still active. What's the bottleneck to the number of users ? Is it processing batches that could raise a memory error ? Or the overpass API request rate limits ? Isn't the processing "stateless" between users ? What I mean is : if one server got too busy, could we not start a new server and proxy the following app downloads to the newer server ? |
|
As I told Shankari, hosting in DFKI seems a good perspective. I am currently investigating the final details of opening up the DFKI server and awaiting for some permissions; hopefully they will be positive. The legal aspect concerning data privacy will be the most tricky one. Although we can leave many aspects of the development open, we have to be already pretty clear with what is going to happen with the data. Because as Shankari said, for the server to run, we need a privacy policy and a user agreement approved by our legal department and I would (barely) happy to do that once, definitely not more than that. I like the idea of various interfaces. This could be done by offering pre-compiled app packages (e.g. apk) for each interface. Of course, as DFKI we would be very happy if we can promote our fork/interface which is focusing on CO2 emissions. demo here the alpha version is uglier :-) |
|
Hi @lefterav , I hope the privacy policy and User Agreement can be approved, that would super if DFKI can host the server:-) Thanks for the link to the mockup, I see that you implemented a way to delete a trip or segment and edit a segment, I didn't know, this is a great feature! would it be easy to add to another app ? How does it impact the server code? (e.g. how does this feature interact with the pipeline? Can you only delete/edit processed trips? are the modified/deleted segments tagged as such? |
|
The mockup includes some wanted features that are not in our alpha implementation. Maybe it is not the right thread to discuss this, but as far as I remember, in the alpha version the interface includes the option to edit the detected transportation mode. Nevertheless our developers had issues with synchronizing that with the server and it may have been left unfinished. Editing the kilometers of a segment was not possible in the alpha version and I am not sure about deleting segments or trips. |
|
Ok thanks for the explanations. If it is implemented later on, it'll better indeed to discuss it in another thread. |
|
@lefterav very interesting mockup ! What about using a bar chart instead of the pie chart ? Just a suggestion, I'm not sure which is better :) |
|
@laem Thanks so much for the detailed feedback. Some responses inline.
Wait, I am confused. Is the plan that cities or organizations would prompt users to download the app, or that users would organically decide to download the app for self tracking? If a city wants to users download the app, then my expectation is that they will build their own app which sends data to their own server. Also, themes and skins are super popular, at least in the OSS world :)
Because then we would need to debate what that single and simple UI should be. Should it look like the current e-mission UI? Should it look like the DFKI UI? Should it look like the TripAware UI? IMHO, the strength and power of e-mission is that it is configurable and allows deployers to customize it to their needs. So any demo for those interested in the project should have a way of showcasing the ability to customize the core platform. The e-mission (not emTripLog) app is an example of a single UI app, and every time people see it, the first thing they tell me is how they want to change it 😄 Of course, you (or FabMob) can publish a single UI app based on e-mission to the stores going forward.
You have installed emTripLog with one particular skin (the emotion skin)
It seems like you have specific ideas for a different skin. That's great! Build it and submit it to the gallery. As I said earlier, you can also publish a simple app based on it to the stores if you are willing to take on the burden of keeping it maintained. You may find this other channel to be closer to what you want. Just click on it to switch the UI to one that you might like better :)
This was a choice that the TripAware skin developers made because they didn't want people to cheat in the game by reclassifying their trips to look more sustainable. The
Server requests are slow because the tripaware server is running on a 10-year old laptop in my house. Once we move to DFKI, it should be faster. And the new skin (above) supports displaying unprocessed trips as well.
The current pipeline is at intake.py. I would strongly encourage you to read my thesis for a description of the pipeline steps and a high level idea of their implementation.
We could definitely start a new server and load balance between the two servers. But I haven't yet seen anybody step up to host such a server when needed. Even though DFKI plans to host this server, they have not yet finished provisoning it :) |
@laem Aha! This is why it is important to, at least right now, support multiple UIs. Because everybody who looks at any UI can immediately think of a way to change it, and we don't have any data on which is better. And there might not be one "better" - @laem may prefer a bar graph and @PatGendre may prefer the polar bear UI. Which is why I suggest for now that we offer a gallery of potential skins for users to choose between. What would be really cool would be to also capture usage information (e.g. number of launches, time interacting with the app, etc). Note that those are not personally identifying. We could publish a dashboard of the usage information so we know objectively which is more popular and deployers who do want to build a single UI app know where to start :) |
I don't think this has been implemented, but I would recommend using the approach in #476. IMHO, you don't want to mix analysed and input data for all the reasons outlined in that bug. |
There have been requests for the plugins to support React Native/Flutter in addition to cordova (#499). I have not had time to build this yet. But I have also been blocked by the lack of UI support for the other platforms. I don't have the resources to build and maintain a React Native UI and a Flutter UI, and my UI design skills suck. But if you wanted to port the existing Angular UI to React Native, I would be open to adding a RN interface to the plugins when I next have some spare time.
British English uses kilometre, US English uses kilometer. Since I was raised in India (British English) and have lived in the US for > 20 years now (US English), both of them look right to me 👍 But if you can avoid a word with |
Given that we don't want to modify the privacy policy and user agreement multiple times, we should keep it simple. I propose two option: 🎉 We will never use the data for anything. We will not share it with anybody, and we will not even attempt to analyse it ourselves. This is the most privacy preserving, but I wonder if it is too restrictive. What if we could use the data to help in a potential second wave of the pandemic? Should we just sit on the data and not use it for public good? On the other hand, users can download their data and upload it if it is needed for public good. Thoughts? 👀 We will use the data only for aggregated research. We will not share it with anybody other than academic collaborators who sign an agreement to not republish the data. Collaborators will have to demonstrate a clear project for which they want the data. Data will be shared primarily to improve app functioning - e.g. for better mode detection. This is more on the utility side of the tradeoff. But it gives us more flexibility if there is an urgent need to use the data in a crisis situation. We will not monetize the data or sell it to third party brokers in either case. @PatGendre @laem Please vote 🎉 or 👀 using the reactions for the comment ☝️ I am torn between the simplicity of 🎉 and the ability to respond to crises inherent in 👀 |
|
@shankari I would vote for the simplicity. As for aggregation, the terms of use should clearly state how the data is aggregated. For instance, sending the daily total of kilometers by mode (as in mael kilometre app) could be ok, but not the heatmap. And I have a question : as emtriplog is designed to have a configurable UI, the user consentment is done after installing the UI, right? So we could have the "default" UI / QrCode with purely self data terms of use, and another UI with other terms, authorizing aggregation (and possibly routing to another server) ? |
Unfortunately, we don't know when the user leaves. Other researchers have asked whether we can detect when the user uninstalls the app, and we cannot. If we have the user email, we can send them an email if they haven't uploaded data for a while, but with the token based approach that we are discussing, we can't. Once the user uninstalls the app, the data is effectively unusable.
First, I agree that we should ditch the heatmap for this. wrt metrics, there are at least two aggregation scopes:
I can see the argument against (3), but I don't see the argument for prohibiting (2). Also, many of the current UIs (master, DFKI, TripAware) support (2) and I don't have the time to go through and modify them to remove that functionality.
That's a great idea! We could give people a choice between sharing and not sharing their data (e.g. between options 🎉 and 👀) above. Let's see what @lefterav thinks about asking DFKI legal for two different consent documents :) |
|
Thanks for your reply.
We discussed earlier the idea of "limiting the number of days that a user has data for", so in practice the app would work only for a certain number of days (like a free demo version of a commercial software ;-) Or how do you think this limitation will
Ok, I don't see the argument either. But there may be a legal reason. |
I was thinking of just deleting any data that is more than 15 days old. So the users would continue to collect data, they would be able to view their new data in real time, but their old data is gone unless they have set up the script to auto-download it. |
Ok, this a simple and as such a good way of doing it :-) |
Not really. If there is no data left for a particular user, we can just delete their "account", which is an entry in the profile DB as well.
I want to reiterate that with the current proposal of using a user-specified string as the auth, we have no way of contacting users who don't have the app installed. We will not have their email address or any other contact information.
This would have to be an in-app survey because again, we won't have their email address. If we do want to get their email address, maybe we need to use the FabMob OpenID auth server instead. |
|
@shankari thanks for the answers you're right, setting up an proper auth like openid may be too complicated and the user specified string should be ok. |
|
Maybe we can revisit this after we set it up and experiment a bit within ourselves. |
I can ask DFKI legal for anything we want, although I don't see a reason to not ask for the more permissive of these two. I am already a bit lost how to start concerning GDPR and privacy statements. That's totally not my expertise. If anybody can give me a hint, please do so. Edit: I am looking again at Shankari's intro consent text and it seems pretty good. I guess we have to
|
|
@lefterav I believe that the e-mission platform currently supports GDPR as long as we commit to delete data manually on request, which I can commit to do. It has been deployed in France, so @ericafenyo could tell you concretely if there was anything else wrt the three points:
I think that's it! |
|
@lefterav right now, it seems fine to list me with my NREL affiliation. Do you need any other information before you ask for permission? |
|
With the energy iCorps interviews, and the recent publication of the NREL news article on the eBike project, it looks like some people have searched for the e-mission app in the stores and installed it. Unfortunately, the e-mission app has not been updated since 2018. AWS has also notified me that there is degradation of the underlying hardware for the currently running instances, and they will be shut down on the 11th. I can restart the server, but then EECS Berkeley needs to reconfigure the DNS for the server to point to the new IP, and I am not sure if they are comfortable doing so. Due to the acquisition by NREL, and the focus on customizable and extensible user interfaces, we are unlikely to have a single app going forward; instead we are likely to go with an approach similar to emTripLog. So I decided to make the following changes this weekend:
I've attached the logs from the push. |
|
It looks like we had two iOS phones and 213 android phones At least some of the failures were due to |
|
Also backed up all the data as of now and stored on kundavai's backup. |
|
Changed the appid and retried. migrate_push_copypaste_emission.log.gz |
|
I got the notification both times on android, so the difference is primarily for iOS. |
|
The reason for the mismatch between iOS and android is that we are not able to convert the tokens for iOS. we need "Maximum 100 tokens per request." |
|
Fixed (will link PR here). |
|
So overall, we had But it was never going to work anyway, since the app itself would need to be published by NREL. |
…t server retirement - Handle the case where there is no curr_platform set by using `.get()` with a default value of `None`. This ensures that these entries are skipped. - Send the mapping tokens to firebase in batches of 100 - This required some additional refactoring around return types since we needed to concatenate the values from the various batches before storing them to the database This fixes the iOS issues described in e-mission/e-mission-docs#326 (comment) as seen in e-mission/e-mission-docs#326 (comment)
From @PatGendre there was a request to have a sandbox server where users can play with the app before committing to a full deployment.
We are currently thinking of this as having two main steps:
The text was updated successfully, but these errors were encountered: