Drafting #IndieWeb Principles for the Rest of Us

Community
I woke this morning to see the weekly discussion of “What is #IndieWeb and what is not” flared up again last night. Eventually someone points to the principles page. Yet to the audience I serve these set of core ideals can chase folks away for being too technical. So I wanted to remix them to see if I get develop the same principles for a non-technical crowd.

I started by forking the original list and trying to make the language more inclusive. I did add one new principle about actively building for diversity as like all things tech #IndieWeb is too white and male.

This is just a starting point and this draft is not official #IndieWeb stuff. Just me having fun trying to help the community.

Current #IndieWeb Principles

  1. Own your data.
  2. ???? Use visible data for humans first, machines second. See also DRY.
  3. ???? Make tools for yourself first, not for all of your friends or ”everyone“. If you design tools for some hypothetical user, they may not actually exist; if you make tools for yourself, you actually do exist. It’s extremely hard to fight Metcalfe’s law: you won’t be able to convince all your friends to join the independent web. By making something that satisfies your needs, and is backwards compatible for others, e.g. by practicing POSSE, you benefit immediately, without having to convince anyone else. If and when others join, you all benefit. This principle is also known as scratch your own itch (See also: The Cathedral & the Bazaar lesson #1).
  4. ???? Use what you make! AKA eat your own dogfood. Whatever you build you should actively use. If you aren’t depending on it, why should anybody else? We call that selfdogfooding. Personal use helps focus your efforts on building the indieweb around your needs and consistently solving immediate real world problems. selfdogfooding is also a form of “proof of work” to help focus on productive interactions.
  5. ???? Document your stuff. You’ve built a place to speak your mind, use it to document your processes, ideas, designs and code. At least document it for your future self.
  6. ???? Open source your stuff! You don’t have to, of course, but if you like the existence of the indie web, making your code open source means other people can get on the indie web quicker and easier.
  7. ???? UX and design is more important than protocols, formats, data models, schema etc. We focus on UX first, and then as we figure that out we build/develop/subset the absolutely simplest, easiest, and most minimal protocols & formats sufficient to support that UX, and nothing more. AKA UX before plumbing.
  8. ???? Build platform agnostic platforms. The more your code is modular and composed of pieces you can swap out, the less dependent you are on a particular device, UI, templating language, API, backend language, storage model, database, platform. Modularity increases the chance that at least some of it can and will be re-used, improved, which you can then reincorporate. AKA building-blocks. AKA “small pieces loosely joined”.
  9. ???? Longevity. Build for the long web. If human society is able to preserve ancient papyrus, Victorian photographs and dinosaur bones, we should be able to build web technology that doesn’t require us to destroy everything we’ve done every few years in the name of progress.
  10. Plurality. With IndieWebCamp we’ve specifically chosen to encourage and embrace a diversity of approaches & implementations. This background makes the IndieWeb stronger and more resilient than any one (often monoculture) approach.
  11. ???? Have fun. Remember that GeoCities page you built back in the mid-90s? The one with the Java applets, garish green background and seventeen animated GIFs? It may have been ugly, badly coded and sucky, but it was fun, damnit. Keep the web weird and interesting.

Drafted Principles for the Rest Of us

        1. Own your data. Having a domain and website is the first step. Why should you give big social media companies rights to everything you make?
        2. ???? Learn a bit of HTML. Start off with a website “out of the box.” Everyone else did. but a major goal of the IndieWeb is to make sure people and not just machines can understand how your website works. The best way to do this is learn HTML over time
        3. ???? Use IndieWeb Tools A lot of good people make tools that allow to POSSE, Publish on your own site and syndicate elsewhere, It’s extremely hard to  convince all your friends to join the independent web. By using our tools to making something that satisfies your needs you benefit immediately, without having to convince anyone else. If and when others join, you all benefit. This principle is also known as scratch your own itch (See also: The Cathedral & the Bazaar lesson #1).
        4. ???? Try first, ask second! AKA eat your own dogfood. Whatever you build you should actively try and use.  We call that selfdogfooding. Personal use helps focus your efforts on building the indieweb around your needs and consistently solving immediate real world problems. This stuff is hard and the community is here to help but assistance is easier to provide when you first try to help yourself.
        5. ???? Learn Out Loud. Document your stuff. You’ve built a place to speak your mind, use it to document your processes, ideas, designs and code. As you start your IndieWeb journey. At least document it for your future self.
        6. ???? Open source your stuff! You don’t have to, of course, but if you like the existence of the indie web, making your content open source means other people can benefit. Depending on how you licesne the work they can remix and reuse it. This makes the IndieWeb quicker and easier.
        7. ????Content is more important than design. Do not worry about building the perfect site. Just get your content out there. That is step one. Then think about the user experience and the design. Storyboard your website or draw protocols. Make sure you meet accessibility standards.
        8. ???? Create building blocks of your idenitity. As you build your site you will want to make sure you can move parts to other services. The more your website is composed of pieces you can swap out the easier it will be to switch websites hosts in the future.
        9. ???? Longevity. Build for the long web. If human society is able to preserve ancient papyrus, Victorian photographs and dinosaur bones, we should be able to build web technology that doesn’t require us to destroy everything we’ve done every few years in the name of progress. If you own your content you don’t lose it when social media shuts down.
        10. Plurality. With IndieWebCamp we’ve specifically chosen to encourage and embrace a diversity of approaches & implementations. This background makes the IndieWeb stronger and more resilient than any one (often monoculture) approach.
        11. Plan for Diversity Actively encourage people from under represented groups to the #IndieWeb. Learn to listen to other communities. Find out how they #IndieWeb can help and then invite others on the journey. Be careful in your language as we build communities. Words like “ninja” and “rockstar” may not resonate. 48 hackathons may not be open to all. If you plan #IndieWeb events think about childcare and low bandwidth communities.
        12. ???? Have fun. Before the rise of social media everyone’s websites were different. For example in the mid 90’s Remember that GeoCities pages may have, garish green background and seventeen animated GIFs? It may have been ugly, badly coded and sucky, but it was fun, damnit. No we all look the same. Keep the web weird and interesting.

         

      1. Featured Image credit: “community” flickr photo by LilySusie https://flickr.com/photos/lilysusie/2095648843 shared under a Creative Commons (BY-SA) license

Also published on Medium.

9 responses on “Drafting #IndieWeb Principles for the Rest of Us”

  1. I really enjoyed this, Greg. I like how simple and approachable it sounds.
    @aaronpk, I definitely think these should be looked at during the Leaders Summit. I think some modifications to the Principles similar to what Greg has written could be super beneficial.

  2. I love this!

    There’s one thing I disagree with in your list, and one from the original, that I think is worth unpicking:

    1. “Learn a bit of HTML.” I don’t think that should be necessary; a world where anyone who publishes is using HTML isn’t achievable or even necessarily desirable. And it creates a situation where people with technical skills have elite status over people that don’t.

    2. “Make tools for yourself.” The premise is flawed. Made-up personas are certainly a bad idea, and creating software without having a user in mind is also terrible. But if we all just build for ourselves, the result is software for technical people. That’s kind of boring, but also counter to the mission of the indieweb as I see it. Instead, I’d propose: “Make tools for real people you care about.” That could be you; it could be your partner, or your family, or a community you want to support. It turns indieweb into an outward-facing, open endeavor instead of an introverted one, while staying true to the ideal of building for real people.

    1. Ben,

      Thanks for the comment. Yes trying to to come up with the equivalent for “Make tools for yourself” was difficult an d”learn a bit f HTML” isn’t a perfect fit. Yet I am okay with it. I tried to think what would we need to do in K12 education to get students to a place where they could, “Build tools for and with a community” by the end of high school.

      I am not a believer in #CS4ALL (computer science for all movement) but I do want every child ready to pursue that path by middle school/high school if they so choose. So I thought beyond computational thinking what would be the best way to get folks ready. I settled on learn a bit of HTML.

      I believe the web has fundamentally shifted the way we read and write and I have responsibility as a literacy teacher to prepare students for this reality. Having tudnets make a website on wix, weebly, or Google Sites is not enough. That would be like telling students to download an essay, change a few words and call it their own.

      The Holy Grail Design (Header, Nav, Body, Aside, Footer) is the five paragraph essay of the web. Just as I teach text structure of essay writing I believe we need to teach text structure of the web. I believe your alternative leads to ignorance and the rise of silos in the name of convenience.

      First I have spent a career working with too many adult educators who can not share a link or add one to an email. Mainly because they do not understand the underlying technology. As we approach three decades of the web this is inexcusable.

      I am not saying every person must master web design but if we want to build a better web that embraces the values of the nineties, without excluding 85% of the world folks need a tiny bit of HTML. The telegraph ushered in a new era of cursive writing to meet the needs of the technology. The web should do the same in school. In fact to find th time I would just have HTML replacecrsive as a now outdated technology.

      You are right we have to ensure HTML isn’t a skill of the technical elite and the best way to do that is to teach the masses.

Mentions

  • Aaron Davis
  • Possible cultural & technological futures of digital scholarship
  • Grant Potter

Leave a Reply

Your email address will not be published. Required fields are marked *

To respond on your own website, enter the URL of your response which should contain a link to this post's permalink URL. Your response will then appear (possibly after moderation) on this page. Want to update or remove your response? Update or delete your post and re-enter your post's URL again. (Learn More)