This update began with two short messages in our Suggestion box. One person asked for a direct link to the plain text of a note. Another told us that notes set to delete after the first read were being deleted before the person they were meant for ever saw them. Both were right, and both are fixed. Here is everything that changed, and what we learned on the way.
Every note has a raw link
Add /raw to the end of any note's address, or press the new
Raw button on the note:
https://sharenotes.dev/blue-fox-42/rawYou get the note's text and nothing else. That is what you want when the text is going
into something other than a person's eyes: curl in a terminal, a config file a
script downloads, a game or app that imports text from a link.
Notes you wrote in the editor come back as the text you see on the page, with line breaks and indentation kept and formatting left out. Until now, if you had pasted code from a site that colours it, the plain-text link returned all of that colouring as markup instead of the code. It returns the code now. Notes sent through our API come back exactly as they were sent.
The Raw button does not appear on notes that delete after the first read, or on notes locked with a PIN for viewing. Those links are meant for one person in a browser. The details are on the developer page, and the story of building it is in a separate post.
Delete-after-reading notes now work as promised
A reader spotted this one. When you saved a note with delete after first read ticked, ShareNotes opened the note for you straight away, and that counted as its first read. The friend you sent the link to was told it had already been opened.
Now the browser you made the note in never uses it up. You can open it, reload it, or come back to it later, and a notice tells you the first read is still waiting for someone else. The first other person to open the link sees the note, and then it is gone for everyone, including you.
Two things stay the same. Chat apps that fetch a link to build a preview still do not count as the reader, as we explained before. And we fixed a second problem in the same area: opening one of these notes could show "No note here" even to its first reader.
Saving works in more browsers
We check each new note for signs of spam. That check was too strict. It refused some people outright, more often on Firefox or in the browser built into another app, and told them their "score" was too low, which is not something anyone can fix.
Now a save the check is unsure about goes through, under a tighter limit on how many notes can be made from one connection in an hour. Someone saving a note or two will not notice. A flood of spam stops quickly.
Better on phones and on shaky connections
- Phones. On small screens the page no longer scrolls sideways, and the header, the note buttons and the share dialog all fit.
- Lost connections. If you go offline or ShareNotes is briefly unreachable, the note says "not saved yet" instead of quietly dropping your change, keeps your text, and saves it when you are back. If someone else changed the note in the meantime, nothing is overwritten: you choose which version to keep.
- Open tabs. A tab you left open moves to the newest version of ShareNotes by itself, never while you have unsaved text.
Smaller fixes
- Code keeps its lines. Code typed line by line could show as one long line when the note was opened again, and Copy text and Download gave you that one line too. Each line stays on its own line now.
- Checklists tick from the box. Clicking the words of a checklist item used to tick it, which got in the way of editing. Now only the box does.
- A clear message when a note is too big. Notes can be up to 10 MB. A note over that could not be saved, and the message did not say why. Now it does. Pasted images are usually what takes up the space.
What we learned
Test the way a person uses it. Our tests for delete-after-reading notes opened each note in a fresh browser, which is how the friend opens it. They never did what the person making the note does: save it, and land on it. The bug lived exactly in that gap. Our browser tests now make the note through the homepage, the same way you do, and then check that the friend still gets it.
A spam check can stop the wrong people. It is easy to measure how much a filter blocks, and harder to know who it blocked. Turning people away with a message they cannot act on is the worst outcome, so we chose a limit over a wall, and we now count every save the check was unsure about so we can tell if spam ever rises.
"Just the text" is harder than it sounds. A rich editor stores formatting, and turning that back into plain text means deciding where every line breaks. We wrote those rules once and now use them in two places: for the raw link, and for the code view in the note itself. That is how the one-long-line bug turned up.
Your messages get read. Two of the biggest fixes in this update started as a sentence or two in the Suggestion box, at the top of every page. If something gets in your way, tell us there.
What is next
Pictures. A pasted photo can be several megabytes, which makes a note slow to save and quick to reach the size limit. Next, ShareNotes will shrink images when you paste them, so a note with a few photos stays small and fast.