Make the "edit" button inactive if no commands are available

[amivaleo]

Hi!

Look at this:

I believe that the button in the circle should be inactive if no command is available, right? Indeed, it does nothing in that case.

💪

[ferdnyc]

Yeah, the state is pretty weird there.

1. It starts out enabled even with no entries.
2. If you Create (:heavy_plus_sign:) a first entry, it becomes disabled and Save becomes active. (Arguably, Edit could transform into Save when editing is activated, since they can never both be enabled at the same time. But, that might not be obvious enough?)
3. When you Save the new entry, Edit is re-enabled (which is what you'd expect, in that case).
4. If you Delete (:heavy_minus_sign:) the last entry, Edit is disabled (again, as you'd expect).
5. Buuuut, if you Create (:heavy_plus_sign:) a first entry, don't fill in any values, and Save the empty form, the blank entry gets auto-deleted... except, now Edit is once again enabled on an empty list.

[ferdnyc]

(Who am I to buck The System™?) :angel:

[amivaleo]

Uhm... I didn't want to be noisy this time. Also, I didn't really go into checking exactly how that Commands tab works. And yet, this issue got the "Jimmy" label anyway, so I'm eligible to be noisy! :D

That tab definely needs to be changed "a bit". ^_^

Maybe something like the dialog when creating a new shortcut in Settings...? I'm not suggesting to add a popover dialog, but to copy&paste the look&feel if possible.

By the way, the :heavy_minus_sign: should be red, 'cause it triggers a destructive action. 🙂

[amivaleo]

Clicked on the wrong button...

[ferdnyc]

Maybe something like the dialog when creating a new shortcut in Settings...? I'm not suggesting to add a popover dialog, but to copy&paste the look&feel if possible.

Well, the Look & Feel of the gnome-control-center Keyboard list really requires a dialog, since they do away with explicit Edit buttons (you just click a thing to bring up the edit interface), and the Remove button is moved to the dialog's header bar. (Save is implicit, so there's no button for that except the Close button.)

The :heavy_minus_sign: button isn't really big enough for the Destructive styling to be effective, IMHO — I don't think I've ever seen a list-removal button styled that way.

(Then again, normally list-removal isn't destructive, so it wouldn't be needed. When it is destructive, like in g-c-c for custom keyboard shortcuts or GSConnect's commands, the GNOME house UX design seems to gravitate towards editing in a dialog with an explicit Remove button, rather than in-place in the list.)

[ferdnyc]

There's actually a lot of implicit-destructive in the Commands list, I'm noticing. Like, if you Edit an existing entry, blank the name, and hit Save... *poof*! Gone.

[andyholmes]

Yeah, I've never really been happy with this panel, but I didn't like the treeview approach either with columns that magically become editable when you click them.

I think fixing the buttons/active won't be too hard. What to do when the entries are empty is a bit tricky, because missing title/command kind of gets messy internally. We can make the entries red or one of those error icons like when your passwords don't match.

I have an idea for a better "new" widget, it'll just take me a day or so. I keep volunteering to do other things in GNOME and I think I've over-committed myself :confounded:

[amivaleo]

the GNOME house UX design seems to gravitate towards editing in a dialog with an explicit Remove button, rather than in-place in the list

You have a point here, indeed. And it is also my point actually, because it goes in the same direction: that panel needs some change. ^_^

columns that magically become editable when you click them

I don't like them either.

But I like the way the wi-fi panel works. There you have a gear-icon that opens a dialog.

GSConnect could do something similar.

There's no real need for a dialog in a separate window, I believe. I leave that to you.

The idea that I have in my mind right now is a list of items like in many panels in Settings (wifi, bluetooth, notifications, search, etc). At the end of each item, there's a gear button. The last item of the list is a [+] button (like in Settings > Region and Language).

When the user click on the [+] button, either a dialog or another item in the list appears. 1- If the latter appears, it shows the two text fields, one for the Name, the other for the Command. The gear icon is replaced by the save icon-button. Somewhere in the same box there should be an additional an x-button or a cancel-button. 2- If a dialog appear, its headerbar contains a "Cancel" label-button on the left, and a "Save" label-button on the right. The main content consists of the two text fields "name" and "command".

When the user click on the gear button, either a dialog appears or the item changes UI to become similar to the case explained in (1). The only difference: the x-button/cancel-button is replaced with a trash-button/delete-button (in red). If a dialog appears, it looks like the one described in (2), but again: Cancel -> Delete (in red).

Apologies for not making a tiny mockup for this idea. I don't have a mouse right now and drawing anything using the touchpad is a pain in the a*s for me.

Of course, it's just an idea. My hope is that it triggers some smart thinking that leads to something nice go use and see. 💪

I keep volunteering to do other things in GNOME and I think I've over-committed myself

Never forget to review gnome extensions please! People completely neglect them otherwise. :|

[andyholmes]

Never forget to review gnome extensions please! People completely neglect them otherwise. :|

Heh, that's because I'm just the only reviewer right now :D

For the topic at hand though, I'm not a huge dialog hater, but I don't really like them either. I also don't mind putting buttons in the rows themselves, but I think the reason it's this way is because I decided putting "delete" buttons in the rows would make it too easy to accidentally press them. So making them selectable made sense, but edit buttons in selectable rows is kind of weird.

The idea I had, is to have the list be part of a stack. So instead of a magical row that appears, when you click edit/add it slides an editor in from the right and slides back when you're done. I think also it might be better to move the controls to the bottom of the page as an action bar, instead of having them attached to the list. Then the second page could have its own controls.

[amivaleo]

edit buttons in selectable rows is kind of weird

uhm? According to my idea, rows are not selectable. They can be "clickable". The idea is that the user clicks either on a gear-button/edit-button at the end of each row OR on the row -> he can edit or remove the command. It's up to you to decide if that "OR" has to be inclusive, that is: it's up to you to decide if also clicking on the row opens the editor or not.

By the way, android users are quite used to have buttons at the end of list items. They're everywhere. So the UX won't be broken if you make the rows clickable.

[...] the second page could have its own controls.

I think that the focus should remain on one single page, and that adding or editing items in a list should not make the list disappear. The idea of the dialog is that the user is doing something on that very same list. Loading a different page somewhat breaks such perception.

Also, I think there might be the need to have some quick check at the list while adding/editing one entry. Maybe because... Dunno: I'm not sure if I'm going to add some command that I already have.

I don't really like the idea of a second page/panel only for the editor. Apologies! ^_^

[andyholmes]

Oh, I didn't mean another page. This is roughly what I meant:

But like I said, I'm not a dialog hater, I just really try to avoid them :) If you want to do a dialog I'm fine with that. I don't know why that gif is so slow, it's much smoother in real-life :)

[amivaleo]

Yup, I understood that correctly. It's just that I can't express myself in a proper way. ^_^

So yes, what I said still holds, because I was definitely thinking at what you show in the gif.

What's the issue with dialogs, by the way? Is it just a matter of personal tastes or you see some UI/UX issue with those?

[andyholmes]

I think popup dialogs in general are very disruptive, so I prefer to only use them when I'm purposefully stealing attention. I think they're good for things like "Warning!" or the FindMyPhone alert when you want to really disrupt someone's process and make them pay attention.

They're also not really "connected" to anything and there's no visual sign the dialog is part of a process, it's just suddenly there. That's why I kind of like the animation here. A counter-example is opening something in an editor before you can delete it; that's a sort turning a command into a process.

One thing that will be weird is the FileChooser dialog, because it will be a dialog over a dialog. But that's fine, I don't really use this feature and when I do I don't add/remove commands very often so a dialog is fine with me. I can probably do that tomorrow. I'm off to bed for tonight though :)

