Eventually I have to move to the Web version when the Desktop version gets out of support. Hopefully we can all move the the Web version when enough features are added. I believe you are working on UDF for examples.
So am starting to use the Web version in view mode lately to see how it works, what I am missing and problems I run into.
On of the things is a usability thing. The infinite scroll is an absolute disaster for me if I don’t change my way of working when I move to Web (little exaggerated 
).
- Quickly sweeping, with the scroll bar, through my collection is not possible.
- Using the End button on my keyboard only brings me to the last entry that is loaded, not to the last entry of my complete list
- Applying filters resets the list so not all results are loaded, only the first x items.
- You already implemented the up and down arrows to browse to each entry. Which is great. What I am missing is if you start typing it does nothing. In the Desktop app I often use this to scroll down to the right element in the list without actually filtering.
From a performance point of view the app is already pretty fast (kudo’s for that). Is there a particular reason to only load the first 100 results? Why not everything? Or 5000?
If I check each Letter filter I only have 11 letters with less than 100 results.
For me this are not dealbreakers. Just sharing how I would like to use the application. Maybe you see some nice idea’s you didn’t think about.
Because that would be much much slower 
Loading everything in one go would generated a HUGE HTML documents which would
- take a long time to generate on the server side
- take a long time to download to your browser
- would possibly cause severe slowdowns on everything because of the huge document the browser needs to manage.
Lazyloading part by part in an infinite scroll is THE way to go for web-based applications.
If you are not planning to switch to the Web version, maybe it is best to let it rest, forget about it and just use the desktop software?
I am a developer/software architect myself an from an architectural point of view there are 2 solutions.
The first solution is the solution you have chosen. Making small and quick calls to load only a small part of the total data set. This is the easy solution in my opinion, but not by default the standard way to go.
The alternative is to load all data into the web client. Then make the app work on the data that is loaded into to client. This has a couple of advantages. Because you can do almost everything client side it is even faster than making backend calls to load parts of the data. You can do all the filtering completely client side. Of course it also has some drawbacks like you already mentioned. Loading the initial dataset can take more time if not done properly. And if done properly I am convinced it can reduce the total load on the backend. What is also possible: when the backend is down you can still load the whole database in read only mode (you will miss images, but data wise it is possible).
At the company I am working I implemented both solutions.
But I can understand why you have chosen this solution. It is the easiest and it works fine. It only has some drawbacks like I mentioned in the Topic start.
You see it as switching to the web version as an all or nothing. I see it differently. I assume the point on the horizon is that support for the Desktop version will be dropped so we are forced to move to web. At some point it will be too expensive to maintain. I am complaining about the desktop version for years because it is painfully slow at some points. Some of those issues you fixed in the past (loading the YouTube preview was one of the issues). But the desktop version won’t be improved anymore. So my first experiences with the web version are quite convincing (performance wise). I am convinced at some point in time I don’t need the desktop version anymore. Up till then I want to give as much feedback as possible (N = 1, from my point of view) so we as a community can make the web version even better. To achieve that I have to start using the web version as well. So all 3: Mobile, Desktop and Web together. Then I can actually feel where work needs to be done (my way of working or missing features, etc) before I can drop the desktop app.
I will add Web to my subscription to start experiencing it with the editing posibilities. Now I only experienced the view only mode.
When I have feedback of the full web version I will let you know. I will be focusing on the way you maintain details because that is what I am doing quite a lot.
Making small and quick calls to load only a small part of the total data set. This is the easy solution in my opinion,
No that is definitely not the easiest solution. Doing lazy loading is much more complex than just download all data in one go. It is complex, harder to do well, especially if you do unloading as well, to keep the browser document manageable. Very complex, takes a lot of finetuning.
As I said, that would:
- take a long time to generate on the server side
- take a long time to download to your browser
- would possibly cause severe slowdowns on everything because of the huge document the browser needs to manage.
I think you are underestimating the size of the collections of our users. Especially for comics, typical collection sizes are 20 thousand, 50 thousand, many even over 100 thousand.
Your proposed solution will never ever work. Imagine loading the data for 100 thousand comics in one go…
Our solution is designed to be scalable.
Trust me on this, we got this covered. We have a team of smart developers here.
Feedback is welcome, but please stick to feature suggestions. We will do the UI design and the technical implementation.
That is why I share my experiences from a user perspective / functional level in my initial message. I know the game. As a developer I only want to get feedback on a feature level. Maybe if you take another look at my points and forget how it works with lazy loading etc. Maybe you think, hey this is something to add in the future. I think there is something possible with the second and fourth one if I look what nice stuff you already build.
Note: I have some bad experiences with a lot of companies where they don’t understand what is happening when I try to explain it from a functional level (something they should know). Only when I get to a technical level they finally acknowledge there is something wrong in their system. Sorry, if sometimes my behavior falls back to a technical level after my first functional explanation.
I have to ask you again, please stick to feature suggestions and bug reports, and as concise as possible.
We will worry about the technical implementation, and we will take care of the UI design.
Can we agree on that?
Yes. I though I already agreed on that with my reply.
Are my four points in my initial report clear enough? Or do you want me to explain it a little bit more? If I have to put them in boxes. Number 1, 2 and 3 are “Bugs” and 4 a feature request.
These 4 points are clearly not technically possible in a lazyloaded list.
We are aware of those drawbacks, but we do not see a technical solution.