Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Post-Footer Implementation #10

Open
3 tasks
Akamig opened this issue Mar 16, 2021 · 0 comments
Open
3 tasks

Post-Footer Implementation #10

Akamig opened this issue Mar 16, 2021 · 0 comments
Assignees
Milestone

Comments

@Akamig
Copy link
Owner

Akamig commented Mar 16, 2021

Screenshot from 2021-03-17 05-21-09

Current Prototype

  • Flexbox based (flex-basis 50% on over-bp.sm)
  • Seperated with borders

Problems inferred from prototype

  • adjacent border lines are causing eyestrain.
  • double column layout seems a bit distracting because of obscured information order.
  • uneven space reservation
    For example, short metadata (post language, date, authors, related links, files) are shove-able in a small box, even in 20~33% width of full layout, without causing much distraction.
    while longer metadata (license information, description) requires larger space, more like post-body.

so when these two mixed together and laid without length consideration (ie. samely), since the content length keeps changing extremely, it really hurts constant read flow.

  • I'm not sure how should I handle conditional metadata.
  1. even should these metadata be conditional or not? (from seeing wikidata, conditional metadata is not much frustration)

  2. different metadata sometimes can be very different when it comes to representation. (Tag requires Tagbox component), so I can't just simply map them out on the same styled box component with a key-value data.

  3. what kind of structure should I pass as props?
    3.1. how about make some special case components and conditionally render them when these specific props exists, and non-crucial non-special other values can be given as key-value structure and just default-render them out?
    3.2 3.1 is quite hard to handle when using it on pages (like, a lot of props should be nullable, and that's not good.)

  4. how the hell should I store these conditional metadata in markdown? I'm pretty sure just simple frontmatter won't do it.

Improvements

Screenshot from 2021-03-17 06-06-05
Maybe this wikidata style layout would help. this title left, desc right layout helps, but I don't like it in mobile.
nutrition label
As I first intended, I should be more focused on this nutrition facts layout style, on shorter metadata, this layout can be really effective and unified even if some ingredients missing.

  • Focusing on separate some longer / shorter, crucial / non-crucial metadata will certainly help readability

  • I need to sleep

  • Create special case subcomponents

  • Thinking about how can I put these subcomponents without making a ton of nullable props.

  • Make these collapsible <- Not so important, but will help readability a lot.

@Akamig Akamig added this to the Release 1.0 milestone Mar 16, 2021
@Akamig Akamig self-assigned this Mar 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant