You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 standardevent=@t:: what happened? ex. "~hanfel-dovned shared a Group"author=(unit @t) :: who originally authored the content. ex. ~hanfel-dovnedtitle=(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-clickcolor=(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.
The text was updated successfully, but these errors were encountered:
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.
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: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:
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:
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.
The text was updated successfully, but these errors were encountered: