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

Some buttons do not do anything without JavaScript enabled #243

Closed
bkil opened this issue May 30, 2023 · 5 comments
Closed

Some buttons do not do anything without JavaScript enabled #243

bkil opened this issue May 30, 2023 · 5 comments
Labels
Z-Confidence-Low Low confidence in the enhancement or suggestion based on known factors, or as described.

Comments

@bkil
Copy link

bkil commented May 30, 2023

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 MadLittleMods added the Z-Confidence-Low Low confidence in the enhancement or suggestion based on known factors, or as described. label May 30, 2023
@MadLittleMods
Copy link
Contributor

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
Copy link
Author

bkil commented May 30, 2023

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
Copy link
Contributor

@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: #158

It isn't helped by the fact that the links to days aren't stable either as per #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 #238 improves this situation either.

@bkil
Copy link
Author

bkil commented May 30, 2023

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
Copy link
Contributor

@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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Z-Confidence-Low Low confidence in the enhancement or suggestion based on known factors, or as described.
Projects
None yet
Development

No branches or pull requests

2 participants