[amivaleo]

I'm off to bed for tonight though :)

Ah, Californian guy! I'm about to go to lunch here... :3

I see your point now. It makes sense to me. Still, your solution doesn't make sense to me. 😄

At this point, I'd prefer a new row that behaves as a editor. That means that there should be a [+] button somewhere (as last item of the list...?) and an edit-button/gear-button at the end of each row (that changes the UI of that row to an editor-like gui).

I'm doing some brain-storming here. See if something smart comes up from this. 😶

Goodnight!

[ferdnyc]

Oh, I didn't mean another page. This is roughly what I meant:

Hmmm. It's interesting, but a couple of things I don't love about that:

1. It doesn't do anything to address one of @amivaleo 's original points, which is that the destructive action of deleting a custom command entry is still "hidden" behind an innocuous-seeming little button labeled only with a :heavy_minus_sign: sign. Deleting items from that list is destructive, whereas the :heavy_plus_sign: / :heavy_minus_sign: buttons make it seem like it's just housekeeping. (More like a list where you add/remove pre-existing items, so nothing is actually ever created or destroyed. It's all just inclusion vs. exclusion.)

2. The distance from the item you click to the edit button is kind of... excessive, now... no? Maybe it needs to be one of those lists like in the Network pane of gnome-control-center, where there's a :heavy_plus_sign: button above the list (at the top-right) to create entries. In those lists, it opens a dialog, but there's no reason it couldn't trigger the slide-pane instead. And I guess the Edit button could be there too, if the gear-icons-on-list-items thing is out.

