Open mmurthydol opened 7 years ago
DOL design template and sample application have been sent to the 18F team.
the Web guideline: Here is a link to the template files http://dolcontentdev.opadev.dol.gov/homepage/agency-template/DOL-Agency-Template-with-2ndLevel.zip Sample application - http://savingmatters.opadev.dol.gov/ or http://savingmatters.dol.gov/
@oghaffari @phirefly @EStriegel @binwang89 @mgwalker : A) Updated the issue with OPA requirements after DIT meeting with OPA. This should help the vendor scope out the work. B) TODO: (1) & (2) needs Ux redesign. Whoever is responsible for Ux redesign is where the TODO needs to be captured. Ideally available before the vendor is on board.
I'd like to flag this one for conversation sometime when we're on a chat, not because I disagree with it or anything, but just because I'd like to reframe it in terms of its value for users. I don't think that will be hard to do (consistency across DOL apps, apply DOL's existing body of knowledge on accessibility, etc.) but I think it would be good to always frame these issues with respect to users, rather than just about conforming to policies. After all, if a policy doesn't serve a user need, then it might be useful to discuss changing the policy. :)
Sure Greg :) Not sure that the user cares about DOL requirements per say. We can wordsmith to say "As a user I would like a consistent look and feel across all DOL applications" - this is strictly not true though for most employers/users of 14C. Also, users might want to feel comfortable that they have reached an official site (DOL standard headers/footers)
Not sure how some of these mandated requirements can be fit in to a classic Agile "user" value paradigm. It's not like we can negotiate this requirement out. Having said that, am on the same page with the spirit of whatever we do must add value to the end user & to be cognizant of changing requirements when they can be avoided from a user perspective.
I agree, the user isn't going to care about the DOL requirements. But, consistency across a suite of applications is valuable to users. Once they know how to get around on one app, they have a better sense of how to navigate the others as well. But I like your second part a LOT, about users knowing they have reached an official site.
On the second point, if a requirement does not add user value, then it absolutely should be negotiated. While I think there's a user value argument for this requirement, in general, we should all be willing to escalate and discuss the purpose of requirements that don't have a user impact. Ultimately the application users are the most important stakeholders in the whole thing, and if we can't frame a requirement in terms of their needs, then we should seriously question why we have to do it.
But that last part is neither here nor there, in this case, because I think you've already articulated a real user value. 😉 This is kind of a soapbox issue for me, so I apologize for going on and on about it. The expression "that's just the way it is" from higher level folks always ticks me off. I feel strongly about challenging policies that don't clearly benefit users - either the policymakers need to explain the value, or they should reconsider the policy.
@Greg, Rest assured we do our due diligence from the user perspective & on requirement bloat. This requirement is non-negotiable. In a product there will be some enterprise considerations like this one, that can be verbalized from a user perspective. Absolutely welcome to wordsmith them as long as the requirements are met. There is very little value added to the user preaching to choir :)
This story requirements are met for milestone 1 with #292 latest comments are implemented completely.
DOL Web applications must conform to DOL Web UI artifacts/template requirements. These artifacts include form artifacts, CSS/IMG files.
Requirements as known at this time (css & related artifacts to be provided after NDA) : 1) All web pages need the DOL standard header/footer. 2) All web pages need to support bread crumbs. 3) Web application needs to support DOL provided "Foundation" CSS files. <-- Current implementation will provide similar look but will not support Foundation CSS. All the above functionality needs to be verified for supported browsers/devices as required.
Vendor to confirm requirements prior to working on this issue.