[HN Gopher] Show HN: SaaS for making software documentation less...
___________________________________________________________________
Show HN: SaaS for making software documentation less annoying
As a developer, I absolutely despise writing documentation. That's
why I've started building software that would make it a more
bearable experience. Our current features include the following: -
An AI assistant that lets you talk with your documentation. Ask
questions like: How do I do thing X? What is the method for
fetching a model from the database? And the AI assistant will
answer. - Developers can choose their preferred way of writing:
online WYSIWYG editor or writing to markdown files using their
favorite editor and then synchronizing with the system via CLI. -
Tagging relevant documentation pages with the corresponding code
files. Git integration will let you know when one of those tagged
code files changes and lets you know the documentation needs an
update. I'm sure the people in HN have many more pain points they
are experiencing with their documentation software, and we would
love to hear them. Any feature suggestions are more than welcome.
Author : doclab
Score : 10 points
Date : 2023-04-15 17:52 UTC (5 hours ago)
(HTM) web link (documentationlab.com)
(TXT) w3m dump (documentationlab.com)
| jerf wrote:
| "An AI assistant that lets you talk with your documentation."
|
| This is a nice opening for me to say something in a positive way
| instead of a negative way: I'm more interested in this sort of
| thing than some of the other uses of the LLMs.
|
| Consider the use case I've seen bandied about of "This will
| automatically take your commit and write commit messages!" This
| is useless to me... but not because of the "but it will lack
| insight" sorts of reasons. That may be true, but that only makes
| it less useful, it doesn't remove the use. The reason why I call
| this useless is, I have no need for the output to live in a
| commit message. I can take any commit I like, even a commit that
| already has a commit message, and feed it into a summarizer. In
| fact if I do it three or four years from now, it'll probably be
| even better, on the same input.
|
| Taking fixed inputs, just throwing an LLM at it, and recording
| the output somewhere, is not a useful use to me, because there's
| no compelling reason for me to do that today when I could even
| more easily do it on demand, later.
|
| Now, ingesting my documentation (or perhaps even my raw source
| code) and answering the question I have _right now_ is valuable
| to me, right now. Maybe in three years the system will be even
| better, but I have a question _right now_.
|
| In general, I'd suggest that any startup looking at adapting LLMs
| look carefully at any place their system involves storing the
| output of the LLMs somewhere persistent. Marketing fluff, well, I
| may have personal distaste for that use, but it's a case where it
| clearly makes sense. Autogenerated documentation for filling in a
| Wiki suffers from the same problem I'm outlining here.
| madmax108 wrote:
| For user-facing documentation, I noticed Docusaurus
| (https://docusaurus.io/) coming up in conversations more and
| more, so finally bit the bullet and moved our customer-facing
| documentation to use docusaurus as well (originally using a
| modified mkdocs).
|
| Gotta say, Docusaurus has worked out great for us. Smooth
| migration if you have markdown already, everything just works,
| and a lot of sane defaulting
| doclab wrote:
| I also love docusaurus and their easy of migration and use with
| markdown is something I've tried to bring to my tool as well.
|
| Glad you are happy with it and if you just migrated you
| probably don't want to do it again this soon but if any of our
| other features interest you or you need online wysiwyg editor
| as well, definitely keep us in mind.
| JTyQZSnP3cQGa8B wrote:
| > I absolutely despise writing documentation
|
| You really should learn that skill because it's very important in
| most software companies, and mandatory for some fields like the
| healthcare industry. It is, like unit-tests or code coverage, a
| skill that makes a difference between a developer and a senior
| developer.
|
| Also my pain point is when documentation is not written when it's
| so easy to use nowadays with files in a docs/ directory, wikis,
| or comments like Doxygen. We don't need more tools, we need
| discipline. I'm still trying to understand what your service
| could bring me, and why I would pay for this.
|
| Last but not least, in the comparison page
| (https://documentationlab.com/blog/best-software-
| documentatio...), you describe Read the docs as a tool when it's
| only a web site to store user-generated content (from Sphinx or
| any other tool). That's why it's more confusing.
| doclab wrote:
| I do write documentation, but what often happens in companies
| is that you are forced to use Confluence or other such software
| since the documentation has to be available and editable for
| all kinds of users in your company. Technical or non-technical.
| This makes it a hassle for developers to use these tools when
| they really would like your example of docs directory.
|
| What I'm trying to do is to have the same advantages as tool
| like confluence but make it as developer friendly as possible.
| With my tool, you can actually just write the docs into the
| docs directory if you want and then sync them with our cli tool
| so you can also edit and view them with your browser from
| anywhere. When a company needs such tool, they also usually
| have a problem that the documentation is not up-to-date; my git
| integration is made to address that.
|
| I think if you don't have these kinds of needs or problems I'm
| describing. You are able to write your docs to the doc folder
| and don't value the git integration or AI assistant, this
| probably ain't the tool for you. I completely understand why it
| sounds useless to you, but from working in the from software
| industry for a decade I believe there are enough companies with
| these kinds of problems I'm addressing.
|
| Also thank you for feedback. Based on the comments I'm getting
| it seems like my web page isn't communicating the advantages of
| my tool well enough and I'll definitely need to fix that in the
| upcoming weeks.
| jmduke wrote:
| Two immediate nits (and I mean these from a place of love -- I am
| a sucker for docs tools):
|
| - Your splash page's hero image is indistinguishable at first
| glance from basic Markdown. More than that, it's the kind of
| thing I'd expect a tool to _automatically_ generate!
|
| - The idea of colocating documentation with the files its
| documenting is really interesting, and a core pain point of most
| internal docs ("what do I need to update when I change this
| file...?") I think your screenshot here can be much improved.
| doclab wrote:
| Great and fair feedback. I think you are right that my
| screenshots don't show the unique parts of my software very
| well. The point of the first screenshot was supposed to be that
| you can either work with the wysiwyg editor or just do
| everything from cli if you never want to leave your vim. But I
| guess it doesn't get the point across very well. Do you think
| that screenshots from the version control integration would be
| better? For example picture of terminal window doing git commit
| where the system then lets you know that the page X needs an
| update.
|
| Again thank you for your feedback, you definitely gave me some
| thoughts for improvement
___________________________________________________________________
(page generated 2023-04-15 23:02 UTC)