Add user feedback #723
Add user feedback #723
Conversation
|
Your Render PR Server URL is https://toolpad-pr-723.onrender.com. Follow its progress at https://dashboard.render.com/web/srv-cbki28ta499ce8q2qlig. |
oliviertassinari
requested a deployment
to
feedback - toolpad-db PR #723
Render
Abandoned
| <Route path="/app/:appId/*" element={<AppWorkspace />} /> | ||
| </Routes> | ||
| </BrowserRouter> | ||
| <UserFeedback> |
There was a problem hiding this comment.
i didn't immediately understand this was a context provider from the component name - maybe we could make it more explicit?
nevermind it has the dialog too - i think it's fine, usually i would just have the provider and the component completely separate, so it confused me at first but nothing wrong with this approach
|
Both interactions look good and well positioned. A copy change suggestion: For components, can we somehow take users to a page where they can vote among many components ? If not possible on GitHub then may be Notion ? |
We could make a GitHub issue for each component? |
This seems straight forward, but won't it become additional work to manage ? I mean for the scenario when the component wasn't listed there: a user clicks on another component and creates an issue for the component they need, but it won't reflect in this catalog (additional work to show it) and may miss some votes. But since there are only a certain number of popular components users will request first, we can start with a list of top-10 each linking to a GH issue. |
|
Cool, I'll share the list of components. The top-right position is also suitable for:
Should we have a small menu there or where else can we place these? @gerdadesign |
|
Is something like this what you're looking for?
|
It's possible, we should probably take a look at app navigation as a whole as well, but I would leave it out of the scope of this PR.
either https://github.com/mui/mui-toolpad/issues or https://github.com/mui/mui-toolpad/issues/new?assignees=&labels=status%3A+needs+triage&template=2.feature.yml |
|
Isn't this Help icon more suited in the top right corner ? Also, instead of Submit feedback we can have:
Rest everything else looks good. |
That was my initial instinct as well, but it felt a little confusing sitting next to App deployment functions — the help icon isn't directly related to Previewing the app, so I moved it. In general though I agree that overall navigational elements could be revisited.
This link goes directly to Request feature, so to add the option to upvote seems like it should be a step back to https://github.com/mui/mui-toolpad/issues ?
|
Agree, for now, let's go ahead with what you shared.
Agree, let's do this. |
|
A quick benchmark on the support help:
I had a look as Linear too, but I found it horrible (you have to move your cursor all the way from the left side to the right side between the open and close state, WUT, they don't want you to use it 🙃). |
|
We could certainly pin it to the bottom! Does this get in the way of any functionality? |
|
More points to note:
So keeping it at bottom right as an overlay (as shared by Gerda) appears to be the best placement. |
Probably yes, e.g. when selecting a component that has several properties:
Personally not a big fan of those floating help/chat buttons. They tend to get in the way, you have to design every screen in your application around them. The header is a surface that is present on every page, wouldn't that be the ideal location and where people would naturally look? There's a bit of a selection bias in the above benchmark, adding a few more:
|
|
Ok. So if we place it on the header bar, then it has to be in the right corner for consistency and that's how some other products have done it. And, it will be missing from the preview view, which should be ok as it is app preview and the entire header bar won't be there.
I think we can close this here. |
Lay the groundwork for a potential user feedback flow.
Screen.Recording.2022-08-02.at.15.04.00.mov