Skip to content

Meetings

Jump to bottom Edit New page
Zeb Burke-Conte edited this page Jan 12, 2018 · 14 revisions

Next Meeting Agenda: 2018-01-11

Our Design Pipeline: What Does it Look Like?

"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

2018-01-11

Design Pipeline

  • A process for systematically forming design consensus as a group
  • Necessary because none of us are design experts; we need the "wisdom of the crowd"
  • Basic process
    • Select and prioritize features
      • Some questions about how best to do this: for instance, bottom-up (starting specific) or top-down (starting with almost a mission statement)?
    • Do research on existing implementations of the same or similar features
      • For some things, there won't be exact carbon copies already out there. We need to map the general landscape, compare existing tools with each other, and think about the reasoning behind their differences. Once we've understood that, we'll be well on our way to deciding on what Mapseed should do.
    • Everyone sketches and brainstorms designs (divergent thinking)
    • Discuss, compare, and evaluate (convergent thinking)
    • Assign a single person to turn the broadly-agreed-upon low-fidelity mockup into a mockup with enough fidelity that the developer can start work
  • We'll need to continue to discuss this process

God Mode Design

  • Compared sketches
  • Discussed pros and cons of WYSIWYG
    • Pros
      • Immediate feedback
      • Unified UX
      • Fun
    • Cons
      • Not as flexible in different situations (e.g. different story themes)
      • Can be hard to fit into existing UI
      • "Bootstrapping" concerns and making clear what is editor and what is map
  • Discussed stories (because that was the example we sketched)
    • Are stories made up of map-maker-generated or community-generated content?
      • We think probably both
      • Should user-submitted places themselves be put into stories, or just referenced from stories?
        • We mostly think the latter; places can stand on their own and can be in multiple different stories
        • You could think of a place as an "embed" just like a YouTube video or similar
    • Are stories flexible enough to cover curation and filtering tasks?
      • For instance, showing only funded places on participatory budgeting maps; you'd probably want that in the legend like a data layer. It has no order or narrative.
      • Is curation and filtering of user-generated content necessary?

Documentation Site

  • Integration with new landing site
  • Automatic deploy from GitHub?
  • Should collect content from wiki, doku, etc.

2018-01-04

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?

Back to home

Home
Features
Roadmap

Clone this wiki locally