Design critique

[flibbles]

I've been using Commander off and on since it synced up with Relink, and it's definitely useful, but there are a few design choices that seem like they could be improved upon. This is just a critique, and this issue can absolutely be closed after you've read it.

1. There is a dropdown arrow labeled "Select Tiddlers" which you must always expand in order to use Commander at all. I can't think of any reason why it would ever not be expanded since the tiddlers in a list are unselected by default. I suppose in the case that the tiddler list is so long that it pushes the controls off screen, but in that case, perhaps a split view would work better. Maybe the always-expanded list on the left, and the controls on the right, or something like that.
2. There's a button to "commit" a typed-in filter and show the resulting list, which is incongruous with the rest of Tiddlywiki. In all other places, the list updates with each keystroke.
3. Also, about the "commit" thing, is Commander doesn't seem to gain any benefit from it. A frequent operation I've done is to change the prefix of several tiddlers. This is tedious with Commander currently, because after I remove the old prefix. The list clears before I can add the new prefix. This seems at odds with the whole "commit" button, which would have me think the list won't change unless that button is pressed again. Right now, I have to add a dummy tag to those tiddlers to re-search for them so I can add the new prefix.

Just as a user, the kind of behavior I feel like would be intuitive would be that either search button to "commit" your search filter, the resulting list doesn't change or unselect until the commit button his hit again. OR the commit button wouldn't exist at all, and the filter list just updates with each keystroke.

Again, feel free to ignore these. I just know how it can be as a developer to sometimes not see how a layman would expect a program to work. I also may not be representative of how everyone uses Commander.

-Flibbles

[kookma]

Hi Flibbles,
Many thanks for your feedback. I highly welcome your comments and idea and I hope I can improve Commander for simpler interface and logic. So, here I will discuss to see how we can implement these improvements and NOT to reject the proposal.

I've been using Commander off and on since it synced up with Relink, and it's definitely useful, but there are a few design choices that seem like they could be improved upon. This is just a critique, and this issue can absolutely be closed after you've read it.

1. There is a dropdown arrow labeled "Select Tiddlers" which you must always expand in order to use Commander at all. I can't think of any reason why it would ever not be expanded since the tiddlers in a list are unselected by default. I suppose in the case that the tiddler list is so long that it pushes the controls off screen, but in that case, perhaps a split view would work better. Maybe the always-expanded list on the left, and the controls on the right, or something like that.

That is correct! I tried the tiddler list at the bottom of page and also side by side to controls! Each has some pros and cons but I welcome your suggestion. One solution may be to use initially selected tiddlers when the Select Tiddlers is closed and if one needs to select few of them, then expand the Select Tiddlers and un-select others.

Why by each operation the Select Tiddlers (selected items) is reset? Because some operations like removing tiddler tags needs to update the list of selected tiddlers! (they are not resulted from current filter search)

2. There's a button to "commit" a typed-in filter and show the resulting list, which is incongruous with the rest of Tiddlywiki. In all other places, the list updates with each keystroke.

That's correct!

3. Also, about the "commit" thing, is Commander doesn't seem to gain any benefit from it. A frequent operation I've done is to change the prefix of several tiddlers. This is tedious with Commander currently, because after I remove the old prefix. The list clears before I can add the new prefix. This seems at odds with the whole "commit" button, which would have me think the list won't change unless that button is pressed again. Right now, I have to add a dummy tag to those tiddlers to re-search for them so I can add the new prefix.

One reason for commit button is selective operation. writing filter to do this instead of checkboxes is tedious. If we ignore this feature, it seems we can remove commit button! In my opinion, the selective operation is useful and I like to keep it, but then we should modify the code and I think that is the way for now.

Just as a user, the kind of behavior I feel like would be intuitive would be that either search button to "commit" your search filter, the resulting list doesn't change or unselect until the commit button his hit again. OR the commit button wouldn't exist at all, and the filter list just updates with each keystroke.

