A few quick remark about alternativeto.net:
- You are a bit harsher on it than I would be! From a user's perspective, they are my go-to place for "related" software.
- Whether it's the tags or some algorithm behind the scene, their related software work more often than not for me, especially when tried in multiple iterations (related, then related of related). I discovered a lot of gems through that system.
- Also their tags largely have unified terminology; meaning there is only one phrasing used consistently as tag for a particular feature.
- Our "Similar/alternative apps": is the kind of feature that requires the a whole lot of maintenance and manual work beyond the occasional use, which is what I want to avoid through systematic relations. It also works for largely overlapping apps rather than intersecting ones. It is also kind of cryptic (in what way are they similar?) and subjective on what level of similarity warrants it.
If that is what comes across, I realize know I should have been clearer. Please, bear with me as I try to explain the system that I have in mind:
- My target audience is someone like me (and, I believe, many tech-minded people): interested in finding a piece software can do a certain job, but also wants to get their pick of the litter, rather than install the first "youtube mp3 downloader" they find on Google. I want to make it easier to find these tools.
- I also expect that user to be able to do a little bit of the work themselves.
- "extract video from mpeg without quality loss" is something I would never bother adding even if I had the time:
- It is not one use case. It is multiple. A tool that does that would be tagged: ("transcode video" = "convert video to video"), ("mux video" = "convert video to video losslessly"),("video to mpeg"), ("convert to mpeg"; which would also cover images to mpeg), ("avi to mpeg"), ("mp4 to mpeg"), ("flv to mpeg"), etc.
- As I expect the user to have a minimum of tech sense, and as they are searching for CLI and on our site, I would not plan on (nor care to prepare for) them to use a phrase like "extract video from mpeg", it's not about getting a part from a whole. I would expect something like "convert" at the very least.
- See the 2 main reasons for aliases in my previous post, but here, as the user searches for "convert video to mpeg without quality loss", the search engine should pick matches like "convert", "mpeg" (or "mpg"), "loss" and show the relevant tags at the top (my suggestion), and also the entry results with the most relevant tags.
- I want to cover the common terms/phrases, not every unique version. I just want to help the user described above find the proverbial thread.
- The format variations, like "avi to mpeg" would be in the dozens for all-in-one tools like ffmpeg, but I believe that the problem they may pose is not mainly the effort to add them, but the presentation; i.e. hiding them in lists, but showing them if they have a search hit, in the entry's page, under a "more" button, whatever it may be.
Just curious, how do you see that happening? It is not a rhetorical question. I know things can break. I just want to know what you have in mind.if something changes, some entries break and need to be verified/maintained.
Other than it not being an index of tags as I visualize it, I guess I am aiming at 80-90 percent by breaking things into manageable units rather than doing all the variations of tags together. I don't know how our search engine works, but if it indexes keywords from the database or performs direct search, then weighs the results, it will be good enough, I think. I do believe it should do partial word matches though. That will make things easier (like with "losslessly").You can argue the index doesn't need to be complete to be useful. But the fact is, if it's only 20%~30% complete, it won't be very useful. And that 20% to 30% is already a _ton_ of work.
I have to say I do believe that CLI tools fall comfortably enough within what you describe. The pool for Windows is comparatively small and relatively stable (if not fully static). See post #175 above for why I believe that. I wouldn't tackle such a project with even 10% of Softpedia's database for example.What you have in mind could potentially work if the search domain is small, static and exhaustively maintained. That is why I brought up expert systems in my previous post. It turned out to have very limited application precisely because of that. Very few real world applications fall into this category. New information comes in all the time, and it became very costly and laborious for expert systems to remain updated and relevant.
I agree in part . See my previous point. But also, the categories and common use cases don't grow that much with time. The tools may. If we did the framework systematically and adopted a DRY approach (for example, see the last few paragraphs of my post #175 above), changing things en masse should be fairly easy or at least manageable in the vast majority of cases."This idea will never scale."
I would actually like that. I mean, I am invested in this project and I wouldn't presume to tell you what to do with your effort on your site, but I wouldn't say no to both .I think a more fruitful approach will be a better search engine.
Wall of text over!