If I use the delete key here in the image above, it will not make any changes.
What it could do differently is instead of having the user highlight the points below and having them hit shift+tab, it could shift all of the points below back by one.
Hmm… I like the intended functionality. A couple of thoughts about the implementation, though:
I personally would be very surprised by the proposed behaviour, and I think Principle of Least Astonishment is important to think about.
Hitting backspace at the beginning of an item already has a function: merging it into the previous item (if a previous item exists and is childless). Having a different behaviour in certain edge cases feels confusing.
What should happen if a previous item existed but had children? (Perhaps just the fact that I have to ask is a bad sign.)
I often hold down backspace when I have a lot of blank items I want to get rid of. I wouldn’t want something odd and major to happen if I go too far.
I agree with you there, especially if there isn’t a visual indicator.
Assuming I’m understanding what you’re saying correctly (backspace vs delete key), I should’ve mentioned that the backspace key does not work, either.
Like this?
In that case, since your cursor would be moving upwards, it would start at the lower levels of a bullet point (the children), in which case it the same behavior would apply. This shouldn’t change that, AFAIK (as far as I know).
The way I see it, would be that it would still be considered as merging, via unindenting the following items.
I think in that case, it should just affect that point’s tree and just unindent those items. Sort of like a succession.
Right, that should work as expected. But if you were to delete X Bar, it should let you unindent Baz 1 and Baz 2 so that way they would be in the same position X Bar was.