-
Notifications
You must be signed in to change notification settings - Fork 4
User Stories
User stories organised by subject.
Stories relating to basic administrative tasks associated with the website.
There should be a link on every public facing page that allows users to either sign up or log in. this should be especially so on the homepage. In the first instance I suggest we piggy-back on Django's built in user and group management (see: https://docs.djangoproject.com/en/dev/topics/auth/) with perhaps the addition of something like django-social-auth to allow users to link their presence on social networks with their checklisthq.com account (see: https://github.com/omab/django-social-auth)
If / when a user is logged in, there should be an obvious means to changing their settings. I suggest we piggy-back on Django's built in user management (see above).
There should be an admin area in the application that allows super-users to administer the site (add users, change data, delete things). We should use Django's built in admin capabilities (see: https://docs.djangoproject.com/en/1.4/ref/contrib/admin/) but change the default path from /admin to something less obvious.
Stories relating to the life-cycle of a checklist from creation to deletion.
Every checklist should have at least the following attributes:
- A title (text)
- An owner (FK to a user)
- Content (the text of the checklist expressed as checklistDSL)
- Tags (perhaps we can piggy-back on some of the options described here: http://davidfischer.name/2010/09/django-taggit-vs-django-tagging/)
- Created timestamp.
- Type of checklist ie. whether or not different sections need to be completed sequentially or Non-sequentially.
Given that we want checklists to be versioned I suggest the checklist table contain one row for each version of a checklist with a unique id for the checklist (a uuid4) and a unique constraint on the uuid and head flag (indicating what row is currently the latest version). To this end, the checklist table probably needs the following fields:
- UUID (universally unique ID) that tracks the identity of the checklist across users / revisions.
- A unique SHA1 value for each version derived from the content, timestamp and other unique fields described above.
- DSL_Version - if we ever enhance or change the DSL we need to know which version of the interpreter to use with a specific checklist.
- Parents - a list of sha1 values indicating the parent revisions contributing to the current revision.
- Commit message - a la VCS systems.
It should be possible to see recent activity associated with your checklists. This could also be exposed as an RSS/ATOM feed (see: https://docs.djangoproject.com/en/1.4/ref/contrib/syndication/). Activities to log include:
- Branching
- Merging
- Edits
- Comments
There should be an obvious way to create a new checklist and fill in the required details (as described above). In addition, it should be possible to clone existing checklists from other users and have the details filled in automatically.
It should be possible to edit the content and tags of a checklist. There should be an obvious preview button so we don't hit the database with unfinished / incomplete changes. There should also be an opportunity for the person making the edits to leave a commit message describing what they changed.
The less technically inclined might be scared by the text based input. A switch should be present to give an alternative graphical user interface to create/ edit checklists. Ideally this should not require a page reload.
It should be possible to add comments to a specific version of a checklist. Django has a commenting library built in (see: https://docs.djangoproject.com/en/1.4/ref/contrib/comments/) but I'm not sure how good it is.
It should be possible to compare two versions of the same checklist (as identified by it's UUID). See http://docs.python.org/library/difflib.html#difflib.HtmlDiff (part of the Python standard library) and the discussion here: http://stackoverflow.com/questions/1576459/generate-pretty-diff-html-in-python
There should be a way to merge two different versions of the same checklist (identified by the UUID). If there are conflicts the merging user should be given the opportunity to make modifications before submitting the final version.
Deleting a checklist must not remove all other child versions. Rows in the checklist table should be marked with a deleted flag and not actually deleted from the database (ergo this table is likely to grow a lot).
Stories relating to how a checklist is used by medical practitioners "in the wild".
Checklists can be exported to standalone platforms that can track it's own runs of the checklist. This is to enable use within closed environments to preserve patient confidentiality and to overcome information governance issues. Metadata should be present within this file to enable version tracking.
An ability to create an formatted version of the checklist to be used on paper. This should have certain pre-defined templates and font size can and layout can be automatically adjusted.