But as far as deletion, I'd really prefer a Big Red "Remove" Button™ in the edit interface, something more explicitly ominous than a little :heavy_minus_sign: button lurking there looking all innocent.

IMOverlyOpinionatedAndNotVeryH-SoundingNowThatIReadItO.

[ferdnyc]

2. Maybe it needs to be one of those lists like in the Network pane of gnome-control-center, where there's a heavy_plus_sign button above the list (at the top-right) to create entries. In those lists, it opens a dialog, but there's no reason it couldn't trigger the slide-pane instead. And I guess the Edit button could be there too, if the gear-icons-on-list-items thing is out.

Although, actually, now that I think about it if Remove is part of the Edit interface, then really there's no reason that clicking an entry couldn't be the Edit action, because they no longer need to be selectable for any reason. There'd be only one action you could perform on an entry, from the list view.

[amivaleo]

I did some sketchy mockup to clearly illustrate my idea:

When click on the [+] button, this happens (Annulla -> Cancel; Salva -> Save):

The latter editor appears also if you click on the gear-button OR on a row. Whether to add that buttons or not, and if you want the row to be clickable, depends on you, guys. My advice is to keep the button because it helps understanding that you can actually do something with each item in the list. Of course, one can argue that, if you happen to need the Commands panel, than you are expected to be smart and courageous enough to try clicking here and there instead of staring at the screen trying to understand something as my granny would do. Still, I think that being redundant here is a pro.

No matter how you get it, if you want to edit an existing command, that editor appears. With one single difference: Save is replaced by Delete, in red.

[ferdnyc]

No matter how you get it, if you want to edit an existing command, that editor appears. With one single difference: Save is replaced by Delete, in red.

If there's ever a Save button, then you need to always show it, since it implies that the content doesn't auto-save. (There has to be some way to commit the changes.) Remove would need to be a third button, added only when re-opening existing entries.

Alternately, if changes do auto-save, then the only button that would always have to be there is Close, to make the edit interface go away. New entries could also show a Cancel, to abort the addition, which would then become the Big Red Remove Button™ when existing entries are reopened.

[ferdnyc]

My other question, with your mockup: What does it look like when you click to edit one of the existing entries? The same thing appears, with the edit interface at the bottom of the list... even if you click the very top entry?

Also, what if the bottom of the list isn't visible, because it's longer than the window?

[amivaleo]

