{"action":"opened","issue":{"url":"https://api.github.com/repos/cantino/huginn/issues/1583","repository_url":"https://api.github.com/repos/cantino/huginn","labels_url":"https://api.github.com/repos/cantino/huginn/issues/1583/labels{/name}","comments_url":"https://api.github.com/repos/cantino/huginn/issues/1583/comments","events_url":"https://api.github.com/repos/cantino/huginn/issues/1583/events","html_url":"https://github.com/cantino/huginn/issues/1583","id":165490875,"number":1583,"title":"Google Now-like \"Cards\" agent","user":{"login":"strugee","id":911174,"avatar_url":"https://avatars.githubusercontent.com/u/911174?v=3","gravatar_id":"","url":"https://api.github.com/users/strugee","html_url":"https://github.com/strugee","followers_url":"https://api.github.com/users/strugee/followers","following_url":"https://api.github.com/users/strugee/following{/other_user}","gists_url":"https://api.github.com/users/strugee/gists{/gist_id}","starred_url":"https://api.github.com/users/strugee/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/strugee/subscriptions","organizations_url":"https://api.github.com/users/strugee/orgs","repos_url":"https://api.github.com/users/strugee/repos","events_url":"https://api.github.com/users/strugee/events{/privacy}","received_events_url":"https://api.github.com/users/strugee/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-07-14T07:03:04Z","updated_at":"2016-07-14T07:03:04Z","closed_at":null,"body":"I've been thinking for a while about a Huginn-powered Google Now-like Android app called [Muninn][1].\r\n\r\nHere's what I'm thinking: Huginn will expose a new agent, \"CardAgent\" (improvements on the name welcome). This agent will receive events that generate \"cards\" in the app. Here are some things to consider:\r\n\r\n1. Some cards will be ephemeral, i.e. relevant only for a short amount of time, while some will be (semi-)permanent, i.e. consistently relevant but changing. (As an example, think about Google Now's \"upcoming appointments\" vs. its \"commute time\" cards - the former is relevant only when you actually have upcoming appointments, whereas the latter is relevant pretty much every day.)\r\n2. Cards will need to have a mechanism for updates. For example, a value (commute time in the example above) may need to be updated, or the card may need to be destroyed entirely.\r\n3. Cards should have a set of visual elements they can use (listed below)\r\n4. The user should be able to specify that some cards are high priority\r\n5. Cards should be able to be grouped into categories\r\n6. CardAgents should be able to generate more than one card\r\n7. Cards should have automatic expiration\r\n\r\nVisual elements cards should be able to use:\r\n\r\n* A primary icon\r\n* A progress bar\r\n* Time indication, for e.g. upcoming appointments (should this have multiple styles?)\r\n* Lists, both horizontal and vertical - these should be able to contain all visual elements that would make sense in them\r\n* Color\r\n\r\nHere's a rough proposal for what an advanced CardAgent configuration might look like - this particular one receives incoming events about news articles and creates a card for each one:\r\n\r\n```json\r\n{\r\n    \"priority\": \"high\",\r\n    \"event_action\": \"new_card\",\r\n    \"autoexpire\": \"12h\",\r\n    \"layout\": [\r\n        {\r\n            \"type\": \"primary_heading\",\r\n            \"value\": \"{{title}}\"\r\n        },\r\n        {\r\n            \"type\": \"text\",\r\n            \"value\": \"{{body}}\"\r\n        }\r\n    ]\r\n}\r\n```\r\n\r\nThe intent here is that for each incoming event, a new card is created with a large, primary heading of the article's title, and some smaller text from the article's body. The `autoexpire` option causes the card to disappear from the app 12 hours after its creation, and `event_action` causes a new card to be created for each event. It might also have the value `update_card`, which would replace a previously-created card with the updated event values.\r\n\r\n`layout` is an array of what actually goes into the card. At the moment I'm thinking that this should be layed out top to bottom in the in-app representation, but I'm not sure how this would interact with e.g. an icon, where you'd want to have a title and text to the right of the icon instead of below. (Could this be solved with a horizontal list?) Regardless, each object in that array contains a `type` attribute which defines what that element is, and then all other properties are specific to the `type`. ATM, I'm thinking that horizontal lists could have e.g. a `value` property whose value was an array of layout elements (exactly like the top-level `layout` property), but I could also easily imagine it simply being an array in `layout`, instead of an object with `\"type\": \"horizontal_list\"` or something. (Although then how would we differentiate between vertical and horizontal layout?)\r\n\r\nAnyway, I clearly have lots of ideas about how this should work, but I thought I'd open this issue to solicit feedback from the community.\r\n\r\n(Also, this would probably expose some sort of public API for card retrieval. Not sure where that should be, either.)\r\n\r\n [1]: https://github.com/strugee/muninn\r\n"}}
{"actor":{"display_login":"strugee"}}