{"action":"created","issue":{"url":"https://api.github.com/repos/status-im/ideas/issues/24","repository_url":"https://api.github.com/repos/status-im/ideas","labels_url":"https://api.github.com/repos/status-im/ideas/issues/24/labels{/name}","comments_url":"https://api.github.com/repos/status-im/ideas/issues/24/comments","events_url":"https://api.github.com/repos/status-im/ideas/issues/24/events","html_url":"https://github.com/status-im/ideas/issues/24","id":275062504,"number":24,"title":"Onboarding experience","user":{"login":"sla-shi","id":1944596,"avatar_url":"https://avatars0.githubusercontent.com/u/1944596?v=4","gravatar_id":"","url":"https://api.github.com/users/sla-shi","html_url":"https://github.com/sla-shi","followers_url":"https://api.github.com/users/sla-shi/followers","following_url":"https://api.github.com/users/sla-shi/following{/other_user}","gists_url":"https://api.github.com/users/sla-shi/gists{/gist_id}","starred_url":"https://api.github.com/users/sla-shi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sla-shi/subscriptions","organizations_url":"https://api.github.com/users/sla-shi/orgs","repos_url":"https://api.github.com/users/sla-shi/repos","events_url":"https://api.github.com/users/sla-shi/events{/privacy}","received_events_url":"https://api.github.com/users/sla-shi/received_events","type":"User","site_admin":false},"labels":[{"id":754722572,"url":"https://api.github.com/repos/status-im/ideas/labels/design","name":"design","color":"9df9de","default":false},{"id":749664963,"url":"https://api.github.com/repos/status-im/ideas/labels/draft","name":"draft","color":"9897ef","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2017-11-18T08:04:20Z","updated_at":"2017-11-20T12:41:06Z","closed_at":null,"author_association":"MEMBER","body":"<!-- Please Review https://docs.google.com/document/d/1CaFM2ZXGOKf05_LXMPJeNNy5qJOdAq91EF2Gn2QUBFI/edit# for more details -->\r\n<!-- in PR the document should be named as`DEV#1-title.md` -->\r\n\r\n## Preamble\r\n\r\n    Idea: <to be assigned>\r\n    Title: <title>\r\n    Status: <Draft | In Progress | Closed >\r\n    Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>\r\n    Requires (*optional): <Idea number(s)>\r\n    Replaces (*optional): <Idea number(s)>\r\n\r\n\r\n## Summary\r\n<!-- \"If you can't explain it simply, you don't understand it well enough.\" Provide a simplified and layman-accessible explanation of the Idea. -->\r\nMake Status app easy to use right after it's installed.  Revisit onboarding user experience and make sure that user can explore Ethereum and the app possibilities without having to go though boring funnel of creating new account, etc. \r\n\r\nIn essence, user should be able to provide just enough information on the `as-you-go` basis.\r\n\r\n## Vision\r\n<!-- A short (~200 word) description and motivation of the Idea. Without clear explanation the Idea should not proceed. Can include User Stories -->\r\n> Reduce the initial screen down into a set of verbs or phrases, where all you need to choose is how you want to be started, ie \"make a transaction\", \"find a friend\", \"explore Ethereum\", \"recover an account\"\r\n\r\n## Swarm Participants\r\n<!-- Each contributor pledges to the idea with their FOCUS value. (hours per week) -->\r\n<!-- Here all roles in swarm are defined and filled, one of the contributors should responsibility of the Idea as Lead. -->\r\n\r\n<!-- Testing/Evaluation support role is also mandatory to check in on specified Goal dates or earlier. -->\r\n\r\n<!-- A swarm requires at minimum 3 contributors and 1 evaluator/tester -->\r\n<!-- 'Contributor' should be replaced with a descruptive role type. -->\r\n- Lead Contributor: <!-- @username -->\r\n- Testing & Evaluation: <!-- @username -->\r\n- Contributor: <!-- @username -->\r\n- Contributor: <!-- @username -->\r\n- UX (if relevant): <!-- @username -->\r\n<!-- - Contributor: @username -->\r\n\r\nSwarm channel: TBD\r\n\r\n## Requirements\r\n<!-- The Swarm must then develop a fully fleshed out Requirements document for the idea to proceed, to the satisfaction of participants. -->\r\n<!-- There is no approval unless the idea requires to be reviewed by supporting organelles (Financial, Hiring or Design). -->\r\n\r\n## Goals & Implementation Plan\r\n\r\n<!-- Testing/Evaluation role accepts responsbility to checkin at Goal dates, -->\r\n<!-- forces discussion to continue implementation or recommend disband and post-mortem. -->\r\n\r\n### Minimum Viable Product\r\n<!-- Mandatory, completes the Idea in the fastest route possible, can be hacky, needed to feel progress -->\r\nGoal Date: <!-- Date for evaluation in ISO 8601 (yyyy-mm-dd) format --> \r\nDescription: <!-- Description of Deliverables-->\r\n\r\n### Iteration 1..N\r\nGoal Date: <!-- Date for evaluation in ISO 8601 (yyyy-mm-dd) format --> \r\nDescription: <!-- Description of Deliverables-->\r\n\r\n## Supporting Role Communication\r\n<!-- Once Requirements and Goals are fleshed out, then it should be communicated to supporting organelles if required -->\r\n\r\n## Post-Mortem\r\n<!-- Only necessary when in Closed state -->\r\n<!-- Should summarize how the Swarm behaved, document what went well, what didn't -->\r\n\r\n## Copyright\r\nCopyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).\r\n"},"comment":{"url":"https://api.github.com/repos/status-im/ideas/issues/comments/345684419","html_url":"https://github.com/status-im/ideas/issues/24#issuecomment-345684419","issue_url":"https://api.github.com/repos/status-im/ideas/issues/24","id":345684419,"user":{"login":"denis-sharypin","id":6559881,"avatar_url":"https://avatars2.githubusercontent.com/u/6559881?v=4","gravatar_id":"","url":"https://api.github.com/users/denis-sharypin","html_url":"https://github.com/denis-sharypin","followers_url":"https://api.github.com/users/denis-sharypin/followers","following_url":"https://api.github.com/users/denis-sharypin/following{/other_user}","gists_url":"https://api.github.com/users/denis-sharypin/gists{/gist_id}","starred_url":"https://api.github.com/users/denis-sharypin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/denis-sharypin/subscriptions","organizations_url":"https://api.github.com/users/denis-sharypin/orgs","repos_url":"https://api.github.com/users/denis-sharypin/repos","events_url":"https://api.github.com/users/denis-sharypin/events{/privacy}","received_events_url":"https://api.github.com/users/denis-sharypin/received_events","type":"User","site_admin":false},"created_at":"2017-11-20T12:41:06Z","updated_at":"2017-11-20T12:41:06Z","author_association":"MEMBER","body":"![onboarding 02](https://user-images.githubusercontent.com/6559881/33017981-bf8500d2-cdf4-11e7-9ebf-d2a1d63eefaa.png)\r\n\r\nTo start a discussion, I have a general idea how to implement an onboarding that could satisfy the most of our [design principles (https://docs.google.com/document/d/1pKouXBAcMHVOySkSI1we4N-qhA9smLNbs5uW2QEdjaQ/edit). \r\n\r\nWe can create screens like that on every new concept or a complicated UX for users. For instance, if a user sends a message to an offline user we show him a 'blue screen of help' saying that Status is a p2p messenger and works differently.\r\n\r\nI like this approach because it's flexible and has a simple logic behind. UX flow is like that: \r\n1. a user is going to make an action that requires SNT; \r\n2. we are checking was a concept of SNT introduced to the user;\r\n3. if not, we simply show him a help screen with the description of what SNT is.\r\n\r\nMain disadvantages of this modular onboarding are: sometimes a user can see two screens in a row like I had it here https://github.com/status-im/ideas/pull/23 or this approach could feel like braking and interrapting main userflows. \r\n\r\n    \r\n\r\n"}}
{"actor":{"display_login":"denis-sharypin"}}