No, in this example it’s actually merging two adjacent rows, but performing that merge by cutting out a selection of text spanning both rows, to be pasted elsewhere (or removed altogether). In my example it only includes the dialogue quotation mark in the second row, but that can vary from a single character to a few full sentences. This may be specific to editing prose.
And it may be that the block discipline, so helpful in the systolic stage of taking stock and organising, does costs perceptible friction in the looser, more expansive, diastolic stage of discovery, splurge, and unconstrained expansion.
Perhaps an editor that serves both phases of the mental cycle – growth and pruning, if you like – does need, ideally, to be as utterly unconstrained as possible for one phase, and as helpfully structuring as possible for the other.
If I understand it correctly, Bike 2.0 now works like this: It kinda only has one mode, but will automatically slip from “Text mode” to “Outline mode” if you select outside the boundaries of one row.
But how much extra complexity would it add, for people like @Gorgonzola to be able to turn off the slipping?
Because first I thought it would be a lot, because maintaining one mode is simpler than two. But isn’t there already two modes in 2.0 as well? It just automatically switches between them. And if this is the default choice, you’d still get the benefit of the simpler on-boarding.
Thanks for all the feedback. I think my next demo/focus will be making the selection implementation more real. In current state I think it’s a little hard to tell what is part of the “block” design and what is unimplemented or a bug.
As a small example, in current demo when you select text it indicates that selection by drawing a strikethrough… confusing for sure.
For instance:
This will not be part of final design. It shouldn’t even be part of current design, but there are some bugs, plus the fact that selected text is indicated by strikethrough makes it confusing to tell what is going on.
The intention is when you overstep it will go to block selecting, but when you move cursor back into original row it will snap back to character selection mode until you again extend outside that row. This is both when extending selection with mouse or keyboard.
Maybe confusing to explain, but let me get the bugs out of the current implementation so you can try. I think it should work pretty well.
This is mostly true, but a few more points:
In Bike 1.0 when you are in text mode outline editing commands have a different behavior then when you are in outline mode. For example TextEditing vrs OutlineEditing. So fundamental commands such as delete and move change behavior. I like that design in some ways, but I’ve changed my mind that it’s the best approach. The Bike 1.0 approach adds two kinds of complexity:
Two modes with different editing behavior
Almost all existing outliners and block editors don’t work this way, making Bike’s approach the unfamiliar one.
In Bike 2.0 the plan is to simplify by working how almost all existing outliners and block editors work, but then take extra time to improve and polish those interactions.
For instance, avoiding the above described problem in Craft where if you select too far you’ve lost your text selection. Other areas where block editing is often rough is caret movement between lines. There are lots of little details that I think when done well will make the selection/edit system feel nice.
Hopefully by Friday I can make this all more concrete with a new demo.
This is very true. I think Legend implements both of these fairly well (but not ideal), I still wouldn’t use it to edit prose I think I understand your change of heart, it makes sense to position Bike in the outliner space. I liked the hybrid outliner-writer approach, it felt non-Electron, fresh, and the Escape button actually did something cool. Oh, well *exasperated sigh*
I’m underqualified to comment, as I’m not using all of Bike yet, and not highly skilled in what I am using, but I’m using outlining extensively and want to put in my two cents that I LOVE the two modes (disclosure: I’ve used Vim some, but not deeply). For me it is intuitive and clarifying, not confusing (= simplifying rather than complicating) to have two modes. imo it doesn’t take long, nor is it a steep learning curve, to get used to two modes. I love, when in outline mode, I hit left arrow (without a modifier key!) and it collapses the branch, no matter where I am in the outline.
In outline mode, highlight three lines and promote/demote/move, bang left arrow to collapse the newly created branch, then move it where you want it, into a different branch or whatever. Good stuff!
But I also love limited and slightly different outline functions in edit mode, e.g. I can move a line independently from the outline branch it’s in, no worries about where it’s going to pop to like when I move a branch in outline mode.
The mind readily snaps back and forth between edit and outline mode. Maybe standardizing some of the outlining keystrokes between both modes would help, but don’t lose the editor’s differing outline behavior. I need both of these functionalities, and separating into modes is good. The highlighting in outline mode assures you can’t forget which mode you’re in. Maybe the keystrokes could be simplified, standardardized for the two modes, but please don’t lose the two modes.
Not sure what you mean my ‘more like a traditional outliner, less like an editor’, but I for one greatly appreciate the editor/outliner mode shift. Keep and enhance both modes!
Added complexity does not equal complication. Well structured complexity equals clarity and simplification. Two modes is an added complexity that simplifies!
Repeating myself again and again: I’m all for different outlining behavior in different modes!
jmtc
I just wanted to respond to clarify that in either case Bike will still have two modes, with many of your “likes” intact. Escape key to toggle. When in outline mode arrow keys to expand/collapse… and eventually I hope a bunch more VIM like single key commands.
The big change will be that when you select more than one line you automatically enter outline mode… so text mode is only within a single paragraph. Also I want to remove the difference in behavior of the move commands … they should work same in both modes.
I understand that some of those changes are also removing things that you like, just wanted to make it clear that underling design of two different modes won’t change… and a number of your mode related likes will remain in either design choice.
I’m glad this change in functionality is planned for 2.0 — having child rows move with the parent regardless of mode is one of the reasons I like using dedicated outliner apps