One thing that would be helpful about not using drop-down boxes for static options: Fewer clicks required to set up a search. Each of the drop-down boxes in use now requires the user to:
Read the text on the drop-down box to decide whether it's relevant
Move the mouse to the drop-down box
Click to open it
Read the options within
Move the mouse to the best fitting option
Click to choose the option
The first drop-down box (search type) contains only five options, which could be replaced by buttons like the existing Subscribed/Local/All buttons. It would make discovering the available options easier because they would no longer be hidden behind a drop-down, and it would reduce the number of actions required of the user.
The second drop-down box (sort type / time frame) might be a good candidate for this change, too.
As for whether tabs would be a better choice than the button-style approach currently used by Subscribed/Local/All: I'm not sure right now, as I haven't had much time to consider it. But I think things would get messy and possibly confusing if more than one of these input elements were converted to tabs, because it would mean nesting tabs within tabs. On the other hand, using a row of buttons for each category would allow them to coexist neatly, fit the existing visual style, and avoid adding the complexity of another widget type for users to navigate.
This is a little confusing because you also re-post* questions from non-.ml users. [example] [example] [example] I guess you mean you're copying questions that were posted by people on any instance to communities hosted on lemmyml. Yes?
*(I say re-post because you do it without using the cross-post feature, so we can't see the sources.)
I think I now understand what you're trying to do, but I'm skeptical. As someone on the receiving end of your copypasta, what I see is a flood of posts from a single account dominating some of the forums that I frequent. The pattern resembles that of a bot, casts an unauthentic tint on the content of your posts, and makes the signal-to-noise ratio of the receiving communities look pretty bad.
Even as someone who prefers to avoid the tankie instances, I suspect that what you are doing is likely more harmful than helpful to the other ones. I have been considering unsubscrbing because of it. And, since you are bridging content from the problematic place, I think a case can be made that your effort is counterproductive to your own goals. After all, why would people migrate away from lemmyml if they know they can post there and have their words reach other instances as well?
As an alternative, might I suggest contributing your time to boosting awareness and membership of non-ml communities? This would be a more organic approach, and perhaps slower, but I think the results would be better. Take !privacy@lemmy.dbzer0.com for example. It was pretty quiet until recently, but after a little promotion and participation from a few interested people, activity there seems to be rising quite a bit.
They might be referring to the fact that X11 allows things like user input snooping and screen scraping between processes. It's a legitimate problem, and I think Wayland aims to address at least part of it...
...but it's impossible to tell what the author understands of issues like this, since their list of complaints is scattered, shallow, and poorly articulated. I think they would do better to open a discussion and start learning from it, rather than making a broad critical declaration to everyone here without supporting it.
In what way is the search function in Lemmy awkward to use,
Generally, I find that it requires too many clicks.
To search for things I'm usually interested in, I have to click a link to reach the search page, wait for the page to load, click a drop-down box, select and click a target type from the list (e.g. "Posts"), click a scope (usually "Subscribed"), click another drop-down box, select and and click a date range from the list, and then enter my search. That's a lot of steps.
(I could enter my search before selecting all those other things, of course, but it wouldn't reduce the number of steps, and it would put extra load on the instance host by triggering multiple extra searches before the one that matters to me.)
Also, in certain cases like searching for a community by ID, there's a weird glitch where the search yields no results at first, but clicking the Search button again gets the expected results.
is there anything specific that can be fixed?
Yes, I think the user friction could be improved in several ways.
I haven't made a list of potential search improvements, but just off the top of my head, it would be convenient to have a simple search box in each community's sidebar. Reddit had this back when I was using it, and it made checking for duplicates before submitting an article much more convenient than it is here.
EDIT 2:
It's also inconvenient that the Community search field displays them in example.org/community format, rather than the normal !community@example.org format, and fails to recognize input in the latter format. The slash format might be a little easier to type for a minority of people who expect it, but it's surprising by being unfamiliar to everyone else, confusing by introducing a second format for community links, and counterproductive by defeating copy/paste of a community link from someplace else.
My suggestion for this would be to standardize on !community@example.org format, and allow omitting the ! on input. It's a dedicated input field just for community searches, after all, so the software shouldn't need users to lead with a bang in order to know we're searching for a community. Side benefit: Since this format places the community name before the domain, users could simply start typing the community name without having to remember what domain hosts it, and they would see useful autocomplete suggestions right away.
EDIT 1:
Outside of search, the first thing I would suggest is making Lemmy readable without JavaScript. This would make it usable by people who disable scripts for security and privacy reasons*, and allow more search engines to index it, both of which would expand Lemmy's reach and utility. And, since we're talking about Lemmy as forum software for communities beyond the fediverse, this change would avoid imposing new requirements and vulnerabilities on communities whose web sites do not currently require JavaScript.
*Note that this matters not only for someone's home instance, which might be whitelisted for scripts, but also when following links to other instances, which is pretty common in my experience.
I admire Kent's drive to create something good, but I'm disappointed to see that he still hasn't learned to tread lightly in shared spaces. From what I've seen of the Bcachefs story, Linus has been responding appropriately to his behavior.
Sigh... maybe a few more trips around the sun will help.
I'm not aware of any such communities that run their forum on Lemmy.
I think it could fit, although Lemmy's design as a link aggregation site gives it some rough edges for the purpose we're discussing. For example, the search functions are a bit awkward to use, there is no support for subtopics, and file upload support is (from what I've seen) very limited.
On the other hand, Lemmy's use of Markdown makes it more comfortable for text formatting than BBCode, which is the HTML-like markup used on many forums.
Wine has two forms of WoW64. Old WoW64 uses 32-bit libraries and has been around for a long time.
New WoW64 (first available in Wine 9.0 if built with a special option) works without 32-bit libraries, but is still incomplete. It cannot yet replace old WoW64 everywhere, and even where it can, it reduces performance in some APIs. (For example, OpenGL.)
It will eventually make sense to drop the old one, but doing so now would be premature.
One thing that would be helpful about not using drop-down boxes for static options: Fewer clicks required to set up a search. Each of the drop-down boxes in use now requires the user to:
The first drop-down box (search type) contains only five options, which could be replaced by buttons like the existing Subscribed/Local/All buttons. It would make discovering the available options easier because they would no longer be hidden behind a drop-down, and it would reduce the number of actions required of the user.
The second drop-down box (sort type / time frame) might be a good candidate for this change, too.
As for whether tabs would be a better choice than the button-style approach currently used by Subscribed/Local/All: I'm not sure right now, as I haven't had much time to consider it. But I think things would get messy and possibly confusing if more than one of these input elements were converted to tabs, because it would mean nesting tabs within tabs. On the other hand, using a row of buttons for each category would allow them to coexist neatly, fit the existing visual style, and avoid adding the complexity of another widget type for users to navigate.