Feature Request: Create a view that is "list" instead of "map"

[momack2]

In roadmaps like the FVM roadmap (fvm.filecoin.io) it is useful to see a single webpage where you can view the linear milestones top to bottom (including the description in prose).

• It would be useful for multiple groups and to be rendered in a tool (vs manually created on websites)
• It would also be useful to be able to embed that in a website - so that it updates programmatically when the github issues are changed.

[juliaxbow]

Including some rough mockups below for how this could look. Let me know which direction is preferred and we can go from there.

Some addt'l questions:

• How closely do we want this to match FVM formatting? The alternative is to include in table format
  • I assume we would like all parameters to be the same for this view, e.g. include explicit ETA rather than high-level month/quarter? This makes the FVM-style a bit less neat but shouldn't be a problem
• Is there any other metadata from GitHub we would like to include?

Alt. 1 High Level List

Alt. 2 Table View

[SgtPooki]

ping @momack2

I say we go with the first option for now.. it makes the descriptions much easier to read, and as our only view with descriptions, that's important.

cc @tinytb

[momack2]

I also like option 1 better!

[momack2]

I also think working on the list view is a more impactful short term win. we can debug specific css positioning changes after landing this.

[AlexxNica]

We may have to handle multiple items under the same date. Any ideas on how we would display that?

An idea using the FVM example as inspiration would be to show them under an indented list (like Milestone 2.1 there) and have the date be the header.

[SgtPooki]

An idea using the FVM example as inspiration would be to show them under an indented list (like Milestone 2.1 there) and have the date be the header.

@AlexxNica I like that approach, we can fine-tune as we get feedback, but that sounds more than reasonable for now. Are you working on the list view? You mentioned, via slack, having put some effort toward that. I'm planning to take that on as core work tomorrow and finish within a week or so. lmk

[AlexxNica]

@SgtPooki I started exploring. I'll add that to a branch in my fork and ping you; hopefully that saves you some time. I can also help review the PR when it comes in. Sounds good?

[SgtPooki]

thanks Alex!

[AlexxNica]

Here's the template: https://codepen.io/AlexxNica/pen/gOdwxwa

I think the template can be a starting point (that's how I prototyped the list view before), but there are definitely other ways to achieve the same, so feel free to choose whatever method you're most comfortable with!

@SgtPooki let me know if it'd be helpful to pair up for some time next week to do this together. 🙌

[SgtPooki]

Thanks Alexx, that's a great snippet for showing the nesting 👍

got the basic view done for now. working on styling the titles and such before I hop into nesting:

just using a simple grid and template areas for the items at this point

      templateAreas={`"date icon title"
                      "empty line description"`}
      gridTemplateRows={'1fr 1fr'}
      gridTemplateColumns={'1fr 0.5fr 8fr'}

[SgtPooki]

I believe the intention with this list view was to render all children, but I don't think that's a great UX, and so the first pass is going to only render the direct children (similar to how overview only shows direct children). This causes a few issues with navigation within the list view.

The initial design doesn't give guidance on communicating to users what links are clickable or not, nor whether to differentiate between linkable children or not, so i've been looking over a number of separate ways to communicate this (because all issue titles are currently Blue and look clickable).

Display all links as blue, clickable or not (in original mockup from Julia)

Pros

• Looks great
• Hover state can potentially communicate clickability to users.

Cons

• Cannot tell at first glance which items are clickable or not

Screenshot

Display clickable links as blue, and non-clickable as black.

It's how we do it on overview/detailed view

Pros

• Convention aligns with other screens
• Users can immediately see which items are clickable

Cons

• Doesn't look great on list view.

Screenshot

Use underlines

Very common and accessible; but not "pretty." Out of fashion.

Pros

• Users can immediately see which items are clickable

Cons

• We don't use underlines for links on starmap.site unconventional and surprising(UX bug)
• Doesn't look great

Screenshot

Use an icon to indicate traversibility

Pros

• Users can immediately see which items are clickable
• Looks good and gives flexibility with coloring
• link icon should be pretty intuitive in this scenario.

Cons

• Can look odd depending on how we want to position it

Screenshots

Arrow

Link Icon (front)

Link icon (rear)

---

I'm going to go with the link icon in the front for now, but let me know if others have better ideas, comments, questions, or concerns.

cc @whizzzkid

[SgtPooki]

There is also a discussion in #196 (comment) pertaining to parsing of "description:" content from milestones.

[whizzzkid]

@SgtPooki I like the link icon at the end, reminds me of Reddit. Using ellipses along with that might not be a bad idea either.

Also the GitHub issue will be linked, so two links will exist side by side, I can understand the rationale with link icon before and why you like it.

Can we also change the link icon from 🔗 to something like this https://icons8.com/icons/set/open-url the former is more related to inserting a link than opening (latter)