I don’t think so 
Possibly a slight misunderstanding ?
( not a beta - just a demo of a couple of things - particularly of a flexible approach to defining display styles )
Right, sorry for the imprecise vocab. In any case, I just wanted to voice concern about text selection’s behavior possibly changing.
I wonder if I am missing something here ?
When I select text, it tends either to be:
- within a row – part, but not all, of the row text. Moving a word or clause for example, OR
- One or more whole rows. (Moving some rows to a new position, for example)
What I don’t find myself doing is selecting across row boundaries …
I can’t immediately imagine, for example, selecting the lower half of one row, and the top half of the next row.
Can anyone explain a use case in which they feel that that might arise in their rough drafting or restructuring ?
Wouldn’t it just be a symptom of the document’s segmentation failing to match its meaning ? A case of needing a simple row split keystroke ( 
) , or perhaps row join ( ⌫ ), in other words, rather than an exotic selection ?
Have users of OmniOutliner, for example, complained that such half and half selections (across row boundaries) are frustrated ?
(I don’t think I’ve ever noticed any discussion of that kind …)
Yes. Shortening a point made across two paragraphs into a single paragraph for brevity and moving from abstraction to concreteness. Or taking one piece of narrative/dialogue and placing it somewhere else.
Those are certainly core elements of outlining:
- subsuming the expansive under the pruned or abstracted
- repositioning elements
but neither of those seem to have an obvious connection with selecting the latter half of one row and the first half of another …
Can you help me with an example or two ?
Are we talking about merging rows ? Splitting them ?
Are you thinking of an operation which is impossible, or incurs more friction, in something like OmniOutliner ?
- Splitting a row into two rows (at the cursor point)
- merging two adjacent rows into one
both of these are, I notice, easier in Bike 1 than in omniOutliner.
Splitting:
- In Bike 1 we hit a simple return ( )
- in omniOutliner it has to be control-return ( ^↩ )
Merging:
- With cursor at the start of the second line, in Bike 1 we hit backspace ( ⌫ )
- In omniOutliner, that needs to be control-backspace (^⌫)
(More burden on memory – less intuitive – frustrating if you have to look it up)
I’m not sure we’re talking about the same issue.
Bike v1:
vs. Craft (block editing)
This is only one sentence. Imagine how many of these come up in a 100k+ word draft.
how many of these
these refers to splits ?
Can you describe the friction you are aiming to represent with those videos ?
Without words it may not be quite as clear to an observer as it is clearly self-evident to you.
It looks as if your point may be about splitting, but I am not yet sure …
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.
2 Likes
So, if I’ve understood, getting two splits:
- one in the row above
- one in the row below
by
- extend select across row boundaries + cut, rather than
- split one row, then split another.
?
I think I can see the economy there.
(Though I can’t say it’s a pattern that arises much in my own writing – perhaps I make more granular use of outline rows)
That, plus losing the initial selection entirely if you overstep boundaries by accident. I think that’s the bit that irks the most with block editing.
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.
1 Like
Suggestion for a solution:
Bike 1.0 has two modes:
- Text mode
- Outline mode
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.
2 Likes
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*
1 Like
Please do keep trying to demos and let me know how it goes.
2 Likes
Legend ?
(A link without a URL there, I think)
Sorry, fixed the URL.
1 Like
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
Andy
1 Like
Thanks for trying Bike and feedback.
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.
2 Likes