Skip to content
Trevor Croxson edited this page Dec 22, 2017 · 14 revisions

Next Meeting Agenda

Our Design Pipeline: What Does it Look Like?

  • Discuss rationale, goals, and process for moving our design forward given our resources (15-20 mins)
  • Brainstorm orgs/people who might be able to connect us to design talent, and how we might reach out (5-10 mins)

"God Mode" Design

  • State our design problem: Who are we serving, and what problem(s) of theirs are we trying to design for? (5-10 mins)
  • Circulate individual God Mode sketches/designs among team and discuss initial reactions (20-30 mins)
  • Formulate next steps

2017-12-21

Work in progress:

  • Trevor: Still working on the PlaceFormView port to React, but very close to done now. Once done with that, he is planning to move onto other components. Others may also help with other components once we have a pattern to follow.
  • Luke: Working on the Django upgrade.
  • Zeb: Starting work on localizing on the client side, which will help with porting components over to React. There are some complications, e.g. a very inconsistent current state of Mapseed localization and at least a few lost translations.

"God Mode" Architecture

  • What architecture would facilitate the best customer experience with "god mode"?
  • Talked about this document from a while back which addresses the problem, discussed what we might change with new knowledge and business model
  • Data storage of map configuration: in a relational database or not?
  • We mostly agreed that the source code of "God Mode" should be separate from the api source

"God Mode" Design

  • What interface makes the most sense for "god mode"?
  • Drag and drop, editing right in the map vs. editing in a separate interface
  • Highlighted in detail the challenges of designing a story editor
    • If drag-and-drop, editing UI has to adapt to custom viewing UI (for instance, no story progress indicator, just back and forward buttons)
    • Selecting what location the map jumps to is hard to do in a tactile way

Organization

  • Have a design meeting on the above design problem: each do individual sketches on pen and paper and compare/contrast/evaluate
    • We need a system to hold our design sketches and to continue the design process on; maybe just a git repo?
    • Make a community-editable agenda for the design meeting
  • We lack resources for tackling difficult design problems; it would be ideal to have some design leadership
    • We could use our network to find some experienced designers
    • It would be nice to have a website/some public-facing stuff so we can pitch ourselves to potential designers
    • Designer onboarding could be worth improving
  • Mentorship/Governance
    • We could use mentors or a board of directors to help strategize on hard problems
  • Planning
    • Clearer timelines for when we'll have things done
    • We need to make sure everyone knows what they can do to help the most
      • Group understanding of what's most important/highest priority
      • Communicate progress and delegate tasks

2017-12-15

React port

  • Trevor has a big PR pretty close to done, which ports over one family of components and establishes a pattern for porting future components
  • Porting flavor-specific overrides is difficult
    • For flavors we don't use anymore, let's not do it up front--just leave an old version deployed, "freeze" it there, and do the update work if we ever need that flavor back again

Components vision

  • Mapseed will expose lots of components which can be mixed and matched by developers to create custom map types
  • Story templates: multiple pre-made configurations/layouts/themes that can be selected among by someone who doesn't know how to code
  • Each flavor becomes its own repository that imports some version of Mapseed and consumes some or all of the components
  • Should business logic like preparing data for the server be in components or should we put it somewhere else?
  • "Tweaks" API for when developers want to make small changes to the components, like our current flavor overrides?
    • Maybe no dedicated API, just replace + compose like you would if making big changes?
    • Lifecycle hooks that define some small/reasonable number of spots that can be trivially tweaked (think callback functions)?
    • Inheritance pattern in which the map creator can override almost any method in the component?
Clone this wiki locally