the design and programming
portfolio of marco segreto
Web Design Standards Perforamance Guide
To implement this guide a team was assembled to do user research
with different government agencies to see where website performance
was falling short. The team also researched different open
source tools for performance tracking and started to make some decisions
on how to best guide people. More details on the research can be
found on the
The research showed that most teams were not consistently tracking
performance as a project evolved and would benefit from doing so. Performance
tracking became the focus of the guide, with a bulk section on
implement performance tracking on almost any team. Additonally, there's
guidance on HTTP/2
and a glossary
of performance concepts.
Code for America is a
non-profit working to improve government technology through it's year-long
fellowship program and volunteer city brigade programs. I was part of
a panel discussion with three other experts talking about web accessibility
particularly related to the US Web Design Standards.
For the panel, we discussed how to effectively ensure a government
style system, such as the Web Design Standards, can remain accessible
for all that use it. A main point of the discussion was how to design
and develop with accessibility in mind from the start of the project,
continually keeping it at the forefront as new parts are added. This
contrasts with a more typical approach of fixing accessibility issues
at the end of a project before launch. I've found the tactic of keeping
accessibility in mind from the start and throughout a project is the most
effective method of ensuring the project is always accessible.
The specific pages for the talks at the summit have been taken
offline, but general information about the summit can be found
on the CFA Summit
How we share style across multiple sites 18F blog post
The cloud.gov, a PaaS for government,
front end has multiple different site's that all need a universal style
and consistency. In order to keep the styling code for these different
sites without having repition, a style library was needed that could be
brought into each of the different sites. This led to the creation of
cg-style or cloudgov-style, an npm deployable style library.
Having found that many other 18F and government projects also required
sharing styles between multiple sites or repositories, I wrote a blog
post to articulate the benefits and difficulties of maintaining a
shared style library. It discusses the CSS architecture, how we used
SVG to create adaptable icons, how we distributed the library to make
it easy to include and update, and the continuous integration and release
process for the library.
A technical document to provide 18F and government developers with
guidance on best practices for writing CSS.
In order to address the problem of hard to maintain CSS at 18F
, I did user research interviews with developers on the 18F
team to find what the largest problems were in CSS codebases. I found
that code style was inconsistent, there were bad practices around
having too high of specificity and organization and naming conventions
were not well defined.
After having looked for comprehensive style guides that reflected
18F's values and character and not finding anything that matched well,
it was decided I would write an 18F CSS Styleguide to be used
internally and shared around the government. This guide includes
general CSS formatting guidance, how to architect CSS, naming schemes
and much more on how to write great CSS. The CSS guide was eventually
folded in with a larger front end guide for 18F.