Why was the project created?¶
We are Arkbauer - Custom Software Development company.
We often need to document various things to help us, our customers, and the customers of our customers to access important information.
So, we needed a tool using which:
- we can rapidly create a new/isolated Project containing various “books” of information
- we can super easy create and publish documentation with a click of a button
- we can allow our team members and customers to manage the contents
- we can have an online version of the documentation that we have created
Why didn’t we use existing tools?
- first of all, all the tools using
HTMLas the basis for documentation are not handy at all. Once you learn writing in
Markdownsyntax, you will understand how quickly you can create easy-to-read content. If you don’t believe us, then just believe in the IT industry that uses
Markdownas the number one language for content creation. It is the same case physicists using
LaTexfor writing the thesis…
- Markdown tools that offer publishing of the content online, like Read the Docs, are good but the effort of setting up new projects, lack of content editing tools, the fact that you have to push the content changes to GIT each time, is just very inefficient and, to be honest, very annoying. In addition, you have to be quite a technical person to understand how to work with all of that.
We needed an efficient and simple tool that can be understood and used by anyone!
Thus, we created it for our own needs at first but saw, there could be many other companies, product owners, or just individuals that need the information to be published quickly.
How docwriter.io is used by us?¶
We’ll describe how we benefit from the tool and this will serve as the best example of how it might be used by you!
First of all, we needed to have it documented what lives in our internal zoo. When we see there is something useful we need to write down, we just quickly open up the tool. Click! - it is published and available to other people. It literally takes seconds…
What we have in our internal docs:
- what tools, utilities we’ve discovered as being useful
- hints about various development hacks
- how to set up different things
- what our infrastructure consists of (network topology, servers, tools, etc.)
- links to useful books and information resources
- list of our Team members with the relevant contact information
- other, office-related information (who to call if something happens, etc.)
Technical documentation of the software projects¶
As Custom Software Development is our daily routine, we need to have the following written down:
- what’s the architecture of the project
- what modules are in the system, how they function
- what’s the contact info of the team members
- what’s the infrastructure (environments, server addresses, ports, tools, services, etc.)
- describe different procedures (like - if this happens, do this)
- write down Know-hows (how to deploy, how to restore backups, how to migrate something)
Our customers often need to have it written down somewhere:
- how to configure the software systems
- how to onboard their customers
- what to do when something happens
- other information about the software solution
Software user manuals¶
Did you already check app.docwriter.io management tool and see those little help icons next to some UI elements?
It is great if you can squeeze the description of the functionality into a tooltip. Yet, there are many cases in more complex software solutions where you really need to provide a good description of the feature, how it works, and what consequences it will bring. In those cases, it is great if you can have dedicated documentation with content structured the same way as in the application and just link the help icons to the corresponding section in your documentation.
Just navigate to app.docwriter.io, click on the help icons and see.
We aren’t talking, for example, about REST API documentation. This tool isn’t about generating API documentation. There are dedicated, very good tools for that.
We use docwriter.io to document how other parties can integrate with the systems developed by us. How to configure the integrations, what are the available environments, what are specifics, etc.