develop a GlitchCat flavour and make it the default one

[aescling]

if it were solely a cat family project, i would suggest a black theme perhaps with notable rusting (a very nice pun, if we consider the interests of one of our initial users!)

i’m not sure what a melding of cat and KIBI æsthetic preferences would look like (especially given that at time of writing i borrow design language from the latter Way Too Much), but figuring out what that would Mean as a design would be the Ideal imo

[marrus-sh]

A dark, mostly monochrome theme using the Print + Pastels colour scheme (which is slightly sepia‐tinted) has always been my preference for default themeing (I actually first created that palette for use with Ardipithecus, a very old attempt at a mastodon fork); I’ve actually been working on a colour palette which is more blatantly sepia for a while but it’s Not Done Yet.

[aescling]

both of those sound very up my alley so cool

is the dark theme you’re mentioning basically what my website looks like now lol

[marrus-sh]

[marrus-sh]

Remind me later to write up some design principles so that if somebody wants to experiment with this they have a place to start.

[marrus-sh]

Before we begin work, there are a few questions which need to be decided :—

• The programming language we will use. Our options are :—

  1. (Literate) CoffeeScript, and compile with Babel/Node/Webpack.
  2. JavaScript, and compile with Babel/Node/Webpack.
  3. JavaScript, and compile with Deno.
  4. TypeScript, and compile with Deno.

  It’s not possible to get rid of Kibicat Mastodon’s dependency on Node (unfortunately), because it is presently used for streaming and Webpack (which we need to keep around for CSS). But we could immensely simplify it / reduce our dependencies by using Deno (and deno bundle) for our frontend work. This would be my preference, bearing in mind that Deno is a much more minimal scene and we’ll have to do some architectural work to get it working.

  (Of course, this means adding a dependency on Deno, but this is Not A Big Deal.)

  The downside to using Deno is that we would need to either maintain Node/Webpack as an alternate option (probably not that difficult), or drop support for the upstream flavour (and any flavours derived from it) completely. The upside is reducing the massive memory requirements of assets:precompile, plus Deno has a much simpler model (it works exactly like the browser).

• The license we will use. The flavour ought to be developed in its own repository and then incorporated here as a Git submodule (the flavour system is designed to work this way), so it doesn’t need to be AGPL. My preference is to use the MPL for Ecmascript code, but this is of course open to discussion.

• Language support. See Remove support for some languages #23. Developing a new frontend likely means an entirely new set of localizations, so we will have to decide ⓐ which languages we plan on supporting, and ⓑ whether we want to continue maintaining languages for other parts of the interface, if we aren’t planning on adding support in the frontend.

Design principles I think the flavour should uphold :—

• Use standardized web technologies (HTML custom elements, template literals, JavaScript internationalization API), not proprietary library solutions (React, JSX).

• “It’s Just HTML” and “It’s Just JavaScript”; follow best‐practices and don’t reinvent the wheel. Use builtin interface elements where possible and follow web interface guidelines/standards. Avoid popups / toggles / animations in favour of disclosure elements, buttons, checkboxes and so forth.

• Flexible, reusable components.

Design limitations :—

• It needs to be a single‐page web app loaded from an effectively blank page. This is required by the theming architecture.

• It needs to be easily maintainable. Compare the current Mastodon frontend, which is a nightmare.

[marrus-sh]

https://github.com/kibicat/lune