Opinion Poll: CLI Database Filters and Future

[vevy]

Hi everyone

I was talking to Andrew about filters in the database and he said he can't be motivated to work on it if there is no interest in it and it is not the way he would use search.


What I mean about filters:

• Something like this.
• The ability to filter (only show) tools with (for example) size below 5M, open-source license that allow you to convert csv or compress pdf, etc.
• The idea is to also be able to filter by any other criteria like release date, current/discontinued, ported tool or native Windows, TUI or regular CLI, etc.

The CLI database I envision (and am building) is comprehensive. This means it contains all the CLI tools out there that we can find. This is why I see filtering needed to allow better usage of the database and finding the appropriate tools (as opposed to only including select tools, which already exists elsewhere).


Why I care:

• It could help find a much faster tool.
• Problems may appear later in a tool (or more) and you want to explore alternatives.
• Organize and trim down your tools (find which tools you may already have that can do x).
• Dynamically updated (vs forum posts).
• Easy reference for questions about "what tools are there that can do x"

I want to be able to curate on top of a comprehensive database, to get the best of both worlds! Filters can be in some form or other: shown or click-to-show or in detailed page only or as text, etc.


So, my question to you: Do you have an interest in filters being available in some form?


Impatiently waiting

[webfork]

If the following post seems like much too long an answer for a fairly simple question, it's because I'm trying to try and give a broader suggestion about the CLI database. As I have not been one of it's more active members, it may not be useful and therefore ignored.

Iterative vs. exaustive

The issue of Andrew's reluctance on this topic reminds me a bit of some analysis of the Waterfall and Agile software development models: Agile is much better at delivering features with a quick turnaround that demonstrating value. A client says "I bake cookies, I need a timer that also pays attention to temperatures" and then you see about adding features for your other client who bakes bread.

Waterfall development meanwhile can take months and years to show a result, but doesn't bother responding to small issues and instead tries to make a comprehensive, customizable temperature-timer software for every chef. You don't tell the computer what kind of cook you are, you tell it what relationship you want between time and temperature.

Agile often fails to build smart frameworks and just becomes a bag of disconnect features, where Waterfall projects sometimes get shelved after two years when the technology changes or the project runs out of money.

Intelligent search

Good models to effectively sort, filter, and search through large databases like the one you're working on for are non-simple. With a larger the database and more properties to sort/filter, you're looking at increasingly complex methods that really call for careful thinking and design akin to Waterfall.

The excellent Everything file search program available here on the site -- it handles by showing file results as-you-type so you can increase or decrease your search parameters on the fly. But it doesn't much matter if you have 100,000 log files all with a similar size, name, and number. You'll need a smarter search program to sort through that data and find what you're looking for. That might require an output of time and energy to either develop or buy a program to sort the data, or you could try to pare down the database to reduce the total number of results.

