BestEvidence

Before contributing to the project, please read our contributing guide here: https://github.com/dwyl/contributing

Introduction

BestEvidence (BE) is an open source project commissioned by City, University of London. The purpose is to create an application that can be used to search for scientific evidence to aid a user in following the principles of evidence-based practice. The primary audience is medical professionals/students, but the app is open to all, including lay members of the public.

Live App Links

BestEvidence can be found at: https://www.bestevidence.info/

This URL corresponds to the production app on Heroku: https://best-evidence-app.herokuapp.com/

There is also a staging app to test features prior to production: https://best-evidence-staging.herokuapp.com/

Technologies Used

The project utilises a number of technologies, listed here:

Setup

• Install dependencies with mix deps.get
• Create and migrate your database with mix ecto.create && mix ecto.migrate
• Install Node.js dependencies with npm install
• Start Phoenix endpoint with mix phoenix.server
• Visit localhost:4000 from your browser.

Running Seed files

• Add types to the database with mix run priv/repo/seeds.exs
• Add librarian to the database with mix run priv/repo/add_librarian/exs
• Add super-admin user to the database with mix run priv/repo/super_admin_seed.exs (You will need to have added a SUPER_ADMIN_EMAIL and a SUPER_ADMIN_PASS to you .env file for this to work)
• Update special type in the database with mix run priv/repo/update_special_type.exs
• Add questions to the database with mix run priv/repo/bear_question_seeds.exs

Ready to run in production? Please check the deployment guide.

Features

In-app messaging

This functionality allows for one way communication from administrators to users by design.

Although design solutions were presented for a 'chat' style of UI which would allow users to reply and interact with administrators, it was noted that in these early stages of the application there simply wouldn't be enough resources for BE admins to keep up with full in-app two way communications.

Administrators can communicate with:

• All users: This will be used to communicate things like new features or important news
  • Super admins are the only ones who can message all users
  • Client admins can only message the users who 'belong' to this client
• Individual users: This will be used to alert users of things like if they have inadvertently breached patient confidentiality or to lend individualised support
  • All user email addresses will continue to be encrypted and no user names are collected, so this will be via user ID

Users will be able to see that they have new messages by a small red dot next to the Messages item in the navigation. In their Messages screen, they will also be presented with a banner message to let them know how to contact the BE team should they need to.

In-App messaging preliminary designs

Admin user flows
The first two screens in this flow depict the current application with a change to the navigation menu which will allow for the additional Messages menu item.

The rest shows the administrator's Messages screen, allowing them to pick a specific individual to send a message to.

If the admin is to select 'Send to all' in the top right of the screen, they would go through the following flow instead:

User's Messages flow
As above, the first two screens in this flow depict the current application with a change to the navigation menu which will allow for the additional Messages menu item.

The last screen shows the one-way communication messages screen a user sees. Clicking See More will expand the message to show its full content.

Learn more

• Official website: http://www.phoenixframework.org/
• Guides: http://phoenixframework.org/docs/overview
• Docs: https://hexdocs.pm/phoenix
• Mailing list: http://groups.google.com/group/phoenix-talk
• Source: https://github.com/phoenixframework/phoenix
• Tachyons Bootstrap: https://tachyons-bootstrap.dwyl.com/