-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Table block UX - to discuss or not? #2609
Comments
There is no specific ticket about the table UX. However, lets maybe pan out a bit and look at what you are thinking is the issue, because UX is a wide term. Is this from self discovery? Or do you have some usability testing to feedback on this? It would be great to dig in a bit more, thanks. |
Sure. I guess my initial question was "is this being dealt with already?". I think this falls into "self-discovery". This is just something that I found coming to Gutenberg for the first time - most of the block's settings made pretty good sense. But I really struggled when I added a table. The high-level overview is that it doesn't really behave like any other embedded table-in-document interface that I've used, and I don't think the drop-down for modifying rows/columns is "discoverable" enough. Examples:
Eventually I found the table-editing button with a drop-down of actions: and that enabled me to do the things I wanted to do. But until I found that I was struggling and even for a while thought that the table block must be a work-in-progress that was waiting for add/remove row/column functionality. I basically gave up using tables because, as far as I could tell, they didn't work. I think if it behaved more like other embedded table UI's (such as Word's or Pages's) then actions on Gutenberg tables would not need to be as discoverable. And if actions were more discoverable then it wouldn't matter so much that it works differently. So, ideally we'd both make it easier to discover how to take these actions and make them similar to tools that people are more familiar with. But I can see how improving one of these aspects might reduce the need to improve the other. Hope this all makes sense and is useful. |
As a reference, here's some of Word's online, browser-based tables UI: https://cloudup.com/c69TkDhH9BA Google docs doing the same thing: https://cloudup.com/cn6YmDmDASF Pages on a Mac, which doesn't have right-click, but has a nice affordance for adding rows: https://cloudup.com/cBVUbLPAyyo And me acting out the first time I played with Gutenberg: |
@rosswintle : you raise a few excellent points here, thanks heaps
|
Thanks. I don't have the kind of time that's going to be needed to be involved in a deep way, but I appreciate you taking this feedback on board. I think I'd still like to see some improvement on the "affordances" (I hope I've used that term correctly) for adding rows and columns. I liked what Pages did with this (see https://cloudup.com/cBVUbLPAyyo if you haven't already) and it seemed relatively touch friendly. I totally appreciate that some of these things are hard problems to solve, especially when you take into account touch screens and accessibility. So thanks again. |
Just a note, lets remove the feedback label until we have something mocked to give feedback. |
What do you both feel out of this discussion are good baselines to have implemented? Lets think of small wins here. |
I appreciate that the priority of this is probably pretty low given the technology discussions that must be happening. And generally, I think the table UI is going to be HARD. I think it comes down to the fact that I'd like to have some kind of in-line control for adding and deleting rows as I feel like the drop-down menu for this is too hard to find and not discoverable. Here's a mockup of something you might do: My thinking is that these could appear to add/delete rows/columns when you are hovering over a cell. I appreciate that there are issues with touch devices and possibly issues with touch/tap control sizes too. Something like this would be my quick win here. |
Just left some comments/suggestions on #2620 for the default styling for tiny changes we could do on table block. There are tons of awesome ways we could approach the table block, here’s some suggestions that we’ve been chatting about (including an initial sketch with lots of different options): Bigger suggestionsBeyond what’s suggested above, there are some additional things that I’ve been chatting with Brendan Woods and Anna Harrison about. I’ll outline them below. Been looking at tons of other table options out there.
One option: Another great sketch/suggestion from Brendan on how the initial state could look: Another option (as shown on tinymce.com and on Google Docs) Could also look like this (Thanks @jasmussen):
Thanks to @brendanwoods-xwp for helping think through all the options for how we could approach this, and for your awesome sketches! Also thanks for @annaephox @EphoxJames for your great feedback and thoughts through this. |
I feel we're splitting things between 2 issues on tables. Could we merge them into focusing on #2620? Let's close this for now and focus on there - we can always reopen as any UX improvements would go into defaults right? @jwold I feel adding another step to the inserting isn't UX friendly. Let's discuss in the other issue but I really don't see that as an improvement. Similarly I don't think adding yet more things like images, borders, styling and images helps with UX. Sure they are nice features but they don't improve the experience. |
Issue Overview
I don't want to start by going into too much detail in case it's not necessary. But I really don't like the table block UX. My initial questions are:
Expected Behavior
Will add later if necessary
Current Behavior
Will add later if necessary
Possible Solution
Related Issues and/or PRs
The text was updated successfully, but these errors were encountered: