User blog:JoshuaJSlone/DohBell: Improving mobile

Some of you may remember my H!P song database DohBell, which I started about the same time I started editing here. It now hasn't seen a significant update in over 2 years. Largely because as far as I know the only significant visitors were myself and search engines, so the hassle of updating started feeling like more than it was worth. I've thought about catching it up to date, but if so I want to improve and modernize the basics a bit, by making it suck less on mobile.

For a long time my web site design has been very straightforward and simple. Throw some text and tables, a few images where appropriate, and it's going to be functional for pretty much any browser. Until mobile browsing became more of a thing, and even more so when high resolution mobile browsing became a thing. Now my sites could render pretty much as if they were on a large monitor... only now the monitor was too tiny to see anything. So a day late and a dollar short, I've begun properly looking into ways to make things scale better for various resolutions and ratios.

There's still plenty to do, but there's enough improvement that taking a break and showing off some before-and-after sounds good to me. The following screenshots were taken with the Android version of Firefox.

Front page: There's not much to this page. I learned what to put in a page header to make it not treat every high resolution screen as high resolution as its physical pixel count, and that accounts for most of the change here. The only other thing I've done so far is make it so that the title image starts to scale down so it maxes out at 50% width.



Album list: Once the same fix was applied to this page that basically enlarged everything, two problems emerged. First: Without a wide view the two parts at top that are side-by-side continued to be side-by-side and just forcing one to scroll to see them. I've adjusted them in such a way that on a wide screen they're still side-by-side, but when things get narrow one goes above the other. Second: Lots of table data in a narrow screen gets messy. The biggest change here was not anything in coding, but in design. I changed which columns are shown by default--Seniority and AID are probably most important to me while working on the page, but not so much to anyone else. The Edition information is found within the album pages anyway, and the fewer links that are just one or two characters that a person might be expected to hit with their finger, the better. With those gone I made it so the album name has a link to the album page and not just the AID number like before.



Album page: I spent a lot more time on this one than the others so far, though it doesn't really show. A lot of time trying five dead-end solutions before figuring out a workable way to do things. Once the size adjustment was made, the images were way too big. Took a long time to figure out the proper way to scale them like I wanted. One thing I did fail to do is find a way to split the cover rows up nicely. In this example it works out well, 3 and 2, but something like 3 and 1 is also possible when I'd rather it be a more even 2 and 2. BUT making that happen seems a lot more hassle than it's worth.



That's it so far. The rest of the pages are largely more of the same, so what I've done with these pages will make those go much more quickly. The biggest problem, I think, is simply that so much of the data is presented in tables, and there's really no good way around that. One of the things I read was about best size to make buttons to make them finger-friendly, but making sure that applies to every link in the tables would make things pretty bloated. Right now the compromise solution I'm considering is that beneath a certain screen size (so, when it is probably on a mobile device), somewhat increase the height of each row. Enough of them already wrap around into a second row (see the album list where Morning and Musume always end up on different lines) that it shouldn't seem too out of place.