From d6b260f7777a20f4f73c05732323682c5112ac07 Mon Sep 17 00:00:00 2001 From: Charles Worthignton Date: Mon, 24 Aug 2015 14:25:04 -0400 Subject: [PATCH] finish updates to typography --- _plays/01.md | 4 ++-- _plays/02.md | 4 ++-- _plays/03.md | 4 ++-- _plays/04.md | 4 ++-- _plays/05.md | 4 ++-- _plays/06.md | 4 ++-- _plays/07.md | 2 +- _plays/08.md | 4 ++-- _plays/09.md | 4 ++-- _plays/10.md | 4 ++-- _plays/11.md | 4 ++-- _plays/12.md | 4 ++-- _plays/13.md | 4 ++-- assets/_sass/styles.scss | 51 ++++++++++++++++++---------------------- index.html | 6 ++--- 15 files changed, 51 insertions(+), 56 deletions(-) diff --git a/_plays/01.md b/_plays/01.md index f20f25a0..4a26e1f0 100644 --- a/_plays/01.md +++ b/_plays/01.md @@ -5,7 +5,7 @@ title: Understand what people need We must begin digital projects by exploring and pinpointing the needs of the people who will use the service, and the ways the service will fit into their lives. Whether the users are members of the public or government employees, policy makers must include real people in their design process from the beginning. The needs of people — not constraints of government structures or silos — should inform technical and design decisions. We need to continually test the products we build with real people to keep us honest about what is important. -#### checklist +### checklist 1. Early in the project, spend time with current and prospective users of the service 2. Use a range of qualitative and quantitative research methods to determine people’s goals, needs, and behaviors; be thoughtful about the time spent 3. Test prototypes of solutions with real people, in the field if possible @@ -14,7 +14,7 @@ We must begin digital projects by exploring and pinpointing the needs of the peo 6. Create a prioritized list of tasks the user is trying to accomplish, also known as "user stories" 7. As the digital service is being built, regularly test it with potential users to ensure it meets people’s needs -#### key questions +### key questions - Who are your primary users? - What user needs will this service address? - Why does the user want or need this service? diff --git a/_plays/02.md b/_plays/02.md index 44abf625..1004bb91 100644 --- a/_plays/02.md +++ b/_plays/02.md @@ -5,14 +5,14 @@ title: Address the whole experience, from start to finish We need to understand the different ways people will interact with our services, including the actions they take online, through a mobile application, on a phone, or in person. Every encounter — whether it's online or offline — should move the user closer towards their goal. -#### checklist +### checklist 1. Understand the different points at which people will interact with the service – both online and in person 2. Identify pain points in the current way users interact with the service, and prioritize these according to user needs 3. Design the digital parts of the service so that they are integrated with the offline touch points people use to interact with the service 4. Develop metrics that will measure how well the service is meeting user needs at each step of the service -#### key questions +### key questions - What are the different ways (both online and offline) that people currently accomplish the task the digital service is designed to help with? - Where are user pain points in the current way people accomplish the task? - Where does this specific project fit into the larger way people currently obtain the service being offered? diff --git a/_plays/03.md b/_plays/03.md index dd0ea01c..5730d417 100644 --- a/_plays/03.md +++ b/_plays/03.md @@ -5,7 +5,7 @@ title: Make it simple and intuitive Using a government service shouldn’t be stressful, confusing, or daunting. It’s our job to build services that are simple and intuitive enough that users succeed the first time, unaided. -#### checklist +### checklist 1. Create or use an existing, simple, and flexible design style guide for the service 2. Use the design style guide consistently for related digital services 3. Give users clear information about where they are in each step of the process @@ -14,7 +14,7 @@ Using a government service shouldn’t be stressful, confusing, or daunting. It 6. Use language that is familiar to the user and easy to understand 7. Use language and design consistently throughout the service, including online and offline touch points -#### key questions +### key questions - What primary tasks are the user trying to accomplish? - Is the language as plain and universal as possible? - What languages is your service offered in? diff --git a/_plays/04.md b/_plays/04.md index fd0c4c7c..5848736b 100644 --- a/_plays/04.md +++ b/_plays/04.md @@ -5,7 +5,7 @@ title: Build the service using agile and iterative practices We should use an incremental, fast-paced style of software development to reduce the risk of failure. We want to get working software into users’ hands as early as possible to give the design and development team opportunities to adjust based on user feedback about the service. A critical capability is being able to automatically test and deploy the service so that new features can be added often and be put into production easily. -#### checklist +### checklist 1. Ship a functioning “minimum viable product” (MVP) that solves a core user need as soon as possible, no longer than three months from the beginning of the project, using a “beta” or “test” period if needed 2. Run usability tests frequently to see how well the service works and identify improvements that should be made 3. Ensure the individuals building the service communicate closely using techniques such as launch meetings, war rooms, daily standups, and team chat tools @@ -17,7 +17,7 @@ We should use an incremental, fast-paced style of software development to reduce 9. Use code reviews to ensure quality -#### key questions +### key questions - How long did it take to ship the MVP? If it hasn't shipped yet, when will it? - How long does it take for a production deployment? - How many days or weeks are in each iteration/sprint? diff --git a/_plays/05.md b/_plays/05.md index 43d84fef..93e6ea1c 100644 --- a/_plays/05.md +++ b/_plays/05.md @@ -7,7 +7,7 @@ To improve our chances of success when contracting out development work, we need [The TechFAR Handbook](https://playbook.cio.gov/techfar/) provides a detailed explanation of the flexibilities in the Federal Acquisition Regulation (FAR) that can help agencies implement this play. -#### checklist +### checklist 1. Budget includes research, discovery, and prototyping activities 2. Contract is structured to request frequent deliverables, not multi-month milestones 3. Contract is structured to hold vendors accountable to deliverables @@ -18,7 +18,7 @@ To improve our chances of success when contracting out development work, we need 8. Contract specifies a warranty period where defects uncovered by the public are addressed by the vendor at no additional cost to the government 9. Contract includes a transition of services period and transition-out plan -#### key questions +### key questions - What is the scope of the project? What are the key deliverables? - What are the milestones? How frequent are they? - What are the performance metrics defined in the contract (e.g., response time, system uptime, time period to address priority issues)? \ No newline at end of file diff --git a/_plays/06.md b/_plays/06.md index 50e6236c..e6b70bae 100644 --- a/_plays/06.md +++ b/_plays/06.md @@ -5,14 +5,14 @@ title: Assign one leader and hold that person accountable There must be a single product owner who has the authority and responsibility to assign tasks and work elements; make business, product, and technical decisions; and be accountable for the success or failure of the overall service. This product owner is ultimately responsible for how well the service meets needs of its users, which is how a service should be evaluated. The product owner is responsible for ensuring that features are built and managing the feature and bug backlogs. -#### checklist +### checklist 1. A product owner has been identified 2. All stakeholders agree that the product owner has the authority to assign tasks and make decisions about features and technical implementation details 3. The product owner has a product management background with technical experience to assess alternatives and weigh tradeoffs 4. The product owner has a work plan that includes budget estimates and identifies funding sources 5. The product owner has a strong relationship with the contracting officer -#### key questions +### key questions - Who is the product owner? - What organizational changes have been made to ensure the product owner has sufficient authority over and support for the project? - What does it take for the product owner to add or remove a feature from the service? diff --git a/_plays/07.md b/_plays/07.md index 17f9f388..69c2901d 100644 --- a/_plays/07.md +++ b/_plays/07.md @@ -5,7 +5,7 @@ title: Bring in experienced teams We need talented people working in government who have experience creating modern digital services. This includes bringing in seasoned product managers, engineers, and designers. When outside help is needed, our teams should work with contracting officers who understand how to evaluate third-party technical competency so our teams can be paired with contractors who are good at both building and delivering effective digital services. The makeup and experience requirements of the team will vary depending on the scope of the project. -#### checklist +### checklist 1. Member(s) of the team have experience building popular, high-traffic digital services 2. Member(s) of the team have experience designing mobile and web applications 3. Member(s) of the team have experience using automated testing frameworks diff --git a/_plays/08.md b/_plays/08.md index 0b0aef51..5a957fa5 100644 --- a/_plays/08.md +++ b/_plays/08.md @@ -5,13 +5,13 @@ title: Choose a modern technology stack The technology decisions we make need to enable development teams to work efficiently and enable services to scale easily and cost-effectively. Our choices for hosting infrastructure, databases, software frameworks, programming languages and the rest of the technology stack should seek to avoid vendor lock-in and match what successful modern consumer and enterprise software companies would choose today. In particular, digital services teams should consider using open source, cloud-based, and commodity solutions across the technology stack, because of their widespread adoption and support by successful consumer and enterprise technology companies in the private sector. -#### checklist +### checklist 1. Choose software frameworks that are commonly used by private-sector companies creating similar services 2. Whenever possible, ensure that software can be deployed on a variety of commodity hardware types 3. Ensure that each project has clear, understandable instructions for setting up a local development environment, and that team members can be quickly added or removed from projects 4. [Consider open source software solutions](http://www.whitehouse.gov/sites/default/files/omb/assets/egov_docs/memotociostechnologyneutrality.pdf) at every layer of the stack -#### key questions +### key questions - What is your development stack and why did you choose it? - Which databases are you using and why did you choose them? - How long does it take for a new team member to start developing? \ No newline at end of file diff --git a/_plays/09.md b/_plays/09.md index db3b9c70..fabd7c59 100644 --- a/_plays/09.md +++ b/_plays/09.md @@ -5,7 +5,7 @@ title: Deploy in a flexible hosting environment Our services should be deployed on flexible infrastructure, where resources can be provisioned in real-time to meet spikes traffic and user demand. Our digital services are crippled when we host them in data centers that market themselves as “cloud hosting” but require us to manage and maintain hardware directly. This outdated practice wastes time, weakens our disaster recovery plans, and results in significantly higher costs. -#### checklist +### checklist 1. Resources are provisioned on demand 2. Resources scale based on real-time user demand 3. Resources are provisioned through an API @@ -14,7 +14,7 @@ Our services should be deployed on flexible infrastructure, where resources can 6. Static assets are served through a content delivery network 7. Application is hosted on commodity hardware -#### key questions +### key questions - Where is your service hosted? - What hardware does your service use to run? - What is the demand or usage pattern for your service? diff --git a/_plays/10.md b/_plays/10.md index bc234fa1..f33fb0dc 100644 --- a/_plays/10.md +++ b/_plays/10.md @@ -5,7 +5,7 @@ title: Automate testing and deployments Today, developers write automated scripts that can verify thousands of scenarios in minutes and then deploy updated code into production environments multiple times a day. They use automated performance tests which simulate surges in traffic to identify performance bottlenecks. While manual tests and quality assurance are still necessary, automated tests provide consistent and reliable protection against unintentional regressions, and make it possible for developers to confidently release frequent updates to the service. -#### checklist +### checklist 1. Create automated tests that verify all user-facing functionality 2. Create unit and integration tests to verify modules and components 3. Run tests automatically as part of the build process @@ -13,7 +13,7 @@ Today, developers write automated scripts that can verify thousands of scenarios 5. Conduct load and performance tests at regular intervals, including before public launch -#### key questions +### key questions - What percentage of the code base is covered by automated tests? - How long does it take to build, test, and deploy a typical bug fix? - How long does it take to build, test, and deploy a new feature into production? diff --git a/_plays/11.md b/_plays/11.md index 29e817be..cf601a23 100644 --- a/_plays/11.md +++ b/_plays/11.md @@ -7,7 +7,7 @@ Our digital services have to protect sensitive information and keep systems secu The following checklist provides a starting point, but teams should work closely with their privacy specialist and security engineer to meet the needs of the specific service. -#### checklist +### checklist 1. Contact the appropriate privacy or legal officer of the department or agency to determine whether a System of Records Notice (SORN), Privacy Impact Assessment, or other review should be conducted 2. Determine, in consultation with a records officer, what data is collected and why, how it is used or shared, how it is stored and secured, and how long it is kept 3. Determine, in consultation with a privacy specialist, whether and how users are notified about how personal information is collected and used, including whether a privacy policy is needed and where it should appear, and how users will be notified in the event of a security breach @@ -15,7 +15,7 @@ The following checklist provides a starting point, but teams should work closely 5. “Pre-certify” the hosting infrastructure used for the project using FedRAMP 6. Use deployment scripts to ensure configuration of production environment remains consistent and controllable -#### key questions +### key questions - Does the service collect personal information from the user? How is the user notified of this collection? - Does it collect more information than necessary? Could the data be used in ways an average user wouldn't expect? - How does a user access, correct, delete, or remove personal information? diff --git a/_plays/12.md b/_plays/12.md index 99998815..f32573e4 100644 --- a/_plays/12.md +++ b/_plays/12.md @@ -5,7 +5,7 @@ title: Use data to drive decisions At every stage of a project, we should measure how well our service is working for our users. This includes measuring how well a system performs and how people are interacting with it in real-time. Our teams and agency leadership should carefully watch these metrics to find issues and identify which bug fixes and improvements should be prioritized. Along with monitoring tools, a feedback mechanism should be in place for people to report issues directly. -#### checklist +### checklist 1. Monitor system-level resource utilization in real time 2. Monitor system performance in real-time (e.g. response time, latency, throughput, and error rates) 3. Ensure monitoring can measure median, 95th percentile, and 98th percentile performance @@ -16,7 +16,7 @@ At every stage of a project, we should measure how well our service is working f 8. Use an experimentation tool that supports multivariate testing in production -#### key questions +### key questions - What are the key metrics for the service? - How have these metrics performed over the life of the service? - Which system monitoring tools are in place? diff --git a/_plays/13.md b/_plays/13.md index 30828fed..bcc6a09b 100644 --- a/_plays/13.md +++ b/_plays/13.md @@ -5,7 +5,7 @@ title: Default to open When we collaborate in the open and publish our data publicly, we can improve Government together. By building services more openly and publishing open data, we simplify the public’s access to government services and information, allow the public to contribute easily, and enable reuse by entrepreneurs, nonprofits, other agencies, and the public. -#### checklist +### checklist 1. Offer users a mechanism to report bugs and issues, and be responsive to these reports 2. Provide datasets to the public, in their entirety, through bulk downloads and APIs (application programming interfaces) 3. Ensure that data from the service is explicitly in the public domain, and that rights are waived globally via an international public domain dedication, such as the “Creative Commons Zero” waiver @@ -16,7 +16,7 @@ When we collaborate in the open and publish our data publicly, we can improve Go 8. When appropriate, publish source code of projects or components online 9. When appropriate, share your development process and progress publicly -#### key questions +### key questions - How are you collecting user feedback for bugs and issues? - If there is an API, what capabilities does it provide? Who uses it? How is it documented? - If the codebase has not been released under an open source license, explain why. diff --git a/assets/_sass/styles.scss b/assets/_sass/styles.scss index c8e43b69..3a6286f6 100644 --- a/assets/_sass/styles.scss +++ b/assets/_sass/styles.scss @@ -79,14 +79,13 @@ $slimmer: new-breakpoint(min-width 641px max-width 980px 12); h2.display { font-family: $serif; - font-size: 54px; - line-height: 65px; + font-size: 40px; + line-height: 1.375em; font-weight: 300; margin-top: 0; color: $black; @include media($mobile) { font-size: 32px; - line-height: 42px; } } @@ -98,21 +97,26 @@ $slimmer: new-breakpoint(min-width 641px max-width 980px 12); h4 { font-family: $serif; - font-size: 18px; + font-size: 17px; + font-weight: 700; + line-height: 1.375em; color: $miami_vice_blue; margin-bottom: 0; } - h5 { + h6 { font-family: $sans-serif; - font-size: 14px; + font-size: 13px; + font-weight: 400; + line-height: 1.375em; margin-bottom: 15px; - color: $black; - font-weight: lighter; } p { color: $black; + font-weight: 400; + font-size: 17px; + line-height: 1.375em; } .outer_container { @@ -240,22 +244,20 @@ $slimmer: new-breakpoint(min-width 641px max-width 980px 12); height: 0; background: $atlantic_blue; color: $white; - font-family: $serif; .outer_container { padding: 0 40px; } - h4 { + h3 { padding: 20px 0; margin-top: 0; - font-size: 20px; + // font-size: 20px; color: $white; - font-weight: lighter; - line-height: 20px; + // line-height: 20px; display: inline-block; } - h4:hover { + h3:hover { text-decoration: underline; } @@ -322,7 +324,7 @@ $slimmer: new-breakpoint(min-width 641px max-width 980px 12); .outer_container { padding: 0 20px; } - h4 { + h3 { font-size: 16px; padding: 16px 0; line-height: 16px; @@ -443,11 +445,11 @@ $slimmer: new-breakpoint(min-width 641px max-width 980px 12); } #plays, #techfar { - h2, h4 { + h2, h3 { @include span-columns(8); } - h4 { - margin-top: 0px; + h3 { + // margin-top: 0px; color: $atlantic_blue; } @@ -455,10 +457,6 @@ $slimmer: new-breakpoint(min-width 641px max-width 980px 12); margin-bottom: 24px; } - h5 { - font-size: 14px; - } - p { @include span-columns(9); } @@ -475,9 +473,8 @@ $slimmer: new-breakpoint(min-width 641px max-width 980px 12); } li { - font-size: 15px; - line-height: 25px; padding-left: 5px; + font-size: 17px; } ul { @@ -486,14 +483,12 @@ $slimmer: new-breakpoint(min-width 641px max-width 980px 12); a { color: $atlantic_blue; - // border-bottom: 1px solid $atlantic_blue; text-decoration: underline; display: inline-block; } a:hover { color: $white; - // border-bottom: 1px solid $white; background: $atlantic_blue; } @@ -507,13 +502,13 @@ $slimmer: new-breakpoint(min-width 641px max-width 980px 12); line-height: 20px; } - h2, h4, p, ol, ul { + h2, h3, p, ol, ul { @include span-columns(4); } } @include media($slimmer) { - h2, h4 { + h2, h3 { @include span-columns(9); } p { diff --git a/index.html b/index.html index e88527f8..18db1e00 100644 --- a/index.html +++ b/index.html @@ -17,7 +17,7 @@
-

U.S. Digital Services Playbook

 +

U.S. Digital Services Playbook
    {% for play in site.plays %}
  • {{ play.id }}
    • @@ -69,8 +69,8 @@

    Digital Service Plays

    {% for play in site.plays %}
    -
    PLAY {{ play.id }}
    -

    {{ play.title }}

    +
    PLAY {{ play.id }}
    +

    {{ play.title }}

    {{ play.output }}