If there's ever a Save button, then you need to always show it, since it implies that the content doesn't auto-save. (There has to be some way to commit the changes.) Remove would need to be a third button, added only when re-opening existing entries.

You're right. I completely forgot that. 😅

Well, in that case, the editor could show:

[Remove] -------------------- [Save]

"Remove" in red and "Save" with the ordinary greysh background.

if changes do auto-save

Sir, I hate that.

It makes sense if you changing some settings, but not if you put a lot of effort in writing a command, letter by letter, and then you don't find a "Save" button anywhere.

Definitely not, please...

Text editors can have auto-save but that is a feature that has to show some indicator somewhere when they are actually saving.

The same thing appears, with the edit interface at the bottom of the list... even if you click the very top entry?

Nope. My idea: THAT row you clicked is replaced by the editor, no matter where that is.

if the bottom of the list isn't visible, because it's longer than the window?

I didn't get this. The entire panel should be scrollable if it's not large enough to accomodate all the entries. o.O When the editor appears, the panel height is extended accordingly.

Didn't really get this question. 🤔

[amivaleo]

I hope this help.

That could be a possible scenario.

[ferdnyc]

Didn't really get this question.

Well, it was based on my previous one, that you answered in the negative. Given that, it was no longer applicable.

[Remove] -------------------- [Save]

"Remove" in red and "Save" with the ordinary greysh background.

I think you probably also need some sort of "Close" / "Cancel" ... some way to abort the edit, without forcing either a Save or a Remove.

As far as the last mockup... can't say I really care for that. I prefer @andyholmes' slidey edit-pane thingy to that. Otherwise there's too much going on inside the list. Seems confusing.

I like the layout, though, with the buttons Right. There., rather than way off at the bottom of the window, completely disconnected from the content they operate on. I just think it needs to be more the sole focus of the interface, when it's activated .Whether that means a dialog, or an edit view, w/e.

Again, IMO that nobody should feel they have to listen to or anything.

[andyholmes]

Here's some mockups from the design team that might give some good ideas:

https://gitlab.gnome.org/Teams/Design/os-mockups/blob/master/lists/list-design-patterns.png https://gitlab.gnome.org/Teams/Design/os-mockups/blob/master/lists/list-test-cases.png

FYI, drag-n-drop sorting is pointless though, since the Android app will do its own sorting and ignore ours. That's why its just alphabetical.

[ferdnyc]

(Ugh, speaking of bad UI, GitLab sure does make it suck, trying to view those giant image montages the design team inexplicably favor. My kingdom for a PDF, or even just multiple images that displayed larger than my actual thumb's actual nail. :stuck_out_tongue_closed_eyes: )

[andyholmes]

Yeah, that's probably the consequence of asking to collect usage telemetry, instead of just doing it like Github does. But we all know how that worked out for GitLab by now :P

[amivaleo]

https://gitlab.gnome.org/Teams/Design/os-mockups/blob/master/lists/list-design-patterns.png

The "row expansion" is close to my idea. IT could work as in Settings > Devices > Color, where only one row can be expanded at once and, if there's some unsaved change, the gui could keep that row expanded.

The sliding editor is way too much freaky!

[andyholmes]

Seems like it's starting to get pretty complicated :)

I'd rather keep it as simple as possible, and maintain sane keyboard navigation as well. I think if the current UI isn't acceptable, I'd probably prefer to just go for a popup dialog if anything.

[andyholmes]

Okay, it's a dialog now. But it took long enough that I don't really want to work on this for a long time, so any other changes will have to come as a PR :wink:

[amivaleo]

Okay, it's a dialog now. But it took long enough that I don't really want to work on this for a long time, so any other changes will have to come as a PR

Apologies, Andy. ._.

[andyholmes]

Don't apologize, just submit PRs :wink:

[amivaleo]

Don't apologize, just submit PRs

I'm not skilled enough. Can't even understand how to setup any ide for testing changes. 😶