One benefit of saving the rendered html along with markup in the database is that you can make breaking changes to the parser (like swap it out entirely) without worrying about old posts.
...this needs a publicly accessible sandbox connected to a database that gets flushed daily. I want to play with this, but at the same time, I don't want to add noise to the actual posts, and there's currently no way for me to squirrel my formatting experiments out of sight.
On that note, categories/sections/tags are definitely probably a good idea to add to the roadmap for down the track a bit, along with infinite easily-accessible database storage.
# UI/UX:
I had no idea the textarea was "functionally multiline" (where pressing enter adds a new line). The submit section feels like something's missing; I'm floundering, I don't know what I can and can't do. A help section might, er, help, but my initial reaction was "that's only one line. Is that for the title? Can I only fit a one-line message? ......???!?" - granted I'm tired today :P maybe you could see this as a baseline worst-case-scenario interpretation.
While I'm on the subject of UX, one thing that's bothered me about input UI for ages is the differentiation between "edit" and "presentation". It would be truly awesome if you could somehow get something where the only difference between "view" and "edit" is maybe a faintly-visible border - everything else stays the same. This would also imply a hybrid Markdown/WYSIWYG editor setup; for the WYSIWYG editor I'd recommend... where is it... THIS: http://trix-editor.org/
(My case in point about view/edit differentiation is the fact that I've edited this post about 5 times as I've remembered stuff)
After this ^ point, Readability switched to extraction-as-a-service with API calls and a key and limits and plans and the like.
The heuristics in this code likely don't take the latest design edge cases, and the full gamut of how HTML5 has been interpreted over the past few months, into account. A reasonable amount of work may well be required to get it up to speed. I'm not aware of any such maintenance projects, though.
But this project is Node.js... and that code is JavaScript... and I have to say, maintaining an open variant of Readability (under a different name) would definitely make this project a bit different.
It'd make keeping your current UI really simple: throw the service a URL, it suggests the best paragraph (or maybe a list of paragraphs?) and you pick the best >=1 and hit Publish. I'll admit, that'd be cool.
[+] [-] hayksaakian|10 years ago|reply
[+] [-] danneu|10 years ago|reply
[+] [-] kulakowka|10 years ago|reply
[+] [-] sandGorgon|10 years ago|reply
[+] [-] _RPM|10 years ago|reply
[+] [-] kulakowka|10 years ago|reply
[+] [-] kulakowka|10 years ago|reply
[+] [-] izolate|10 years ago|reply
[+] [-] gamesbrainiac|10 years ago|reply
[+] [-] kulakowka|10 years ago|reply
[+] [-] wodenokoto|10 years ago|reply
[+] [-] specifictso|10 years ago|reply
[+] [-] kulakowka|10 years ago|reply
[+] [-] i336_|10 years ago|reply
# Above and beyond all else...
...this needs a publicly accessible sandbox connected to a database that gets flushed daily. I want to play with this, but at the same time, I don't want to add noise to the actual posts, and there's currently no way for me to squirrel my formatting experiments out of sight.
On that note, categories/sections/tags are definitely probably a good idea to add to the roadmap for down the track a bit, along with infinite easily-accessible database storage.
# UI/UX:
I had no idea the textarea was "functionally multiline" (where pressing enter adds a new line). The submit section feels like something's missing; I'm floundering, I don't know what I can and can't do. A help section might, er, help, but my initial reaction was "that's only one line. Is that for the title? Can I only fit a one-line message? ......???!?" - granted I'm tired today :P maybe you could see this as a baseline worst-case-scenario interpretation.
While I'm on the subject of UX, one thing that's bothered me about input UI for ages is the differentiation between "edit" and "presentation". It would be truly awesome if you could somehow get something where the only difference between "view" and "edit" is maybe a faintly-visible border - everything else stays the same. This would also imply a hybrid Markdown/WYSIWYG editor setup; for the WYSIWYG editor I'd recommend... where is it... THIS: http://trix-editor.org/
(My case in point about view/edit differentiation is the fact that I've edited this post about 5 times as I've remembered stuff)
# Extraction:
A final suggestion: here is the final version of Readability's Javascript extraction engine: https://code.google.com/p/arc90labs-readability/source/brows...
After this ^ point, Readability switched to extraction-as-a-service with API calls and a key and limits and plans and the like.
The heuristics in this code likely don't take the latest design edge cases, and the full gamut of how HTML5 has been interpreted over the past few months, into account. A reasonable amount of work may well be required to get it up to speed. I'm not aware of any such maintenance projects, though.
But this project is Node.js... and that code is JavaScript... and I have to say, maintaining an open variant of Readability (under a different name) would definitely make this project a bit different.
It'd make keeping your current UI really simple: throw the service a URL, it suggests the best paragraph (or maybe a list of paragraphs?) and you pick the best >=1 and hit Publish. I'll admit, that'd be cool.