-
Notifications
You must be signed in to change notification settings - Fork 468
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
Better depiction of bits in bit layout. (Also place all api names on left side panel, like java documentation to make it easier/quicker to find them) #665
Comments
I will also include my initial depiction which makes it even easier to see exactly where each field begins and each field ends without any uncertainty, and also it's size without any uncertainty, so it's also worth something, though the bit order is reversed and it uses a horizontal display at the bottom to show it one more time in an ultra compact way:
|
Finally I would recommend repeating these depictions per mode/type. So one for H3 Cell Index and so one and then simply replace the legend. So that it is crystal clear, how each type/mode is stored. It's a bit redundant but leaves no doubt as to how it's stored. One thing which I find annoying about the H3 documentation is the constantly scrolling back and forth, it takes a lot of time. Because the table currently is at the bottom, one has to scroll up and down a lot to try and understand grasp it. It's a tiny little example of "excessive scrolling" but the entire documentation is full of it. Very unfortunate. Finding anythig is also very hard. I would highly recommend putting all API function call names on the left side panel, so it can quickly be scrolled up and done and select from it, optionally seperated by group if desired, but should remain alphabetically within the group. For a good example of how to document a large API see the java documentation example. |
I've been meaning to break the index modes out into their own pages, I started a PR in #667 to do that. I agree the scrolling is very unfortunate and we should try to fix that. I think that is exacerbated by a styling issue that prevents the table from ever being full width, although I imagine breaking the table in half horizontally would be easier for more readers. |
@douglasg14b We do have a playground-style bit layout explorer on Observable: https://observablehq.com/@nrabinowitz/h3-index-bit-layout Not sure if we can easily make this part of the docs, but it might be worth trying. I like your layout here, this is a bit nicer than my current notebook and probably worth emulating - thanks! |
https://h3geo.org/docs/core-library/h3Indexing/
Problem with "Bit layout of H3Index" table is the non-usage of 1 block per bit.
Instead the entire field is one big block. The colors chosen are also very vague, very hard to see where a block begins and ends.
For example I did not notice initially that digit 10 is actually 1 bits on the bottom row and 2 bits on the row above it.
One cause of this is the usage of hexadecimal and the x in front of it, hexadecimal adds very little to this and confuses more than is worth it, simply decimal usage would have made the table more compact. Now because of 3 letters per box, instead of just 1 or 2, it's unnecessary wide and needs scrolling on a 1600x900 monitor.
Recommendation is to switch to decimal, and use 1 box per bit, and use a legend and letters to depict the bits more clearly.
Using both is best. One layout to clearly surround the fields and put the words into them, but also one where the bits are crystal clear placed. I would even go so far as to put a row of offset numbers below each row to make it more practical usefull to quickly find the correct offset, without having to do strange hexadecimal calculations.
In case one wants to only store on depiction, adding boxes around the bits that belong together would be a very recommendation. One big box with black thick lines, and one thin little gray box per letter/bit so that it can clearly be seen that it's one bit.
Better or extra depiction of bit positions:
The text was updated successfully, but these errors were encountered: