skalman / notes Goto Github PK

It should be possible to search for section and page names and content. The search should be prioritized as follows:

• Page names in the current section
• Section names
• Page content on the current page
• Page names in other sections
• Page content on other pages in the current section
• Page content in other sections

Additionally, it should be possible to only search for section and page names.

To begin with, search will be case and whitespace insensitive. Further options can be added later on.

Instead of askiing the user to confirm their intention to delete a section or a page, a popup allowing the user to undo the deletion should be shown.

Moving content boxes within a large area doesn't work on a small screen. Neither does displaying sections as horizontal tabs.

One solution for mobile browsers would be to make content boxes like a list of 'cards' (similar to Trello).

Investigate design alternatives, and whether it would be possible to fluidly transition between the mobile and desktop designs.

The desktop design will also have to support touch screens, which means that bigger click and drag areas are needed.

Implement localization of the user interface. Whatever system is chosen, it should:

• Have logic implemented in JS, so that e.g. grammatical number can be decided in the client ("1 page" or "2 pages");
• Support different plural rules for different languages;
• Support user gender as needed;
• Support RTL languages;
• Support fallbacks per language;
• Be an as small implementation as possible;
• Be a mature implementation; and
• Be open source, compatible with the MPL 2.0 license

Investigate whether L20n fulfills these requirements.

Step 1

Basic functionality: Undo and redo within a page, instead of the default browser functions to undo and redo within a contenteditable, i.e. within a content box.

We will need good heuristics for thresholds that decide whether something is a undo-able. Here are some examples:

• User stops typing for 10 seconds
• User edits another content box
• User moved a content box (note: the individual steaps should not be undo-able)
• User presses an arrow key, page up or page down

Step 2

Support undo and redo for section and page actions, e.g. create/delete page/section, rename section.

This is probably tricky to integrate in an intuitive way with undoing within a page. Investigate how OneNote solves this.

The need for "step 2" will partly be alleviated if #8 is implemented.

The goal should be that both the navigation and the page area can be replaced with another implementation, without changing any surrounding code.

How modular the HTML should be remains an open question.

Investigate whether Knockout components, or standard Knockout view models are better suited.

The current data format is suitable for this purpose. Care should be taken so that the download and upload format version is handled in a reasonable way.

<hostname>.notebook would work as the default download filename.

Subpages don't have to be implemented as a hierarchy. Instead they can probably be implemented by adding an 'indent' property to each page.

It should be possible to visually hide subpages. Whether a page has its subpages hidden should be saved in the permanent storage.

Add tests that ensure that there are no bad regressions in functionality.
To start with, we'll test the very basics: Creating and changing sections, pages and content boxes.

Investigate whether Selenium is suitable, and if so, which language binding to use. My guess is that either Python, or NodeJS/Python via remote control would be easiest to use.

Currently, everything is sent to the server when a change is made. And if you change something in one page while keeping another tab open will cause an edit conflict.

1. Split the notebook content into multiple database tables, with revision information on each item (section, page or content box).
2. Figure out a way to prevent two instances from creating an item with the same ID.
3. Only send changed items, not the whole notebook.
4. Frequently get information about new items.

It should be possible to carry out all actions without using a mouse. In addition, all common actions should have quick and logical keyboard shortcuts.

Here's one idea for navigating sections and pages:

• Esc - switches context between editing content boxes within a page, and the other stuff (so far just navigation)
• When the "other stuff" is focused, Left and Right changes the current section; Up and Down changes the current page.
• When the "other stuff" is focused, Shift+Left and Shift+Right moves the focused section; Shift+Up and Shift+Down moves the focused page.

It should be possible to copy, cut and paste...

• Content boxes
  • Into the same page or other pages (ID:s should be regenerated unless it can be guaranteed that there isn't a duplicate ID)
  • Into any contenteditable on the web (with reasonable HTML)
  • Into Word and OneNote (if sufficiently easy)
• A page
  • Into the same section, with a different name (e.g. with " - Copy" added to the title if copied)
  • Into another section
  • Into any contenteditable
  • Into Word and OneNote (probably just as content, not as a page)
• A section
  • With a different name if copied
  • Into any contenteditable
  • Into Word and OneNote (probably just as content, not as a section)

Initially, the following should be supported:

• Inline elements: b, i, u, s
• Block-level elements: h1-h4, ol, ul, li (also nested)
• Styling: text and background color

Ideally, we would use a light-weight library for this, that:

• Integrates well with Knockout
• Will allow for at least the following future features:
  • Custom objects that render different HTML than what is saved:
    • Tags for list items saved as an HTML class="", but rendered as a <span> (which may be clickable).
    • Highlighted text (within a <span class="highlight">) may be saved as an HTML class on the parent element.
    • Calculated objects, e.g. based on the current date (TODO items that have an associated deadline will be displayed differently depending on whether the due date is in the future or in the past).
  • Custom link and image handlling
  • History API (it must be possible to undo/redo programmatically)
  • Copying and pasting custom objects

Investigate whether (a part of) CKEditor fulfills these requirements.

Add unit tests for the models in js/notebook.model.js:

• Notebook
  • Migration
  • Automatic IDs
  • The ID generator
• Section
  • Automatic colorization
• Page
  • Page name from the title content box
• Content boxes

Considerations:

• Does it have to work in the browser?
  • Arguments for Node only:
    • Building will be quicker
    • Browsers will anyway be tested in the UI tests
  • Arguments for tests in a browser:
    • It will use the environment in which the code ultimately runs

Investigate QUnit, Mocha and other unit test frameworks.