The "affinity cursor" is a really lovely innovation. Most HTML/DOM/contenteditable based rich text editors end up adding support for virtual cursors that enable you to have the insertion cursor somewhere that the native browser cursor hasn't got support for (next to a floating image, end of a table row). Effectively this is what this is doing.
Internally the inline formatting will be marked as tags in a rage, exactly like html. Essentially there is a possible cursor position both inside and outside a formatting tag, but both appear as the same visual location on the screen. This is such a lovely way to indicate the difference.
So with this code:
Something <b>bold</b>
There are two cursor positions that are visually the same place:
Something |<b>|bold</b>
^ ^
Most editors "jump" over one of those positions to hide the implementation detail from users. This idea exposes it with a little tail on the cursor.
I really wish browsers would support this for `contenteditable` (even without the tail, just having some way to put the cursor in either position, maybe based on from what direction the cursor is coming from).
Slack's message editor is `contenteditable`-based, and it means there is absolutely no way to put the cursor inside at the beginning of e.g. an inline code snippet.
Despite the code snippet formatting having an outline border and some padding, meaning it should be possible to even click inside or outside the snippet unambiguously just with your mouse, Chrome will always place it in the same spot and you have to do the awkward trick of replacing the first character.
This single behavior makes `contenteditable` so terrible
It is possible via JS to place the cursor in that position. The issue is the a native browser cursor navigation skips over it. It would be quite possible to implement this on a contenteditable editor.
That particular bug with slack would be possible to fix with JS. The particular difference about that style is there is a little bit of padding at the start of the style. Bowsers have no understanding of clicking on that padding to select inside the the beginning of the inline style.
The behavior for inserting text varies by browser and/or OS, unfortunately. I made [sandbox] to test this. Click the button to set the selection to the first position inside the first <strong> tag in the contenteditable div.
On my Mac, Firefox 104.0.2 inserts new characters inside the <strong>, so they're bold.
In Chrome, the browser API allows positioning the selection there, but during the input event, the selection ends up normalized to just before the strong tag, so the characters aren't inserted into the <strong> tag.
In Safari, the browser API accepts the arguments to set the selection to the first position inside the strong tag, but normalizes during the API call, and the selection always ends up right before the strong tag.
The variance of contentEditable is a huge impediment to using the API raw. If you want reliable, relatively low-level control of rich text input on the web, use ProseMirror.
(I learned a lot about this stuff while working on Notion's rich-text editor, which is all custom.)
Thank you for the example. I do mostly the same thing and as a Safari user there is no way to place the caret in "the right spot". What I found working (but I still have to test on other browsers and make my mind if it is really worth the hack) is to place a dummy marker with [contenteditable="false"] at the beginning and the end of the inline elements (the one on the end has to be skipped to avoid getting stuck in a limbo inside the parent element). This way the result is similar to the one in Bike, with the caret that stops on both sides of the element. Let's see if this thing goes somewhere...
Of of the top of my head, you'll need to watch out for:
- The default behavior that triple-click to selects a whole paragraph/line will stop at the first contenteditable=false element.
- Android may dismiss the keyboard & selection if the selection ever touches one of your contenteditable=false marker elements.
- Firefox won't let you place the caret in between two contenteditable=false elements, or at the start or end of a contenteditable=true element if the first/last child is contenteditable=false.
I am sure that there are plenty more! Working on top of customeditable is hell, but it is the price to pay if you want to implement a custom editing experience. Of the issues you listed, the triple-click is a good one, and easy to solve with a custom handler (even if there is no tripleclick event, the detail property of the event object holds the number of consecutive clicks). I am pretty sure that ProseMirror does something similar, because it uses [contenteditable="false"] decorations without interfering with the triple-click selection. For mobile devices and Firefox I would surrender, and gracefully degrade the editing experience.
Why not use ProseMirror? It doesn't fix this issue, does it? At least in the demos on their website you cannot insert text at the beginning of a styled element. You cannot do it even in a native application (at least on macOS) without a custom handling of the selection.
Thanks for the sandbox. I'm working on a company-wide blog post on a good richtext editing strategy / library and wanted to demostrate how unpredictable it is with contenteditable. This sample is perfect and I'm thinking of hyperlinking the sandbox :)
Do you happen to have any more samples to demonstrate how difficult it is to work with contenteditable APIs?
Oh, I made that sandbox for my HN comment. I actually have a similar internal blog post & several more complex examples I built for that, but can't share any of it publicly.
I just started experimenting with contenteditable yesterday so there might be an easier way, but I think you do this by manipulating the Range object in window.getSelection().
I think natively if you don’t jump into a tag and you don’t jump out of a tag. So if your cursor is in the tag and you move to the boundary, you stay in it. Similarly if you are outside of it, and move to the boundary you stay outside of it.
So I basically would listen to the the relevant input events, see if I’m at the boundary and the orientation of the cursor (which I save in memory) and if I’m only moving across a boundary (i.e. not to the next character) I call event.preventDefault(), manipulate the range accordingly, and update the orientation state.
I’m not sure how to style the caret it self (other then the color) but I’m sure it can be achieved with some absolute position hacking.
You'll need to track your own selection state and take over actually inserting the characters by calling preventDefault() during beforeinput in Chrome and Safari. Both Chrome and Safari will fight you on this one. To say nothing of Android...
When I came up with this feature in Bike I was pretty proud of the idea and it seemed original. Then a few weeks later I came across your post on StackExchange UX... everything already been invented I guess :) I'm curious how you came with idea? Also have you come across other editors that implement it?
For me I new that something bothered me about rich text editing... always seemed more painful then required. I was also aware of the idea of split cursor from Humane Interface book. And also aware of affinity idea from text cursor position in wrapped text editor lines. Bike's typing affinity came from combining those ideas.
Anyway would love to hear any related thoughts or ideas.
In https://tigyog.app I'm solving the same problem in a different way. Like Bike, the TigYog editor treats those two cursor locations as district. But TigYog shows which position you're at in a different way: when the cursor is inside a link, the link gets a "focus" outline.
Microsoft Word never had problems with inserting any formatting at any position in the text. It also has some visual style indicators via caret shape and size.
MSWord doesn't have formatting codes, at least not for simple text styles. Instead, each individual character has formatting attributes. So the word italics is not a single italicized region, it's 7 separately italicized characters, that just happen to be next to one another. It's a radically different model from HTML/markdown/WordPerfect markup.
Microsoft Word may never have problems inserting any formatting, but I have; when it comes to paragraph structure, indenting and such, I find it very hard to predict. For example, I'll look at sections of a document with basically the same structure, but in one place the spacing between a table and the paragraph that follows is much larger, and I have no idea why or how to make them the same.
I guess it won't work for rich editors that create tons of elements for every style applied, like `<b><span style=font:...><span style=...>...<i>...` it requires some sanity of the editor.
Older content editable editors would do that. But modern ones have moved to not nesting inline styles, and separating internal data structure from the exported html. Full html isn't really that great for the internal data structure of a rich text editor.
Think of them as having only a none nestable <span> tag with a style attribute.
I don't think it would matter, text affinity happens at texts "run" boundaries... so only where formatting changes. Doesn't matter how many attributes each run has. I think that is proper way to design the feature, but it does means it's maybe less flexible then you are thinking. You can pick left or right run... you can pick individual attributes within a run with text affinity.
It works on text "runs", so there will only ever be two choices. In the case you describe there's no way to choose only bold, or only link... you would need to revert to standard rich text dancing for that.
I'm Bike's developer. Thanks everyone for the comments.
While I have the eyeballs I hope you don't mind me asking...
I'm in process of adding autocomplete to Bike. Problem is that I generally find macOS autocomplete painful and unpredictable. I both disable it and have many typos. I'm not talking so much about the suggestions, but about the surrounding UI.
I'm looking for ideas/links for how to make autocomplete better and more predictable. I know Mac apps, I do know much else. What are your favorite autocomplete implementations past or present? If you could have a "fixed" macOS autocompletion what would it look like?
Great product and new features! Will definitely try it out when I get a chance. While I am right in your target user base, over a decade ago I built https://zetabee.com/text for myself and even though there are now so many better solutions to the text outlining problem, it is just too difficult for me to switch. Not sure what your keyboard binding for collapse/expand is but I played with backtick (single key) and loved it because it just feels natural and I never type ` in my notes.
Long ago, I tried to make a better autocomplete feature so people with speech disabilities have fewer buttons to push. Here's what I did - https://ktype.net/wiki/research:articles:progress_20110209 - basically broke down tweets into n-grams (1-4) and then used the 5 most likely next words as suggestions. If I were to do this today, I would still try to get a large volume of text in my target use case (what do most of your users type? Tech project notes? home construction items? grocery lists) and break them down into large lists of 2-3 n-grams. Then ask GPT3 (or equivalent) for 3 possible suggestion for next 1-2 words and save them. Compress and hard-code this list into the app (or alternatively make it download/update from your site infrequently).
If you would like me to explain more, please feel free to reach out!
Your outline project looks great. Hard to beat an app that you make yourself and can change when you see fit.
Bike does have a keyboard shortcut for expand/collapse, but truth is I don't remember what it is without looking. Instead what I do is always exit to "outline mode" with escape key, and then use left/right arrow keys.
Outline mode is inspired by vim, it's a mode where there is no text input, so you can use typing keys for other purposes. Right now it does very little, mostly just expand/collapse and delete. I hope to expand on this in future, but right now I'm more focused on text editing fundamentals.
Thanks for the autocomplete links. I maybe didn't explain well in my question... but I think I'll leave the actual autocomplete logic to macOS. I want to integrate with their autocomplete system so users will have consistent experience that way.
I'm more interested in UI problems of indication that correction has happened and easy undo when corrections go wrong. In this regard I think macOS is pretty poor.
For example on macOS if you type "hello " then after the space it will be corrected to "Hello ". If that's not what you wanted then there aren't really easy options to undo. Of course you can undo... but that will remove the space and then select "hello". Then another few keystrokes to get back to what you wanted. On the other hand in Google docs all you need to do is backspace and it undoes the autocorrect. I like that and will probably copy, but am looking for more autocorrect systems to learn from.
One of the most important changes that I've noticed in autocomplete on iOS (I have it disabled on MacOS, so no idea how it works there), is this:
Old behavior: Autocomplete suggests the word I want partway, but by the time I tap it, I've typed additional keys and the suggestion changed. Deleting and trying again would enter the same mistake.
Current behavior: Autocomplete suggests the word I want partway, but by the time I tap it, I've typed additional keys and the suggestion changed. Deleting a few characters causes it to suggest (again) the word I actually wanted. It remembers the next most likely suggestion and I can quickly select it.
This change in behavior was the most significant improvement that I can recall. It went from maddening to somewhat annoying but useful.
Please keep up the good work. Mac nerds who care about high-quality native apps appreciate what you're doing.
> I have it disabled on MacOS, so no idea how it works there
Well that's really at the core of my question. Why do you have it disabled? What need to be improved so that you don't disable it.
I think almost everyone would agree that if you type "teh" or other common typos it would nice for computer to automatically correct them. But many people (myself included much of the time) disable autocorrect. I think this is because the UI isn't ideal.
I'm looking for ways to fix that. Maybe it's not fixable, but if you can enumerate specifics on why you disabled autocomplete on macOS I might come up with some solutions. Thanks!
Sorry that this isn't very likely to help you gain much actionable insight.
I just turned the feature on for the first time since originally disabling it whenever it was introduced.
After playing with it briefly, it isn't fast enough to offer me any real help. Perhaps if I was hesitating on spelling a challenging word (does it have two of that letter or just one?) it would help me out. But I don't run into those scenarios often enough that it'd be worth the other downsides.
Just now, when I wanted to manually enter typos in the bottom line, it was clunky to dismiss without changing the words. I could mouse over the X or use the arrow keys to change position. Maybe there's another way that isn't intuitive to me? Maybe Esc, but I've already disabled it. Point is, it broke my flow.
I prefer to have the computer point out to me when I spell something incorrectly. It's a method of reinforcing the correct spelling. Then I can hopefully learn not to make the same mistake in the future.
Finally, as I've had it on while typing this post, it autocorrected a typo to the wrong word (amke turned to take; wtf). Had I not noticed, it would make my sentence strange (though most would just assume I was typing on a phone). That's fine on a web forum, but that's not acceptable in professional emails and the like.
It's just not useful to a life-long computer user with a full-sized kbd. However, despite 15 years of thumb typing on phones, the targets are still small enough and my thumbs are still large enough that it's mostly useful.
PS: Because I'm a fan of text-substitution apps (I use aText, but TypeIt4Me is also well-regarded), I already have custom entries for things like hte or thakns).
> I'm looking for ideas/links for how to make autocomplete better and more predictable.
Consider taking a hint from every code editor. As the user types they are presented with a drop-down list of completions and corrections for the current word. This list hovers below the cursor and moves with it. The top item of the list is automatically selected such that hitting the completion key combo (often just the Tab key) replaces the current word with the selected item from the drop-down. The elements of the drop-down are sorted by likelihood of them being what the user meant to type and are navigated with up/down arrow keys. Hitting escape hides the completion drop-down and allows the user to use the up/down keys to move the cursor. At any time the user can press a key-combo to bring up a completion/correction drop-down for the word under the cursor.
I agree code editor autocomplete is a good design for searching through space of options efficiently. I'm not sure if that design works for "autocorrect" in general writing instead of code editing.
I guess you could popup a list of all possible matching "correct" words as you type, but that would likely get old fast for normal writing. You would always see the popup. Generally autocorrect (fixing typos and spellings) happens once you have finished typing a word. At that point the word is checked, and maybe autocorrected.
I think that basic design is good. Finish word, then autocorrect if there's a high quality match. The place where I think problems happen and maybe a better design can help include:
1. Clear indication of what has been autocorrected
2. Easy way to revert autocorrections
3. Don't pop up to much UI during this whole process
I love Bike so much on my Mac. It’s light and nimble in a way that OmniOutliner never was, and makes me want to use it. I’m a very happy customer! My only “complaint” is that now I desperately want it on my iPad. “Light and nimble” are especially important on mobile and I haven’t found an awesome alternative there.
I'm not a user of Apple products, but in the Linux world there are code editors that enable the user to define custom completions. I find this to be an excellent productivity feature, not just for coding.
Thanks. I agree the way that programmer text editor handles snippets is nice. I think this is a pretty good and clear UI already.
For autocorrect I'm talking about corrections that are less predictable such as spelling or grammar errors. They can be very useful because they mean fixes happen without any extra work, and mean you don't see lots of red spelling errors in your document... but it's also a case where computer is doing automatic work that sometimes might be wrong. So needs good way to indicate that correction has happened and easy way to revert.
I've been doing indie Mac software since around 2003. Mostly full time with some consulting mixed in. I've had varying levels of success. Generally business grew into (enough to support me and three others for a few years) until around 2012. Then down down (with very little bumps of success in-between). Since 2012 it's been just me. I make less than I would in a "real" job. Sometimes quite a bit less. Even with Bike's recent success I'm mabye making less than average US programmer.
Some of this is likely due to indie being hard. Much is also due to me being mostly programmer driven, not business driven. I am doing many stupid things business wise. But I also get to work on exactly what I want to work on.
Very nice. I love these little innovations, it’s exactly the type of design ideas that makes me want to try an app.
I wonder if it’s an intentional easter egg that the keyboard shortcuts in the popover spell out “bischl”… which is more than a little reminiscent of “bicycle”. (Could improve it by replacing “h” for “highlight” with “y” for “yellow”: “bisycl”.)
No easter eggs in Bike yet... though I should add something someday. At the moment just trying to get features in to make it a good place to work and think.
The video, demonstrating the features of the rich text editor, is well done. Now I want to try this Bike app (unfortunately I have no mac). I hope more developers will copy this whenever they are implementing a rich text editor.
For me, it was too long and verbose: instead of showing with no prior knowledge, it starts telling me how intuitive stuff will be. Also the sound started activated and by clicking, as instructed by the blinking text, I disabled it, which was confusing.
This is genius. Very clear explanation of what's wrong with rich text editing too. Especially frustrating in Slack. On desktop they support "Mrkdwn" (a bastardisation of Markdown) but there's no way to do custom link text with it at all! The only way is if you switch to their shitty WYSIWYG editor.
In their app I think you can only use WYSIWYG, but it's full of insane flaws, like if you open a code span (backticks) and then close it but don't immediately enter some more text then there is literally no way to escape it into normal text again. You have to delete the whole code span and start again.
If anyone from Slack is reading this, fix your shit!
That sounds an awful lot like what emacs is doing in org mode (if you configure it too). I have to say, it's often nice, but sometime still gets in the way of editing in my experience. So I'm often conflicted if I want this or pure editing of the org without the rendering.
I was just going to comment about how bringing features like this to org would be great. Do you know if there's a way to have caret affinity displayed in org, or equivalents for the other features mentioned? Sorry if they're obvious features, I'm a bit rusty on the latest developments.
Text affinity and the command pallet is innovative. Could probably bundle this up as a Objective-C library that acts as a drop in replacement for UITextView/NSTextView. Perhaps a JS/WebComponent library for <textarea> as well. I’m sure you could extract some revenue with licensing those libraries or tech support.
For puzzle one, in Microsoft Word, control+space clears direct font formatting from the cursor (or if text is selected, the selected text). So exactly a consistent way to go back to unformatted text.
For puzzle two it uses some opaque heuristic to decide where to insert the text, I wouldn't really on it, I'd right click and edit the link.
Thanks, I didn't know about Control-Space on MS Word. Looking in menu's I see "Clear Formatting" menu item, but the shortcut isn't listed. How did you know about this shortcut?
I don't remember. I spend quite a bit of time editing in Word and usually end up searching if there is something I think should be possible and don't know how to do, and I'll keep an eye out for other tidbits when reading.
My solution, when I coded my own word processor, was to use a single, invisible control character, '¶' ¹.
So, for example, bold would be enclosed by '¶b' and '¶B', and a first-level heading would be a line starting with '¶1'.
So, there exist characters in the text that are invisible but you know are there: you can insert the couple and delete it just like any other character.
¹(part of the extended character set - '¶' is easily accessible on some systems as [AltGr]+[R])
Two chars - fixed amount. One control, one command. Just cleaner, simple and functional. It's something you type, and it is hidden, you want it to be short and clear.
«How is that different», more literally: it is markup, like in htMl, but it is a special markup for that other special purpose of direct rich text tagging in word processors, not for hypertext (HTml). I called it differently, but if you so fancy, it is DRTTIWPML.
I love all of these features. The link part is a little rough. I think this is the best choice out of a space or bad options, but it sucks that it means that the thing a link does 99% of the time has to be flipped on its head. I don’t see a good alternative though; if you make it an “edit” button instead of a “visit” button, you make normal text editing super inconvenient, and that’s the effect users will usually want in an editor.
I agree it's not perfect. In particular it's a little weird to highlight the link text blue since it's not what you interact with. Mostly just makes it easy to see and then find the link button, also useful if you are planning to publish a document so that you can see where the links will be in published document.
One feature that I do like about this design is it's pretty generic. For example in the future I could imagine detecting dates and then insert a button after the detected date to interact with calendar. I think the general idea of inserting simple interaction button in text can be quite useful.
Yeah a lot of love has gone into that. I like the subtle animations as the caret slides rightwards whilst typing or the "_I_" appears above it when he sets it to italic.
Is that really true? I had a feeling that macOS desktop developers are on the decline.
There are certainly a lot of Windows-only apps that are quite nice.
Further, as a person trying to develop a cross-platform, desktop-only GUI framework and applications, macOS is absolutely the worst offender on nearly everything. From only supporting an outdated OpenGL version to requiring that windows are managed on the main thread. Neither Windows nor Linux have either of these limitations.
Internally a lot of editors don't nest inline styles like that. The formatting is more like a style attribute on a <span> tag, listing all style properties. So you still only have two positions, previous formatting to the left, new formatting to the right.
If I were implementing this, I would ignore the middle one. There's virtually nothing visible to the user that there is a middle one OR that <b> is actually placed before <i>. I feel handling this edgecase causes more UX problems than not.
The approach I took with my own hacky editor component was to highlight the styles that currently apply at the caret position via toggle buttons for B, I, etc. This is something word processors have been doing for decades, although I recognise it's far from a perfect solution.
Writing the text editor has certainly been painful and taken me a long time. This particular feature (typing affinity) isn't actually to hard and I think could be bolted on to most existing edit editors. Really you just need to take one extra bit of state... and then can calculate cursor drawing + moment based on that state and all the other state the editor normally tracks.
This looks awesome. I do all my writing (creative writing, outlining, todos) in Bear and really love it. But this app seems like it would make outlining more fun and intuitive. Def gonna try it!
Great to see fresh, innovate apps like this that prioritize fast native experience.
The cursor affinity could be entirely subsumed by the visible typing attributes, which might be more intuitive. For both, I'd worry about the user's cursor configuration affecting things - it could be safer and more widely compatible to have it float nearby rather than have it attached to the cursor.
The link editing doesn't seem like an improvement on other rich text interfaces, with no visually obvious way to edit the link destination.
A keyboard shortcut that tells you other keyboard shortcuts isn't at all innovative, but it is handy and more software should have it.
Brilliant idea. I am actually just researching how to build my own structured document editor for the web, based on my parsing engine for Pyramid grammars, and I'll certainly examine how to apply this idea in my context.
It's not actually a straightforward idea. It's just good design. No project manager will ask for it (just as no one asked for multiple cursors until sublime came along and won lots of hearts with it). There's plenty of space for such ideas which will all feel stunning. But, surprising they were not made before, neah...
I think this is a great example of where an individual can really innovate on their own, but they do need to have a good mix of experience with developing on a particular platform as well as a good sense for UX.
Working in a larger company, you tend to have each of those tasks (implementing vs designing) split out into multiple roles, making it very difficult to know what's possible to innovate, plus experience levels often differ, so newer designers may not know the limitations on a platform, so may over-design, and developers may not have experience to implement certain things, so they may limit the end result as well.
Please see footnote in linked article. Like all ideas it's probably been invented many times before. But also like all ideas you need to invent, make good implementation, and then hopefully luck into people finding out a about it.
Of course, but it doesn't seem that any currently available text editor has this. Even the one mentioned in the Stack Overflow post is now gone, it seems.
Still, this looks amazing - thank you for implementing it. Would love to see this formatting UI used in more apps going forward.
There're some other editors that have similar behaviors. AFAIK, CKEditor [1], an online rich text editing framework, is optimized for cascaded formatting tags. A <pre> or <a> element will be highlighted if the cursor is "within" its context, and when your cursor is at the edge of such an element, you can press the arrow key again to move into/out from it.
It always makes me smile to see Hog Bay Software releases get such positive attention. Jesse Grosjean is one of the only indie developers of note that I am aware that are based in Maine. Makes myself, the aspiring iOS developer, not feel so alone in this state. :)
What Jesse is doing here for rich text editing is astounding, to me, and is exactly the type of advancement that the popular word processing apps should take note of.
Rich text posts in HN constantly recalled this personal story that I am waiting to happen (e.g. be developed by someone else).
Since the use of an early Palm Pilot [1] I wanted to have a personal wiki. It was a little awkward in that moment comparing to something like a Squeak Wiki [2]. So when the iPhone 1 appeared [3] there was another call.
The first versions of iOS didn't include text selection and copy and paste to generate links to new pages. In this context I did a basic reverse engineer of the UITextView and could advance this towards the "wiki dream" but it would never be accepted in the Apple Store so I abandoned the idea that was basically without a business perspective.
As tptacek [4] said recently: "For several years I just use Apple's Notes.app. It's honestly pretty great; it's frustratingly good..." [5]. I would add: but it will be more great if they add native hyperlinks within the internal notes.
For the hyperlinks, it seems editing the text and visiting the link is easy. But there isn’t a way to edit the hyperlink itself quickly?
Have you considered using affinity cursor along the up/down for that as well? Eg. Up updates the hyperlink content while default/down updates the link text.
Not sure how it would work out UX wise. Maybe opens up a popover with cursor for the hyperlink.
> But there isn’t a way to edit the hyperlink itself quickly?
Correct. For that you need to use Formatting pallet (also in video). I did initially build it so clicking link would open a pallet with option to follow link or edit link (Pages.app) does that. But in the end felt better to make following link fast and add/edit links slower.
Up/Down could work, but I think it would break text editing movement/consistency more than I would want. For example if you were down arrowing to navigate you document and then randomly hit a link it would be frustrating to see link editor instead of keep moving down.
Sorry, I'm tried web tech in previous apps. This time I wanted build native, and I don't have resources to do it all.
What I would love...
Take a look at Bike's file format, it's just a subset of HTML. Would love to someone to write a web based editor for Bike's file format. Then you could edit Bike files anywhere you want... and also have cool native experience on Mac.
Also note that Bike does read/write .txt and .opml.
Discovered this on HN a few months ago, and it has become indispensable for me. Beautiful software with subtle, nifty innovations in UX.
I love that Jesse is taking a first principles approach with this and not constraining himself with the standard text editor patterns. He's also pretty active on the support forum and very receptive to feedback.
But all my notes are in Notational Velocity (https://notational.net/) at the moment, because the largest source of friction for me is finding note files. In Notational Velocity I never have to open a file dialog; file dialogs on Mac OS are still shockingly slow, and even if they were fast it would take too long to find the file I want. My hands never leave the keyboard; I just type a few characters and Notational Velocity finds the correct note for me.
Do you have any interest in adding an instant search feature, like Notational Velocity? I'd replace it if I could keep the fast search while being able to outline and edit with Bike's fantastic rich text capability.
Right now Bike is very much a text editor, while notational velocity is more database of text files. At some point I hope to add a "workspace" aspect to Bike where you can open a directory of Bike files, but this is a long way off. For now the focus will just be to improve the text editor aspect of Bike.
I really enjoy seeing how you demo the features of Bike. The design is really thought out and you do a great job of communicating how it works in simple terms. (I'm an indie Mac/iOS dev myself, so I'm going to take pointers on how you present your innovations!)
“Those formatting characters are always visible. They make my text look messy.”
This problem was solved in Vi with highlighting and concealing: the formatting characters are hidden and the target formatting is approximated until you move the cursor to edit the formatted bit. I’m sure Emacs has an equivalent.
Are there any examples out there what kind of documents people are writing with this?
What's the right way to write more than one line per row? Return always just adds a new row. For instance, with Workflowy, you can hit Return+shift to add a note to row which can be as long as you want, and only the first line of it will be shown if not focused.
I personally use it for a thinking tool... as opposed to document creating at this point. So I store notes and ideas. Process ideas. I don't author final documents.
Currently there is no way to add multiple lines to a row. I "think" I would rather solve this problem by adding multiple row types (maybe heading vrs notes) and then use some sort of filtering. That's still on todo list.
This is the second time in 8 days that something I submitted first made it to the front page from someone else's repost less than 24 hours later. What am I doing wrong?
https://news.ycombinator.com/item?id=33480410
I think a lot of getting to the front page depends on your random luck of the first 10 people that see the post. If enough of those 10 like your thing, it gets seen by thousands more and may make it to the front page. If none of those 10 do, it's fades away. It's 10 people out of millions that visit HN, so there's a lot of variability. You could post the exact same thing 15 minutes later then the first time and get a totally different "first 10" and that post could perform completely differently.
Yeah, all good points. I guess I'm partially just confused about the dupe detector. E.g., when I post something that someone else has already submitted recently, it just redirects me to the existing post.
Re the luck factor, part of the appeal of Hacker News is there seems to be a lot of work done to minimize the role of luck. Which generally felt like it worked well for me historical, just not recently.
Not a big deal in any event, but if there's something I should be doing differently, I'd like to do it.
Yeah, unfortunately I think a huge amount still comes down to luck.
HN is better then any other platform (which is incredible considering how many engineers work on it) at detecting fraud (e.g. "upvote rings"). But I think a ton still comes down to the first few people that see the post.
Pretty sure :) I submitted this story a month ago when Bike first released this feature and only got 3-4 upvotes. Very pleased and surprised to see it generating interest today.
These are pretty nice ideas fixing existing problems for desktop computers.
How would these work with mobile devices ? It doesn't seam compatible.
Also, these are user interaction suggestions. What about the encoding ? There are plenty limitations with Markdown (the pseudo standard) on this aspect.
For links I just decided to leave out. Seemed blue was enough, and especially since link interaction in Bike only happens through link button. For general formatting I left out because underline formatting seems to be falling out of favor as a standard and when I asked in my forum most users said they didn't need it. Eventually I would like to read/write Markdown from Bike and underline isn't a part of standard Markdown.
Lots of browsers format links with just a thin underline and no color change. I actually prefer that approach since it avoids the visual color clutter. Would be nice to have an option to do that instead of color.
Lots of great ideas, especially the format affinity indication/control. Is that just arrow key or arrow with cmd key? If it is only the arrow key, how do you distinguish user intent to actually move the cursor vs change the affinity?
Eventually I hope to add theme support so that links can look how you want, but that's not a feature that I'll be working on super soon.
The affinity is just treated as a new character position. When caret moves through that position is doesn't "move", but instead draws tail differently. So it's just normal arrow key with one extra state to move through. That extra state only happens at formatting boundaries, so generally the cost isn't too much.
Internally the inline formatting will be marked as tags in a rage, exactly like html. Essentially there is a possible cursor position both inside and outside a formatting tag, but both appear as the same visual location on the screen. This is such a lovely way to indicate the difference.
So with this code:
There are two cursor positions that are visually the same place: Most editors "jump" over one of those positions to hide the implementation detail from users. This idea exposes it with a little tail on the cursor.