Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rich Notification Feed Cards #15

Open
tiller-tolbus opened this issue Mar 19, 2024 · 2 comments
Open

Rich Notification Feed Cards #15

tiller-tolbus opened this issue Mar 19, 2024 · 2 comments
Assignees

Comments

@tiller-tolbus
Copy link

There exist three broad categories of "feed card" data structures that apply to capabilities we would like to give publishers to %feed, corresponding to at least three different types of entry:

  • Microblog: Small, atomic pieces of content. Primarily focusing on some combination of text, media, and rich links, with some possibility of a reference to another feed entry. We expect these to primarily be authored within the feed app.
  • Rich Notification: A non-invasive notification of a happening within another application. Contains some constrained ability for an application to "brand" the card. Can be clicked-through into a native Urbit application, carrying some context along the way.
  • Embedded Application: An actionable interface to another application as a resizable "widget" inside the feed.

The "Embedded Application" case, while novel and worth pursuing, is also the most laden with design challenges. Many low-hanging third party use-cases of feed cards fall into the "Rich Notification" category, including "discovery" for many kinds of content that are normally difficult to stumble upon, including:

  • Applications
  • Groups
  • Turfs
  • Betting Markets
  • Macroblogs
  • Shared Files

These types of discovery use-cases do not need a native UI standard to implement, but must provide third-party developers with more graphic flexibility than the basic "microblog" use-case, which are assumed to have a generic theme so that users can submit content with minimal friction. A "Rich Notification" type could look like this:

::  not a spec. just an example
+$  place
  $:
    icon=pith  ::  reference to an embedded image according to content naming standard
    event=@t  ::  what happened? ex. "~hanfel-dovned shared a Group"
    author=(unit @t)  ::  who originally authored the content. ex. ~hanfel-dovned
    title=(unit @t)  ::  title of the thing being shared, ex. "Trent's Group"
    description=(unit @t)  ::  description of the thing being shared, ex. "Place to chat about UI languages"
    action=(unit @t)  ::  what the user clicks through to by clicking. ex. "Join Group".
    ::  note: "clicking through" does not perform a command, but rather goes to the third party application in some context.
    click=(unit pith)  ::  hint to client on where to take the user on-click
    color=(unit @ux)  ::  background color for feed card; if null, white/black depending on system theme
  ==

Implementing this style of feed card would not require a novel native UI system and still allow third party applications to both use the global feed to make their content more discoverable by more-casual users, and allow them to express their visual style of their brands with custom icons and colors. Rather than showcasing unique capabilities of Urbit, this type of feed entry aims to solve a crucial gap in the Urbit UX experience around discoverability.

@hanfel-dovned
Copy link
Collaborator

I think this is the way to do it yeah. Rich notifications cover the 90% of cases that we can realistically cover right now, and covering the other 10% with bespoke entry types isn't too hard and gets us the rest of the way there.

@hanfel-dovned hanfel-dovned self-assigned this Apr 2, 2024
@hanfel-dovned
Copy link
Collaborator

I've made good progress on this; just need to think harder about what specific fields to have here and how to render them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants