Hi Rich, Thanks for the feedback. Comments inline…
On 2013-04-16, at 10:31 AM, Richard Schwerdtfeger <[email protected]> wrote: > You need to define "Inversion of Control Philosophy" in the first section. > You provide a link to Fluid's Infusion but the page says nothing about it. Thanks. I've added an extra sentence or two about this directly in the document. I don't want to go into too much technical detail in the context of this report; the citation I included here points to a paper that elaborates the approach for those who want more information. > The security and and privacy section says nothing about meeting U.S. Federal > requirements for security or privacy. Is OAuth adequate? You may not know but > I think it should be the intent to meet U.S. Federal requirements. Given that this project is a) focused on delivering a prototype and b) is global in scope, I'm not comfortable committing to meeting U.S. regulations specifically. I added a sentence about how the architecture is "intended to support diverse privacy and security requirements internationally." Seem like a reasonable approach? > The document should also say something about how preferences are defined. > They are not defined in terms of medical disabilities but rather functional > limitations which could be cause by something as basic as a low light > conditions when using a mobile device. This ties back to the main document > goals. Good point. I added a small section about this. > Persistence information: Preference should NOT be communicated in a "cookie". > This is a privacy issue as these preferences flow over the network and can be > monitored. If we had to store domain-specific preferences I would recommend > at least storing them in HTML5 local data storage, Due to same origin policy restrictions, preferences will have to flow from server to client and client to server whenever we're storing preferences in the GPII preferences server. The key point in this section of the document is that developers have control over which persistence strategy is most appropriate for their application or context. For example, sites that support older versions of IE (sadly still widely used in government and banks for example) will not be able to use local data storage. From an architectural perspective, developers need flexibility and choice. That said, I don't see any reason not to also offer a local data storage DataStore implementation. The default persistence store will be the GPII preferences server. > Regarding the name "captions": The proper name should be subtitles. This is > what they will be called in Indie UI and it is also the name used for the > HTML5 video track element that exposes them. We are going to go back and > change AccessForAll V3 for this. This is a good way to start a flame war in the deaf community. Many people argue that there is an important distinction between between captions and subtitles. The issue is partly functional, partly ideological, and partly cultural. I changed references in the document to "captions and subtitles" to avoid the terminology debate. > Somewhere in here we need to specify how the user gets specific AT tools they > need - such as a plug-in. For example, a key part of our solution must > address Math Comprehension. This will require, at least in the near term, > plug-ins like Math Player. > > What we have here is heavily browser dependent. We need to specify why > specific browser levels are necessary. Such as: > > ARIA Support > CSS2+ Support > HTML5 and HTML5 Canvas support I agree that we need to do this as part of the prototype when we are addressing particular implementation requirements. I expect it will be on an Enactor-by-Enactor basis (e.g. many of the current UI Options Enactors currently work just fine on IE 6, while more sophisticated ones will require modern browsers.) I don't want to narrow requirements down too early in the architecture phase. Thanks again for all your suggestions, Colin --- Colin Clark Lead Software Architect, Inclusive Design Research Centre, OCAD University http://inclusivedesign.ca _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
