v2 design review

[alanjosephwilliams]

Description

Conduct a design review of the v1 demo. In particular, evaluate form design and offer suggestions for v2 and v3.

To-do

• [x] Deploy calffresh-and-so-clean
• [ ] Design review itself, with screenshots and notes
• [ ] Draft 1 pager of recommendations for v2 and v3

[alanjosephwilliams]

Quick cross-browser testing of my deployment using Browserling, 5/11/2014:

• App does not load on IE9
• Does not load on Firefox < v.18.0
• Does not load on Chrome < v.12.0
• Loads on all available version of Safari (4.0+)

[lippytak]

:(!

While you're on it would be good to test some mobile options, too. We did our demo last week on an iPhone and it sounded like small tablets would be a good size for on-the-move intermediaries.

On Sun, May 11, 2014 at 8:58 PM, alanjosephwilliams < notifications@github.com> wrote:

Quick cross-browser testing using Browserling, 5/11/2014:

• Does not load on IE9
• Does not load on Firefox < v 18.0
• Does not load on Chrome < v 12.0
• Loads on all available version of Safari (4.0+)

— Reply to this email directly or view it on GitHubhttps://github.com/daguar/calfresh-and-so-clean/issues/40#issuecomment-42794376 .

[alanjosephwilliams]

Those are significantly older version of Firefox and Chrome. IE 9 is the point of failure worth considering.

Will definitely conduct a cursory test of devices with the demo/v1. Everything worked on iOS 7/iPhone 5 & iOS 7/iPhone 5s. I'll take a look on the iPad 3 this evening. I'll also include these devices in the design review.

[daguar]

Awesome (well, not awesome, but pretty awesome to have known failures rather than unknown ones).

We're using Bootstrap's straightforward mobile media queries, so I imagine there's a standard workaround. Alan, if you want to take a look, this is contained in views/layout.erb.

That said, probably good to drive priorities on the browser/device front by what we see among the direct clients and the intermediaries.

On May 12, 2014, at 9:25 AM, alanjosephwilliams notifications@github.com wrote:

Those are significantly older version of Firefox and Chrome. IE 9 is the point of failure worth considering.

Will definitely conduct a cursory test of devices with the demo/v1. Everything worked on iOS 7/iPhone 5 & iOS 7/iPhone 5s. I'll take a look on the iPad 3 this evening. I'll also include these devices in the design review.

— Reply to this email directly or view it on GitHub.

[alanjosephwilliams]

Agreed on the first and last points.

Unclear to what you are referring with regard to media query workarounds.

[daguar]

What I was thinking is that, for vanilla Bootstrap like were using, I'm pretty sure there are straightforward workarounds for most issues in IE 8-9.

Looking at the Bootstrap site's Getting Started section, they use HTML5 Shim and Respond.js for older IE:

    <!-- HTML5 Shim and Respond.js IE8 support of HTML5 elements and media queries -->
    <!-- WARNING: Respond.js doesn't work if you view the page via file:// -->
    <!--[if lt IE 9]>
      <script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
      <script src="https://oss.maxcdn.com/libs/respond.js/1.4.2/respond.min.js"></script>
    <![endif]-->

And some online resources suggest changing if lt IE 9 to if lte IE 9 (as in, use these JS libraries in IE 9 too, not just versions < 9).

I wanted to try and implement these, and as a starting point threw the calfresh-alpha deploy at Browserstack, and that current site actually seems to work in both IE 8 and 9:

Either way, I'm going to quickly add those recommended Bootstrap lines, fork, and throw up on Heroku for testing purposes.

[daguar]

I've added those lines on the add-support-for-ie branch and deployed to:

https://calfresh-add-support-for-ie.herokuapp.com/

Alan - Want to let me know if that resolves it?

[alanjosephwilliams]

:thumbsup:

[daguar]

Sweet - @alanjosephwilliams, can you run https://calfresh-add-support-for-ie.herokuapp.com/ on the same platforms as before and report back?

After the good-to-go signal, I'll merge into master.

[alanjosephwilliams]

@daguar we're operational on IE8 and IE9, as well as older version of Chrome and Firefox. There are definitely some design considerations to better accommodate the degradation, but it works!

[daguar]

Sweet, thanks!

Let's definitely catalog those browser-specific problems so that even if we don't attack them in this version, we know they're things to be aware of when there's bandwidth: I've opened an issue to do that here https://github.com/daguar/calfresh-and-so-clean/issues/42

On May 12, 2014, at 1:48 PM, alanjosephwilliams notifications@github.com wrote:

@daguar we're operational on IE8 and IE9, as well as older version of Chrome and Firefox. There are definitely some design considerations to better accommodate the degradation, but it works!

— Reply to this email directly or view it on GitHub.

[alanjosephwilliams]

Continuing to catalog issues and considerations in #42 .

I will build out this issue with photos and commentary tomorrow, but I am going to use it to outline finding of design review for now. If there anything that reflects a misunderstanding of the problem space, work done to date, or goals for v2, just let me know.

• Quick wins available with improved copywriting.
• Most substantial enhancement will be uploading of 1 - 3 verification docs.
• As a result, v2 design should be mobile first, desktop second. See #21 for thinking.
• Checkbox for waiver and plain english need to be included as well.
• Signature box needs be afforded more real estate or an easier interaction.
• Investigate both a single page scroll and tap-to-advance designs. Not sure which is cheaper from a dev perspective.

Not sure whether it is in the schedule to actually mock-up these designs. Let's discuss whether my time over the next couple of days is better spent here or on research into eligibility.

[lippytak]

• Agreed on copywriting. You're better at it so I'd like you to own it but no worries if you can't do that right now.
• I think you're probably right on the mobile first, desktop second conclusion, but I'm a bit more hesitant. I wouldn't dedicate too much to this until we talk to the Food Bank outreach staff on Thurs and understand their context for enrollment. If clients are physically coming into the food bank (or community center, church, etc.), desktop may be P1. If verification docs are the issue, we could still use desktop cameras for that.
• Signature box kinda sucks :(. However, we don't know if it's required quite yet (CalWIN just makes you check a box and type your name) so we should chat with a lawyer before devoting much time to improve it.

I would prioritize research over mockups right now because we don't know what we're building until we talk to users (hopefully tomorrow!) but we DO know that we need to find our target population.

[alanjosephwilliams]

Great feedback---very much in-line with where @daguar and I landed. I'll hold off on this vector of work until after you synthesize your experience with the folks at the Food Bank.

[alanjosephwilliams]

Probably doesn't improve usability too much, since uploading images with backwards writing feels wrong and confusing, but we could always flip the photos on our end.

[alanjosephwilliams]

Food Bank Assisted Application Workflow

Synthesized and excerpted from raw meeting notes (much more there, it's a great research asset) https://docs.google.com/a/codeforamerica.org/document/d/1OMHwsQPykIVtArXPBx2RUQ-uSZWUrhrPkbvJrbRurAQ/edit?disco=AAAAAKL4dnQ

The mission of the Food Bank of San Francisco and Marin is to reduce food insecurity. As such, they have long been receiving funding form nutrition assistance programs to help intake and enroll assistance recipients.

The intake process is conducted via a hub-and-spoke partnership with FBoSFM supplied food pantries across the city.

These food pantries (and other CBOs) serve as initial points of contact with unassisted citizens. The staff at these CBOs refer citizens to FBoSFM social workers (often through a google doc) phone screen. During that 10 minute phone screen, social workers at FBoSFM headquarters enter the citizen information into their Excel-based "CRM".

Based on the screener's judgement, citizens then schedule in-person appointments with a FBoSFM social worker. The screener talks through all of the documents that need to be collected by the citizen, and brought to the in-person meeting. FBoSFM donuts about 22 site visits a month to conduct these appointments, and each appointment takes about 45 minutes.

The in-person meeting typically takes place at the same place where initial contact with the citizen was made--one of many partner food pantries--so that the citizens does not have to take on the burden of transportation. Even then, there is a 20% no show rate.

During these in-person meetings, the social worker and the citizen "pair" to go through and complete the CalWin Application, answering questions and uploading required documents. This is typically done using a Windows NT tablet, using the built-in camera to upload documents, while an external keyboard is typically utilized to complete forms.

To successfully submit at an application, very the following information is needed:

Name

Gender

Address

Social Security Number self-verification accepted no digital signature required

Identification Document must be scanned or photographed

Income self-verification accepted digital signature accepted

Expenses self-verification accepted digital signature accepted specifically:

• Rent
• Utilities

Once initial app is submitted, CBO staff cannot log back in and change anything or add verification documents. They have one chance to get everything in.

An application missing a verification document triggers of mail-based resolution process. The citizen or client is then in a tricky position of needing to scan or mail missing documents. FBoSFM social workers will try to call HSA and determine what exactly is missing missing. This process is riddled with confusion and time lags.

When an application is received, it is processed through the "clearing team". The "clearing team" is composed of perhaps over a hundred City of San Francisco HSA employees. Their role is to determine eligibility for nutrition assistance. One eligibility is determined, the clearing team forwards the application to a smaller group of HSA staff responsible for processing and approving applications.

After an application is submitted, FBoSFM social workers conduct intensive follow up with both the citizen and the agency's eligibility workers.

Design Constraints based on this workflow

• The audience is the "pair" of client and outreach worker.
• The outreach workers perspective should be reflected in the copywriting
• 6 required pieces of data, 4 attachments to upload
• Really three themes:
  • Identity (Name, SSN, Identification)
  • Contact (Address, phone and e-mail)
  • Financial (Income, Expenses: Rent & Utilities)
• It might be nice to treat the audience like the intelligent animals they are, and write a little copy about why each piece of information is important and useful.
• Some visual aids or iconography might help people understand what kind of documentation is desired and valid, particularly for financial matters.
• One signature should be valid to "self-validate" reported income and expenses