https://github.com/omab/python-social-auth/tree/master/examples/flask_me_example

At the moment we need an option to login with facebook/twitter credentials.

There should be a way to mark particular user as admin. CLI script is totally enough for now.
You might use http://pythonhosted.org/Flask-Principal/ if you want.

We should have a easy way to make some views to be accessible by admins only.

We need to move "logged in" logic outside of template so app will have a main page for non-logged users with some inside and only after login other page will be available (on the different url). If logged user is trying to access home page he should be redirected straight to workplace.

We also need to forbid an access to next/skip/etc WS for non-logged users.

Sometimes tags are stored in lowercase, e.g. app.py:

    tags = set(map(unicode.lower, request.form.getlist("tags")))
  ...
    Shreds.objects(...).update_one(
        push__tags=..... tags=list(tags),
    User.objects(.....).update_one(
  ...
        add_to_set__tags=list(tags)

And then, few lines below it's capitalized:

    for tag in tags:
        Tags.objects(pk=tag.capitalize()).update_one(

There's probably some other convention for transferring tags over HTTP and displying on the page.

There should be a consistent convention, e.g. tag db entries have separate:

• some id, either text or just numeric which is used throughout the db and over HTTP
• label, which is only used for display.

Basically we want to each user to work independently so all shreds will be processed with some redundancy (for example 1 shred should be processed at least by two users).

We also want to track progress per user and make sure that user A cannot see results of user B.
Tags suggestions however should be common.

Go away from central column layout.
Hide technical information on the right. Show it only by click or mouse hover.
Put tags input instead of technical information.
Put recognizable text (#21) input under tags input.
Put list of base tags (#25) next to inputs.
Make Instructions link more visible.

So user can quickly get used to existing tags and not introduce duplicate/similar ones.
Clicking those tags should add them to the list

Depends from #14

Amount of processed shreds during current session, amount of all shreds processed by user since creation of the account. Position in global rating.

Allow user to add new tag that consists of substring of existing tag.
Right now if we have base tag “Foobar” it's not possible to create new tag “bar”, because by hitting Enter it'll add Foobar to the list of tags.

On top of #22.

Data scheme/UI etc to be discussed.

Use should be able to skip the shred she is presented. For instance, with the following screenshot one is stumbled:

This is especially true for new user, when the only tag to be assigned to a shred is already typed in, and the only action that is possible is to "Save", but the user hadn't done any change, thus is afraid not to break something. Usually the first time users are lurkers, and would like to browse through shreds, trying to find one that can have her attention.

As long as we don't want users to start working without reading help we should display them a service page with some text + the same help as we have in lightbox and a big button “I got it, ready to work” below the text.

Display 2x copy of the part of the image under the mouse so user can make a closer inspection of the shred.

Documents in the Shreds collection have more fields than the models declare. Also update the code that uses undocumented _get_collection() method of the models to have access to those fields.

See image:

This might a part of the admin UI. What we need is a tool to assist tags analysis.
The first use-case would be answering the queries: show me the clusters having tags X AND/OR Y (ideally any combination of parentheses, conjunctions, disjunctions).

@bv
Set up a framework to run test automation against the application http://dev.unshred.it/

• integrate test automation framework; additional repo to be created
• set CI for running UI tests

Tags model should also have a flag which says if it's base tag (chosen by admin or approved by admin) and category field (so we can group tags by categories like background, text, etc).

Should be stored in Tag model and reuse jquery.hotkeys lib

Related to #25

We need a page where admin will be able to check per user stats. Just for now this page will be accessible to anyone, and when #6 will be landed we will protect an access to that page.

For now page should display very basic stats: amount of processed/skipped items, amount of tags used, avg tag/shred ratio, last login.

No pagination for now.

Bonus: sorting by last login time, some indication of activity (to easily spot champions)

Probably with filtering/sorting, pagination or endless scrolling

Depends from #14

Similar to #7. Also admin only.

Very basic stuff for now: tag name, number of usages, number of shreds tagged with it (so for example if two users used the same tag for shred number 1, first value will be 2, second one will be 1).

Ideally: also examples of shreds tagged with each tag. 5-10 (ruled by setting).

Without any tests the code seems too fragile and dangerous for any major refactoring.

It would be nice to have at least the basic sanity tests that verify all the existing HTTP handlers (GET/POST) work as expected.

Another task would be lower-level unittests which are probably out of scope for current issue.

This is strictly frontend task, we don't need to generate thumbnails etc.

Currently app.py looks like a pile of functions. There's a number of helper functions, which clobber the code.
It would make sense to move most of the functions that are not flask http handlers to more suitable modules. e.g. most of the get_*() functions would make more sense as corresponding model's (e.g. Tag) methods.

Each user who is tagging particular shred should be also able to enter the text from the shred.

Text entered should be stored independently to each user.

Ignore spaces in autocomplete.

And store this information to shred together with tags.

Shortcuts to rotate it quickly, CSS to apply rotation to the shred.

Some reference links:

• http://en.wikipedia.org/wiki/Tf–idf
• http://alias-i.com/lingpipe/docs/api/com/aliasi/spell/TfIdfDistance.html

Modify tags input to disallow adding same tag over and over again

Each time user tags something also track interval between rendering of task and storing of the tags.

Separated mongo collection, should include current time, time difference in seconds or msec, user _id and shred _id.

So we can have a metric to measure time required to process single shred and see how that correlates with UI changes.

Order tags by newest first.
Add an option to move tags from user tags to base tags.
Depends from #14

@dchaplinsky

• should we have a separate endpoint for clearing database?
• should it be all in one endpoint: clear database and run fixtures?

This is useful in a number of scenarios:

1. Consistent links to the specific shreds for e.g. sharing.
2. Would solve most of #24
3. Would provide more user-friendly URLs, e.g. GET/POST /shred/1:23_45

Depends from #22