About web site

Introduction

This web site is partly for exploring and demonstrating some Web publishing methods of current interest to me. I've worked on Web design, publishing, and collaboration more or less since it emerged, with the launch of the 1st web browser Mosaic in 1993, so the notes/practices here come from many reflection, projects, and experiments, in a variety of contexts from large organizations to startups to civic initiatives to personal publishing.

This site is hosted on the free Google Sites service, which launched in 2008, and which in my assessment is a surprisingly good and underappreciated web hosting platform. I think it serves well my and many people's purposes. for many Web tasks.

I'm quite wary of Google and other BigTechs' power and practices, and would generally prefer to use open-source and decentralized tools. However, for me maximum usability and collaborability are paramount, and here as in other things I reluctantly find Google's offerings compelling, particularly in combination. I and a preponderance of people I know use Google tools for core workflows like email, documents, calendar, and file handling/sharing. Google Sites is a good web publishing tool because it directly integrates, in many way works similarly to, and extends those other tools.

Google Sites itself is somewhat limited in customizability, and in extension to other capabilities e.g. e-commerce, compared to, say, WordPress software's great extensibility and plugins ecology. However:

• Other tools and services very often could integrated into a Google Sites site by embedding them into pages. You can also have other services at a subdomain URL (e.g. shop.ourorganization.org) or just link out to them, perhaps using some design/branding elements at the destination service to unify the experience for the user. Many web sites do this all the time, and most people hardly notice or care.

• For most people and purposes, the additional customizability and fine-tuning of appearance offered by other site-builder tools is often unnnecessary, in my opinion; and it tends to divert focus, and make it harder for most people to have a hand in developing and maintaining sites.

• You can evolve a site to another platform later if need be, and use the fast easy site in the meantime until its successor is ready to launch. In fact I think it's often an excellent strategy to create a web site initially, quickly, and simply, with the easiest possible, preferably free tool, and then evolve it.

Key goals, and how Google Sites helps.

Easy setup

For me, good tools are those which best facilitate capability, comfort, and flow. In the high states of productivity (also often, of satisfaction & pleasure) described by 'flow'), characteristically one is able to mostly remain focused on the goals, and collaborators if any, and on high-level foci such as one's mental model of the work subject, open imagining, or adapting from inspiring material. That is to say, not focusing on or perhaps even conscious of the tools.

A principle of user-interface design (UI / UX) I've long espoused is, the best user interface is often the one the user is already using. [I think I coined, or at least independently came to, this formulation, though it is basically applying a famous founding statement from "ubiquitous computing" field, that "The most profound technologies are those that disappear," from Mark Weiser of Xerox PARC, in"The Computer for the 21st Century" 1991 ].

Meaning that, if the goals/task can be achieved without having to create or get users to employ a new interface, this is probably better. From my perspective, I and most people I work with already do or can write/edit in Google Docs, and manage resources in Google Drive with its well-understood conventional folders and permissions structure. So if a web interface and publishing system can be wrapped onto that with little to no effort, this has some strong advantages.

[Aristotle said, character is that which you do regularly. Similarly, you might say the true character of a tool/product is defined by what actions and experiences it most regularly, consistently facilitates].

So I suggest, for an easy & effective quick start:

1. create a Google Site, and make one or a few pages such as a home page saying who/what you are, perhaps separate About, Contact pages.

2. If possible, display or embed on the home page anything that shows project activity/conversation: e.g., your project's Twitter feed.

3. on the Home page, embed a view of a Google Drive with your project materials. Any materials or folders you don't want to be publicly visible, set their permissions to "Restricted: Only people with access can open with the link."
   
   Note, you can also make folders that are public, but have everything inside them non-public. In some cases I might suggest this for transparency: i.e. a passer-by or potential project participant can see how matters are set up, and perhaps be encouraged by seeing signs of transparency, activity, and collaboration.

4. Any web pages you want to do, you can start them as a Google Doc in your Drive. This makes them easy to write/edit, and collaborate on.
   
   Then at a later step, create a new Page in Google Sites and embed that doc: either with a "Full page embed" or by embedding it as one page element, perhaps with some web page text above it to introduce it and instruct user to click on the doc or the doc icon below to read full document.
   
   Also, you could, then or later, turn the full Doc contents into a Page. This will display somewhat more easily for web visitors, but require use of Google Sites thereafter for editing; so perhaps do this once a page contents is stable, or if its only maintainers don't mind using the Google Sites interface.

5. You could also embed other Google Drive views on the Home or other pages, for example to show a relevant sub-folder, or even a Drive folder owned and managed by a project partner, or some other part of the team.

From that simple step onwards, you will in a sense have a fully functioning and fully up-to-date web site that the right people can easily update and manage, using tools they already know. It will have greater usability for your team/org, and be more up-to-date and transparent for any web visitor, than 99% of all web sites out there.

Co-governance, co-ownership

These are often important issues for an organization's site, but not really for a personal site like this.

I write about these topics and suggested approaches in ongoing article, "Equity Organizing", section "Building co-governed, collaborative media tools", which also incorporates most of the contents of this "About web site" page in somewhat rewritten form.

Decentralization

You can have a Google Sites site display Google documents or folders that are hosted/owned elsewhere. This is quite helpful if you have a decentralized organization in which various parties might start & own documents or folders of materials. People tend to this naturally, when using the most-at-hand tools, and it's a good idea to pay attention to what people, unprompted, find the easiest way to do something.

