Technical Writing 101 🇺🇦
1.6K subscribers
244 photos
3 videos
12 files
418 links
Anything's A Documentation If You're Brave Enough

👋 @SuckMyNuts
Download Telegram
Что-то в последнее время то ли меньше времени на поиск и чтение всяких полезностей стало, то ли потеплело и пипл разленился писать.
Если вдруг у вас есть чем поделиться, чего еще небыло тут - милости прошу, кидайте всякое на @SuckMyNuts

Сегодня микростатейка про "дружбу, не вражду" UX и Тех. Документации

https://medium.com/gsoft-tech/docs-and-ux-its-a-collaboration-not-a-competition-b5076390c87a

А еще в новомодных GitHub'овских Actions появилась линтовка с помощью Vale, зацените, но оно оч сырое:

https://github.com/marketplace/actions/vale-lint

#uiux #testthedocs #tool
Давненько в закладках лежит хороший разбор плюшек, которые предоставляют Docz, Storybook и Styleguidist для интерактивной документации UI-компонентов (и API'шек)

Кроме того, в статье хорошим и понятным языком рассказывают, что такое MDX

https://css-tricks.com/front-end-documentation-style-guides-and-the-rise-of-mdx/

#uiux #tool #en
Хороший, годный цикл постов про дружбу Markdown + ConTeXt (типографский брат LaTeX) и Pandoc

Зачем?

Отделение текста документа от его внешнего вида (цвета, шрифты и макет) позволяет создавать единообразный фирменный стиль, упрощать сопровождение документации, упрощает совместное редактирование, встраивание всяческой CG-инфы, позволяет одновременно публиковать в нескольких форматах и повысить производительность.

1. https://dave.autonoma.ca/blog/2019/05/22/typesetting-markdown-part-1/
2. https://dave.autonoma.ca/blog/2019/05/29/typesetting-markdown-part-2/
3. https://dave.autonoma.ca/blog/2019/06/16/typesetting-markdown-part-3/
4. https://dave.autonoma.ca/blog/2019/06/23/typesetting-markdown-part-4/

#visual #uiux #en #markdown
This media is not supported in your browser
VIEW IN TELEGRAM
Просто влюбился в Purple Numbers. Это же намного круче и удобнявее простых якорей на заголовки. Тут отличный пример и немного про сами Purple Numbers.

#uiux #tool #en
Часто работаешь с интерфейсами? Мож изредка делаешь опросничек-другой в помощь менеджменту? А может ты тесно завязан на продукт? Учись делать правильно и помогай тем, кто пока еще делает не до конца правильно.

Рекомендации по использованию чекбоксов и *chuckles* радиокнопок:

- Checkboxes vs. Radio Buttons

У статьи хороший финал, где объясняют, почему нужны эти гайдлайны и что это не пустой трёп и что "if you don't, you'll be taken for an amateur."

#visual #uiux #en #article #resource
Не совсем техрайтинг, но буквы и цифры все еще присутствуют и я думаю в наших (техрайтерских) силах влиять на такое — пропорциональный vs моноширинный шрифты в динамических элементах интерфейса.

https://blog.usejournal.com/proportional-vs-monospaced-numbers-when-to-use-which-one-in-order-to-avoid-wiggling-labels-e31b1c83e4d0

Просто посмотрите на приведенные примеры-картинки в статье. Меня, лично, очень бэдит с такого, давайте вместе стараться, чтобы вот так небыло.

#uiux #visual #en #resource
Читая местные техрайт чаты и наблюдая повторяющиеся изо дня в день вопросы, всё меньше боюсь постить сюда что-то очевидное (но, конечно, полезное), поэтому ловите 9 действительно хороших, годных советов по UX-райтингу (не обращайте внимание на название статьи, внутри релевантно):

https://medium.com/@johnamwill/9-simple-but-powerful-ux-writing-tips-for-designers-83ec1ca96561

#uiux #article #en
Несколько дельных советов UX писателям о том, как повысить свою визибилити (простите я устал) и получить больше признания а работу, которую вы делаете!

Words matter. Writers matter. You matter.

https://medium.com/dropbox-design/getting-a-seat-at-the-table-as-a-ux-writer-da63303d5b1d

#uiux #en #article #resource
В последние пару недель приходится усиленно макать свои лапки в UX|UI писательство, а точнее — в онбординг в не самом простом приложении. Продавать буквами куда сложнее, чем объяснять что-то ими, поэтому всегда держите в уме вот эту простую весч:

https://www.useronboard.com/features-vs-benefits/

Вы продаёте пользователю не продукт или какие-то фичи, вы продаете им улучшенную версию самих себя. Да, звучит банально и избито, но стоит один раз по настоящему вдуматься в эту фразу и в голове что-то щёлкнет, и все станет на свои места.

Мой пример: целевая аудитория нашего приложения это в первую очередь манагеры, владельцы компаний (читай очень занятые люди, чье время стоит дорого). Вот такому человеку, попавшему в ваш сервис без разницы сколько фич он сейчас увидит в онбординге, насколько красивые будут нарисованы иллюстрации и уж точно ему будет насрать на то, сколько месяцев вы всё это продумывали, вы должны здесь и сейчас дать ему понять, что сейчас будет происходить не двухчасовое заполнение всего и вся, а экономия его времени. Мы продаем не продукт, мы продаем сэкономленное время.

Конечно же я не имею в виду, что не нужно рисовать красивые иллюстрации и прописывать грамотно всякие feature-flow, просто делать это нужно держа в уме всё вышесказанное и строить онбординг-экспириенс отталкиваясь именно от этих простых, казалось бы, истин

#uiux #en #article #visual
Гигантский монструозный лонгридище из 7 частей от "Богов Поиска" - Algolia. Рассказывают о том как они редизайнили свою документацию, от причин зачем это всё и UI/UX решений, вплоть до самого писательства и nitty-gritty технических моментиков.

1. Redesigning Our Docs – Part 1 – Why
2. Redesigning our Docs – Part 2 – Making Technical Content Readable for Everybody
3. Redesigning Our Docs – Part 3 – The UX/UI Phase
4. Redesigning Our Docs – Part 4 – Building a Scalable CSS Architecture
5. Redesigning Our Docs – Part 5 – Building an Interactive InstantSearch Showcase
6. Redesigning our Docs – Part 6 – The processes and logistics of a large scale project
7. Redesigning our Docs – Part 7 – What’s next to come

Бонусным треком статья от них же про API документацию с посылом и о том, что счастье не в тулзах с помощью которых это всё делается, а в деньгах, которые за это платятся, а в самом подходе к структурированию этой информации и в самом контенте. Иными словами тулинг должен заботить пусть и не в последнюю очередь, но и уж точно не в первую. Adapt the tool to the content, not vice versa.

Good API Documentation Is Not About Choosing the Right Tool

#API #en #article #resource #uiux
Kubeflow активно опенсорсит свои процессы, в этой статье (https://medium.com/kubeflow/the-making-of-kubeflow-1-0-designing-for-stability-and-broad-market-adoption-a190358e96b6) можно найти ссылки и посмотреть как у больших дядь устроены Док-спринты и вообще поглазеть на их борды и порыться в процессах и полисях. Ну это так, для общего развития.

#uiux #en #resource #article
Делюсь с вами своей самой свежей болью, которую можно было бы решить/избежать грамотным сообщением об ошибке и наняв хотя бы одного техписа/ux-писателя.

Имеем: Sony PlayStation Network, мое желание купить игру, очень агрессивная и недокументированная анти-fraud система, очевидное отсутствие техписателя.

1. Жму, значится, я кнопку "Купить и оплатить игру", получаю ошибку "при обработке заказа произошла ошибка. Попробуйте повторить позже" (капитализация и пунктуация сохранены);
2. Меняю карту оплаты на ту, на которой есть деньги;
3. По совету сообщения об ошибке пробую еще раз;
4. Получаю аналогичную ошибу;
5. Звоню в техподдержку, где мне говорят, что уже после первой попытки из пункта 1 я получил бан транзакций на 24 часа (по другим сведениям неделя и больше).

Зачем было советовать попробовать еще раз, если за это я получу бан (возможно продлённый, возможно повторный)? Почему было не уведомить о существующей, как я понял, годами системе? Почему не сказать о бане на nn недель/nn часов или хотя бы вообще о бане? Почему не добавить код ошибки к этому сообщению, когда во всей остальной системе PlayStation любая ошибка содержит в себе соответствующий код, который легчайше гуглится?

Из этого получается:

1. Очень (очень) недовольный клиент;
2. ОЧЕНЬ загруженную техподдержку, которой приходится тратить время на выслушивание моей боли, на поиск моего аккаунта, на информирование меня о моем бане;
3. Испорченный имидж компании, которая буквально из имеющейся налички может строить дома, но не в силах нанять техписателя (и, судя по постоянно отваливающейся логин форме на официальном сайте, и программиста);
4. Потерянные приколы за предзаказ игры, который заканчивается через 4 дня;
5. Потерянные 20% кэшбека в честь карантина, который заканчивается еще через несколько дней.

Так ли должны работать многомиллиардные компании с крупнейшей юзербазой игроков в мире? Не уверен.

#uiux #example #en
Нужно написать релиз ноуты? Чейнджлоги? А вдохновения нет?

А может их никто и не читает вообще и можно написать туда абы что?

Ответы на эти и еще многие другие вопросы в прекрасной статье про искусство написания релиз ноутов:

https://uxdesign.cc/the-art-of-writing-great-release-notes-6607e22efae1

#cnahgelog #en #uiux
Залежалась в закладках статья (статья старая, кидал вам её сюда еще в 2018, а перевод свежий 🇷🇺) про UX Writing от Гугла.

Статья особенно полезна примерами как делать и как не.

Там и про бренд войс и про тон и, собственно, очень полезный чеклист, чтобы ничего не упустить! Если не осилили её на английском, крайне советую прочитать сейчас

#uiux #ru #en #article
Есть такой сайтик, зовется goodui, на этом сайте постят примеры и результаты A/B тестирования крупнейших компаний: Amazon, Netflix, Airbnb, Etsy, Google и иже с ними.

Да, сайт посвящен в основном UI-решениям и паттернам, но и для нас, техписов, можно найти в этом ценность. Помимо того, что это просто дико интересно, т.к очень много информации на сайте берется из слитых скринов внутренней кухни, мы еще можем убедиться в пользе структурирования и упорядочивания всего и вся, и немного поучиться UX-райтингу у больших дядь.


На скрине к посту, например, пример эксперимента Amazon, где *кто бы мог подумать* структурированный и разложеный по полочкам контент оказался понятнее, читабельнее и впринципе приятнее глазу, чем полотно текста, которое выглядит автоматически сгенерированным, а-ля описания в Алиэкспресс.

#uiux #en #testthedocs
Причины менять интерфейсный текст могут быть очень, очень разные

https://twitter.com/MichaelSteeber/status/1334619509743874052?s=20

#example #uiux
👅 Языки:

#ru | #en

👷 Карьера:

#career — советы и всемозможные статьи о карьере техписателя
#conference — техписательские конференции, их записи и заметки
#resources — ресурс для саморазвития
#article — полезная статья, которая учит чему-то клёвому, что позволит стать более лучшим писателем
#vacancy — интересная вакансия или что-то связанное с наймом
#video — видео, видос, видосичек, видосюлька. И подкасты!
#book — книга/хендбук
#courses — курсы, программы для технических писателей

🛠 Технологии:

#tool — полезная утилита/приложение
#changelog — все о чейнджлогах, примеры, правила
#markdown — все о языке разметки Markdown
#reStructuredText — все о языке разметки reStructuredText
#asciidoc — все о языке разметки asciidoc
#LaTeX — все систему набора и вёрстки и язык разметки LaTeX
#ide — среды разработки и все что с ними связано
#vscode — все о Visual Studio Code, настройка, плагины, хитрости
#SSG — JAMStack, генераторы статических сайтов, Hugo, Jekyll, Antora, etc.
#testthedocs — тестирование документации, линтинг
#API — про документирование API, примеры, лайфхаки, подсказки
#diagram — про диаграммы (много про diagrams as a code), mermaid, UML
#screenshot — все про скриншоты, утилиты, сервисы и красивенькие фотоснимки экрана
#ai — про GPT, GitHub Copilot и прочее, где ИИ помогает нам писать

🧺 Общее:

#tonevoice — о правилах общения в документации
#language — что-то конкретно о языке, в основном английский
#legal — юридическая документация, лицензии
#styleguide — все о стилях и правилах
#DocsAsCode — все про подход к документации как к коду
#example — примеры документации (хорошие и плохие)
#uiux — интерфейсы, текст в интерфейсах, пользовательский опыт
#knowledgemanagement — менеджмент знаний, хранилища, тулзы, техники, советы и наблюдения
#versioning — про версионирование
#accessibility — все об аксессебилити в документации
#checklist — чеклист/шпаргалка
#vintage — винтажная документация, старые компьютеры, софт, техника, игры
#visual — про визуальную составляющую документации
#metrics — все о метриках документации
#random — что-то совсем косвенно относящееся к техписательству, юморески

Предлагайте новые хэштеги в комментариях!