Tuesday, December 27, 2022

an ode to LiveJournal

 Man, what happened to the community of LiveJournal?

They just sent me a kind of pathos-laden "hey happy 19th anniversary of starting on LJ!"

For those who don't know, it was a fairly popular (at pre-Twitter, pre-FB, pre-YouTube levels of "popular") site that let people have their own blogs, and you could see and comment on the posts of your friends aggregated on a "feed" page.

I didn't post there, since I had already started my own blog (and had just added a comments board that was the nucleus of its own little community - in fact I had a sidebar microblog for other people to write on the front page...) so my LJ account was for following others and participating in comment threads.

It's notable that many of the final-ish entries of my friends (many in 2010, then more in 2016) mention twitter which is where I assume most of that energy left. Actually, to make a Just-So story: 2010 is when folks who were fonder of the community of folks they know in real life jumped off for Facebook, and 2016 is when folks aspiring to get a wider audience and maybe go viral left for Twitter.

LiveJournal encouraged thoughtful writing in paragraphs; I guess medium now has most that vibe. Maybe substack, but they seem to lean on individual newsletter-y bits. But neither medium nor substack emphasize the "shared feed"/wall/stream that twitter, tumblr, instagram, FB etc have, where posts from a variety of people you find (or The Algorithm hopes you will find) interesting will be on a single scrollable page.

As far as I know LiveJournal was the strongest attempt to encourage longer length writing with entries that were then blended onto feed pages. (Standalone blogs had RSS to collate from sites, but Google embraced and then extinguished the most promising attempts to make that friendly to less technical users. I never got into reading via RSS, frankly, because extracting just the text out of the visual context of its home site made me feel something was lost.)

I think that "are you encouraged (by the UI, or the community vibe) write in paragraphs or sentences" - that's a big part of what separated LJ from Twitter (and also old Usenet (which I used to love) from Reddit, which has never really clicked for me.)

And it's just that short-form mojo Twitter that has, (or a visual, easily digestible image-based approach that Instagram, Tumblr, and even FB) which lends itself to The Algorithm mixing and matching and letting you find new people based on what people you already follow are also digging. Which when I write it out, does sound rather herdish, or redolent of the maddening crowd. Finding new interesting people on LJ was slower, and more organic, generally by following up co-commentators on mutual friends, because going through someone's LJ entries was a longer-attention-span thing.

I've been leaning into tumblr more lately, which (like twitter) I'd mostly been using as an information consumer and not a contributor. Sometimes I wonder if I had started reposting my blog content there years ago like I have been on FB, if I might be have found an even stronger community there (or a set of "mutuals" as they're called). Tumblr has cultural space for both long paragraphs and for quick hit images, and a unique style of additive reblogging that keeps contact with the original post while still getting people to riff.

Monday, December 26, 2022

interactive guide to getting a feel for flexbox

An Interactive Guide to Flexbox by Josh W. Comeau.

I admit, I don't think I quite get it... like I wanted a version of the first example, but where it never went to 2 lines, just one line or three, which was the spec, but I couldn't quite find the magic to make it work...

Sunday, December 25, 2022

how often is Christmas on a Sunday?

 Joined my folks for Church stuff this Christmas day, a Sunday, and the minister mentioned we wouldn't have another Christmas Sunday until 2033!

Curious, I made up this jsitor to see which years had Christmas Sundays, and then what was the pattern.

So day of week for a certain date (I'm sure very similar for all post-Feb 28 days, and then probably roughly similar for days before) repeat every 5, 6, and 11 years, depending on if the leap day is with or against it and then sometimes skipped. 

It's nice to be able to compute this stuff out, though not as interesting as 2013's Thanksgiving on the First Day of Hanukkah - something said not to recur for 70,000 years. 

UPDATE: either jsitor isn't design for codepen-typing sharing (like, optimized for live sharing) or I'm doing something wrong, because my snippet went away. But I reconstructed the logic:

function getDayNameForDate(date){
return ['sun', 'mon', 'tue', 'wed', 'thu', 'fri', 'sat'][date.getDay()];

let lastYearWithXmasSun = 2022;
for(let year = 2023; year <= 2222; year++) {
const date = new Date(`December 25, ${year} 12:00:00`);
const dayName = getDayNameForDate(date);
if(dayName === 'sun'){
console.log(`${year}: ${year - lastYearWithXmasSun}`);
lastYearWithXmasSun = year;

In general, that refreshes my biases about depending on fewer external sites for my blogs. In particular I'm really said how many embedded videos on my blog have gone away when I look at it on this date feature... I mean many of the links are broken too but they're not as visible a scar. I bemoaned that process, and the disillusion about how a URL could/should be "forever", in November.

Wednesday, December 14, 2022

viewport 101

 The meta "viewport" setting is so fundamental to the mobile web experience that it's easy to miss, and so therefore weird to correct if you don't know what to look for.

It's the line in the header that tells a device (I'm not even sure if it tends to matter on desktop?) roughly how many pixels the screen should start as.

So here's a more or less normal test page with the viewport set.  (Specifically with the fairly typical formulation <meta name="viewport" content="width=device-width,initial-scale=1">)

If you resize a desktop browser window, all the squares stay about the same size. and the flow layout moves them around. I put a watcher on the resize event so it tells you how wide it thinks the encompassing gray box is. 

Here's the same page without the viewport line. On desktop it is practically identical, but if you go into Chrome's developer tools and toggle the device toolbar, you will see something odd... if you put it in Dimensions: responsive, no matter how wide or narrow you make the window, the offsetWidth is "980" - and the boxes shrink like you were zooming out, they don't rearrange. View the "with viewport set" page  and you'll see the desktop-like behavior is restored.

Notice even though I've set the device width to 480, the box thinks it's 980 across...

What's going on? My guess is in the early days of smartphones that had proper browsers (i.e. the 2007 era iPhone) websites obviously weren't set up for mobile... but a typical laptop window of the day might be around 980 pixels, give or take, and so the initial, unzoomed view started at 980 across, so that the (quite possibly table-based) layout of the sites would make sense. That's why a page without the viewport line seems weirdly zoomed out on a real phone, and why the scaling (of the responsive windows, as if you were using different devices) in chrome is so odd. But if you set the width to viewport width to device-width, you get a more reasonable result (heh, my big iPhone Pro Max starts the device-width at 430; my partner's older iPhone X says 375. But of course that's like px, both are "retina" devices with many more actual pixels than that. Still that's useful... I wasn't quite aware that layouts for phone should be focused on that 400px range...)

Of course you're free to manually specify a starting viewport width, ala  <meta name="viewport" content="width=450;" /> (It's bad form and maybe blocked to try and stop your content from being zoomed; that's a big accessibility no-no)

This came up at work - it took me a while to figure out why we were seeing that second style of zooming in chrome, but it was because we were looking at a code snippet in the browser, and not a whole page (which would presumably set the viewport early on) So even though viewport is fundamental to the mobile web, it makes sense that a lot of UI devs haven't run into it; it's probably set up earlier in the project, like in the "boilerplate" code that launched in, and once you set the width to device-width everything pretty much "just works" like you would expect...