Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move talk descriptions from "abstract" key to "description" key #1178

Merged
merged 7 commits into from
Aug 3, 2024
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@
{
"abstract": "Over the course of 2018 I planned and helped execute a complete, ongoing\nrewrite of about 1000 pages of documentation - changing the markup\nlanguage, the focus (feature to user story), and the structure (linear\nto modular) - without actually being in charge of strategy, scheduling,\ntooling, or content.\n\nThis talk charts the process and provides recommendations for others\nattempting to instigate massive change on multiple fronts.\n",
"copyright_text": null,
"description": "Write the Docs Australia 2018",
"description": "Over the course of 2018 I planned and helped execute a complete, ongoing\nrewrite of about 1000 pages of documentation - changing the markup\nlanguage, the focus (feature to user story), and the structure (linear\nto modular) - without actually being in charge of strategy, scheduling,\ntooling, or content.\n\nThis talk charts the process and provides recommendations for others\nattempting to instigate massive change on multiple fronts.\n",
"duration": 1438,
"language": "eng",
"recorded": "2018-11-15",
Expand Down
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@
{
"abstract": "I\u2019ll walk through how my team and I create an information experience\nthat feels human, helpful, and how we know if it\u2019s successful. Part of\nthat experience bridges the information gap between the messages you\nreceive before you log into an Atlassian product and the messages you\nreceive in the form of:\n\n- Introductory states\n- Blank states\n- Directional and instructive text in the app\n- UI copy and it's connection to user expectations and perceptions\n- Documentation and how it supports different functional journeys\n\nWe\u2019ll cover how working ahead of time with our marketing, content, and\nbrand teams allows us to know and influence user expectations throughout\ntheir early journey. We\u2019ll also talk about how far we have yet to go.\n",
"copyright_text": null,
"description": "Write the Docs Australia 2018",
"description": "I\u2019ll walk through how my team and I create an information experience\nthat feels human, helpful, and how we know if it\u2019s successful. Part of\nthat experience bridges the information gap between the messages you\nreceive before you log into an Atlassian product and the messages you\nreceive in the form of:\n\n- Introductory states\n- Blank states\n- Directional and instructive text in the app\n- UI copy and it's connection to user expectations and perceptions\n- Documentation and how it supports different functional journeys\n\nWe\u2019ll cover how working ahead of time with our marketing, content, and\nbrand teams allows us to know and influence user expectations throughout\ntheir early journey. We\u2019ll also talk about how far we have yet to go.\n",
"duration": 1697,
"language": "eng",
"recorded": "2018-11-15",
Expand Down
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@
{
"abstract": "Most industries have had what we might call an oh-no moment. It's those\nmoments that encourage industries to become better regulated, in order\nto prevent further disasters. The IT industry has had many moments that\ncould be considered consequential enough to encourage better regulation,\nbut the changes have never been made. Because the industry has avoided\neffective regulation for so long, it is possible that we are hurtling\ntowards a disaster of epic proportions, one that we haven't even managed\nto conceive of yet.\n\nIn this talk, I will go through some historical examples of disasters\nleading to regulation in other industries, and the measures that were\nput into place to mitigate the problem. I will also address some of the\nmajor moments from the IT industry that should have prompted regulation,\nand haven't. Finally, I will discuss ways that documentation\nprofessionals are uniquely placed to identify, and potentially blow the\nwhistle on, potential disasters before they happen.\n",
"copyright_text": null,
"description": "Write the Docs Australia 2018",
"description": "Most industries have had what we might call an oh-no moment. It's those\nmoments that encourage industries to become better regulated, in order\nto prevent further disasters. The IT industry has had many moments that\ncould be considered consequential enough to encourage better regulation,\nbut the changes have never been made. Because the industry has avoided\neffective regulation for so long, it is possible that we are hurtling\ntowards a disaster of epic proportions, one that we haven't even managed\nto conceive of yet.\n\nIn this talk, I will go through some historical examples of disasters\nleading to regulation in other industries, and the measures that were\nput into place to mitigate the problem. I will also address some of the\nmajor moments from the IT industry that should have prompted regulation,\nand haven't. Finally, I will discuss ways that documentation\nprofessionals are uniquely placed to identify, and potentially blow the\nwhistle on, potential disasters before they happen.\n",
"duration": 1466,
"language": "eng",
"recorded": "2018-11-15",
Expand Down
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@
{
"abstract": "Code review is the duty of every developer in a team. We are the guards\nof the mystical \u201cgood\u201d code and defenders against evil technical debt.\nIt\u2019s universally agreed that it\u2019s easy to spot \u201cbad\u201d code and much\nharder to determine \u201cgood\u201d code.\n\nI\u2019m going to share some of my experiences working on a team producing a\nlarge amount of code every day, with few reviewers. We\u2019ll dive into\nlooking for smart architectural and design decisions, coherently\nunderstanding what problem the author intended to solve and\nunderstanding how they implemented a solution.\n\nI\u2019ll touch on automating away the most common issues within Code Review\nand pulling the technical brains out of your team mates into great\ndocumentation. Most importantly we\u2019ll talk about the human side of code\nreview and how to manage code review within large and small teams. Code\nreview helps our teams grow institutional knowledge and shared\nunderstanding of the systems we build together. A strong understanding\nof how to review code will help you to write better code and help you\nhelp your teammates to write better code.\n",
"copyright_text": null,
"description": "Write the Docs Australia 2018",
"description": "Code review is the duty of every developer in a team. We are the guards\nof the mystical \u201cgood\u201d code and defenders against evil technical debt.\nIt\u2019s universally agreed that it\u2019s easy to spot \u201cbad\u201d code and much\nharder to determine \u201cgood\u201d code.\n\nI\u2019m going to share some of my experiences working on a team producing a\nlarge amount of code every day, with few reviewers. We\u2019ll dive into\nlooking for smart architectural and design decisions, coherently\nunderstanding what problem the author intended to solve and\nunderstanding how they implemented a solution.\n\nI\u2019ll touch on automating away the most common issues within Code Review\nand pulling the technical brains out of your team mates into great\ndocumentation. Most importantly we\u2019ll talk about the human side of code\nreview and how to manage code review within large and small teams. Code\nreview helps our teams grow institutional knowledge and shared\nunderstanding of the systems we build together. A strong understanding\nof how to review code will help you to write better code and help you\nhelp your teammates to write better code.\n",
"duration": 1188,
"language": "eng",
"recorded": "2018-11-15",
Expand Down
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@
{
"abstract": "The first few weeks at a new job are hard. There seem to be too many\nquestions and not enough answers, and so much assumed knowledge about\nthe company you joined and the products they make.\n\nI\u2019m going to talk about how you can make those first few weeks your most\nproductive and valuable to your new company. By writing internal\ndocumentation that answers all the questions only someone new on the\nblock knows to ask, you can help pave the way for new hires in the\nfuture, and even help identify and solve customer pain points.\n\nDrawing from my own experiences working as an intern and support agent\namong highly technical teams, I will go over deciding what to document\nbased on the level of technical proficiency you would expect the reader\nto have, how to use tone to convey the company\u2019s spirit and keep a\nfuture reader interested, and how to future-proof your internal\ndocumentation so it doesn\u2019t stop being updated when you move on.\n",
"copyright_text": null,
"description": "This video is about internal docs to teach the next hire what you've learned.",
"description": "The first few weeks at a new job are hard. There seem to be too many\nquestions and not enough answers, and so much assumed knowledge about\nthe company you joined and the products they make.\n\nI\u2019m going to talk about how you can make those first few weeks your most\nproductive and valuable to your new company. By writing internal\ndocumentation that answers all the questions only someone new on the\nblock knows to ask, you can help pave the way for new hires in the\nfuture, and even help identify and solve customer pain points.\n\nDrawing from my own experiences working as an intern and support agent\namong highly technical teams, I will go over deciding what to document\nbased on the level of technical proficiency you would expect the reader\nto have, how to use tone to convey the company\u2019s spirit and keep a\nfuture reader interested, and how to future-proof your internal\ndocumentation so it doesn\u2019t stop being updated when you move on.\n",
"duration": 1094,
"language": "eng",
"recorded": "2018-11-15",
Expand Down
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@
{
"abstract": "Software support teams are in a tough spot. They know documentation is\nimportant, and they love to refer customers to it, but finding time to\nactually write and maintain those documents is *really* hard.\n\nThat endless support queue and its ceaseless demand for attention mean\nthat documentation is too often ignored. Mat shares his hard earned\npractical advice to help technical writers and support team knowledge\nbase owners create a more effective documentation system.\n\nLearn why documentation falls behind, how to reduce support writing\nfriction and how other SaaS teams have made support an engine for great\ndocumentation.\n",
"copyright_text": null,
"description": "Write the Docs Australia 2018",
"description": "Software support teams are in a tough spot. They know documentation is\nimportant, and they love to refer customers to it, but finding time to\nactually write and maintain those documents is *really* hard.\n\nThat endless support queue and its ceaseless demand for attention mean\nthat documentation is too often ignored. Mat shares his hard earned\npractical advice to help technical writers and support team knowledge\nbase owners create a more effective documentation system.\n\nLearn why documentation falls behind, how to reduce support writing\nfriction and how other SaaS teams have made support an engine for great\ndocumentation.\n",
"duration": 1585,
"language": "eng",
"recorded": "2018-11-15",
Expand Down
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@
{
"abstract": "Creating high quality and engaging content is a challenge, but finding\nways to present that content to readers on a vast array of devices and\nhardware has been even more problematic. This session will explore best\npractices for enabling your content to automatically adapt to various\ncomputers, browsers, devices, and platforms. This is a rapidly changing\narea.\n\nIn this presentation Mike will cover the most recent developments in the\nindustry that have made responsive content presentation much easier for\ncontent authors. Mike will visit the concept of Media Queries and\ncompare that with the newer and easier techniques such as using the\nFlexBox Model. It has never been easier to ensure that your content is\npresented to your reader in an optimized manner.\n",
"copyright_text": null,
"description": "Write the Docs Australia 2018",
"description": "Creating high quality and engaging content is a challenge, but finding\nways to present that content to readers on a vast array of devices and\nhardware has been even more problematic. This session will explore best\npractices for enabling your content to automatically adapt to various\ncomputers, browsers, devices, and platforms. This is a rapidly changing\narea.\n\nIn this presentation Mike will cover the most recent developments in the\nindustry that have made responsive content presentation much easier for\ncontent authors. Mike will visit the concept of Media Queries and\ncompare that with the newer and easier techniques such as using the\nFlexBox Model. It has never been easier to ensure that your content is\npresented to your reader in an optimized manner.\n",
"duration": 1864,
"language": "eng",
"recorded": "2018-11-15",
Expand Down
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@
{
"abstract": "For any business that\u2019s producing a lot of documentation from a lot of\nhands, a style guide is a necessity. It can provide consistent quality\nacross documents, and over time it can lift the writing standard within\nyour organisation.\n\nThis talk will aim to cover:\n\n- What does your style guide need to contain?\n- What are the pitfalls that you need to consider?\n- How do you communicate the style guide across the organisation?\n",
"copyright_text": null,
"description": "Write the Docs Australia 2018",
"description": "For any business that\u2019s producing a lot of documentation from a lot of\nhands, a style guide is a necessity. It can provide consistent quality\nacross documents, and over time it can lift the writing standard within\nyour organisation.\n\nThis talk will aim to cover:\n\n- What does your style guide need to contain?\n- What are the pitfalls that you need to consider?\n- How do you communicate the style guide across the organisation?\n",
"duration": 1558,
"language": "eng",
"recorded": "2018-11-15",
Expand Down
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@
{
"abstract": "You have to write some docs. To do this, you need information from other\npeople.\n\nExcept that they're too busy, or in another office, or another timezone,\nor they just don't want to help. What do you do?\n\nThis talk will look at the psychology behind why we often don't get the\nhelp we ask for, how we can work with what we've got, and ways we can\nget information out of unwilling participants, in spite of themselves!\n",
"copyright_text": null,
"description": "Write the Docs Australia 2018",
"description": "You have to write some docs. To do this, you need information from other\npeople.\n\nExcept that they're too busy, or in another office, or another timezone,\nor they just don't want to help. What do you do?\n\nThis talk will look at the psychology behind why we often don't get the\nhelp we ask for, how we can work with what we've got, and ways we can\nget information out of unwilling participants, in spite of themselves!\n",
"duration": 1704,
"language": "eng",
"recorded": "2018-11-15",
Expand Down
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@
{
"abstract": "The most common perception around the term UX writing is that it only\nincludes microcopy for the user interfaces. However, that is not\ncorrect. Writing snappy messages on the UI is only a part of it; more\nimportant aspect is developing a voice for the product and imbibing that\nvoice in your content (UX, help, knowledge base, etc).\n\nThis talk covers some of the necessary skills required for being good at\nUX writing and how these skills help us in designing a better product\nexperience. Whether be it the decision of keeping the tone professional\nvs casual or using title case vs sentence case, decisions must be taken\nbased on the audience and should always be in-context.\n\nAnd yea, one last thing, technical writers are/can be great UX writers!\n",
"copyright_text": null,
"description": "Write the Docs Australia",
"description": "The most common perception around the term UX writing is that it only\nincludes microcopy for the user interfaces. However, that is not\ncorrect. Writing snappy messages on the UI is only a part of it; more\nimportant aspect is developing a voice for the product and imbibing that\nvoice in your content (UX, help, knowledge base, etc).\n\nThis talk covers some of the necessary skills required for being good at\nUX writing and how these skills help us in designing a better product\nexperience. Whether be it the decision of keeping the tone professional\nvs casual or using title case vs sentence case, decisions must be taken\nbased on the audience and should always be in-context.\n\nAnd yea, one last thing, technical writers are/can be great UX writers!\n",
"duration": 1357,
"language": "eng",
"recorded": "2018-11-15",
Expand Down
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@
{
"abstract": "As many documentation teams move towards a docs-as-code workflow, most\nare turning to static site generators like Jekyll, Sphynx, Hugo, or\nGitBook to turn that 'code' into user-facing documentation websites. In\nthis mini- workshop, you'll get an introduction to the static site\ngenerator landscape, and apply what you learn by publishing your own\nsite in class. We'll cover:\n\n- How static site generators work\n- Comparison of popular generators, with guidelines for choosing one\n for your next project\n- Hands-on editing and publishing of your own statically generated\n portfolio website\n",
"copyright_text": null,
"description": "Write the Docs Australia 2018",
"description": "As many documentation teams move towards a docs-as-code workflow, most\nare turning to static site generators like Jekyll, Sphynx, Hugo, or\nGitBook to turn that 'code' into user-facing documentation websites. In\nthis mini- workshop, you'll get an introduction to the static site\ngenerator landscape, and apply what you learn by publishing your own\nsite in class. We'll cover:\n\n- How static site generators work\n- Comparison of popular generators, with guidelines for choosing one\n for your next project\n- Hands-on editing and publishing of your own statically generated\n portfolio website\n",
"duration": 3479,
"language": "eng",
"recorded": "2018-11-15",
Expand Down
Loading
Loading