Basic Features

these are the things that we pretty much *know* any decent sticky architecture is going to need to have no matter what else we decide on:

• in place editing. each sticky note should have a little 'edit' button. clicking it basically turns the sticky into a textarea (but with no borders and the same background color so it doesn't look much different). it would also be nice to have it so double clicking on the sticky body switches to edit mode (but i think we still need the button for discoverability). hitting save uses javascript/Ajax stuff to save the results, get the new rendered structured text and place it back in the body of the sticky. so the user shouldn't have to leave the page or refresh to edit a sticky note.

• colors. there should be a little palette of four or five nice pastel colors that the user can choose from (yellow, pink, light blue, light green, maybe light purple and light orange). i envision the UI for this as a couple little colored squares on the bottom edge of the sticky which, when clicked sets the sticky to that color. changes saved immediately.

• drag + drop initial placing. when a new sticky is created, it should be placed where the mouse cursor is on the mouseup. so if the user just clicks on the 'new sticky' button, it shows up right there. but if they click down and drag over somewhere else on the page and then release, it will appear at that spot. easier for me to demo than to explain.

Onward to the Future

Jonah and I have discussed some of these ideas in depth but it would be good to have them archived in one spot where others can read them and contribute their input.

Fine Grained Annotations

one of the most vexing and promising questions with the stickies is what to stick them to. the demo javascript implementation and EMCC use a model of just attaching stickies directly to a page. it isn't much finer grained than that. we see some of the biggest potential with stickies being used for annotating elements within a page. so it's not just important that there's a sticky on a page, the location of the sticky is important too. the current javascript stuff remembers the pixel location of where the sticky was, but this is quite brittle as a method for doing fine-grain annotation. it depends on the content of the page staying the same between visits as well as the size of the browser window and font sizing. it certainly wouldn't hold up to the page being visually redesigned beyond anything trivial.

we would like it if the user could select a bit of text on the page and attach the sticky to that. attaching stickies to specific locations on images could also be useful; it would have to know which image it was stuck on and the pixel offset from there. attaching stickies to sections of text would allow them to reflow with the text. problems it raises involve how to specify which text to attach it to and what to do if the underlying text changes. in an environment where we control all the content and the backend that serves it, the first problem isn't too bad. we could dynamically wrap a span with an id around the text and attach the sticky to that id. there are some issues with multiple annotations and the potential for overlapping messiness, but they are solvable. if we don't control the backend and can't modify the content, it gets much trickier. just storing the selected phrase with the sticky and having it search for that text and attach itself to it in javascript isn't very robust; eg, if someone selects "the" to attach a sticky to, we'd need more information to know which occurrence of "the" on the page is the one that we want. annotating text that could change (eg, in a wiki) gets even trickier since the selected phrase could potentially move, be changed, or even deleted and we'd need to figure out and build in reasonable behavior for any of those situations.

One approach that we'll probably pursue in the interest of flexibility is to make the issue of sticky placement be handled with a Memento design pattern so the page that it's attached to can dictate the policy for placing the sticky in whatever manner it chooses.

JS Only Implementation

I would like to have a stickies implementation that is done entirely in javascript. all you would have to do to use it would be to include the right javascript and CSS files and maybe create an element in the page with a particular id. the javascript would do everything after that. it would dynamically insert the form for adding a new sticky, etc. everything including sticky content would be saved in cookies. this means that they would be isolated by user; ie, no sharing of annotations or viewing other peoples' stickies. this would be useful as a quick and dirty way to give users basic stickies functionality for a site no matter what backend was being used. the trickiest part of this could be if we want to let users enter structured text; a pure JS implementation would then mean that we'd need a JS STX parser.

i'm also tempted to implement stickies as a Greasemonkey script so people can use stickies on any website at all. then an additional greasemonkey script that lets them browse and search through all the stickies they have would be kind of neat.

• Very cool idea. This might be where Annotea compliance might fit in namely, a way to implement the zannotea spec w/out requiring a browser plugin (well, a special plugin for annotations. Grease monkey doesn't count).

Centralized Sticky Server (a PITA microapp?)

The next step after the pure javascript stickies is to use a centralized server for storing the sticky contents (and things like which elements they're attached to, size, position, color, etc). it could be set up so there's one server that serves the stickies for all applications. each page in an application which can have stickies would have some kind of globally unique id (possibly just the url). upon loading, the javascript would query the server for any stickies on that page and display them.

this is basically the Annotea model. whether or not we implement the annotea spec or just do something like it is up for debate.

Workflow / Permissions Issues

whether inside or outside plone, issues of user permissions and workflow are likely to come up and likely to complicate things. there are a bunch of potential use cases that we might want to be able to allow:

• wiki style. all stickies on a page visible and editable by all users.

• private. totally the opposite of wiki style. only the creator of a sticky can view it or edit it.

• publishable. private but the owner can make a sticky visible or editable for other users

• groups. private but stickies can be marked visible or editable for other users in a particular group (eg, students in the same class, etc.)

and more i'm sure. as we have seen with the IAT, complex permissions policies can be tricky to get right for all the edge cases.

for stickies in plone at least, implementing permissions on stickies shouldn't involve much more than making them fit in with plone's existing workflow mechanism. outside plone, we may have to duplicate a lot of that functionality.

Longterm

SVG stickies. wouldn't that be sweet.

Architecture

screen mockups

TODO

html structure

<pre>

• div.sticky

  • div.stickycontent

    • div.stickyview

      • div.stickyhead

        • div.stickytitle div.stickyclose

        div.stickybody

        • p's

        div.stickyfooter

        • ul.stickycontrols

          • li.editcontrol li.coloryellow li.colorblue ...

          div.resizer

          • img

      div.stickyedit

      • div.stickyhead

        • input.stickytitle div.stickyclose

        div.stickybody

        • textarea

        div.stickyfooter

        • ul.stickycontrols

          • li.savebutton li.coloryellow ...

          div.resizer

          • img

</pre>

switching between view and edit mode toggles visibility on .stickyview and .stickyedit so that one or the other is displayed. maybe seperate out the stickyfooter and have it not inside those; then just tweak some stuff to change the edit button to a save button.

APIs?

Javascript

To make stickies as useful as possible in as wide a variety of applications and settings as possible with as little per-application customization as possible needed (preferably none), extensibility will be key.

The goal of the API basically is to provide a bunch of named hooks or callbacks that will be called at specific times in a sticky's lifecycle, giving the calling page opportunities to override the sticky's default behaviour.

the page should register javascript functions for the hooks after stickies.js is loaded. hooks are registered with <code>registerStickiesHook("hookName",hookFunction)</code>.

the available hooks are:

• <code>loaded</code>

• <code>moved</code>

• <code>resized</code>

• <code>contentChanged</code>

• <code>colorChanged</code>

• <code>rolledUp</code>

• <code>rolledDown</code>

• <code>hidden</code>

• <code>deleted</code>

it should be fairly obvious when each of those would be called. if a particular hook hasn't been registered, there will be some default behavior (probably in line with the "JS Only stickies" use case described above. multiple callbacks can be registered for each hook. they will be called in the order that they are registered. this makes it possible to specify a general application level behavior and then override it or add to it on a per-page basis. there will also be a <code>clearStickiesHook("hookName")</code> function available that will remove all registered callbacks for the specified hook (so you can replace it with your own instead of adding to it).

Serverside

TODO: define the api that the stickies javascript uses to talk to the server for loading and saving of stickies. this will probably be greatly affected by what we decide for the permissions/workflow issues.