Github Pages Documentation site for TCK docs

[LukeBair]

To make the documentation for the TCK docs a little more available for developers, created a simple structure for hosting the markdown files under /docs/ as a github pages site. I chose a theme that comes with a built in search bar, so thats a nice little feature to have.

No changes to the documentation files have to be made, although new pages added to documentation would need to be added to the index.md file.

If this PR is merged, one setting should get tweaked in the repo settings. Go to 'settings' -> 'pages', and make sure that the source for the site is 'deploy from branch', and the branch is 'main', and the folder to serve from is '/docs'

Examples of the site (hosted on my fork of this repo: https://lukebair.github.io/hiero-sdk-tck/)

[rwalworth]

I really like this idea and I think it would be a great feature to integrate to make our docs more readable. However there are a couple things I noticed on the site that should be fixed before we merge:

• The test specifications use tags with < and > to denote variables in the tests. For example, if a test needs to use the ID of a previously created account, it will look something like <CREATED_ACCOUNT_ID>. It doesn't look like these show up in the docs, they are just replaced by blank white space.
• Links in the test specifications can't be clicked on to go to that URL. Don't know if this is possible to add or not.
• Is there a way to better organize the sidebar? It looks like all the pages are in alphabetical order, but if we could maybe organize them by service like they are in the repo, that would help declutter a bit.

[ivaylogarnev-limechain]

I really like this idea and I think it would be a great feature to integrate to make our docs more readable. However there are a couple things I noticed on the site that should be fixed before we merge:

• The test specifications use tags with < and > to denote variables in the tests. For example, if a test needs to use the ID of a previously created account, it will look something like <CREATED_ACCOUNT_ID>. It doesn't look like these show up in the docs, they are just replaced by blank white space.
• Links in the test specifications can't be clicked on to go to that URL. Don't know if this is possible to add or not.
• Is there a way to better organize the sidebar? It looks like all the pages are in alphabetical order, but if we could maybe organize them by service like they are in the repo, that would help declutter a bit.

I really like this idea as well! A similar approach has been implemented in the JS SDK, and from what I’ve heard, it’s a well-structured and user-friendly feature. I haven’t personally worked with it yet, but it seems like a great addition.

Building on Rob’s comments, I’d also like to suggest an improvement regarding how document titles are displayed. Instead of showing long, technical names like AccountAllowanceApproveTransaction - Test Specification, we could modify the visualization to present them in a clearer and more readable format—something like Account Allowance Approve Transaction. This would make it easier for users to quickly understand what the document is about without getting lost in complex naming conventions.

[LukeBair]

@rwalworth @ivaylogarnev-limechain, thanks for the suggestions, I'll work on fixing/adding your suggestions! I do have a quick question though. I was trying to make sure that the documentation didn’t have to be written any differently than it has been, this is a priority I should keep right?

[rwalworth]

@rwalworth @ivaylogarnev-limechain, thanks for the suggestions, I'll work on fixing/adding your suggestions! I do have a quick question though. I was trying to make sure that the documentation didn’t have to be written any differently than it has been, this is a priority I should keep right?

I think I'd prefer not having to make any major changes, but if you'd want something small to be changed (e.g. using a different form of tagging variables without the < and >) then we can collaborate and come up with a path forward. What changes were you thinking?

[LukeBair]

Ok sounds good! The stylistic things like environment variables and links work now, but the navigation by service will need a front matter at the top of every md file to work properly.

[ivaylogarnev-limechain]

Hi @LukeBair ,

I reviewed the files again, and for a static HTML setup, everything looks good for now. The SCSS naming conventions are also properly followed—great job!

I have two small requests:

1. Could you format the files using Prettier? The entire project follows this standard, so it would be great to keep it consistent.
2. Could you add a README with instructions on how to launch the page and any other relevant details?

Thanks!

[rwalworth]

Hi @LukeBair ,

I reviewed the files again, and for a static HTML setup, everything looks good for now. The SCSS naming conventions are also properly followed—great job!

I have two small requests:

1. Could you format the files using Prettier? The entire project follows this standard, so it would be great to keep it consistent.
2. Could you add a README with instructions on how to launch the page and any other relevant details?

Thanks!

I second this! Also in addition to the instructions on how to launch the page, how we'd be able to test adding new specifications; I'm not sure if there'd be a separate site on which we'd be able to try things out and see potential changes or how that works, so it'd be good to have clarity there.

[LukeBair]

Could you format the files using Prettier? The entire project follows this standard, so it would be great to keep it consistent.

I assume you mean the non-documentation files, like all the custom HTML and SCSS; is that correct?

I second this! Also in addition to the instructions on how to launch the page, how we'd be able to test adding new specifications; I'm not sure if there'd be a separate site on which we'd be able to try things out and see potential changes or how that works, so it'd be good to have clarity there.

I'm not quite sure what you mean by this. Do you mean that the README should have instructions on how to add to the docs? Maybe the README can have a local build guide to help people test their edits/additions.

[rwalworth]

I'm not quite sure what you mean by this. Do you mean that the README should have instructions on how to add to the docs? Maybe the README can have a local build guide to help people test their edits/additions.

If I were to add new tests specs, I'd want to make sure they show up on the site correctly before I merge. I think it'd be good to have documented whatever the process would look like to verify that.

[ivaylogarnev-limechain]

Hi @LukeBair,

Yes, I was referring to formatting the HTML and SCSS files with Prettier—you’ve done that, great job! Thank you.

I was able to run the site locally, and it looks good! The documentation is also clear enough to get the site up and running. However, you might want to add a small disclaimer mentioning that some users may need to run bundle install with sudo (as I did). Some users might see this as a security risk, so it’s good to acknowledge it. Additionally, you could provide a bit more context on the purpose of the site—essentially, visualizing the TCK docs and making them more accessible to developers (as you described here).

I’m attaching some UI improvement suggestions with screenshots:

1. Dropdown Layout Issue
In the image below, you can see that when the TokenService dropdown is opened, it pushes down other elements and causes them to shrink, leading to an overlap.

2. Search Icon Movement
When switching between different documentation sections, the search icon slightly shifts. Ideally, the screen should remain static to provide a smoother user experience.

3. Left Sidebar Adjustments
You might consider a way to make the left sidebar collapsible, allowing for more space for the main content—perhaps a button to toggle its visibility.