Also, letting project participants start, own, and manage their own documents and folders, while it could be a mess, might also be a good way to enact/allow collaboration and share trust, without having to do so formally/explicitly.

Mobile, life-embedded, continuous partial engagement work

While "lean-forward" tools/interfaces like a desktop or laptop computer -- as opposed to "Lean-back" tools, in Jakob Nielsen's terminology -- may conduce to focused 'flow' working, sometimes also good flow and productivity comes from having minimal barriers to action. For example, being able to turn to a mobile device easily any time, and see or add to work. This is a key idea of "ubiquitous computing," noted above, in which many capabilities require little to no "turning to", but are automatic or at hand.

Google Docs pioneered and continues to lead in mobile, realtime-collaborative document editing, and Google Drive also has high mobile usability. So I suggest, a great solution for a lot of cases is to set up a Google Sites web as described above, thereafter allowing most people most of the time to do all editing and managing of the web site using GDocs and GDrive as they already know how to use or could easily learn to.

Free service

Anyone can set up a site, to appear at URL sites.google.com/view/[SITE NAME]. You can, optionally, register and use with it your own domain name, e.g. "tmccormick.org", registed at Google or any other domain registrar.

You can also get comparable free hosting on other platforms such as Wordpress.com (which offers hosting using the very popular free/open-source blogging software WordPress). Your site will then typically be reached by a 'subdomain' URL, such as "tmccormick.wordpress.com". However, my hunch is that these other services aren't as long-term stable as Google's is, and they don't offer as good likelihood of archival stability (see next point).
Also, such platforms are generally offering paid levels of service or add-ons, and I find that in using them, and Wordpress site-building tools generally, you tend to be beset with distracting/confusing upsell promotion.

Google Sites, by contrast, offers no paid services, and seems quite free of upselling or cross-marketing confusion.

Archival stability and discoverability

Google Sites sites are free and apparently remain up perpetually -- though they don't make any explicit commitments of longevity, as far as I know. So is true of e.g. Wordpress.com free sites, but my guess is these are less likely to be long-term stable. Also, significantly, the way Google Sites works is, you set up the site with sites.google.com/site/[SITENAME], and this URL works ongoing, whether or not you also set up a custom domain, or whether that domain registration in future lapses or gets used for something else. [not true, I think, with Wordpress.com and other free hosting platforms, although I haven't entirely verified that].

Incidentally, a good strategy for any person/org really concerned about archival preservation of your web materials, is to do initial and ongoing automatic saves to Internet Archive. It's easy to do this manually for any URL, using the Save Page Now feature at https://web.archive.org/. IA will also automatically tend to pick up and archive your pages if they are publicly linked to much, and there are way for larger projects to setup automatic archviing.

Some Google Sites features that help ease of use:

I've compared Google Sites to various other site-building options such as Wordpress.com, Wix, Squarespace, and free Wordpress installation as offered by general web-hosting platforms like Dreamhost. I find Google Sites to be the easiest way to set up and maintain sites, and crucially, the way in which others are most likely to be able to take over or share in creating and maintaining the site. In my experience, most web sites die, go stale, or underfunction because of the comparative difficulty of maintaining and collaborating on them.

Some of the features contributing to ease of use:

• Simple, intuitive, visual page layout and site layout tools
  It offers a true WYSIWYG (What you see is what your get) page editor, and I've found this has unusual usability-enhancing features such as the editing view remaining functional e.g. so you can follow links to switch to editing other pages, without having to stop and save the page each time.
  
  Also, I find the site layout tool, which runs in sidebar, to be quite intuitive and easy to use, and it also doubles as a helpful site outline view visible while you are editing pages, giving you good overview and an indication of where the page you're editing fits into the overall site plan.

• Easily add and rearrange helpful set of page/URL types: the add ('+') button gives you a choice or new page, or web page that "Full page embeds" a Google Doc, or Link (a page redirect, which can be to any URL on or off site). You can easily easily customize the URLs.
  
  I've spent a lot of time twiddling with various technical methods elsewhere to get URLS & pages to appear or redirect as wanted — in part because I'm among those who believe good URL design is a crucial part of good Web design. So I appreciate how easy Google Sites make this.

• Runs in browser, with minimal resource demand
  Other tools such as Wix's site builder and Wordpress tools run in browser, but I've found that Google Site runs more easily and faster, and even can be partially used on mobile device. I often use an ancient 2009 Mac desktop — living on the edge! — on which newer software doesn't work and many web sites barely work or tend to crash the browser or whole computer, so I'm quite sensitized to and constantly observant of web sites/tools that are resource-consuming or buggy.
  
  A behavior I've particularly observed and appreciated is the speed and clarity of the Publish (i.e. repost site after changes) function. Much of maintaining/editing a web site is making changes and republishing repeatedly, so when the tool does this efficiently it's a really noticeable help.

• Stored mostly in a single file
  which is easy to understand, back up, share, manage permissions for, etc. Of course, things like included images and documents are separate files, as you would want.

• Auto-saves while working
  This is now standard and expected behavior in software. Any software/web tool not doing this is embarrassingly archaic and going to be causing big problems constantly. (I'm talking to you, WordPress and MediaWiki!).