CLI Database Discussions

[Andrew Lee]

PS. I see the default status of a request to be KIV, so you don't have to add it manually. Just if you approve/reject etc.

The KIV is more to remind myself that I have already been through that item.

A KIV status is also an indication that the request needs to see more support from the community.

[Andrew Lee]

Secondly, I think we do not need a single entry for basic CLI utility tools like mkdir. I think just the collection like Busybox and Yori is sufficient, but perhaps that's just me. I think once private listings is no longer the default view, this should be okay though.

Apps like youtube-dl and ffmpeg are listings I would expect to see.

I second this.

Background: I took some time off just now to approach the CLI site as a user, not as a programmer i.e. I imagine I have a problem to solve, and approach the site as a resource to answer my questions.

My personal opinions:

- The current database gives me a feeling of being an encyclopedia. You know, the thick tomes that your parents bought and let sit on the bookshelf to look impressive, but don't actually _do_ anything. They just contain pages and pages of useless information that look impressive, but not particularly useful for anyone.

- The parent/child hierarchy (which leads to single entries for mkdir) is not very effective. If I am looking for a tool to do something, a simple keyword search would have already displayed the parent entry, and I would have just gone off to donwload the app and try out that particular CLI tool.

- If I were looking for why a particular tool is not working as intended (like that odd behaviour of Window's clip), a forum style resource is more suitable for debugging and workarounds, and would have suggested alternative tools.

- If I were looking for how to use a particular tool to achieve some function (command line options etc.), a forum or tutorial style resource is more useful.

The main TPFC site, with all its imperfections, actually "feels" more useful. I have used it on more than a few occasions to find the right tool to solve a problem, most recent being RIOT, which was found using "image optimization" and narrowed down through reading related forum posts.

Although the main database is very patchy in terms of covering the entire universe of portable freeware, it represents (mostly) the stuff that people care about. And the conversation that goes on in the forum, I feel, is far more important than the database itself.

[Midas]

... The conversation that goes on in the forum, I feel, is far more important than the database itself.

It is. (At least for me...)

Don't get me wrong, the database is very convenient as a primary search tool -- but what makes my mind is user feedback and my understanding of a program and that's where the forum excels.

Also, most of what you just noted.

[vevy]

The KIV is more to remind myself that I have already been through that item.

A KIV status is also an indication that the request needs to see more support from the community.

I see. Fair enough.

- The parent/child hierarchy (which leads to single entries for mkdir) is not very effective. If I am looking for a tool to do something, a simple keyword search would have already displayed the parent entry, and I would have just gone off to donwload the app and try out that particular CLI tool.

I don't get that part.

- If I were looking for why a particular tool is not working as intended (like that odd behaviour of Window's clip), a forum style resource is more suitable for debugging and workarounds, and would have suggested alternative tools.

I actually mostly agree. I wouldn't put these details in the entry, and I would discuss them in the forums. In my mind for the database, I separated comprehensiveness and curation. Curation can go from highlighting the better tools to a totally new DB (undesirable to me) and a range of things in between. This is a wide field for discussion.

- If I were looking for how to use a particular tool to achieve some function (command line options etc.), a forum or tutorial style resource is more useful.

This is where the "mostly" in mostly agrees comes into play. Much of what I did and am working on is towards automating the boring, enumerative portion of this, Leaving the human element to what computers can't do well (as far as I can instruct them ).

It is very difficult to keep a tutorial for suggesting the tools for all those use cases, or even the main ones. Well, you can, but it is too much work and more difficult to update and maintain. Let all the "make directory tools" or "echo tools" be one click away. There is a lot of value in that.

The main TPFC site, with all its imperfections, actually "feels" more useful. I have used it on more than a few occasions to find the right tool to solve a problem, most recent being RIOT, which was found using "image optimization" and narrowed down through reading related forum posts.

Although the main database is very patchy in terms of covering the entire universe of portable freeware, it represents (mostly) the stuff that people care about. And the conversation that goes on in the forum, I feel, is far more important than the database itself.

Again, I agree. But please remember that we are midway. It is not done yet! It is still in the amorphous/ugly phase where it is neither solution! We are close to something workable. Help me reach the first finish line!

... The conversation that goes on in the forum, I feel, is far more important than the database itself.

Keyword: conversation!

Don't get me wrong, the database is very convenient as a primary search tool -- but what makes my mind is user feedback and my understanding of a program and that's where the forum excels.

Nicely summed up. I would add that some of the user feedback can be expressed non-verbally: e.g. curation/filtering by voting, liking, etc. We already do that!

[vevy]

Tell you what Andrew, how about lowering your guard for a little while, and spoiling me with implementing my requests*? I will play with them, ask you to change some, delete some, add some more, and if you are not convinced with the end result, we'll argue some more! </homersimpson>


---------------------------
* The reasonably doable ones. If a request has a "p" in the priority, it means I don't need them currently.

[Andrew Lee]

- The parent/child hierarchy (which leads to single entries for mkdir) is not very effective. If I am looking for a tool to do something, a simple keyword search would have already displayed the parent entry, and I would have just gone off to donwload the app and try out that particular CLI tool.

I don't get that part.

Let's say I am searching for a CLI that makes directories. So I enter "make directory" and out pops a list of collections (since they already have the short description for the individual CLIs) and individual entries that fits the criteria. I am probably going to simply download the first collection and try the "mkdir" within it. If it solves my problem, I move on. If it doesn't, I will try the second collection. I don't see the point for the individual entries if the collection already matches my search.

[Andrew Lee]

- The parent/child hierarchy (which leads to single entries for mkdir) is not very effective. If I am looking for a tool to do something, a simple keyword search would have already displayed the parent entry, and I would have just gone off to donwload the app and try out that particular CLI tool.

I don't get that part.

Let's say I am searching for a CLI that makes directories. So I enter "make directory" and out pops a list of collections (since they already have the short description for the individual CLIs) and individual entries that fits the criteria. I am probably going to simply download the first collection and try the "mkdir" within it. If it solves my problem, I move on. If it doesn't, I will try the second collection. I don't see the point for the individual entries if the collection already matches my search.

Tell you what Andrew, how about lowering your guard for a little while, and spoiling me with implementing my requests*? I will play with them, ask you to change some, delete some, add some more, and if you are not convinced with the end result, we'll argue some more!

It's not about lowering any "guard". It's just that when you are working on something, you are constantly evaluating if you are on the right track and not just blindly charging ahead!

Can you explain how adding more badges, or uses cases, or links etc. is going to change the overall prognosis? Yes, it will make things look prettier and even more verbose, but how are they actually going to make the system useful?

The same fundamental problem is there from the start, and I don't seem to be the only person who has pointed it out. This is designed to be more like a encyclopedic showcase more than anything else.

If I am indeed missing some key idea(s), please share.

[vevy]

Ahh! Is a little blind faith too much to ask? </SimpsonsSundaySchoolTeacher>

Two important principles:

• Making a comprehensive database before curation. It actually leads to good curation.
• Filtration makes the comprehensive "encyclopedic tome" very usable.

[...] I am probably going to simply download the first collection and try the "mkdir" within it. If it solves my problem, I move on.[...]

Then good for you! Remember that if we are designing only for the casual user, this site wouldn't exist! "Portable software? Pfft.. just run an installer and click next next!"

If it doesn't, I will try the second collection. I don't see the point for the individual entries if the collection already matches my search.

That's part of the missing picture. Search shouldn't just default to "newer first". How I see it:

• Use case matches first. In this case, <create directory>. You click it to see the tagged tools.
• Priority to direct title matches.
• Priority to "curated" (more votes, editor's pick, etc)
• Rest of the matches (including keyword, description matches) later.

It's not about lowering any "guard". It's just that when you are working on something, you are constantly evaluating if you are on the right track and not just blindly charging ahead!

That's "guard"! It is not a bad thing generally. I am just asking for a little less of it for myself! I can accept that you may not have the same approach as a user as me when it comes to using a database, but let me showcase mine!

Can you explain how adding more badges, or uses cases, or links etc. is going to change the overall prognosis? Yes, it will make things look prettier and even more verbose, but how are they actually going to make the system useful?

Of course! It is filtration. Take this thread as an example.

There must be somewhere on the TPFC website a Windows version of the Unix command-line CAL.
But I could not find it, so I had to go online.

This is solvable by a single link to the use case. My mind is heavy with ideas and visualizations for the database listings and search pages, etc. But it is difficult to describe everything, even as a mock-up.

For example, Clicking a badge will get you to only such tools (e.g. TUI). Think a bar at the top of any listing/search page (with the badges next to each other) where you can filter e.g. search "calendar" + unix port. You don't need to make a thread just for that. It also naturally lends itself to every possible situation.

The same fundamental problem is there from the start, and I don't seem to be the only person who has pointed it out. This is designed to be more like a encyclopedic showcase more than anything else.

Let me show you! That is what I am asking! You don't have to do the overly complicated stuff. I will try to make more mockups, but it is much easier to work with the real thing!

[vevy]

Here is a rough one for search "directory". Some terms could be clearer or fit better in another group, but you get the idea.


Forgot to say that individual entries make such filtration/tagging easier and more useful. You can filter by size, better use case and category management and usability, etc. Also, clearer search results (ordered simply but properly).

Working on that mock-up made me see that I can probably forgo the "Win Package" badge and just use "Package" for everything. Since we made things failry atomic and normalized (instead of just used text in the description), changing such a thing would be trivial. This is why I want to try out the ideas/new fields etc in practice. They will show their value then.

[Andrew Lee]

It feels like this has evolved into a shouting match between me and vevy

Can someone else talk some sense into either me or him/her?

I was like staring at the previous mockup and squeezing my brain to try figure out how any of those things are useful at all. Sorry, it's not working for me.

There is a Chinese saying (I am paraphrasing here..): You don't need to see the whole animal to decide whether it's a leopard or pig. It seems fitting for the situation we have here.

[vevy]

I want something like this: https://www.imdb.com/search/title?user_ ... ating,desc

I think it is useful for finding the best tool for a task as much as it is useful for finding a good watch.

It is easy to a find a curated list of best David Attenborough documentaries. But do you expect to find one (relevant and recent) for every other person that piques your interest? This is a machine's job. Then humans curate and discuss.

Do you really see no value in this?

[billon]

vevy is a girl?

[vevy]

vevy is a girl?

Nah!

[freakazoid]

(I edited this post after I looked at vevy's screenshot some more)

The search page that vevy mocked up is something that the main TPFC search page could use. Andrew, would it be possible to add a select dropdown to filter searches by category or multiple categories? That way, we could use the existing categories functionality to power the CLI search and we wouldn't need to add new taxonomies for Entry Type, Status, Origin and Tool Type.

[Andrew Lee]

Andrew, would it be possible to add a select dropdown to filter searches by category or multiple categories? That way, we could use the existing categories functionality to power the CLI search and we wouldn't need to add new taxonomies for Entry Type, Status, Origin and Tool Type.

Care to elaborate? What you are describing doesn't seem like what vevy is aiming for at all.