Comic-book viewer, Java Spring project

This is maybe more Javascript than Java at this point? I’ve been working on a comic book viewer. There’s a lot to do still, but the main design goals I had seem to be working. Curious if anyone is willing to give it a go, give feedback.

My main design thought was to try to maintain a sense of the page. I saw one viewer that would expand each frame up to the entire screen, and even though the image was nice and large, not knowing what was around it kind of didn’t feel right for a comic-book reading experience, to me. Maybe others disagree?

The second design thought was to make the viewing as mindless as possible, so that one isn’t distracted from the story while trying to navigate the panels. So, I set things up where the viewer “advances” to the next view automatically when you click “Next” or hit or . Getting the viewer to make good choices was a bit of a geometric-puzzle challenge.

I’ve only implemented 4 zoom levels ("+" and “-” buttons on top, or ), and 6 viewer-portal sizes (code automatically attempts to ‘best fit’ the current browser dims, but at this point they are all landscape oriented). I want to also get some touchscreen controls working (drag for repositioning, swipes, pinches for zooming). Most of all this has been written with Javascript. Gritting my teeth and getting some experience working with it. (Many functions, and tests for those functions, has been very helpful.)

The Java part is the interaction with the database, where we have images and panels and their dimensions organized, and using the controller code for maintaining state when changing pages. I also made an auxiliary Java app for encoding the panel locations and ordering.

Eventually, the comic book author will have his own site with links to the viewer (it’s very bare bones at this point), so only those links will require a port# in the address.

Also, I’ve put very little creative effort into the GUI for the viewer. That is not something I feel particularly good about designing, in terms of the look.

1 Like

Since this is still in early development you might already be aware of these issues, but just in case you are not:

Is the viewer not centered on the page on purpose? I’m on a 27’ 1440p monitor, so the viewer is in the very top left of the page. Doesn’t make for the best viewing experience. But maybe big screens are not your target audience?

Also, if you click on the zoom buttons ( + / - ) too quickly, without waiting for the zoom animation to complete, the buttons stop working entirely.

1 Like

Thanks! Yes, both these matters need to be addressed. I was aware but hadn’t dealt with them yet. Need to make a formal list for project-management purposes. It’s helpful to have it confirmed/reminded.

I’m in the middle of adding two portrait-oriented viewers. Adding them is not so difficult, but I think some down-stream logic will require re-entry of the “panel” data for the page. The program stalls (“prev” “next”) if it can’t zoom to a level that allows a full “panel” to show.

I think maybe something that attempts to maintain a zoom level might be good, too. So, if the “next” requires a zoom out, the following “next” attempts to zoom back to the initial level if the panel size allows it.

Some fixes and progress. I think I got the two suggestions from @Gjaller covered now. Still want to get to implementing touch screen gestures/mouse dragging, etc. But the basic mechanics of the on-screen buttons work pretty smoothly, it seems to me.

A couple problems with the tiny reader sizes remain, as the panel data needs to be re-entered to accommodate the minimum reader size.

Meanwhile, I’ve tasked the comic book artist with looking for other comic book readers for comparisons. I’ve found a couple (on the Libby library app, Kanopy, Hoopla).

I did some refactoring to try to clarify what is used for positioning calculations and what is used for actually changing the GUI. I can’t say it was a total success, but I think it is clearer than before.

The usual warning is “will you be able to read your code six months from now?” I think that is a “young brains” trope. If instead “two weeks,” the warning would still be perfectly valid.