Что-то в последнее время то ли меньше времени на поиск и чтение всяких полезностей стало, то ли потеплело и пипл разленился писать.
Если вдруг у вас есть чем поделиться, чего еще небыло тут - милости прошу, кидайте всякое на @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
Если вдруг у вас есть чем поделиться, чего еще небыло тут - милости прошу, кидайте всякое на @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
Medium
Docs and UX: It’s a collaboration, not a competition
A look at how technical documentation and UX are stronger together
Давненько в закладках лежит хороший разбор плюшек, которые предоставляют Docz, Storybook и Styleguidist для интерактивной документации UI-компонентов (и API'шек)
Кроме того, в статье хорошим и понятным языком рассказывают, что такое MDX
https://css-tricks.com/front-end-documentation-style-guides-and-the-rise-of-mdx/
#uiux #tool #en
Кроме того, в статье хорошим и понятным языком рассказывают, что такое MDX
https://css-tricks.com/front-end-documentation-style-guides-and-the-rise-of-mdx/
#uiux #tool #en
CSS-Tricks
Front-End Documentation, Style Guides And The Rise Of MDX | CSS-Tricks
You can have the best open source project in the world but, if it doesn’t have good documentation, chances are it’ll never take off. In the office, good
Хороший, годный цикл постов про дружбу 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
Зачем?
Отделение текста документа от его внешнего вида (цвета, шрифты и макет) позволяет создавать единообразный фирменный стиль, упрощать сопровождение документации, упрощает совместное редактирование, встраивание всяческой 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
Technical Writing 101 🇺🇦
Хороший, годный цикл постов про дружбу Markdown + ConTeXt (типографский брат LaTeX) и Pandoc Зачем? Отделение текста документа от его внешнего вида (цвета, шрифты и макет) позволяет создавать единообразный фирменный стиль, упрощать сопровождение документации…
Чувак неугомонно продолжает писать годные гайды про Markdown + ConTeXt.
Там уже пошли расчёты, R Markdown, CSV, YAML. Ловите 5, 6 и 7 части цикла:
https://dave.autonoma.ca/blog/2019/07/06/typesetting-markdown-part-5/
https://dave.autonoma.ca/blog/2019/07/11/typesetting-markdown-part-6/
https://dave.autonoma.ca/blog/2019/08/06/typesetting-markdown-part-7/
#visual #uiux #en #markdown
Там уже пошли расчёты, R Markdown, CSV, YAML. Ловите 5, 6 и 7 части цикла:
https://dave.autonoma.ca/blog/2019/07/06/typesetting-markdown-part-5/
https://dave.autonoma.ca/blog/2019/07/11/typesetting-markdown-part-6/
https://dave.autonoma.ca/blog/2019/08/06/typesetting-markdown-part-7/
#visual #uiux #en #markdown
dave.autonoma.ca
Typesetting Markdown – Part 5: Interpolation (Dave Jarvis)
Software development blog
Часто работаешь с интерфейсами? Мож изредка делаешь опросничек-другой в помощь менеджменту? А может ты тесно завязан на продукт? Учись делать правильно и помогай тем, кто пока еще делает не до конца правильно.
Рекомендации по использованию чекбоксов и *chuckles* радиокнопок:
- Checkboxes vs. Radio Buttons
У статьи хороший финал, где объясняют, почему нужны эти гайдлайны и что это не пустой трёп и что "if you don't, you'll be taken for an amateur."
#visual #uiux #en #article #resource
Рекомендации по использованию чекбоксов и *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
https://blog.usejournal.com/proportional-vs-monospaced-numbers-when-to-use-which-one-in-order-to-avoid-wiggling-labels-e31b1c83e4d0
Просто посмотрите на приведенные примеры-картинки в статье. Меня, лично, очень бэдит с такого, давайте вместе стараться, чтобы вот так небыло.
#uiux #visual #en #resource
Medium
Proportional vs. Monospaced Numbers: When to use which one in order to avoid “Wiggling Labels”
Читая местные техрайт чаты и наблюдая повторяющиеся изо дня в день вопросы, всё меньше боюсь постить сюда что-то очевидное (но, конечно, полезное), поэтому ловите 9 действительно хороших, годных советов по UX-райтингу (не обращайте внимание на название статьи, внутри релевантно):
https://medium.com/@johnamwill/9-simple-but-powerful-ux-writing-tips-for-designers-83ec1ca96561
#uiux #article #en
https://medium.com/@johnamwill/9-simple-but-powerful-ux-writing-tips-for-designers-83ec1ca96561
#uiux #article #en
Medium
9 simple but powerful UX writing tips for designers
In Design in Tech 2017, John Maeda’s seminal annual report, Maeda notes that “code is not the only unicorn skill.” His nomination for the…
Несколько дельных советов 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
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
Medium
Getting a seat at the table as a UX writer
It’s time to pull up a chair.
В последние пару недель приходится усиленно макать свои лапки в UX|UI писательство, а точнее — в онбординг в не самом простом приложении. Продавать буквами куда сложнее, чем объяснять что-то ими, поэтому всегда держите в уме вот эту простую весч:
https://www.useronboard.com/features-vs-benefits/
Вы продаёте пользователю не продукт или какие-то фичи, вы продаете им улучшенную версию самих себя. Да, звучит банально и избито, но стоит один раз по настоящему вдуматься в эту фразу и в голове что-то щёлкнет, и все станет на свои места.
Мой пример: целевая аудитория нашего приложения это в первую очередь манагеры, владельцы компаний (читай очень занятые люди, чье время стоит дорого). Вот такому человеку, попавшему в ваш сервис без разницы сколько фич он сейчас увидит в онбординге, насколько красивые будут нарисованы иллюстрации и уж точно ему будет насрать на то, сколько месяцев вы всё это продумывали, вы должны здесь и сейчас дать ему понять, что сейчас будет происходить не двухчасовое заполнение всего и вся, а экономия его времени. Мы продаем не продукт, мы продаем сэкономленное время.
Конечно же я не имею в виду, что не нужно рисовать красивые иллюстрации и прописывать грамотно всякие feature-flow, просто делать это нужно держа в уме всё вышесказанное и строить онбординг-экспириенс отталкиваясь именно от этих простых, казалось бы, истин
#uiux #en #article #visual
https://www.useronboard.com/features-vs-benefits/
Вы продаёте пользователю не продукт или какие-то фичи, вы продаете им улучшенную версию самих себя. Да, звучит банально и избито, но стоит один раз по настоящему вдуматься в эту фразу и в голове что-то щёлкнет, и все станет на свои места.
Мой пример: целевая аудитория нашего приложения это в первую очередь манагеры, владельцы компаний (читай очень занятые люди, чье время стоит дорого). Вот такому человеку, попавшему в ваш сервис без разницы сколько фич он сейчас увидит в онбординге, насколько красивые будут нарисованы иллюстрации и уж точно ему будет насрать на то, сколько месяцев вы всё это продумывали, вы должны здесь и сейчас дать ему понять, что сейчас будет происходить не двухчасовое заполнение всего и вся, а экономия его времени. Мы продаем не продукт, мы продаем сэкономленное время.
Конечно же я не имею в виду, что не нужно рисовать красивые иллюстрации и прописывать грамотно всякие feature-flow, просто делать это нужно держа в уме всё вышесказанное и строить онбординг-экспириенс отталкиваясь именно от этих простых, казалось бы, истин
#uiux #en #article #visual
UserOnboard
Never Mix Up Features with Benefits Ever Again | UserOnboard | User Onboarding
People don't buy products; they buy better versions of themselves. See how to help your prospects succeed!
Гигантский монструозный лонгридище из 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
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 документацию с посылом и о том, что счастье не в тулзах с помощью которых это всё делается,
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
#uiux #en #resource #article
Medium
The Making of Kubeflow 1.0: Designing for stability and adoption
An update from the Kubeflow Community Product Management Team
Делюсь с вами своей самой свежей болью, которую можно было бы решить/избежать грамотным сообщением об ошибке и наняв хотя бы одного техписа/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
Имеем: 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
А может их никто и не читает вообще и можно написать туда абы что?
Ответы на эти и еще многие другие вопросы в прекрасной статье про искусство написания релиз ноутов:
https://uxdesign.cc/the-art-of-writing-great-release-notes-6607e22efae1
#cnahgelog #en #uiux
Medium
The art of writing great release notes
One of the first tasks I was given as a technical writer was writing a set of release notes. For the most part it involved pulling…
Залежалась в закладках статья (статья старая, кидал вам её сюда еще в 2018, а перевод свежий 🇷🇺) про UX Writing от Гугла.
Статья особенно полезна примерами как делать и как не.
Там и про бренд войс и про тон и, собственно, очень полезный чеклист, чтобы ничего не упустить! Если не осилили её на английском, крайне советую прочитать сейчас
#uiux #ru #en #article
Статья особенно полезна примерами как делать и как не.
Там и про бренд войс и про тон и, собственно, очень полезный чеклист, чтобы ничего не упустить! Если не осилили её на английском, крайне советую прочитать сейчас
#uiux #ru #en #article
Medium
UX Writing: How to do it like Google with this powerful checklist
Notes from Google I/O 2017 on choosing the right words
Есть такой сайтик, зовется goodui, на этом сайте постят примеры и результаты A/B тестирования крупнейших компаний: Amazon, Netflix, Airbnb, Etsy, Google и иже с ними.
Да, сайт посвящен в основном UI-решениям и паттернам, но и для нас, техписов, можно найти в этом ценность. Помимо того, что это просто дико интересно, т.к очень много информации на сайте берется из слитых скринов внутренней кухни, мы еще можем убедиться в пользе структурирования и упорядочивания всего и вся, и немного поучиться UX-райтингу у больших дядь.
На скрине к посту, например, пример эксперимента Amazon, где *кто бы мог подумать* структурированный и разложеный по полочкам контент оказался понятнее, читабельнее и впринципе приятнее глазу, чем полотно текста, которое выглядит автоматически сгенерированным, а-ля описания в Алиэкспресс.
#uiux #en #testthedocs
Да, сайт посвящен в основном UI-решениям и паттернам, но и для нас, техписов, можно найти в этом ценность. Помимо того, что это просто дико интересно, т.к очень много информации на сайте берется из слитых скринов внутренней кухни, мы еще можем убедиться в пользе структурирования и упорядочивания всего и вся, и немного поучиться UX-райтингу у больших дядь.
На скрине к посту, например, пример эксперимента Amazon, где *кто бы мог подумать* структурированный и разложеный по полочкам контент оказался понятнее, читабельнее и впринципе приятнее глазу, чем полотно текста, которое выглядит автоматически сгенерированным, а-ля описания в Алиэкспресс.
#uiux #en #testthedocs
Причины менять интерфейсный текст могут быть очень, очень разные
https://twitter.com/MichaelSteeber/status/1334619509743874052?s=20
#example #uiux
https://twitter.com/MichaelSteeber/status/1334619509743874052?s=20
#example #uiux
Twitter
M1 battery life is so good that the macOS UX writers will need to redefine “soon”
👅 Языки:
#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 — что-то совсем косвенно относящееся к техписательству, юморески
Предлагайте новые хэштеги в комментариях!
#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 — что-то совсем косвенно относящееся к техписательству, юморески
Предлагайте новые хэштеги в комментариях!