Updates to user profile pages

codeforamerica / rva-screening

Health service prescreener for sharing patient eligibility data.

http://quickscreenrva.com

BSD 3-Clause "New" or "Revised" License

11 stars 8 forks source link

Updates to user profile pages #134

Closed mapsam closed 9 years ago

mapsam commented 9 years ago

`/user/<id>`

User profile routes are navigated from patient pages (history, overview) in order to see who has been editing users most recently. In the database, they will be related to a specific service.

Information to include for now:

[x] Name / username?
[x] Contact information (phone, email)
[x] associated service they are related to ~~(can there be more than one?)~~
[ ] photo?
[ ] when do they work? (could be useful for volunteers who aren't working full-time)

bengolder commented 9 years ago

I think I get the general sense and agree that it is needed. I think we should also nail down:

Who, specifically, do we assume would be using this page?
What do we assume they would be trying to do there?

esmithayer commented 9 years ago

I've been thinking about these two situations:

A staff member at Service A helps a patient fill out their information and then refers the patient to Service B. Screeners at Service B have questions about the information, so they want to talk to the person who initially filled it out.
A screener or navigator wants to contact someone to check a patient's application status at another service. A general contact number for the service would probably also work, but several users have told us that they like having a specific person to contact for these types of questions.

But yeah, I'm unsure about exactly when people would want user-level contact info vs. service-level contact info--might be a good thing to ask about in the next round of user research.

I think associating users with a single service makes sense for now--I don't think we've met anyone who works at more than one, and associating users with multiple services would bring up a bunch of new consent questions.

mapsam commented 9 years ago

Good questions. Those two scenarios seem to cover most of it. We should probably ask the same about #135 as well.

Fine by me starting with one service per user!

mapsam commented 9 years ago

There's also an option to not create full-fledged user pages, and just show users with their contact information in the service overview pages. Right now there isn't much information for a single user to warrant a full page.

I've put a list of related users on service pages already, which we could flesh out.

screen shot 2015-05-27 at 9 21 54 am

mapsam commented 9 years ago

I added a quick style update to the user pages, since they were completely borked when testing with Access Now. I'm still not sold on the need for user-specific pages at this point, but they exist and don't look like crap :+1: