Product Plan
Summer 2017
We're going to do a sprint focused around the editor.
There are still a lot of bugs that need to be addressed (Editor Bugs Round 3).
Feature List
Formatting
add markdown style to-do's
add tooltip for inserted link to view link
Publishing
submission screen modal [mockup] & moving tag form into submission modal
Images
remove filepicker modal and make custom dialog/draggable target area to trigger image/file uploads
fix the drag and drop target size (react-dnd)
fix image captions to use placeholders
add image sources to update images, banner images
Editor Plugins
citations: major citations search improvements
code: code syntax highlighting
New Features
redesign user pages (lab note indexes)
search
inline commenting [mockups] [feature issue]
notifications
activity feed
following writers/projects
encryption of posts
privacy options: generate a public link (refactor shared token slugs)
autosaving drafts
comments: use slate
comments: use redux and pub/sub for hot reloading new comments
"actively viewing"
user integrations
Technical Debt / Infrastructure
testing
refactor updates controller
fix heroku review apps
fix circleCI errors (missing react, slow builds)
rails/webpack
In my mind, there are two things we can be doing when working on this project: 1) improve the current UX with polish/bugfixes/edgecase fixes or 2) introduce new features that leverage the editor.
It's the difference between doing one thing exceptionally well, versus adding features that make the tool more powerful, and we should aim to deliver on both of these goals.
How we've worked on this so far is that Jeff does most of the early hard work with the implementation, and then Denny comes in to do polish and the hard detailed UI work. I don't know if this is the most effective method, if it helps us deliver the final 10% faster, or if it's the best possible code quality.
Right now, I feel like our editor code is not that well organized; the SlateEditor.js.jsx is getting big and gnarly, modules are starting to get unseparated and muddled (e.g. /helpers and /helper-components), and we don't have any sort of test protection or sane testing environment established.
In terms of design, most of the things on this list don't require design work, so we could prioritize those items when deciding what to tackle first.
Prioritization
Here is a rough sample for how we could work on this in the next three weeks.
For major features of inline commenting and notifications - I believe we could finish the feature spec's in 1 week for each, and then after that it will require another 1 week where Denny will work on polish alone, because it doesn't require the full team working on polish full-time. So the important part of this forecast is scheduling the bulk work.
0 comments