We started to using Dynalist for task-based collaboration. It turned out to be the right project management tool for us. So we will invest some effort to adapt it even more to our needs. This topic discusses our plans and progress. Structured as a list of feature proposals.
Content
1. Functional design customizations
2. Notifications for changes in Dynalist
- 2.1. E-mail notifications
- 2.2. Browser push notifications
- 2.3. App-based mobile notifications
- 2.4. Discourse notifications
- 2.5. Matrix notifications
6. Syncing Github issues to Dynalist
8. Replacing Dynalist with open source software
1. Functional design customizations
Status: finished
@anu created a Stylus user agent stylesheet that provides various functional design improvements, including color-coded tags for task status, highlighting tags using the own username, better header formatting etc…
For details, see our Dynalist Manual in section “7. Adapting the Dynalist appearance”.
2. Notifications for changes in Dynalist
Status: in progress
There would be the following types of notifications, each containing a direct link to the concerned task in Dynalist:
-
Task assignment. “You have been assigned a new task by {username} on Dynalist: {name and link}.”
-
Task reassignment. “Your task {name and link} has been transferred to {username}.”
-
Deadline added / changed. “Your task {name and link} has been given a [new] deadline: {date}.”
-
Upcoming deadline. “The deadline {date} for your task {name and link} is coming up in {days}.” Derived from the
!(yyyy-mm-dd)Dynalist dates, and (optionally) a custom tag that tells the system when to start reminding the user of the upcoming deadline. Such as#notify-1wfor “start one week before”. -
@mention. “You have been mentioned by {username} on in Dynalist task {name and link}.”
-
Notifying extra people. By applying a custom
#notify-{username}tag to a task, a project manager etc. can subscribe to notifications about a task as well, such as for an upcoming deadline. But probably easier by adding a second assignee.
Dynalist now provides an API and due to this, creating notifications about changes in Dynalist will be quite simple.
2.1. E-mail notifications
The most basic and most important type of notifications. Best created by a stand-alone software running on a server.
2.2. Browser push notifications
Push notifications are asynchronous messages sent by a server to a browser. The web application in the browser can then decide how to react. For example, it can show desktop notifications – the small popup windows that pop up on top of the screen, outside of the browser window. (They can be enabled in Discourse, for example.)
Technically, push notifications that result in these desktop notifications consist of three parts:
-
HTTP Web Push Protocol. A simple protocol by which a server-side application can send push messages to a client-side web application in a browser. This is standardized as RFC 8030. There are various open source implementations of this protocol that help a server-side software manage and send push notifications; most are contained in the web-push-libs repos, among them a Python library. When dealing with Python, there is a great tutorial showing how to create a complete push notifications server, and another tutorial here.
There is also a Ruby gem, used for example within Discourse.
-
Push API. A standardized JavaScript interface of the browser that allows a web application to interact with the HTTP Web Push Protocol mentioned above. For example, subscribing to and unsubscribing from various types of push notifications.
-
Notifications API. A standardized JavaScript interface of the browser that allows to configure and show desktop notifications.
There are various SaaS services that provide a service to distribute push notifications: Pushy, OneSignal, Pushover, Pushpad, etc.. Often, they include additional features like also delivering notifications by SMS etc… But as we only want “simple” browser based push notifications, these services only create additional costs, dependencies and installation complexity, none of which is good for the small open source application we want to create.
2.3. App-based mobile notifications
In addition to or instead of the browser-based push notifications described above, a mobile app for the sole task of creating notifications for the above Dynalist events will be very helpful. While it is true that browser-based push notifications can be received on mobile devices even if no tab is open, this is confusing behavior and should be rather avoided (for example, it is not immediately clear how to disable these notifications again). Also, Safari based browsers do not support push notifications at all [TODO: source]. A notifications app seems to be a cleaner solution.
The app would be fully open source and operate by downloading and analyzing the Dynalist content belonging to an account, creating events as content updates come in. Surely more
2.4. Discourse notifications
What we really need to avoid the “too many tools” scenario are Discourse reminders and notifications about Dynalist tasks. Because then there’s only one notification system, and also Dynalist will get a notifications feature (which it does not have so far because the integration of Dynalist Pro with Google Calendar supposedly provides notifications about deadlines.
In Discourse, a bot would post comments about Dynalist events to a dedicated topic per project, probably pinned and put into the project’s workspace. It would be named “{projectname} Tasks”, which results in Discourse notifications being shown usefully as “@mention / reply [for] {projectname} Tasks”. All comments posted by the bot would be deducted from parsing automated OMPL backups of the Dynalist document.
2.5. Matrix notifications
Similar to the Discourse notifications described above, it is possible to post equivalent notifications to Matrix chatrooms. It could suit better, as it does not clutter Discourse topics with small chunks of information, and because we use Matrix more for collaboration than Discourse. Also this is quite simple to do, as there the existing implementation of a Matrix bot for Slack integration can be used as a basis. However, a mobile notification app for Dynalist will be much more useful to people outside Edgeryders as well, so rather plan to develop that.
3. Backups
Status: in progress, initial implementation finished
Quite important, as there is no revision history but many collaborators in the task list who could accidentally delete content. So far, Anu is tasked to create a backup every 2-3 days, and we might automate that with a script. But the easiest permanent solution is to have one Dynalist Pro account for the company (8 USD/month), as that includes daily backups to Google Drive – and because Dynalist is just great for us, supporting its development with a paid subscription is in our own interest.
For the (yet to be finished) documentation of our Dynalist backup system, see our Dynalist Manual in section “8. Keeping backups”.
4. Gantt charts
Status: idea
For that, we would introduce custom syntax to express dependencies between tasks, such as #depends {dynalist-task-url} which renders nicely into linked tasks in Dynalist. If necessary, also custom syntax for the typical constraints “earliest start date”, “latest start date”, earliest end date" – the “latest end date” syntax exists: !(yyyy-mm-dd).
Then, a script can generate Gantt charts from OPML exports of Dynalist documents, and keep a linked Discourse topic up to date with them.
5. Task archiving
Status: idea
If desired, asks could be archived on Discourse. For that, a script would remove them from the “Done” sections (after a number of days being there) and add them automatically to a certain Discourse topic. Probably, to the first post of the Discourse topic used to manage Dynalist notifications for a project (see above).
6. Syncing Github issues to Dynalist
Status: idea
To have only one place to look at for tasks, it would be great to sync Github issues of selected software projects to Dynalist tasks in corresponding sections, incl. syncing of issue assignment on Github to task assignment on Dynalist (but not the other way round, Github would still be the authoritative version, and Dynalist the reminder). A special tag or markup to indicate the corresponding Github issue could be used, making the task of the syncing script simpler.
7. Offline usage
Status: idea
To be able to use any offline outliner software, including FreeMind, for offline editing of Dynalist documents. For that, the Dynalist document would be exported to OPML (already possible), converted to a native format (such as for FreeMind), edited offline, converted back to OPML, and then reconciled to the online OPML version based on a diff.
8. Replacing Dynalist with open source software
Status: idea, with roadmap
Not an easy task, but possible. See my blog post at “Open Source Dynalist / Workflowy replacements” for existing open source software that can be used to start from.
9. Embedding Dynalist
Status. idea (probably a bad one; we do not intend to implement it)
9.1. Embedding Dynalist in Discourse
Not sure this is recommendable, but it seems Dynalist can be embedded in an iframe (“If you want to embed Dynalist in an iframe, now the header is hidden for better presentation.” – see). So adding a new Onebox URL scheme for embedding into Discourse is all that’s needed here. People might start to post links to individual Dynalist tasks (in the “zoomed in” mode), allowing to track the progress of these tasks right in Discourse by looking at the embeddings. Also, by embedding different Dynalist search results and tasks, embeddings can focus on tasks of a project, of a user etc…
It is not yet clear if and how we would manage access rights to the dynalist when embedding it into Discourse. Dynalist lists can be made anonymously editable, but that seems not advisable as trolls could delete all the content (and there is no edit history). So probably, sharing the dynalist to e-mail addresses for edit access is better. Still, there could be a view-only mode for which the link would be enough.
9.2. Embedding Dynalist in Matrix
Again as a possibly better alternative than embedding Dynalist in Discourse, we could embed it into Matrix. For that, Riot (our Matrix client application) provides the widgets feature, allowing to embed a Dynalist area right into the chat window. That could make it feel like a complete project management / collaboration cockpit.