Hey #believeinfilm friends,
Have you ever wondered if your chemicals are still good, whether they got weaker, and if so, how much should you extend your development time by?
I wrote for 35mmc about Chem Log, a new app made to save you money and help you get better results on film:
The article explains how to use it and why you may want to do that instead of keeping shotty or no records.
I built CL. Any feedback?
@analog_cafe Is there any scope for moving this away from the "web app" model to actual iOS & Android apps? This is one of the few occasions where I actually think push notifications could be justified, and I'm outright against web browsers having access to push notifications on any mobile device for a whole slew of reasons.
@coldkennels there is the concept of PWA with the ability of push notification. idk if it works here.
@analog_cafe today i had to wash successfully my negatives with fix again. they went from very foggy to clear. have to look at your tip.
@coldkennels Yes, I'm considering this, but it may take a while. The challenge is the app store fees and personal time.
Do you think email notifications could solve that problem?
@analog_cafe Possibly, but I suspect you'd end up getting your email domain flagged as spam one way or another.
I guess you could use SMS - or even a Mastodon bot. That could be fun, now I think about it.
@coldkennels If the notification issue is solved, would you still prefer a native app or would a web app be OK?
@analog_cafe Honestly, even if you ignore all the issues I raised in the other thread that's come out of this, I don't really *get* web apps. I've tried a few over the years; it's too easy to forget they exist. I'd be curious to see how much engagement/usage yours get.
If it wasn't for the fact this is the sort of thing you'd want a mobile device for, I'd argue a lightweight program that can be hosted on Github and installed via Brew.sh or any other package manager would be better.
@analog_cafe Case in point - the two programs/apps I use most with relation to film photography (outside of the iOS/OSX Notes app) are AnalogExif, a 38MB piece of abandonware on SourceForge (https://sourceforge.net/projects/analogexif/) that hasn't been updated since 2010, and ExifTool, a command line util which is about 5MB. Both are more streamlined and faster to use than any webapp.
@coldkennels From a developer's perspective, it's a whole field of study that's different from native apps, which is why I have to be sure before diving into native apps.
Web apps are seamless with the rest of the web, which is why you may not notice them. Every single social network, inc. Mastodon is a web app. Online payments are web apps, etc.
Web apps aren't the right tool for everything, but they are lighter and more accessible. They could even be better if Apple and G didn't kneecap them
@coldkennels The programming languages and tooling for iOS, Mac, Android, and Windows are different. Plus, there's Linux. All these platforms require some kind of registration and vetting and often payments. This is generally what's preventing me from taking them on. But I can build a command-line tool using the same tech as in the web apps (but that may be a little too painful to use for some folks :)
@analog_cafe Yeah, I work in web dev, so I'm familiar with the concept. I'm also aware that a lot of "programs" are now basically just web apps in a container; I can't say I'm a big fan of that, either!
For instance, it's one thing having something like a Mastodon client being a web app (I'm using Sengi on OSX at the mo, which just the Sengi website in a wrap to make it look "native"), but with tools that you use regularly but actively don't *need* to be online, it doesn't make a lot of sense.
@analog_cafe Even if you get past the need for an internet connection, there's also the overheads involved with a constant connection & a browser. One huge bugbear for me is how many websites (and, by extension, web apps) are designed for the (comparatively) high-end devices and connections the designer/programmer uses, without any consideration of how poorly they will run on old hardware or intermittent or slow internet connections.
@coldkennels won't disagree with you here. There's tech to make web apps usable offline but it's complicated, hard to test, and flaky. The native mobile frameworks also have some UI interactions that are hard to replicate and maintain. Many of my native apps require an internet connection, though. I wish they didn't.
@analog_cafe I do some work for a client who buys into every single bit of business tech possible - Google Cloud, Monday.com, Canva, etc.
None of them run as quickly or efficiently as basic .rtfs, emails, and so on. Even Photoshop is faster and smoother than Canva, for god's sake - and new versions of Photoshop aren't exactly efficient!
There's been such a push towards "the cloud", AI integration, beautiful UX, and all this fancy tech bro bullshit, but actual *performance* has really suffered.
@coldkennels Yes, there are some performance bottlenecks on web apps, for sure. It's hard to be a technologist and navigate the hype because it can definitely lead astray. I'm lazy and cynical, which has paid off so far lol
@analog_cafe I think another part of my concern is that a lot of things that are being presented as a good idea (like web apps) end up benefitting companies more than the end user.
Take, for instance, the rhetoric around Apple restricting what websites can do on iOS; this is very much a Good Thing. I bought into iOS precisely because I don't want random websites having access to the operating system, and it's no surprise companies like Google are criticising Apple for this position.
@coldkennels In some cases, yes. I benefit from saving a lot of time building a single app for the open web rather than dealing with multiple languages, frameworks, and walled gardens within native app stores. In some cases, this may be detrimental to usability.
But web apps can also be easier to secure (they show requests and are easy to sandbox; native apps do almost anything on your machine opaquely), they don't need gigabytes of space, and they are theoretically compatible with all devices.
@coldkennels I see a lot of websites like that. I promise you this is the result of a subpar effort by the developer and not the technology. Because JavaScript/HTML is more accessible than, say, C++, many programmers making websites are simply not experienced enough to think of performance.
@analog_cafe Ah! Found it.
This is perhaps the best example/explanation of what I meant by web bloat: https://danluu.com/slow-device/
Edit: another way of thinking about this is my battered old 2008 Macbook still runs AnalogExif and ExifTool without issue. But because of the gradual bloat of browsers, it cannot run any current release of any browser - meaning it cannot run *any* web apps.
This push towards the "browser operating system" is rapidly increasing e-waste.
@coldkennels This is a nice resource, I'll have to look into this more. Part of my job is researching and implementing best performance practices. But as I mentioned earlier, because the web is easier to build for, there are more websites (than apps) built by people with more diverse backgrounds, which means that many of them are lacking.
Flipping the script: this table makes 13MB look bad, but what about Mastodon Web (3.2MB JS/CSS/Docs/XHR) to Mastodon iOS (55.4MB + all future requests)?
@coldkennels Follow up to the edit: web browsers are native applications, which are to blame for the lack of backward compatibility. PWAs are 100% backward compatible, which is why you can still browse the new internet on the older browsers on your 2008 Macbook! I'm curious if my blog will still run on your machine, if not, perhaps there's something I can do better. 2008 is not that long ago
@analog_cafe The problem I'm getting at is that browsers themselves are hilariously bloated these days, and a lot of websites don't support older and more lean browsers.
I used Camino for YEARS after it was officially discontinued. It was the fastest & most streamlined browser I've ever used, but most of the modern web just won't display on it at all now.
I jokingly said on here once that if your website will run on the browser on a PSP, you're doing something right. I'll have to check yours!
@analog_cafe Okay, I can report: analog.cafe will not work on a PSP; that browser doesn't like the fact it's forced into https.
However, it *does* work on a Vita, which is quite impressive (that browser is from 2011 and laughably bad). It won't display a single photo for some reason, but hey, at least I can read the text without the Vita running out of memory.
Next week in dumb website testing: can we access Librivox on a Nintendo DS?
@coldkennels Haha, this is fun! It also gave me an idea: if the website can run on Windows XP machines, it can run on computers that power vintage film scanners. I can think of at least one practical use for that!
@analog_cafe what’s the last supported version of Firefox on XP?!
I’ll have to try the PS3 browser next time I turn that on. That was the only web browser I owned for a while back in 2006, and it was surprisingly useable with a USB keyboard and mouse!
@coldkennels Don't know if it's the latest, but the one in the screenshot is Firefox 52
@analog_cafe I guess the Mastodon comparison comes down to caching vs. locally stored material. In theory, a one-off download of the bulkiest parts of the whole process that is never/rarely altered is far better allocation of resources than constantly/regularly redownloading the same thing over and over again.
The problem of course - like I acknowledged - is that a lot of "programs"/apps are just containers for a web app anyway. I checked on Sengi, and sure enough, it's "built" in Electron.
@analog_cafe ...this sort of scenario was what Java was designed for. I've got a few old Java "apps" sat on the hard drive of this laptop that I've carried forward across multiple systems with multiple operating systems. Is it the cleanest setup ever? No, but it *does* work.
@coldkennels Java was cool, very powerful stuff. I'm not sure I like the containerization like that, though. Same with ActionScript (Flash) and even HTML Canvas. But there's new tech out there that lets us write native components and execute binary code, which is what native apps do. It's a little weird and definitely right for all uses
@pixelroiber @coldkennels yes, these could work, may need to consider some services 🤔
