Post-doctoral researcher at NTT Communication Science Laboratories. PhD from the University of Toronto’s Faculty of Information. I research values, labour, inclusion, and interoperability in communication technologies.
I just changed the look of my website, and I’m pretty happy with the results. The site still runs on WordPress, and I built a child theme from Matthias Pfefferle’s SemPress theme.
One of my main goals was to make my site a bit more fun and expressive, which I’ve accomplished in a few ways:
1. The new header uses ASCII art wrapped in an SVG. Because ASCII art is just text, it’s a bit challenging to make it responsive. Putting the heading inside an SVG allows me to fluidly resize it for different screen sizes. This ends up being a nice hybrid of old and new — ASCII art was an early method of representing graphics on computers, and SVG’s popularity on the web is much more recent. The ASCII art itself was generated by patorjk.com’s ascii-art generator.
2. Continuing the theme of old and new, the navigation menu uses the Meyrin font, which was created to resemble the terminal font in the Line Mode Browser — the first popular web browser. More about the font here and it’s worth checking out its use in CERN’s browser-based emulation of the Line Mode Browser
3. The background image for my site is a photo I took at Nanzen-ji temple in Kyoto.
Still a few bugs to work out (e.g. the header doesn’t display quite right in Safari or on Apple mobile devices), but I’m happy with the new look.
Today is day 2 of @IndieWebCamp New Haven: Hack day. My goal is to finish some work I’ve been doing to improve Yarns‘ UI. If I have time after that I’ll work a bit on my website’s structure. I’ll be hanging out most of the day on IRC and will be in and out of video chat at https://hangouts.google.com/call/BZQnCS1Tlsn8-p7udU1vAEEE
IndieWebCamp New Haven 2019 is a gathering for independent web creators of all kinds, from graphic artists, to designers, UX engineers, coders, hackers, to share ideas, actively work on creating for their own personal websites, and build upon each others creations.
I won’t make it New Haven in person, but I’ll be participating remotely
Showing off how easily quill.p3k.io can post to my site
Really enjoying the live stream of IndieWebCamp Austin: https://www.youtube.com/watch?v=bGENDlYMnm4
Seems like a lot of new faces, and some of the homepage demos highlighted the political (and emotional) stakes of carving out one’s own space on the Internet. I’ll be tuning in all day and chatting at https://chat.indieweb.org/
Here’s a quick reminder that IndieWebCamp Austin is this weekend. If you’re in the #DoOO, #edtech, or #IndieWeb spaces and can’t attend in person, there should be some interesting conversations and work that can be done to participate remotely (via chat, video, etc.) to help you improve and b...
Replied to a post by Jack Jamieson Jack Jamieson (jackjamieson.net)Thank you to @RyersonResearch and especially @joyceemsmith for inviting me to talk about my research today. I had a great time talking IndieWeb, and specifically, Bridgy.
I presented a study I’ve been working on about Bridgy, i...
Thanks Chris,
Actually we didn’t talk journalism very much. Most of the people there were from other parts of the same parent faculty as the journalism school (Communication and Design). I briefly talked about Storify’s shutdown since a lot of news outlets used Storify in its heyday.
Most of the discussion was a bit more general — future directions for alternative social media, regulatory responses, considerations for maintaining one’s values when using social media, etc.
Thank you to @RyersonResearch and especially @joyceemsmith for inviting me to talk about my research today. I had a great time talking IndieWeb, and specifically, Bridgy.
Jan 30, 2019 Lunch and Learn at Ryerson Journalism Research Centre
I presented a study I’ve been working on about Bridgy, in which I investigated the challenges arising from its use of Facebook’s API from 2014-2018. IndieWeb’s practice of syndicating to and from silos while also acting as an alternative to the ‘corporate web’ demonstrates simultaneous antagonism and dependence upon corporate platforms. My question then, is how this relationship might complicate IndieWeb’s efforts to build a Web that reflects its principles
I studied Bridgy by sifting through issues on its GitHub repo, identifying recurring challenges and how they were addressed. Additionally, Bridgy’s creator Ryan Barrett was kind enough to talk with with me about his work, which added context and helped me verify that I was on the right track.
I highlighted three recurring challenges in Bridgy’s development:
1. Mapping between the open Web, where resources are identified using URLs, and platform APIs, where they are are identified using arbitrary IDs. This problem kept recurring, which highlights the ongoing labour necessary to maintain a software like Bridgy.
2. Instances where Bridgy had difficulty determining the privacy status of posts or photos. These are thankfully uncommon, but present a significant problem when they do occur. Bridgy errs on the side of preserving privacy, but this has sometimes meant compromising its expected functionality.
3. Precarity of relying on APIs. For the most part, Bridgy is able to endure API updates due to ongoing maintenance work by its developers. However, Bridgy lost support for Facebook in 2018, when the API was updated with dramatic privacy restrictions. These restrictions are a response to Cambridge Analytica’s mass collection of Facebook data, but also impact legitimate apps like Bridgy (and Internet researchers). Fortunately, Bridgy still works with other platforms— e.g. The post you’re reading now was syndicated to Twitter with Bridgy.
The Cambridge Analytica news broke when I was in the middle of studying how Bridgy used Facebook’s API during the same timeline. Being immersed in Facebook’s API helped me understand some of the nitty gritty of what had happened and how this affected third-party developers, and I tried to convey some of that in my talk.
Finally, I think Bridgy’s development history demonstrates the kinds of challenges that arise when trying to build alternatives alongside corporate platforms, instead of simply opting out. While principled technologists attempt to build a Web for the future, they must work through the present. This means contending with messiness, heterogeneity, and resistance from established infrastructures.
Thanks to @schnarfed for talking with me about Bridgy’s development
Bridgy is an IndieWeb tool for syndicating content between a personal website and platforms such as Twitter, GitHub, Flickr, and Instagram. Until last year, it supported Facebook, but this feature was removed when Facebook tightened their API in light of the Cambridge Analytica scandal.
I’ll be talking about how Bridgy navigated challenges working with Facebook’s API from 2014-2018. I’m interested in how Bridgy uses Facebook’s API in ways that Facebook’s operators may not expect. I see IndieWeb’s syndication strategy (see POSSE on IndieWeb.org) as simultaneously antagonistic and dependent upon corporate platforms. By delving into this relationship, I’m trying to understand positive ways forward for building Internet tools that reflect their creator’s values. (In my case, I identify strongly with IndieWeb’s principles)
Chris Aldrich
Tantek Çelik