Draft of Q3 2018 OKRs for In Web Browsers Working Group

OKR planning issue: https://github.com/ipfs/in-web-browsers/issues/85

Feel free to propose objectives, results, or just things you would like to work on or see happen by editing this pad

Goals

same? change?

olizilla: I think these goals still stand. my OKRs didn't feel very measurable when I came to look at them at the end og q2. I think we need more regular review, either at each weekly catch up, or 1 per month, as an internal / peer2peer project management exercise.

  • GUI/UX

    • Our GUI apps expose core IPFS features in a robust, accessible and intuitive form

  • Web Browsers

    • Browser developers are committed to addressing requirements of the distributed web
    • Create a developer ecosystem around window.ipfs API
    • Ensure smooth experience for web developers

      lidel: I feel the old goal was too narrow. Web Browser WG should act as an overwatch that ensures entire IPFS stack works well in web browser. The window.ipfs is a small part of that goal. Browser bundles of js-ipfs* libs, tools, examples and documentation are probably the biggest chunk of the work.

OKR Draft

{use this as a "brain dump", a sanbox of ideas - we will organize them later}

Asking these questions may help (copied from ipfs/pm):

  • What are your top users/applications on top of the part of the project you contribute and/or lead?
  • What are their next goals? How can your project help them be successful?
  • What are the main blockers for adoption of your project?
  • What are the main blockers for contribution to your project?
  • Name the most important thing you and your team need to achieve? What is the timeline for that? What could be done to achieve that in less than three months (Hiring, Partnerships, Drop other tasks, etc)?

Emoji meaning:

  • 🔗 – link to relevant issue/resources
  • (pN) – priority (0-4)

Web Browsers WG 🖥️

Browser developers are addressing requirements of the distributed web

  • p0 Finished switch to base32 CIDv1 as the default across entire IPFS ecosystem 🔗
  • p1 Created at least three IPFS demos using experimental WebExtension APIs from mozilla/libdweb 🔗
  • p2 IPFS Companion with embedded go-ipfs ship with Chromium-based Brave by default
  • p3 Published final draft of “Addressing on the Decentralized Web” and found a champion to take it further 🔗

Ensure smooth experience for web developers in browser contexts

  • p0 Browser-focused checks exist for js-ipfs(-api) and are part of CI: fail build if tests don't pass when bundled by all the bundlers or run over maximum bundle sizes
  • p1 IPFS in Firefox and Chrome supports upload of 5GB file without crashing or slowing down the UI (via Companion / window.ipfs / HTTP API)

Browser extension exposes IPFS features in a robust and intuitive form

  • p0 New WebUI ships inside of Companion bundle and is re-used for sharing/uploads, file management, exploring peer info and config editor 🔗
  • p1 User is able to define multiple API backends and switch between them via browser menu 🔗
  • p2 Preferences, ACL and Upload screens follow visual language from WebUI and ipfs-css 🔗
  • p2 Performance impact of content script that injects window.ipfs decreases by at least 50%
  • p3 One click to add a snapshot/screenshot of current web page to IPFS 🔗
  • p4 User is able to easily switch node to read-only mode (Disabling Content Reproviding for improved privacy) 🔗
  • p4 It possible to control the node provided by IPFS Desktop from browser extension UI 🔗
  • p4 Browser extension is exposing IPFS API on-demand in fingerprint-resistant way 🔗

GUI Team 🎨

Core IPFS features are intuitve and accessible to all

  • p0 Revamp of existing Web UI features is complete and deployed with stable go-ipfs release - https://github.com/ipfs/ipfs-gui/issues?q=is%3Aissue+is%3Aopen+label%3A"existing+feature"
  • p0 Desktop is rebuilt as a wrapper for Web UI (we can deploy without waiting for go-ipfs)
  • p0 On board a full time UI designer to the GUI team
  • p1 Web UI works with js-ipfs in the browser (backend pluggability)

    lidel: how about measurable "Web UI works with three different IPFS API backends" ?

  • p1 Web UI scores 100 for accessibility in lighthouse test and is available in at least 3 locals (en, pt, pl)
  • p1 There is a documented user testing plan and 5 recorded user testing sessions of Web UI
  • p1 There is a smooth 3-step onboarding flow (offer, install, welcome) for companion and desktop https://github.com/ipfs/ipfs-gui/issues/27
  • p2 Companion reuses file sharing flow from Web UI

lidel: is it too late to add this?

  • p4 Translations to all GUI apps (Companion, WebUI, Desktop) are on a single crowdsourcing site 🔗

Everyone is empowered to make great new IPFS user interfaces

  • p1 There is a UI dev guide with example components for headers, footers, navigation, forms, lists and tables.
  • p1 Web UI pages are extracted as standalone apps that can be linked to from new apps

The GUIs push forward understanding and adoption of IPFS

hacdias: looking back at Q2 objectives and key results, I think it was hard to define how much time we'd need to finish each one.
For this quarter, I propose to finish what we had started on the last quarter, mainly:

  • Build the new Sharing screen
  • Finish the new WebUI
  • Redesign Desktop to streamline our design line
  • Embbed WebUI on Desktop

Some other small ideas:

  • Create a page on ipfs.io, or reuse Get Started, to talk about Companion and Desktop.

Needs to communicate to other WGs

  • go-ipfs

  • js-ipfs

    • Make base32 CIDv1 the default
    • js-ipfs in browser context has same connectivity magic feeling as go-ipfs
      • dht interop
      • relay with discovery

  • interface-ipfs-core

    • Authenticated API access
Select a repo