briar issueshttps://code.briarproject.org/briar/briar/-/issues2018-06-13T10:09:16Zhttps://code.briarproject.org/briar/briar/-/issues/1225Improve setup UX2018-06-13T10:09:16ZakwizgranImprove setup UXReport from user testing:
"I saw several people trying to click the circle that gets checked when they allow to disable doze. However, many people didn't know they need to click the big button in the middle. Some didn't even seem to rec...Report from user testing:
"I saw several people trying to click the circle that gets checked when they allow to disable doze. However, many people didn't know they need to click the big button in the middle. Some didn't even seem to recognize it as a button. We use the same theme there as everywhere, but people using the app for the first time don't know yet how our buttons look like."Android 1.1akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1222[i18n] Languages unavailable on Android2018-06-14T20:19:17ZExilat_a_Tolosa[i18n] Languages unavailable on AndroidI'm opening this issue because for some languages it's impossible to have the application translated as the application switches to the system language.
The problem is that for example, Android is not available in Occitan, so the applica...I'm opening this issue because for some languages it's impossible to have the application translated as the application switches to the system language.
The problem is that for example, Android is not available in Occitan, so the application won't show in this language.
Could we add a menu in the setting to set the language one wants?
Best regardsAndroid 1.1Julian DehmJulian Dehmhttps://code.briarproject.org/briar/briar/-/issues/1196"Message sent" snackbar covers text entry area2019-03-08T14:25:10Zakwizgran"Message sent" snackbar covers text entry areaA user reported that in private groups the "Message sent" snackbar covers the text entry area. The same thing happens for forums.
We could probably get rid of this snackbar, as the message appears in the conversation immediately.A user reported that in private groups the "Message sent" snackbar covers the text entry area. The same thing happens for forums.
We could probably get rid of this snackbar, as the message appears in the conversation immediately.Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1193Hotspot local coms flakey2020-11-19T10:05:15ZPratiwirHotspot local coms flakeyI tried turning off mobile data and wifi router then turned on android hotspot for two other devices with briar beta to connect to, so three in all. The host device could see one acccount active, but not the other. The two users could se...I tried turning off mobile data and wifi router then turned on android hotspot for two other devices with briar beta to connect to, so three in all. The host device could see one acccount active, but not the other. The two users could see eachother, one user couldn't see the host account.
It seems the devices aren't reliably seeing eachother.
Also as another related issue, none of the bluetooth links worked for chats at all without wifi, even though they were paired. I think the manual needs more detail on how to get this to work.Android 1.2https://code.briarproject.org/briar/briar/-/issues/1126Buttons on external link warning aren't visible in landscape mode2019-03-08T14:24:49ZakwizgranButtons on external link warning aren't visible in landscape modeFeedback from a user: "I just tried opening a link from an RSS feed. The pop-up warning me that this could be used to identify me is a bit higher than wide, and since I was using my phone in landscape mode, the buttons at the bottom of t...Feedback from a user: "I just tried opening a link from an RSS feed. The pop-up warning me that this could be used to identify me is a bit higher than wide, and since I was using my phone in landscape mode, the buttons at the bottom of the pop-up were off-screen, and I only understood what was going on after several attempts, and turning the phone. It would be good if that pop-up could adjust its aspect ratio to the screen."Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1054Cannot scroll in error dialog2019-06-18T16:51:27ZligiCannot scroll in error dialogThis happens on a very small device (Jelly-pro):
![briar_bug](/uploads/54e8e90ff0d2e9a348126c2363a4aee1/briar_bug.png)This happens on a very small device (Jelly-pro):
![briar_bug](/uploads/54e8e90ff0d2e9a348126c2363a4aee1/briar_bug.png)Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1035Get briar added to the main f-droid repo2018-11-16T13:04:46ZGreg TroxelGet briar added to the main f-droid repoThe point is that people who have f-droid installed, but haven't added the briar repo (which presumably will continue to have beta releases for testers) will 1) see briar in the list of apps and 2) be able to install it with no effort.
...The point is that people who have f-droid installed, but haven't added the briar repo (which presumably will continue to have beta releases for testers) will 1) see briar in the list of apps and 2) be able to install it with no effort.
This depends on #783, and then requires getting a build description added to f-droid's configuration.
(I'm really glad to see so much progress towards this overall goal.)Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1012User feedback screen doesn't scroll when email address field gets focus2019-06-18T16:51:11ZakwizgranUser feedback screen doesn't scroll when email address field gets focusA user reported that when sending feedback and moving focus to the email address field, the screen didn't scroll, so the email address field was hidden under the onscreen keyboard.A user reported that when sending feedback and moving focus to the email address field, the screen didn't scroll, so the email address field was hidden under the onscreen keyboard.Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/978Add preference for using tor only when having power2019-02-21T10:34:01ZGreg TroxelAdd preference for using tor only when having power(Sorry if this is a dup; I searched but am not confident.)
I just built and installed Briar after being absent for a while. I see there's a preference for using tor never, on wifi, and on cellular. That's great for some, but doesn't a...(Sorry if this is a dup; I searched but am not confident.)
I just built and installed Briar after being absent for a while. I see there's a preference for using tor never, on wifi, and on cellular. That's great for some, but doesn't address my problem. I realize there is tension with UX and complicated config, but given that having a HS is very very costly power wise, and outbound tor is somewhat costly, I'd like to see a config for "Use Tor when not charging" that is "no, outbound only, outbound and inbound". This would probably let me start running briar, and I suspect would let others do so as well.Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/976Dark theme2019-04-25T09:18:03ZakwizgranDark themeA user asked for a dark theme.A user asked for a dark theme.Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/940Update to the latest emoji2018-09-03T12:13:35ZakwizgranUpdate to the latest emojiSignal's emoji code and resources were updated in December 2016:
https://github.com/WhisperSystems/Signal-Android/commit/f7474362ff8bc75fff70ed75a1caad31fd55374e
New emoji were released in March 2017:
http://emojipedia.org/emoji-5.0/Signal's emoji code and resources were updated in December 2016:
https://github.com/WhisperSystems/Signal-Android/commit/f7474362ff8bc75fff70ed75a1caad31fd55374e
New emoji were released in March 2017:
http://emojipedia.org/emoji-5.0/Android 1.1akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/875Sharing state doesn't update while sharing status or memberlists are open2019-02-28T13:27:49ZMegaloxSharing state doesn't update while sharing status or memberlists are openIt updated when we closed and reopened the screen again.
* [X] Update membership/sharing state
* [ ] Update member's online stateIt updated when we closed and reopened the screen again.
* [X] Update membership/sharing state
* [ ] Update member's online stateAndroid 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/830Some text input fields don't work in landscape mode2019-03-19T10:38:50ZakwizgranSome text input fields don't work in landscape modeCheck that all text input fields can be used in landscape mode. We may need to set `android:imeOptions` so the done button works.Check that all text input fields can be used in landscape mode. We may need to set `android:imeOptions` so the done button works.Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/257Consider offering user validation alternatives2019-04-10T10:39:39ZErnir ErlingssonConsider offering user validation alternativesCurrently we are only validating users with text strings but text input, on small mobile devices especially, is little fun and for that reason some users might choose comfortability, with a short password, over security. There are severa...Currently we are only validating users with text strings but text input, on small mobile devices especially, is little fun and for that reason some users might choose comfortability, with a short password, over security. There are several possibilities available to tackle this "problem":
**1. Offer more user validation possibilities besides using a password, e.g. use the device's fingerprint sensor**
if available. This will only work for one account though, if a user has multiple accounts we will need to offer some way for the user to define which account is using his fingerprint.
**2. Define access layers with different security restrictions**
This is much more tricky and maybe not desirable at all but I feel there is sufficient discussion merit nonetheless. Currently Briar employs a single access restriction on a per account basis, i.e. you either have access to everything (for the respective account) or nothing depending on your knowledge of the password.
Another approach would be to have multiple access levels, e.g. you enter the app with a four digit pin that gives you access to the app but in order to communicate with extra-secure users (this could be marked when contacts are added) you must first confirm your password on a session basis. Here we would need to make sure that the security restriction on the communication between contacts A and B would be identical, i.e. both parties would be required to confirm the passwords in order to communicate.Android 1.1https://code.briarproject.org/briar/briar/-/issues/68Allow private messages to be deleted2020-11-06T11:48:08ZakwizgranAllow private messages to be deletedFeedback from a user: "We should be able to delete our half of private messages. When the second party deletes their half of the conversation it should be completely deleted."
Private messages include invitations and responses in sharin...Feedback from a user: "We should be able to delete our half of private messages. When the second party deletes their half of the conversation it should be completely deleted."
Private messages include invitations and responses in sharing and introduction protocols. Forum, blog and private group clients all depend on the invitation message being available when the accept message is received, so they can get the group descriptor from the invitation message in order to add the group.
We can easily migrate that information into the session. For this we need a way for clients to run migrations. The first phase of the message deletion work would be to add some kind of client migration mechanism.
Android 1.2https://code.briarproject.org/briar/briar/-/issues/47Remind the user to sign in2018-08-06T09:38:28ZakwizgranRemind the user to sign inUsers may forget that they need to sign in to be notified of new messages. We can run a small service at startup that reminds the user to sign in after a certain amount of time has elapsed - maybe a day, then a week, then a month. Touchi...Users may forget that they need to sign in to be notified of new messages. We can run a small service at startup that reminds the user to sign in after a certain amount of time has elapsed - maybe a day, then a week, then a month. Touching the notification should launch the app.Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/2429SecurityException: Permission Denial for CLOSE_SYSTEM_DIALOGS2023-04-18T15:39:33ZakwizgranSecurityException: Permission Denial for CLOSE_SYSTEM_DIALOGS* Android version: 12
* Phone model: Google Pixel 3 XL (crosshatch)
* Briar version: 1.4.23 (070165f)
* User feedback: "I wrote a message, then Briar shut down. This also happens frequently to other apps."
Stacktrace:
```
java.lang.Secu...* Android version: 12
* Phone model: Google Pixel 3 XL (crosshatch)
* Briar version: 1.4.23 (070165f)
* User feedback: "I wrote a message, then Briar shut down. This also happens frequently to other apps."
Stacktrace:
```
java.lang.SecurityException: Permission Denial: android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from org.briarproject.briar.android (pid=24174, uid=10004) requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS.
at android.os.Parcel.createExceptionOrNull(Parcel.java:2425)
at android.os.Parcel.createException(Parcel.java:2409)
at android.os.Parcel.readException(Parcel.java:2392)
at android.os.Parcel.readException(Parcel.java:2334)
at android.app.IActivityManager$Stub$Proxy.closeSystemDialogs(IActivityManager.java:7614)
at com.android.internal.policy.PhoneWindow.sendCloseSystemWindows(PhoneWindow.java:3791)
at com.android.internal.policy.PhoneFallbackEventHandler.sendCloseSystemWindows(PhoneFallbackEventHandler.java:323)
at com.android.internal.policy.PhoneFallbackEventHandler.startCallActivity(PhoneFallbackEventHandler.java:275)
at com.android.internal.policy.PhoneFallbackEventHandler.onKeyUp(PhoneFallbackEventHandler.java:261)
at com.android.internal.policy.PhoneFallbackEventHandler.dispatchKeyEvent(PhoneFallbackEventHandler.java:76)
at android.view.ViewRootImpl$ViewPostImeInputStage.processKeyEvent(ViewRootImpl.java:6317)
at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:6141)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5623)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5680)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5646)
at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:5811)
at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:5654)
at android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:5868)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5627)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5680)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5646)
at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:5654)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5627)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5680)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5646)
at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:5844)
at android.view.ViewRootImpl$ImeInputStage.onFinishedInputEvent(ViewRootImpl.java:6002)
at android.view.inputmethod.InputMethodManager$PendingEvent.run(InputMethodManager.java:3158)
at android.view.inputmethod.InputMethodManager.invokeFinishedInputEventCallback(InputMethodManager.java:2722)
at android.view.inputmethod.InputMethodManager.finishedInputEvent(InputMethodManager.java:2713)
at android.view.inputmethod.InputMethodManager$ImeInputEventSender.onInputEventFinished(InputMethodManager.java:3135)
at android.view.InputEventSender.dispatchInputEventFinished(InputEventSender.java:154)
at android.os.MessageQueue.nativePollOnce(Native Method)
at android.os.MessageQueue.next(MessageQueue.java:335)
at android.os.Looper.loopOnce(Looper.java:161)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7842)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
Caused by: android.os.RemoteException: Remote stack trace:
at com.android.server.wm.ActivityTaskManagerService.checkCanCloseSystemDialogs(ActivityTaskManagerService.java:2955)
at com.android.server.wm.ActivityTaskManagerService.access$900(ActivityTaskManagerService.java:294)
at com.android.server.wm.ActivityTaskManagerService$LocalService.checkCanCloseSystemDialogs(ActivityTaskManagerService.java:5309)
at com.android.server.wm.ActivityTaskManagerService$LocalService.closeSystemDialogs(ActivityTaskManagerService.java:5783)
at com.android.server.am.ActivityManagerService.closeSystemDialogs(ActivityManagerService.java:3800)
```
Edited log:
```
04-02 10:16:30.039 I/BaseActivity: Starting ConversationActivity
04-02 10:16:30.041 I/BaseActivity: Resuming ConversationActivity
04-02 10:16:32.999 I/AutoDeleteManagerImpl: Sending message with auto-delete timer 604800000
04-02 10:16:33.045 I/DuplexOutgoingSession: Next send time decreased
04-02 10:16:33.052 I/DuplexOutgoingSession: Generated offer: true
04-02 10:16:33.052 I/DuplexOutgoingSession: Sent offer
04-02 10:16:33.061 I/DuplexOutgoingSession: Generated offer: false
04-02 10:16:33.495 I/DuplexOutgoingSession: Generated batch: true
04-02 10:16:33.495 I/ConversationActivity: Messages sent
04-02 10:16:33.495 I/DuplexOutgoingSession: Sent batch
04-02 10:16:33.504 I/DuplexOutgoingSession: Generated batch: false
04-02 10:16:34.069 I/ConversationActivity: Messages acked
04-02 10:16:42.127 I/DuplexOutgoingSession: Generated request: true
04-02 10:16:42.127 I/DuplexOutgoingSession: Sent request
04-02 10:16:42.128 I/DuplexOutgoingSession: Generated request: false
04-02 10:16:42.743 I/ValidationManagerImpl: Validating message for org.briarproject.briar.messaging
04-02 10:16:42.761 I/DuplexOutgoingSession: Generated ack: true
04-02 10:16:42.762 I/DuplexOutgoingSession: Sent ack
04-02 10:16:42.768 I/ValidationManagerImpl: Delivering message for org.briarproject.briar.messaging
04-02 10:16:42.770 I/AutoDeleteManagerImpl: Mirroring auto-delete timer 604800000
04-02 10:16:42.786 I/ConversationActivity: Message received, adding
04-02 10:16:42.791 I/DuplexOutgoingSession: Generated ack: false
04-02 10:17:12.763 I/DuplexOutgoingSession: Sending keepalive
04-02 10:17:33.484 I/DuplexOutgoingSession: Checking for retransmittable messages
04-02 10:17:33.514 I/DuplexOutgoingSession: Generated batch: false
04-02 10:17:33.520 I/DuplexOutgoingSession: Generated offer: false
```
As far as I can tell, the crash happens because `PhoneFallbackEventHandler` is being called to [handle a key event](https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/com/android/internal/policy/PhoneFallbackEventHandler.java;drc=95c1165bb895dd844e1793460710f7163dd330a3;l=250) for `KEYCODE_CALL`. The handler tries to start a call activity for the current app, which fails because Briar doesn't have permission to close system dialogs (which I guess is part of the process of launching the call activity).
So perhaps this is happening just because the user hits the call button on their device/keyboard, or perhaps it also requires some other circumstances, like an unusual device/keyboard config. Either way, it looks like a problem that's specific to this user and (based on their comment) not specific to Briar.https://code.briarproject.org/briar/briar/-/issues/2385Sponsor 6 User feedback2023-08-28T16:07:07ZIvanaSponsor 6 User feedbackThis ticket gathers different strands of user feedback received during Q3 and Q4 2022 from users.
Users were asked to test the Briar app at an event, therefore there was little in the way of user preparation, onboarding etc.
## Feedba...This ticket gathers different strands of user feedback received during Q3 and Q4 2022 from users.
Users were asked to test the Briar app at an event, therefore there was little in the way of user preparation, onboarding etc.
## Feedback from users on how to improve Briar
### Issues Relating to User Experience and Functionality
| Problem | Solution proposed by person giving feedback | Notes from team | Relevant tickets | Next steps |
| ------ | ------ | ------ | ------ | ------ |
| Anecdotally, users have said that Briar doesn't work during internet shutdowns. We heard this at the conference last week. | <p> What we need to explain is that it does work, but it has limitations. We need to lower expectations of what this can do. It is not as good as WhatsApp, and it can take up to 10 minutes to install and connect with friends who have it as well as add yourself to a forum. </p><p> Briar should adjust expectations of what it is capable of doing and make its limitations clear, so users don't become frustrated that it doesn't operate like WhatsApp. </p> | <p> This feedback touches on an issue we've been discussing recently: whether our product strategy of imitating the features and UX of a typical messaging app is effective for meeting the needs of people affected by internet shutdowns. That's an issue we should continue to discuss as a team, but it's too big to tackle in the remaining sponsor 6 hours. Still, within the existing product strategy there are things we could do to address this feedback. </p><p> We could change the language we use to describe the app (on our website, Google Play and elsewhere), to make it clear that when operating offline, the app can only be used to communicate with people nearby. </p><p> Within the app, we could create a stronger UX distinction between online and offline operation. </p><p> We could add onboarding to explain how offline communication works when the app is used offline for the first time, perhaps using information about the available transports and contacts to decide when onboarding is needed. </p><p> We could be more proactive about using onboarding and UX cues to explain the differences between Briar and typical messaging apps, both online and offline. </p> | #1472 | Design UX for contextual help: #2390. |
| Techies at the event found it hard to download and install the app and became frustrated. Once the app is downloaded and users are trying to connect to one another, they don't understand how to scan each other's QR codes. Our tests often saw pairs of users only scanning one of the QR codes, rather than both on each user’s phone - the current documentation of a still image doesn't exactly show how to do that - and users can get frustrated during this period. | Here are some ways to improve this: Briar needs to include clear images, GIFs and/or a video to make clear how to correctly scan the QR codes early in the installation process to avoid user frustration. | <p> Many other apps use QR codes, but none of them require both parties to scan each other's codes, creating a strong expectation that Briar will work in the same way. </p><p> We've already made a small step towards addressing this by adding hints to the UI. </p><p> We could improve the onboarding for adding a nearby contact, perhaps with a vector animation of both devices scanning each other's QR codes. </p><p> In the longer term we could replace the QR code workflow with a new workflow in which the users choose who will go first, so that we can show each user the next step they need to take. </p> | #348, #1909, #1235 | Design UX for contextual help: #2390. |
| While tutorials and documentation on Briar exist in several languages, these are difficult to find. | <p> We need a centralized place to download Briar's existing documentation and tutorials in multiple languages quickly and easily to help people install the app with ease. </p><p> Some suggestions to improve this include: Making these resources available on the Google Play Store and/or the Briar website, and/or when people download the app they are instructed to do a walkthrough of the app in various languages. Instructions or a walk-through in multiple languages would be helpful. </p> | <p> We should make the manual, quick start guide and FAQ easier to find on the website - this depends on restructuring the nav. </p><p> Linking to the docs from Google Play is an easy win. </p><p> We could also write tutorials for specific tasks (eg creating an account, adding a contact). These might replace the current quick start guide and would allow more topics to be covered. </p><p> Bundling the manual and/or tutorials with the app, and/or writing help text specifically for the app, might also help. </p><p> Open problem: generating in-app documentation and web documentation from the same source, in a format that's compatible with Transifex. </p> | website#21, #1312 | <p> Restructure website navigation: website#21. </p><p> Link to docs from Google Play: #2387. </p><p> Design UX for contextual help: #2390. </p> |
| People join Briar, but they don't know what to do or how to find and join a forum. | The documentation should spell this process out clearly, along with GIFs -- not just still images that don't properly explain what is needed. | <p> We should add onboarding for the blog, forum and private group features. This could consist of a "tour" after the user creates their account, and/or onboarding for specific features when the user first opens them. </p><p> We should offer contextual help throughout the app, either by linking to the appropriate part of the bundled documentation or by writing help text specifically for the app. </p><p> Open problem: how to indicate that help is available in a given context without interrupting the user's workflow? </p> | #1472 | Design UX for contextual help: #2390. |
### Issues Relating to Transparency
| Problem | Solution proposed by person giving feedback | Notes from team | Relevant tickets | Next steps |
| ------ | ------ | ------ | ------ | ------ |
| <p> Information on how and what user data is collected and used by Briar needs to be more clear and more transparent to users in plain language. While the privacy information is on GitHub this is not accessible to an ordinary user and to those who may not be familiar with a privacy policy, especially if it is written in very technical language. </p><p> Some of the questions event participants wished to be answered before they downloaded the app included: Is it encrypted? What will they do with my data? Why do I need a password? Why isn't it on iOS? Will it become available on iOS? Who has developed the app? </p> | They should have a help/FAQ section based on this information. | <p> The privacy policy is linked from Google Play - we should also link to it from GitHub. </p><p> The privacy policy is written in non-technical language, but it's only available in English. Making the website available in multiple languages would help with this. </p><p> The FAQ should also be made available in multiple languages and linked from Google Play and GitHub. This argues in favour of putting the FAQ on the website (where it can be translated) rather than the wiki. Including the FAQ in the app might also help. </p><p> We could add onboarding to the account setup process (or expand the existing contextual help and make it more obvious) to answer the questions about encryption, data storage and why the password is needed. </p> | website#28, website#29, #1312 | <p> Link to docs and privacy policy from GitHub: #2388. </p><p> Make website translatable: website!87. </p><p> Add FAQ to website: website#29 (depends on website#21). </p><p> Design UX for contextual help: #2390. </p> |
### Some Suggestions for Improvements to Increase Functionality/User Uptake
#### Read/Delivery Receipts
| Problem | Solution proposed by person giving feedback | Notes from team | Relevant tickets | Next steps |
| ------ | ------ | ------ | ------ | ------ |
| During an emergency situation information on the delivery/receipt/reading of messages can be vital. | Briar developers should make it optional to add read receipts to private messages and forums. The app should provide clear ways to show if a message has not been delivered or read, similar to some other apps. | <p> Opt-in read receipts could be implemented for private messages. </p><p> We should look at how other apps handle the UI distinction between a contact who hasn't enabled read receipts and a contact who has enabled them but hasn't read the message. </p><p> Some apps don't let you request read receipts unless you also send receipts to your contacts (although this couldn't be enforced in a P2P app). </p><p> For forums, it's not clear how read receipts would work, as the membership of the forum isn't known. </p><p> Read receipts for private groups might be feasible. We should look at how other apps handle read receipts for group chats. </p><p> Some people may think that two checkmarks mean a message has been read. We could show onboarding for this and add it to the FAQ. </p> | #1220, #1208 | <p> Research how other apps handle read receipts: #2389. </p> |
#### Understanding the Internet vs Bluetooth Function
| Problem | Solution proposed by person giving feedback | Notes from team | Relevant tickets | Next steps |
| ------ | ------ | ------ | ------ | ------ |
| At the moment, people don't seem to understand what the internet and Bluetooth functions are, what they mean, why it is better than WhatsApp, when it is appropriate to use either function, and what the limitations are when these functions are used. | A notification/banner showing if the app is relying on the internet or Bluetooth should be shown to make the use of the two functions clear and help people understand the two different modes it can operate. | See notes above re: making it clear that the app works differently from WhatsApp. | See above. | See above. |
#### Confusion about the Forum Function
| Problem | Solution proposed by person giving feedback | Notes from team | Relevant tickets | Next steps |
| ------ | ------ | ------ | ------ | ------ |
| Event participants were confused about what the term ‘forum’ meant and which function it was meant to provide, which can indicate that other users, especially non-English-speaking users may not be able to understand what this function provides. | Briar should consider changing the name Forum to Groups which is more clear and in line with other apps to avoid confusion and misunderstandings by users, especially those in non-English-speaking countries. | <p> We should try to find out whether this is a translation issue or whether the term is also unclear to English-speaking users. </p><p> We could do some user research into what users expect the terms "forum", "private group" and "blog" to mean. </p><p> We discussed renaming "forum" and "private group" to "public group" and "private group", or "open group" and "closed group", but this might cause further confusion between the two features. We won't find any single term that conveys the right concept to everyone, so explanations need to be included in the app and easily accessible. See notes above re: onboarding for features and contextual help. </p> | #800, #1472 | Design UX for contextual help: #2390. |
#### Warnings and Notifications on Internet Disruptions and Shutdowns
| Problem | Solution proposed by person giving feedback | Notes from team | Relevant tickets | Next steps |
| ------ | ------ | ------ | ------ | ------ |
| It needs to be clear that people DO need internet access to download and install the app, so installation needs to happen before any shutdowns/disruptions. | <p> To help users be prepared and remember to use Briar, notifications could be sent to users' phones while they are connected to the internet to tell friends about the application and to help them download it. The notification can be sent periodically to remind users about the app. </p><p> Briar could also connect to civil society/research groups who monitor internet connectivity around the world, so that it can provide notifications and warnings if there is a risk of imminent internet disruption or shutdown so that users can prepare/share information to friends/family to start using Briar. </p> | <p> Apparently we need to do a better job of advertising the offline app sharing function! We could add onboarding for this feature when the app is first used offline. We could also think about whether there's a more prominent place in the app where this feature could live. </p><p> Showing too many notifications might irritate users and cause them to turn off notifications. </p><p> Notifications for specific countries at risk of internet disruptions would be possible, but the Briar team would prefer not to operate any centralised infrastructure. We might be able to partner with an organisation like Access Now to publish information, perhaps as an RSS feed that Briar peers could fetch via Tor and automatically re-share. </p><p> We could direct the user to the offline app sharing feature when we detect that the app is offline. </p><p> Many apps have the ability to generate a generic message like "Let's keep in touch via Briar, download it here", which can be sent via another app. This would be an easy win. </p> | | Share a link to the Briar download page: #2391. |
## Feedback received via Briar blog from project partners
| Problem | Solution proposed by person giving feedback | Notes from team | Relevant tickets | Next steps |
| ------ | ------ | ------ | ------ | ------ |
| It's not obvious that the Reblog button can be used to reply to a post. The reblog icon is intuitive *if you're accustomed to Tumblr*, but that's ancient to most savvy youths, a primary target audience for Briar. | It would be better to have separate Reply and Reblog buttons, like Twitter. | This is an easy win. | | Use separate buttons for reblogging and commenting: #2392. |
| A link shared within a blog is neither clickable not intuitively copy-able. | | <p> The underlying issue is that blog posts are written in plain text but rendered as HTML, because RSS posts can contain HTML. Messages elsewhere in the app (private messages, forums, private groups and even blog comments) are written and rendered as plain text. </p><p> We could convert blog posts to HTML when they're written, including converting URLs into links. </p><p> Alternatively, we could continue to render RSS posts as HTML, but render non-RSS posts as plain text. We could then make links clickable when rendering all plain text content (blog posts, blog comments, private messages, forums and private groups). </p><p> We should investigate the options for preprocessing text to HTML. </p> | #689, #421, #786, #1038, #90 | Convert blog posts and comments to HTML when composing: #2393. |
| As I play with the app, I'm continually seeking a "homebase" with the feed but featuring notifications of messages and new posts, and instead I end up hitting the Back button and accidentally exiting the app. | A centralised homepage with just my notifications would be optimal. | <p> We could show badges for new content in the nav menu, and maybe even on the hamburger button. This might require some refactoring to limit the amount of DB work needed. </p><p> Paul has some drawings of different navigation options, including bottom navigation, which would make the badges visible from everywhere. </p><p> Another option would be to create a new homepage that shows new content from all parts of the app. This would be a much bigger change, requiring design work to differentiate the various types of content and backend work to make the new content available efficiently. </p> | #42 | Show new content in navigation drawer: #42. (This may need to be broken down into subtasks.) |
| Why can't I filter the Blogs page to see posts from specific contacts? | | This could be added, either as a blog list screen accessible via the overflow menu, similar to the forum and private group lists, or as a dropdown at the top of the feed.| #624, #864, #865, #996 | |
| Post that is continually reblogged when I add comments to it creates annoying redundancy for my contact. | | This is a tricky one because comment threads can fork. Let's look at how Tumblr and Twitter handle this. | #2154 | Research how Tumblr and Twitter handle comments/reblogs for previously seen posts: #2394. |
| When I go to contacts individually, I'd like to see their blogs. | | This could easily be added to the conversation screen's overflow menu. Alternatively, it could be added to the long-requested contact info screen. The contact info screen could also serve as an entry point for documentation. | #26 | |
| Adding nearby contact wait screen makes one unable to do other things in the app. | Can it happen in the background? | <p> By the time we know that the contact has scanned our QR code, the process is nearly finished. So with the current protocol, not much time would be saved by moving the process to the background at that point. </p><p> If we redesign the workflow and protocol for adding nearby contacts then we should keep this request in mind, but that redesign is probably too big a piece of work to tackle in the remaining sponsor 6 hours. </p> | #348 | Too big for sponsor 6. |
| Ability to make others admins of private groups. | | This has been requested before. Having multiple admins would be very complex. Transferring ownership to a new admin might be feasible, but it would be too big a piece of work for the remaining sponsor 6 hours. | #920 | Too big for sponsor 6. |
| Bigger buttons. | | More information needed. | | Ask for more info. |
| Too many similar terms. | | More information needed. | | Ask for more info. |
| Notifications are clunky. | | More information needed. | | Ask for more info. |
| Restructure actions so you just write a post and then decide who sees it (eg private, a contact, a group, or all). | | <p> If the request is only intended to apply to blogs then it should be feasible. It would require UX and backend changes, including a small protocol change to let recipients know whether they're allowed to re-share the post. </p><p> If the request is intended to apply across the app, ie to make it possible to write some content and then decide whether it should be a private message, a blog post, etc, then that would be more complex (for example, private messages support attachments but other types of content don't). Email clients and some messengers support this, and it's useful to be able to create an ad hoc group for a conversation. We should keep this use case in mind when working on public mesh protocols. </p> | #1013 | |akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2308Emoji button doesn't work on Android 42023-03-22T12:47:53ZakwizgranEmoji button doesn't work on Android 4* Android version: 4.1.2
* Phone model: Samsung GT-I8260 (arubaslimssxx)
* Briar version: 1.4.5 (4df523a)
* User feedback: "I would like to inform you about the emoji icon which does nothing. It does not show the emoji selection box and ...* Android version: 4.1.2
* Phone model: Samsung GT-I8260 (arubaslimssxx)
* Briar version: 1.4.5 (4df523a)
* User feedback: "I would like to inform you about the emoji icon which does nothing. It does not show the emoji selection box and therefore it is not possible to send any emoji."
I can reproduce this on my API 16 test device (Samsung Galaxy Ace 2).https://code.briarproject.org/briar/briar/-/issues/2209Unable to delete my own blogs2021-10-26T10:35:55ZJerry WhiteUnable to delete my own blogsI'm unable to delete any blogs i create. The option appears from the menu but is greyed out and unavailable.
I can successfully delete RSS feeds and other people's blogs but not my own. This means if i make a mistake, it's permanent and ...I'm unable to delete any blogs i create. The option appears from the menu but is greyed out and unavailable.
I can successfully delete RSS feeds and other people's blogs but not my own. This means if i make a mistake, it's permanent and the only option is to create a new Briar account.