I prefer to follow the Tiddlywiki behavior and I am not interested to have such commit button! We need to carefully see how we can remove commit without affecting Commander operation.

Again, feel free to ignore these. I just know how it can be as a developer to sometimes not see how a layman would expect a program to work. I also may not be representative of how everyone uses Commander.

Your commends help improving Tiddler Commander.

-Flibbles

[flibbles]

One reason for commit button is selective operation. writing filter to do this instead of checkboxes is tedious.

So this is the case where I'm not your typical user. I'm a blackbelt in filter-fu, and I typically write filters that contain exactly the tiddlers I want to manipulate. If most users type in filters that only approximate their target list, then I can see why a commit button might be useful.

the selective operation is useful and I like to keep it, but then we should modify the code and I think that is the way for now.

Arguably, you can still have it without the commit button. Suppose there's no commit button, and when someone types in the filter text-field, it updates the list on the fly. Now they have their approximate list complete with clickable checkboxes. They can check what they want. If they go back and edit the filter, it may reset their checkbox choices, but if they're altering the filter, then aren't they about to re-press the commit button anyway?

Because some operations like removing tiddler tags needs to update the list of selected tiddlers! (they are not resulted from current filter search)

This is true. That's why I would think the commit button would actually write the filter results to a state tiddler. That way the list remains unchanged even if the tiddler's themselves no longer meet the search criteria.

I realize this would require a little bit of logic when adding or removing prefixes to titles, so that the committed list is still up to date, but that wouldn't be hard.

I realize I'm sort of arguing for two different cases here:

1. There should be no commit button. Or...
2. The tiddler list should only ever update when the commit button is pressed.

Both ways have pros and cons, and I think it's ultimately up to you. It sounds like you're not a big fan of the commit button either.

-Flibbles

[kookma]

Hi Flibbles,
Okay! Could you make a PR and lets see how it is going on!
The first part could be removing the commit button but having the check boxes for selective operation.

[flibbles]

I could maybe do this at some point if I get a free moment. I wasn't actually angling to do it myself (which I realize is a little selfish), I was more just providing a critique of the UX.

I looked into it first, and the tricky part about removing the commit button is dealing with those check boxes for selective operation. Before, when you use the commit button, it resets the checkboxes, but you can't do that with a text field.

The best way I believe is to not bother. Instead, change the filter everything uses to be something like:

[subfilter{$:/temp/commander}] -[[$:/temp/commander/selected-titles]indexes[]] ...

And instead of doing that, put all that inside a special tiddler like $:/plugins/kookma/commander/settings/targets and then call:

[subfilter{$:/plugins/kookma/commander/settings/targets}] ...

everywhere instead. Not only would this make switching over to no-commit-button possible, it would generally increase Commander's extensibility overall.

[kookma]

@flibbles
Okay, Thank you for your help.

[kookma]

@flibbles
I tried to implement your suggestion as below

• by default the result of search filter is the target tiddlers
• if you want to exclude a tiddler then select it and everywhere use the

[subfilter{$:/temp/commander}] -[[$:/temp/commander/selected-titles]indexes[]] ...

The problem is if you change the filter still you have the selected item from previous operation. If you do no operation but from previous search you have selected some tiddlers they are still in $:/temp/commander/selected-titles and this affects the next operation.

I did not find a way to have both the selective operation and no commit button!

• when you click the search button it actually empties the selected-titles from previous search even you have not done any operation.

I just came to this solution to remove the whole selective operation and do everything by search filter!

[kookma]

[subfilter{$:/temp/commander}] -[[$:/temp/commander/selected-titles]indexes[]] ...

Assume you entered a filter selected some items to exclude and then before any operation you enter another new filter, then the items selected from previous search is in $:/temp/commander/selected-titles]indexes[] ...

[flibbles]

