Working Topsoil Wiki
What (summary)
This task delivers a basic wiki focusing only on Topsoil's WYSIWIG and revision history capabilities.
Why this is important
Now is an especially good time to make our first step toward production Topsoil technology. We're at the beginning of a funding cycle and we're in a new building so we are ready to start working in fundamentally different ways.
A company goal is to grow a top 10 website. We're never going to get to be that website if we're built on someone else's technology. This is the first production component that will grow AboutUs to top 10 status. Accordingly, it's very limited in functionality but will be developed with production standards.
It serves as the top-to-bottom seed for Topsoil. Is close to ready to receive the Admin Wiki migration.
DoneDone
-
Written in pure Ruby on the backend -
This is not a spike, so it is to be assumed that all pieces are unit tested and the framework is functionally tested ... this is standard of care for all future Ruby projects -
Basic login functionality (create account/login) -
Users can edit/save pages using basic WYSIWYG functionality (bold, italics, underline, bullets and numbered lists) -
Basic revision functionality (views previous revisions,rollback) -
Working EasyLinking (internal links) - Assess what it takes to migrate the Admin wiki over to Topsoil
-
All javascript functionality manually tested in Firefox - Will have completed one walk-in cold usability test with two of our content and community members.
Discussion
- I am concerned that the front end issues of WYSIWYG and the backend issues of revisions and rollbacks are in the same card. I feel that splitting these concerns would allow at least half of it to get to DoneDone Jason Parmer 16:37, 30 August 2007 (PDT)
- Jason, the project is not notable unless all of these pieces are delivered. Splitting it into two non-notable projects doesn't feel good to me. Brandon
Usability Test Comments
- Mark likes discoverability of the magic ... so when you click on something, the formatting syntax is revealed
- Julia likes buttons for most things (for refactoring) AND speedy shortcuts that don't require a mouse (wikitext) for when typing
- Everyone likes it simple and clean
- Pretty is good
- WYSIWYM is great (even Mark likes it)
- for the slow ones among us, can someone please say what WYSIWYM means?
- Julia want's good tabular formatting
- Calendar that allows wikilinks would be hot!
- Simple spreadsheet (with math)
- Vinh points out that a timeline would be great for recent changes (perhaps more than our current list view)
- Suggesting internal links that might go good in this page
- When you creat a link, ask if you want all the other instances of the word in the page to be links
- Highlight and click a button to turn a word into a link
- Great pluralization and other word form support
- Immediate feedback on red and blue links
- Headers, three levels that you can pull down like in a word processor
- Dual input mode (buttons and magic character sequences)
- Move the edit focus into the edit window when you click edit
- Get the caret into the right place (where you click) when you click on the edit window
- Fix the linking so that it actually works
- Put edit back at the top left and make it visually huge
- Cursor jumps to the wrong place
- Want external linking
- Wants sections using ===
- Wants external links using [
- CamelCase links (are you sure? really really sure?)