Some buttons do not do anything without JavaScript enabled

[bkil]

A banner should be prominently displayed somewhere on each page that enabling JavaScript would gain certain additional features (which ones exactly?).

Disfunctional user controls should be hidden when JavaScript is disabled (or better yet, not be part of the DOM itself).

Here are a few I could identify on the timeline view:

• Developer options
• ... (The Timeline_messageOptions menu to the right of each message)
• The year & month dropdown in the date picker
• The previous and next month buttons in the date picker

And on the main page & search page:

• Safe search
• Actions -> Add new server... in the HS picker dropdown

[MadLittleMods]

Please note, we're not specifically optimizing for the disabled JavaScript case but simpler and semantic is better in terms of search engines which we do care about.

The interactions mentioned aren't really relevant to a search engine to worry about and aren't critical for users to view content (someone can directly visit an archive link and see messages).

[bkil]

Putting it another way, some search engines will not be able to go far back in time during indexing by clicking the calendar widget as they may only want to click a limited number of times on the jump to earlier activity button as it clearly is dynamically generated. It isn't helped by the fact that the links to days aren't stable either as per #238

[MadLittleMods]

@bkil Search engines can crawl the next/previous links to gather all days. And all calendar day links are exposed as soon as you view a day in that month.

We might even have a sitemap in the future: https://github.com/matrix-org/matrix-public-archive/issues/158

It isn't helped by the fact that the links to days aren't stable either as per https://github.com/matrix-org/matrix-public-archive/issues/238

It's impossible for links to be completely stable with a URL based on dates against the Matrix DAG of events in a room. I'm not seeing how https://github.com/matrix-org/matrix-public-archive/issues/238 improves this situation either.

[bkil]

What is the target browser audience? Are proxy browsers such as UC/Opera Mini on the table or should I not bother to test on them? Is KaiOS or modern phones with small screens targeted?

[MadLittleMods]

@bkil There is nothing set in stone yet but it's pretty much this:

• Latest couple versions of Chrome, Firefox, Safari
• Common mobile devices (Android and iOS)
  • Small screens included although we can only do so much with that kind of real estate
• Optimized for search engines (prefer simple and semantic)
• Since it's just HTML and server-side rendered, the content should mostly just be viewable anywhere though (not all interactions need to work unless it's easy and makes sense to fix)