As you've noted that reducing the size of the database isn't really an option (it's going to be comprehensive) it seems reasonable that you'll have to start with a simpler filter. That's not to say that additional, more involved filters/sort tools couldn't be added later.

Summary

Is it possible to do something iterative (more Agile), meaning you have a few filters and then see how people use it, or even come back later and try to add more or do something more complex (akin to Waterfall)? Maybe focus on building up the database and working within available tools, addressing more complex analysis tools down the road?

[SYSTEM]

What I mean about filters:

• Something like this.
• The ability to filter (only show) tools with (for example) size below 5M, open-source license that allow you to convert csv or compress pdf, etc.
• The idea is to also be able to filter by any other criteria like release date, current/discontinued, ported tool or native Windows, TUI or regular CLI, etc.

Honestly, your filters don't sound that useful to someone who is looking for a CLI tool.

For size, filtering by size wouldn't be useful. You'd rather find the smallest tool which meets your needs, not ones which fall below an arbitrary threshold.

Open source license would be a plus but usually not a requirement for a user. If the tool is free and does what you want, it's usually enough.

Release date and current/discontinued are potentially useful, but maybe not so for CLI tools. CLI tools are usually quite mature and don't really need updates.

Ported tool or native Windows: why would you care about that?

TUI vs CLI: those two UI paradigms are usually encountered with completely different tools. You rarely find cases where you can do the same thing with multiple programs, some of which are TUI and some CLI. (TUI is a much better fit to, say, text editors like nano.)

As such, I'm siding with Andrew here. Filtering functionality would take effort to implement and be of little use.

Agile often fails to build smart frameworks and just becomes a bag of disconnect features, where Waterfall projects sometimes get shelved after two years when the technology changes or the project runs out of money.

Agile projects often do much better than you envision here.

The primary point of agile is to involve the client with development of the software. (Both models are primarily designed for the situation where a software shop develops something for internal use of their client.) The point is that once the client sees what the software is like in practice, they can better identify what they actually want and steer development to the right direction.

As a concrete example, Angry Birds Stella was developed with agile style and I was one of its programmers. The original plans called for shooting the birds with a swing instead of a slingshot: however, when we tried it in practice, we found that it didn't work as well as the traditional slingshot and we scrapped the idea. If we had used the waterfall model instead, we'd have instead stuck with the original plan and made the game worse. (In the end it didn't matter because the game was financially a failure anyway. ¯\_(ツ)_/¯)

There is nothing that would inherently make an agile project "a bag of disconnect features".

Waterfall projects indeed have a risk of getting shelved in a late stage. One of the problems of the waterfall model is that you need to finish the entire project before you deliver anything. If the money runs out before that, tough luck.

Is it possible to do something iterative (more Agile), meaning you have a few filters and then see how people use it, or even come back later and try to add more or do something more complex (akin to Waterfall)? Maybe focus on building up the database and working within available tools, addressing more complex analysis tools down the road?

This is more for Andrew to answer, but from what I can tell, filters can indeed be added incrementally. Being able to filter by one criterion requires that there is a DB field for that criterion (e.g. for size, the existing size field can be used), UI to allow maintainers of the DB to edit it and search UI. The actual filtering would merely require adding another criterion to the SQL statement. It's the UI which is the highest amount of work.

[vevy]

Thank you both for interesting point.

I should clarify a couple of things:

• I am assuming that filters as text is fairly simple to implement. map a text (e.g. dev:"string") to a php parameter (dev=string) to an SQL query. Some may require an extra conversion step (e.g release date), but most should be Boolean whic is even simpler. Correct me if I am wrong.
• Filters can indeed by implemented as needed and in steps, but since there doesn't have to be a UI (not even checkboxes), I wouldn't limit them since many useful relations can be had. It is definitely a solution, though.
• Badges like TUI tools function both as a quick visual indicator for the type of tool and (as clickable links) filter to only TUI tools aka their own "category" without having to add both visual badge and category to each such tool.

-----------------------------------

As I have not been one of it's more active members, it may not be useful and therefore ignored.

It is useful. Thanks for sharing.

As you've noted that reducing the size of the database isn't really an option (it's going to be comprehensive)

I am not really dictating it . I was just bitten before by my attitude of

• "This tools is redundant and covered by other established tools. I am not going to stop at it", only to find that it actually had a USP but I don't remember its name anymore!
• "This tool X seems to complicated and over-designed. Tool Y is much simpler and meets my needs", only to realize that tool Y had much more more to offer beyond the learning curve.

I just don't want to make another CLI directory curated by "my-current-thinking"™.

Is it possible to do something iterative (more Agile), meaning you have a few filters and then see how people use it, or even come back later and try to add more or do something more complex (akin to Waterfall)? Maybe focus on building up the database and working within available tools, addressing more complex analysis tools down the road?

I could do that.

[vevy]

For size, filtering by size wouldn't be useful. You'd rather find the smallest tool which meets your needs, not ones which fall below an arbitrary threshold.

It certainly can be flexible. Arbitrary "Small, medium, big" or size><n B/KB/MB.

Open source license would be a plus but usually not a requirement for a user. If the tool is free and does what you want, it's usually enough.

FOSS is important for many people on principle. I, for one, use freeware but prefer open-source.

Release date and current/discontinued are potentially useful, but maybe not so for CLI tools. CLI tools are usually quite mature and don't really need updates.

I generally agree, but sometimes you'd want to contact the developer about something you need, so discontinued is a deal-breaker.

Ported tool or native Windows: why would you care about that?

Because there are differences between Unix and Windows environments. For example forward/backward slashes (under UnxUtils), wildcard expansion, etc.

These definitely have consequences on usage when it comes to ported tools and can lead to unexpected results!

TUI vs CLI: those two UI paradigms are usually encountered with completely different tools. You rarely find cases where you can do the same thing with multiple programs, some of which are TUI and some CLI. (TUI is a much better fit to, say, text editors like nano.)

I mostly agree. Perhaps I should have chosen a better example. Still, there are areas of overlap that you may want to decide on what kind you want. For example, "edit text", list files, network tools, etc.


The pattern in all these is that allowing filters lets everyone cover their own use cases.

I was one of its programmers.

Nice!

The actual filtering would merely require adding another criterion to the SQL statement. It's the UI which is the highest amount of work.

Like I said above, UI can wait. Something like this works for me:

[Andrew Lee]

I just realized a lot of my arguments were via PM with vevy, so I shall summarize my position on this below.

I think we have 3 options going forward:

a) Stop the experiment, shut down the CLI site, I send vevy an export of the database.

b) Let the CLI site go live as is. We will see the respond and add stuff when there is demand for it. If no one finds it useful, we can still shut it down later.

c) Leave the CLI site as is, and wait for more interest or feedback.

