Engage: Code entry screen

[Colin Clark]

Hey Sveto,

Nice work! I'll merge Object Code Entry into trunk as soon as I can. We may have to wait until tomorrow--Yura has just imported all the new data from McCord, but it looks like the object codes are missing. We'll get that fixed and get the component integrated into the app.

On 2010-02-01, at 8:26 AM, Svetoslav Nedkov wrote:
>> * The number pad images are a bit pixellated. I've attached PNGs of the number pad sourced directly from the wirefreames to this JIRA: http://issues.fluidproject.org/browse/ENGAGE-305
>>  
> We are now using the new images, one thing I wondered about was that there was a transparent margin around each of them, so the obvious way to lay them out was to put a negative margin in the css to compensate those gaps. I reckon that this could be totally wrong.

I grabbed the images straight out of OmniGraffle, so they do have a slight border around each image. In the wireframes, it looks like there is a gap on all sides. Why do you need the negative margin?

I've copied James on this thread just in case he sees something I'm missing.

>> * I think the user experience would be improved if we wait a brief moment before redirecting to the ArtifactView page. At the moment, the user can't see the second digit before the page starts to reload. James, what do you think?
>>  
> I have added a delay of one second in the component options.

Cool, thanks.

>> * We probably have some accessibility work to do on this page. I did some quick testing with the iPhone Accessibility Inspector, but there's more testing to be done. Off the top of my head, I think we should:
>> 	- Make each number button a real button, or, if all else fails, give each number an ARIA button role
>>        - Improve the code display area--it might make sense as HTML input elements, or perhaps a live region? The core problem at the moment is that a non-sigted user will be unaware of the code display area when no digits have been entered.
>>  
> About the code display area Justin mentioned that we don't want the iPhone native keyboard to pop-up when on the code entry screen.
> I will do more tests and will make sure that those problems are resolved.

Yeah, I'm not fully convinced that input elements are the right solution, although there are lots of things we could do to prevent the iPhone keyboard from appearing if it turns out to be our best option. I'm curious to brainstorm this issue with Alison and Sam and others on the list to see if they have ideas.

You're probably eager to get back to My Collection, which is hot this week. The one other thing I thought of that we're missing for Object Code Entry is some unit tests. I'll try to put together a few when I commit the component, and then perhaps you can help to flesh them out?

Colin

---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org