[HN Gopher] Bike: Innovative Rich Text Editing
___________________________________________________________________
Bike: Innovative Rich Text Editing
Author : goranmoomin
Score : 466 points
Date : 2022-11-06 04:52 UTC (18 hours ago)
(HTM) web link (www.hogbaysoftware.com)
(TXT) w3m dump (www.hogbaysoftware.com)
| nbzso wrote:
| Affinity cursor and formatting tooltips are cool. Sadly, only for
| macOS.
|
| I am a long time Apple user, but knowing Apple's direction,
| cannot invest in software made only for macOS.
|
| Obsidian gives me everything I need, and mostly a multiplatform
| confidence.
| practal wrote:
| 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.
| canadiantim wrote:
| Is there any hope of turning this editor into a web-embeddable
| rich test editor like eg tiptap? Would love that and would gladly
| pay for it.
| jessegrosjean wrote:
| 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.
| IshKebab wrote:
| 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!
| amjd wrote:
| 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.
| nudpiedo wrote:
| I like it, specially the contextual format popup, it is sort like
| emacs made visual (for text format).
|
| Being a meta-shortcut I guess the more complex/options it gets,
| the worst.
| iot_devs wrote:
| We really need Rich Text Editing on the web.
|
| Few years ago, I was writing a tiny note taking app, and the only
| viable alternative was Trix.
| jasonjmcghee wrote:
| There are many open source Rich Text editors.
|
| The most popular is Quill, and then there are block style like
| EditorJS, and those meant to be very extensible like Lexical.
|
| And many more- try searching for "Quill alternatives"
| donatj wrote:
| I was a little sad when I figured out this was part of an app and
| not a rich text editor I could use in my projects.
| geniium wrote:
| Simple and clean, I like it.
| cush wrote:
| I want these features on every text caret everywhere. Love the
| typing affinity tail!
| account-5 wrote:
| Is there a Windows / Linux alternative to this. I was excited to
| be reading about this prior to realising it was Mac only.
| criddell wrote:
| Other than games on Windows, it seems like the Mac is the only
| desktop operating system with anything interesting happening on
| it.
|
| Workflowy is what I use. It's cross platform, but a lot
| clunkier than this.
| d4rkp4ttern wrote:
| Any plans to support Math(Jax) or other latex-like math notation
| ?
| jessegrosjean wrote:
| Unlikely in the near term. I feel like there are many other
| features that I need to do first. Longer term maybe?
| mdp2021 wrote:
| > _Those formatting characters are always visible_
|
| My solution, when I coded my own word processor, was to use a
| single, invisible control character, 'P' 1.
|
| So, for example, bold would be enclosed by 'Pb' and 'PB', and a
| first-level heading would be a line starting with 'P1'.
|
| 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.
|
| 1(part of the extended character set - 'P' is easily accessible
| on some systems as [AltGr]+[R])
| xigoi wrote:
| How is that different from HTML tags?
| mdp2021 wrote:
| > _How is that different_
|
| 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 ht _M_ l, 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.
| emptyparadise wrote:
| I'm surprised that no other text editor has these text caret
| features already.
| laserbeam wrote:
| 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...
| jessegrosjean wrote:
| 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.
| emptyparadise wrote:
| 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.
| tobr wrote:
| 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".)
| jessegrosjean wrote:
| 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.
| morsch wrote:
| Having it start with B I was pretty much a given, since that's
| how it's always been.
|
| https://www.versionmuseum.com/history-of/microsoft-word
| DecoPerson wrote:
| I was expecting them to say "..as easy as riding a bike."
| rane wrote:
| 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.
| jessegrosjean wrote:
| 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.
| fuzzygroup wrote:
| I'm a very, very happy HogBay customer. Two comments: the product
| is high quality and the support is outstanding. Recommended.
| cycomanic wrote:
| 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.
| matthberg wrote:
| 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.
| jessegrosjean wrote:
| I'd like to see what emacs/org mode is doing ... is there a
| link to documentation, of demo video somewhere?
| mdmglr wrote:
| 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.
| keizo wrote:
| The caret tail is rad
| leephillips wrote:
| "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.
| mistercow wrote:
| 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.
| jessegrosjean wrote:
| 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.
| kybernetyk wrote:
| Respect. This must have been a pain to implement. (I still have
| PTSD from writing a text editor for macOS).
| pandatigox wrote:
| Hello! I keep asking this, but do you have any good resources
| for doing that? For example, any repos you would recommend
| studying?
|
| Thanks!
| jessegrosjean wrote:
| I've spent a lot of time reading through these codebases and
| found that reading very useful.
|
| - https://codemirror.net - https://prosemirror.net -
| https://xi-editor.io
| jessegrosjean wrote:
| 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.
| schipplock wrote:
| 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.
| a3w wrote:
| 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.
| mshockwave wrote:
| This is a neat solution! Though I wonder if this can carry over
| to terminal environments
| samwillis wrote:
| 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.
| jamesfisher wrote:
| 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.
| felixfbecker wrote:
| 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
| samwillis wrote:
| 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.
| panzerboiler wrote:
| > It is possible via JS to place the cursor in that
| position...
|
| How? No matter what I try, the insertion point is always
| before the bold element, and not inside it.
| runarberg wrote:
| 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.
| jitl wrote:
| 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...
| jitl wrote:
| 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.
|
| [sandbox]: https://codesandbox.io/s/gracious-dew-
| rx3xhz?file=/index.htm...
|
| 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.)
| panzerboiler wrote:
| 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...
| jitl wrote:
| 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.
|
| Why not use ProseMirror?
| panzerboiler wrote:
| 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.
| lewisjoe wrote:
| 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?
| jitl wrote:
| 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.
| stabbles wrote:
| 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.
| jessegrosjean wrote:
| 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.
| samwillis wrote:
| 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.
| oneeyedpigeon wrote:
| I'm hoping these modern editors you refer to at least
| replace those <span...> atrocities with the correct
| elements on save.
| samwillis wrote:
| They do, they separate the internal representation of the
| editor state from the saved html.
| munch117 wrote:
| Yeah, looks really nice.
|
| The innovation is the visual indicator, the cursor tail. The
| rest is how WordPerfect worked 30 years ago.
|
| It is horrifying to think how much the Microsoft Word approach
| has hobbled rich text editing for all those years, and
| continues to do so.
| ComodoHacker wrote:
| 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.
| munch117 wrote:
| 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.
| MForster wrote:
| What if there are more than three cursor locations? Like a bold
| link?
| jessegrosjean wrote:
| 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.
| c-smile wrote:
| My Sciter [https://sciter.com] uses that since 2012 :
| https://terrainformatica.com/2012/11/04/caret-positions-in-h...
|
| The feature there is named "directional caret"...
| jessegrosjean wrote:
| Nice work on Sciter.
|
| 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.
| jessegrosjean wrote:
| 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?
| alsetmusic wrote:
| 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.
| jessegrosjean wrote:
| > 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!
| alsetmusic wrote:
| 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).
|
| Good luck conquering this obstacle!
| kstrauser wrote:
| 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.
| recuter wrote:
| Couple weeks ago the guy who implemented autocomplete on iOS
| went on a bit of a rant.
|
| Doesn't translate directly to macOS but useful reading:
| https://twitter.com/kocienda/status/1565341723860971520
|
| And just in case you or somebody isn't familiar, read this
| classic: https://norvig.com/spell-correct.html
|
| I suggest to try and keep it simple.
| idle_zealot wrote:
| > 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.
| jessegrosjean wrote:
| 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
| zerr wrote:
| Since this is HN... :) would be nice if you share how is your
| business going on? Are you able to fully concentrate on your
| apps? Thanks!
| jessegrosjean wrote:
| Yes... kinda...
|
| 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.
| heresie-dabord wrote:
| > I know Mac apps, I do know much else.
|
| Possible autocomplete-related grammar error? ^_^
|
| 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.
|
| The editor Geany calls them _snippets_.
| jessegrosjean wrote:
| 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.
| chime wrote:
| 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!
| jessegrosjean wrote:
| 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.
| Ptchd wrote:
| In Firefox, I enable the cursor mode to solve the link problem...
| I can click anywhere and the select the text using the keyboard.
| maxerickson wrote:
| 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.
| jessegrosjean wrote:
| 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?
| maxerickson wrote:
| 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.
| airbreather wrote:
| How about we have an informal rule that if is Mac only, or Win10
| only, etc that it says so in the title?
| Narishma wrote:
| Or Linux only for that matter.
| dev_tty01 wrote:
| Well, historically there is a lot of software discussed that is
| Linux or Win only and nobody bothered to mention that there was
| no Mac version...
|
| As a long time Mac user, I think a little movement in the other
| direction is only fair. :-)
| voidz wrote:
| Fantastic innovations. But where's the underline? :)
| jessegrosjean wrote:
| For links or for just general formatting?
|
| 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.
| dev_tty01 wrote:
| 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?
| jessegrosjean wrote:
| 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.
| codethief wrote:
| This looks really nice. If only it weren't Mac-only. :(
| chubs wrote:
| So many great ideas here. Brilliant UX! Congrats :)
| fatboy wrote:
| 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.
| chmike wrote:
| 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.
| padjo wrote:
| The affinity cursor is a really smart solution to such an old and
| common problem. Bravo! I hope more editors adopt it as a standard
| pattern.
| wslh wrote:
| 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.
|
| [1] https://en.wikipedia.org/wiki/Palm_(PDA)
|
| [2] https://en.wikipedia.org/wiki/Swiki
|
| [3] https://en.wikipedia.org/wiki/IPhone_(1st_generation)
|
| [4] https://news.ycombinator.com/user?id=tptacek
|
| [5] https://news.ycombinator.com/item?id=27535683
| sgallant wrote:
| Happy to see this here! I'm a long time fan of Jesse's work [1]
| and love seeing independent software developers ship their own
| products.
|
| 1. https://www.hogbaysoftware.com/about/
| jessegrosjean wrote:
| Thanks :)
| caseyf wrote:
| So nice. I use Notion daily at work and these ideas solve so many
| annoyances that repeat over and over
| daretorant wrote:
| 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.
| elygre wrote:
| How does the affinity cursor work when there are multiple formats
| applied?
|
| For example, "<b><i>text" has three insertion points shown with
| the pipe character: "|<b>|<i>|text"
| laserbeam wrote:
| 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.
| oneeyedpigeon wrote:
| 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.
| samwillis wrote:
| 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.
|
| I suspect that is how Bike is doing it.
| jessegrosjean wrote:
| This is correct.
| leobg wrote:
| Let's hope Microsoft doesn't read HN. Else you're going to see
| that bundled with Office in no time.
|
| \s
| robenkleene wrote:
| 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
| mritchie712 wrote:
| 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.
| robenkleene wrote:
| 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.
| mritchie712 wrote:
| 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.
| ilaksh wrote:
| Are we sure that there aren't some users involved in a voting
| ring?
| jessegrosjean wrote:
| 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.
| sumitgt wrote:
| Brilliant work! Wish I was a Mac user.
|
| 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.
| jessegrosjean wrote:
| > 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.
| replwoacause wrote:
| So many great ideas, loved the video, keep up the excellent work!
| blakewatson wrote:
| Now that I've used this, I want it everywhere there is rich text.
___________________________________________________________________
(page generated 2022-11-06 23:01 UTC)