- - - - - - - - - - -

As for features of the CLI site, I am basically not in favour of:

1) Being comprehensive. We shouldn't waste space and bandwidth on "mkdir" or "ls", but instead should list only entries that are useful to us eg. youtubedl, ffmpeg, imagemagick etc. Also, no need for parent-child hierarchy.

2) Tons of filters and badges. I prefer the KISS approach. Also the cost-benefit matters. An ex-gf used to insist that we sort incoming correspondences into 20 different categories so that they are "easy to find". But we only need to find anything at all maybe once or twice a year. So all that effort categorizing _every_ incoming letter is simply premature optimization.

3) Grand unified theory. Basically, having some grandiose scheme in mind that nobody finds useful. Far better to take an incremental approach and incorporate feedback along the way, than to end up with a bridge to nowhere.

I am simply not convinced by vevy's argument that the CLI site won't be useful if (2) is not implemented. That smacks too much of (3)

[vevy]

From a,b and c:
b would be the worst. It is not complete either way and would satisfy no-one.

------------
As for 1,2 and 3:

1. A personal preference or a formal decision?

2. Filters are an option. Don't use them? Ignore them!

3. I don't ask for many other requests now. Basic implementation of filters is needed for comprehensiveness. Why comprehensive? See above!

Why only list tools most already know? There are a lot of hidden gems out there! And when imagemagick fails, do you know that graphicsmagick exists? Do you know that ffmpeg can do much of the same? A forum thread for every possible task? Do you know about rxrepl or hideexec or so many excellent lesser known tools?

When a "simple" tool like mkdir or echo breaks your script because of weird behavior, where else lists alternatives you can try one by one until you find the one that works correctly?

You want to see if there is interest in my ideas, but as you can see above, people can easily get the wrong idea or miss the point because they didn't see them in action!

A badge for TUI helps the user identify the tool quickly/click to see other TUI tools. Is that too difficult to make?

[webfork]

I definitely don't mind someone chasing that goal like vevy's, as it's certainly a worthy mountain to climb. I appreciate an ambitious project and know that a lot of programs will get a spotlight along the way. But I also understand the hesitation to chase an advanced structure for organizing and searching a very incomplete database.

Would it be possible to shore up what's available now, prepare it to open it up to the public (and participation by the same group that can edit the GUI database) and see where it goes? The "let the CLI site go live as is" option? Then add options like afterwards if it TUI badge or other elements if it makes sense? I've already benefited from the non-live site and can't imagine that it being incomplete would be harmful.

[vevy]

prepare it to open it up to the public

Because of this:

searching a very incomplete database.

Also, while it is Andrew's call in then end, we are in a bit of catch-22. He won't prioritize these requests until there is enough public interest, and I can't begin to get public interest when even knowledgeable members like SYSTEM don't seem to get the benefit based on my description alone, even though there are real benefits.

I see very clear benefits to being comprehensive (which I mentioned from the very beginning). I mentioned here and elsewhere, yet I feel these are not getting through to Andrew because he expects the database to be curated only.



-------------------------------
Or like Reddit search.

[Andrew Lee]

Why only list tools most already know? There are a lot of hidden gems out there! And when imagemagick fails, do you know that graphicsmagick exists? Do you know that ffmpeg can do much of the same? A forum thread for every possible task? Do you know about rxrepl or hideexec or so many excellent lesser known tools?

When a "simple" tool like mkdir or echo breaks your script because of weird behavior, where else lists alternatives you can try one by one until you find the one that works correctly?

I fail to understand how you are going to solve the above problems by having filters, badges, parent-child etc.!

The first problem can be solved by the "Similar/alternative tools" field, or asking in the forum for recommendations. Any feedback can then be subsequently added back into the "Similar/alternative tools" field.

The second problem can only be solved by asking in the forum. I seriously cannot see how every unexpected or weird behaviour of existing apps can be thoroughly documented and easily searched, unless I have missed something. The best tools we have for this currently are Stack Overflow and Google searches on various niche forums.

[SYSTEM]

Or like Reddit search.

Umm, Reddit search is notoriously unreliable. It's a long-standing meme to make jokes about how terrible it is. Example.

[vevy]

Or like Reddit search.

Umm, Reddit search is notoriously unreliable. It's a long-standing meme to make jokes about how terrible it is. Example.

Yeah, I know! . But it is unreliable because it fails at heuristics and AI (aka The Google). It is surprisingly exact when you want precise results.

