I love that this goes both ways. What other pair of Linux distros mutually offer first class support for using each other's package managers alongside their own??
It's a cute little testament to the fundamental strengths of the functional package management paradigm, as well as helping users on either side of the fence fill some gaps in a pinch and providing more/easier opportunities to compare notes and inspire improvements.
Guix comes with a service for using Nix packages[1], if that's what you want. It's very simple to setup, and would allow you to use Nix's Firefox package without any issue.
Thank you for taking the time to share all this great feedback! Appreciate it :)
I agree with all your points. I will only comment on a few, but will go through each of them and fix what I can.
> I assumed it didn't matter but turns out right goes back, but after you go back, left swipe gives you a new article instead of going back to the article you went back from
This is actually a bug, it's supposed to go forward but it seems `window.navigation.canGoForward` is not implemented in Safari. I'll add a workaround, and then think about better ways to navigate between articles.
> preload the next page
This is supposed to happen already (the API is queried in advance), but it might be slow due to updating the DOM. I'll see if there's a way I can pre-render the next page (might work well with your visual feedback suggestion).
> does the algorithm track how I scrolled the page, which words I dwelled on etc.?
No but I'd like to try something like this and see if it helps the suggestions.
> letting people see more of what you track, like what articles they've read and show them long lists of related articles for the current article, so that you can see that you're making progress instead of feeling that it's an endless pit of information
That's a great idea! Once I've fixed the numerous bugs I'll try and add some interesting/fun stats.
> Will you open source this?
Yes! The only reason it's not already open source is because I'd like to clean up the code a little first.
I should've said "preload images for the next article", I realize now (after using it on a spotty connection) that you do preload multiple articles (you made a good choice for the amount that I didn't notice my spotty connection that much), but just not the images. Maybe you should preload multiple pages but only preload images for the next page to save data.
More thoughts after using it again today:
- try disabling the network, scrolling right to the end of the preloaded articles and then re-enabling the network, I think it won't load more articles you'll just be stuck on a white screen with no feedback. At least I managed to get it stuck in this mode somehow and I had to refresh the page manually
- remove the # from the url
- if it's not hard to do, make it multilingual. at least for the top, let's say, 12 languages. en.wiktok.org should just redirect to wiktok.org though
- I sometimes want to read a specific article while reading a recommended article, but there's no way to do that, such as an article search (I almost hesitate to bring this up because I like the clean interface without this feature)
- let me create an account to not lose my data (also, let me log in with my Wikipedia account specifically and extract the articles I've edited to gauge what I'm interested in, although careful here because I personally edit things I'm knowledgeable in or things I care about not being wrong, not necessarily interested in reading more about)
- I've seen the article for ISBN about 4 times now
- the recommender needs to be making more varied, exploratory recommendations. But obviously the recommender is the hardest, most important part of this whole thing.
- for long term users you can start showing articles they've already seen if you record a timestamp for when they saw an article
- Wikipedia really is nicer without the citations if you're trying to read a lot
- I end up opening multiple WikTok tabs when I open links on some article, it would be a nice detail to synchronize recommendations across tabs with that in mind. Maybe you do this already, but for example I might open a new tab, then swipe left for a recommendation, close the tab and go back to the first tab I came from and I shouldn't get the same article recommended there again, even though it might already be preloaded. Though here you will have to make sure you avoid preloading the same recommendation 10 times if I have 10 tabs open every time I view a recommendation in one of them that they might all have preloaded
Data sources:
- articles have a short description... on the one hand the short description could help me decide if I'm interested in an article faster, on the other if I end up reading the entire article reading the short description was a waste of time. Maybe it could be a totally separate "blitz" interface of an endless scroll of these short descriptions and I tap on articles I'm interested in
- Wikipedia articles are categorized (most articles belong to some Project and also have a list of categories they belong to) are you making use of that data? Though in my experience that data isn't that reliable and using it directly (instead of as a signal for the recommender and to seed the algorithm's learned categories) would not be the optimal recommendation. When you install TikTok it lets you scroll to start and to get the idea of the app, but when you create an account it shows a list of categories and asks which ones you're interested in to bootstrap, this could be good here too, there's some topics I'd like to read about but the algorithm hasn't started suggesting them yet
- Wikipedia publishes view counts of articles, you could also use this data point in your recommender
- user location: a large part of Wikipedia is geographical articles. These are largely useless, but while there's no chance I would be interested in learning about regions of Finland (what I was recommended once), I might be interested in the places around me, possibly all subdivisions of the country or state I'm in. The whole thing with tiktok is that users want (for some definition of "want") to give you all their data, as long as the recommendations are good.
As I mentioned before, when you detect that I seem to be interested in a certain group of articles, there could be a natural order to show those articles in, these "runs" could also be user curated or maybe use Wikipedia categories somehow.
If this is a project to help people read Wikipedia exhaustively, you could display some kind of time estimate of how long it will take to read everything I seem to be interested in
Another idea (related to my suggestion for doing this for books instead of Wikipedia) is to make this a kind of "jumping off point", where the article is the preamble for the topic. So when I scroll to the end of the article and then scroll even more, past the article, it would open some resource that's more in depth, like a book or a scientific paper or a webpage. Deciding which resource that would be is a complex editorial decision and a lot of work and there might not always be one, you could for example look at the sources of an article and somehow gauge which one is the most important one, you could look at the External Links section if it exists (but they usually suck because no one reads them so no one curates them), you could seed it using these methods but then ultimately let users curate the decision (now we're talking about of course reimplementing Wikipedia), you could have a list of options and choose somehow using what you know about the user and if you can determine why they're interested in this topic. If it's not a freely available paper/book (which it never will be), you could have a setting to open a Google search with the title or to just show the DOI or ISBN number (and users could choose to run some code that does something with that information). Ideally it would open a specific page in the book though, because I don't want to scroll past "this page intentionally left blank" and a book can be authoritative for multiple articles but be 1500 pages long.
Scrolling down after the article could load articles in the same category as the current article. This would work well for geographical articles, if I get a page about a water canal in Germany and I decide I want to read about every single canal in Germany (or every type of skin disease or every type of sorting algorithm or every type of butterfly, etc.), I would keep scrolling down instead of left, then after that category is exhausted it would start showing some broader category, i.e. canals in Europe and then the world and then waterways.
One way to choose which category to use would be looking at all the articles in all the categories of the current article and finding the category that has the most repeated articles (for example if a page belongs to 5 categories, use the category that has the most articles that also belong to all 5 categories), essentially the most specific one and then keep getting more generic. A second pass would be learn to throw out overly specific, uninteresting categories like "Canals opened in 1922". A third feature would be to magically figure out which category I'm interested in. Another feature would be to show the category I'm currently scrolling and what fraction of the articles in it I've read, this would also be a good place to make it a clickable drop-down that lets me choose to follow a different category, but that's antithetical to the TikTok idea.
P.S. love the name but TikTok's lawyers will probably tell you to change it if this gets any traction.
Not quite. I don't think my setup is very special, so, I describe it in more detail:
My company provides me with the laptop, VPN connection to the office network, which, in turn, connects to our (tiny) datacenter, where actual work happens (i.e. compilation, CI, testing, all happen there).
Sometimes I work from the office, other times from home.
The datacenter has several "jump" servers having distinct roles, there is a server that lets you connect to our OpenStack cluster, another has some resources to run a bunch of unrelated VMs in KVM, yet another one is the storage for all kinds of artifacts, s.a. Linux packages, Linux distro images, Docker images for development and testing, and then there's CI cluster.
So, my typical setup is like this: I have an ansi-term buffer per jump server. The jump servers are running my tmux session. So, every time I have to move my laptop to a different network (eg. going home from office), I reconnect to the jump servers and to the tmux session they were running so that I can pick up from where I left off before disconnecting from office VPN.
If TRAMP could have a persistent session, maybe, I'd not use tmux (I don't like that I have different commands for managing buffer appearance and clipboard). On the other hand, tmux is more universally used (at least in my company), so that sometimes I can simply ask a colleague to connect to my session, if they need to investigate some strange situation (only a handful of people are using Emacs, but almost everyone would be able to use tmux at where I work).
Might be worth looking into detached.el for persistent sessions? Tbh I haven’t set it up properly myself, but I did watch the talk from EmacsConf and I plan to look into it further.
Thanks for this! Unlike a stereotypical Emacs user, I haven't touched my configuration in a few years. Guess, I'll need to do some cleanup / research in the near future.
[1] https://wiktok.org/