<!--UX - Reboot
- Overview
- Intro & Summary
- Purpose
- Guiding Philosphy: Design Thinking
- UX Value
- UX in 2017
- UX = User Experience
- UX = User + UI
- Know The User
- Build The UI
- UX Cycle
- UX Phases
- I. Learn
- II. Design
- III. Build
- IV. Analyze
- V. Output
- UX Process
- UX Roles
- UX Deliverables
- UX - In Depth
- UX Core Values
- Phases vrs. Process (Phases describes point in product journey, whereas process is ongoing)
- Roles In A UX Team
- Project Manager
- User Researcher
- Content Strategist
- Information Architect
- Interaction Designer
- Visual Designer
- Prototyper
- Front-end Coder
- Usability Expert
- System / Business Analyst
- Development
- UX Deliverables
- I. Learn
- Stakeholder Interview
- User Interviews
- User Personas
- User Scenarios
- Content
- UX Objectives
- II. Design
- System Maps
- Wireframes
- Visual Appearance
- Modual Components
- Mockups
- Style Guide
- III. Build
- Code
- Materials
- Pages or Views
- UI Toolkit
- Prototype
- IV. Analyze
- A/B Testing
- User Surveys
- QA
- V. Output
- Backend Development
- Prod
- Documentation
- User Onboarding
- UX Audit
- UX Score
- Measured by UX Deliverables
- Project History Audit
- UX Skill Audit
- Audit Findings
- Outlook
- Biz Side: plans for annual income gain
- projection
- hiring: tiers, priorities
- culture shift
- new department & director
- management approach
(old)
- Solution
- Value
- New Plan
- UX Roles - Details
- UX Director
- UX Liaison
- UX Designer
- UX Analyst
- New Team
- Goals & Outlook
- Inner-Office Coordination
- Secondary
- Office
- Management Structure
--
Overview
- Intro & Summary
- Purpose
- Guiding Philosphy: Design Thinking
- UX Value
Intro & Summary
'UX'
These letters show up often in our industry, but what exactly do they mean, even? This guide is built as both an entry point and a user manual for applying UX throughout the entire website-creation process.
Purpose & Goals
Purpose
- Define the role of UX @ PAI
- Define the role of UX as it pertains to our stakeholders
Goals
- Define the role of UX in modern web development
- Demonstrate the value of UX
- Display an ideal UX model as applied to PAI's workflow
- Develop a system for measuring our UX capacity / output
- Analyze our past and current UX capacity / output
- Plan phased-in methods for integrating UX into our process
- Establish if there's a need for a UX Department
- Create an estimated Projection: analyze impact and value
Guiding Philosphy
The central philosophical idea that propels the UX process is Design Thinking.
I. What is Design Thinking?
II. How does it apply to eGovernment
I. What is Design Thinking?
Design Thinking is a problem-solving philosophy. It’s currently trending among company leaders and within the UX community.
Google Trends
"Results show that over the last 10 years design-led companies have maintained significant stock market advantage, outperforming the S&P by an extraordinary 228%.” (via DMI: Design Management Institute)
Design Thinking applies the user-centered, multifaceted thought process of modern designers and artists to non-design problems. This thought process has three main components:
redefine the problem - rather than jump to a solution, “take the original problem as a suggestion” then think broadly about the real underlying issues. In other words, challenge assumptions; question & investigate the conditions of a problem to find the root issue.
“Don’t try to search for a solution until [determining] the real problem.” (via “What Is Design Thinking And Why Is It So Popular")
human-centric perspective - (aka UX) - view the problem from the user’s perspective, and build the solution around this. This is a huge part of Design Thinking, as it applies context to the other parts of Design Thinking, identifies a target audience, provides a way to measure performance and judge a project’s output, and brings meaning to otherwise seemingly arbitrary designs.
test & verify everything - experiment, prototype, “try on for size” each solution, research, learn, play, poke & prod, and use real data to back your conclusions. This is an opportunity to revisit and redefine your own solution.
This breaks down into 5 non-sequential steps. (via “What Is Design Thinking And Why Is It So Popular")
- Empathise – with your users
- Define – your users’ needs, their problem, and your insights
- Ideate – by challenging assumptions and creating ideas for innovative solutions
- Prototype – to start creating solutions
- Test – solutions
"Think Different(ly)” an article from Zurb (i.e. the people that makes the popular framework Foundation), refers to it as “divergent thinking”, and uses Steve Jobs’ success with Apple to explain it’s advantages. It also brings up some of the challenges that comes with this approach:
- there tends to be two ways of viewing problems - critical, and creative; divergent thinking brings these two inherently different approaches together
- Creative thinking is unnatural to critical thinkers, which causes frustration for the critical thinker, and can create friction between the two thinking types.
- Further, since it doesn’t come naturally, it feels risky, and requires "the guts to breakout of conventional trends to design what is best for our customers.”(via "Think Different(ly)")
- The solution is culture. “Lead by design” - ie. Have empathy for coworkers, and create structures for people to work within.
"The success of the elite worker will depend upon that person's ability not to get things done, but to have breakthroughs'''to use access to knowledge and automation to deliver explosive ideas. To do that which only a human can do." David Cadaver
Examples of applying design thinking to concepts (all via "In Search Of The Ultimate User Experience”)
Products:
- While evaluating a product or service is subjective, defining the problem narrows this down to 2 things: utility & emotion.
"Utility and emotion are simple measures to evaluate any product on."
“Utility is mandatory...If a product passes the utility test, then it will elicit an appropriate emotional response.”
- Remember: "Forgettable experiences are forgotten products.”
Workplace:
“[The] workplace is a product. People spend most of their lives working, and this insight gave birth to the destination work experience.”
"We can create a better world faster through collaboration, open communication, and exposure to feedback and criticism. Makers understandably apply the user experience concept within their organizations. It’s a logical progression."
There are two primary strategies for doing that:
- Develop a strong workplace culture
- Get mission-driven
Overall Better World: "creating a better world begins with a single user who wants a solution to their problem—and it starts with your product or service. If your product is worthy, it spreads—first through communities (offline or online), then beyond borders to other countries and continents.”
II. So, how does this apply to eGovernment?
Define the Problem
It’s common for Krystal or the agencies to bring up problems by presenting a solution. Ideally, we’ll bring Krystal to the point where she’s coming to us with “I don’t feel like the logo text is visible enough” instead of “make the logo 200-400% larger”; until then, we should make a habit of asking or, at least, thinking first about the actual root problem.
Human-Centric Perspective
This is where UX, visual design, and accessibility come into play.
We aren’t just building products, especially since our product is digital, we’re building the experience the user has with the product. By thinking like the user, we can take as much pain as possible out of mundane online government forms and improve the overall clarity of the state’s online communication with its citizens (which corresponds nicely with the whole open data, government transparency thing).
"The human experience trumps everything, and a product or service that’s designed with a contextual view of someone’s life will dominate the marketplace.”
Challenges
A challenge for this perspective, especially for the eGovernment industry, is implementing improvements in a way that isn’t jarring for the user. According to Paul Rand, "The public is more familiar with bad design than good design. It is, in effect, conditioned to prefer bad design, because that is what it lives with.”
Precedence In Gov’t
It’s being implemented by gov.uk - ("User Centered Design”)
Philosophic Rationale
We’re empowering the user by giving them access to information, without interfering with the message; improving the experience for humans, instead of for politicians or bureaucrats or ourselves.
"We believe makers and users can aspire to something greater. The maker can create something profitable AND meaningful. The user can be a more conscientious consumer. Together, we can build remarkable things that does less harm and maximum good in the world."
I believe this is best explained by "In Search Of The Ultimate User Experience”:
“As the definition of a product evolves, so do its users. The empowered consumer shapes a product’s trajectory with reviews, online activism, customer feedback, and focus groups. The empowered user remains your traditional customer, but they’re also your employees, a city’s residents, and a political party’s constituents.
Users are slowly realizing they have power to change these institutions. This happens with big companies (Taylor Swift and Apple), the toppling of dictators (hello, Arab Spring), and influencing how big government operates (Obama’s geeks).
Forward-thinking makers are collaborating with their power users more and more on mutually beneficial projects. This exchange results in products and services that are not only relevant, but higher in quality.”
And for convenience here’s my references and a few other links I haven’t read yet, but look promising:
references
———————————————
- What Is Design Thinking And Why Is It So Popular
- Think Different(ly)
- In Search Of The Ultimate User Experience
- uk.gov - User Centered Design
- DMI: Design Management Institute
- Google Trends
additional info
———————————————
- How Design Thinking Improves the Creative Process | Stanford Graduate School of Business
- Intro to Design Thinking
- Why Human-Centered Design Matters | WIRED
- Design thinking - Wikipedia
- How to use design thinking in your next project
- Building a design-driven culture | McKinsey & Company
- Does Design Thinking Make Better Businesses? | Yale Insights
- 7 Do’s and Don’ts: The Latest Trends in Design Thinking - | PDAgroup
- New innovation trends: Design Thinking | Opinno - We deliver impact through innovation
UX Value
Value
TODO: Rephrase this around the Value UX brings in general, then the value I bring to facilitate this.
"There's probably nothing more frustrating to a UX designer than the feeling (or reality) that the value of one's discipline is constantly brought into question, and given lower priority to other business objectives.
In this situation, it is easy for the UX designer to feel that the end users are being neglected, and that the quality of the product or service will suffer due to neglect. It is also extremely difficult to debate your position without the support of the quantitative metrics used to argue for other business objectives—the same metrics that lowered UX priorities in the first place."
Communicating The UX Value Proposition
Value Diagram
The completed diagram provides a visual representation of:
- key business objectives
- how UX attributes relate to those objectives
- the current and desired state of success
- the activities that will be completed to meet those objectives.
Communicating The UX Value Proposition
- Identify key business objectives
- Identify the UX attributes that will influence the success (both directly and indirectly) of the key objectives and desired outcomes
At a minimum, the UX attributes that should be considered in a project include:
- Usability– How easy to understand and operate does the product need to be?
- Appeal– How professional does the product need to appear? How much does the audience need to enjoy using it?
- Accessibility– What audiences need to access the product? On which devices?
- Performance– How well does the application need to perform? How fast does it need to load and respond to input?
- User Assistance & Help– How easy does it need to be for the audience to get assistance when they get stuck?
Simple statements or descriptions of how these attributes influence the key objectives are sufficient.
- Identify the current success of these UX attributes - plot on a scale from poor (1) to excellent (5)
- Identify the desired state of these UX attributes - plot on a scale from poor (1) to excellent (5)
- Identify the activities and design work that can be done to improve the state of the UX
An important aspect to the success of any project is to obtain consensus with stakeholders on what it means to succeed, and how we will know if our UX work has been successful.
When the value proposition of UX is directly associated with key business objectives, it is much easier to have quality discussions about time and budget for UX activities. Helping your stakeholders understand how UX directly and indirectly influences their key business objectives allows you to focus more time on critical work and might help you increase the budgets and time you are allocated for UX initiatives.
Communicating The UX Value Proposition
Identify key business objectives
UX in 2017
- UX in 2017
- UX = User Experience
- UX = User + UI
- Know The User
- Build The UI
- UX Cycle
- UX Phases
- I. Learn
- II. Design
- III. Build
- IV. Analyze
- V. Output
- UX Process
- UX Roles
- UX Deliverables
- UX - In Depth
- UX Core Values
- Phases vrs. Process (Phases describes point in product journey, whereas process is ongoing)
- Roles In A UX Team
- Project Manager
- User Researcher
- Content Strategist
- Information Architect
- Interaction Designer
- Visual Designer
- Prototyper
- Front-end Coder
- Usability Expert
- System / Business Analyst
- Development
- UX Deliverables
- I. Learn
- Stakeholder Interview
- User Interviews
- User Personas
- User Scenarios
- Content
- UX Objectives
- II. Design
- System Maps
- Wireframes
- Visual Appearance
- Modual Components
- Mockups
- Style Guide
- III. Build
- Code
- Materials
- Pages or Views
- UI Toolkit
- Prototype
- IV. Analyze
- A/B Testing
- User Surveys
- QA
- V. Output
- Backend Development
- Prod
- Documentation
- User Onboarding
UX = User Experience
The User Experience (UX) is created when the user interacts with the user interface (UI).
By focusing first on understanding the user and his or her needs, we can focus design and development efforts directly around a measurable impact.
Build For Users
UX = User + UI
Understand The User
in order to
Build The UI
As you read this, UX is being generated as you interact and react to this document.
you (the user) + this document (the UI) = user experience
UX Cycle
- UX Phases
- UX Process
- UX Roles
- UX Deliverables
The UX Cycle encompases the entire scope of any given project, from inception to User On-Boarding.
It's broken down into phases, which describe steps of progress in the product's journey. Along each step of the phase, teams and UX roles will be building cyclically, using the UX Process, with many back-and-forth conversations between multiple team members.
UX Phases
- I. Learn
- II. Design
- III. Build
- IV. Analyze
- V. Output
This is what we know as the "Requirements Gathering" phase. It's the introduction to the subject for the entire team, and lays down the groundwork for the following phases. It's most important output are the UX Objectives.
The UX Objectives, in turn, empower design and development to build the UI.
- III. Build
- IV. Analyze
- V. Output
UX Process
Know The User
- Empathise
- Define
- Ideate
Build The UI
- Prototype
- Test
- Implement
UX Roles
Roles In A UX Team
- Project Manager
- User Researcher
- Content Strategist
- Information Architect
- Interaction Designer
- Visual Designer
- Prototyper
- Front-end Coder
- Usability Expert
- System / Business Analyst
- Development
Roles in a UX Team
The roles that encompass UX manifest throughout the website creation process. Meaning, it involves many people across multiple disciplines. Project Managers, Frontend Developers, Visual & Interactive Designers, Information Architecture, Prototyping, and other UX roles all contribute.
UX
- Project Manager
- User Researcher
- Content Strategist
- Information Architect
- Interaction Designer
- Visual Designer
- Prototyper
- Front-end Coder
- Usability Expert
- Online Marketer (unused in this model)
- System / Business Analyst
- Development
Role Descriptions
- Project Manager: focuses on planning, organising and controlling a project and its team—including UX-related activities;
- User Researcher: focuses on tasks such as conducting user interviews, interviews, behaviour analysis;
- Information Architect: focuses on tasks such as how to organise site content, how search should work, what labels to use on menus;
- Content Specialist: focuses on tasks such as copywriting, how to structure content to be deployed on different devices, microcopy on headings & buttons;
- Interaction Designer: focuses on tasks such as what screens should go where in an app, and how a user flows through them. Also transitions between screens, often inspired by real-world paradigms (page curls, sliding windows etc.);
- Visual Designer: focuses on typography, layout, colour, graphics, visual effects, imagery, texture, mood;
- Prototyper: creates working examples of visual & iteractive design's deliverables
- Front-end Coder: focuses on writing HTML, CSS, JavaScript code to implement a visual design; and
- Systems Analyst: analyzes systems.
- Business Analyst: Ensures UX Objectives align with Business Objectives
For reference, this table identifies where each UX role meets Teams (Departments and other UX Roles), Tools (Photoshop, frontend frameworks, etc.), and who would benefit the most by learning about that particular UX Role or process.
| Role |
Team |
Tool |
Teach |
| UX Designer |
| Interaction Designer |
UX Design |
xD, Sketch |
UX Design |
| Visual Designer |
UX Design |
xD, Ai, Ps, Strapless |
UX Design |
| Prototyper |
UX Design, UX Analyst, QA, Frontend Dev |
Strapless, Mockups to Krystal |
QA, Frontend Devs, UX Design |
| Frontend Coder |
UX Design, Information Architech, Content Strategist |
Strapless |
UX Design, Frontend Devs |
| UX Analyst |
| User Researcher |
UX Liaison, UX Analyst |
Strapless, Mockups |
Prototyper, Usability Expert |
PM, QA |
| Information Architect |
UX Design, UX Analyst, |
Strapless, Accessability, Semantics, HTML5 |
UX, Dev |
| Usability Expert |
Marketing, QA, UX Liaison |
Surveys, Online Surveys, "Was This Helpful", Strapless (demo sites) |
Marketing, QA |
| Content Strategist |
UX Design / UX Liaison + Partner |
Word, Google Docs, Text Editors |
UX Design, UX Liaison, Partner |
| System Analyst |
UX Analyst, UX Liaison |
Feedback, Google Analytics |
Directors, UX Liaison |
| Project Manager |
UX Liaison |
VSTS, Email, Slack, UX Pin, inVision, Trello, others |
UX, PM, Dev |
UX Deliverables
- I. Learn
- Stakeholder Interview
- User Interviews
- User Personas
- User Scenarios
- Content
- UX Objectives
- II. Design
- System Maps
- Wireframes
- Visual Appearance
- Modual Components
- Mockups
- Style Guide
- III. Build
- Code
- Materials
- Pages or Views
- UI Toolkit
- Prototype
- IV. Analyze
- A/B Testing
- User Surveys
- QA
- V. Output
- Backend Development
- Prod
- Documentation
- User Onboarding
UX Deliverables
UX - In Depth
UX Core Values
UX Central Goals
What UX Roles You Need and Why
- collaboration
- communication
- quality consensus
- operational excellence
- innovation
Communicating:
UX In Practice:
Challenges & Solutions other UX Professionals Have Used:
Phases vrs. Process (Phases describes point in product journey, whereas process is ongoing)
Roles In A UX Team
Process within Roles
Visual Designer
Interaction Designer
Integrate Motion Design Animation
- Project Manager
- User Researcher
- Content Strategist
- Information Architect
- Interaction Designer
- Visual Designer
- Prototyper
- Front-end Coder
- Usability Expert
- System / Business Analyst
- Development
PM
- Narrative Reports
- Presentations
- Plans
- Specifications
UX Deliverables
- I. Learn
- Stakeholder Interview
- User Interviews
- User Personas
- User Scenarios
- Content
- UX Objectives
- II. Design
- System Maps
- Wireframes
- Visual Appearance
- Modual Components
- Mockups
- Style Guide
- III. Build
- Code
- Materials
- Pages or Views
- UI Toolkit
- Prototype
- IV. Analyze
- A/B Testing
- User Surveys
- QA
- V. Output
- Backend Development
- Prod
- Documentation
- User Onboarding
Roles & UX Objectives
| Step |
Role |
UX Deliverable |
Deliverable To: |
| 1 |
Project Manager |
Narrative Reports, Presentations, Plans, Specifications |
Partner, All UX Roles |
| 2 |
User Researcher |
Users (User Personas, User Scenarios, User Surveys) |
Information Architect |
| 3 |
Content Strategist |
Content Inventories |
Information Architect |
| 4 |
Information Architect |
Flow (Concept Maps, System Maps, Process Flows), Design Patterns |
Visual Designer / Interactive Designer |
| 5 |
Visual Designer |
Mockups, Styleguide |
Interaction Designer, Prototyper |
| 6 |
Interaction Designer |
Mockups, Storyboard |
Prototyper |
| 7 |
Prototyper |
Prototype, Storyboard |
Usability Expert |
| 8 |
Usability Expert |
Prototype, Users, Analytics |
Frontend Coder |
| 9 |
Frontend Coder |
Implementation, Prototype, Specifications |
Implementation, Prototype: Dev Workflow; Specifications > PM |
| 10 |
System Analyst |
Analytics, Design Patterns |
Design Patterns > Information Architect; Analytics > User Researcher |
| 11 |
Business Analyst |
UX Objectives = Business Objectives |
PM, Inforamtion Architect, Systems Analyst |
UX Workflow
Process Flow
Requirments Gathering > User Personas > User Scenarios/Stories > UX Objectives > UX Process + Roles
UX Process (cycle)
- Learn / Research
- Build
- Plan: IA
- Design:
- Assemble: Materials
- Prototype
- Output
/dist/
- Styleguide
- Document
- Analyze
Communicate & Overview
| Step |
Role |
UX Deliverable |
Deliverable To: |
| 1 |
Project Manager |
Narrative Reports, Presentations, Plans, Specifications |
Partner, All UX Roles |
Core UX Process
1. Learn / Research
| Step |
Role |
UX Deliverable |
Deliverable To: |
| 2 |
User Researcher |
Users (User Personas, User Scenarios, User Surveys) |
Information Architect |
| 3 |
Content Strategist |
Content Inventories |
Information Architect |
2. Build
| Step |
Role |
UX Deliverable |
Deliverable To: |
| 4 |
Information Architect |
Flow (Concept Maps, System Maps, Process Flows) |
Visual Designer / Interactive Designer |
| 5 |
Visual Designer |
Mockups, Styleguide |
Interaction Designer, Prototyper |
| 6 |
Interaction Designer |
Mockups, Storyboard |
Prototyper |
3. Prototype
| Step |
Role |
UX Deliverable |
Deliverable To: |
| 7 |
Prototyper |
Prototype, Storyboard |
Usability Expert |
4. Output
| Step |
Role |
UX Deliverable |
Deliverable To: |
| 8 |
Usability Expert |
Prototype, Users, Analytics |
Frontend Coder |
| 9 |
Frontend Coder |
Implementation, Prototype, Specifications |
Implementation, Prototype: Dev Workflow; Specifications > PM |
5. Analysis
| Step |
Role |
UX Deliverable |
Deliverable To: |
| 10 |
System Analyst |
Analytics, Design Patterns |
Design Patterns > Information Architect; Analytics > User Researcher |
| 11 |
Business Analyst |
UX Objectives = Business Objectives |
PM, Inforamtion Architect, Systems Analyst |
Align With Strapless:
- Learn
- UX
- Best Practices
- Design System
- Code
- Build
- Input
- Styles
- Materials
- Data: YAML
- Handlebars.js
- Gulp
- UI Toolkit
- Toolkit Name
- Frontend Assets
- HTML, CSS, JS
- HTML: Materials
- Brand
- Style
- SASS
- Central Base
- Atomic Design
- Unified Variables
- Output
Learn / Research
- Users
- Personas
- Scenarios
- Stories
Personas
”Personas are your cast. User scenarios create the plot.”
User Personas
- What is their demographic information?
- What is their job and level of seniority?
- What does a day in their life look like?
- What are their pain points?
- What do you help them solve?
- What do they value most?
- What are their goals?
- Where do they go for information?
- What experience are they looking for when seeking out your products or services?
- What are their most common objections to your product or service?
via: Developing Personas
User Persona Scenarios
Scenarios add elasticity to personas by lling in the “why” behind the “who”.
- Ben Hunt, creator of Web Design From Scratch,
There are three main categories:
- goal-based scenarios
- elaborated scenarios
full task scenarios
create realistic goals for your personas.
Each user scenario starts with a user story, structured as:
“As a [role], [the persona] wants to [complete this action] so they can [ful ll this goal]”
"A user scenario will then expand upon user stories by including details about how your system could be interpreted, experienced, and used."
The persona’s environment — Where are they when they interact with your web site? Are they at work? At a coffee shop? Or at home?
- Any factors that impact the context of use — How fast and stable is their Internet connection? How much time do they have? What distractions are there?
- Triggering events & goals — What specific goal motivates the persona to interact with the web site on this occasion? What event triggered this scenario?
- Persona behavior — Visualize the scene. What considerations are most important in the persona’s mind? What clues are they looking for in particular?
(via Web UI Design Best Practices - ebook by UX Pin)
UX Objectives
- Rename?
- Composed of:
- UX Deliverable
- UX Attributes
- UX Central Goals
Build
Plan
- Flow
- Concept Maps
- System Maps
- Process Flows
Design
- Mockups: Also referred to as Concept Designs,
- Storyboard
Assemble
Prototype
Output
- Implementation
- Styleguide
Analysis
- Analytics
- Design Patterns
- UX Objectives = Business Objectoves
UX Audit
UX Score
Measured by UX Deliverables
Project History Audit
COPA Metrics:
- Frontend Framework: built using Foundation, with styles customized on top of Foundation's Pre-Compiled CSS.
- Styles: CSS, non-compiled. It was decided to code this using .css early on, which proved unmnagable by the end.
- Markup: Bulky, unsemantic (in order to use foundation, the markup doe not denote meaning on its own, and is mostly used for styling)
- CMS: Wordpress
- Lessons learned:
- coding in pure CSS is entirely too slow and cumbersome.
- Preserve code used to counter Foundation's boiled in styles.
- There was no guidelines or codebase to build from --- I needed to learn, decide, or build as I went.
- In the end, the project was a success.
PA.GOV:
- Frontend Framework: built using Foundation, customized on top of Foundation's Pre-Compiled CSS.
- Styles: SCSS, on top of the newest build of Foundation's Pre-Compiled CSS, with code brought over from COPA Metrics where appropriate and to counter Foundation's styles
- Markup: Cleaner, due to an effort to minimize markup where-ever possible. Not completely semantic, as there wasn't time to wrangle with Foundation's styles to adapt to a more semantic markup.
- CMS: Wordpress
Lessons learned:
- Many of the issues from COPA Metrics were solved by using SASS. A project that size and prone to sudden change coulnd't have been built using anything else.
- Early on, a lesson learned from COPA Metrics was the need to organize and systemize the design assets. Because nothing of the sort existed yet, building our framework with Foundation is the best choice available.
- It also made several things clear about working with Foundation:
- Foundation is excellent for rapid prototyping, but as a project matures, becomes cumbersome, then entirely unnecessary.
- We were unable to safely work with Foundation's scss, because it would get overwritten everytime they updated the codebase.
- near the end, it became increasingly difficult to manage, and ironning out the finer points of mobile styling became very time-consumming.
- Our style base had matured to the point that the only thing we were using from Foundation was a hand-full of mixins and a plugin called What-Input (which we're still using because it's amazing). We used their grid for some positioning, but ultimately relied on it very minimally. At mobile, other than supplying the breakpoints, Foundation made no difference to the appearance whatsoever.
Agency Template:
- Frontend Framework: built using Foundation, customized on top of Foundation's Compiled CSS
- Styles: CSS, build on Foundations compiled CSS, and built to adapt to Sharepoint's built-in markup & styles
- Markup: Bulky, unsemantic, difficult to manage
- CMS: Sharepoint 2010
- Lessons learned:
- The massive maintainability issues were caused by two things:
- Building on the Compiled CSS was a huge error. Immensely difficult to modify.
- Letting Sharepoint control the markup. Sharepoint markup is not accessable, and carries a large blame for our accessability failure last summer.
- Until fixing the two causes of the maintainability issue, no matter what framework we use, these problem will persist.
- Regardless of framework, it would be quicker to start from scratch than to 'fix' the old template.
- Avoid re-using the old agency template
DGS: State Construction Notices Directory
- Frontend Framework: built using our
Style Asset Library
. In other words, framework-free.
- Styles: SCSS. The
Style Asset Library
= the styles brought over from PA.Gov, without Foundation. The decision was made during this project to move away from Foundation entirely. From Foundation, we kept 'What-Input', about 5 mixins, and to replace Foundation's grid, we're used a Sass-based tool called Susy. Other than those things, Foundation brought nothing to the table that our Style Asset Library
wasn't already handling.
- Markup: Semantic, clean, and minimal. Built in VSTS, using Razor (MVC ?) to generate partials
- Lessons learned:ß
- making the move away from Foundation came with growing pains, and wasn't immediately accepted.
- In addition to standardizing the styles, the choice was made to begin standardizing the HTML5 markup as well. However, without a centralized and definitive resource to define the markup, this could lead to confusion.
- The need to have a central authority on 'correct' markup comes up : for it, I'm referring to HTML5's latest docs, the latest Accessability best practices, and one prevalent rule: Use The Least Amount Of Markup Possible
- the
Style Asset Library
is incomplete without also standardizing the markup; in other words, everything needs to be more modular.
- began building this standardize library via a Styleguide, stored in a directory within the site
PBPP: Most Wanted Absconders
- Frontend Framework: built using the matured
Style Asset Library
from DGS. This time, adapted to include standardized semantic / accessability markup.
- Styles: SCSS. The
Style Asset Library
+
- Markup: Semantic, clean, and minimal. Built in VSTS, using Razor (MVC ?) to generate partials
- Lessons learned:
- Though unnamed, this was the test implementation of
Strapless
: semantic, assessable markup + Style Asset Library
- The project was built rapidly, with a rapid bug-fixing phase.
- Also stores a 'Styleguide' directory within the site, a more mature (though very early) version of Strapless's styleguide output
Strapless, PSP, Employment, and Beyond
UX Skill Audit
Skill Audit
- Scale:
1 - 5
, 5 = Very Proficient
| Role |
Brian |
Briana |
Average |
| User Researcher |
2 |
4 |
3 |
| Information Architect |
5 |
4 |
4.5 |
| Interaction Designer |
4 |
3 |
3.5 |
| Visual Designer |
5 |
3 |
4 |
| Prototyper |
2 |
3 |
2.5 |
| Usability Expert |
5 |
5 |
5 |
| Content Strategist |
4 |
4 |
4 |
| Project Manager |
2 |
5 |
3.5 |
| Frontend Coder |
5 |
3 |
4 |
| System Analyst |
4 |
5 |
4.5 |
| --------------------- |
-------- |
-------- |
-------- |
| Overall |
5 |
4 |
Skill Audit - Details
Brian Roy
- Roles Currently Assuming:
- Front-end Coder
- Information Architect
- Interaction Designer
- Visual Designer
- Prototyper
- Usability Expert
- Content Stategist
- Strengths: Frontend Code, Visual Design, Interactive Design, Information Architech
- Weaknesses: Communication be
Briana
- Roles Currently Assuming:
- Front-end Coder
- User Researcher
- Usability Expert
- Visual Designer
- Prototyper
- Strengths:
- Weaknesses:
Audit Findings
Department Audit Outcome
Externally (within Office, outside of UX Team)
- UX at PAI: Little-to-none
- Team of One: Under-Staffed
- For Example: "Employment"
Internally (within UX Team)
Inner-Office: Areas In Need of UX:
DEV:
- Code Authorship
- Integration
- Accessability
PM:
- Completing Projects On Time
- Communicate Status
- Increased Visibility
- Outlook
- Biz Side: plans for annual income gain
- projection
- hiring: tiers, priorities
- culture shift
- new department & director
- management approach
Current State Of UX @ PAI
Process
- PM + DESIGN + DEV + PARTNER: Requirements Gathering
- PM: Put together requirements into a doc > DESIGN
- PM or DESIGN: Create wireframes > DESIGN
- DESIGN: create mockups > PM
[ Design Asset Delivery ]
Deliver design assets to Partner for approval. This step involves one or both of these two things:
- PM > PARTNER: send the PM exported assets
- PM + DESIGN > PARTNER: Presentations
DESIGN: revisions based on partner feedback > PM > PARTNER
- DESIGN + PM + PARTNER: repeat steps 7-9 as needed, until partner gives final approval of designs. Ideally, 1-2 cycles for most projects.
- DESIGN + DEV: adjust toolkit materials based on mockups, create new materials as needed.
After this step: backend development
, launch
, and post-launch maintenance
Devices
MacBook Pro (Retina, Mid 2012)
2.7 GHz Intel Core i7
16 GB 1600 MHz DDR3
NVIDIA GeForce GT 650M 1024 MB
Intel HD Graphics 4000 1536 MB
iPad Mini 4
Pen & Notepad
Notes
- [ ] MacDown
- [ ] Keep
- [ ] Apple Notes
Email + Communication
- [x] Outlook
- [x] Slack
- [ ] Trello
- [ ] VSTS (in browser)
Local Dev
- [ ] GitKraken
- [x] MAMP
- [ ] iTerm2
- [x] node.js
Images
Cloud
- [x] Dropbox
- [x] Adobe CC Cloud
- [ ] OneDrive
- [ ] Google Drive
Text Editors
- [x] Atom
- [ ] Visual Studio Code
- [ ] Visual Studio (PC)
- [ ] Sublime Text
- [ ] Brackets
Browsers
- [ ] Firefox
- [ ] Safari
- [x] Chrome
- [ ] Chrome Canary
- [x] Edge
Adobe
- [x] CC Cloud
- [ ] xD
- [x] Ps
- [x] Ai
- [ ] Lightroom
macOS exclusive
- [ ] Notes
- [ ] Calendar
- [ ] Reminders
- [ ] Mail
Here's How To Fix: (from my email to Adam, adjust to apply to UX in general, also add other points)
- Define the UX Department - In terms of the department's role, responsibilities, and position in overall project flow
- centralized, visual workflow - What projects are coming up, what projects is everyone working on
- requirements gathering coordinate process
SOLUTION
Process
I. Requirements Gathering
- UX (IA, Visual Design) + PM + Dev
Partner
UX (IA, Visual Design) + PM + DEV + PARTNER: Initial meeting, ideally in person, with all stakeholders.
- UX IA + PM Build User Personas, based on Data, Target Demographics, and Partner Input
- UX IA + PM Build User Scenarios, to identify UX objectives.
- PM Put together User Personas, User Scenarios, technical and design requirements into a doc
- UX + PM > PARTNER Communicate and agree with partner on user personas, either through a meeting or via email.
- Repeat steps 2-5 as needed, until approval.
II. Design & Storyboard
- Information Architect: Create System Maps, Process Flows, then wireframes > DESIGN
- VISUAL DESIGN: create mockups (concept designs (stills)) > INTERACTIVE DESIGN
- INTERACTIVE DESIGN / Front-end Developer: prototypes > QA / A/B Testing
QA / A/B Testing Test solution against UX objectives (step 3). QA > UX (IA, VISUAL DESIGN, INTERACTIVE DESIGN), PM > PARTNER
Repeat steps 8 - 11 until passing internal tests.
[ Design Asset Delivery ]
Deliver design assets to Partner for approval. This step involves one or both of these two things:
- PM > PARTNER: send the PM exported assets
- PM + DESIGN > PARTNER: Presentations
UX (IA, DESIGN): revisions based on partner feedback > PM > PARTNER
- DESIGN + PM + PARTNER: repeat steps 8-11 as needed, until partner gives final approval of designs. Ideally, 1-2 cycles for most projects.
- DESIGN + DEV: adjust toolkit materials based on mockups, create new materials as needed.
After this step: backend development
, launch
, and post-launch maintenance
'
--
Questions This Answers:
- Why Me?
- Why me, versus someone else internally?
- Why me, versus someone externally?
- What Value Do I Bring?
- What Will Happen If I'm Not Made UX Director?
- Would I be more useful in another department or doing another task?
--
I've played incrementally stronger and more central parts of every key successful project I've been assigned
Central to my process is a focus on bringing value to both PAI and our Partner.
- I bring that value through a dedication to observing UX Design and Frontend Development standards, trends, methods.
More importantly, I merge what I'm learning back into what I produce, ultimately improving it.
- Using this process, I've been building a frontend asset toolkit of the best and most consistent & standards-aherent code
Along side, I've been developing a plan for the UX department. I need more time to bring the plan to full bloom, but I don't want to keep it secret and I'm at a point where external insight begins to become very be helpful
I'm useless for migrations.
Versus Others (internal / external hire)
I've been doing this work already:
- director
- design architech
--
plan
Phase I:
- anaylsis of current systems
- planning
- communication
- preparations
Phase II:
Phase III - Phase(x):
- Acquire New UX Team Members
- Re-assign internally based on UX Team Audit results
new team
UX Roles
Roles within the current UX Team:
- Senior UX Designer
- UX Designer
Of course, these don't account for many of the primary UX roles.
Since we won't be hiring new UX personel immediately, we'll divide up the current UX Roles between 4 Primary Roles:
UX Director:
- Define UX Department:
- UX Scope:
- Visual Design
- Code
- Communications: Requirements Gathering, Technology Discussions
- Authority on UX
- UX - Involved From The Start
- Processes:
- Oversee All UX Processes
- Define UX Processes
- Measure, Track, & Improve UX Processes
- Communication:
- Along side the UX Liaison, see the Inner-Office Coordination plan through
- Directors: Planning, resource allocation meetings
- Frontend Code:
- Scope: HTML5, CSS3, CMS
- Accessability, & Semantics, include UX in Frontend Development's Process
- Director level authority input on technology choices
- Architech of HTML5 & CSS3, to ensure Accessability, Semantics, and Consistency with Design Assets
Phases: Transitioning & Division of Labor
Phase I: (current)
| Role |
Team Member |
| Senior UX Designer |
Briana |
| UX Designer |
Brian |
Phase II:
| Role |
Team Member |
| UX Director |
Brian |
| UX Designer |
Brian |
| UX Analyst |
Briana |
| UX Liaison |
Briana |
Phase III:
Time to bring in new talent:
Cambrea
- UX Designer = (get requirements, create designs)
- Frontend Developer = (designs > code)
Sam
- Frontend Developer
- Analytical, PM Experience
| Role |
Team Member |
| UX Director |
Brian |
| UX Designer |
Brian, Cambrea, Sam |
| UX Analyst |
Briana, Sam |
| UX Liaison |
Briana, Cambrea |
Expanding On This:
| Role |
Team Member |
Specialization |
| UX Director |
Brian |
| UX Designer |
Brian |
Frontend Dev, Interaction Designer |
| UX Designer |
Cambrea |
Frontend Dev, Visual Designer, Interaction Designer |
| UX Designer |
Sam |
Frontend Dev |
| UX Analyst |
Briana, Sam |
| UX Liaison |
Briana, Sam |
| Prototyper |
Jerrina |
QA Department |
Skill Audit (with new Team Members)
| Role |
Brian |
Briana |
Cambrea |
Sam |
Average |
| User Researcher |
2 |
4 |
3 |
| Information Architect |
5 |
4 |
4 |
| Interaction Designer |
4 |
3 |
4 |
| Visual Designer |
5 |
3 |
5 |
| Prototyper |
2 |
3 |
4 |
| Usability Expert |
5 |
5 |
4 |
| Content Strategist |
4 |
4 |
3 |
| Project Manager |
2 |
5 |
3 |
| Frontend Coder |
5 |
3 |
5 |
| System Analyst |
4 |
5 |
2 |
| --------------------- |
-------- |
-------- |
-------- |
| Overall |
5 |
4 |
Goals
For 2017:
- Define UX Role
- Improve UX Process Visibility & Internal Communication
- Create Docs, Tools, & Libraries:
- UX Playbook for PMs, UX
- Style Guide for Commonwealth
- Design Asset Library for Design
- Frontend Code Asset Library for Development
- Find, Build, & Establish Central Tool inVision, Strapless
- Unify Docs, Tools, & Libraries Under Central Tool
- Integrate Tool Sharepoint, Wordpress, PHP, Razor/MVC, App Engine
- Agency Template Redesign, Modernize, update
- Update Old Sites
Ongoing:
The more you educate others about your UX process and overall vision, the easier it is to gain buy-in on growth for your team.
Once you prove your team’s ability to positively change products, improve experiences, and gain adoption, you’ll have the power to grow. Building An Enterprise UX Team
Expose The UX Proces
- "Less Demands, More Feedback"
- establish internal self-improvment mechanism, so Commonwealth doesn't feel the need to lead that charge
- Earn a higher level of trust from Commonwealth
- Shift conversation from demands and fixes to questions & advice. For example, we want to shift away from "Build a website that contains x" or "We need you to fix x", to "what do you think of x, and if it's a good idea, how do we accomplish x?"
Cultivate Proccess
- Research, test, and try new techniques and tools for UX, Development
- Cycle out old or ineffective tools
- Tool audit
- Cultivate Team
- Training, Continued Eductation
- Stay up to date on trends by reading industry news sources
- Research, learn, safely try new things
- Conferences
- Daily, Weekly, Monthly Meetings
- Document & Educate:
- Documentation
- Tutorials
- Internally, Externally, Commonwealth
- UX latest, trends, standards, best practices,
- PM UX, asking questions
- Frontend Dev semantics, accessability, SASS, markdown, etc.
UX Roles - Details
I. UX Director
Roles
Frontend Code
- HTML + CSS
- Build + Maintain Frontend Code Framework
- Constant improvement of over-all codebase
- Maintain Frontend Asset Library
- Maintain Resource Library
- Build & Maintain Docs
- Research + test new methods of coding & solving UX issues
- Develop + Improve Processes
Design
- Build + Maintain visual Style Guide for Commonwealth
- Build + Maintain Design Asset Library
- Write and Maintain Design Process Documentation
- Research Latest Trends + Techniques
Code + Design
This is a major goal for the UX Team.
- Unify Design Asset Library with Frontend Code Framework
- find a tool to easily facilitate or minimize the involvement time when initial coordinating
Documentation
- document all the things (in markdown, of course :) )
II. UX Liaison
(Internal Analysis, Systems Management, & Communications)
As the Senior UX Designer, Briana will focus primarily on the human-interaction side of UX.
Requirements Gathering
- Present, or responsible for ensuring someone from UX is present in every relevant Requirements Gathering meeting
- Involved in all design communication
- Involved with and Responsible for communcating development parameters, as they relate to UX
Primary Tasks
- Requirements Gathering: Have a design / dev presence be in ALL requirements gathering
- Inner-Office Coordination: Improve Processes, Coordinate Tasks & Unify Workflow
- R&D (Research & Development)
- Tools
- PM + UX: Tool to facilitate
Requirements Gathering -> Wireframes -> Prototype
- Dev + UX: Tool to unify assets (assist Devopers & UX Director)
- Audit, Research, Testing, Implementing, Docs
- UX Processes
- Frontend Dev New technologies, advancements in HTML5 & CSS3 Spec, etc.
- Communicate & Teach
- Audit current Internal Communications and Training processes
- Find and suggest ways to improve
- Facilitate knowledge sharing
- UX: Findings as they related to UX best practices, tools, processes, trends, etc.
- PM: Asking questions, Client-interaction research, info, and articles
- Dev: Learning New Tech, like SASS, Accessability, etc.
- Internally: about processes, about requirements gathering, Accessability, Communcation coordination.
- Externally: w/ Partner, in collaboration with PMs during requirements gathering.
Inner-Office Coordination
The more you educate others about your UX process and overall vision, the easier it is to gain buy-in on growth for your team.
Our UX team exposes the entire process from our initial research to ideation stages, all the way to final visual design, microinteractions, and prototypes.
Exposing those roles to other teams and management helps identify the varying workloads that a full enterprise UX team takes on. Plus, sharing your team’s process fosters cross-functional collaboration with external teams—and drives future ideation.
Building An Enterprise UX Team
Marketing
- leverage tracy's talents for getting us in front of target markets for research
- likely, largely for conducting surveys and polling and A/B testing
- otherwise: meet with Tracy to truely grasp nature of her duties and goals
QA
- leverage Jerinna's focus for conducting tests of apps.
- meet with her to coordinate docs with her Play Book entry
PM
I. Coordinate Requirements Gathering Process
- Have a design / dev presence be in ALL requirements gathering
- This will enable UX-centered discussions immediately from the start
- Moreso, if we don't begin a UX-centered discussion at the beginning, you can't add it in afterwards. UX conversations should always begin by analyzing the user's needs --- trying to apply UX thinking after requirements have already been set in stone essentially means starting again from the beginning.
- If not, design cannot be held responsible for extra time needed to accomplish UX
II. Coordinate Tasks & Unify Workflow
- documentation coordinate + centralize
- the PMs have been building a playbook --- let's share!
- store all docs from other depts in same repo.
- Standardized documentation writing method (Word doc vrs. Markdown)
- knowledge sharing
- educate PMs to UX + Asking Questions
- Provide PM Team: List of Things to Ask + Approaches to UX
- Provide PM Team complete library of web components w/ specs, should they want to see what we're actually selling
- Find central tool for the Requirements > Prototype stages (or one that goes beyond the Prototype stage)
- Unify wireframe tool
- adobe v. balsamiq
- Unify, build or document recurring wireframe patterns
Dev
- Knowledge Share (via Jakob's meeting)
- Every other week 1 different person from team must present?
- Framework Maintenance Coordination
- Coordinate w/ Corey on Framework JS
- Documentation & Process
- would help with appearing more granually involved with project if many tasks get completed instead of just big over-arching category-based tasks.
Documentation
Coordinate Efforts:
Markdown
--
Secondary
UX TEAM AUTHORITY STRUCTURE
Steam has a "managerless" office structure, where no ones the boss, people just fill roles as needed, but everyones on equal footing in terms of authority, pay, or exposure to "management-only" info
I wonder if we could try something like that, in a microcosm, in the UX department.
a possibility for that: Id take less income than directors traditionally make, and spilt the difference amount the ux team (meaning you, cam, sam, if i get my first picks for this.
SKILL ACCESSMENT
Frontend Development
Skill Audit
Frontend Development
Frontend Dev: Detailed
- HTML5
- Markup
- Markdown
- Semantics
- Accessability
- CSS3
- Pre-Processors (SASS, LESS)
- Susy
- Layout & Grids
- Animations
- JAVASCRIPT
- jQuery
- Angular
- TypeScript
Bridging The Gap
- We're all on different levels. Regardless of the results a skill audit, we still need to bridge this knowledge gap somehow, or at least center it somewhere from whence to base discussions or explanations when sharing about code.
Solution: Training, Research, Knowledge Sharing
-->


NEWS
SIR DAVID ATTENBOROUGH
ACCEPTS RSB AWARD
SARS-COV-2
THE VIRUS AT THE HEART
OF A GLOBAL CRISIS
PUBLIC HEALTH
HOW TO OVERCOME
‘VACCINE HESITANCY’
THE MAGAZINE OF THE ROYAL SOCIETY OF BIOLOGY / www.rsb.org.uk
ISSN 0006-3347 • Vol 67 No 2 • Apr/May 2020
COMPUTER
EVOLUTION
Making new life forms – with
frog cells and a supercomputer


| Network Working Group | J.C. Gregorio, Editor |
| INTERNET DRAFT | BitWorking, Inc |
| <draft-ietf-atompub-protocol-03.txt> | R.F. Sayre, Editor |
| Category: Standards Track | Boswijck Memex Consulting |
| Expires: September 2005 | March 2005 |
The Atom Publishing Protocol
draft-ietf-atompub-protocol-03.txt
By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at <http://www.ietf.org/ietf/1id-abstracts.txt>.
The list of Internet-Draft Shadow Directories can be accessed at <http://www.ietf.org/shadow.html>.
This Internet-Draft will expire in September 2005.
Copyright (C) The Internet Society (2005). All Rights Reserved.
This memo presents a protocol for using XML (Extensible Markup Language) and HTTP (HyperText Transport Protocol) to edit content.
The Atom Publishing Protocol is an application-level protocol for publishing and editing Web resources belonging to periodically updated websites. The protocol at its core is the HTTP transport of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format (draft-ietf-atompub-format-06.txt).
To provide feedback on this Internet-Draft, join the atom-syntax mailing list (http://www.imc.org/atom-syntax/index.html).
1
Introduction
1.1
Notational Conventions
1.2
Terminology
2
The Atom Publishing Protocol Model
2.1
Atom Collections
2.1.1
Usage
2.1.2
Client and Server Interaction
3
Functional Specification
3.1
Collections
3.1.1
Collection Document
3.1.2
Elements in a Collection Document
3.1.3
Collection Requests
<IP_ADDRESS>
Range: Header
<IP_ADDRESS>
Accept-Ranges: Header
3.2
Introspection
3.2.1
Service Document
<IP_ADDRESS>
Service Documet Elements
3.3
Entry Collection
3.3.1
Locating
3.4
Simple Resource Collection
3.4.1
Locating
3.4.2
Request
3.5
Atom Request and Response Body Constraints
3.5.1
id
3.5.2
link
3.5.3
title
3.5.4
summary
3.5.5
content
3.5.6
issued
3.5.7
modified
3.5.8
created
3.5.9
author
3.5.10
contributor
3.5.11
generator
3.6
Securing the Atom Protocol
3.6.1
[@@TBD@@ CGI Authentication]
4
Security Considerations
5
IANA Considerations
6
Appendix A - SOAP Enabling
6.1
Servers
6.2
Clients
7
Appendix B - Examples
7.1
Example for a weblog
7.2
Example for a wiki
8
Revision History
9
Normative References
§
Author's Addresses
§
Intellectual Property and Copyright Statements
The Atom Publishing Protocol is an application-level protocol for publishing and editing Web resources using HTTP [RFC2616] and XML.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
The Atom Publishing Protocol is an application-level protocol for publishing and editing Web resources. The primary way of interaction in the Atom Publishing Protocol is by managing collection of resources. All collections support the same basic methods of interaction. In addition, the resources belonging to collections also share the same interaction patterns. Using the common HTTP verbs provides a pattern for working with all such Web resources:
An Atom collection is a set of items all of the same type ("members" of the collection), where the "type" may be, for example: Atom entry, category, template, "simple resource", or any other classification of web resource.
Each collection has a URI which is given in the introspection file. A GET on the collection URI MUST produce a collection document as defined in "3.X.1 Collection Document." That document describes PART OF the state of the collection.
All the members of a collection have an "updated" property, and the collection is considered to be ordered by this property. A single collection document may not contain all of the members of a collection. If a collection document is the response of a non-partial GET request, and does not contain all of the members of a collection, then it will contain the URI of the next collection document which will contain more of the collection members. By traversing this list of collection documents a client can obtain all of the members of a collection. The 'next' attribute will not be present in the response to a partial GET request.
Below two usages are outlined for Atom Collections. They are here to highlight common idioms for interacting with a Collection Resource and not a normative interaction pattern.
The Atom Collection can be used by clients in two ways. In the first case the client has attached to a site for the first time and is doing an initial syncronization, that is, retrieving a list of all the members of the collections and possibly retrieving all the members of the collection also. The client can perform a non-partial GET on the collection resource and it will receive a collection document that either contains all the member of the collection, or the collection document root element 'collection' will contain a 'next' attribute pointing to the next collection document. By repeatedly following the 'next' attribute from document to document the client can find all the members of the collection.
In the second case the client has already done an initial sync, and now needs to re-sync, because the client was just restarted, or some time has passed since a re-sync, etc. The client does a partial GET on the collection document, supplying a Range header that begins from the last time the client sync'd to the current time. The collection document returned will contain only those members of the collection that have changed since the last time the client syncronized.
[rfc.comment.1: ...]
This document does not specify the form of the URIs that are used. The URI space of each server is controlled, as defined by HTTP, by the server alone. What this document does specify are the formats of the files that are exchanged and the actions that can be performed on the URIs embedded in those files.
A collection document is rooted by a <collection> element. A collection element may have any number of <member> elements as children; each such element identifies a member of the collection. In some situations, a collection document may not contain every member of the collection itself.
Whether complete or partial, the members in a collection document MUST constitute a consecutive sequence of the collection's members, ordered by their "updated" properties. That is, a collection document MUST contain a contiguous subset of the members of the collection ordered by their 'updated' property.
A collection document MAY contain zero or more 'member' elements.
Each 'member' element MUST include an 'href' attribute identifying a URL of the member resource. The 'href' URI of a member resource is an "EditURI" under the terms of section 2, and MUST respond to the same HTTP methods as such an EditURI.
Each 'member' element MAY include an "hrefreadonly" attribute. This optional attribute identifies a URI which, on a GET request, responds equivalently to how the "href" URI would respond to the same request. Clients SHOULD NOT apply to this URI any HTTP methods that would be expected to modify the state of the resource (e.g. PUT, POST or DELETE). A PUT or POST request to this URI MAY NOT affect the underlying resource. If the "hrefreadonly" attribute is not given, its value defaults to the "href" value. If the "hrefreadonly" attribute is present, and its value is an empty string, then there is no URI that can be treated in the way such a value would be treated.
Clients SHOULD use the "href" value to manipulate the resource within the context of the APP itself. Clients SHOULD prefer the "hrefreadonly" value in any other context. For example, if the resource is an image, a client may replace the image data using a PUT on the "href" value, and may even display a preview of the image by fetching the "href" URI. But when creating a public, read-only reference to the same image resource, the client should use the "hrefreadonly" value. If the "hrefreadonly" value is an empty string, the client SHOULD NOT make public reference to the "href" value.
Each 'member' element MUST include a 'title' attribute, whose value is a human-readable name or description for the item. The values of 'title' attributes are not required to be unique across all members of a collection.
Each 'member' element MUST include an 'updated' attribute, whose value is the 'updated' property of the collection member whose format MUST conform to the date-time BNF rule in [RFC3339].
HTTP/1.1 allows a client to request that only part (a range of) the collection to be included within the response. HTTP/1.1 uses range units in the Range header field. A collection can be broken down into subranges according to the members 'updated' property. If a Range: header is present in the request, its value explictly identifies the a time interval interval in which all the members 'updated' property must fall to be included in the response.
Range = "Range" ":" ranges-specifier
The value of the Range: header should be a pair of ISO 8601 dates, separated by a slash character; either date may be optionally omitted, in which case the range is understood as stretching to infinity on that end.
ranges-specifier = updated-ranges-specifier updated-ranges-specifier = updated-unit "=" updated-range updated-unit = "updated" updated-range = [iso-date] "/" [iso-date]
The response to a collection request MUST be a collection document, all of whose 'member' elements fall within the requested range. If no members fall in the requested range, the server MUST respond with a collection document containing no 'member' elements.
The response to a non-partial GET request MUST include an Accept-Ranges header that indicates that the server accepts 'updated' range requests.
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges acceptable-ranges = updated-unit ( 1#range-unit )
There are many different kinds of resources that can be managed through the APP, for example, entries, templates, users, etc. The Service Document is a single document that lists all the facets of the APP that a site supports and also contains the URIs of all those resources.
The Service Document lists the resources that each site makes available. The Service Resource returns an Service Document in response to a GET request. Here is an example of an Service Document.
<?xml version="1.0" encoding='utf-8'?> <service version="0.3" xmlns="http://purl.org/atom/ns#"> <workspace title="Main Site" > <collection rel="entries" name="Entries" href="http://example.org/reilly/feed" /> <collection rel="categories" name="Categories" href="http://example.org/reilly/cat" /> <collection rel="templates" name="Templates" href="http://example.org/reilly/tmpl" /> <collection rel="users" name="Users" href="http://example.org/reilly/users" /> <collection rel="resource" name="Pictures" href="http://example.org/reilly/pic" /> </workspace> <workspace title="b-links"> <collection rel="entries" name="Entries" href="http://example.org/reilly/feed" /> <collection rel="http://example.net/booklist" name="Books" href="http://example.org/reilly/books" /> </workspace> </service>
The default for the rel attribute is 'resource'. Extensibility for 'rel' values is handled in the same manner as PaceFieldingLinks. Each 'collection' element in 'workspace' represents a single facet of the APP. While a site must fully support each facet they list in their Service Document, a site does not need to support all the facets in this RFC. Additionally, new facets may be added either through vendor extension or follow-on RFCs.
The "service" element is the document element of a Service Document, acting as a container for service data associated with possibly multiple workspaces. Its only child elements MUST be one or more 'workspace' elements. The 'service' element MUST have a single attribute 'version' whose content indicates the version of the Atom specification that the document conforms to. The content of this attribute is unstructured text. The version identifier for this specification is "1.0".
The 'workspace' element element contains information elements about the collections of resources available for editing. The only children of 'workspace' MUST be one or more "collection" elements. The 'workspace' element MUST have a single attribute 'title' whose content MUST NOT be empty and which is a human-readable name for the workspace.
The 'collection' element describes various typed groups of resources available for editing or adding to.
Entries are managed through collections and as such entry collection and entries that are members of a collection must support all the operations enumerated above.
An Edit Resource is used to edit a single entry. Each entry that is editable MUST have a unique URI. This URI supports both GET and PUT and they are used in tandem for an editing cycle. The client GETs the representation which is formatted as an Atom entry. The client may then update the entry and then PUT it back to the same URI. The PUT will cause all the related resources to be updated, for example, the HTML representation.
Note that the value of the content element in the Atom entry does not have to exactly match the content element for the same entry when it is represented in an Atom feed. For example, a server may allow the client to post entries whose content is formatted as WikiML, yet the server may clean up such markup and transform it into well-formed XHTML before placing it in the publicly available Atom feed. Another scenario is summaries--the EditURI is for editing the full content of an entry, but the server may only present excerpts when it produces an Atom feed.
A client will send a DELETE to the EditURI to delete an entry.
For editing a site Entry, the link tag is used. Note that a link tag is used in both HTML and in the Atom format. A link tag of the following format points to the EditURI for a site. In HTML, the link tags for editing are always found in the head element, while in Atom they may appear as children of the entry elements.
<link rel="service.edit" type="application/atom+xml" href="URI for Editing goes here" title="Readable desc of the entry." />
Note: The critical characteristic of this link tag is the @rel of 'service.edit' and the @type of 'application/atom+xml'.
Simple Resources are managed through collections and as such simple reource collections and simple resources that are members of the collection must support all the operations enumerated above. Simple Resources can be images, templates, and any other non-entry resources.
For creating a new non-entry resource, the link tag is used. Note that a link tag is used in both HTML and in the Atom format. A link tag of the following format points to the ResourcePostURI for a site. In HTML the link tags are always found in the head element, while in Atom they may appear as children of the Feed and entry elements.
<link rel="resource.post" href="URI for Resource Posting goes here" title="The name of the site.">
The request contains a resource, sent through a standard HTTP POST, e.g.:
POST /_do/exampleblog/post_resource HTTP/1.1 Host: www.example.com Content-Type: image/jpeg Content-Length: nnn ...raw bytes of image go here...
The Atom format is used as the representation of all the resources in this specification. As it is used in differing contexts, there are different constraints of which elements may be present, and how their values should be interpreted.
All instances of publishing Atom entries SHOULD be protected by authentication to prevent posting or editing by unknown sources. Atom servers and clients MUST support one of the following authentication mechanisms, and SHOULD support both.
Atom servers and clients MAY support encryption of the Atom session using TLS [RFC2246].
There are cases where an authentication mechanism may not be required, such as a publicly editable Wiki, or when using the PostURI to post comments to a site that does not require authentication to create comments.
This authentication method is included as part of the protocol to allow Atom servers and clients that cannot use HTTP Digest Authentication but where the user can both insert its own HTTP headers and create a CGI program to authenticate entries to the server. This scenario is common in environments where the user cannot control what services the server employs, but the user can write their own HTTP services.
Because Atom is a publishing protocol, it is important that only authorized users can create and edit entries.
The security of Atom is based on HTTP Digest Authentication and/or [@@TBD@@ CGI Authentication]. Any weaknesses in either of these authentication schemes will obviously affect the security of the Atom Publishing Protocol.
Both HTTP Digest Authentication and [@@TBD@@ CGI Authentication] are susceptible to dictionary-based attacks on the shared secret. If the shared secret is a password (instead of a random string with sufficient entropy), an attacker can determine the secret by exhaustively comparing the authenticating string with hashed results of the public string and dictionary entries.
See RFC 2617 for more detailed description of the security properties of HTTP Digest Authentication.
@@TBD@@ Talk here about using HTTP basic and digest authentication.
@@TBD@@ Talk here about denial of service attacks using large XML files, or the billion laughs DTD attack.
This document has no actions for IANA.
All servers SHOULD support the following alternate interface mechanisms to enable a wider variety of clients to interact with Atom Publishing Protocol servers. The following requirements are in addition to the ones listed in the Functional Specification Section. If a server supports SOAP Enabling then it MUST support all of the following.
Fill this in with an example for how all the above is used for a weblog. Start with main HTML page, link tag of type service.feed to the 'introspection' file. 1. Creating a new entry 2. Finding an old entry 3. editing an old entry 4. commenting on a entry (via HTML and Atom)
Fill this in like above but for a wiki.
draft-ietf-atompub-protocol-03 - Incorporates PaceSliceAndDice3 and PaceIntrospection.
draft-ietf-atompub-protocol-02 - Incorporates Pace409Response, PacePostLocationMust, and PaceSimpleResourcePosting.
draft-ietf-atompub-protocol-01 - Added in sections on Responses for the EditURI. Allow 2xx for response to EditURI PUTs. Elided all mentions of WSSE. Started adding in some normative references. Added the section "Securing the Atom Protocol". Clarified that it is possible that the PostURI and FeedURI could be the same URI. Cleaned up descriptions for Response codes 400 and 500.
Rev draft-ietf-atompub-protocol-00 - 5Jul2004 - Renamed the file and re-titled the document to conform to IETF submission guidelines. Changed MIME type to match the one selected for the Atom format. Numerous typographical fixes. We used to have two 'Introduction' sections. One of them was moved into the Abstract the other absorbed the Scope section. IPR and copyright notifications were added.
Rev 09 - 10Dec2003 - Added the section on SOAP enabled clients and servers.
Rev 08 - 01Dec2003 - Refactored the specification, merging the Introspection file into the feed format. Also dropped the distinction between the type of URI used to create new entries and the kind used to create comments. Dropped user preferences.
Rev 07 - 06Aug2003 - Removed the use of the RSD file for auto-discovery. Changed copyright until a final standards body is chosen. Changed query parameters for the search facet to all begin with atom- to avoid name collisions. Updated all the Entries to follow the 0.2 version. Changed the format of the search results and template file to a pure element based syntax.
Rev 06 - 24Jul2003 - Moved to PUT for updating Entries. Changed all the mime-types to application/x.atom+xml. Added template editing. Changed 'edit-entry' to 'create-entry' in the Introspection file to more accurately reflect it's purpose.
Rev 05 - 17Jul2003 - Renamed everything Echo into Atom. Added version numbers in the Revision history. Changed all the mime-types to application/atom+xml.
Rev 04 - 15Jul2003 - Updated the RSD version used from 0.7 to 1.0. Change the method of deleting an Entry from POSTing <delete/> to using the HTTP DELETE verb. Also changed the query interface to GET instead of POST. Moved Introspection Discovery to be up under Introspection. Introduced the term 'facet' for the services listed in the Introspection file.
Rev 03 - 10Jul2003 - Added a link to the Wiki near the front of the document. Added a section on finding an Entry. Retrieving an Entry now broken out into it's own section. Changed the HTTP status code for a successful editing of an Entry to 205.
Rev 02 - 7Jul2003 - Entries are no longer returned from POSTs, instead they are retrieved via GET. Cleaned up figure titles, as they are rendered poorly in HTML. All content-types have been changed to application/atom+xml.
Rev 01 - 5Jul2003 - Renamed from EchoAPI.html to follow the more commonly used format: draft-gregorio-NN.html. Renamed all references to URL to URI. Broke out introspection into it's own section. Added the Revision History section. Added more to the warning that the example URIs are not normative.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC2246] | Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. |
| [RFC2396] | Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. |
| [RFC2616] | Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
| [RFC2617] | Franks, J., Hallam-Baker, P.M., Hostetler, J.L., Lawrence, S.D., Leach, P.J., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. |
| Joe Gregorio (editor) | |
| BitWorking, Inc | |
| 1002 Heathwood Dairy Rd. |
|
| Apex, NC 27502 | |
| US | |
| Phone: | +1<PHONE_NUMBER> |
| EMail: |<EMAIL_ADDRESS>|
| URI: | http://bitworking.com/ |
| Robert Sayre (editor) | |
| Boswijck Memex Consulting | |
| 148 N 9th St. 4R |
|
| Brooklyn, NY 11211 | |
| US | |
| EMail: |<EMAIL_ADDRESS>|
| URI: | http://boswijck.com |
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at <http://www.ietf.org/ipr>.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at<EMAIL_ADDRESS>
Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Funding for the RFC Editor function is currently provided by the Internet Society.


---
layout: post
authors: ["Greg Wilson"]
title: "Code and Data for the Social Sciences"
date: 2013-09-26
time: "10:30:00"
tags: ["Noticed"]
---
Matthew Gentzkow and Jesse Shapiro have written an excellent guide
"Code and Data in the Social Sciences".
It's short (only 38 pages),
very readable,
and full of practical advice for scientists of all stripes:
- Automate everything that can be automated.
- Write a single shell script that executes all code from beginning to end.
- Store code and data under version control.
- Run the whole directory before checking it back in.
- Separate directories by function.
- Separate files into inputs and outputs.
- Make directories portable.
- Store cleaned data in tables with unique, non-missing keys.
- Keep data normalized as far into your code pipeline as you can.
- Abstract to eliminate redundancy.
- Abstract to improve clarity.
- Otherwise, don't abstract.
- Don't write documentation you will not maintain.
- Code should be self-documenting.
- Manage tasks with a task management system.
- E-mail is not a task management system.


404
Error! Page not found.
This page is not available! due to incomplete profile. please fill-up your profile Here.
{% extends 'index.html' %} {% load static %} {% block title %} Error Page {% endblock title%} {% block css %} {% endblock css %} {% block nav_dashboard %}
This page is not available! due to incomplete profile. please fill-up your profile Here.


{{ "home.head" | translate }}
Set up a Portfolio
New Portfolios will be visible in the left side bar of this page.
All TOs associated to a specific Application or set of related Applications will be entered at the Portfolio level. Funding is applied and managed at the Portfolio level as well.
{{ "navigation.portfolio_navigation.breadcrumbs.funding" | translate }}
{{ "home.funding_descrip" | translate }}
{{ "navigation.portfolio_navigation.breadcrumbs.reports" | translate }}
{{ "home.reports_descrip" | translate }}
{{ "navigation.portfolio_navigation.breadcrumbs.applications" | translate }}
{{ "home.applications_descrip" | translate }}
{{ "navigation.portfolio_navigation.breadcrumbs.admin" | translate }}
{{ "home.admin_descrip" | translate }}


Ivan Dusseau's Web Developer Examples and Resources
Social Media Optimization
Modern age brands and companies are more entwined with audiences than ever. From the Wendy’s twitter to Gillete making social justice ad campaigns, brands are seeking connection to audiences through social media and the internet as a whole. To help generate more clicks on these platforms, understanding Social Media Optimization (or SMO) is key. Investopedia defines SMO as, “the use of social media networks to manage and grow an organization’s message and online presence.” This idea is incredibly important to raising awareness of your brand or product.
It’s not a new concept, but it’s become tied to a sister concept, Search Engine Optimization (SEO), which is the art of manipulating search engines to show your website above others. These used to be separate concepts, but now they’re increasingly married together.
In fact, a survey by Searchengineland found that 38% of companies that had successful SEO campaigns also had a large social media standing. All of this is part of viral marketing. A strategy revolving around fast spreading word of mouth advertising stimulated by a conversation online.  That’s a successful viral marketing campaign. And the internet, especially social media, is a great outlet for this.
An advantage of online marketing, and SMO as an extension, is that it’s almost instant and extremely cheap. Every retweet of a Wendy’s tweet, message about Nike supporting Colin Kaepernick, or post about loving/hating the Gillete ad is free marketing. It’s extremely efficient and cheap to create or spread a social media campaign. This optimization is beneficial for any business, especially smaller startups. The cost of running a twitter page is low, it reaches a broad audience, and it allows for engagement with that audience.
The optimization of getting your brand recognized is fairly similar to search engine optimization, but now involves personal touches. Creating a strong profile, original content, images, hashtags and the like will boost your brand on the platform, and in turn boost the likelihood that you are topping the google results.


JSON MessagePack converter.
You can see the source code on GitHub.
Choose source file or input JSON on the below text area.
You can input only JSON format here.
Convert


JavaScript is disabled on your browser.
Skip navigation links
Overview
Package
Class
Use
Tree
Deprecated
Index
Help
Prev Letter
Next Letter
Frames
No Frames
All Classes
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
Z
W
walkDirectory(List<Path>, Path, int)
- Static method in class
MyFiles
walkDirectory(Path, int)
- Static method in class
MyFiles
warnings
- Variable in class
Route
Waypoint
- Class in
io.github.kkysen.quicktrip.apis.google.maps.directions.response
Waypoint()
- Constructor for class
Waypoint
waypointOrder()
- Method in class
WaypointOrderOnlyDirections
waypointOrder
- Variable in class
WaypointOrderOnlyRoute
waypointOrder
- Variable in class
Route
WaypointOrderOnlyDirections
- Class in
io.github.kkysen.quicktrip.apis.google.maps.directions.order.response
WaypointOrderOnlyDirections()
- Constructor for class
WaypointOrderOnlyDirections
WaypointOrderOnlyRoute
- Class in
io.github.kkysen.quicktrip.apis.google.maps.directions.order.response
WaypointOrderOnlyRoute()
- Constructor for class
WaypointOrderOnlyRoute
waypointOrderOnlyRoutes
- Variable in class
WaypointOrderOnlyDirections
WaypointOrderRequest
<
E
> - Class in
io.github.kkysen.quicktrip.apis.google.maps.directions.order
WaypointOrderRequest()
- Constructor for class
WaypointOrderRequest
waypoints
- Variable in class
GoogleDirectionsRequest
waypoints
- Variable in class
Directions
WaypointType
- Enum in
io.github.kkysen.quicktrip.apis.google.maps.directions.response
WaypointType()
- Constructor for enum
WaypointType
welcomeMsg
- Variable in class
WelcomeScreen
WelcomeScreen
- Class in
io.github.kkysen.quicktrip.app
WelcomeScreen()
- Constructor for class
WelcomeScreen
WholeNumberField
- Class in
io.github.kkysen.quicktrip.app.javafx
WholeNumberField(long)
- Constructor for class
WholeNumberField
WholeNumberField()
- Constructor for class
WholeNumberField
WholeNumberInputError
- Exception in
io.github.kkysen.quicktrip.app.input
WholeNumberInputError(String, long)
- Constructor for exception
WholeNumberInputError
write(JsonWriter, GoogleFlightsRequest)
- Method in class
GoogleFlightsRequestAdapter
write(Path, String)
- Static method in class
MyFiles
write(Path, BufferedReader)
- Static method in class
MyFiles
write(Path, Iterable<T>)
- Static method in class
MyFiles
write(Path, T)
- Static method in class
MyFiles
write(JsonWriter, JsonFx)
- Method in class
JsonFxAdapter
write(JsonWriter, T)
- Method in class
TypeReaderAdapter
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
Z
Skip navigation links
Overview
Package
Class
Use
Tree
Deprecated
Index
Help
Prev Letter
Next Letter
Frames
No Frames
All Classes


ASFV -bp DNA segment sheep silvarum using nuttalli ticks used PCR sequencing testudinarium OpenUrl Swine detected reported African Fever Chen RNA Sanger existence genome new nuttalli, performed results sequences virus blood bovine data different hard province sRNA-seq sequenced showed small study (GenBank: Dermacentor Figure Gao Ornithodoros Sun Using collected detect pipeline range reference samples specific ASF Lane Virus VirusDetect Xinjiang adults, amplified bands based represent represents sheep, single technology. ticks. viruses


Looks like you've lost connection. It's probably best you wait until you reconnect, otherwise we can't save your changes.
If you rebooted you box or synced any network settings, you might have been disconnected.
Check you're connected to the correct network and that the box has connectivity.


EYEGLASS GALLERIA
home
Lenses
contact
services
Eyeglass Repair
Fix your lenses
Eyeglass Fittings
Get measured
Eye Counsel
Discover what you need
Book Appointment


In addition to income and poverty level data, awareness of the rate and type of public assistance in our neighborhoods can help inform stakeholders at a deeper level of the kinds of challenges residents are facing.
| Public assistance - household | % change | - | - | CV | MOE (+/-) |
|---|---|---|---|---|---|
|
The black vertical bars show the indicator's margin of error (MOE). |
|||||
| Public assistance - individuals | |||||
Source: U.S. Census Bureau
Margin of Error (MOE): The MOE, reported along with an estimate, means that one can be 90 percent confident that the true value is the estimated value, plus or minus the MOE. More information here.
Coefficient of Variation (CV): a measure of reliability of the ACS estimate. The Census provides the following guidelines for determining the reliability of the estimate:
Coefficient of Variance <15% - Good
Coefficient of Variance >15% and < 61% - Fair
Coefficient of Variance >= 61% - Poor


Hello friends and family...Welcome to our birth fund!
Our Story
This summer, Brian and I moved across the country from DC to CA. We traveled with our clothes, books, and our 14 week old son in my belly. In Oakland, we live a very simple, cost-efficient, and healthy life and as we plan our future together (jobs, finding a permanent home, the start-up, the birth of our baby), we are making very intentional decisions about how spend our money and time.
In preparation for our baby's arrival, we are asking friends and family to donate to our homebirth fund instead of buying a gift. Especially since we have most of the big ticket items thanks to The Zaragoza and Wohlgemuth Families :]
Our decision to birth our son at home was made with the hope and faith that we can begin this journey in an empowering, affirming space without unnecessary interventions. A healthy woman having vaginal birth is the most natural thing that can take place on the face of the planet. I am so thankful that our baby and I are healthy enough to be candidates for a natural home birth. Ultimately, we have taken as many steps to ensure that we are mindfully prepared to receive this gift from God and the universe.
If you prefer to buy a gift, we do have a few items on our registry.Team
Midwife
Shannon Staloch, Certified Professional Midwife (CPM) and Board Certified Lactation Consultant brings the most wholesome, positive energy and is extremely passionate about cultivating a natural, welcoming, safe environment for all three of us.
Midwifery care includes:
- Prenatal appointments every 4 weeks until 27 weeks, every two weeks until 36 weeks, and weekly until birth
- Care throughout labor and home birth
- Breastfeeding and lactation support
- Postpartum care in our home to ensure mother and baby wellness until 6 weeks after the baby is born
- Gentle and complete newborn examinations
Doula
Lenore Palumbo, Certified Birth and Postpartum Doula and Nutritional Therapist, is equipped with mindful comfort and massage techniques. We had instant chemistry with her specifically because of her expertise in nutrition and she speaks Spanish :)
Doula services include:
- 2 Prenatal appointments to discuss birth plan + comfort techniques + childbirth education
- Unlimited phone consultations throughout pregnancy and post-partum
- 24 hour on-call availability after 36 weeks
- Emotional support during early labor and throughout birth
Both offer holistic (nutrition, physical, emotional) 1 hour prenatal appointments in our home.
In case, you want to learn more about home births and doulas, we encourage you to visit Homemade Families. and Holistic Belly, respectively.


@@include(".includes/before.html")
| Staff Sergeants |
| Abuk | |
| Clarke | |
| Ryujin | |
|
| Specialists |
| Addon Reviewer | Bull | |
| Training Manager | Dachi | |
| Template Developer | Freghar | |
| Member Manager | Goat | |
| Django Developer | Supreme | |
|
| Interviewing |
| Manager | Ryujin | |
| Interviewer | Abuk | |
| Interviewer | Akado | |
| Interviewer | Dusky | |
| Interviewer | Goat | |
| Interviewer | Ionaru | |
| Interviewer | Xerses | |
|
| Mission Making |
| Manager | Ryujin | |
| Mission Maker | Anders | |
| Mission Maker | Dachi | |
| Mission Reviewer | Ryujin | |
|
| Research & Development |
| Addon Reviewer | Bull | |
| Template Developer | Freghar | |
|
| Design Team |
| Django Developer | Supreme | |
| Graphics Designer | Tiloup | |
|
| Training Team |
| Manager | Dachi | |
| Trainer | Abuk | |
| Trainer | Ryujin | |
|
@@include(".includes/after.html")


| Job | Description | Contingent Worker | Action |
|---|---|---|---|
| 5185 | Light Industrial I | Katy Matthews | Progress |
| 5121 | Registered Physical Therapist | Nicky Boy | Progress |
| 5051 | SQL Programmer | Alex Paner | Progress |
| 5007 | Programmer 1 | Adam Smith | Progress |
| 4998 | Programmer/Analyst II | Andy Dufresne | Progress |
| 4995 | Programmer/Analyst II | Jane Wilson | Progress |


Installing the Ragnarok Wizard
Current Repository Version: 1.1
Instructions for adding this repo:
- Go to the Kodi file manager
- Click on "Add source"
- The path for the source is
https://RagnarLothbrok-Odin.github.io
- Name it "Ragnar" without the quotes
- Go to "Add-ons"
- Select "Install from zip file".
- When it asks for the location, select "Ragnar".
- For Ragnarok Wizard, install
repository.ragnarokwizard-1.1.zip
- Go back to "Add-ons" and select "Install from repository"
- Select "RagnarokWizard Repository"
- Select "Program add-ons" and install "Ragnarok Wizard"
helo


Documentation
Middlewares
Fastify provides out of the box an asynchronous middleware engine compatible with Express and Restify middlewares.
If you need a visual feedback to understand when the middlewares are executed take a look to the lifecycle page.
Fastify middlewares don’t support the full syntax middleware(err, req, res, next)
, because error handling is done inside Fastify.
Also, if you are using Middlewares that bundles different small middlewares, such as helmet, we recommend to use the single modules to get better performances.
fastify.use(require('cors')())
fastify.use(require('dns-prefetch-control')())
fastify.use(require('frameguard')())
fastify.use(require('hide-powered-by')())
fastify.use(require('hsts')())
fastify.use(require('ienoopen')())
fastify.use(require('x-xss-protection')())
or, in the specific case of helmet, you can use the fastify-helmet plugin, which is an optimized helmet integration for fastify:
const fastify = require('fastify')()
const helmet = require('fastify-helmet')
fastify.register(helmet)
Restrict middleware execution to a certain path(s)
If you need to run a middleware only under certain path(s), just pass the path as first parameter to use
and you are done!
Note that this does not support routes with parameters, (eg: /user/:id/comments
) and wildcard is not supported in multiple paths.
const serveStatic = require('serve-static')
// Single path
fastify.use('/css', serveStatic('/assets'))
// Wildcard path
fastify.use('/css/*', serveStatic('/assets'))
// Multiple paths
fastify.use(['/css', '/js'], serveStatic('/assets'))


Default Menu One Menu Two Menu Three Menu Four Center Align .o-menu .o-menu--center Menu One Menu Two Menu Three Menu Four Right Align .o-menu .o-menu--right Menu One Menu Two Menu Three Menu Four Space Around .o-menu .o-menu--space-around Menu One Menu Two Menu Three Menu Four Space Between .o-menu .o-menu--space-between Menu One Menu Two Menu Three Menu Four Responsive @mobile-tablet Menu One Menu Two Menu Three Menu Four Responsive @mobile Menu One Menu Two Menu Three Menu Four


// an fd to redirect and pop it, else leave it in as part of
// the command line.
try:
try_num = int(node.command[-1])
if try_num > 0:
num = try_num
node.command.pop()
n = int(self.peek.t)
redirect_target = ("&", n)
self.consume("number")
parts.append(Node(kind="redirect", input=num, type=redirect_kind,
output=redirect_target, pos=(start, self.token.end)))
tt = self.peek_token()
return parts, node is None


--- layout: page title: About header-img: "img/about-bg.png" ---
Live sound engineer, audio engineer, music producer, and a photographer. Joined Flatiron to gain some coding skills and add it to my list.


Boy Howdy!
Didn't see you there.
Keep Going. Because you didn't come this far just to come this far.
how about them cowboys
Sign Card
Sign


{% extends "base-site-error.html" %} {% block title %} Page 403 {% endblock %} {% block content %}
We are sorry but you are not authorized to consult this page…


Disclaimer: This is a third-party implementation. The original authors stated that they will be releasing their code soon.
Implementation GitHub repo link: https://github.com/seungwonpark/melgan
Audio samples from original authors: https://melgan-neurips.github.io/
In summary, MelGAN can convert mel-spectrograms into raw audio at real-time on CPU, and it generalizes to unseen speakers with significantly fewer parameters than previous state-of-the-art, WaveGlow.
All audios below are unseen during training. We split LJSpeech-1.1 into 9:1 for train/validation.
| Epochs | LJ001-0005.wav | LJ001-0015.wav | LJ014-0285.wav |
|---|---|---|---|
| Original | |||
| Epoch 400 | |||
| Epoch 800 | |||
| Epoch 1350 | |||
| Epoch 1600 | |||
| Epoch 3200 | Training in progress |
Training in progress |
Training in progress |
All details are shown in GitHub repository's README. Thank you!
Implementation author: Seungwon Park, Myunchul Joe @ MINDsLab | Rishikesh @ DeepSync Technologies Pvt Ltd.