In any case, I was talking about about the options it provides. These work pretty reliably for what they do. For example, "title:".

Google provides these too (intitle:, inurl:, date ranges, alternative keywords, etc).

[vevy]

OK. Lets untangle what we have:

• Comprehensiveness
  
  Pros:
  • There are a lot of good less-known tools.
  • There are tools with unique selling points that are not immediately apparent.
  • There is no other such database on the web.
  • General search can often fail to get you the tool you want/need easily or at all.
  • Direct asking for help can fail to solve the problem:
    • No responses (search.php?search_id=unanswered&fid[]=1&fid[]=2&fid[]=5). (Didn't know or didn't bother)
    • A good suggestion can appear years later (stackoverflow for example).
    • Answers that fail to address the question.
    • etc.
  Cons (Pros of curated only):
  • A lot of work to do.
    • My solution: I already have a ton of these tools and plan to add them over months or years.
  • Can be confusing.
    • My solution: Good default sorting on search and listings (title matches, votes, recency, download clicks, etc)
    • Also, hide (administrative) / demote (democratic) less than average tools.
  • Diluted-looking database.
    • My solution: The above. Also, outweighed by the benefits in my opinion, so you'll probably just get used to it the same way you get used to pages of Google results?

If I missed something or a solution is not convincing, let me know!

------------------------------------------------------------------------------------

• Filters (as a principle):
  This is dependent on the above; meaning that for a curation-only database, filters do still help, but are less important.
  
  Pros:
  • Make the database more manageable.
  • Allowing users to show only tools with the aspect they care about.
    • Sub-point: allowing the user to combine filters in whichever way matches their unique use case.
  • Lesser need to make threads asking for general tool recommendations (What tools allow me to do X).
  • Allowing for easier answers of such question: "See here."
  • Dynamically-updated lists. No need to manually update multiple forum lists (usually with descriptions for each) when a new tool comes along. Just specify what the tool does in "use cases".
  • Dynamically-sorting lists. Good tools that have more votes/downloads/recent updates, etc surface to the top automatically. No need to update forum topics. Also, more democratic/less subjective while still allowing personal forum lists for those who desire.
  Cons:
  • Some filters are more difficult to implement that others.
    • My (partial) solution: Start with text filters. Do the easier one first.
  • UI takes some time and effort.
    • My solution: See how the text filters go first.
  • Can be confusing for the users.
    • My solution: Text filters first. See the response. Focus on unassuming, intuitive design (e.g. clickable badges ).

[vevy]

Part 2.

Specific Filters:

• Size: Some users prefer small tools.
  When faced with two tools that do the same function, I tend to associate smaller size with better coding quality and "lightness".
• License: FOSS is important for many people on principle.
• Release date: For example, to exclude tools without support for standard released on year YYYY.
• Developer:
  • See if a developer you like has a particular tool (e.g search "tool name" and filter by dev.
  • Quickly link to all the tools in the DB by a particular developer.
• TBC.

---------------------------------------------

Status/Badge Filters (as a principle):

• They serve as a quick visual indicator for the type/status of tool. Being clickable seems like a natural and intuitive way to filter by them For example, click on TUI to only show TUI tools, instead of also creating a category for TUI tools.

---------------------------------------------
Specifc Status/Badge Filters:

• Current status: For when you want to contact the developer about something you need, so discontinued is a deal-breaker.
• Origin: Ported vs native. Because there are differences between Unix and Windows environments. For example forward/backward slashes (under UnxUtils), wildcard expansion, etc. These definitely have consequences on usage when it comes to ported tools and can lead to unexpected results!
• TUI vs CLI: Sometimes, there are areas of overlap that you may want to decide on what kind you want. For example, "edit text", list files, network tools, etc.
• TBC.

[vevy]

The first problem can be solved by the "Similar/alternative tools" field, or asking in the forum for recommendations. Any feedback can then be subsequently added back into the "Similar/alternative tools" field.

If you remember, I touched upon this field here. In short: manual, harder-to-maintain, vague, and subjective.

Also, the relationship model with use cases is one-to-many. With "Similar/alternative apps", it is many-to-many which is much more difficult.

I seriously cannot see how every unexpected or weird behaviour of existing apps can be thoroughly documented and easily searched, unless I have missed something.

I am definitely not attempting that. I am for making all the tools (as much as I can) with the same function readily available so that you, the user can try them out. I only plan to make use cases for the common tasks.

The second problem can only be solved by asking in the forum.
[...]
The best tools we have for this currently are Stack Overflow and Google searches on various niche forums.

It can work, but please check my answer above (under pros of comprehensiveness).