Suche
Beiträge, die mit InformationArchitecture getaggt sind
The ugly ducking theorem has relevance for all efforts at organization.
https://en.wikipedia.org/wiki/Ugly_duckling_theorem
Put simply, it states that all categorization systems are fundamentally arbitrary, once all possible attributes are considered.
It's basically "proof" that common sense is contextual. For me it shows that you need to deeply engage with the people who need to find (and return) the stuff, and always include "uncategorized" for the stuff that slips between the perfect system.
#informationArchitecture
https://en.wikipedia.org/wiki/Ugly_duckling_theorem
Put simply, it states that all categorization systems are fundamentally arbitrary, once all possible attributes are considered.
It's basically "proof" that common sense is contextual. For me it shows that you need to deeply engage with the people who need to find (and return) the stuff, and always include "uncategorized" for the stuff that slips between the perfect system.
#informationArchitecture
"The following are my suggestions regarding what else to consider for each of Daryl White’s excellent questions about choosing a toolset for documenting a software product or project.
I have appended a brief guide to the main/broad categories of documentation toolsets and some of the platforms/components that are popular in each.
Finally, this resource ends with a table of possible solutions for various scenarios you might find yourself in.
Before we start with the existing list of questions, I want to highlight one that I think is most important of all, but which is often assumed by people who create these kinds of guides, as they tend to come from one or another world already.
What are you documenting?
When it comes to software technical writing, the more appropriate way to ask this might be: For what user roles is your documentation intended?
For graphical end-user interfaces (GUIs), the largest range of docs tooling is available, but here some of the more commercial turnkey tools have most of their advantages.
For administrator interfaces (installation, configuration, etc), again any tooling will work, but we start seeing real advantages for lightweight markup, codebase integration, and version control.
For developer interfaces, docs-as-code offers significant advantages. Developers can better contribute directly, and it’s generally friendlier for coded samples. APIs (native and remote), SDKs, and CLIs are almost certainly best documented in a docs-as-code environment, even if you integrate it with a more conventional platform for end-user docs."
https://gist.github.com/briandominick/d4cbe11228de0ebe31cda630976af4ef
#TechnicalWriting #SoftwareDocumentation #Documentation #DocsAsCode #TechnicalCommunication #InformationArchitecture #CCMS
I have appended a brief guide to the main/broad categories of documentation toolsets and some of the platforms/components that are popular in each.
Finally, this resource ends with a table of possible solutions for various scenarios you might find yourself in.
Before we start with the existing list of questions, I want to highlight one that I think is most important of all, but which is often assumed by people who create these kinds of guides, as they tend to come from one or another world already.
What are you documenting?
When it comes to software technical writing, the more appropriate way to ask this might be: For what user roles is your documentation intended?
For graphical end-user interfaces (GUIs), the largest range of docs tooling is available, but here some of the more commercial turnkey tools have most of their advantages.
For administrator interfaces (installation, configuration, etc), again any tooling will work, but we start seeing real advantages for lightweight markup, codebase integration, and version control.
For developer interfaces, docs-as-code offers significant advantages. Developers can better contribute directly, and it’s generally friendlier for coded samples. APIs (native and remote), SDKs, and CLIs are almost certainly best documented in a docs-as-code environment, even if you integrate it with a more conventional platform for end-user docs."
https://gist.github.com/briandominick/d4cbe11228de0ebe31cda630976af4ef
#TechnicalWriting #SoftwareDocumentation #Documentation #DocsAsCode #TechnicalCommunication #InformationArchitecture #CCMS
On my way to #UniventionSummit . It's going to be great day with awesome people from the German #opensource and business community. I'm looking forward to talking with you. I can offer experience in #tech-writing , #docs-as-code, #InformationArchitecture , #enterprisearchitecture , and #ArchiMate .