Re: introducing deken trends

On 24/08/2025 01:57, IOhannes m zmölnig via Pd-list wrote:
> On 30/07/2025 06:29, Chris McCormick wrote:
> here's a random excerpt of search words (splitting all search queries of 
> the last 7 years into single words, removing duplicates and then 
> randomizing the list; finally picking a handful)

> i just replayed these search-queries, and of the 26 queries, only 6 gave 
> any result.


The ones that give no result are the interesting ones. The user is 
saying "this is what I want" and getting nothing in return.


> looking specifically at multiword queries, here are a few gems (after q 
> quick glance at about 6000 of these queries):
> 
> ```
> sudo apt-get install libgstreamer-plugins-base0.10-dev
> sugn wave
> suma de frecuencias
> super collider
> surround patches
> svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/ 
> pd-gui-rewrite/0.43/startup/
> pd help browser
> alexandre torres porres
> Gem/0.94 (deken-archive for macOS Intel/64bit (macOS10.12+))
> ```
> 
> (i'm afraid, only the very last of these queries returned anything; and 
> only because the "easyflow" library has a [for] object - probably not 
> what the user was looking for)


Ranking the queries that returned nothing by frequency is what is 
interesting.


> so this probably tells us a bit about the expectations of people when 
> they encounter a search field (and thus a bit about the shortcomings of 
> deken as a search engine)


Yep, that's useful information about people's expectations from Deken 
and maybe ways it could be improved to meet or calibrate expectations.


> (especially where no results
>> are found).
> 
> this one might turn out trickier than expected.
> i only have the webserver logfiles, that logs the actual queries and how 
> those queries were served. the only information about the result we can 
> extract from the logs, is the status code (200, also for empty results) 
> and the number of bytes returned.
> obviously empty results require less bytes than many results.
> but there's a bit of a grey area.


Ah ok, understood.


>> 1. Developers review search interest data.
>> 2. Developers build the things that users are looking for that don't 
>> exist yet.
>> 3. Users rejoice.
> 
> do you really think so?
> 
> i would have thought that the Pd ecosystem is more like the classical 
> open source world ("you need something yourself, but it's not available; 
> you implement it; then you share it") rather than (somewhat idealized) 
> commercial software enterprises ("you do a market analysis of what 
> people want; you implement it; then you sell it").
> but that might very well be because of my personal background.


Yes I agree that is how the Pd ecosystem is. I would say that process is 
sub-optimal for non-technical users. I guess we are privileged to be 
able to solve our own problems by writing code, whereas for the vast 
majority of Pd users that's a significant undertaking and they rely on 
volunteer developers to improve things.

I should say, I'm not proposing anybody sell anything.


> but anyhow: no i had no plans to publish statistics about the search 
> terms and downloads.
> most likely because for me this has a "(a)social media" smell, where 
> software contributions get "ranked", making developers of popular 
> packages "better" than those of niche packages.


Yes, agree, that's gross.


> the idea about statistics for empty search terms is interesting, but i'm 
> not sure how much work is required to clean up the data from simple 
> typos / invalid queries, to get something meaningful.

Yep fair enough. I understand it would take work.

Typos and invalid queries are a very useful signal though. They tell you 
where users are making mistakes or using Deken in a way it's not 
designed for. The frequency of common typos and invalid queries tells 
you how sharp the problem is = how bad your own UI/documention is, which 
is causing the issue for those users.

I think even the list of 6000 terms ranked by frequency would be 
interesting (even if you filtered out actual package names).

Anyway, I know you spend a lot of time and effort maintaining these 
systems. I'm grateful for that and definitely not asking you to do more 
work than you already do! It was just a random idea that I thought might 
help end-users of Pd in some way.

Cheers,

Chris.

-- 
https://mccormick.cx/


---
[email protected] - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/[email protected]/message/4SRSPXES4HTSAWSUL7QBH653XGSABXN2/

To unsubscribe send an email to [email protected] mailing list
UNSUBSCRIBE and account-management -> https://lists.iem.at/