Muting, hiding, or adjusting lane colors is a nice focus-feature

[benjaminapetersen]

I recall doing this in Trello years ago via some user-defined CSS, but for use cases like Done lane or Rejected or Ice Box, being able to Mute (70% opacity) or hide a lane is nice for reducing the UI clutter.

I haven't thought about a UX for a lane with tons of cards (ie, Done lane with many items that are no longer necessary to see). I imagine a Empty lane button that moves them to a hidden Archive lane could be a handy maintenance feature.

[benjaminapetersen]

Related to #135, but I think might be a more robust feature.

[benjaminapetersen]

Started looking into this. The main issue I see is that a lane is just a string, but needs to be an object, something like:

// config/sort/lanes.json
{
  name: "something"
  metadata: {
    mute: true||false  // to track a CSS class that can do a simple opacity: 0.4-ish
  }
}

Seemed simple enough, but there are quite a few things that depend on lane being a string, so wasn't able to knock it out in a quick pass. I imagine updating the model to an object will support other future potential changes.

[benjaminapetersen]

@BaldissaraMatheus prob would be good to get your input here, before just hacking something. I'd rather hack on it further with your vision of what an object like lane should look like.

In theory, something standardized would be ideal, not just for lane, but any object like card and tag, etc (/config/sort/cards.json, /config/sort/lanes.json) Something like I suggested above:

// Ideally a standard object that all objects can follow, if they need.
// most probably won't
// if it emulates a Mardown file structure (such as mentioned in issues  #144 and #145)
// then it avoids UI inconsistencies, backend inconsistencies, etc.
// could easily translate a Task to JSON, Markdown, YAML, or whatever in the future, if desired.
{
  frontMatter: {
    uid: 12345,
    title: "my lane",
    description: "",
    dueDate: "",
    createdAt: ""   
  }
  content: {    
    body: ""
  }
  footer: {
    metadata: {
      // a string or enum is better for future flexibility.  
      // "0.4" is effectively "true" for now, but one day could support
      // several choices (if ever desired).  If not, "0.4" just remains the "truthy" forever
      mute: "0.4"
   },
    updateLogs: [],
    comments: []
  }
}

Ideally a relationship between this /config/sort/whatever.json object and the markdown files mentioned in #144 and #145. So if most objects represented in mardown look something like this:

---
# front matter style block for important metadata
created: 8 Jan, 2025
title: Projects We Care About Session x
id: 12346
---

# My Markdown File for Stuff

- foo
- bar
- baz 

<!-- 
# html style block for "noisy" metadata
metadata:
  task.md:
    log:
    - updated: 
      - date: 2025, Jan 8
      - column: backlog
    - updated: 
      - date: 2025, Jan 7
      - column: doing
    - updated: 
      - date: 2025, Jan 3
      - column: done
-->

then a similar JSON could look like:

// most of this may not be needed, but 
// nice ot know up front that both JSON and Markdown
// can have symmetry if desired
{
  frontMatter: {
    uid: 12345,
    title: "",
    description: "",
    dueDate: "",
    createdAt: ""   
  }
  content: {    
    body: ""
  }
  footer: {
    updateLogs: [],
    comments: []
  }
}

[BaldissaraMatheus]

The JSON representation looks fine (maybe a too much info for this use case), but the /sort directory is supposed to be used specifically for sorting, that's why they're represented as strings.

I though about creating muted.json and hidden.json files, but It looks like it's starting to pile config files for different things, which is not good.

Maybe we could add a flag within the lane directory name, more or less like described in #152. By not having database we have to be a little creative

[benjaminapetersen]

Yeah definitely no need to overdo it, keeping it simple makes sense. There is a sweet spot of simplicity/consistency somewhere.

I'm a bit inclined to think an object { } with a unique iud and then attributes as one config file might be the easiest to manage, rather than different files with [string,string,string].