website
website copied to clipboard
asyncapi
[📑 Docs]: Re-arrange content bucket menu on mobile view
What?
Fix the current structure of the menu in the mobile view
Why?
The mobile menu's present arrangement makes it tough to find. We can improve the user experience by making the menu behave similarly to the "ON THIS PAGE" menu, i.e. sticking side by side as the user scrolls.
Here's how it looks currently:
And when the user scrolls, here's how it looks:
The menu for the other content buckets completely disappears.
My suggestion is to have it look like this:
@alequetzalli
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Great find, @nelsonmic! ⭐
Let me connect you with our /website core contributor and code owner, @magicmatatjahu. He can guide you how to fix this or you are free to put up a PR and add Maciej to review it. 😄
In addition, I have tagged @mcturco who is a core design contributor, in case she needs to also review changes made.
Thank you @alequetzalli, i would love to connect with @magicmatatjahu, so that he can help me get started
Thank you for reporting this issue, @nelsonmic!
I think this would be a good issue for a design contributor to pick up and ideate on some solutions, keeping in mind that we have some major changes being worked on in the docs currently on PR #601, so these ideas would have to work with this new structure.
However, I think that this bug should get resolved in the meantime and I think your solution should work just fine, but I think that the "On this page" button should go to the edges instead of having the margin/white space around it to help it look more like a toolbar. What do you think?
Hi @mcturco!
That's fine, I'm happy to have created the issue.
Also, you're right, I think that would be a good approach to solving the issue, that way it looks more like a toolbar
Hey @mcturco @nelsonmic, it's a nice idea to put the TOC and the left Sidebar buttons inline, but as Missy suggested to have TOC aligned at the edges, can we make it be a right sidebar for the mobile view. It will be much more interactive, but a bit difficult task to create it as a right sidebar instead of just a dropdown (as of now). My thinking behind it as we are already with a dropdown feature on Navbar and it is sticky on the top of the window, the left sidebar is viewed when the page title is clicked, and you are aligning the On the page to the right edge, it's will be nice and cool to have it as right sidebar when clicked. What's your suggestion on it?
Hi @akshatnema, thank you for your suggestions.
At the moment, it's actually not a dropdown menu, it just looks like it, however, it behaves like a "hamburger menu". Your suggestion if i got you correctly is to make it look like a "hamburger menu", but there's already a hamburger menu at the top right corner of the page.
what do you think?
I would like to take up on it.
I feel we can have a Sticky Tag/ bookmark like design, where the user can click on the tag to open the hamburger style menu.
I feel like this is an Index, and it can work like that, I have some iterations
or
How about a Design like this for the scroll: This will make the Menu still accessible, and an animation while scrolling can make it so that the heading collapses and only an arrow is visible
Figma Prototype: (click to see the different states) https://www.figma.com/proto/N4jtHmKHco1jXkeokdU1cq/Modelina?node-id=6%3A62&scaling=min-zoom&page-id=0%3A1&starting-point-node-id=6%3A62
Yes @iipranavii the last design you just sent makes sense in my opinion, let's wait for @mcturco go-ahead.
Also, one more thing to note, as @mcturco said before "the (On this page) button should go to the edges instead of having the margin/white space around it to help it look more like a toolbar."
Hmmmm 🤔 Is it just me or does it seem like the "Concepts" arrow and the "On this page" arrow are directly competing? I think we should come up with some other ideas for how we could layout this secondary navigation so that the user knows what to expect when clicking arrows. Perhaps the sidebar menu toggle button could be separated from the TOC toggle button? Do we need the TOC dropdown on mobile? How can we easily communicate to the user that "x" will happen when you click "y"? Just some questions that I am asking, would love to know what others think.
Hi @mcturco, you're right about both arrows conflicting, what do you suggest we do? How would users navigate if we decide to remove the TOC dropdown for mobile?
I have gone through the above designs made by @iipranavii and the @mcturco comment regarding the competing of the arrows of the menus in the mobile view. Based on the comments and my previous comment https://github.com/asyncapi/website/issues/761#issuecomment-1124105338, I have created these designs. @mcturco do review these and give suggestions regarding them.
I prefer the above two changes made because it will clearly depict that one is the left side bar and TOC is the right side bar to the users. I showed you the concept, but the design of the button and colors depends on you and it should be around the theme of the website. If needed, I can make the design for the sidebar as well.
Hi all! I had some ideas for solutions on this experience issue. I have propagated them in a couple of prototypes, let me know what you all think.
Option 1
Breadcrumbs, TOC drawer sticky to the bottom of the viewport
Option 2
Same as Option 1, except with docs title and current page shown instead of breadcrumbs
Both options have been prototyped in figma, toggle through each option using the Figma UI sidebar in the following link: https://www.figma.com/proto/DWMN1qbGucDB7lEhMdB5li/Docs-Mobile-Navigation-%23761?page-id=2%3A37&node-id=2%3A39&viewport=395%2C48%2C1&scaling=scale-down&starting-point-node-id=2%3A39&show-proto-sidebar=1
Hey @mcturco, you made a brilliant and technical design to handle the TOC in the website accurately :clap:. But I have a concern that you made that TOC at the bottom of the window and the same TOC is being used in the blog as well. In every blog, we use a script and at4 to display the social icons to enable the share feature in them. They are also confined to the bottom of the window and can't be customized due to the external renderation of the whole component. How both the components will take the bottom side of the window?
Yaaaaaaas @mcturco Option 1 is just perfect, I think we can go with that, it's descriptive and well placed.
Also, @akshatnema, do you mean that if we change the "On this page" button on the docs page, we would have to do the same for the blog pages?
But I have a concern that you made that TOC at the bottom of the window and the same TOC is being used in the blog as well. In every blog, we use a script and at4 to display the social icons to enable the share feature in them. They are also confined to the bottom of the window and can't be customized due to the external renderation of the whole component. How both the components will take the bottom side of the window?
@akshatnema Thank you for pointing this out!! Hmmm 🤔 I am starting to wonder if we even need the TOC on the blog pages? I don't feel like our blog posts are super long to where that would be necessary. What does everyone think about removing TOC altogether from blog pages?
But I have a concern that you made that TOC at the bottom of the window and the same TOC is being used in the blog as well. In every blog, we use a script and at4 to display the social icons to enable the share feature in them. They are also confined to the bottom of the window and can't be customized due to the external renderation of the whole component. How both the components will take the bottom side of the window?
@akshatnema Thank you for pointing this out!! Hmmm 🤔 I am starting to wonder if we even need the TOC on the blog pages? I don't feel like our blog posts are super long to where that would be necessary. What does everyone think about removing TOC altogether from blog pages?
We can take it off since we don't really need it there
@akshatnema Thank you for pointing this out!! Hmmm thinking I am starting to wonder if we even need the TOC on the blog pages? I don't feel like our blog posts are super long to where that would be necessary. What does everyone think about removing TOC altogether from blog pages?
I think we do need it sometimes in the blog. This is because Lukasz writes the blog regarding the summary of what is happening in AsyncAPI may be quarterly or half-yearly basis. Those blogs cover some important headings and may get long if he needs to give good explanation regarding the improvements made. Secondly, you can go through this blog AsyncAPI vs OpenAPI which really denotes that the TOC can have a good impact on our blogs to improve the reader's interest and important points/headings to be considered important. In this way, I think it is important but you can definitely go with the vote on which majority community members agree.
Also, @akshatnema, do you mean that if we change the "On this page" button on the docs page, we would have to do the same for the blog pages?
On both pages, the same TOC component is rendered. So, if we change the component, both pages will get affected.
@akshatnema Hmmm I would like to get some feedback from others in the community about this. Even that AsyncAPI vs OpenAPI article isn't too long to scroll through, and I almost think that the links in the TOC is overkill compared to the short length of that article.
@akshatnema Hmmm I would like to get some feedback from others in the community about this. Even that AsyncAPI vs OpenAPI article isn't too long to scroll through, and I almost think that the links in the TOC is overkill compared to the short length of that article.
In my opinion, I don't think we need the "TOC" menu on the blog pages.
Inspired from @mcturco's design, and the problem with the bottom window, I felt this design can work for the TOC, it doesn't take up as much space and I feel can be easily recognized by the user for its use case?
No please do not remove TOC 🙏🏼 It is industry standard for docs and super useful in blogs too. Sometimes articles are short but sometimes they are technical, few chapters and TOC is crucial.
I recommend tracking the usage before it is removed (https://github.com/asyncapi/website/issues/432). I remember last year, around October there was a discussion to remove animation from landing page as "nobody watched it" but numbers from GA show just for April that Open Studio button was clicked by 974 users, while `Open in Studio (that shows up after animation) button was clicked by 354 users. Sounds to me that animation is important to stay if only 3 times fewer people wait for it to end. So yeah, sometimes we get biased by our "long exposure to the UI" (I have no idea how to explain it in English)
I am not a designer but I am here to give my opinion and agree with @derberg about keeping the TOC. 🙃
It is industry standard to have TOCs in both blog posts and documentation pages, regardless of how long a post or article happens to be. It's also extremely useful because then you can send links to people to the specific section that answers a question, versus having to send them the link to the whole page and hope they can find what they need.
@derberg @alequetzalli Thank you guys so much for your input! I think the idea was to remove the TOC only from the blog pages, but I do understand how that might affect someone's experience of reading an article. I'm fine with leaving it, I just think we should come up with some other solutions for having both the share buttons and the TOC on the blog pages (on mobile)
Here's a new idea 💡
I don't think its super necessary to have the share buttons stuck to the bottom of the blog pages, I wonder if we can consolidate this with the use of a button. I really like the design that @iipranavii came up with, and I think this might create some space to add another button for a share popover as well.
Here is a quick wireframe sketch that I came up with that shows both icons at the bottom right corner
And here are the screens when each one of them is active
Would love to know what everyone thinks about this idea? Of course, on the docs it will ONLY have the TOC at the bottom. These screens are meant to show what it would look like on the blog post pages.
@mcturco Hats off to your designing skills, Missy 🫡. But we have a big problem that the shareable links (i.e. at4) are not JSX components. It is not handled from our repository. It is just a JS script written and rendered from the external source and we can't customize it to a single onclick button. Hence, what you showed in your prototype is practically not possible with the present scenario of the sharing options available. Please go through this part of the BlogLayout.js and you will get to know why I'm not preferring the above design. If we have a plan to make our own system to handle the sharing options from the website repo, it is the best solution because the given at4 is even not responsive on our website.
If we are continuing with the at4, you can go through the designs mentioned by me (in https://github.com/asyncapi/website/issues/761#issuecomment-1124912416). These can be easily implemented but frankly, I'm not aware of the UI standards that should be used to make it more professional.
@akshatnema hmm I see what you mean and I am wondering if there is an alternative solution since as you pointed out the script is causing issues on mobile (I have a problem where the horizontal scroll bar shows up and the page scrolls side to side as I am trying to scroll down. Wonder if we could put the scripts into a component and add them where we need? Not sure what is possible, maybe @magicmatatjahu can help with ideas on this!
As for addThis, we can always style it in a different place than the default, and even choose a rendering "way", one of official. I wouldn't worry about that.
Heyy @nelsonmic 😀. I hope you are doing great. I would like to work on this issue, are you still working on this?. I will be happy to work with you 😀. Thank you 😁
