Formats & Access

[ninavizz]

So... in an ideal workflow, designers manage styleguides. With an interest in contributing an edit to this styleguide, I just realized it's coded using various dev tools that require use of Terminal and a working knowledge of Git.

That's a participation showstopper for many designers (and unfortunately, for me). It's why many don't engage in FOSS projects. Would love to encourage @AnXh3L0 @elioqoshi and @uracreative folks to consider that with assembling future styleguides. WordPress, as an example, is an easy to use CMS that is also open-source; and a tool most designers are familiar with. Just FYI.

[elioqoshi]

Hi @ninavizz

Thanks for opening up this discussion. I'd like to address your concerns here and while their motivation is well intended, they only scratch the surface to a much more complex discussion, I'd argue.

So... in an ideal workflow, designers manage styleguides.

I think that's a rather wrong approach to tackle this. In an ideal workflow, there shouldn't be any "handoff" from designer to developer. Designers need to learn to work well with developers and vice versa. The scoping, technical requirements, feature sets and user flow a designer would require, would be impossible to come up with without a developer assisting with these. This process should go hand in hand and I think a designer solely managing a style guide of this kind (which includes a design system ready to be used by developers) is the wrong approach.

With an interest in contributing an edit to this styleguide, I just realized it's coded using various dev tools that require use of Terminal and a working knowledge of Git.

A static page generator tool like Jekyll (which can be hosted on git infrastructure, not requiring any database) was a requirement for this style guide as discussed with Freedom of the Press folks at the start of this work. I can understand you not being aware of this however since you joined the team at later date. There are various ways to edit Jekyll pages, such as Forestry, which has a similar experience to blogging on WordPress, but more lightweight: https://forestry.io/ A Command Line is also not necessary to do changes. GitHub Desktop is a great alternative which works well on all platforms, is open source and does everything needed via the graphical user interface. In fact this is how I would do changes to the pages (mind you, I never took the time to do things from the terminal).

WordPress, as an example, is an easy to use CMS that is also open-source; and a tool most designers are familiar with. Just FYI.

For a project like SecureDrop, WordPress should be a no-go since it requires a dedicated hosting server, requires a database (and hence backend technology, making it more heavy weight and prone to breaches, while Jekyll has no backend at all). One of the requirements for the SecureDrop style guide was to have it work fine without JavaScript, something which is close to impossible in WordPress. Seeing SecureDrop as a critical project (which protects lives in many cases as well) use JavaScript and a database for something as lightweight as a style guide brings up bigger problems than a higher barrier of entry for designers (which again is not true as far as I'm concerned). Of course, please correct me if I'm wrong with any of these points. @redshiftzero and @eloquence should know more about these technical decisions.

However at the end of the day, no, it's not required at all to know anything about the Terminal or Git to get started.

Generally there is always an opportunity to lower the barrier of entry, but that should be a collective effort and going from Zero to this style guide has not been a small achievement I'd like to think. We would be happy to make it even easier to contribute to the style guide, let us know how we can help and we can schedule some interviews to better understand the problems you bring up :)

[ninavizz]

Hi Elio:

Thanks for the thoughtful response—and I agree, it is definitely a bigger discussion than a single GitHub "issue."

You're right, I was not around at the beginning of the project—hence my comment was only intended as an "FYI" for consideration with future work. Not so much, this project... so pls do know, I'm not at all speaking on behalf of the SecureDrop team in my thoughts on this. Just one designer, to another. 😃

With a living artifact (which styleguides are), user-centric lifecycle needs not being prioritized at the outset is where I've seen most styleguides go wrong. Which sucks the hardest, because as you said—none are ever a small effort to create. If a styleguide cannot be maintained, added to, or edited by the designer(s), it's been my experience over ~20yrs that they get abandoned—and redundant efforts endeavored. Which is a wasteful bummer for everyone.

As such, a styleguide's chosen media should not exclude standard designer skillsets (basic HTML and CSS, as well as tools that more often than not tend to be proprietary). Often this is something we (designers) need to educate our clients about, if a full-time designer does not exist on a team. In the end, it's a consideration everyone will benefit from and is part of the value we have to offer projects. ✨

A few other 🤔 points:

• Creation vs Consumption. Developers are the primary consumers of styleguide content, whereas designers are the primary creators and custodians of that content. User centricity at work is optimizing for how the creators, custodians, and consumers need both ends of the create/consume continuum facilitated. Yes, developers write the code for the code snippets that go into a styleguide, and as such play a supportive role... but again, it's usually a designer who's responsible for plopping said snippet into the styleguide artifact (which positions the designer as a primary creator or custodian to optimize around).

• Custodianship. A styleguide is an artifact that documents final decisions, not an artifact to facilitate collaboration. Developers own administrative maintenance of an organization's GitHub, for instance... and designers own the maintenance of their org's styleguides. Sometimes we're creators, and in creation we always need to collaborate—but sometimes we're custodians of consumables for others on a broader project team, to guarantee project consistency.

• Standardized code snippets of UI elements is important, but historically those have been presented in styleguides as static/text code snippets with accompanying documentation to guide implementation. Many styleguides don't even exist as live code, rather as PDFs—again, because they're created by designers, to be consumed by developers. Of course, empathy (and similarly optimizing) for open source developers would block any designer with a brain from going the PDF route with FOSS projects, heh.

• In the interest of getting more designers from traditional backgrounds engaged in FOSS projects, it's extra critically important we advocate on their behalf with clients and project teams we work for/with. The barrier for non-technical designer participation in FOSS projects needs to be as low as possible. All good designers are always learning new things: new research techniques, new workshopping methods, keeping up with design patterns, and attending design events to learn from our peers. Learning new toolsets and/or coding languages is very secondary—and that's ok. Learning about design patterns is a low priority for developers. That's why we each have our expertise, and meet in the middle to work collaboratively.

• Wordpress is just one method I really like. I know a lot of teams don't like it, and those reasons are all legit, too.

Finally, please know: all of the above, is shared with all the respect in the world. I love what you've committed to do with Ura, and only want to see you guys rock it! ❤️

[elioqoshi]

Hey @ninavizz,

Excuse the delay in getting back here. Thanks for further clarifying your points, that helps understand where you are coming from :)

I generally agree with your notion here and in an ideal scenario, the workflow would more or less look like what you suggested. I'd like to think however that we had more important battles to pick at the beginning, going from zero to this state. Now that everyone digested it, it's a great time to think about the issues you highlight. I just read your original post as "this should have been done" rather than "it would be great to do this".

Assuming the latter, we would be happy to refresh the style guide and explore how we could make it more lightweight, easier to edit and generally more pleasant for non-developers to contribute. If Freedom of the Press and you would like to pursue that, I'd gladly join a UX call sometime in the coming weeks and we could talk about it. :)

[ninavizz]

Definitely "It would be great to do this" intended. My bad, if that was unclear. <3

And, sorry I missed you in Berlin. I had planned to attend, by have had issues with my passport's renewal and the US gov shutdown. It would have been ideal to discuss F2F.

All the above said: we're pretty slammed atm just wrestling some pressing release and Qubes Workstation things, together... but I'd love to take you up on your offer, once things have calmed! :)

In the meantime, if you'd like to join any of our calls to offer critique or thoughts on the work I'm currently doing, we need all the eyes and ears we can get and would welcome your contributions.

TTFN, n!