Oh whoops. That minus sign is supposed to be a plus sign. I did notice the issue of residual tiddlers being in selected-titles but I thought I'd accounted for that. I'm on a trip right now, but when I get back, I'll try what I suggested and see for myself.

I think I meant:

[subfilter{$:/temp/commander}] +[[$:/temp/commander/selected-titles]indexes[]] ...

Your solutions also works, but I still contend there'd be a benefit from having a $:/plugins/kookma/commander/settings/targets. I'll make a PR for this one though.

[kookma]

Okay! I tried something like this.

I thought it is better to check the idea in a empty.html to see how search and select works!
So, I tried the below solution. The selected tiddlers will be excluded! The main search filter will be used for operation

\define newVal() $(pf)$ -[[$(Item)$]]
\define removeTid()
<$action-setfield $tiddler="test" text=<<newVal>> />
\end

<$edit-text tiddler=test tag=input focus="yes"/>
<br>

<$set name=pf value={{test}}>
<$list filter="[subfilter{test}]" variable="Item">
<$checkbox tiddler="testIndex" index=<<Item>> checked="selected" checkactions=<<removeTid>> >&nbsp;<$link to=<<Item>>><$text text=<<Item>> /></$link></$checkbox><br>
</$list>
</$set>

on every change the main filter changes, still the problem is the remained selected items in testIndex from previous operation. I think we need to trigger an action when the filter search changes!

ps:
I think the inclusive or exclusive, both should work the same!

--Have a good trip, feel free to send the raw idea before putting much time

[kookma]

@flibbles
I am starting reread the Commander code and see how I can improve it!
I appreciate if you send me if you have any idea comments

[flibbles]

You've got a lot of repetition among your macros. I can't speak for all of them, but a frequent operation of mine was to replace title prefixes, instead of just adding or removing them, so I coded that into my local repository. However, in the source/commander/title/uicomp directory, the same macro exists, like, six times I think with only a single line difference between them which could easily have been an argument.

So I only programmed my title-replace into the prefix, and didn't bother with suffix (or the other one. Pattern match?). I'm guessing the code could be more DRY in other places too.

Also, many of your macros have typos. like replacePrefix-tiltle-bulk. It's so common, I started to wonder if it was deliberate. Is it?

[flibbles]

Also, a UI improvement:

When you type in a filter. Results comes up automatically now, which is nice. That means one less click. However, all results that come up are unselected by default, and the "Select Tiddlers" drop down is closed by default. This means another unnecessary click regardless of how you use Commander.

I'd say all filter options should be selected by default (my preference), or that dropdown should be open by default.

[kookma]

You've got a lot of repetition among your macros. I can't speak for all of them, but a frequent operation of mine was to replace title prefixes, instead of just adding or removing them, so I coded that into my local repository. However, in the source/commander/title/uicomp directory, the same macro exists, like, six times I think with only a single line difference between them which could easily have been an argument.

Here there was two options:
-simple code simple to understand but many repetition
-complex code with no repetition

I selected the first route! By the way in Commander 2 I will look to see where they can be improved!
It is good to exactly refer to them. Then for me it simpler to find and work on them

So I only programmed my title-replace into the prefix, and didn't bother with suffix (or the other one. Pattern match?). I'm guessing the code could be more DRY in other places too.

If you don't mind share them and I will look at them

Also, many of your macros have typos. like replacePrefix-tiltle-bulk. It's so common, I started to wonder if it was deliberate. Is it?

At the time of development there was lack of time and a rush to finish it as soon as possible! So, I did not come back and correct them! The documentation also needs improvement!

[kookma]

Also, a UI improvement:

When you type in a filter. Results comes up automatically now, which is nice. That means one less click. However, all results that come up are unselected by default, and the "Select Tiddlers" drop down is closed by default. This means another unnecessary click regardless of how you use Commander.

I'd say all filter options should be selected by default (my preference), or that dropdown should be open by default.

I addressed this commander-ii beta