I like this idea, too! I think for an initial release of this feature it would even be
enough to just have `:read` and `:unread` states. That is what most email clients have and
Github notifications have that, too.
···
Am Donnerstag, den 07.03.2019, 14:31 +0000 schrieb James Haydon:
When a user lists items related to a machine it's hard for them to see what has
changed since the last time the used the app.
Gmail shows emails in 3 ways to the user:
- `unopen`/`new`: these are emails that the user has never seen listed
before. The `new` tag disappears after about 5 seconds.
- `unopen`: these are emails that the user has not opened, but that they have
seen listed.
- `open`: emails that the user has already read.
I think it is likely that lists of items which exist in Radicle machines
corresponding to various apps will have similar statuses with respect to a user.
We could make a library with the following functions:
- `(mark-seen! machine-id item-id)`: The user has seen this item in a list.
- `(mark-open! machine-id item-id)`: The user has opened a detailed view of this
item. This implicitly marks the item as seen too.
- `(get-user-item-newness! machine-id item-id)`: Returns one of `:open`,
`:unopen`, `:new`.
The library would use local files to persist which items have been
opened/seen. Apps can choose how they want to use the information provided by
the library (highlighting new items, filtering, etc.).
The `rad-issue` app would call `mark-seen!` when an item is displayed in `rad
issue list`, and `mark-open!` when it is read in detail (e.g. opened
in an editor
for adding a comment).
When a user lists items related to a machine it's hard for them to see what has
changed since the last time the used the app.
Gmail shows emails in 3 ways to the user:
- `unopen`/`new`: these are emails that the user has never seen listed
before. The `new` tag disappears after about 5 seconds.
- `unopen`: these are emails that the user has not opened, but that they have
seen listed.
- `open`: emails that the user has already read.
I think it is likely that lists of items which exist in Radicle machines
corresponding to various apps will have similar statuses with respect to a user.
We could make a library with the following functions:
- `(mark-seen! machine-id item-id)`: The user has seen this item in a list.
- `(mark-open! machine-id item-id)`: The user has opened a detailed view of this
item. This implicitly marks the item as seen too.
- `(get-user-item-newness! machine-id item-id)`: Returns one of `:open`,
`:unopen`, `:new`.
The library would use local files to persist which items have been
opened/seen. Apps can choose how they want to use the information provided by
the library (highlighting new items, filtering, etc.).
The `rad-issue` app would call `mark-seen!` when an item is displayed in `rad
issue list`, and `mark-open!` when it is read in detail (e.g. opened
in an editor
for adding a comment).
I like the idea, I am wondering though how this would work with changes to existing items.
Consider the scenario where a user saw and opened an issue and commented on an item. It would be marked appropriately. Now someone else adds a comment or changes the status. In Gmail this (a reply) would mark the email again as new/unopened. How & when would we reset the seen/unopened state of an item?
···
On Thu, Mar 7, 2019 at 3:31 PM James Haydon james@monadic.xyz wrote:
When a user lists items related to a machine it’s hard for them to see what has
changed since the last time the used the app.
Gmail shows emails in 3 ways to the user:
unopen/new: these are emails that the user has never seen listed
before. The new tag disappears after about 5 seconds.
unopen: these are emails that the user has not opened, but that they have
seen listed.
open: emails that the user has already read.
I think it is likely that lists of items which exist in Radicle machines
corresponding to various apps will have similar statuses with respect to a user.
We could make a library with the following functions:
(mark-seen! machine-id item-id): The user has seen this item in a list.
(mark-open! machine-id item-id): The user has opened a detailed view of this
item. This implicitly marks the item as seen too.
(get-user-item-newness! machine-id item-id): Returns one of :open,
:unopen, :new.
The library would use local files to persist which items have been
opened/seen. Apps can choose how they want to use the information provided by
the library (highlighting new items, filtering, etc.).
The rad-issue app would call mark-seen! when an item is displayed in `rad
issue list, and mark-open!` when it is read in detail (e.g. opened
My thinking on this was that the app can override the result that it
gets from the lib functions, but I see now that this isn't so simple.
We could change the API a bit:
- The `mark-_!` functions also take a timestamp.
- The `get-user-item-newness!` function should return the timestamp it
was marked at.
The app can then see if it has been updated since that timestamp. It
would probably be nicer to use entry indexes instead of timestamps,
but then we would also need daemon endpoints for things like "is this
index before this one".
···
On Thu, Mar 7, 2019 at 2:42 PM Merle Breitkreuz <merle@monadic.xyz> wrote:
I like the idea, I am wondering though how this would work with changes to existing items.
Consider the scenario where a user saw and opened an issue and commented on an item. It would be marked appropriately. Now someone else adds a comment or changes the status. In Gmail this (a reply) would mark the email again as new/unopened. How & when would we reset the seen/unopened state of an item?
On Thu, Mar 7, 2019 at 3:31 PM James Haydon <james@monadic.xyz> wrote:
When a user lists items related to a machine it's hard for them to see what has
changed since the last time the used the app.
Gmail shows emails in 3 ways to the user:
- `unopen`/`new`: these are emails that the user has never seen listed
before. The `new` tag disappears after about 5 seconds.
- `unopen`: these are emails that the user has not opened, but that they have
seen listed.
- `open`: emails that the user has already read.
I think it is likely that lists of items which exist in Radicle machines
corresponding to various apps will have similar statuses with respect to a user.
We could make a library with the following functions:
- `(mark-seen! machine-id item-id)`: The user has seen this item in a list.
- `(mark-open! machine-id item-id)`: The user has opened a detailed view of this
item. This implicitly marks the item as seen too.
- `(get-user-item-newness! machine-id item-id)`: Returns one of `:open`,
`:unopen`, `:new`.
The library would use local files to persist which items have been
opened/seen. Apps can choose how they want to use the information provided by
the library (highlighting new items, filtering, etc.).
The `rad-issue` app would call `mark-seen!` when an item is displayed in `rad
issue list`, and `mark-open!` when it is read in detail (e.g. opened
in an editor
for adding a comment).